Curry Kenworthy wrote:
> http://curryk.com/NeverGonna.mp4
Thank you for the link to test results relating to specific issues.
What bug reports can I find those test stacks attached to?
I'd like to follow their progress, and perhaps re-run them to see where
there may have been changes after the seven builds delivered since v9.0
was released. Happy to help steward issues along as best I can;
supporting the QA process benefits my work as well.
> Oh boy - I was ALWAYS gullible enough to fall for the "concrete
> concerns" type of line every single time, and rush off to make a newer
> list..
Not really needed. When you use the RQCC you'll see that searches are
expressed in the URL, so when communicating about several issues at once
you needn't really need to spend any time writing each of them down, you
can copy the search URL you've already bookmarked to monitor issues
you're following.
> And testing indicated that it's almost certainly NOT just a Unicode
> thing.
Kudos. I've have neither the time nor the C++ experience to examine the
code well enough to rule out all possible impact from type coercions
which may involve encoding operations.
What I have seen in many RQCC discussions is that fixing legacy bugs
sometimes adds additional overhead.
Admittedly going out on a limb here, but I'm reasonably confident the
team is neither willfully introducing new code to slow things down for
no reason, or doing slopping haphazard work with no regard for quality.
With that assumption, when I see performance degradation I'm inclined to
recognize that what I have is not a lengthy declaration opining about
what constitutes professional code, or any declaration at all. What I
have is inherently a question: Why is this specific operation slower?
When I pose questions as questions I usually get answers in reply, and
often quite helpful ones, e.g.:
> Mark Waddingham:
>
> > It hasn't as yet - that PR
> > (https://github.com/livecode/livecode/pull/6671) has actually
> > turned into a mini-grab bag of things [...]
>
> > - reduction of memory usage of the 'handle' structures used to
> > hold values (particularly on 64-bit)
> > - faster processing of integer index access in arrays
> > - faster short-path array access (both storing and fetching) [...]
>
> Yes!!! Just what I was hoping to hear, that this is still in the
> works. Thank you, sir. It should help a great deal.
My interest is in getting results. I wish I had time for anything as
colorful as "circling wagons", but alas like most people here I simply
have software to deliver and need to stay focused where I can on
specific actionable outcomes.
To that end, my method here is as straightforward as with anyone I work
with:
1. Learn from the people doing the work I'm relying on
how best to support their efforts.
2. Then I do that.
FWIW, using this method I see a lot of issues I report get resolved.
Some very quickly. And the ones not yet resolved are usually
accompanied by an explanation of what's involved so I can understand the
priorities at play.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
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
