You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
Busy afternoon/evening coming up for me. Okay, the COM server idea works for me too. I'll make a list of what the Tokenizer needs and you make a list of what the Editor needs. We post each (mine will be later this evening or tomorrow morning) and build the server accordingly.
Stan
Do not go quiet into that good night,
... Rage, rage against the dark.
After giving the issue of communicating with the Tokenizer some thought here are my observations:
Getting data into the Tokenizer.
As long as we can track where the current line is in the editor (easy to do), I can send text to the Tokenizer in whatever form you need. I think we do need to adopt some standards up front to solidify this process.
Need to determine a standard for passing source code lines to the Tokenizer. Continued lines should be read until the logical end of the source code line, call this a logic source code line.
Need to determine the amount of source code to pass to the Tokenizer depending on conversion level. Level 1 conversions could probably be handled logical line by logical line. Level 2 and above would probably require blocks of code to be submitted to the Tokenizer, FOR EACH or WITH/END WITH, other levels could require the entire procedure be passed, or even the entire file.
Need to determine the source code passing mechanism, string, array, or? By default Scintilla uses a $CR + $NUL combination to delimit each source code line.
Getting data back from the Tokenizer.
This is a critical step as it determines what we need to tell the Scintilla control to do.
Need a flag (property?) set to tell Scintilla if any VB source code was converted, could be %TRUE/%FALSE, or the number of lines converted. If %TRUE update edit control with new code lines, otherwise read the next chunk of VB code and convert.
Format of the data to be passed back to Scintilla, delimited string, or array? It is easier to insert an array into the Scintilla control as all you need to do is to pick the insertion point then insert the contents of the array from the bottom up. That way you don't have to keep track of the current line or set the insertion status. Even if the Tokenizer outputs a delimited string I will probably convert it to an array anyway before insertion.
Determine the new code insertion standard. Do we comment out old VB lines, or remove them before new code insertion? Perhaps this could be a user defined option. I personally favor commenting out old lines and inserting the new lines before the old lines. This gives the user a before and after picture of the VB vs. PB way of doing things. Also we can set an UNDO marker at this point and allow the user to back out of the conversion changes they just made if they want to.
Basically this is about all I can think of right now, but it should be enough to get us started hashing out the concept.
Later...
JR
"When governments fear the people there is liberty. When people fear the government there is tyranny." - Thomas Jefferson
Determine the new code insertion standard. Do we comment out old VB lines, or remove them before new code insertion? Perhaps this could be a user defined option. I personally favor commenting out old lines and inserting the new lines before the old lines. This gives the user a before and after picture of the VB vs. PB way of doing things. Also we can set an UNDO marker at this point and allow the user to back out of the conversion changes they just made if they want to.
Are you referring to the what will become the finished output file?
If you are, and forgive me if I misunderstand things here, I think we would be better off putting the PB code in a separate file with a comment at logic line end like: ' Murphysfolly.xxx line 1234.
While syntax highlighting would keep everything fairly obvious, as per your description, continuity and clarity would be atrocious for any subsequent work on the file. This for all stages of conversion. IMHO.
Part of this my reasoning is to facilitate a VBer learning PB. Analogous to me switching to a new mode of transportation, both requiring balance on my part. I have to forget an awful lot about the riding the horse to ride a bike. Both would have got me where I was going.(I don't have to feed the bike!)
Rod
In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.
Are you referring to the what will become the finished output file?
Eventually, yes.
If you are, and forgive me if I misunderstand things here, I think we would be better off putting the PB code in a separate file with a comment at logic line end like:
I don't think you are misunderstanding the issue at all. I think there are many ways to show the user the changes from VB to PB. Your method is another way. IMO there are upsides and downsides to both methods. The issue really depends on how much conversion is performed by the Tokenizer. If you weren't aware of it the editor is a MDI application which will have an effect on what and how much information is displayed to the user.
With my method the converted VB lines are commented out and the new PB lines are inserted above the comments in the same edit control. However, you make a valid observation that the resulting source code would be difficult to read, with heavy duty conversion. This method has the advantage though of keeping the conversion in the same edit control/file, thereby reducing the number of dialog boxes displayed to the user.
Your method would produce cleaner output, but with more edit controls displayed. While this is not necessarily a bad thing it will become obnoxious for the user to have to track 25 or 30 dialog boxes loaded at one time for a relatively large conversion project. This would be the case where heavy duty conversion is being performed, say every other line. There is also the problem of keeping track of the current line in two or more edit controls, while not impossible it does tend to complicate the issue dramatically, but should NOT be a disqualifier for accepting one method over another.
Perhaps both methods could be a user defined option.
' Murphysfolly.xxx line 1234.
Is the MINISTER OF FINANCE being obnoxious too!
While syntax highlighting would keep everything fairly obvious, as per your description, continuity and clarity would be atrocious for any subsequent work on the file. This for all stages of conversion. IMHO.
One of the tools I had developed for the editor would allow the user to eliminate the commented VB lines, once they had a converted file and it compiled and ran ok. In any case, I think we need to always perform any conversion on a copy of the original VB file/project, that way if things really go south, which could happen, the user has a clean starting point again. I think file management can be handled more easily in the editor than the Tokenizer.
Since we are talking about a concept here, I am certainly open to any and all methods and discussion on the issue as this will serve to make the product stronger and more "user friendly".
Good observations Rod.
Later...
JR
"When governments fear the people there is liberty. When people fear the government there is tyranny." - Thomas Jefferson
I like the sound of the editor controlling the files. The tokenizer is set up to do almost everything in memory. On this issue some thoughts:
The idea of a dozen or more windows is scary. I was thinking more along the lines of side-by-side views of VB code vs. PB code.
Would it help if there are 3 basic files used by the system? I'm thinking the original VB file unchanged, an interim file with John's system of commenting out things, and a third file which is all PB except for the necessary obnoxiousness to point out where the VBer may have a problem. You know, check this one before you use it kind of thing. The user could then refer to the interim file for detailed and/or point-to-point comparison if he wants/needs to.
Regarding format within the Tokenizer:
1. Each VB line is parsed into an array of terms. Everything, including spaces, is considered a term at this stage. Parens, brackets, periods, commas, DQs, single quotes... everything. Each 'word' or var name that can be identified is a term also. (ex.: MyObject.Method is parsed into 3 terms: "MyObject"; "."; and "Method")
2. The array further indexes each term with a Vb line no. and a Vb line pos. I can put it back together any way Scintilla likes to see it.
3. Once conversion is complete another array (see ConcordanceType in the vb2pbTypes.inc file in my recent zip). In this array everything is indexed to the PB code line. The original VB line and the new PB line are STRING * 256. PB line nos. and corresponding VB line nos. are stored together where there is a direct correlation. (VB line no. blank if no direct correlation.)
The tokenizer is set up to deal with dynamic string input.
The Concordance Array may be the easiest to pass back to Scintilla. It contains 2 LONGs and 2 STRING * 256s. I picked 256 out of thin air. If it needs to be bigger to handle logical lines, not a problem. If I follow you correctly, I can take out almost all of the Windows stuff and just concentrate on the conversions.
Do not go quiet into that good night,
... Rage, rage against the dark.
This is kinda the way I always thought of it. Or over/under, but s/s gives better comprehension, I think.
RE: line length. PB at one time, Dos for sure, PBCC, I think used to tell you in the manual that line length was limited to 248 (Dos 3.5 manual)characters. I've checked the manual, on line help, and wherever I can think of and I can't see diddly on this in anything current. It may be something that they take for granted that everyone knows, or they have done away with it. I suspect the former.
Long winded way of saying 256 should be good but we may want to lower it to 248 just in case.They may reserve a few characters(spaces) for the IDE/compiler.
Rod
In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.
I like the sound of the editor controlling the files. The tokenizer is set up to do almost everything in memory.
I guess we're on a roll.
The idea of a dozen or more windows is scary. I was thinking more along the lines of side-by-side views of VB code vs. PB code.
I need a little clarification here. Are you planning to have the user only convert one VB file at a time? If so, how do you plan on converting an entire VB project?
I also think we need to adopt a directory structure so we can automatically save files, something like:
C:\MyProject\VB = Original VB files
C:\Myproject\VB2PB = interim conversions, side by side comparisons, obnoxious comments, etc.
C:\Myproject\PB = Clean PB files
Just a thought.
Would it help if there are 3 basic files used by the system? I'm thinking the original VB file unchanged, an interim file with John's system of commenting out things, and a third file which is all PB except for the necessary obnoxiousness to point out where the VBer may have a problem. You know, check this one before you use it kind of thing. The user could then refer to the interim file for detailed and/or point-to-point comparison if he wants/needs to.
This is doable, but I think it needs to be tied to the decision of how many VB files we wish to convert/load into the editor at a time. If the user loads 5 VB files and wishes to convert each file, that is 15 separate dialogs to manage. Doable from a programming point of view, but may be a headache for the user to keep track of.
Another way to do this is to assume that the user does wish to load and convert 5 files at a time. We could have a ListView control to list the loaded files, let the user pick one, then programatically minimize the other dialogs. Do the conversion, save the 2 new output files as per the above directory structure, then prompt the user through the listview control for the next file to convert. This way, only a maximum of 3 dialogs would be viewable at a time.
Does this work for you?
Regarding format within the Tokenizer:
1. Each VB line is parsed into an array of terms. Everything, including spaces, is considered a term at this stage. Parens, brackets, periods, commas, DQs, single quotes... everything. Each 'word' or var name that can be identified is a term also. (ex.: MyObject.Method is parsed into 3 terms: "MyObject"; "."; and "Method")
Sounds like what I was doing in my pitiful attempt at parsing VB code. This is really more of a Tokenizer question; How are you handling string literals? I don't think we want to convert them under any circumstances.
2. The array further indexes each term with a Vb line no. and a Vb line pos. I can put it back together any way Scintilla likes to see it.
Since this is just text the way Scintilla "sees" it is immaterial, the source code line rebuilt by the Tokenizer must be able to compile. That should be the standard.
3. Once conversion is complete another array (see ConcordanceType in the vb2pbTypes.inc file in my recent zip). In this array everything is indexed to the PB code line. The original VB line and the new PB line are STRING * 256. PB line nos. and corresponding VB line nos. are stored together where there is a direct correlation. (VB line no. blank if no direct correlation.)
From your description here you are planning to convert line by line, correct? Have you considered the possibility that it may be easier to perform some conversions by a block of code, or by entire procedure? If so, I would assume that you would pass back an array of the code block as well?
The tokenizer is set up to deal with dynamic string input.
Easy to do.
Does the Tokenizer preserve original source code formatting such as indentation, or is this something I need to keep track of? Not a problem though. I can strip off leading spaces, pass the dynamic string to the Tokenizer, and upon return add the leading space back into the new source code line. Original source code indentation is something I think we would want to preserve.
I'm assuming here that you would want special characters removed, like trailing $CR and $NUL? These two characters are used by Scintilla to specify the end of line condition. All that needs to be determined now is do I pass the VB source code line to the Tokenizer, by procedure or an object? Although Tokenizer objects appeal to me, what is going to be faster to get out the door right now, procedures or objects?
The Concordance Array may be the easiest to pass back to Scintilla. It contains 2 LONGs and 2 STRING * 256s. I picked 256 out of thin air. If it needs to be bigger to handle logical lines, not a problem. If I follow you correctly, I can take out almost all of the Windows stuff and just concentrate on the conversions.
I guess I need to sit down and read about the Concordance Array. The source line length limitation appears to be applicable only to PB. This is not a problem. Once the converted line is returned from the Tokenizer I can format this line to keep it under, say, 200 characters if we want, just to be on the safe side. Perhaps a user defined option?
Rod,
This is kinda the way I always thought of it. Or over/under, but s/s gives better comprehension, I think.
Either way is doable, however, with side by side you run into the problem of lack of screen real estate.
RE: line length. PB at one time, Dos for sure, PBCC, I think used to tell you in the manual that line length was limited to 248 (Dos 3.5 manual)characters.
I seem to remember reading this somewhere myself. The important point to remember is once the converted line returns from the Tokenizer we can format it so that it always contains less characters than the maximum PB line length limitation. I think we should choose the PB product with the smallest maximum line length, so we will always be safe.
Later...
JR
"When governments fear the people there is liberty. When people fear the government there is tyranny." - Thomas Jefferson
There was a limit in PB/DOS. After I selected 256 as the standard I tested long code lines in both 8 & 9 -- They handled 512 without reaching a limit or an error. I wouldn't want to go that high because the line becomes unreadable after about 80, but I thought for logical lines 256 would be a reasonable limit. It can be anything if you guys think this is too big.
Stan,
...
I need a little clarification here. Are you planning to have the user only convert one VB file at a time? If so, how do you plan on converting an entire VB project?
It can handle any number of files at one time. The files are stored as a delimited list and the Tokenizer takes each file in turn, processes each line by line (currently 2 passes, but obviously there will be more than that). It identifies code blocks (FOR/NEXT, WITH/END WITH, etc.) on the first pass through a file and saves that info for when processing reaches that point on subsequent passes.
I also think we need to adopt a directory structure so we can automatically save files, something like:
C:\MyProject\VB = Original VB files
C:\Myproject\VB2PB = interim conversions, side by side comparisons, obnoxious comments, etc.
C:\Myproject\PB = Clean PB files
A necessary thing, IMO. Right now everything is dumped into "..\PBWinFiles". How about:
...
assume that the user does wish to load and convert 5 files at a time. We could have a ListView control to list the loaded files, let the user pick one, then programatically minimize the other dialogs. Do the conversion, save the 2 new output files as per the above directory structure, then prompt the user through the listview control for the next file to convert. This way, only a maximum of 3 dialogs would be viewable at a time.
Whatever works for the editor display works for me. The Tokenizer can take a dynamic string containing a delimited list of fileNames to be processed. I considered processing files in separate threads, but that is over-engineering at this point. Each file in the list is processed in turn. Progress updates can be passed back to the editor. There's a Pause feature and one or two fatal error conditions (sorry, not looking at that part of the code right now) which can be handled either directly or by the editor -- your recommendation?
Sounds like what I was doing in my pitiful attempt at parsing VB code. This is really more of a Tokenizer question; How are you handling string literals? I don't think we want to convert them under any circumstances.
String literals are NOT converted -- used verbatim in the PB output.
...
From your description here you are planning to convert line by line, correct? Have you considered the possibility that it may be easier to perform some conversions by a block of code, or by entire procedure? If so, I would assume that you would pass back an array of the code block as well?
Necessarily, it's line by line, but there's a LookAhead for blocks. If you mean non-standard or user-defined blocks of code, I can set up an option to accept it (perhaps a flag = ThisIsASnippet). Don't think that would be much different, other than smaller, from processing an entire file.
...
Does the Tokenizer preserve original source code formatting such as indentation, or is this something I need to keep track of? ...
Leading and trailing spaces are preserved. Tabs are ignored.
...
I'm assuming here that you would want special characters removed, like trailing $CR and $NUL? ...
Yes. Using $CRLF in the Tokenizer.
...
All that needs to be determined now is do I pass the VB source code line to the Tokenizer, by procedure or an object? Although Tokenizer objects appeal to me, what is going to be faster to get out the door right now, procedures or objects?
Let me get back to you on this. My gut feeling is that the Tokenizer should expose a vbLineObject for line-by-line conversion. It's set up to take a delimited string list of fileNames for multi-file processing. For user defined block? I don't know. Hadn't thought about this possibility until you mentioned it here. I'll work on it today.
I guess I need to sit down and read about the Concordance Array. The source line length limitation appears to be applicable only to PB. This is not a problem. Once the converted line is returned from the Tokenizer I can format this line to keep it under, say, 200 characters if we want, just to be on the safe side. Perhaps a user defined option?
An array of TYPEs. TYPE is 2 LONGs (for line nos.) and 2 STRING * 256 (for the code itself). Formatting those strings for display in the editor ... I'll leave that up to you guys.
...
with side by side you run into the problem of lack of screen real estate.
Can we give the user the option of S/S or O/U in the editor without too much trouble?
Do not go quiet into that good night,
... Rage, rage against the dark.
If a project has multiple files to convert, and all of them will, the user will have to establish the sequence I think, but perhaps there is some way of letting the converter find its way through the forest on its own.
However, when it comes to showing the actual conversion process, read source, interim, output, that only needs to be shown for the current file/line, whether, the files are nested or sequential, would it not?
There should be a 'Current file' display of course.
I am assuming that showing the conversion process like this is going to be a user option. Showing line by line while the converter is experiencing no delay (conversion issues) will be a waste of time most likely. Display on issue?
I can see a user wanting to see what happens the first file or two, but because of the time it takes to scrutinize each line by a human, they may want to just do the conversion as quickly as possible so they can get to the final, manual adjustment stage as soon as possible.
A "Howdedodat" button?
It has occurred to me that we might be wise to prevent any editing during the conversion process, except perhaps the occasional converter request, for fear of the user trying to add, delete, change a process that has already been started and effectively rendering the conversion unstable. Instead just inject obnoxious comment.
S/S or O/U as a user choice. On wide displays, S/S shouldn't be too bad, I do it frequently on mine.
With regard to line length, I didn't test the current editors, nor the compiler.
The converter isn't likely to run into lines that are too long for the PB system so the whole issue is probably moot. The converter will not be appending lines to other lines unless there is an issue with the converter.
I wouldn't worry about it until user feedback dictates that there is an issue there.
I know that is not a professional way to look at it, but we can't do everything for release 1.
Rod
In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.
If a project has multiple files to convert, and all of them will, the user will have to establish the sequence I think, but perhaps there is some way of letting the converter find its way through the forest on its own.
Early on I made the assumption that we would only try to convert compilable code. There should be a bolded warning somewhere that if it won't compile in VB the converted code certainly won't compile in PB.
...
Display on issue?
Yes.
I can see a user wanting to see what happens the first file or two, but because of the time it takes to scrutinize each line by a human, they may want to just do the conversion as quickly as possible so they can get to the final, manual adjustment stage as soon as possible.
A "Howdedodat" button?
With the Concordance array we should be able to display matching code sections that do the same thing (it looks like col A in VB and col B in PB).
It has occurred to me that we might be wise to prevent any editing during the conversion process ...
Currently, other than PAUSE, there are no breaks for user input once conversion has started.
I wouldn't worry about it until user feedback dictates that there is an issue there.
That's part of the Extreme Programming model. Implement what is implementable, then adjust to come closer to the user's specs as we go. I think for v1, we have a very good concept. It's getting down to nuts and bolts making it all work together now.
Do not go quiet into that good night,
... Rage, rage against the dark.
With regard to PBCC.
Considering the nature of the product that we're converting, and while the converter could have been written in PBCC, the output files are going to have to be PBWin specific. I think VB users will be concentrating on PBWin more than the PBCC and it is another item that should be left until we have user feedback. Converting a VB project for compilation in PBCC will be a lot more complicated, and I doubt that it is needed.
Rod
In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.
If a project has multiple files to convert, and all of them will, the user will have to establish the sequence I think, but perhaps there is some way of letting the converter find its way through the forest on its own.
Early on I made the assumption that we would only try to convert compilable code. There should be a bolded warning somewhere that if it won't compile in VB the converted code certainly won't compile in PB.
The conversion is string based. Several arrays are used to track functions, methods, properties, objects, etc., with a file name and line no. This should allow us to find problem areas that exist across more than one file.
Do not go quiet into that good night,
... Rage, rage against the dark.
Early on I made the assumption that we would only try to convert compilable code.
I was aware of this, but I'm not sure of just how complicated and convoluted the VB system is for keeping things in sequence, or perhaps more appropriately, orderly.
This connects tangentially to the volume of string based code that the converter tries to handle if I'm not mistaken.
I'm sure you have a handle on it.
Rod
In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.
If a project has multiple files to convert, and all of them will, the user will have to establish the sequence I think, ...
This would be one way.
...but perhaps there is some way of letting the converter find its way through the forest on its own.
If I remember correctly VB requires you to set a starting form or procedure, usually called "Main". I think this may be located in the VB project file, if so, we could start with the "StartUp form/procedure" if there is a question about where to start.
I am assuming that showing the conversion process like this is going to be a user option. Showing line by line while the converter is experiencing no delay (conversion issues) will be a waste of time most likely. Display on issue?
Agree, a user defined preference.
I can see a user wanting to see what happens the first file or two, but because of the time it takes to scrutinize each line by a human, they may want to just do the conversion as quickly as possible so they can get to the final, manual adjustment stage as soon as possible.
I think this depends on the nature of the VB project and the depth of conversion required in the first place. I can see where I might want to suppress the animated display for small simple projects, at other times I would want to view what is being converted.
A "Howdedodat" button?
I love it!!!
Stan,
Early on I made the assumption that we would only try to convert compilable code. There should be a bolded warning somewhere that if it won't compile in VB the converted code certainly won't compile in PB.
Perfect opportunity for an OBNOXIOUS COMMENT. BTW, you may also want to return some sort of status from the Tokenizer to help generate these same OBNOXIOUS COMMENTS. As I showed you in my Firefly app there were 3 types of messages, INFORMATION, WARNING, and ERROR.
INFORMATION messages would be those that inform the user of odd things in the converted code, but would not affect the compile in PB. An example of this would be unused variables in the argument list, or an empty procedure.
WARNING messages hold the possibility that the compile might fail in PB. An example here might be enumeration of objects. At this point user review and intervention may be required.
ERROR message mean something is seriously wrong with the conversion, wouldn't compile and requires user intervention.
Necessarily, it's line by line, but there's a LookAhead for blocks. If you mean non-standard or user-defined blocks of code, I can set up an option to accept it (perhaps a flag = ThisIsASnippet). Don't think that would be much different, other than smaller, from processing an entire file.
The issue here is supplying enough source code lines so the Tokenizer can do its thing. If the editor is supplying source code lines to the Tokenizer, because it needs to read ahead, I need to know how many lines to send. This is important so the two, or more, edit dialogs can be coordinated with each other. Basically I would need a "read next line" return status from the Tokenizer to keep reading and supplying lines to the Tokenizer until the status returned "Processing".
As an alternate, the portion of the Tokenizer code that reads ahead could be moved to the editor app so Scintilla knows up front how many lines to send to the Tokenizer.
Can we give the user the option of S/S or O/U in the editor without too much trouble?
From the DDT Scintilla app:
Code:
CASE %IDM_CASCADE
MdiCascade ghWNDCLIENT
CASE %IDM_TILEH
MdiTile ghWNDCLIENT, %MDITILE_HORIZONTAL
CASE %IDM_TILEV
MdiTile ghWNDCLIENT, %MDITILE_VERTICAL
That's it.
I did not anticipate allowing the user to edit a file while under conversion. Doesn't make any sense to me to allow edits at this point.
That's part of the Extreme Programming model. Implement what is implementable, then adjust to come closer to the user's specs as we go.
Sounds good to me.
I think for v1, we have a very good concept. It's getting down to nuts and bolts making it all work together now.
Do we have our marching orders?
Later...
JR
"When governments fear the people there is liberty. When people fear the government there is tyranny." - Thomas Jefferson
This is important so the two, or more, edit dialogs can be coordinated with each other.
This sounds like the Tokenizer is going to need to pass a couple of messages, more concise of course, but meaning the following:
%FEED=Need a line
%FEEDMEMORE=Need more info to compute intended code
%QUITSHOVING=Wait till I'm finished with what I have.
An alternative to my EQUATES might be a buffer where the Tokenizer reads from the top and the Editor writes to the bottom.
A buffer could have a maximum size, and the editor would have to check for space before adding a line.
Maximum would have to be the largest type of block expected.
This is probably easier to set up and use rather seamlessly.
Rod
In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.
This sounds like the Tokenizer is going to need to pass a couple of messages, more concise of course, but meaning the following:
%FEED=Need a line
%FEEDMEMORE=Need more info to compute intended code
%QUITSHOVING=Wait till I'm finished with what I have.
My thinking exactly.
An alternative to my EQUATES might be a buffer where the Tokenizer reads from the top and the Editor writes to the bottom.
A buffer could have a maximum size, and the editor would have to check for space before adding a line.
Maximum would have to be the largest type of block expected.
This is probably easier to set up and use rather seamlessly.
I guess I don't see the advantage of this method of input, although it too is doable. Since the editor is supplying the source code, the Tokenizer is the process actually controlling the conversion, therefore, it makes sense to me to allow the Tokenizer to tell the editor what it needs in the way of source code.
Later...
JR
"When governments fear the people there is liberty. When people fear the government there is tyranny." - Thomas Jefferson
[Quote:]
An alternative to my EQUATES might be a buffer where the Tokenizer reads from the top and the Editor writes to the bottom.
A buffer could have a maximum size, and the editor would have to check for space before adding a line.
Maximum would have to be the largest type of block expected.
This is probably easier to set up and use rather seamlessly.[Quote
I guess I don't see the advantage of this method of input, although it too is doable. Since the editor is supplying the source code, the Tokenizer is the process actually controlling the conversion, therefore, it makes sense to me to allow the Tokenizer to tell the editor what it needs in the way of source code.
Maybe I should not be commenting because Stan is the guy that has the Tokenizer in the grip of his mind. What you say makes sense for sure if there's any recursion going on.
Rod
In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Tweet
Comment