I remember there used to be a compiler option to remove white space and comments before a compile. Does anyone know what it was?

I have a program that has just gone over 34k. Id rather not have to split it in two if I can help it.

Ta

Dave Goddard

dgoddard@ecis.com.au

At least for arev 1.16 (or there abouts) you have two options

C to cut off the symbol table

and

L to suppress linemarks

I'm not sure what is available at later releases, never had any

manuals for them

What are you running under?

Using AREV 3.12, we did an experiment a few years ago on this question. We had a program that we were writing that was hitting the 34K barrier. We then copied the program and removed all blank lines and comments, then compiled it. We then checked the compiled ($) size against the original compiled code (where the source code had the blank lines and comments). The two sizes were identical. The only thing we could conclude was that the compile process removed or ignored all of the blank lines and comments. From that and knowing the rough precentage of commented lines as compared to actual lines of code, we were able to come up with a rough estimate of how many lines total can be in source code program before we have to start looking at spliting it out. This estimate is dependant on how you code and what percentage of your source code is comments and/or blank lines. For me it came to about 52% of my source code was either comments and/or blank lines.

I would recomend doing the same thing as we did. Make a copy of your code that you are having problems with. You may want to remove a subroutine or a section of code (code, comments and blank line) to get it to compile. This will give you a rough estimate on the number of lines you can code (with your style of programming) as an upper limit before you may need to think about splitting the code out. Then strip out the comments and blank lines and recompile. Once you do, compile the stripped down version. Compare the two object code sizes.

I later learned that the middle code ("*" rows) contain the symbol table for the compiled code. This is what allows the error messages to reference line numbers and/or variable names when a program breaks to the debugger.

Michael Slack

It was either XK or KX. Can't remember which. The order was important though. Pretty sure it was XK.

akaplan@sprezzatura.com

Sprezzatura, Inc.

Thanks Arron but no joy. Maybe I need to call the compiler directly, rather than from TCL? In fact, isn't there a pre-compiler some where?

Dave G

I'm a vocal proponent for cutting down the source code size. IMHO, source code that hits the barrier needs to be divied up. Don't forget that insert records are also included when assessing the 34K limit, so you may want to look at how you've structured those.

You should put it on the edit line

EDIT SOURCE MYFILE (XK

which will be absorbed into the compile when you press F9.

If not, let me know and I'll try and dig up the exact syntax.

akaplan@sprezzatura.com

Sprezzatura, Inc.

]]We then checked the compiled ($) size against the original ]]compiled code (where the source code had the blank lines and ]]comments

This does not seem right. Every line in the source will generate an 'object line' that is terminated by a line mark h(01). So the more comments and blank lines you have, the bigger the object will be. (unless you explicitly select the option to exclude line marks).

You mean SF9?

Yes, I'm a mean SF9…what's it to you?

Thank you..yes, I did.

akaplan@sprezzatura.com

Sprezzatura, Inc.

View this thread on the forum...