PellesC RunTime Library built
DataOrbiter11
1) A place where I divided the BCX Parser, GUI and Console
RunTimeFunctions. The "RunTimeFunctions" are the BCX built-in
functoins.
2) It took about 30 minutes to compile, but I finally created the BCX
RunTime Library using the instructions in the help file and almost an
hour trying to get the process to actually run correctly. I had to copy
my bcxdevsuite\ \bin, \lib, and \include directories to a DOS 8.3 short
filename path, then modify the BCX batch file to make it all work.
It appears at first glance that each .c file uses the same .h header
files and that each time PellesC compiles a .c file, it takes a LONG
TIME for the header information to be processed. We noticed previously,
that Version 4.x takes a LONG time to compile bc.bas, imagine it taking
655 times longer!!! It was at least a solid half hour.
Looks like we are at version 5 now and that each time a change is made
the version increments. Not all of the files uploaded for the library,
but I'm not able to tell which ones did not make it. There should be an
include\*.obj, source\*.c, and lib directories.
John
David Garner
I'm going to bring some of your last personal mail to the group because it
seems to be appropriate here. Hope you don't mind. ;)
>Hi Dave, in case you use the same info for someone else to set up the snv,
>your path was c:\mbcx\projects\mbcx and it should be
>C:\svn\progjects\mbcx
>No problems, I just read some info on how to use it.
Maybe you are going to teach me something new again, but my experience is
that you can have any directory structure you wish as long as you check out
the project from Subversion into it; Subversion will keep track of it. You
can even have one project checked out to multiple places if for some reason
you want to confuse yourself. Subversion will handle it just fine if you
can keep things straight. ;) I sometimes have a common root directory for
several projects and other times have only one.
Wow, I've not looked at what you've done yet, but what you describe looks
exciting.
One immediate thought from the above message in regard to version control:
You should very rarely control output files. If you can recreate it by
compiling or linking or other standard automated process, you don't need to
version control it.
>Now that the main .c files have been created AND we wont be updating
>bc.bas, I was wondering if you would like to make .h files like we did back
>in the day?
I'm not sure where you are in the process or exactly where you're trying to
go, but I'll try to give a couple of general responses that might address
the question you asked.
First, I think the .c files are temporary files or at least I think they
should be. MBCX should create .c files from the .bas files and then the C
compiler generates .obj files, etc.
You should control any control files (.mak, .bat, .whatever) or special
programs that you use to do any pre/post processing.
Second, yes, I think there should be .h files for the .c files that contain
the externs in each individual .c file. I think they should also be
generated when the .c files are generated.
I'm not sure how to handle the .c/.h file stuff. VB does not have header or
include files, but still allows multiple various .bas, .cls, .frm, .whatever
files to be used to group code into manageable chunks. This needs some
thought.
>I am also going to branch the library WINDOWS and one for LINUX. I suppose
>I should do that now before you guys waste time downloading the current one
>into a folder, just to have it download again? To a new folder.
Do what you want and what makes sense to you and don't worry about us. The
other two current members have fast internet connections and we may never
look at what you're doing at this stage anyway - unless we want to. ;)
I want to do something similar to what you've done - starting with the
original BCX file and factoring it in a way that makes sense to me. I hope
we can eventually agree on one way to do things, but I need to do the work
to get my mind around the process. At this point I'm not fully engaged yet.
David Garner
John Jacques
We want to have bcx library for run time functions like we did in the
past
with BCXLIB right? If so, it is done. The .c, .h, and .lib files were
created by the internal bcx library maker for the run time functions.
These
can now be linked as a .lib file with 2 header files it looks like.
The remaining bc.bas is still over 21,000 lines of code long. If the
RunTimeFunction support code is then removed it will be (HOPEFULLY) a
couple
of thousand lines less of code. This is still approximately 20K lines
of
code for the parser itself!!!!!
> >First, I think the .c files are temporary files or at least I think
they
> >should be. MBCX should create .c files from the .bas files and then
the
> >C compiler generates .obj files, etc.
I'm not sure if you are talking about something different or not. For
example, the RunTimeFunctions in BCX are written in C and fprinted into
the
C file. The .c files were created with the bcxrt.bat file, which was
created
with "BC -l" option. The problem with the "-l" option is that it is
sort of
hard coded to work on 1 persons machine, or at least requires 8.3 file
specs
to be useable. The bat file needs manual changes to work too. I can
imagine
the bat file taking several hours or longer on a slow machine. I'm
running
2.6Ghz 1.5GB RAM and it took at least 30minutes.
> >You should control any control files (.mak, .bat, .whatever) or
special
> >programs that you use to do any pre/post processing.
Ok, I understand this, but once the library files were created they
never
have to be re-created. So I actually no longer have the bcx creation
files,
but anyone can generate them with the "bc -l" option as is explained in
the
help file.
One thing that comes to mind from what you said is that we need a make
file.
The batch file used a FOR loop. I will have to check into it and see if
we
can somehow generate a .lib file from the .c files using the same
method. It
might be a good time to re-visit BCXLIB to see how we did the Makefile.
So, the output files, in this case bcxrt.lib would be uploaded to the
file
area and not included in the versioning system?
> >Second, yes, I think there should be .h files for the .c files that
> >contain
> >the externs in each individual .c file. I think they should also be
> >generated when the .c files are generated.
The problem is that the header files (2 of them) were generated by bcx
itself. It looks like we will have to run a program to create the
header
files for each .c file or do it manually. I figure we did it for BCXLIB
so
it should be pretty simple here too, but I did not look at the .h or .c
contents yet.
> >I want to do something similar to what you've done - starting with
the
> >original BCX file and factoring it in a way that makes sense to me.
I
> >hope
> >we can eventually agree on one way to do things, but I need to do
the
> >work
> >to get my mind around the process. At this point I'm not fully
engaged
> >yet.
I was thinking the same thing when I started today. There was no value
in
moving the RunTimeFunctions from the parsing engine into $INCLUDE
files, but
I wanted to see how much code was left and almost choked when I seen it
was
still over 21,000 lines!!!! OUCH! Headache just thinking about it- LOL
I then figured I would manually remove the RunTimeFunction support code
when
I stumbled on the bcxrt.lib code. I then went back to what I had with
the
$INCLUDE version and tried out the "bc -l" option. After a couple of
hours I
had the RunTimeFunctions in .c, .h, and .lib formats. Perfect for
linking.
This now allows us to remove ALL "RunTimeFunctions" support code from
bc.bas
which should shave off a ton of code from the remainder of the parsing
code
file.
What I want to do next is just that, open the 21,000 line parsing file
and
remove all references to the RunTimeFunctions. Not an easy task because
there are many variables that helped decide which functions are
included
with the user's program. To make things more difficult they are tangled
up
in 2 different IF THEN logic states, so an automated program, I think,
would
mess up too much of the code to save any real time. For example,
instead of
writing just "IF use_project THEN..." there are also "IF NOT
use_project
THEN..." and ELSE statements too. Then there are lines that have 'flag'
variables like this mixed into the same IF THEN statements.
What I like about the sub versioning is that we can make a file and it
stays
until it is updated. For example the .c files are created, so that part
is
complete. We need a makefile, but we can use the .lib file for the time
being. Once the RunTimeFunctions are removed from the parsing engine,
there's less code to maintain and it will be easier to read.
Well, it's really late. This is what I have for ideas. What do you
think? Do
you have other ideas? Good time to make goals and such huh? Maybe make
a set
of rules or something like you mentioned for what to include in the svn
and
what to place in the file area?
Thanks
John
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.407 / Virus Database: 268.13.1/466 - Release Date:
10/7/2006
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
David Garner
There are so many important points in your latest post! I'm up early to
make up for staying up late ;) and still don't feel like I can do them
justice at this time. I've read your message once and I'll give the off the
top of the head responses and plan on revisiting most of your points later
when I have a lot more time to fully address them.
I feel like I don't know enough to answer many of your questions. I'm
afraid that it's the old "solve the problem so you know how to specify the
problem to solve" syndrome.
First and foremost, we need to remember that BCX has a lot of really
powerful capabilities in a really clever and deceptively simple looking
package. We need to try real hard to not loose any of the things we really
like about it in the process of making it better. I'm convinced there's
room to make it better, but exactly how, has eluded me so far.
We need to find a way to handle the modular aspects in order to do modular
programming and gain the benefits of maintainable, reusable, scalable code.
The traditional C approach to this is with Makefiles. Java has ANT and
there's supposed to be an NANT for .NET. I don't know the requirements for
using it. We can always roll our own management scheme if we have the time,
patience, cleverness and abilities that it takes.
I think I'll quit for now. I need to get on the treadmill and then the
"treadmill" called work.
Thanks for sharing your efforts. You've provided some more ideas that I had
not thought about yet. I hope to catch up with some of what you've done in
the next few months. I know we've both gone around this thing several times
and I'm confident that we're capable of making improvements, we just need to
try a lot of stuff and see what works and what does not and then try and
determine where we can get the most bang from any changes that we make to
BCX.
David Garner
David Garner
I've started to try and capture some beginner concepts in the MBCX.doc
that's in Subversion. I'm starting over with a new XP install on my best
machine and my laptop too. I want to try and capture the minimal steps to
set up BCX. I think I have a fair start on the process in that document. I
plan to expand it as time and interest allows.
I'd like to create some beginner training materials for BCX similar to those
found on www.LearnVisualStudio.net. I really like his style and would
recommend you check it out if you have not. He has several free tutorials
and a range of prices for his offerings. I've been watching his stuff
during my walks to nowhere (treadmill) and have found them to be much better
than all those books that I don't read. ;)
Anyone have a favorite screen cam program?
David Garner
John Jacques
sentence is. I did NOT read it, just skimmed over it quickly.
I just wanted to point out that you have to sign up to Yahoo and to the
BCX
group before getting file access. I think we should provide a different
download for it where the people do not have to join a group.
I passed my Associates test this evening and signed up for the
Professional
(whatever it is called). Surprisingly, I have already taken most of the
prerequisite courses to take the test. I might take it tomorrow!
John
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.408 / Virus Database: 268.13.2/472 - Release Date:
10/11/2006
David Garner
On the MBCX front, John has done much more than I ever hope to do on slicing
and dicing BCX with an eye toward modularity and portability. I hope to
learn from his adventures.
I know that I need to dive into the process again myself and see how far I
can get. I've attempted a couple of times to carve it up in an effort to
understand how it works so that I can improve on it.
My previous approach was to automatically modify it with my SrcInden
program. SrcInden is a BCX simple string processing program that does a
specific set of conversion processes to BASIC source code. Mostly, it
removes what I consider clutter (rows or characters that I guess some
programmers thing help identify sections or significant portions of code)
that I think just take up file and screen space and it adds and deletes
spaces to get the code indentation to follow the code structure which makes
it much easier to follow.
It seemed like every time I would start over with the latest version of BCX,
I would have to modify SrcInden because new features had been added to BCX
that SrcInden did not support and was confused by. SrcInden performs its
actions based on certain specific key words and sometimes the BCX code uses
those key words as part of variable or label names and SrcInden would get
confused by those words and think they were keywords that it needed to take
action on. SrcInden, which is written in BCX, is really fast, but by
performing too many conversions at one time, I found there was no good way
to verify that the code functionality had not been inadvertently modified in
the process.
A second process that I performed was to chop the cleaned up BCX source file
into separate files based on the subs and functions (one per file) with
everything that's left over in another file. This too was performed by a
BCX program. As I recall, this program seemed to work pretty well and to
cause less collateral damage to the code in the process. Of course, the
result was a bunch of individual files to juggle which tends to confuse the
issues even with a good multi-file editor like CodeWright.
Then the fun started. I reviewed the code for things that I did not like
the looks of, but changing would not modify the program behavior. Replacing
GOSUBS with SUBS and GOTOs with structured code constructs.
I also started the process of identifying functions that share a global
variable and if the number of functions was small or at least manageable,
moving all the functions that manipulated the variable and the variable into
one file. This means one less global variable to deal with.
Replacing global variables with set/get functions for those that do really
need to be globally accessible is another important step.
It takes a very long time to perform this process manually. I made some
significant progress in this way, and gained some understanding of the code,
but at the time BCX was evolving so rapidly that I wanted to start over to
try and keep current and maybe do a better job of factoring based on my
additional knowledge of the function of the code.
I don't think I ever got this far, but once the consolidation and
encapsulation is finished, any functions that need to be called from other
files need to be externed in .h files and the .h files included in the files
where the functions are defined (so the compiler can verify the .h file
matches the .c file) and in the other files that need to call the function.
Another fundamental problem with this process is that BCX does not do
multiple modules very easily and so even when all the above is finished, you
can't use the resulting BCX source files.
I never got this far, so I'm not sure what the answer to this problem is. I
have done multiple modules using the $PRJ USE construct, but it is very
painful to get the make files set up properly for a small number of files, I
can't imagine what it would take to get it to work for something the size of
BCX.
And the important thing about this whole process is that I see BCX as being
among the smaller programs that I'd like to use BCX to develop.
I think I want to repeat the above procedure this time around as well, but
this time I want to do the SrcInden process in much smaller steps and verify
the results of each small transformation by compiling the results and
verifying that identical .c code is produced in the case of comment and
white space manipulations or by using a comparison program to verify the
more substantive programming changes such as splitting multiple command
lines into separate lines and converting IF THEN's to structured IF THEN
ENDIF's.
I would also like to develop a set of TDD tests so that we can validate the
code at any time in the future. This is new to me, so I need to learn how
to accomplish this. I'm hoping Marc can guide me to the easiest approach to
this when the time comes.
I don't know if there are any refactoring tools that would help with any of
the above steps, or if I can create some this time around.
I'm wondering if Visual Studio could be adapted to assist with any of the
above. I don't know how flexible it is.
Marc, Do you think Eclipse is suited to assist with any of this? Remember
we're not talking C here, but BCX BASIC source.
John, Do you understand what I've described and do you see any way to make
it more efficient?
Thanks guys.
David Garner
John Jacques
What I would like to do is remove the RunTimeFunction code from the
parser,
so that it is just "BCX" and the "RunTimeFunctions" (as they are named
in
bc.bas) are .c & .h files for use in building a library file to be
linked
into the user's bcx program. Also, I suppose it would allow someone to
create a runtime DLL if they wanted to. Anyway, once the real "C" is
out of
the way we have the real BASIC portion left as the BCX
parser/translator
engines. The RunTimeFunctions can be used for cross platform ports and
a few
other things.
I will write a simple program to break the bcx code into single
statements
as you suggested. This is actually a good idea if we are going to break
it
into modules.
Then I will remove the RunTimeFunction code. I can actually write a
program
to do this too. It just needs to be a bit smarter than what is normally
needed.
I also agree that the gosubs should be changed to actual subroutines
whenever possible.
Finally, getting rid of as many global variables, by moving them
locally
would make the move into modularity easier.
Just a note, because I know we will eventually have many people wanting
to
make the code execute FASTER, as the goal with BCX has been. We are not
looking for the fastest code, but the most BASIC and modular code
right?
I think a set of "rules" or whatever you want to call it, maybe a
mission
statement should include something like:
1) The functionality of this bcx version 5.09x will not be altered by
the
modifications. A program compiled with our modular approach will run as
it
does with the normal bcx of the same version, but maybe not as
efficient.
*Also note that as we learned with BCXLIB, some of us were able to use
extensive C optimization to actually improve the speed of the code. The
problem was that it makes the final executable not compatible on all
systems. Particularly Intel -vs- AMD optimizations.
2) One BCX statement per line, no colon compound lines of code.
3) local variables whenever possible.
Etc....
Just some late night ideas....
What do you think?
David Garner
> Wow, large message!
Yep. I can get long winded, but I want to be clear about what I have done
(to myself as well as others) and what I think needs to be done. It's not a
simple process, but taken one step at a time, it can be manageable.
> Looks like we are moving in the right direction.
I'm glad you think so. I sometimes wonder if I know what I'm doing.
I think your idea of documenting some guidelines will help all of us. This
is the kind of thing that a Wiki would be good for. A Wiki provides a place
to stick things that you don't want to get lost and refine the presentation
as new ideas evolve. I think the Google Groups pages provide a similar kind
of functionality. If you have time, you might start a page and put your
points on it so we don't loose them in the flood of messages.
I want to create a lot of secondary effects from this effort. I'd like to
capture some documentation for new programmers, create some tutorials to
ease the learning curve, document the process of the conversion so others
can duplicate our efforts and tweak things in some other direction, document
how BCX works internally, create some methodologies and mechanisms to
facilitate the processes we find useful and have a lot of fun along the way.
You talk of writing some tools to manipulate things. That is one of my main
lines of focus. I have a couple of programs that I have used and hope to
write more. I'm sure you must have a hard drive or two full of them
yourself. I'd like to see what you've done and how. I think there is a
huge potential for code re-use and would like to create some tools to
facilitate it. There is a massive amount of BCX code available that does a
lot of interesting things. I hope to be able to re-package and reuse it to
build some truly massive MBCX projects that solve many real world problems.
If all code is written to minimize the use of global variables and hide all
the internal workings of functions, it makes it much easier to plug it into
other projects.
I also hope to learn and share the tools and techniques via this effort.
SrcInden does a lot of the steps I described in my previous message and the
source is available on my www.dgarner.com website. Please feel free to snag
all that's there - if you can understand it. I don't claim it's the best
BCX, but it seemed to work pretty well - most of the time. Let's not
re-invent the wheel anymore than we have to. I'll be posting some of the
other tools I've built (and will build) as soon as I can locate them or
create them.
David Garner