- Created: 14 December 2015
We are pleased to announce that Alpha build 0.1.4 has been uploaded to the downloads area on this website.
Most of the issues reported by our FOX subscribers have been fixed in this build.
Some of the changes in this build:
- Several changes to allow calculations with integers and enums
- Several changes to allow VO compatible _OR, _AND, _NOT an _XOR operations
- Fix interface/abstract VO properties
- Insert an implicit “USING System” only if not explicitly declared
- Error 542 turned to warning (members cannot have the same name as their enclosing type)
- Changes in the .XOR. expression definition
- Fix double quote in CHAR_CONST lexer rule
- Allow namespace declaration in class/struct/etc. name (CLASS Foo.Bar)
- Fix access/assign crash where identifier name was a (positional) keyword: ACCESS Value
- Preprocessor keywords were not recognized after spaces, but only at the start of the line. This has been fixed.
- Created: 04 December 2015
In this message I would like to share with you some of the progress that we have made with the X# project, and especially the progress with the new compiler.
We have planned to release the first public version of the compiler in the first quarter of 2016 and we are very much on schedule. In fact I think we are a little ahead of schedule.
Most of the new language features that we have on our list for the X# Core dialect are working, and the code generation has proven to be of excellent quality. Our choice to build the new compiler on top of the Roslyn architecture has proven to be an excellent choice. It has taken some effort, but we are getting there. At this moment almost all “valid code” compiles and runs perfectly. We are now focussing on the level of handling incorrect code and producing meaningfull error messages. We are also focussing on some of the areas where the Xbase language is quite different from the C# and VB languages where the Roslyn architecture was written for.
As proof that the compiler is working we have uploaded a few examples (both source, EXE and PDB) that you can test on your own machine.
- Created: 30 November 2015
We have just uploaded Alpha build 0.1.2 to this website. It is available for download for FOX subscribers.
A summary of the changes in this build can be found in the Announcements forum on this website
If you are interested to test this build and you have not subscribed to the FOX program yet, then please go ahead and scubscribe today.
- 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.