xsharp.eu

Matt,

You'll be able to contribute in a few weeks. After finishing the current build I will add function prototypes for all the functions from the list to the source and I will also create a xml file for the documentation of these functions.
I'll write a small tool to extract the documentation from the VFPX help project (will give them credits of course) so we can fill the help fairly quickly.
After that you can start filling in functions, either by copying the implementation from the toolkit or by writing it yourself.

Please give me a few weeks (let's say Jan 1st) to set this up.

Robert

Robert - this is GREAT news. The run time functions are the most trivial part of this, and once you've laid the framework in place for this to unfold, I think it is fair to make at least a few community people get on board to help out in this area so you gurus can work on the really hard parts.

Once you make give the word, I'll tackle one or two myself, and then after we get a cycle under our belt from that exercise, we can decide how wide we want to cast the net to see if one or two others are needed to join this task. I'd love to tackle as much of them as possible myself, but I'd also like to see a couple of other VFP folks get involved at this level too.

robert wrote:Matt,

You'll be able to contribute in a few weeks. After finishing the current build I will add function prototypes for all the functions from the list to the source and I will also create a xml file for the documentation of these functions.
I'll write a small tool to extract the documentation from the VFPX help project (will give them credits of course) so we can fill the help fairly quickly.
After that you can start filling in functions, either by copying the implementation from the toolkit or by writing it yourself.

Please give me a few weeks (let's say Jan 1st) to set this up.

Hi Robert,
few things from my side. The implementation of vfp is not always in sync with the vfp docs - I think xSharp.vfp should target the behavior of vfp9 SP2 and reflect true behavior implemented in new docs as addition.
Also more than a hint on what the ideal implementing looks like.would be helpful. My own idea is that code in dialects should best be built upon code already in core, to keep code DRY and runtimes small. In some cases like the just*, force* functions it might be best to move them into core and base further, more complicated functions upon them, .
I have also looked at the Dotnet kit - maybe my dumb luck, but very first mini function had erroneous implementation.Also: are you planning for a test suite based on a function table with test code or wait for users to find differences?
Not as much fun as coding, but necessary if others not knowing the conventions probably automatic in your group start adding to vfp dialect.
my 0.02€
thomas
P. S. DBC events missing currently in the list - should be at the far end to be implemented, but listed. Even better would be a single event implemented as example as soon as DBC is accessible, so that in case another event is needed, one can follow the lead.

Robert,
both execscript and compile are both listed as not targeted.
Generating code snippets or copying/concatenating memo fields is not that uncommon in vfp apps. I thought Rosslyn supports compile as service - ability to add such snippets in runtime is nice, for instance to deploy rule engines configuring themselves or after user input. Doable in pure compiled code as well, but more elegant if not pre-creating all possible permutations.
regards
thomas

Thomas,
You are right, Roslyn provides that. We also have "X# Sscript" support, but the scripting does not support dialects yet (so it runs in pure X# Core).
I'll discuss with Nikos if we can add dialect support in the scripting engine. When we can then we can certainly support compile() and execscript().

Robert

Thomas,
If the behavior of VFP differs from the docs, then we most certainly need support from VFP experts.
I did not include DBC in the list at all. Of course we want to support that, and DBC events are part of that.
But we'll probably need some help from VFP experts in this area as well.
And yes, we plan a test suite.

Robert

Robert - any idea when you will experiment with proof-of-concept/approach to native VFP SQL with Join and Where clauses?

Plus, the Rushmore optimization aspect of native SQL Queries.

Example:
.
Remember, in FoxPro, these DBFs do not have to be open first... If there is no Alias already alive with these table names, VFP will do a USE to open the DBFs, and leave them open.

If no "INTO CURSOR" statement is included in the query, then the result of this query will live in a new work area named 'Query' and it will be the currently selected Work Area. The DBFs are left as USED in the environment, even if they were not opened beforehand.

Matt,
I have an idea but I am not ready to share that yet. I don't want to raise expectations that I can't fulfill.

Robert

robert wrote:You are right, Roslyn provides that. We also have "X# Sscript" support, but the scripting does not support dialects yet (so it runs in pure X# Core).
I'll discuss with Nikos if we can add dialect support in the scripting engine. When we can then we can certainly support compile() and execscript().

Hi Robert,
thx for quick confirm of basic possibility.
When you meet in Athens to discuss progress path to take implementing next features, please try to get away from current near-binary scale of supported(perhaps with different parameters) to a scale reflecting support status (perhaps asking for testing of specifics) and guesstimate of priority if not already supported. I am NOT asking for a detailed function-after-function plan, only groupings you will go at as milestone definitions for example
- Buffering-Tableupdate (pretty please
- Class definitions
- GUI
- Report
and so on. Gives a better picture to us and option to implement stop-gap patches ourselves if we foresee a need and such groupings should be easy to add to a certain table describing language elements.

regards
thomas

robert wrote:If the behavior of VFP differs from the docs, then we most certainly need support from VFP experts.

Nothing earth-shattering, but a few edge cases not touched in docs as they are written to be read, not used as implementation guide and known to us by expirience. Fine-tuning to be done when the functions are all done - then we can ask for effort over at "our" watering grounds to sieve out the things Matt, Antonio, Dragan and the other vfp-ers already testing the waters here missed.

I did not include DBC in the list at all. Of course we want to support that, and DBC events are part of that.
But we'll probably need some help from VFP experts in this area as well.

DBC is needed early on for long field names. RI support also in DBC as standard, but many skip RI via DBC as it is not elegant.Field captions and validations sometimes used. DBC events I used only seldom - most of the times to do things declared impossible by others...

And yes, we plan a test suite.

Good. Currently fun to play with xSharp, but not efficient use of time

regards
thomas