Slow Script Editor
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Posts: 17
- Joined: Mon Mar 21, 2022 8:13 pm
Slow Script Editor
I've worked with several different IDE's over the years, but I'm new to LiveCode. I'm running 9.6.6 on Windows 10.
I have a very small project (single stack, 3 cards, almost no code as yet) and I've noticed that the script editor can be very slow at times. I'll type as many as 10 to 20 characters before they appear in the script, and then they all appear at once. I've read other posts whose authors describe the same issue, and have followed the steps recommended to alleviate them, such as closing the Project Browser, and disabling Script Debug Mode, which have helped a bit, but the performance of the script editor is still very slow. Oh yeah, this occurs even while not in 'run mode'.
Is there anything else I could disable that might alleviate this?
Thanks!
I have a very small project (single stack, 3 cards, almost no code as yet) and I've noticed that the script editor can be very slow at times. I'll type as many as 10 to 20 characters before they appear in the script, and then they all appear at once. I've read other posts whose authors describe the same issue, and have followed the steps recommended to alleviate them, such as closing the Project Browser, and disabling Script Debug Mode, which have helped a bit, but the performance of the script editor is still very slow. Oh yeah, this occurs even while not in 'run mode'.
Is there anything else I could disable that might alleviate this?
Thanks!
~Bob (one of the many)
Re: Slow Script Editor
Personally i prefer to use state-of-the-art code editors rather than the built-in editor.
As much as it is OK for many things it is just not as good as a dedicated code editor such as VSCode or Atom, both of which have plugins that provide code formatting, syntax colouring, linting etc, on top of the standard features like code-folding, dark mode and so on.
To be able to use this moderately effectively, i've converted all my scripts where possible to scriptOnlyStacks. It's fairly straightforward to use these as stack scripts, card scripts or even object scripts (by setting the scriptOnlyStacks to be behaviour stacks) and can be loaded as backscripts where needed. This then makes using GitHub more meaningful and if a project is on GitHub it can be directly opened in it's entirety in VSCode (or Atom) and can be sync'ed between machines via git. Another benefit is that by using scriptOnlyStacks i can then break down massive scrips in to smaller entities and organise these in an MVC type pattern - easier to organise and easier to reuse in other projects.
The way i set my current project up is that i have a scriptOnlyStack who's only job is to dynamically serve up file paths for the scripts depending on whether in IDE or standalone, so i can just pass the functions as filepaths for the scripts and load them at start up, or where needed.
I'm relatively happy with this setup; it's of course not quite the same as using a properly integrated setup (for example when debugging i end up using the built in editor in parallel with VSCode) and the ideal would be that the IDE would provide a code editor on par with VSCode, or at the very least allow full integration with 3rd party editors... but for now this will do...
As much as it is OK for many things it is just not as good as a dedicated code editor such as VSCode or Atom, both of which have plugins that provide code formatting, syntax colouring, linting etc, on top of the standard features like code-folding, dark mode and so on.
To be able to use this moderately effectively, i've converted all my scripts where possible to scriptOnlyStacks. It's fairly straightforward to use these as stack scripts, card scripts or even object scripts (by setting the scriptOnlyStacks to be behaviour stacks) and can be loaded as backscripts where needed. This then makes using GitHub more meaningful and if a project is on GitHub it can be directly opened in it's entirety in VSCode (or Atom) and can be sync'ed between machines via git. Another benefit is that by using scriptOnlyStacks i can then break down massive scrips in to smaller entities and organise these in an MVC type pattern - easier to organise and easier to reuse in other projects.
The way i set my current project up is that i have a scriptOnlyStack who's only job is to dynamically serve up file paths for the scripts depending on whether in IDE or standalone, so i can just pass the functions as filepaths for the scripts and load them at start up, or where needed.
I'm relatively happy with this setup; it's of course not quite the same as using a properly integrated setup (for example when debugging i end up using the built in editor in parallel with VSCode) and the ideal would be that the IDE would provide a code editor on par with VSCode, or at the very least allow full integration with 3rd party editors... but for now this will do...
Re: Slow Script Editor
PS: if you are considering replacing scripts with scriptOnlyStacks as i've done, you may find Richard Gaskin's expertly detailed post on the messagePath useful.
It's definitely worth a read: https://fourthworld.com/embassy/article ... _path.html
in summary:
The yellow boxes are easy to replace with scriptOnlyStacks - but the missing bit is that both groups, cards, substacks and mainstack can also have behaviours (which can be scriptOnlyStacks as well), so that 90% of your code can be in text files that work perfectly with code editors like VSCode.
It's definitely worth a read: https://fourthworld.com/embassy/article ... _path.html
in summary:
The yellow boxes are easy to replace with scriptOnlyStacks - but the missing bit is that both groups, cards, substacks and mainstack can also have behaviours (which can be scriptOnlyStacks as well), so that 90% of your code can be in text files that work perfectly with code editors like VSCode.
-
- VIP Livecode Opensource Backer
- Posts: 4036
- Joined: Sun Jan 07, 2007 9:12 pm
- Location: Bochum, Germany
Re: Slow Script Editor
Hi Bob,
There are some reports about the Script Editor being slow on Windows (I am on a Mac and have not experienced this)
https://www.mail-archive.com/use-liveco ... 09768.html
From that discussion:
in case you use Microsoft Defender as antivirus you might try to exclude the Livecode program folder and its
support folders (like preferences) from realtime scanning in MS Defender.
Kind regards
Bernd
There are some reports about the Script Editor being slow on Windows (I am on a Mac and have not experienced this)
https://www.mail-archive.com/use-liveco ... 09768.html
From that discussion:
in case you use Microsoft Defender as antivirus you might try to exclude the Livecode program folder and its
support folders (like preferences) from realtime scanning in MS Defender.
Kind regards
Bernd
Re: Slow Script Editor
I'm on a mac too and haven't experienced severe lag when typing either - but i do find it a bit slow with larger scripts, in a way that 'proper' code editors just aren't... i wonder if the 'compiled' version of LC stacks which i read somewhere is a planned feature will improve that?
-
- VIP Livecode Opensource Backer
- Posts: 4036
- Joined: Sun Jan 07, 2007 9:12 pm
- Location: Bochum, Germany
Re: Slow Script Editor
I see the slowdown with larger scripts also. And I also wonder what 'compiled' will mean.stam wrote: ↑Sat Apr 09, 2022 3:01 pmI'm on a mac too and haven't experienced severe lag when typing either - but i do find it a bit slow with larger scripts, in a way that 'proper' code editors just aren't... i wonder if the 'compiled' version of LC stacks which i read somewhere is a planned feature will improve that?
As an explanation/excuse for the script editor I consider it quite a feast to use a simple Livecode field and pile a _LOT_ of code on top of it to edit scripts.
Kind regards
Bernd
-
- Livecode Opensource Backer
- Posts: 9476
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Slow Script Editor
Well . . . I'm doing most of my work on MacOS 12.4, and using LC 9.6.3 Community,
and recently (i.e. since I upgraded from MacOS 11 to MacOS 12) working in scripts that contain about 6000
lines in my Devawriter Pro I have noticed a significant lag with post-and-replace actions . . .
. . . but as that gives me time to take a gulp of coffee, I'm not getting worked up about it.
and recently (i.e. since I upgraded from MacOS 11 to MacOS 12) working in scripts that contain about 6000
lines in my Devawriter Pro I have noticed a significant lag with post-and-replace actions . . .
. . . but as that gives me time to take a gulp of coffee, I'm not getting worked up about it.
-
- VIP Livecode Opensource Backer
- Posts: 7266
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Slow Script Editor
Start by turning off all the options in the Edit menu you don't use. They cause slowdowns.
https://forums.livecode.com/viewtopic.p ... te#p182698
I have all of them off except for auto-bracketing.
https://forums.livecode.com/viewtopic.p ... te#p182698
I have all of them off except for auto-bracketing.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- Posts: 17
- Joined: Mon Mar 21, 2022 8:13 pm
Re: Slow Script Editor
General reply to all who have responded thus far...
First, thank you for sharing your insights.
I have wondered whether the Mac version of LC might be more robust than the Windows version, because I've seen a similar situation with other apps that were created first for MacOS and later converted to run on Windows.
I started programming 45 years ago, using punch cards and waiting hours for turn-around to see the results of a single run of my application. Software development tools have come a looooooong way since then.
LC appears to have numerous very cool features that enhance application development, but some of those features actually get in the way. The sluggishness of the script editor appears very similar to application behavior in which a user interface thread does not get a high enough priority over other threads, and should not be too difficult to fix, one would think. It's as if the code that's doing syntax checking 'live' while I type is 'trying too hard', and as a result gets in the way.
Also, the fact that application code ends up being 'spread all over the place' comes with the territory of LC's style of object-oriented development, but presents another challenge -- source code version control becomes cumbersome at best and impossible at worst.
Workarounds don't appeal to me. I'm completely spoiled by debuggers that work reliably and editors that are 'invisible'. I'm planning to develop for Android and iOS, and wondering if going native might present less of a learning curve and obstacle course than using LC.
First, thank you for sharing your insights.
I have wondered whether the Mac version of LC might be more robust than the Windows version, because I've seen a similar situation with other apps that were created first for MacOS and later converted to run on Windows.
I started programming 45 years ago, using punch cards and waiting hours for turn-around to see the results of a single run of my application. Software development tools have come a looooooong way since then.
LC appears to have numerous very cool features that enhance application development, but some of those features actually get in the way. The sluggishness of the script editor appears very similar to application behavior in which a user interface thread does not get a high enough priority over other threads, and should not be too difficult to fix, one would think. It's as if the code that's doing syntax checking 'live' while I type is 'trying too hard', and as a result gets in the way.
Also, the fact that application code ends up being 'spread all over the place' comes with the territory of LC's style of object-oriented development, but presents another challenge -- source code version control becomes cumbersome at best and impossible at worst.
Workarounds don't appeal to me. I'm completely spoiled by debuggers that work reliably and editors that are 'invisible'. I'm planning to develop for Android and iOS, and wondering if going native might present less of a learning curve and obstacle course than using LC.
~Bob (one of the many)
-
- Livecode Opensource Backer
- Posts: 9476
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Slow Script Editor
I started in 1976 with Hollerith cards, a horrible machine that looked like a steam-drive number-pad, and FORTRAN IV.I started programming 45 years ago
- -
Then I thought things were no end of posh when they introduced us to a newq type of Hollerith card where, instead of punching
holes, you filled in tiddly-widdly rectangles with a carbon pencil.
- -
Unlike some sentimentalists, I cannot tell you how glad I am those days are gone.
That's why, when 'things' get too intrusive and I start getting attacks of GUISD (Graphic User Interface Stress Disorder)but some of those features actually get in the way
I crank up either my BBC Model B or my BBC Master Compact and faff around with BBC BASIC on a nice, wholesome
black screen.
I don't suppose they appeal to anyone as, after all, they are work arounds, which is as far as I understandWorkarounds don't appeal to me.
a polite way of saying: a kaka way of getting a programming language to do what it should do had the
developers of that programming language been aware of that requirement and implemented it.
If you can find a programming language that can do absolutely everything with a WYSIWYG interface please let
me know.
Well; two thoughts occur to me:a learning curve and obstacle course than using LC
1. I wonder if you would not be swapping one learning curve and obstacle course for another?
2. As I am 60 and my brain is about 75% fossilised by this point, I really wonder whether I have still got the mental
'oomph' to learn a new programming language at least up to the level I have managed in LiveCode.
I stuck #2 in there, because, TheOtherBob, if you started programming 45 years ago we must be much of an age.
As LiveCode does what I need (and that means NO walks on the wild mobile device side), slow script editor or not, I am perfectly happy with it.
Re: Slow Script Editor
Fair enough - I was just sharing my preferred option. I too started out with the same mindset as you, but gradually got quite tired of the idiosyncrasies of the SE and also the dictionary, so i have replaced both with other 3rd party options and am personally much happier - but that's just me. But perhaps it's you too, as you wouldn't be posting the question if the script editor was reliable as you'd like. It's not bad mind you, it's just not great.TheOtherBob wrote: ↑Sat Apr 09, 2022 5:45 pmWorkarounds don't appeal to me. I'm completely spoiled by debuggers that work reliably and editors that are 'invisible'. I'm planning to develop for Android and iOS, and wondering if going native might present less of a learning curve and obstacle course than using LC.
'Invisible' is fine, but using the best tool for the job is better!
One of the issues is that the Script Editor is built as a normal LC stack; and LC is not multithreaded; there are no thread priorities because there is only one threadTheOtherBob wrote: ↑Sat Apr 09, 2022 5:45 pmsimilar to application behavior in which a user interface thread does not get a high enough priority over other threads
It's not just a matter of speed either; for an IDE that encourages long scripts (eg script and card scripts that can contain thousands of lines) there is a notable lack of helpful features like split screen editing, code folding, dark mode, modifiable syntax colouring etc.
Bernd has a point in that it is remarkable for what they've achieved creating this as a normal stack, but if i'm honest i wouldn't mind if the SE wasn't built in LiveCode, if a compiled app did it better. It will be interesting to see if the newer developments with compiled scripts will mean for this.
Version control need not be as difficult or cumbersome as you may think. ScriptOnlyStacks are great.They are just text files - and ideally suited.TheOtherBob wrote: ↑Sat Apr 09, 2022 5:45 pmAlso, the fact that application code ends up being 'spread all over the place' comes with the territory of LC's style of object-oriented development, but presents another challenge -- source code version control becomes cumbersome at best and impossible at worst.
Neither does code have to be spread all over the place; the more i've used LC the more i've centralised code putting the absolute minimum into controls and using card scripts as 'view' code (obviously some 'view' code in controls as well) and the stack scripts for 'controller' and 'model' code in an MVC approach; and from there I've began splitting out code into libraries.
As my projects have grown in size it's been increasingly difficult managing code split into interface elements and massive stack/card scripts with > 2000 lines.
The scriptOnlyStack method i mention above allows me to centralise all code in one place - an external editor like VSCode - while keeping each script reasonably sized and partitioned in logical compartments - essential for my sanity
As a sidenote, you may also at some point want to look at Dictionary alternatives: on Windows Zeal (free) and Velocity (free/nagware) are great alternatives to Dash for mac.
Dash is an absolutely excellent API documentation app - like the Dictionary, but orders of magnitude better - i really can't manage without it now...
What's even better is that all 3 of these apps automatically integrate with VSCode as well and you can launch documentation blazingly fast from there as well - while LiveCode ltd has done nothing to bring liveCode to Dash docsets, James Hale maintains maintains a user contributed docset that can be installed via Dash and he's also created a great stack to create your own documentation: https://livecodeshare.runrev.com/stack/ ... ke-DocSet/
I know none of this will currently appeal to you @theOtherBob, but just mentioning alternatives... you never know, it may appeal in the future or others may find the discussion useful...
-
- VIP Livecode Opensource Backer
- Posts: 7266
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Slow Script Editor
The one objection I have with script-only stacks is that you can't use remote debugging with them, and since most of my work these days involves mobile apps that's a major drawback. On the other hand, my Mac doesn't display the slowness that Windows does, so using the native SE works well enough.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- Livecode Opensource Backer
- Posts: 9476
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Slow Script Editor
Thank you so, so much . . . I really wish I had known about that ages ago.Start by turning off all the options in the Edit menu you don't use. They cause slowdowns.
https://forums.livecode.com/viewtopic.p ... te#p182698
I have all of them off except for auto-bracketing.
-
-
- Livecode Opensource Backer
- Posts: 9476
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Slow Script Editor
My question about external text editors for scripts relates to the
copy-past cafuffle between those and the in-built editor . . .
copy-past cafuffle between those and the in-built editor . . .
Re: Slow Script Editor
I do not copy/paste...richmond62 wrote: ↑Sun Apr 10, 2022 9:34 amMy question about external text editors for scripts relates to the
copy-past cafuffle between those and the in-built editor . . .
I use scriptOnlyStacks (henceforth known as SOS because i'm lazy )
I edit these in VSCode and reload these as needed in LC to test.
Needs a 1-time setup to load all SOS and a handler to reload them after external editing.
As all my SOS are in one folder all my scripts (including all stack/card behaviours which will replace the stack/card scripts) all show up in the same place as project folder in VSCode.
Bit of a minor hassle for the 1-time set up to do this and still tweaking some minor bits with this system but i expect this to be transferrable to my other projects and so far works well.
Downsides are these are not binary files but text files, so in production unless you convert everything back to 'proper' stacks rather that SOS they are viewable/editable by the user. And Jacque mentioned this stops her from doing remote-debugging on mobile (not an area i've looked into). Obviously debugging isn't done in VSCode as LC have not provided integration for this (but many other IDEs have), so still use the native SE for that.
But upsides are that VSCode has so many useful features it's a joy to use (apart from syntax colouring, code formatting, linting etc - provided by FerrusLogic - its a blazing fast code editor that can display split screen multiple tabs, code-folding, dark mode etc. More importantly it has helped me properly compartmentalise my long scripts into logical MVC units so they are both smaller and easier to maintain.
As there is no full integration with external editors inevitably there is mix-and-match and i end up coding in both the native SE and VSCode, but for working on long scripts it's just much nicer using a well established, nimble and very capable code editor...