LiveCode 8.2.0 DP-1 Dropping Keystrokes in IDE

[Brian Milby]

Do you experience the same issue when editing the IDE behavior stacks?  For
example revidelibrary (12k lines)?  I ask because I tried to duplicate the
issue on my system (Win10, HP EliteBook 840G1) and could not.  I don't have
any stacks that I know of with that many lines to check though (other than
the IDE).  It is a very fresh OS build since I just had to reimage my
system about a month ago.

Thanks,
Brian

On Wed, Sep 20, 2017 at 6:15 AM, RunRevPlanet via use-livecode <
use-livecode at lists.runrev.com> wrote:

> Hi Jacqueline,
>
> When I say a 7,000 line script, I should clarify that I am not referring
> to a
> single handler.
>
> Instead the 7,000 lines is comprised of the many handlers that are in a
> stack
> script. Each handler is likely to be less than 200 lines.
>
> There are a couple "monster" handlers that are almost 2,000 lines each.
> These
> are simply repetitive coding hacks that position controls in resizable
> windows,
> because the LiveCode Geometry manager is not really up to the task and I
> like
> the control of doing it in code.
>
> The other thing to know, is that I write LiveCode libraries to produce
> things
> like a smooth scrolling spreadsheet style grid component that suit my
> projects
> better than the DataGrid, I can't do that in less than 5,000 lines. For
> performance reasons all the handlers are in a single stack script.
>
> Getting back to part of my original gripe, in effect what I am hearing is
> that
> it seems to be that part of the LiveCode Philosophy can be paraphrased as:
>
> "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.
>
> If you are developing new features in a code editor how hard is to this.
>
> 1. Pick a random LiveCode handler that you have lying around of say 200
> lines.
> (Be sure to pick one that has no global dependencies.)
>
> 2. Use a macro in your favourite editor to copy it, say, 35 times.
>
> 3. Paste the resulting 35 handlers into a stack script, and save it as a
> test
> stack. There you go, you now have some code that is 7,000 lines long.
>
> 4. Before releasing any LiveCode update, sit down at a Mac and see if you
> can
> successfully enter new lines of code here and there. Maybe even trying
> doing
> some copy and pasting if you are adventurous. All the time seeing how fast
> or
> slow it is, or whether it works at all.
>
> 5. Spend 5 more minutes doing the same on a Windows box and then on a Linux
> machine. (Not virtual machines!)
>
> LiveCode Ltd spending a total of 15 minutes to do this, every now and then,
> should mean that I would be using the 8.2.0 DP-1 *right now* helping
> LiveCode
> test their new features.
>
> But instead, simple stuff like this is not done, and instead excuses and
> rationisations are offered.
>
> So instead someone like me who is actually quite good at finding problems
> in the
> IDE, can't use the current DP because it is broken on Windows when I try
> to edit
> my projects.
>
> If what I suggested (and that I naively assumed would already be routinely
> done)
> is truly too difficult and arduous to do, then I guess I will just have to
> wait
> for 8.2.0 DP-2 and do it myself.
>
> I can live with that because I love LiveCode so much, but I will still
> think it
> is not a good approach to testing and releases.
>
> Regards,
> --
> Scott McDonald
> http://thelivecodelab.com/
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>