An Observation

[John R. Heathcote]

To All:

First, the good news.

The enthusiasm for this project is overwhelming. I'm just now catching up on the latest discussions, observations, implementations and questions from the forum. The level of expertise shown in the forums leads me to believe that the VB2PB conversion project will be a success.

Now the bad(?) news.

I have yet to read any sort of document that outlines the functionality and capabilities of the first version of the converter, what it will do and what it won't do, however I have not completely read everything in this forum so if this type of document has been posted please accept my apologies for my rant. If this document has not been prepared then I would submit it is time to do so now before we all get bogged down in the minute details of the project and we lose focus on what we are trying to do. While all of the questions and observations are certainly valid, it makes me wonder exactly what functionality will be included in the first version of the converter.

If the converter will handle only half of the comments and suggestions made in the forum then that is 50% of my recoding efforts I do not need to do. So I do think we have enough functionality discussed to apply to the version 1 of our converter.

Some of my own suggestions and questions.

Is it absolutely necessary to parse and convert everything on the fly in one pass? IMHO, so what if it takes 1.3 seconds (as Data said, "...an eternity for an android") to convert a VB project to PB in multiple passes. I will take that 1.3 seconds over the weeks of coding I have to do now to convert my VB project to PB.

So instead of attempting to do everything in one pass why not multiple passes? Each pass concentrating on the conversion issues it does best. For example, simple reformatting of VB statements like "Debug.Print" could easily be converted over to its PB equivalent "#DEBUG PRINT". So lets do those types of conversions first before tackling the tough stuff.

Keep it simple, break down the source code line.

For example, Mr. Harris mentions:

but here is what has me scared...

& strFunction(strAnotherFn(strPar1, strPar2), iNumber) & ......

Yes, this is kinda scary, but do we have to parse this statement in one line, or could we write a preprocessor to simplify the above line to:

sTmpStrVar01 = strAnotherFn(strPar1, strPar2)

& strFunction(sTmpStrVar01, iNumber) & ...

Source code functionality and intent is still the same, but the above two lines of code resulting from the simplification process would be easier to parse and convert IMHO.

In my past dealings with automated methods of writing source code it is preferable to simplify the original source code statement to its absolute simplest form until you cannot break it down any further, if at all possible, thereby making it easier to locate, identify, and output a corresponding source code line in another language.

Keep to the convention of allowing only one functional statement per line, being an old FORTRAN IV and FORTRAN 77 guy I have no problem coding this way as both of the FORTRAN compilers (the ones I used anyway) forced this coding standard on the user.

Just some thoughts.

[Rodney Hicks]

So I do think we have enough functionality discussed to apply to the version 1 of our converter.

I think so as well.

There has been a lot of work done, and any effort is appreciated more than we say.

There has been a lot written and you'll find you have to glean little bits here and there about intentions but once you've done that the pieces should fit together for us.

Rod

[Brian Chirgwin]

Is it absolutely necessary to parse and convert everything on the fly in one pass? IMHO, so what if it takes 1.3 seconds (as Data said, "...an eternity for an android") to convert a VB project to PB in multiple passes. I will take that 1.3 seconds over the weeks of coding I have to do now to convert my VB project to PB.

No, I think a multi-pass parser is fine and might even be requried. I also think if it takes an several days to convert an application it is fine if it works. We can modify it to improve performance of conversions.

Here is why.

I've been thinking about variants. Some people are lazy and use variants, but the datatype is always the same. This can be determined in most cases (maybe not all).

Dim vName as variant

vName = "Brian" ' String

vName = txtName.text ' String

If these were the only two uses of vName, we could reasonably make vName a String in the PB code.

This requires at least two passes through the code (well it could be done in one and insert variable declarations into the code after the first pass is completed).

I think I raised more questions and didn't really answer yours.

Brian Chirgwin

[Rodney Hicks]

I think I raised more questions and didn't really answer yours.

It seems to get that way with VB, some sort of circular reasoning or something, tangential perhaps.

I would think that several passes could even be in order, we aren't limited by some arbitrary restraint. Once version 1 is operating, refinements can be slipped into version 2. Just exactly how Stan is progressing I haven't looked at as my focus is on matching terms, so he will be the ultimate consolidator of thought.

Rod

[StanHelton]

John,

You mentioned a utility that orders types & functions. Would you mind posting that? I'm working on the Tokenizer now and something like that would be very helpful.

Rod,

Have you had a chance to look at the combined DictionaryTools code I posted? It compiles in PB 8.04 and includes both the uploader and the editor in one package.

Elias,

Are you back yet? I would like to discuss some of the back end concepts with you ASAP.

Brian,

I've started a branch in the SVN for the CodeLineParser. Please check me out and see if I've done it properly.

Everybody,

Our working concept right now is four basic modules. 1 is the parser. I think it's best if all it does is parse. I've borrowed from the code Fred and Chris left us, but not too much.

2 is the tokenizer. Most of what Fred and Chris did is going in here.

3 is the DataDictionary. The code I posted for DictionaryTools is the basis for this. We're going to use Rod's format for the terms in this dictionary. It will be necessary to create a few other data files relating to functions and objects and such, but right now let's focus on getting something that works on the simple stuff.

4 is the BackEnd. This is where the Tokenizer output is converted to actual working PB code. We've discussed using wrappers to convert the more difficult stuff into PB and I think this is the simplest way to go for now. Elias was excited about doing this work and I plan to have a one-to-one with him as soon as he's back for the project.

I know this is short, but it's the conceptual framework you guys are talking about. We've identified a lot of issues and hopefully most of them will be handled as we move through the process of developing these four main modules. Right now I'm working on the KISS principle.

Any questions and/or discussion is welcome. As always I'm open to better ideas, especially if they keep us from reinventing any wheels!

Stan

[Brian Chirgwin]

Stan: Svn

John,

I've started a branch in the SVN for the CodeLineParser. Please check me out and see if I've done it properly.

Stan

Stan the only thing I notices is that you added \tags\test cases\VB6 Test Source\objects. It should be added (copied) to trunk. I don't see anything for CodeLineParser. If you haven't done so make sure you perform a commit. IF you added files, they aren't added until a commit is performed. Right Click the folder and perform SVN Commit...

To reiterate:

Trunk - the latest working code. Only you and I have access to add code to trunk at least for the time being. I believe we will open this up to others over time. This code is working code. No one should add code here that fails to compile or has bugs. Keep non working code/code under development in a branch. The reason behind this is developers should be able to update their source with the trunk and know it will compile without error. Multiple developers should not have to spend time fixing the same errors in the trunk.

Branches - This is where developers should add code in development. Once to a finished or milestone state, report to Stan or Brian and we will copy it to the trunk (Confirming it works). Make sure to mention the revision # to copied to the trunk.

Tags - Tags are for releases or milestones. Anyone can create a tag at anytime. A Tag is basically a labeled version of source (i.e. Release1, beta 1, etc...) Tags are not modified, create a branch.

By the way there is no difference in the way SVN works in the three directories(Trunk, Branches, Tags). In fact I created this structure when setting up the repository. The difference is just how the areas are used.

If anyone has questions on SVN post it to the forum, but also send me a Private message (Brian Chirgwin).

[Rodney Hicks]

I have looked at the new program and it seems more than adequate. I haven't done much but look at the file,compile,run, but I'll give it a work out later this evening.

Rod

[John R. Heathcote]

Rodney,

There has been a lot written and you'll find you have to glean little bits here and there about intentions but once you've done that the pieces should fit together for us.

The problem I have with this philosophy is the "...little bits and pieces" keep changing to accommodate the, "Gee, wouldn't it be cool if the converter did THIS", syndrome. I think a specific doc should be prepared that defines, justifies, rationalizes the current functionality we wish to put in the converter and why.

It seems to get that way with VB, some sort of circular reasoning or something, tangential perhaps.

Have no argument with that. PB in this respect is much more straight forward to understand.

Stan,

I'm cleaning up the utility right now, will send it to you ASAP.

[Rodney Hicks]

The problem I have with this philosophy is the "...little bits and pieces" keep changing to accommodate the, "Gee, wouldn't it be cool if the converter did THIS", syndrome. I think a specific doc should be prepared that defines, justifies, rationalizes the current functionality we wish to put in the converter and why.

There were attempts to do just that, but working with volunteers that are used to working by themselves requires a lot of patience. You are not wrong, and attempts have been made to acquire that kind of focus, which alienated some. At this stage of the game, consult closely with Stan and I think you'll find we are getting close to what you seek.

There will always be knew ideas that come out of our progress, and keeping them on the back burner until the original concept is a reality would be nice. Sometimes though we need a little change of pace and wandering off into one of those ideas for a while gives a break.

Rod