IDE oddities (was Re: Error Messages Are Evil)
ambassador at fourthworld.com
Thu May 15 16:29:49 EDT 2014
> OK, so what do we have to do, as a community of users, to get
> RevOnline working again?
Fix it. :)
My Community meeting this morning with Ben focused almost exclusively on
It's true that LiveCode is inherently problematic to attempt to
integrate into tools like GitHub, not merely because it's a binary file
format and GitHub is designed for plain text, but more because of the
nature of the workflow in which UI and code are intermingled. Monte's
spent considerable time explaining the Why of that, and if needed I
could try again, but for now the bottom line on GitHub integration is
that it may require engine enhancements to support, and given current
priorities not likely to happen for at least a few more months at best.
So in the absence of a GitHub workflow, clearly we need at least some
alternative to move forward with community contributions on IDE components.
We explored a few options, but one stood out as a *possible* solution
for modest fixes in the short term. I'm stressing "possible" here
because he needs to review the workflow with the team to make sure it's
going to work, but here's the outline:
If a member of the community has time and interest to fix a bug in the
IDE, the revised handler(s) can be added to the bug report, and the
title of the report prepended with "FIX:" to flag it for the team as a
report that also includes the fix. And of course the post with the
fixed handler(s) should note the object and line numbers where the
original handler(s) can be found.
For any issue whose recipe requires more than running a single line of
code in the Message Box, a unit test stack should be provided
illustrating the issue so that it can be run before the fix is applied,
then again after copying-and-pasting the fix to verify that it works.
Well-crafted unit tests may even be included in RunRev's internal
collection for future regression tests, providing long-term benefit in
addition to helping to ensure quick action on a bug.
As an example of this workflow in action, we have a simple fix here:
Since the code change is comprised of adding only five characters to a
comparison string and can be easily seen in the Message Box, no unit
test is required for that one.
There may be reasons why they're not able to guarantee super-quick
responses on reports using this protocol, but even before he runs it by
the team I see no harm and potentially much good in encouraging
interested folks to dive into fixing any issues you find particularly
annoying, and including the fixed code in the report.
True, this protocol can only address issues of limited scope, and at the
moment is still being reviewed for feasibility.
But the benefit of having fixed code posted to the report is undeniably
valuable in guiding the team to the solution - all we need now is people
in a position to supply the fixes.
That last step has been the hardest.
For example, after all the discussion of documentation issues over the
years, once I got forum permissions to modify things there for community
initiatives I took the time to set up a new forum section for that:
Thus far there's been some good ideas discussed, but no one in a
position to actually act on any of them.
Many of us juggle multiple priorities, much like RunRev themselves, so I
can understand that it's far easier to imagine fixed code than it is to
write it. :)
It may be that we won't really see serious traction on community
participation for quite some months yet, until the community grows large
enough to include a greater number of people in a position to contribute.
We'll see. But in the meantime the core dev team at RunRev is actively
exploring many ways to incorporate community contributions for IDE
components, and if we start seeing fixes submitted to the bug reports
we'll be able to refine and enhance the workflow to make sure it's
working well for all of us.
LiveCode Community Manager
richard at livecode.org
More information about the Use-livecode