$10 curiosities in coding

Mike Matthews - Omnis omnis at lineal.co.uk
Sat Feb 12 09:51:56 UTC 2022

Hello Andy,

We have come across this issue as well, and I think it is fixed with more recent builds.  Will / Reuben will know more however, so try and get a more recent build if possible from UK Support.

Mike Matthews

Lineal Software Solutions
Commercial House, The Strand<x-apple-data-detectors://1/1> Barnstaple, Devon, EX31 1EU<x-apple-data-detectors://1/1>

omnis at lineal.co.uk<mailto:mike.matthews at lineal.co.uk>



On 12 Feb 2022, at 01:50, TBS <andyh at totallybrilliant.com<mailto:andyh at totallybrilliant.com>> wrote:


Ok that’s kind of what I was thinking - its just curious that a line calling a method with a ‘:’ in it that comes from $5 is ok and works in $10, until you touch it :) So the tokenization must be there…..

I know that’s missing the point you are making - and you are absolutely correct in the way you say it too !!

Yes I *should* make my code fully $10 compatible - it has just become a mountain to climb !!!!

My only hope is to check with Omnis Support as to whether the ‘:’ issue is indeed a bug or a feature :)

On Feb 11, 2022, 8:44 PM -0500, Doug Easterbrook via omnisdev-en <omnisdev-en at lists.omnis-dev.com<mailto:omnisdev-en at lists.omnis-dev.com>>, wrote:
Hi Andy.

I find that the interpreter/method editor in the Studio 10 + to be more strict.

this is great. You are likely being caught by method names not allowing : in them (I think I saw some bug about : in things some place).

and when you edit a line in studio 10, you are subject to every new rule that the parser detects.

if you really want to have fun, try export your library to JSON because the JSON export parser is even more strict than omnis and the VCS. We now export everything to JSON to make sure it passes all tests because the JSON export also re-parses the code as it goes and compares it. The the code will cause an error in import, it flags the code as being bad.

This is super great because the VCS does not catch a number of errors and lets you check in bad/incomplete code (in studio 5, 6, 8 10 and on)

for a long time (5 years or more) we did the same thing - maintaining studio, while putting conditional code in there there we needed studio 10 to behave differently. I alwats made the code in studio 5 and up converted to 10 … and never tried to keep edting both. I needed to know that there was one master set of code.

so, i had a bunch of code that might look like

if $ctask.$isStudio10. (a function we made up)
set some properties differently
end if

now that people need mojave or better, I forced the issue an now we are at studio 10.2 (latest) and I have to tell you… its far far nicer being at one code base if you can get there.

If you want my advice: if you must do studio 5 for some reason

convert the library to studio 10
run the JSON exporter in studio 10.2 (latest)
It will give you a bunch of errors
go back to studio 5 and fix them till you get a clean studio 5 version.
then check into a studio 10.2 vcs (if you are using the studio 10 VCS for code tracking as well)

if you can get up to studio 10.2 and drop studio 5
make it a practice to run the JSON exporter after each VCS checkin.
if you get errors, then fix them in studio 10
check in to the VCS again
run the JSON exporter.

unless you want to only use GIT which has a lot of very handy things. (so we also check out data into GIT and are nearing the point of only using git)

that doesn’t solve all your problems. You highlight things as ‘have you noticed this is different?’’

yes, studio 10 is different, more strict, and my advice is to go with it. it has pointed out code some of our code that has been ’not right' for a long time.

and now that we are 10.2 only, we are finding that the quality/stability of code is getting better and better because of the stricter parser and JSON exporter.

just my $0.02

Doug Easterbrook
Arts Management Systems Ltd.
mailto:doug at artsman.com
Phone (403) 650-1978

On February 11, 2022, at 5:22 PM, TBS <andyh at totallybrilliant.com> wrote:


I have traditionally kept most of my coding to my base modules still residing in $5, so I have really not done a huge amount of code writing in $10, just fixing a few bits up and going back and adding to my $5 version as appropriate !

However today I have come across something that just strikes me as weird and wanted to bounce it off the list for a sanity check !

If I type a line such as :

Do ioMTD.$:SetTestServer(kTrue)

Where the object is correctly instantiated and otherwise works fine - wherever I have a ‘$:’ call, I get told this is an error and the line refuses to run…..

If this line is brought over from my v5 base library - it appears to be ok - it seems like it is only an issue when attempting to write it as a new line within my $10 dev version….

Am I going mad ??????!

As a corollary, if I make a method in my object as $SetTestServer - and call it as :

Do ioMTD.$SetTestServer(kTrue)

Then all is well - however often these are inherited calls which I can’t simply go and change…...

I have these scattered liberally throughout my app so it is slightly concerning !!

If anyone has any pearls of wisdom, I am all ears….

More information about the omnisdev-en mailing list