Pasting large script causes TapForms to hang indefinitely

[cf]

Here’s an example of a script that will cause this:

https://raw.githubusercontent.com/cfilipov/tfscripts/master/cheerio.js

You can try copy-pasting the contents of that script directly in the TapForms script editor and it will beach ball forever. It’s possible if I waited long enough whatever was blocking the main thread would finish but after waiting a long time I just killed tap forms (which of course does not save the script). If I had to guess it’s the syntax parsing of the js causing the hang.

As a workaround I used Sam’s script manager to download the script and add it without using the editor UI. This works for getting the script in tap forms and it’s runnable, however, if you try to open the script to edit/view it will also hang just like before.

[Sam Moffatt]

Cool that you used the Script Manager though that script is 440KB in size compressed. I can understand why the syntax highlighter died on it. When I unminified it, it came to 35402 lines and 1.4MB. It’s a chunky bit of Javascript.

[Brendan]

Yup, it appears that it’s in a loop executing this code:

[view setTextColor:color range:subRange];

Obviously not very performant for large blocks of text.

This is the syntax highlighting library I’m using:

https://github.com/swisspol/SourceTextView

It hasn’t been updated in a very long time, but worked fine for my purposes.

I’ll have to hunt around for another library. It’s not something that I want to spend a lot of time on making a new one for myself.

[Brendan]

It did eventually finish after a few minutes on my MacBook Pro.

Attachments:

You must be logged in to view attached files.

[Daniel Leu]

Brendan, how about disabling syntax highlighting when the source code is big? eg more than 50k or so?

[cf]

I think Daniel’s suggestion to disable syntax highlighting for sufficiently large files is a good short term workaround. Having a way to edit the script directly with an external editor would be another option (assuming it’s saved as a file rather than a database record), being able to have a “show in finder” or “open in”, for example.

[Sam Moffatt]

Scripts are stored in the database and if you use CouchDB you can sync them with an external editor. I have a script sync tool which creates a backup of the script fields and form scripts in a CouchDB sync’d document (I think you might be able to run it using nearby sync as well but configuring that is a pain).

I never put it out to the public but there was a version of the Script Manager that was done entirely via PHP and CouchDB that would push updates to the scripts back into Tap Forms documents. If you combined something that updates named script files with a tool like fswatch to handle updates when you hit save then you’d likely have the experience you’re after.

[cf]

All this stuff youre doing directly on CouchDB, will that still work in the upcoming version of tap forms that’s moving away from CBL?

[Brendan]

No, it wouldn’t work because CoreData is not directly compatible with CouchDB. However, a CoreData database is just an SQLite database with fields and records, so there’s nothing stopping you from directly accessing the .sqlite file from outside of Tap Forms to do some fancy stuff. You’d probably just have to relaunch Tap Forms though to see the results.

I wish the syntax highlighting code was faster.

Perhaps a disable highlighting option would be prudent.

[Sam Moffatt]

Yeah, I’ll have to figure out a different way once the next version of TF hits. Hopefully I can finally convince Brendan to put in a simple REST API to be able to do CRUD on TF’s structures. Alternatively I can figure out a way of hooking into one of the sync systems to manipulate stuff that way to avoid the need to restart. Once that stuff lands I’ll figure something out, I’m not too fussed about poking around the internals :D

[Author]

Posts