[FEATURE] Add mvBase PROC as a language option.

[TedCha]

Is your feature request related to a problem? Please describe.
I work at company who uses a lot of PROCs within their menus and some of their processes. It's pretty annoying to have to edit these files because there is no syntax highlighting at all. I published my own mvBase PROC syntax highlighting extension to the marketplace but it would probably make more sense to be in this extension rather than as a standalone extension.

Currently everything works pretty well, there's a few known issues that I need to fix (user exits have not been accounted for and the T command could use some work). If you think it's a good idea for it to be a part of this extension, I'd be happy to submit a pull request once I fix the mentioned issues.

BTW, this project is awesome! It's so cool to see open source for mvBasic.

[itsxallwater]

I think it's a fantastic idea! We don't have an mvBase language definition yet either, perhaps you'd be willing to work on that too if it's not too much to ask?

[TedCha]

Sure! I'm not sure what a language definition is though. Is there any existing examples I can look at to get an idea of where to start?

[itsxallwater]

Absolutely. If you check out the Syntaxes folder in this repo that's a great place to start--I think adding proc files there will be key plus you can get a sense for the existing language definition and syntax highlighting files for other flavors.

One example is https://github.com/mvextensions/mvbasic/blob/main/Syntaxes/jBASELanguage.json

In general note that the FlavorLanguage.json files define the basic language whereas the Flavor.tmLanguage.json define the highlighting.

[andrewcole50]

As a note, last I heard mvBase was getting discontinued/rolled-into d3. Now that was ~3 years ago and one of the major reasons we migrated to another flavor. Unless that's changed, I'm not sure it would be worth it to create a new language definition for a sunsetting flavor. From what I remember, the only real differences regarding mvBase BASIC were the DOS file operations functions (UOPEN, UREAD, UWRITE, etc) from bare bones BASIC. So if you were going to do a language for mvBASIC, then it might only consist of copying mvon and adding about 10 or so functions.

https://info.rocketsoftware.com/OPERATIONAL-2019-06-D3-1031-mvBase-Product-Launch_LP.html

[TedCha]

I'm very new to the MultiValue Pick universe, so apologies for any misunderstandings I may have. I named my extension under the guise of mvBase because I pulled the syntax from the following documentation: mvBase PROC User Reference Guide Overview.

Now that I'm looking more into it, I think my PROC grammar file will work for a multitude of PROC flavors rather than just mvBase (a few more commands would need to be added of course). I just looked the Rocket ProVerb guide for the latest version of UniVerse (found here) and the syntaxes seem to match (besides having the optional header of PQN and few new commands).

I'm not 100% sure what to make of all of this but am I happy to contribute in whatever manner is deemed best for the project.

[dthiot]

Andrew, As the page at the link suggests, Rocket has integrated mvBASE functionality into D3 10.3.1 and beyond. mvBASE was based on a traditional ABS that is a bit different for D3/Windows and since mvBASE was a windows only product I suspect that most sites would migrate to D3 on Windows rather than Linux. Anyone that has custom ABS (PICK assembler) code has work to do to make the transition and I don’t have any idea how many sites are like that. I think that the D3 language definition needs to support the mvBASE specific statements/functions. I would say that we can probably get by without a mvBASE specific language option however, as soon as we try to do that then someone will likely ask for mvBASE specific language support because they haven’t transitioned. I have several customers still running mvBASE. I hope my thoughts and comments aren’t too disjointed. Dick From: andrewcole50 <[email protected]> Reply-To: mvextensions/mvbasic <[email protected]> Date: Thursday, March 4, 2021 at 8:00 AM To: mvextensions/mvbasic <[email protected]> Cc: Subscribed <[email protected]> Subject: Re: [mvextensions/mvbasic] [FEATURE] Add mvBase PROC as a language option. (#142) As a note, last I heard mvBase was getting discontinued/rolled-into d3. Now that was ~3 years ago and one of the major reasons we migrated to another flavor. Unless that's changed, I'm not sure it would be worth it to create a new language definition for a sunsetting flavor. From what I remember, the only real differences regarding mvBase BASIC were the DOS file operations functions (UOPEN, UREAD, UWRITE, etc) from bare bones BASIC. So if you were going to do a language for mvBASIC, then it might only consist of copying mvon and adding about 10 or so functions. https://info.rocketsoftware.com/OPERATIONAL-2019-06-D3-1031-mvBase-Product-Launch_LP.html — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#142 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACOODL7X75TTFTCZJNBMFBDTB6G6HANCNFSM4YSJTBLQ>.

[andrewcole50]

@dthiot you're correct in regards to that article. I just did a quick web search to pull something that (partially) supported what I was saying. My info very well may be outdated but in 2017 someone (I won't name him) at Rocket told me on the phone that they wanted to add mvBase functionality to d3, migrate mvBase users to d3 and shutter further mvBase development. Not long after that call Rocket posted a blog about the same thing but I can't seem to find it on their site anymore. Things very well may have changed with Rocket's plans but I'm not privy to them anymore since we moved to jBASE.

@tcharts-boop AFAIK, most of the PROC...languages? scripts? are very very similar so a good majority of your work most likely does cross over to other flavors. I don't work with PROCs where I'm at so I won't be too much help in that department. If there's something wrong with a PROC I make the other dev deal with it bc I'd rather just write it in BASIC.

[itsxallwater]

My thoughts:

1. On mvBase vs D3, I think supporting both is fine and acceptable and doesn't put too much burden on this project. The two have a high amount of overlap but they are different, and there are plenty of people still running the former. Even with Rocket's decision, there are liable to be mvBase sites out in the wild for quite some time.
2. On separate PROC definitions done per flavor vs one consolidated, I think separate would be ideal. This may matter less with syntax highlighting although it would still allow for variances between flavors of PICK. It will definitely matter more for language definitions of the PROC language for each flavor, as documentation of each is invariably different and we want the language definition to conform to the flavor's docs. The PICK BASIC side isn't too different in that regard--each of the flavors implement the same core things, but we provide different language definitions for each so that they can conform to each flavors doc language, if that makes sense.

[itsxallwater]

Another thought but with Rocket deciding to push their own extension instead of contributing here, we can probably assume mvBase users won't find much support for their flavor in the "official" Rocket extension so all the more reason for them to have a home here. It will be interesting to see if the same cycle repeats itself for D3--I certainly saw some precursors to that as a former D3 customer.

[dthiot]

That is a very good point that the mvBASE users won’t have support from their vendor. From: Mike Wright <[email protected]> Reply-To: mvextensions/mvbasic <[email protected]> Date: Thursday, March 4, 2021 at 10:34 AM To: mvextensions/mvbasic <[email protected]> Cc: Dick Thiot <[email protected]>, Mention <[email protected]> Subject: Re: [mvextensions/mvbasic] [FEATURE] Add mvBase PROC as a language option. (#142) Another thought but with Rocket deciding to push their own extension instead of contributing here, we can probably assume mvBase users won't find much support for their flavor in the "official" Rocket extension so all the more reason for them to have a home here. It will be interesting to see if the same cycle repeats itself for D3--I certainly saw some precursors to that as a former D3 customer. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#142 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACOODL62NKE634I6MQEUDELTB6Y7NANCNFSM4YSJTBLQ>.

[TedCha]

I've been working on updating the tmLanguage file for my PROC extension and also creating a language definition file. To settle on this issue and provide a good starting point, I'll make a pull request in the near future to add the Universe flavor PROC language to this extension. When that's complete, I can start looking for other PROC documentation to make separate PROC tmLanguage and language definition files for each MultiValue flavor. Does that sound like a good idea?

[itsxallwater]

Love it!

[dthiot]

I love it to. I may be able to help with mvBase and D3. We should consider having another call. Next Tuesday? On Mar 16, 2021, at 10:37, Mike Wright ***@***.***> wrote:  Love it! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#142 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACOODL5YD2BZ6IUIIXN2XKTTD53JVANCNFSM4YSJTBLQ>.