Should I be using Strict Compilation mode ?

[dunbarx]

Richard.

but at least you'll be able to stop debug mode without waiting for 30 seconds.

Are you serious about that time delay? I see only instantaneous transitions from one mode to another. Can you give a recipe?

Mac 10.13, LC 9.6. But similarly in all earlier versions of both.

Craig

[FourthWorld]

Richard.

but at least you'll be able to stop debug mode without waiting for 30 seconds.

Are you serious about that time delay? I see only instantaneous transitions from one mode to another. Can you give a recipe?

Unfortunately it's intermittent, so no recipe as yet.

It happens when I encounter a bug while debug mode is active, and it brings up the editor to the errant line. So far so good. But when I click the square icon to cancel debugging so I can fix the error, it sometimes hangs for up to 30 seconds or so, occasionally longer.

Obviously that's no one's design choice, but if you've looked at the editor code in depth it becomes clear how such unusually long calling chains might occasionally make recursive calls unintentionally.

A good example of the non-xTalk-style complexity is the line number field, which may or may not be related to the debugging delay but has been widely observed:

Old schoolers would likely implement line numbers prepopulated, so the only thing that needs to be done is a scrollbarDrag message in the editor field keeping the scroll of the line numbers in sync. It's a one-line handler that way, and in a scripting language moving work to the engine helps.

I haven't invested the time to discover whether the SE's line numbers are dynamically populated (the sort of thing a C programmer would expect to do), but whether for that or some other reason the line numbers sometimes fall out of sync. I can't yet say why, but when I don my safari hat and go exploring in that jungle I find there's enough complexity in what's happening during scrolling that it's a bit of an effort just to wrap my head around it

All I know is many have observed what I have, that the line numbers frequently fall out of sync with the main editing field, and remain unpredictably off until you click the insertion point into a new location.

That this often happens during debugging is especially tedious, since we need to review the line number specified in the error info, and we can't know what that is when the line numbers are off.

To be fair, I believe the team has been made aware of this, and has been working on it. And I'm not certain I've seen it with the very latest build, though I have in recent weeks before it.

And I know there's not a lot of truly wasted code in there, it's just biting off a lot on actions that are important to perceptions of performance, like selectionChanged. But there is some code in there which is just inexplicable, such as the two different execution paths for saving (trace out menupick and then trace out Ctrl-S).

The SE currently in the IDE was a complete rewrite replacing the one from v1.0. From time to time a rewrite is the right choice (McConnell touches on that in his book Rapid Development). When the then-new SE premiered it was the reason I stopped maintaining my own, and the other parts of the MC IDE, and started using LC's IDE.

But over time, features and fixes have grown the SE code into something at the edge of unmanageable. Indeed, observe how many team members cite using external editors.

It's time for another rewrite. But with so many priorities and the team using external editors, it's a community task, not all that out of place for a tool where most users run the Community Edition.

Mark Weider's GLX2 is one response to this need. And it's very feature-rich, impressively so.

And thanks to a generous benefactor sharing the investment with me, another SE is in the works to provide a different focus, one that emphasizes lean operation and maintainability

Like Dr Raney used to say about tools, "Let a thousand flowers bloom."

With multiple script editors, debuggers, object browsers, inspectors, and other dev tools to choose from, each of us can tailor the IDE experience to become the exact toolkit we most want.

[jacque]

I've never seen a delay either, canceling debugging is instant. The issue may be related to the Windows problem where typing slowed to a crawl in the SE. The team did some work on this for the recent release. I do have almost all the options turned off though (auto-complete, etc.)

[bogs]

Sounds intriguing, as a plugin, how far backwards would it be compatible?

You know, I always wondered something that is kind of related to debugging as well as strict mode, and that is this. Lots of languages I've used previously had a way to strip the debugging code and symbols from the final exe file, even after it was assembled into an executable/standalone. I was looking for the last year, off and on, but haven't found any such in this language. You've been in xtalks a long time, you know of any such?

If the question isn't clear, feel free to say it isn't, I'll try to come up with an example of what I'm referring too.

Two posts and no answer, does that mean no one knows, or that this wasn't clear enough, or ...

[dunbarx]

All I know is many have observed what I have, that the line numbers frequently fall out of sync with the main editing field, and remain unpredictably off until you click the insertion point into a new location.

This must be related to the not-so-old vaporous red dot issue, which seems to have been fixed in v.9. and was the main reason I migrated.. "Clicking in a new location" may be related to closing and re-clicking at the original line where a red dot once lived; which restored it to active status.

But you say v.9 has not fixed your SE waiting issue. Are you the only one who suffers from this? I thought I was the only guy around here who had multiple issues peculiar to me alone.

Craig

[FourthWorld]

All I know is many have observed what I have, that the line numbers frequently fall out of sync with the main editing field, and remain unpredictably off until you click the insertion point into a new location.

This must be related to the not-so-old vaporous red dot issue, which seems to have been fixed in v.9. and was the main reason I migrated..

Could be, but since that one was fixed any relationship would seem peripheral.

But you say v.9 has not fixed your SE waiting issue.

I've seen the debugging-cancel delay as recently as yesterday, using v9.6. I've seen the line number issue for sure as recently as v9.6 RC 2, but can't say with certainty I've seen it with v9.6 final.

Are you the only one who suffers from this?

If "this" is the debugging-cancel delay, I believe I recall at least one other reference to it from another user many weeks ago. If "this" is the line number issue, it's been seen by many, and IIRC reported and confirmed (and possibly even fixed, haven't looked it up).

[FourthWorld]

Sounds intriguing, as a plugin, how far backwards would it be compatible?

You know, I always wondered something that is kind of related to debugging as well as strict mode, and that is this. Lots of languages I've used previously had a way to strip the debugging code and symbols from the final exe file, even after it was assembled into an executable/standalone. I was looking for the last year, off and on, but haven't found any such in this language. You've been in xtalks a long time, you know of any such?

If the question isn't clear, feel free to say it isn't, I'll try to come up with an example of what I'm referring too.

Two posts and no answer, does that mean no one knows, or that this wasn't clear enough, or ...

Yeah, lots of things to reply to in the world. I don't always get to all of them quickly.

RE backwards compatibility: file format will be v8.1. I just don't have time to ensure anything earlier. So far I'm not using any language features specific to recent versions, but I won't be spending time on it. If it works in versions prior to the latest Stable (currently 9.6) super, if not I can't spend time on things like that. Gotta keep a focus on moving my life forward in ways that are meaningful to me, code included.

RE debug code: The question isn't clear to me; aside from breakpoints I'm not familiar with what other "debugging code and symbols" could be candidates for removal in LC.

[jacque]

@bogs LC strips out all the excess symbols, comments, etc. when you build a standalone but it isn't something you can do yourself on demand.

[bogs]

@ Richard - Thanks for the heads up, I didn't mean I was expecting you to provide backwards compatibility to say, Mc in the se plugin, I was just wondering how far back it would be considered compatible, i.e. if your not using widgets, lets say, or super new things, it might well be backwards compatible a long ways, however, if your using behaviors, ssos's, etc, I wouldn't expect it to be so much the case.

RE debug code: The question isn't clear to me; aside from breakpoints I'm not familiar with what other "debugging code and symbols" could be candidates for removal in LC.

I don't know if you have ever programmed in say, pascal or delphi, but that is the best example I can think of at the moment. I think some C language versions do this also.

There are compiler directives in these languages that add in or remove certain things, such as debugging symbols and error codes, comments, etc. Usually during the development period for program x, you would want all these things to be active to help you develop the program. Obviously, your end users don't require access to any of these things, although specific parts of them might be left in during testing or for bug reporting/trouble shooting.

Using Delphi as an example, you could either during compilation (by setting compiler directives), or after the exe is already compiled (by running the strip command), remove these from the final executable, often greatly reducing the size of the resulting executable standalone.

As an example, I recently wrote a program that came in at 20.8 MB (simple utility) consisting of a form, button, field, list of answers. After running strip on it, the size was reduced to 5.8 MB. Hopefully this somewhat clarifies the question for you.

@ Jacque - Thank you, that is the answer I was assuming

[FourthWorld]

I don't know if you have ever programmed in say, pascal or delphi, but that is the best example I can think of at the moment. I think some C language versions do this also.

There are compiler directives in these languages...

LC has no compiler directives, because as a runtime-compiled language it has no build-time compilation.

[mtalluto]

My short and apparently unpopular response is yes to strict compilation mode being turned on full time. We have made it a standard setting team wide and have enjoyed less bugs.

[Simon Knight]

Hi Mark,

Its good to read a counter point of view . I wonder if you have any idea what aspect of strict compilation is reducing your bugs. For example do members of your team explain the use of each variable as it is declared thereby saving other members time when they work on the same handler?

[mtalluto]

Hi Skids,

I am happy to elaborate on the value of strict compilation as I see it.

Writing code is complicated enough without my fingers wandering around and missing the key I meant to touch. Strict Compilation (SC), is analogous to a spell checker. When I mistype a variable in a given handler, SC will notify me that it is not quite right. It also reminds me to define the variable if I got ahead of myself.

Catching that particular bug will save me from a long session of understanding why the real variable does not have the expected value after the completion of a handler.

Variable auto-complete can help, but, at times, it is a bit slow in the LC script editor.

I do not scroll to the top of the handler to declare the variable. Doing so would be disruptive. Instead, I declare the variables inline as I need them. Our code has random declarations here and there. Years ago, we developed a linter that will find those and move them to the top of the handler. Our team runs the linter we call 'Code Cleaner' before submitting their work to GitHub.

Once you get the process down, the extra time declaring the variable is compensated by not having dangling variables. If you have touch typing skills of any kind, declaring a variable does not take much time.

If you want to change a variable name, delete the declaration at the top of the handler. The script editor will guide you in finding all the variables one needs to find and replace.

An aside to the above value from declaring variables is a quick view of a handler's scope. You can quickly scan the variables used and get an idea of scope and complexity. You can copy one of the variables to the clipboard and search to jump to that part of the handler. For this to be most effective, using meaningful names is essential.

We developed a coding style guide for new hires that gets everyone on the same page. Strict compilation and other useful guidance help us complete our work more quickly and with fewer bugs.