Problem with Script Editor in LC 9.6.2 (rc3)

HENRY LOWE hlowe at me.com
Thu Mar 25 19:41:14 EDT 2021 

Thanks you Lagi, Tore and others.

Looks like this is specific to Mac OS Big Sur.

I have submitted a bug report:

https://quality.livecode.com/show_bug.cgi?id=23139 <https://quality.livecode.com/show_bug.cgi?id=23139>

Henry

> On Mar 25, 2021, at 4:11 PM, Lagi Pittas via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> HI Henry,
> 
> Tried it on windows LC 9.6.2 RC2 and it works fine.
> 
> I still have the problem of very laggy text editor  for a machine with 16G
> of Ram and SSD,
> 
>  there is no scrolling problem on a greater than 5000 line script
> 
> so it looks like it's  big Turd this time ;-)
> 
> Lagi
> 
> On Thu, 25 Mar 2021 at 21:09, HENRY LOWE via use-livecode <
> use-livecode at lists.runrev.com> wrote:
> 
>> 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
>> 
> 
> 
> -- 
> KIndest Regards Lagi
> _______________________________________________
> 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

More information about the use-livecode mailing list