Don't remember seeing this mentioned here before but it looks interesting.
You may have heard of Vulcan.NET which is an xBase language in more of the Clipper vein and which supports Visual Objects projects.
Anyway the consensus among developers is that Vulcan.NET is dying or dead, and so some of the developers have struck out on their own to implement an open-source .NET implementation of xBase.
"In April 2015 a group of concerned customers and some members of the GrafX development team have talked about starting a new open source project to give the xBase language for .NET a new future. This initiative is called XSharp. This was partially inspired by the fact that Microsoft has published the source code to its C# and Visual Basic compilers under an open source license (.NET Compiler Platform "Roslyn"[1]). The plan is to create a new development language (compiler, runtime libraties, IDE, tools) where the compiler is partially based on the Roslyn source code."
While it will initially support Vulcan\Clipper\VO type syntax (which is in the VFP ballpark but not identical) they also intend to support VFP syntax next. I would imagine it would be core VFP syntax, dropping all the legacy stuff like @ .. SAY and defunct SYS() functions and so forth. I *think* they intend to support DBF files natively.
Anyway, worth keeping an eye on at least.
--
Alan Bourke
alanpbourke (at) fastmail (dot) fm
Links:
1. https://roslyn.codeplex.com/
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
Will certainly keep an eye on that one... tried to register but the site just hangs...
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Alan Bourke Sent: 07 February 2017 10:22 To: profoxtech@leafe.com Subject: X#
Don't remember seeing this mentioned here before but it looks interesting.
You may have heard of Vulcan.NET which is an xBase language in more of the Clipper vein and which supports Visual Objects projects.
Anyway the consensus among developers is that Vulcan.NET is dying or dead, and so some of the developers have struck out on their own to implement an open-source .NET implementation of xBase.
"In April 2015 a group of concerned customers and some members of the GrafX development team have talked about starting a new open source project to give the xBase language for .NET a new future. This initiative is called XSharp. This was partially inspired by the fact that Microsoft has published the source code to its C# and Visual Basic compilers under an open source license (.NET Compiler Platform "Roslyn"[1]). The plan is to create a new development language (compiler, runtime libraties, IDE, tools) where the compiler is partially based on the Roslyn source code."
While it will initially support Vulcan\Clipper\VO type syntax (which is in the VFP ballpark but not identical) they also intend to support VFP syntax next. I would imagine it would be core VFP syntax, dropping all the legacy stuff like @ .. SAY and defunct SYS() functions and so forth. I *think* they intend to support DBF files natively.
Anyway, worth keeping an eye on at least.
--
Alan Bourke
alanpbourke (at) fastmail (dot) fm
Links:
1. https://roslyn.codeplex.com/
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
[excessive quoting removed by server]
On Tue, 7 Feb 2017, at 11:16 AM, Dave Crozier wrote:
Will certainly keep an eye on that one... tried to register but the site just hangs...
It seems to be having trouble this morning but I managed it OK yesterday. I had a quick look at the current Beta. It seems to exist as both a Visual Studio extension and a standalone XIDE product. The former adds new project types into VS so you can create a new X# WPF, Winforms, Vulcan.NET or console project. XIDE I think is a recreation of the Visual Objects IDE, but AFAIK has been created entirely in X# itself, as a dogfooding exercise.
When I downsized last year I got rid of a load of books (offered here) - this included full sets for V.O. and Clipper - including a special edition Technical Reference which had all the 'C' source code for Clipper functions ( Clipper used a macro* pre-processor that converted 'Commands' into functions - *you could write your own commands). I also remember seeing comments on the Harbour/xHarbour site asking contributors not to just submit these C functions without checking/re-writing them.
Add to that the source code for the VFP extensions for C# /VB .NET and I can see where these guys are coming from, and maybe where they're going <g>
...
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Alan Bourke Sent: 07 February 2017 10:22 To: profoxtech@leafe.com Subject: X#
Don't remember seeing this mentioned here before but it looks interesting.
You may have heard of Vulcan.NET which is an xBase language in more of the Clipper vein and which supports Visual Objects projects.
Anyway the consensus among developers is that Vulcan.NET is dying or dead, and so some of the developers have struck out on their own to implement an open-source .NET implementation of xBase.
"In April 2015 a group of concerned customers and some members of the GrafX development team have talked about starting a new open source project to give the xBase language for .NET a new future. This initiative is called XSharp. This was partially inspired by the fact that Microsoft has published the source code to its C# and Visual Basic compilers under an open source license (.NET Compiler Platform "Roslyn"[1]). The plan is to create a new development language (compiler, runtime libraties, IDE, tools) where the compiler is partially based on the Roslyn source code."
While it will initially support Vulcan\Clipper\VO type syntax (which is in the VFP ballpark but not identical) they also intend to support VFP syntax next. I would imagine it would be core VFP syntax, dropping all the legacy stuff like @ .. SAY and defunct SYS() functions and so forth. I *think* they intend to support DBF files natively.
Anyway, worth keeping an eye on at least.
--
Alan Bourke
alanpbourke (at) fastmail (dot) fm
...
Add to that the source code for the VFP extensions for C# /VB .NET and I can see where these guys are coming from, and maybe where they're going
Yeas, I hadn't realised that Clipper/Visual Objects had that extensibility. They've commented that you could implement quite a few VFP functions that way. To me however the Clipper world is sufficiently syntactically different that the best way is just to implement a new Antlr grammar for VFP code in the same way that they already have for X#.
On 10-Feb-2017 3:16 PM, Alan Bourke wrote:
Add to that the source code for the VFP extensions for C# /VB .NET and I can see where these guys are coming from, and maybe where they're going
Yeas, I hadn't realised that Clipper/Visual Objects had that extensibility. They've commented that you could implement quite a few VFP functions that way. To me however the Clipper world is sufficiently syntactically different that the best way is just to implement a new Antlr grammar for VFP code in the same way that they already have for X#.
Alan, it's been a *very* long time and a lot of beer has flowed, but from memory the big syntactic differences were Browse and array handling (Clipper's was much better than FoxPro's - iirc a Clipper array is implemented as a pointer to a list, each entry can be any sort of value including an array). Forms and reports are also different, but I suspect that there would be problems implementing those (and the FoxPro "Window") in .Net anyway. Thinking laterally, someone (Christoff?) was said to be working on a new intercode parser, which might be on similar lines, or even to generate ECMAscript from VFP syntax?
Having had a further look at this it does not (yet???) seem to be as all-inclusive of xbase dialects as it claims. In fact it reminded me very clearly of why I stopped my V.O. subscription to Nantucket - the price was/is way above what could be afforded by a self-employed developer. It has certainly progressed faster than the glacial pace of [x]Harbour, but their timetable for 2017 doesn't seem to mention VFP (or even basic xbase??).
So, what compelling feature would an "Xbase replacement" get everyone really interested?
Runs on iPhone?
Reads/writes VFP-compatible Power Tools (screen, report, etc.)?
Reads/writes VFP 9 DBC, tables, stored procedures, etc.?
Runs over the internet?
For me, the language isn't any big deal. There's lots of OOP languages, IF...ELSEIF...ENDIF constructs, CASE statements even if they call them SWITCH.
For me, the data store isn't a big deal. I would prefer one with drivers for MariaDB, PostgreSQL and for enterprise support, Oracle and SQL Server. Bonus for DBFs, to aid in migration, but not a deal-breaker; I've written some killer migration apps to move DBFs to some other ODBC-compatible target.
I work with editors far superior to what I get inside VFP.
What I do love about VFP is the integration of GUI design with code, code with classes, a built-in build tool, debugger, interactive data manipulation and, of course, the infinitely deep support resources of books, magazines and web sites.
I have apps that are 30 years old that use every Xbase command you can imagine.
Yesterday, I ran across a very specialized reporting module written with ??? and ?? and using the ON PAGE command -- you know what that is, right?
So, my dream Xbase replacement would take this 30-year-old app and run it, flawlessly.
On Sat, Feb 11, 2017 at 6:40 AM, AndyHC andy@hawthorncottage.com wrote:
Having had a further look at this it does not (yet???) seem to be as all-inclusive of xbase dialects as it claims. In fact it reminded me very clearly of why I stopped my V.O. subscription to Nantucket - the price was/is way above what could be afforded by a self-employed developer. It has certainly progressed faster than the glacial pace of [x]Harbour, but their timetable for 2017 doesn't seem to mention VFP (or even basic xbase??).
[excessive quoting removed by server]
Runs on iPhone?
If you implement it as a .NET language then you get that and Android for free with the Xamarin tools.
Reads/writes VFP-compatible Power Tools (screen, report, etc.)?
Could be useful in migration but once you're in the .NET or Java or whatever world then you have a choice of presentation layers. I think there would be so much re-engineering necessary that it wouldn't be worth it.
Reads/writes VFP 9 DBC, tables, stored procedures, etc.?
Might be nice in migration but going forward I don't know why anyone would remain tied to a file-based database.
Reads/writes VFP 9 DBC, tables, stored procedures, etc.?
Again, make it a .NET language and it becomes usable server-side in web applications. You'd still be lumbered with Javascript and two million JS client-side libraries on the client side of course.
I think what I would like is the basic VFP syntax as a .NET language, with all the legacy crud like most of the Sys() functions, @ .. SAY, all the 2.x stuff, all the Mac stuff and so forth removed. Then add an ORM layer for working with data stores as object collections.
Once you have that then you have a choice of UI and reporting solutions.
On Sat, Feb 11, 2017 at 9:16 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
I think what I would like is the basic VFP syntax as a .NET language, with all the legacy crud like most of the Sys() functions, @ .. SAY, all the 2.x stuff, all the Mac stuff and so forth removed. Then add an ORM layer for working with data stores as object collections.
Once you have that then you have a choice of UI and reporting solutions.
Isn't that what VB.NET gives you? (xBASE and Visual BASIC both have roots in Kemeny & Kurtz's BASIC)
It's more like what something like IronPython gives you.
On Sat, Feb 11, 2017 at 11:33 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
It's more like what something like IronPython gives you.
And what is that? (Asking out of genuine curiosity and ignorance, not picking a fight.)
On Feb 11, 2017, at 2:07 PM, Ted Roche tedroche@gmail.com wrote:
It's more like what something like IronPython gives you.
And what is that? (Asking out of genuine curiosity and ignorance, not picking a fight.)
IronPython is an implementation of Python that runs on the CLR.
-- Ed Leafe
--- StripMime Report -- processed MIME parts --- multipart/signed text/plain (text body -- kept) application/pgp-signature ---
On Sat, Feb 11, 2017 at 3:09 PM, Ed Leafe ed@leafe.com wrote:
On Feb 11, 2017, at 2:07 PM, Ted Roche tedroche@gmail.com wrote:
It's more like what something like IronPython gives you.
And what is that? (Asking out of genuine curiosity and ignorance, not picking a fight.)
IronPython is an implementation of Python that runs on the CLR.
My bad. I deserve an answer right out of Airplane:
Ted Striker: Mayday! Mayday! Steve McCroskey: What the heck is that? Johnny: Why, that's the Russian New Year. We can have a parade and serve hot hors d'oeuvres...
But what I meant by "what is that" is
"So, what compelling feature would an IronPython get everyone really interested as an Xbase Replacement?"
My point, from earlier in this thread, was the FoxPro is the world's most awesome desktop database application development environment, as long as you're willing to stick to the Windows platform. And replacing it is a challenge because it's an IDE, a debugger, a programming language (or three: XBase, SQL, LLFFs, TextMerge, and more), a compiler, a local data engine, a graphical design language, a report writer, and... well, more.
On Feb 11, 2017, at 3:56 PM, Ted Roche tedroche@gmail.com wrote:
My point, from earlier in this thread, was the FoxPro is the world's most awesome desktop database application development environment, as long as you're willing to stick to the Windows platform. And replacing it is a challenge because it's an IDE, a debugger, a programming language (or three: XBase, SQL, LLFFs, TextMerge, and more), a compiler, a local data engine, a graphical design language, a report writer, and... well, more.
Now you know how much fun it was to create Dabo! Having to duplicate all that functionality was not simple, to say the least. ;-)
-- Ed Leafe
--- StripMime Report -- processed MIME parts --- multipart/signed text/plain (text body -- kept) application/pgp-signature ---
On Sat, Feb 11, 2017 at 5:25 PM, Ed Leafe ed@leafe.com wrote:
Now you know how much fun it was to create Dabo! Having to duplicate all that functionality was not simple, to say the least. ;-)
Agreed! I amire all the work you and Paul did, and I appreciate that, as well as appreciate more what the Fox Team did with 10x as many people, as much for the thoughtful design as the implementation.
On 7 February 2017 at 10:22, Alan Bourke alanpbourke@fastmail.fm wrote:
You may have heard of Vulcan.NET which is an xBase language in more of the Clipper vein and which supports Visual Objects projects.
Anyway the consensus among developers is that Vulcan.NET is dying or dead, and so some of the developers have struck out on their own to implement an open-source .NET implementation of xBase.
https://github.com/X-Sharp/XSharpPublic "Public repository for the source code for the XSharp Runtime, Project System and Tools (the compiler source code is available for paying customers only)"
Shame.