Skip to first unread message
Tony Gravagno
Sep 19, 2019, 8:24:47 PM9/19/19
to Pick and MultiValue Databases
;TL/DR; The VSCode extension for BASIC is getting better, there are more ways to talk about it, and you’re invited!
The Visual Studio Code extension was originally written by Grant Hart and the team at ONgroup to support MVON#. We've seen many notes here and a lot of interest. You can find that extension in the VS Code Marketplace:
<https://marketplace.visualstudio.com/items?itemName=ongroup.mvon>
You can find it here <https://github.com/mvextensions/mvbasic>
That team expanded further to include others who are not employed by ONgroup or Zumasys ... It's become a true community project, guided by industry leaders. References to this team are in the repository README (the landing page for the repo IS the README).
The software is not yet ready for actual usage. But it is ready for alpha installation, and suggestions for enhancements and bug fixes. See the README for instructions.
This announcement is not about the functionality of the software. It's about us, the community, and our new venues for collaboration. So here we go..
How to contribute:
1) Just use it as it gets updated, and then share your thoughts.
2) Help with documentation. Offer some text when you see that some feature is not documented, or under-documented, or poorly documented.
3) Offer code. If TypeScript isn’t your thing (and for most of us it’s not), offer snippets or config-file changes, which are simple JSON.
4) Offer insight into how a challenge should be approached. You don't need to fix a problem, just help to refine the definitions of problems and solutions.
5) Create a bug report. What did you find that didn't work? Or report an issue for someone else.
6) Create a feature request. What isn't there that should be? How should it work differently? How would you improve it?
7) Tell others about it.
8) Get someone in your company to participate.
9) Test patches, branches, and pull requests before they get merged and published.
(Note the above applies to All FOSS)
And now, how do we actually communicate about such things?
1) If you have a GitHub account, "Watch" the repo and just keep an eye on how things are progressing.
2) Comment on GetHub Issue items. Your opinions and insight have value.
3) Create new Issues for bugs or features. Suggest new content for the documentation.
4) Post here in this Google Group using the tag 'mvextensions' or 'vscode'. Create new threads to address single, focused topics. Preface the subject with [MVExtensions] as I've done with this thread.
5) Join https://mvtalk.slack.com/ : The mvTalk team/workspace at Slack.com. When there, join the #mvextensions channel, recently created just for this purpose.
6) With a GitHub account or others you can also join <https://gitter.im/mvextensions/community>.
7) If you prefer StackOverflow, ask questions there. With enough usage we'll get an 'mvextensions' tag, which can then be monitored by anyone who is interested in the topic. <https://stackoverflow.com/tags/mvextensions>
Why not just one place? Because Everyone doesn't hang out in one place. People have different preferences. The goal with this community initiative is to allow more people to communicate where They feel comfortable. Going to the audience yields much better results than waiting or forcing the audience to come to you. And note that there are different kinds of media here:
- GH issues are more formalized, a permanent record.
- Forums are threaded, asynchronous, less formal.
- Chat rooms are for immediate questions as they occur to you, and (with luck) near-term, synchronous feedback, when you're right there using the software or writing code. This is also good for those who like to take notes when you’re on the go – use mobile apps to chat like you use SMS.
Use different media to suit your needs … but don’t hold it against others if you choose not to use media that others prefer.
And remember - it's always better to start a new discussion than to pile multiple topics into a single discussion.
The Visual Studio Code extension was originally written by Grant Hart and the team at ONgroup to support MVON#. We've seen many notes here and a lot of interest. You can find that extension in the VS Code Marketplace:
<https://marketplace.visualstudio.com/items?itemName=ongroup.mvon>
The project expanded recently with a collaboration agreement with Zumasys. See:
The new goal has been to support many more MV platforms, and the software was open-sourced. You can find it here <https://github.com/mvextensions/mvbasic>
That team expanded further to include others who are not employed by ONgroup or Zumasys ... It's become a true community project, guided by industry leaders. References to this team are in the repository README (the landing page for the repo IS the README).
The software is not yet ready for actual usage. But it is ready for alpha installation, and suggestions for enhancements and bug fixes. See the README for instructions.
This announcement is not about the functionality of the software. It's about us, the community, and our new venues for collaboration. So here we go..
There are now several ways for people to participate, and several places for this to occur.
How to contribute:
1) Just use it as it gets updated, and then share your thoughts.
2) Help with documentation. Offer some text when you see that some feature is not documented, or under-documented, or poorly documented.
3) Offer code. If TypeScript isn’t your thing (and for most of us it’s not), offer snippets or config-file changes, which are simple JSON.
4) Offer insight into how a challenge should be approached. You don't need to fix a problem, just help to refine the definitions of problems and solutions.
5) Create a bug report. What did you find that didn't work? Or report an issue for someone else.
6) Create a feature request. What isn't there that should be? How should it work differently? How would you improve it?
7) Tell others about it.
8) Get someone in your company to participate.
9) Test patches, branches, and pull requests before they get merged and published.
(Note the above applies to All FOSS)
And now, how do we actually communicate about such things?
1) If you have a GitHub account, "Watch" the repo and just keep an eye on how things are progressing.
2) Comment on GetHub Issue items. Your opinions and insight have value.
3) Create new Issues for bugs or features. Suggest new content for the documentation.
4) Post here in this Google Group using the tag 'mvextensions' or 'vscode'. Create new threads to address single, focused topics. Preface the subject with [MVExtensions] as I've done with this thread.
5) Join https://mvtalk.slack.com/ : The mvTalk team/workspace at Slack.com. When there, join the #mvextensions channel, recently created just for this purpose.
6) With a GitHub account or others you can also join <https://gitter.im/mvextensions/community>.
7) If you prefer StackOverflow, ask questions there. With enough usage we'll get an 'mvextensions' tag, which can then be monitored by anyone who is interested in the topic. <https://stackoverflow.com/tags/mvextensions>
Why not just one place? Because Everyone doesn't hang out in one place. People have different preferences. The goal with this community initiative is to allow more people to communicate where They feel comfortable. Going to the audience yields much better results than waiting or forcing the audience to come to you. And note that there are different kinds of media here:
- GH issues are more formalized, a permanent record.
- Forums are threaded, asynchronous, less formal.
- Chat rooms are for immediate questions as they occur to you, and (with luck) near-term, synchronous feedback, when you're right there using the software or writing code. This is also good for those who like to take notes when you’re on the go – use mobile apps to chat like you use SMS.
Use different media to suit your needs … but don’t hold it against others if you choose not to use media that others prefer.
And remember - it's always better to start a new discussion than to pile multiple topics into a single discussion.
Thanks for your time.
T
MAV
Sep 20, 2019, 4:12:23 AM9/20/19
to Pick and MultiValue Databases
Hi all,
For me, it is the most interesting project of recent years. I am doing something with Typescript. If I get a good level I will get involved as much as I can. It may seem weird, but an editor like VSCode can attract many people to the MultiValue world.
Marcos Alonso Vega
Tony Gravagno
Sep 20, 2019, 9:05:17 PM9/20/19
to Pick and MultiValue Databases
I agree, Marcos, and I think this is something that hasn't been discussed in the industry yet (in public anyway).
VSCode will be used by newcomers to the MV platform, where other tools will not. We will not get Python or Java developers to use ED (GED, SED, WED, AE, or even vi built-in to D3). But if they can get immediate access to the environment through VSCode, a lot of those barriers to the initial learning experience will go away.
This will mean enhancements to the MVExtensions for TCL, compilation, running code, and possibly dict items and other record types.
About dict items, BTW, I think one conversation that should come up at some point is how to represent dict items outside of the MV environment. For example, there's nothing wrong with reading a dict item and then rendering it in VSCode as a JSON object. The developer can work with it natively there, and on save, a program breaks fields out into the proper attributes. This is the way configuration works in these tools and I think we would do well to make our environment more comfortable for those who are familiar with these tools.
This is all new stuff and there is a long way to go. I really look forward to seeing more discussions on this topic in all of the newly available media.
T
Ian McGowan
Sep 21, 2019, 8:15:36 PM9/21/19
to Pick and MultiValue Databases
I imagine everyone reading this is in violent agreement (though perhaps we're not typical MV developers). I'd love to add a visual debugger to that enhancement list, though that's easier said than done.
Also love the idea of presenting dict items (and maybe even data items, with good dictionaries) as json. Maybe one day soon there'll be a filetype that actually stores data natively as json or jsonb? Can also see building a graphical component in to the extension too. It's pretty handy to add the SQL Server extension to vscode and be able to poke around the database with a better CLI than SSMS.
In general there does seem to be some exciting stuff happening and the MV extensions are generating more enthusiasm than I've seen for a while which is awesome! Thanks to everyone making this happen..
In general there does seem to be some exciting stuff happening and the MV extensions are generating more enthusiasm than I've seen for a while which is awesome! Thanks to everyone making this happen..
Reply all
Reply to author
Forward
0 new messages