- Created: 25 November 2015
We are pleased to announce that the Friends Of XSharp (FOX) program has started.
You can now register for this program through the Store link on this website.
The introductionary price for the FOX program is EUR 495,- as has been announced before. There is also a discounting system for companies that want to subscribe with multiple users.
The FOX program includes support for the X# language as well as for Visual Objects and Vulcan.NET.
At this moment we offer support through our online forum only. The Internet Newsgroups are being setup, and we will let you know a.s.a.p. when these are available.
For our subscribers we have also uploaded the first Alpha version of the X# compiler.
- Created: 18 November 2015
Some of the many items in our TODO list for Vulcan.NET had to do with optimizing the runtime and adding some missing functionality (like passing USUALs by reference to CLIPPER methods) to it. We had already implemented some, like improving performance of the late binding system, but for obvious reasons we were not able to make any further improvements in Vulcan.NET. But now, with the fresh start of XSharp, it is a great opportunity to make things right and fast from the beginning. In this article we will discuss optimizations planned or already implemented on the USUAL, FLOAT and ARRAY data types, more about other types and parts of the runtime will follow in future articles.
The problem with the USUAL type
In Vulcan.NET, the VO-compatible USUAL type is defined as a structure (value type), which makes sense, as it is easier this way to emulate the semantics of the USUAL type, the same way as it behaves in VO. Structures are supposed to be lightweight, compact data types, usually a few bytes long, in order to achieve good performance when copying values from one to another, or passing them as parameters to methods etc. Examples of very common structures used in the system classes are System.Drawing.Point (8 bytes long) and Rectangle (16 bytes long).
The problem with the way the USUAL type is implemented in Vulcan.NET, is that it’s much longer than that. It is easy to check its size, with a simple line of code:
- Created: 11 November 2015
Below is a list of some of the most visible new language features in the Core language of X# , compared to Visual Objects and Vulcan.
As you can see many new keywords were introduced, but these are positional: they will also be recognized as Identifiers on other places, so there is very little chance that you will have to make changes to avoid naming conflicts.
Entities and Statements
Below is a list of the new commands / entities inside X#. There are also some new options for existing commands. A full list of changes will be available later.
- Created: 22 October 2015
A while ago we have officially launched the new XSharp project and announced that we are working on a new XBase for .Net platform called X#.
We have received many positive reactions from the community, especially about the fact that we will be releasing the product under an Open Source License. Some people have asked us under which Open Source License model we will release the source code and others have asked us how we plan to finance development of X#. Some of the highlights in these reactions were words like Share, Together, Communication, Generous and Family. We consider the VO and Vulcan.Net community as our family!
And that sort of describes perfectly why we have started to do this:
The community and the future of the XBase Language are our first priority and not the money!
We realize that some of you (or your companies) have invested many man years and many hundreds of thousands of Euros, Dollars or Pounds in the development of your products. Others have invested less, but are just as dependent on the future of their xBase development language.
And now you are confronted with the fact that the product owner of VO and Vulcan.Net (Grafx) is no longer able (and does not want) to execute future development on these products. Also the development of several other XBase alternatives has come to a stop.
- Created: 19 October 2015
Some people have asked us how we are going to write our compiler, and if that is not very complicated.
The honest answer to that question is that it is indeed very complicated, but we use tools to help us doing it, which makes it a little bit easier.
In my previous blog article I have described how we are using the Roslyn infrastructure for a large part of our compiler, and that “all” we have to do is to create a recognizer for our language.
In this article I would like to elaborate a little bit about the language recognition part.
For our language recognition we are using a tool called ANTLR (Another Tool for Language Recognition), written by Terence Parr, a professor from the University of San Fransisco.
This tool allows us to generate a major part of the language recognizer from language definition files. This language definition roughly consist of 2 elements:
- Tokens. These are the sequences of characters that form the Keywords, Identifiers, Constants (Strings, Integers, Floats, Symbols etc.) comments and whitespace in our language.
- Rules. These are the sequences of tokens that form our language.
From this definition the Antlr tool generates classes:
- A Lexer class that scans the source code and builds a list of tokens (the tokenstream)
- A Parser class that uses the rules and scans for the patterns from the language elements. This builds the Parse Tree.
- Created: 13 October 2015
Some people have asked us if we have lost our mind. And that is a very good question:
What they mean is that writing a compiler from scratch is a hell of a job and will take a lot of time.
But we are not writing a compiler from scratch
So we have NOT lost our mind. Let me explain that a little bit:
Early 2015 Microsoft has published the source code for its C# and VB compiler. This is called the Roslyn Project.
Since this source code is licensed under the Apache 2.0 Open Source license we can use and change this code to create our X# compiler.
That means the the biggest part of the code in our compiler has been developed by the geniuses at Microsoft and has been tested by hundreds of thousands of developers all over the world. That is a HUGE benefit for our project.
So it is easy then?
No it is still not easy to write the compiler but a lot of work has already been done.
The following image displays a compiler in a schematic way:
- Created: 25 September 2015
At the Devshare conference in Newent UK Robert van der Hulst has presented the new XSharp Development team:
- Fabrice Foray
- Nikos Kokkalis
- Robert van der Hulst
- And others that want to remain anonymous (for now)
- Created: 09 September 2015
At the DevShare conference in Newent UK, Robert van der Hulst has presented the new XSharp project to the world.
- Created: 28 September 2015
We’ve built it – we can make it better!
Epe: September 28 2015.
We have just returned from a VERY successful DevShare Conference in the UK. Many thanks go to Phil Hepburn, Mike Bertenshaw, Dai Darkin and their spouses Sue and Sue for organizing this great event.
Our new XSharp initiative has received as very warm welcome at the conference, but also raised many questions. We would like to take the opportunity to repeat and answer the most common and most important question over here:
Why do you want to introduce a new compiler / competitor for a small market as Vulcan.NET?