Problem with Script Editor in LC 9.6.2 (rc3)

Thu Mar 25 18:32:37 EDT 2021

I have followed your recipe and I can confirm that this is a problem also with ordinary scrolling fields in LC 9.6.2 (rc3). It does not seem to be a problem in LC 9.6.2 (rc1).

Best regards
Tore Nilsen

> 25. mar. 2021 kl. 22:07 skrev HENRY LOWE via use-livecode <use-livecode at lists.runrev.com>:
> 
> On further investigation this appears to be a problem with any LC scrolling text field, not just the Script Editor.
> 
> Please try the following and let me know what you observe:
> 
> 1. Create a new stack (e.g. 1024 x 768)
> 
> 2. Add a scrolling text field and resize the field to fill the card.
> 
> 3. Paste enough text (multiple pastes of the same text will do) into the field so that the vertical scroll bar is activated.
> 
> 4. Place in run mode. Click before the first text character in the field
> 
> 5. Drag-Select text downwards (hold mouse button down while dragging down over text) towards the bottom of the field until the field begins to auto-scroll
> 
> 6. Let go of the mouse - the field continues to autoscroll until it reaches the end of the text
> 
> 7. LC is unresponsive during this automatic scrolling
> 
> 8. On the Mac the Activity Monitor app shows LC consuming 100% of CPU
> 
> 9. This continues for 1-2 minutes then LC unfreezes.
> 
> In a large script I am “locked out” of LC for 10-15 mins as the field autoscrolls down.
> 
> This may be Mac Big Sur specific, so hopefully someone can test it on that platform.
> 
> Looks like a bug to me.
> 
> Henry
> 
>> On Mar 25, 2021, at 11:05 AM, Sean Cole (Pi) via use-livecode <use-livecode at lists.runrev.com> wrote:
>> 
>> RichardG,
>> That was a very long way of not answering the question. Very insightful
>> regarding the DG though. :)
>> It also went a long way of assuming the skill levels of the audience. Some
>> of us are not limited to xTalk level. I understand C++ and why Trevor
>> likely coded the DG using such.
>> 
>> My question, just to reestablish, was what on Earth could possibly
>> complicate the scrolling of the line-numbers in sync with the main 'field'?
>> Very occasionally the numbers freeze altogether until a click in the editor
>> which is an interesting aside and only partly related to the question. I
>> never notice a lag between the two areas. 32-bit I feel is neither here nor
>> there in relation to the syncing or imperceivable lag, especially for the
>> SE.
>> 
>> Looking on github reveals that the majority of the code for the SE are
>> indeed, as suspected, written in livecodescript (xTalk ;)) by BHall mostly,
>> rather than CPP. And, as suspected, really quite simple and unconvoluted as
>> they can get. Barely anything to become difficult in fixing for Henry's
>> listed issue. revsecommoneditorbehavior.livecodescript holds the key, lines
>> 2658-2721 most likely.
>> 
>> Sean
>> 
>> 
>> On Thu, 25 Mar 2021 at 16:47, Richard Gaskin via use-livecode <
>> use-livecode at lists.runrev.com> wrote:
>> 
>>> Sean Cole wrote:
>>> 
>>>> On Wed, 24 Mar 2021 at 21:45, Richard Gaskin wrote:
>>>> 
>>>>> I believe it may be related to the complicated way the line
>>>>> number field is kept in sync.
>>>> 
>>>> Quick question. Why would the line number field be complicated? I
>>>> can’t imagine anything that would necessitate making it complicated.
>>>> Numbers and break points. That’s all it handles, right?
>>> 
>>> 
>>> It's easy to describe anything in terms that make it sound simple, but
>>> whether a task is *actually* simple depends on many things.
>>> 
>>> It's equally an oversimplification to arbitrarily divide the world into
>>> two types of programmers, xTalkers and C coders, but that won't stop me
>>> from indulging in it here <g>:
>>> 
>>> 
>>> If we look at text editors made by C coders, they generally only render
>>> the line numbers visible on screen given the current scroll position.
>>> But they do everything with lower-level/computer-oriented thinking, with
>>> lineto and moveto and stringAt (yes, the Inside Macintosh references
>>> there show my age, but you know what I mean), so for them these types of
>>> calculations are second-nature and not considered tedious at all, it's
>>> just how things are done.
>>> 
>>> xTalkers, by virtue of choosing a language that is not only high-level
>>> but among the very few that directly incorporate GUI controls as
>>> inherent language elements, think differently. To us we put text into a
>>> field and set the scroll as we like and let the engine figure out the
>>> details.
>>> 
>>> 
>>> Which is "best" is a topic that can be hotly debated, and was here on
>>> this list several years ago in a thread on making text editors in LC.
>>> 
>>> One of the participants in that thread was Jeff Massung, who'd made a
>>> very nice Erlang editor in LC. In his view, IIRC, it was wasteful to ask
>>> the engine to render thousands of lines of line numbers if the script
>>> being displayed was much shorter.  He felt that the "right" approach
>>> would be to do as C programmers do, to dynamically calculate which line
>>> numbers should be visible and dynamically populate the line number list
>>> with only those on each scrollBarDrag.
>>> 
>>> Others, including myself, felt that using xTalk objects as xTalkers are
>>> accustomed to using them was not a mistake at all, but actually quite
>>> with-the-grain for xTalk work. Even if we're asking the engine to work
>>> harder, we're doing it only once up front, relying on the engine's good
>>> buffering to make scrolling throughout the rest of the session simpler.
>>> 
>>> 
>>> It's worth noting that the excellent DataGrid relies on
>>> dynamically-calculated scrolling, but even more worthy to note WHY:
>>> 
>>> It's not because scrolling the DG is made any faster (observably it isn't).
>>> 
>>> It's because the performance impact of dynamically-calculated scrolling
>>> is a NECESSARY tradeoff to cover the sometimes-large number of records
>>> it's asked to display.  LC uses 32-bit coordinate addressing, which is
>>> more than adequate for most things we render since it gives us about 30
>>> feet of drawing space, far bigger than any monitor. But if you try to
>>> place tens of thousands of groups nested within a scrolling group,
>>> you'll quickly discover what happens when you exceed 32-bit coordinate
>>> space. :)
>>> 
>>> So Trevor did the tedious work of providing a profoundly flexible
>>> DataGrid, where for the relatively low cost of a modest performance hit
>>> during scrolls we can effortlessly display even vast numbers of records,
>>> by only actually rendering those on screen at any given time.
>>> 
>>> But the 32-bit coordinate space only applies to controls, not the
>>> contents within text fields, so....
>>> 
>>> 
>>> Back to the LC Script Editor, truth be told it's been so long since I
>>> donned my pith helmet to dive into its code jungle that I'm not in a
>>> position to speak authoritatively on how it's constructed.
>>> 
>>> But we can observe (sadly, without much effort) a lag between scrolling
>>> the script field and the subsequent update of the line number list.  In
>>> some cases, depending on platform and script length, this lag is more
>>> easily seen than on others.
>>> 
>>> This suggests that there's a lot more going on with the SE's line number
>>> update than just setting its scroll to match the editor field's.
>>> 
>>> Indeed, given the variance of the lag it would seem it's not updated
>>> directly at all, but perhaps via "send".
>>> 
>>> 
>>> It wouldn't be appropriate to say the LC implementation is necessarily
>>> "wrong" or even "bad".  It's a deeply complicated layout with a lot of
>>> updates to manage, and given the vast scope of its design ambitions it's
>>> hard to say what one "should" do there.
>>> 
>>> But it is safe to observe that it was written by people who cut their
>>> teeth on languages more lower-level than xTalk. Aside from Monte and
>>> Kevin, I don't know of anyone there who shipped a product using an xTalk
>>> before being hired to make an xTalk.
>>> 
>>> Obviously, that's exactly what we want in an engine team, C++ engineers
>>> who live and breathe deep computer science.
>>> 
>>> But from time to time it does lend itself toward designs and
>>> implementations that look like the work of native C coders rather than
>>> native xTalkers. These strengths give us a beautiful engine, and an IDE
>>> that could probably benefit from some trimming.
>>> 
>>> 
>>> xTalk is a funny thing, and it's not easy coming up with a concise rule
>>> set for what constitutes good with-the-grain savvy of The xTalk Way.
>>> 
>>> But we know it when we see it. And line numbers that lag behind editor
>>> field scrolls may be an example where The Zen of The xTalk Way might
>>> produce a smoother solution.
>>> 
>>> --
>>> Richard Gaskin
>>> Fourth World Systems
>>> 
>>> _______________________________________________
>>> 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
>>> 
>> _______________________________________________
>> 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
> 
> 
> _______________________________________________
> 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