On 2015-10-25 12:06, Graham Samuel wrote:
The discussion about Open Language is interesting, and the idea may
well be a good thing. But I for one would rather hear that for the
actual development team, delivering a rock-solid version of LiveCode
on all supported platforms is taking a massive priority over even
thinking about this stuff. Peter Brett, can you reassure me, as a
member of the use list?
Obviously delivering a rock-solid version of LiveCode on all supported
platforms is the most important thing. It is something I have been
working on ensuring ever since I joined the company in 2004.
We have done many significant things over the years to help reach this
goal - starting off in 2004 with auditing the bug database (as it was
then) and putting the engine source code under version control.
In more recent times, we have:
- Implemented an out-of-tree test system which is run on all new
releases.
- Implemented unit testing frameworks at all levels (C++, LiveCode
Builder, LiveCode Script)
- Started requiring tests to be added to PRs (at least for things
which tests can currently be written for).
- Refined our internal process for handling and managing bugs and
issues.
- Refined our internal process for ensuring patches to the engine are
at the required standard.
- Considerably raised the expected standard of code which can be
accepted as a patch for both internal engineers and external
contributors.
- Instituted the requirements for code review on every single patch
which goes in (which is a requirement - via integration with our build
system - for a PR to be progressed).
- Implemented an automated build system which produces LiveCode
distributions for all platforms.
- Implemented integration of the build system with GitHub, enabling
easy communication of build failures.
- Implemented continuous integration of all Pull Requests, ensuring
that one will not be merged if it does not build on all platforms.
- Working towards running the unit test stack on each PR as part of
continuous integration.
One of the goals of the 7.0 refactor was to move a very old,
undocumented, difficult to maintain and spaghetti-like code forward to a
new model which is cleaner, easier to maintain and more amenable to use
in the ways we need it to be to move the platform forward (indeed, it
has been a 'happy' side-effect that in doing this process the actual
semantics of what things are meant to do has become a great deal clearer
- the code itself in many cases is now almost documentation in and of
itself - assuming you can 'read the runes' in that regard). Of course,
this process alone has been quite long and difficult - but well worth
the effort in terms of what it will enable moving forward.
However, please understand, that we would be entirely remiss if we spent
no time at all thinking about how the LiveCode technology needs to
evolve and change as we move into the future. A lot of what we have
planned has taken a long time to work out how to do, even before we've
actually started to do it. Indeed, future direction *hugely* impacts the
choices you make in the present.
The pace at which computers and software technology evolves is
breath-taking, so unless you want to be relegated to the warehouse of
great ideas which never quite got there (as so many 4GLs have), you find
yourself in an eternal juggling act between ensuring you definitely have
a future, and ensuring that you have a present...
Needless to say, this is not an easy task, but certainly one which
brings with it a wealth of interesting problems.
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
