LiveCode 8.2.0 DP-1 Dropping Keystrokes in IDE

RunRevPlanet feed at smpcsupport.com
Wed Sep 20 07:15:20 EDT 2017


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/




More information about the use-livecode mailing list