Project

FlexibleParser

Goal: FlexibleParser is a multipurpose .NET parsing library which I have developed completely from scratch in C# (.NET 4.0).

At the moment, it is formed by the following independent parts:
- UnitParser. It deals with units of measurement.
- NumberParser. It extends the default .NET numeric support.

Upcoming parts:
- DateParser, planned to be released by April 2017.
- EquationParser.

Methods: C#, Microsoft .NET, Parsing

Date: 1 July 2016

Updates
0 new
53
Recommendations
0 new
0
Followers
0 new
0
Reads
0 new
59

Project log

Álvaro Carballo García
added an update
I have developed a web API dealing with some of the string parsing functionalities of UnitParser (i.e., UnitP constructor taking just one string argument). Bear in mind that it is assumed to only be used as an easy way to get an idea about what UnitParser can do. UnitParser (and all the other FlexibleParser parts) is always expected to be used locally. Even though I currently don't have plans to remove this API, I might change my mind relatively easily.
 
Álvaro Carballo García
added an update
Additionally to relying on the corresponding Java versions (https://customsolvers.com/en/pages/open_source/flexible_parser_java/) if possible, all the FlexibleParser parts might be used on OSs different than Windows. I have recently added a new repository (https://github.com/varocarbas/FlexibleParser_NonWindows) to my GitHub account including sample codes which clearly show that by relying on two different approaches:
 
Álvaro Carballo García
added an update
There are two new RSS feeds in my main site, in English (https://customsolvers.com/en/rss/) and in Spanish (https://customsolvers.com/es/rss/). I am planning to refer there any relevant issue about my activity, including anything related to this project.
 
Álvaro Carballo García
added an update
You can already read a new article about NumberParser (.NET/C#) in https://www.codeproject.com/Articles/1216825/NumberParser.
 
Álvaro Carballo García
added an update
After lots of delays, I have finally found the time to write the varocarbas.com pages about the DateParser code: https://varocarbas.com/date_parser_code/.
Why having delayed so much writing a so small text?
  • Firstly and as explained many times already, the much-tougher-than-planned QuickSearch development didn't let me too much available time for my remaining public activity.
  • Other relevant issue is that this writing wasn't strictly required as far as the code is quite well structured/commented (+ directly testing/analysing it is the best way to get a proper idea about DateParser) and, unlikely other FlexibleParser parts, there isn't really too much to say about it.
  • Additionally, this first version was expected to be notably improved by a second one (honestly, I wasn't fully aware about all the complexity associated with time zones until getting fully stuck into it during the development) which had been systematically delayed for multiple reasons (deciding to develop the Java versions for all the FlexibleParser parts and the aforementioned problems with QuickSearch), but which I have been kind of thinking about doing at different points. In any case, my plans are different now: I will not care about that eventual relevant improvement of DateParser until after having released its Java version and QuickSearch 1.0.
 
Álvaro Carballo García
added an update
I have submitted an article about UnitParser to codeproject.com, which you can read in https://www.codeproject.com/Articles/1211504/UnitParser.
There you can find a relevant amount of information about its code which I haven't written anywhere else. Although it refers to the original .NET/C# version, most of these new ideas are quite generic and can also be useful to understand better the Java code.
 
Álvaro Carballo García
added an update
You can already download from the corresponding repository in my GitHub account (https://github.com/varocarbas/FlexibleParser_Java) the code, binaries and related resources of:
  • NumberParser Java 1.0.8.5 (equivalent to the same .NET version).
  • UnitParser Java 1.0.9.1 (equivalent to the .NET version 1.0.9.0).
During the next few days, I will be updating all the remaining online references.
 
Álvaro Carballo García
added an update
The Java version of UnitParser is already available in the Free Software Directory: https://directory.fsf.org/wiki/UnitParser_(Java). Note that the original .NET/C# version cannot be included there due to the fact that the .NET Framework isn't considered a valid free-software alternative.
REMINDER: even though this Java version is assumed to be identical to the last .NET one (v. 1.0.9.0), there are some issues which have to be fixed. I am planning to release the corrected version (1.0.9.1 still equivalent to 1.0.9.0 in .NET) within the next days.
 
Álvaro Carballo García
added an update
I have to further delay the new Java version of NumberParser (+ UnitParser) due to a new unexpected Java-C# difference: (Java) double vs. (C#) decimal precision.
Even though I was perfectly aware about the notable precision lag between both types (even C# double); the last tests have been proven it to be much more relevant for NumberParser than I was expecting. There are various parts of NumberParser which are fully maximising the high decimal-type precision and where the transition to double is particularly problematic.
As said since the start, I want to make these Java versions as similar to the original C# ones as possible, but by accepting the differences between both languages (+ the fact that all these libraries were originally developed to fully maximise the .NET peculiarities without even considering the option of migrating them to a different format). That's why I am not aiming to reach an almost-similar-to-C# performance on this front as far as fully developing a new high-precision numeric type for Java is certainly outside my plans. In any case, I do expect to somehow correct the default behaviour (i.e., the one resulting from a direct conversion C# to Java) such that the Java versions have a reasonably similar performance in reasonably simplistic scenarios.
All the C# code is already converted. I just have to do some tuning and come up with some optimisation under certain conditions. It is certainly not too complex, but it would take me more time than original expected. And the main problem is my intention of fully-focusing on the QuickSearch development during the current month. So, I have to convert these slightly-time-consuming tasks into a secondary priority and, consequently, the release of the new Java versions will not be ready by the current week as expected, although it should be quite soon anyway.
BTW, you can already download the new C# NumberParser 1.0.8.5 from the corresponding GitHub and NuGet repositories (I will update the customsolvers.com and varocarbas.com versions in some hours). Note that this version is a direct result of the aforementioned C#-to-Java conversion, where I had to review the whole original code and spotted some problems. This new version only includes fixes for secondary bugs and slight performance improvements; it does represent a new milestone within the NumberParser reliability evolution though.
 
Álvaro Carballo García
added an update
I am still having tons of over-work and my FlexibleParser plans are also a bit delayed. But within the next week, I am planning to have ready:
  • New Java version of NumberParser.
  • Updates in the Java version of UnitParser to synchronise with the common structure for all the Java parts (i.e., getters and setters).
  • New .NET/C# version of NumberParser including the (honestly, not-too-relevant) corrections resulting from having reviewed the whole code while converting it to Java.
I will also be gradually updating the associated resources (customsolvers.com pages, repositories, etc.); and even expect to take care of the pending varocarbas.com pages about DateParser (what I have been delaying for way too long already). But the DateParser conversion to Java will have to wait a bit, because my top priority for September is to release the first version of QuickSearch.
 
Álvaro Carballo García
added an update
I am currently working on the Java version of the second FlexibleParser part (NumberParser). This is an excellent excuse to review the original (not precisely simple) C# code, what is likely to output some corrections.
In case of adding relevant enough improvements, I would release a new .NET NumberParser version; what includes: new NuGet package, new DLL/XML in customsolvers.com & varocarbas.com and even new zenodo.org DOI. But I will not perform this whole process for minor improvements as far as it is a bit tiring/time-consuming.
Bottom line: the last official (.NET/C# & Java) versions of all the FlexibleParser parts are completely up-to-date. The binaries/docs generated by the code in the main repositories (https://github.com/varocarbas/FlexibleParser & https://github.com/varocarbas/FlexibleParser_Java) might be slightly different (= better) though.
 
Álvaro Carballo García
added an update
After a curious incident a while ago (+ multiple other incidents involving poor understanding and people suddenly coming to completely-unrelated-to-reality conclusions), I have decided to better write this clarification just in case.
FlexibleParser is a generic name referring to a group of independent C# libraries which I have developed completely from scratch. At the moment, these libraries are the following: - UnitParser. - NumberParser. - DateParser.
You can find basic information in the corresponding pages of http://customsolvers.com and more technical stuff in the http://varocarbas.com ones (DateParser still not done, because I have a ton of pending public work and prefer to focus on programming than on writing :)).
I have also started to work on developing Java alternatives for all the last versions. The UnitParser Java version was finished some time ago and I am currently working on the NumberParser one. Note that these Java versions have some limitations due to the differences between C#/Java and the fact that these libraries were precisely built to maximise/extend the C#/.NET features (the idea of converting them to a different language came later).
I have written each single character of all these codes and, similarly to what happens with all my (= Custom Solvers 2.0 = varocarbas = Alvaro Carballo Garcia) remaining public activity, is expected to provide a clear idea about how I work. Do you like these codes/what these libraries deliver? Hire me and I will develop something equivalent for you :)
 
Álvaro Carballo García
added an update
I am currently converting NumberParser to Java (a bit late already, but I have been spending much more time than planned on the looking-very-nice-so-far QuickSearch) and came across a new relevant difference C#/Java.
The first FlexiblePart part which I converted to Java (UnitParser) didn't rely on C# properties/getters-setters at all. I mean that no special action was performed there, other than getting/setting the corresponding value. That's why I plainly migrated all the public fields/properties (precisely defined by having getter/setters) to simple Java variables.
NumberParser relies a lot on C# getters/setters, in the sense of performing diverse actions when the value of a given property is being updated. Java doesn't have that functionality. Also I don't want to over-complicate things and am trying to respect the original code/functionalities. That's why I will be relying on the Java convention of including public getVariableName/setVariableName methods; and the future users are expected to rely on them to get/set values of public variables.
The main reason for highlighting this issue before the new NumberParser Java version will be released (not sure when, but hopefully by this month) is to warn users of UnitParser (Java) that I will be releasing a new version (again, not sure when) including also the aforementioned methods. As said, UnitParser doesn't strictly need any of this, but I will include it anyway for consistency and to ease the use of all the FlexibleParser parts (i.e., users always able to rely on this approach without thinking whether it is required or not in the given scenario).
 
Álvaro Carballo García
added an update
As explained in various places and at different points, I have had to delay my original DateParser plans due to my current public-work overload: conversion to Java of all the C# FlexibleParser so far (including DateParser), development of QuickSearch and varocarbas.com domain ranking improvements (including adaptation to the new QuickSearch).
Initially, I was planning to release a relevant modification of the first DateParser version to maximise the (unexpectedly complex) timezone aspect. That's why I have been delaying the varocarbas.com related pages where the DateParser code will precisely be explained.
Due to the aforementioned over-work, that relevant DateParser modification will be released much later than planned (perhaps by August 2017?). I will better write a varocarbas.com-documentation version for the current code (within the next weeks) and modify it after that relevant update is released.
And the worst part: this is 100% unpaid over-work! (good opportunity to remind that I, Alvaro Carballo Garcia, am the sole author of each single bit anywhere, anytime done by Custom Solvers 2.0 or varocarbas) The worst kind of over-work! LOL. Just kidding. It is unpaid very stimulating and required over-work. It isn't precisely ideal, but neither too bad.
 
Álvaro Carballo García
added an update
FlexibleParser Java documentation
I have finished what, for the time being, will be all the documentation for the Java version of UnitParser (+ upcoming FlexibleParser conversions):
As suggested in these pages, you might also want to take a look at the much more relevant resources of the .NET/C# version (e.g., the video showing the main UnitParser features https://www.youtube.com/watch?v=8LJptIg3Z4Y).
I am planning to finish the conversion to Java of the second (NumberParser) and third (DateParser) parts by next month. Afterwards, I will start working on the promised relevant modification of DateParser (the pending http://varocarbas.com pages about this part will be finished by the current month).
 
Álvaro Carballo García
added an update
Part of the Java UnitParser code which some people mind find interesting
My intention since the start was to write a code as similar to the original C# version as possible, although always by accepting the differences between both languages and eminently focusing on creating a programmer-friendly structure.
One of the most interesting consequences of the aforementioned paragraph might be the code inside the package CSharpAdaptation (https://github.com/varocarbas/FlexibleParser_Java/tree/master/all_code/UnitParser/src_Internal/InternalUnitParser/CSharpAdaptation); mainly the code in the class Linq. This is just a group of helpful-for-the-conversion approaches which I came up with pretty much on the go, but I am sure that some C#/.NET/Java programmers might find them useful.
 
Álvaro Carballo García
added an update
Java version of UnitParser already available
I have already uploaded the first Java code of the last UnitParser version (UnitParser.dll v. 1.0.9.0) to the new FlexibleParser_Java repository:
Its functionalities are very similar to the ones of the original C# versions, although not identical (intrinsic limitations of Java). The best way to get a quick idea about these differences is by comparing the corresponding test codes: https://github.com/varocarbas/FlexibleParser_Java/blob/master/all_code/Test/src/Parts/UnitParser.java and https://github.com/varocarbas/FlexibleParser/blob/master/all_code/Test/Parts/UnitParser.cs
The file/folder structure of the new Java repository is also quite different (again, a forced decision provoked by the Java peculiarities), although no person interested in understanding the code should find any problem on this front.
I will be adding some further references to the repository and to my sites during the next weeks. In principle, I am not planning to create a relevant amount of specific documentation and references for the Java version.
 
Álvaro Carballo García
added an update
New versioning system for FlexibleParser
I have created new DLLs for all the FlexibleParser parts so far (UnitParser, NumberParser and DateParser), which can already be downloaded from the usual places (customsolvers.com, varocarbas.com and the corresponding nuget.org / zenodo.org pages).
All the new versions are identical to the previous ones, except for UnitParser.dll where I have fixed a minor bug (and with minor I mean that it is quite unlikely that anyone using this library will be ever dealing with that scenario).
I have taken advantage from the upcoming release of the Java versions (the first one, UnitParser, will be ready within the next few days, just check my GitHub account or the updates which I will be writing here) to put a bit of order in the honestly-too-messy versioning structure so far. From now on, the following rules will be applied:
- All the versions will be numbered from 1.0.7.0 (or the sounding-identically-at-least-to-me 1.0.7000 of the associated NuGet package) upwards. Logically, the higher the number, the better the given DLL file.
- All the parts will be numbered independently upon each other. Right now, the versions are: 1.0.9.0 (UnitParser.dll), 1.0.8.0 (NumberParser.dll) and 1.0.7.0 (DateParser.dll). The FlexibleParser version will be given by the average of all the constituent-part versions.
- Equivalent version numbers will denote similar quality. In principle, the older versions are likely to continue being better, although I might spend more time on a newer part and provoke its version to grow beyond an older one. BTW, I will deliver the relevant modifications which I was expecting to do in DateParser later than planned, because I will be firstly focusing on finishing all the conversions to Java.
 
Álvaro Carballo García
added an update
Sample limitations of the upcoming Java versions of FlexibleParser
Even though I am trying to mostly focus on actually-knowledgeable people and these library are precisely meant to be used by programmers (presumably knowledgeable enough), I will better put some examples to help understand what I meant in my previous post with similar enough version.
  • All the FlexibleParser parts are eminently focused on the .NET decimal type. This is a non-floating point rational (or decimal if you prefer) numeric type with no equivalence in Java. I will replace it with double.
  • All the FlexibleParser parts are very user-friendly and, for example, the main classes include overloaded operations like addition or subtraction and LINQ-friendly implementations. Nothing of this is possible in Java either. I will replace the operator overloads with methods (e.g., rather than class1= class2 + class3, class1 = Var.AddClass(class2, class3) ). System.Linq only makes sense within the .NET Framework, so this issue is completely out of question.
  • Another relevant difference between Java and .NET is the way in which they manage resources (i.e., projects, files, folders). If you look at the C# code of any FlexibleParser part, you would see a nice structure also at the file/folder level. It is completely impossible to create a Java library with similar structure and with equivalent performance (hint: .NET languages don't care about folders, but Java does).
As said, all these libraries were (and will continue) targeting the .NET Framework and, under ideal conditions, it wouldn't even be recommendable to move such a complex code to a different language. On the other hand, the whole point of FlexibleParser is to show my programming skills (ideally, to a knowledgeable and actually-caring-about-what-matters-rather-than-about-abstract-nonsense audience; by the way, this reality also seems too confusing for some individuals: the whole value of FlexibleParser, equivalently to all my other online codes, is just to show my coding skills in its widest sense). Converting this code to Java is a good excuse to practice a bit a language which I don't use much lately, to allow a wider audience to easily approach my code and to give some support to my the-exact-language-doesn't-matter-much-for-an-experienced-programmer claims which seem to be less evident than what I thought (or better: lots of abstract-talking-really-saying-nothing-and-convinced-that-their-clueless-opinions-make-sense idiots everywhere).
 
Álvaro Carballo García
added an update
FlexibleParser in Java
I am already working on porting all the FlexibleParser parts so far (i.e., UnitParser, NumberParser and DateParser) to Java. These libraries will continue being eminently focused on C# (.NET) and the new versions should be seen as mere code migrations trying to replicate those original versions as well as possible.
Although C# and Java are very similar languages, they still have notable differences in certain parts; this issue is especially relevant when dealing with libraries whose main focus is precisely improving (certain aspects of) the .NET Framework. That's why an almost-exact copy of the original C# code will not be possible. In any case, these new versions are expected to be similar enough to the original ones such that Java and .NET programmers shouldn't find important differences.
I will be uploading all the new parts to my GitHub account during the next weeks (+ while also finishing the pending bits of the DateParser documentation).
 
Álvaro Carballo García
added an update
Digital object identifiers
Additionally to the main copies in the FlexibleParser repository of my github.com account, I keep other (eventually-adapted-to-that-part) copies of the C# source codes of all the FlexibleParser parts in zenodo.org. All of them are associated with a unique DOI.
At the moment, the last versions of these DOI copies are the following:
 
Álvaro Carballo García
added an update
DateParser video
A video showing the most distinctive features of DateParser is already available in my Youtube account (https://www.youtube.com/watch?v=E2JT2w66uyc).
 
Álvaro Carballo García
added an update
New DateParser version available
You can already download DateParser.dll v. 1.0.6337.38019 from the usual sources (https://customsolvers.com/downloads/flexible_parser/date_parser/, https://varocarbas.com/downloads/flexible_parser/date_parser/ and https://www.nuget.org/packages/DateParser/), where the previously-referred problems with VS 2015/2017 aren't present anymore.
Note that I am planning to include detailed explanations about this incident in some of the upcoming online documentation, most likely in the more technical varocarbas.com parts.
 
Álvaro Carballo García
added an update
DateParser problems with VS 2015/2017
I have realised that there is some issue (bug, in my opinion) with the new Visual Studio versions that provokes DateParser to trigger errors under certain conditions. To know more about it, you can take a look at this video (https://www.youtube.com/watch?v=d__lXHqmPFE) or at the issue I have submitted to the Roslyn repository to let Microsoft know about it (https://github.com/dotnet/roslyn/issues/19346).
Regardless of the fact of being a bug or not, I will release a new version of DateParser working fine on all the VS versions. I guess that during the next days, note that this has been some kind of unplanned "surprise". In any case, bear in mind that you can use the current version of DateParser everywhere by always instantiating a TimeZones variable before performing any other action. You can take a look at the test application (https://github.com/varocarbas/FlexibleParser/blob/master/all_code/Test/Parts/DateParser.cs) which has a working-everywhere-fine order.
 
Álvaro Carballo García
added an update
More DateParser updates
 
Álvaro Carballo García
added an update
DateParser released
You can already take a look at the DateParser (third part of FlexibleParser) code in the corresponding repository of my GitHub account (https://github.com/varocarbas/FlexibleParser).
I will be performing some minor corrections (mostly code commenting) during the next week, also some writing like the readme file and further references (I guess customsolvers.com info and/or the video). In any case, it will still take me some weeks to finish all the references and documentation.
Although this version is already quite stable, I am planning to perform important modifications within the next 1-2 months. Honestly, I wasn’t expecting a so huge amount of information associated with timezones and want to adequately maximise all this.
 
Álvaro Carballo García
added an update
DateParser's timezones
You can already take a look at the (classification of) timezones with which the to-be-released-this-month DateParser will be dealing:
 
Álvaro Carballo García
added an update
New NumberParser version
You can already download it (NumberParser.dll v. 1.0.6302.28051) from customsolvers.com, varocarbas.com, its GitHub repository or via its last NuGet package. Its DOI is 10.5281/zenodo.439942 (https://zenodo.org/record/439942#.WOKLpFV96po). Note that I have also updated the FlexibleParser DOI by including this and the new UnitParser version: 10.5281/zenodo.439945 (https://zenodo.org/record/439945#.WOKMblV96po).
Improvements with respect to the previous release:
  • NumberX constructors accepting UnitParser's UnitP as argument.
  • Minor performance enhancements, mainly in NumberD and NumberO classes.
  • Minor corrections in some of the Math2 methods which emulate the .NET System.Math ones.
  • Fixing of some minor bugs.
 
Álvaro Carballo García
added an update
New UnitParser version
You can already download it (UnitParser.dll v. 1.0.6301.23655) from customsolvers.com, varocarbas.com, its GitHub repository or via its last NuGet package. Its DOI is 10.5281/zenodo.43729 (https://zenodo.org/record/439729#.WOFHuFV96po).
Improvements with respect to the previous release:
  • UnitP constructors accepting NumberParser's NumberX (Number, NumberD, NumberO or NumberP) arguments.
  • Minor enhancements in some UnitP constructors (e.g., separating blank spaces not required anymore).
  • Minor improvements in main classes (e.g., IComparable and implicit operator support).
  • Fixing of secondary unit parsing bugs.
 
Álvaro Carballo García
added an update
Upcoming compatibility among main types of different parts
From now, there will be some compatibility among the main types of the FlexibleParser parts, but without affecting their independence. For example, it will be possible to write a C# code like UnitP newUnitP = new UnitP(new Number(1.23m));, which instantiates a UnitParser variable by relying on a NumberParser class.
By next week, I am planning to release new versions of all the parts so far (i.e., UnitParser and NumberParser) supporting these new functionalities.
 
Álvaro Carballo García
added an update
UnitParser's compound types
A list with the basic constituent of all the compound unit types accounted by UnitParser is already available in https://varocarbas.com/flexible_parser/raw/compound_types/.
 
Álvaro Carballo García
added an update
UnitParser's unit conversion raw data
Tables including basic classifications of the main UnitParser units are already available in https://varocarbas.com/flexible_parser/raw/unit_conversion/.
 
Álvaro Carballo García
added an update
Main URLs
All the FlexibleParser parts are open source (public domain) and their main information is stored in the following URLs:
 
Álvaro Carballo García
added a project goal
FlexibleParser is a multipurpose .NET parsing library which I have developed completely from scratch in C# (.NET 4.0).
At the moment, it is formed by the following independent parts:
- UnitParser. It deals with units of measurement.
- NumberParser. It extends the default .NET numeric support.
Upcoming parts:
- DateParser, planned to be released by April 2017.
- EquationParser.