by Tdarcos » Tue Dec 21, 2021 3:08 am
From
a message on The Adventurer's guild:
Ice Cream Jonsey wrote: Fri Dec 17, 2021 11:45 amTdarcos wrote: Sat Nov 20, 2021 4:39 amJizaboz wrote: Thu Nov 18, 2021 11:24 pmA few years back I swore off all Call of Dookie (Duty)
"Call of Duty is the moment you realize you have to take a dump."
- Me
Been 11 days since we last heard from the Commander...
1. I'd forgotten I said that.
2. I didn't realize it was that long.
As to what I've been doing, I've been busy programming, working on some things, and actually getting stuff accomplished. But here's what triggered my temporary departure.
Earlier, on this board, I fucked up and made a posting in a thread I'd been asked to stay out of. After I saved it, I had a suspicion I'd made a mistake, so I went back several pages to the first posting I thought remembered, and sure enough, Pinback asked me not to post there.
Immediately I went to delete the post, only some fucking moron not only turned off the goddamn post-commit editing, you can't even delete a message if you made a mistake making, when it had only been 30 seconds since you saved it. But what I could do is flag it for reporting, which I did, then, realizing I'd made a terrible mistake and was going to be chewed out. Since I literally did not want to be "a one legged man at an ass-kicking contest," I decided to take a break and walk (or in my case, hop) away for a while. I just hadn't realized how long it was.
As to what I was doing while I was gone, I was just having so much fun, I got "into The Zone," and lost all track of time. Which I now realize, was for
days. I wasn't planning to leave permanently, just for a short time, which turned out to be a bit more than I planned.
While doing a Google search - as I have stated earlier, nowadays a large part of your work in doing progeramming is looking up how specify something or to see if someone else developed an algorithm for what you want to accomplish = I accidentally clicked onto the bookmark for this site. "Oh, shit." Now I've got a problem: if I go away either by closing the window (or tab) or select another website, I lose the last message seen pointer and the notification of new messages since the last visit. So I had to leave that page open until I can read them. I didn't get back around to it for a few hours. I decided to take a little break from my work, so I took the time now and stopped to read everything. Which brings me here.
The explanation of what I've been doing is somewhat technical, and may not be of much interest, but I decided to include it here for the sake of completeness. Also. it will let me organize my thoughts.
I finally did something I wanted to do for a long time, run a unit (file) trace on the Free Pascal Compiler. With dozens of units, lots of interlinkages between them, (virtually every unit depending on anywhere from 3-10 other units), each in a different file, possibly invoking include files, some of them being architecture or operating system specific, it's very difficult to figure out what is happening except by having the compiler tell you what files are read in at each point. And that's what I've done. And along the way, developed routines I can use in other tools as I get around to building them
I have been thinking (for about 5-10 years) about (possibly) doing a compiler port - an implementation of the compiler (and run-time library) for another machine architecture and operating system - and to do that, I need to understand what is going on. It's a fairly good-sized medium length program, (~330,000 lines) so it's going to take a while. But to do something as complex as this, I needed specialized tools to assist me. They need to be automated tools so I don't miss anything or make mistakes in doing them. And since I could not find existing tools to do this, I had to make them.
I have first started on a source marking tool, Noisy (since it causes a file to announce when it arrives th the compiler and when it leaves, i.e., it is very "noisy," hence the name), which is
up on Github, and can be used to put flags to have the Free Pascal compiler indicate when it opens a source file, and again once it reaches the end of the source file. And another tool to then remove said marks once I no longer require them. Next, I'd need to know what files to mark. But now, there's a problem.
The compiler doesn't just include the compiler source but run-time libraries, I'd have to go through and make a list of every file to have the program tag it. That's going to take a while, and I'm much too lazy to do that much work if I can push it off on someone else. Or
something else. Like getting the computer to do it. I realized I could write a recursive directory search routine, to search the main directory and all subdirectories, and all further subdirectories - some of which are five or six levels deep - and just read each directory looking for files with the extensions .pas, .pp, and .inc . When it finds a file, it can act upon it.
I also came to the realization I would have a general purpose code marking tool, which could be used for other things, such as group file labeling (putting a comment line at the beginning of each source file, tagging it for project and version.) So, I realized that I could do a general tool rather than a specialized one.
But, I still first needed a combination directory search recursive algorithm and marking tool to tag appropriate files. I had already figured out how to do that (recursively search a directory tree), having earlier wrote one for a different purpose altogether. With some modifications, I could repurpose it to this use.
Next: how do I make the program safe to use? It must: 1. Not lose any of the user's files, even if the process is interrupted. 2. Backup everything in case of a mistake. 3. Make everything done reversible.
This requires that:
1. Once I find the original file, check if there is already a backup - using my specific backup naming method, if so, delete that file and only that file, If I can't back it up, skip that file and report it.
2. Rename the file to the backup name; if that fails. warn the user and bail on that file.
3. Open the original file (renamed to the backup name, read only). If that fails, try to rename it back. if that fails, tell the user you couldn't restore it to the original name and what it had been renamed to, and skip that file.
4. If you were able to open the file, create the new file under the original name. If you can't open it, use the rollback procedure for item 3.
5. Write the initial compiler flag lines at the top of the file.
6. Copy all of the original file to the replacement.
7. Tack on the compiler flags after the end of the original file.
8. Close the file and continue on to the next one.
At some point I might want to remove those marks. so I had to do the same thing, only now it deletes lines that I marked. But, how do I know which are the ones I added, and which are the ones I did not? I can't just willy-nilly assume the first (and last) 3-5 lines (depending on how many I insert) at the beginning and end are mine and blindly delete them (after all, the program must be safe to use.) So I decided to use a "sentinel," a text string the user would not have in the lines of their program. I decided to use a comment string, so that the lines I inserted begin with "{.Noisy" and if a line starts with that, then and only then is it deleted. Also, I don't necessarily want the flags showing up every time it is compiled, only when I want it, so I surround the message by putting it into a conditional compilation block. Only if the user defines the compile-time symbol "Noisy" is the message displayed. The same thing at the bottom is done to show when that file is done.
Another question is, how will I insert the message at the end, I might have to make sure the lag is before the "end." at the bottom of a program or unit. I did a test and discovered the compiler will process compilation flags after the end of the code of a program or unit.
Now, again, I also need a removal tool. Well, I can repurpose the program to add lines to make a new routine to remove them. So I did. When I tested the program - by running it in a different directory, if I screwed up, I don't want to delete all my files - I made one minor error in which I didn't put each item on a separate line (it would still work as I did it, but this way looks a bit cleaner). It worked perfectly. I had it do a running "odometer" showing the number of files it had processed. I realized I needed to show the name of each file, so I "hived it off" to a different file which announced the file names.
I set each work piece - the file marker displaying counts, the file marker showing names, and the mark remover, into three different programs: Noisyadd, Noisynote, and Noisydel, respectively.
So then, having spent the better part of a day writing this tool, I tried it on a fresh copy of the latest edition, of the Free Pascal compiler, version 3.2.2 sources, in a separate directory. And the result was, in about 4 minutes I watched as it tagged over
sixteen thousand files! I knew this compiler was big, not that big. So anyway, I checked and it had done its job perfectly, a few files I picked at random in different directories, all having exactly what I wanted.
I then used the project file under Lazarus and compiled the compiler on itself. Since it has to open fewer files than my tool does, it takes less than 30 seconds to do so, and I'm able to capture the log of compiler messages. It tells me exactly what I want to know.
My little story here omits many details, including missteps, false starts, and a serious bug that caused me to have to figure out how to have Git recover a file from a previous commit. I am so glad I used source code control and did frequent commits. By checking out the erroneous file from several commits until I found the one that worked - I have no idea how I would have committed files that "break the build," i.e. have syntax errors or specification errors that prevent it from compiling - but because I did commit every time I had a working program, I had the luxury to try things and make mistakes, knowing full well, thatof anything went wong - and in most cases, usually does - I could always back up from a known-good point and start over from there.
Well, I have these tools for now and probably will finish the more substantial "full" Noisy program which will have configurable tools, what I'm doing next is something else I'd been putting off: writing a sophisticated cross-referenxe program for Object Pascal. Knowing not only where every vatiable and constant is used, but have a dependency graph for every procedure, function, and unit, it will allow better understanding of how a program works. And that, more than anything else, is what is important.
That's all for now.
If you actually read this far, thank you.
Paul
From [url=https://www.joltcountry.com/phpBB3/viewtopic.php?p=125855#p125855]a message on[/url] The Adventurer's guild:
[quote="Ice Cream Jonsey" post_id=125783 time=1639766747 user_id=3][quote=Tdarcos post_id=125278 time=1637408353 user_id=829][quote=Jizaboz post_id=125242 time=1637303079 user_id=910]A few years back I swore off all Call of Dookie (Duty)
[/quote]"Call of Duty is the moment you realize you have to take a dump."
- Me[/quote]
Been 11 days since we last heard from the Commander...
[/quote]
1. I'd forgotten I said that.
2. I didn't realize it was that long.
As to what I've been doing, I've been busy programming, working on some things, and actually getting stuff accomplished. But here's what triggered my temporary departure.
Earlier, on this board, I fucked up and made a posting in a thread I'd been asked to stay out of. After I saved it, I had a suspicion I'd made a mistake, so I went back several pages to the first posting I thought remembered, and sure enough, Pinback asked me not to post there.
Immediately I went to delete the post, only some fucking moron not only turned off the goddamn post-commit editing, you can't even delete a message if you made a mistake making, when it had only been 30 seconds since you saved it. But what I could do is flag it for reporting, which I did, then, realizing I'd made a terrible mistake and was going to be chewed out. Since I literally did not want to be "a one legged man at an ass-kicking contest," I decided to take a break and walk (or in my case, hop) away for a while. I just hadn't realized how long it was.
As to what I was doing while I was gone, I was just having so much fun, I got "into The Zone," and lost all track of time. Which I now realize, was for[i] days[/i]. I wasn't planning to leave permanently, just for a short time, which turned out to be a bit more than I planned.
While doing a Google search - as I have stated earlier, nowadays a large part of your work in doing progeramming is looking up how specify something or to see if someone else developed an algorithm for what you want to accomplish = I accidentally clicked onto the bookmark for this site. "Oh, shit." Now I've got a problem: if I go away either by closing the window (or tab) or select another website, I lose the last message seen pointer and the notification of new messages since the last visit. So I had to leave that page open until I can read them. I didn't get back around to it for a few hours. I decided to take a little break from my work, so I took the time now and stopped to read everything. Which brings me here.
The explanation of what I've been doing is somewhat technical, and may not be of much interest, but I decided to include it here for the sake of completeness. Also. it will let me organize my thoughts.
I finally did something I wanted to do for a long time, run a unit (file) trace on the Free Pascal Compiler. With dozens of units, lots of interlinkages between them, (virtually every unit depending on anywhere from 3-10 other units), each in a different file, possibly invoking include files, some of them being architecture or operating system specific, it's very difficult to figure out what is happening except by having the compiler tell you what files are read in at each point. And that's what I've done. And along the way, developed routines I can use in other tools as I get around to building them
I have been thinking (for about 5-10 years) about (possibly) doing a compiler port - an implementation of the compiler (and run-time library) for another machine architecture and operating system - and to do that, I need to understand what is going on. It's a fairly good-sized medium length program, (~330,000 lines) so it's going to take a while. But to do something as complex as this, I needed specialized tools to assist me. They need to be automated tools so I don't miss anything or make mistakes in doing them. And since I could not find existing tools to do this, I had to make them.
I have first started on a source marking tool, Noisy (since it causes a file to announce when it arrives th the compiler and when it leaves, i.e., it is very "noisy," hence the name), which is [url=https://github.com/electric-socket/noisy]up on Github[/url], and can be used to put flags to have the Free Pascal compiler indicate when it opens a source file, and again once it reaches the end of the source file. And another tool to then remove said marks once I no longer require them. Next, I'd need to know what files to mark. But now, there's a problem.
The compiler doesn't just include the compiler source but run-time libraries, I'd have to go through and make a list of every file to have the program tag it. That's going to take a while, and I'm much too lazy to do that much work if I can push it off on someone else. Or [i]something[/i] else. Like getting the computer to do it. I realized I could write a recursive directory search routine, to search the main directory and all subdirectories, and all further subdirectories - some of which are five or six levels deep - and just read each directory looking for files with the extensions .pas, .pp, and .inc . When it finds a file, it can act upon it.
I also came to the realization I would have a general purpose code marking tool, which could be used for other things, such as group file labeling (putting a comment line at the beginning of each source file, tagging it for project and version.) So, I realized that I could do a general tool rather than a specialized one.
But, I still first needed a combination directory search recursive algorithm and marking tool to tag appropriate files. I had already figured out how to do that (recursively search a directory tree), having earlier wrote one for a different purpose altogether. With some modifications, I could repurpose it to this use.
Next: how do I make the program safe to use? It must: 1. Not lose any of the user's files, even if the process is interrupted. 2. Backup everything in case of a mistake. 3. Make everything done reversible.
This requires that:
1. Once I find the original file, check if there is already a backup - using my specific backup naming method, if so, delete that file and only that file, If I can't back it up, skip that file and report it.
2. Rename the file to the backup name; if that fails. warn the user and bail on that file.
3. Open the original file (renamed to the backup name, read only). If that fails, try to rename it back. if that fails, tell the user you couldn't restore it to the original name and what it had been renamed to, and skip that file.
4. If you were able to open the file, create the new file under the original name. If you can't open it, use the rollback procedure for item 3.
5. Write the initial compiler flag lines at the top of the file.
6. Copy all of the original file to the replacement.
7. Tack on the compiler flags after the end of the original file.
8. Close the file and continue on to the next one.
At some point I might want to remove those marks. so I had to do the same thing, only now it deletes lines that I marked. But, how do I know which are the ones I added, and which are the ones I did not? I can't just willy-nilly assume the first (and last) 3-5 lines (depending on how many I insert) at the beginning and end are mine and blindly delete them (after all, the program must be safe to use.) So I decided to use a "sentinel," a text string the user would not have in the lines of their program. I decided to use a comment string, so that the lines I inserted begin with "{.Noisy" and if a line starts with that, then and only then is it deleted. Also, I don't necessarily want the flags showing up every time it is compiled, only when I want it, so I surround the message by putting it into a conditional compilation block. Only if the user defines the compile-time symbol "Noisy" is the message displayed. The same thing at the bottom is done to show when that file is done.
Another question is, how will I insert the message at the end, I might have to make sure the lag is before the "end." at the bottom of a program or unit. I did a test and discovered the compiler will process compilation flags after the end of the code of a program or unit.
Now, again, I also need a removal tool. Well, I can repurpose the program to add lines to make a new routine to remove them. So I did. When I tested the program - by running it in a different directory, if I screwed up, I don't want to delete all my files - I made one minor error in which I didn't put each item on a separate line (it would still work as I did it, but this way looks a bit cleaner). It worked perfectly. I had it do a running "odometer" showing the number of files it had processed. I realized I needed to show the name of each file, so I "hived it off" to a different file which announced the file names.
I set each work piece - the file marker displaying counts, the file marker showing names, and the mark remover, into three different programs: Noisyadd, Noisynote, and Noisydel, respectively.
So then, having spent the better part of a day writing this tool, I tried it on a fresh copy of the latest edition, of the Free Pascal compiler, version 3.2.2 sources, in a separate directory. And the result was, in about 4 minutes I watched as it tagged over [i]sixteen thousand files![/i] I knew this compiler was big, not that big. So anyway, I checked and it had done its job perfectly, a few files I picked at random in different directories, all having exactly what I wanted.
I then used the project file under Lazarus and compiled the compiler on itself. Since it has to open fewer files than my tool does, it takes less than 30 seconds to do so, and I'm able to capture the log of compiler messages. It tells me exactly what I want to know.
My little story here omits many details, including missteps, false starts, and a serious bug that caused me to have to figure out how to have Git recover a file from a previous commit. I am so glad I used source code control and did frequent commits. By checking out the erroneous file from several commits until I found the one that worked - I have no idea how I would have committed files that "break the build," i.e. have syntax errors or specification errors that prevent it from compiling - but because I did commit every time I had a working program, I had the luxury to try things and make mistakes, knowing full well, thatof anything went wong - and in most cases, usually does - I could always back up from a known-good point and start over from there.
Well, I have these tools for now and probably will finish the more substantial "full" Noisy program which will have configurable tools, what I'm doing next is something else I'd been putting off: writing a sophisticated cross-referenxe program for Object Pascal. Knowing not only where every vatiable and constant is used, but have a dependency graph for every procedure, function, and unit, it will allow better understanding of how a program works. And that, more than anything else, is what is important.
That's all for now.
If you actually read this far, thank you.
Paul