LiveCode 8.2.0 DP-1 Dropping Keystrokes in IDE
brian at milby7.com
Wed Sep 20 08:37:17 EDT 2017
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.
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
> script. Each handler is likely to be less than 200 lines.
> There are a couple "monster" handlers that are almost 2,000 lines each.
> are simply repetitive coding hacks that position controls in resizable
> because the LiveCode Geometry manager is not really up to the task and I
> the control of doing it in code.
> The other thing to know, is that I write LiveCode libraries to produce
> like a smooth scrolling spreadsheet style grid component that suit my
> 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
> 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
> really obvious bugs before sending out a DP, it is not worth doing because
> 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
> (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
> 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
> successfully enter new lines of code here and there. Maybe even trying
> some copy and pasting if you are adventurous. All the time seeing how fast
> 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
> 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
> is truly too difficult and arduous to do, then I guess I will just have to
> 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.
> Scott McDonald
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the Use-livecode