On 2017-09-20 13:15, RunRevPlanet via use-livecode wrote:
"Well, if there a simple procedure that we at LiveCode can do that will
catch
really obvious bugs before sending out a DP, it is not worth doing
because it
won't catch all the bugs and have 100% percentage coverage."
I fail to see the logic in not doing simple tests, simply because it
won't
detect all the problems.
We do do this.
Panos diligently tests every build on each we release on each platform
before we release it (DP, RC, GM). Indeed, he checks every bug marked as
AWAITING_TEST to make sure it has been fixed in the actual build as well
as a number of other things which are hard to test completely in an
automated fashion (e.g. standalone building).
As autocomplete was added in 8.2-dp-1 - the SE was also checked
thoroughly.
Now, an important point here is that Panos could not reproduce your
problem on revidelibrary (which is a very long script) in dp-1 - which
he was trying to do to verify that the fix I made to the problem had
actually fixed it. Furthermore, in the lead up to release of dp-1 we
noticed a couple of issues on Windows with AutoComplete which we had to
fix, and no-one noticed the issue then either. This does suggest that
the problem you observed probably would not have been picked up by the
pre-release testing you suggest would have found it.
This is why we do DPs.
Of course I did manage to reproduce and fix the problem but only because
I tried things out in a Debug build of the Windows engine (which is
horrendously slow since moving to VS2017 for an annoying technical
reason which we haven't had a chance to sort out yet). I must confess
that I hadn't actually noticed that it was dropping keystrokes before -
mainly because I had long gotten into the habit of copy/pasting text
into the message box / script editor when running in that fashion.
However, when I tried it out I *did* notice what you observed and a fix
quickly followed (the underlying problem has actually been there since
the early days of 7 - and is caused when script runs for long enough to
cause events to be queued as part of checking for Ctrl-. - the abort
script key stroke).
Now, one retort might be to 'test on less performant windows machines' -
which would be reasonable were it not for the fact that the machine
Panos tests things out on has the spec:
Windows 10 Home (version 1703) 64-bit
Processor: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz 2.40
Installed RAM: 8GB
Standard mobile graphics chipset.
Normal hard-drive (not SSD)
When compared to your spec:
Windows 10 Home 64-bit
Intel Core i5 6600K @ 3.5GHz
16Gb RAM
4Gb GeForce GTX 960
SSD + Normal Hard-drive
You can see that yours is substantially better.
This therefore leads me to ask the following:
1) Do you have anything in your LiveCode IDE (plugins etc.) which
might be:
a) interfering with keyboard message processing?
b) causing script to run at frequent intervals unrelated to user
interaction?
2) Do any of your LiveCode projects send continual pending messages
whilst loaded in the IDE?
3) Or anything on your machine which causes a general system
performance degredation? (i.e. using a fixed percent of the CPU / disk
most of the time).
4) Absolutely anything else you can think of which might cause things
in general on your system to run slower.
The reason I ask is that no-one else has reported a similar problem on
Windows in the entire time the underlying issue has been around (that I
can recall) - and I strongly suspect the issue you noticed with keyboard
shortcuts is caused by the same underlying issue (again something which
has not been reported by anyone else that I can recall - and predates
AC). This coupled with the fact we weren't able to reproduce the issue
in dp-1 here on any of the Windows machines we use (which are quite
varied) does suggest that there is an extra factor at play which meant
the underlying issue was much more likely to cause problems on your
system.
One way to test out this hypothesis is to run inside a fresh user
account on your windows machine, making sure that no 'on startup load'
items launch. Then run a freshly installed copy of LiveCode 8.1-dp-1,
and try to edit revidelibrary (don't load any of your own projects) and
see if you still see the problem.
Whilst I'm pretty sure the fix will work regardless of environment, you
might find that *something* is affecting the performance of the IDE on
your system, in which case finding out what it is and rectifying it will
probably lead to a generally better experience of the IDE for you.
Warmest Regards,
Mark.
P.S. Please don't read the above as 'turning the issue around on the
user' because it isn't. There is clearly another factor at play here but
we don't know what it is. The only thing in the IDE/engine which (in the
normal course of things) could cause the problem to manifest itself is
the engine's Ctrl-. abort key shortcut processing which it does every
500ms whilst script is running. In the debug engine on Windows, a
keystroke into the message box / script editor takes in excess of that
time to process in script (did I mention I had got into the habit of
using Copy/Paste when doing work in that mode? ;)) hence why it was
reproducible there. Even in Monte's performance testing of AC, I don't
think he observed it taking longer than 100ms per keystroke - if that -
and he did, and continues to, work on getting it as efficient and fast
as possible.
--
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
