Problem with Script Editor in LC 9.6.2 (rc3)

Thu Mar 25 19:11:15 EDT 2021

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