Task Assignments

[StanHelton]

2008/06/24

Our conceptual planning is done. We need to focus on building the actual modules. I'm uploading the official System Flowchart and I don't see any significant changes before we reach first release.

Elias has suggested that we divide the necessary modules between us for coding at this point. That's a good idea! He's working on some procedural protocols for us back-end coders now.

Here's the way I think we'll get the most out of our various skill sets.

Chris -- front end design. Need clear differentiation between the parser and the tokenizer (unless I missed it somewhere - good possibility ). Rod's list of terms might be very helpful here.

Rod -- compiling a list of comparative Terms. Doing a very good job digging the VB terms and tagging the appropriate PB terms. Along with the simpler method of parsing our job on the back end will be much easier. (I've uploaded a tool to build the list into a PB random file with a simple review function in the SourceCodeOnly thread.)

Elias -- We're working out out we will divide the back-end modules between us. Once that's done Elias and I start work on some back-end DLLs.

Stan

[Elias Montoya]

As i was trying to figure a way to split the tasks/modules and put what we already
have in an evenly distrubuted, i noticed that there are some tasks that should be shared.

But at the same time they require a work made as if it was 1 sungle person, this meaning
we will need lots and lots of sinchronization...

Im not sure if it would be best to divide tasks in LOTS AND LOTS of tiny asignations, or... create 4 main categories and let everyone focus on 1 of them... each has its strenghts and weaknesses...

for example if we take a separate module each, we will require the ork of someone else
to be already complete to continue with ours... not letting us work even if we are ready while we wait for someone else.

If we split tasks in tiny parts, will be a little slower, and we might not be able to see the
working thing until everything is ready.

Anyway... im almost ready with my part, and we still can change our minds if ew need to later.

For now, the separate modules (Each point is a separate task) that i think would be convenient to split would be....

The Front End

• Front end capable of running plugins, the basic options included.
• DLL for visually modify controls.
• DLL for the Code editor advanced tasks.
• DLL, for Custom options. (ill explain later)

NOTE: It would be good if we could habe all this in one single exe, but lets not be greedy.

The Converter

• DLL for Preprocessor. A dll that might give the first pass to check for errors, correct some of them, as well as replacing some known code with pre-coded source code (wrappers if you will).
• DLL for VB source organization. Some VB code IS messy, this dll can look for better ways to organize code before the first convert step.
• DLL for EQUATE, TYPE, VARIABLES and DECLARATIONS conversion.
• DLL for modules, this dll can place the VB code in the respective PB place, for example, converting private modules into SUBS and FUNCTIONS.
• DLL for events, Mouse clicks, keystrokes, and such can be put in the respective WM_***** location here.
• DLL for Code. This dll can translate the rest of the things like... DATA blocks, FOR/NEXT, IF/ENDIF, SELECT CASE... ETC... this involves EVERYTHING ELSE.

* NOTE, when all the modules are ready, we can merge them all in 1.

The Plugins

• This is what im thinking the best way of doing, i am thinking the plugins should contain some options to be read by the front end, and controlled from there. Ill post the suggested protocol/standard calling convention, same for all.

I believe this is consistent with what we already have, we just sould have to tear the code apart and place it in the right DLL.

Comments?

[StanHelton]

As i was trying to figure a way to split the tasks/modules and put what we already
have in an evenly distrubuted, i noticed that there are some tasks that should be shared.

But at the same time they require a work made as if it was 1 sungle person, this meaning
we will need lots and lots of sinchronization...

I will do my best to sychronize the work using this model.

Im not sure if it would be best to divide tasks in LOTS AND LOTS of tiny asignations, or... create 4 main categories and let everyone focus on 1 of them... each has its strenghts and weaknesses...

4 main categories:
1 -- front-end parser (with the GUI where the user selects options, but the GUI can wait for awhile)
2 -- tokenizer -- converting the 1:1 stuff & tagging the terms that need more work.
3 -- Comparative Terms & Data Manager -- Rod is building the comparative terms list providing equivalents and identifying which ones will need wrappers
4 -- back-end PB code makers -- accept the 1:1 terms identified by the tokenizer & apply the necessary wrappers for the rest -- one each DLL for DDT and SDK

That's the way it's broken down on the System FlowChart. (BTW: I fixed the link http://stanhelton.com -- click on the link at the bottom of my welcome page.)

...
Anyway... im almost ready with my part, and we still can change our minds if ew need to later.

For now, the separate modules (Each point is a separate task) that i think would be convenient to split would be....

The Front End

• Front end capable of running plugins, the basic options included.
• DLL for visually modify controls.
• DLL for the Code editor advanced tasks.
• DLL, for Custom options. (ill explain later)

For now, let's think of a barebones GUI: user options (SDK or DDT, separate form files, separate class files)

The Converter

• DLL for Preprocessor. A dll that might give the first pass to check for errors, correct some of them, as well as replacing some known code with pre-coded source code (wrappers if you will).
• DLL for VB source organization. Some VB code IS messy, this dll can look for better ways to organize code before the first convert step.
• DLL for EQUATE, TYPE, VARIABLES and DECLARATIONS conversion.
• DLL for modules, this dll can place the VB code in the respective PB place, for example, converting private modules into SUBS and FUNCTIONS.
• DLL for events, Mouse clicks, keystrokes, and such can be put in the respective WM_***** location here.
• DLL for Code. This dll can translate the rest of the things like... DATA blocks, FOR/NEXT, IF/ENDIF, SELECT CASE... ETC... this involves EVERYTHING ELSE.

PreProcessor DLL is in the works -- we've called it a Parser, a Lexer, and now a PreProcessor, but the concept is the same-- trying to bring it down to a managable size for the first release and still keep the necessary functions.

The Plugins

• This is what im thinking the best way of doing, i am thinking the plugins should contain some options to be read by the front end, and controlled from there. Ill post the suggested protocol/standard calling convention, same for all.

If we set plugin equates near the front that allows for expandability, certainly. I can't get over thinking we need to concentrate on how the back-end modules will "plug in" to the main app. We solve that and we can use the same method for all Plugins.

Stan

[Chris Holbrook]

Chris -- front end design. Need clear differentiation between the parser and the tokenizer (unless I missed it somewhere - good possibility ). Rod's list of terms might be very helpful here.

Stan, having announced my departure, I don't want to be a prima donna! But just to clear the decks:

I'm assuming that you will have a data dictionary type table and a lexed VB source code table which will be what the PB writer works on. The demonstration lexer code doesn't need a lot of changing but it works at the statement level, what the application has to do is parse a series of source code files. So a component (Scanner?)is required to surround the lexer and pass in things like the statement itself, the VB source code file id, the line number and statement-in-line number, and the context which I suggest is 32-bit number with bit-encoded properties like global, local, form... The scanner itself has to set the appropriate bits in the context. This approach will also allow the scanner to contain, or have access to, code which can identify complex translation cases and flag them, and this flag can be stored in to the internal table containing lexed VB source so that the PB writer can deal with cases which can not be dealt with on a token-by-token or statement-by-statement basis - if there are any!

[Elias Montoya]

I can't get over thinking we need to concentrate on how the back-end modules will "plug in" to the main app. We solve that and we can use the same method for all Plugins.

Stan, there is some code on the source code forums to male DLL calls
on the fly, without having to compile the exe with the DLL declarations.
Those are buggy, but i have a fixed copy of them (i had to change the code
because some calls were crashing the host app).

That is not a problem, ill post an example later.

[StanHelton]

Excellent! Fred and Chris have signed off, so I'm going through all the code they posted. Going to try to put a basic front-end together. Will post cleaned up code soon as possible.

BTW: Brian has announced that SVN is up. You should get a password by PM from him today. As soon as he has the vb2pb repository up and running we'll start putting our code there. It will keep us more organized than we have been so far.

Thanks for your efforts and enthusiasm!
Stan

[Rodney Hicks]

To paraphrase a quote I believe from Ngaio Marsh.

"He was a good programmer, as programmers go, and as programmers go, he went."

Collecting a bunch of programmers is almost like collecting a bunch of painters.

Some paint in the Modern style, others in the Rennaisance style, others paint houses.

They left behind good works, and if they still can, I hope they look in on us once in a while.

Rod