Greeting group.

I recently flash compiled all of my programs. I used a program to compile
and capture the return message. Any program that did not compile correctly
was logged into a file. Fortunately there were only a few.

Now my challenge is figuring out why they did not compile. Here is an
example. The message does not tell me where the problem lies. Can anyone
shed some light on this?

:COMPILE SOURCE-DA REPORT.DA.INV.NONMOVE (OK
REPORT.DA.INV.NONMOVE
...................................
[820] Creating FlashBASIC Object ( Level 0 ) ...
[821] FlashBASIC Compilation Error: Phase 1, Code 255
[B100]*Line 0: Compilation aborted; no object code produced.


Some of my other programs are not behaving properly. One program compiled as
the 1995 version rather than the current version. I re-compiled it
individually and it now works as it should.

Thank you,
Jeff
--
Jeffrey Kaufman
Key Data Systems Group
www.keydata.us
1111 Grizzly Peak Blvd.
Berkeley, CA 94708
510-486-9015 office
510-486-9016 fax
559-432-3832 cell

On Feb 12, 3:27 pm, "Jeffrey Kaufman" <jkauf... (AT) keydata (DOT) us> wrote:
For the compilation error 'phase 1'.... try looking at the passed
parameters. I got a like error when the program defines a MAT VAR as
a passed parameter, but VAR is not dimensioned inside the subroutine.
Or something very close to that.

As for the 1995 version of the program problem, if the source code was
not available, then the flash compile will only work with the object
code. So I'd be suspicious and look at other such possibilities.

One question here.... Why are you using the 'K' option for all your
programs? It is my understanding that you should only used the K
option on subroutines that are called often, like a central data input
and validation routine. Maybe my understanding is wrong!?!?!?

Regards,

Dale

"Dale" wrote:
Dale is right. The K is for core-locking frequently used object code
rather than releasing allocated memory when all users have exited.
('K' = 'keep' in memory?) This should be used for specific programs,
not all, if used at all.

I don't recall the specific error or release but somewhere in D3NT 7.4
I noticed the K option wasn't working properly. Of course I found
this (and reported it) after I suggested to BlueFinity that it would
be efficient to use the K option on mv.NET programs. Uh Oh... I
think the rule of thumb should be to not use the K option unless RD
can verify that there are no known issues - and if you do find issues,
report them.

T

I find nothing wrong with this program. I tried to flash compile without the
K option and got the same results.

:COMPILE SOURCE-DA REPORT.DA.INV.NONMOVE (O
REPORT.DA.INV.NONMOVE
...................................
[820] Creating FlashBASIC Object ( Level 0 ) ...
[821] FlashBASIC Compilation Error: Phase 1, Code 255
[B100]*Line 0: Compilation aborted; no object code produced.
:

This is why I have hesitated flash compiling my programs all these years.

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

On Feb 16, 3:50 am, "Jeffrey Kaufman" <jkauf... (AT) keydata (DOT) us> wrote:

dumb question ... there IS plenty of fee space on the Linux partition?
(had a similar error yesterday, and this was the culprit)

I assume the site has maintenance (?), so what did RD say (once more,
we have found RD/TData to be VERY HELPFUL, and they have been m ore
than willing to connect to client sites to investigate/resolve issues
for us)

On Feb 15, 8:50 am, "Jeffrey Kaufman" <jkauf... (AT) keydata (DOT) us> wrote:

Again... The problem that the code won't Flash-compile has nothing to
do with the 'K' option.

Recheck carefully the first line of the subroutine and the
dimensioning of the variables that are accepting the data past.

Another problem with Flash-compile is that the P-code compiler, as I
call it, will allow the parameter list to also be on the second line.
The flash-compile chokes on this.

I've beat my head against many wall dealing with these flash-compile
errors, and 90% of the time it has to do with parameter passing.

Regards,

Dale

You nailed it Dale. A subroutine call was split onto two lines. Thanks for
your input. Too bad there was no indication in the error message that
pointed to the problem.

Jeff

"Dale" <dale_benedict (AT) flightcraft (DOT) ca> wrote

How can the compiler know what's valid to pass and what's not?

The only problem with passing a parameter that's also common is garbage
collect tries to give up the space used by the subroutine, so when it gives
up the passed parameter, it also throws away your common variable and puts a
hole in the descriptor table.

But the compiler is totally issolated from data issues and could care less.

For example, the following compiles just fine in flash or standard basic,
and barfs big time (if I tried to run it):

common a,b,c
call testit(a,b,c)
stop


Mark


"Dale" <dale_benedict (AT) flightcraft (DOT) ca> wrote

Mark,

The compile error that Jeff is getting is caused by the first two
lines of the subroutine.

eg.

001 subroutine mysub( a, b, c
002 d,e,f)

The regular p-code compile handles this find, but the flash-compile
chokes.

I haven't tried to first compile to p-code using the 'C' option to
suppress the eol markers and the flash-compile the object only. I
suspect this may work, but like most others I prefer to be able to
drop into debug and look at where the program is if there is an error.

By the way, this problem has been reported to RD.

Regards,

Dale


On Feb 15, 11:23 pm, "Mark Brown" <mbr... (AT) drexelmgt (DOT) com> wrote:

The actual problem was more like this:

112 *
113 CALL PROGRAM.NAME (VAR1, VAR2, VAR3,
114 VAR4, VAR5)
115 *

It compiled with the p-compiler, but choked as Dale said it would with the
flash compiler.

112 *
113 CALL PROGRAM.NAME (VAR1, VAR2, VAR3,
VAR4, VAR5)
114 *

This code compiles both ways.

BTW, the first code snip was done accidentally when pasting code from
another program. The code wrapped to a second line. It would have been nice
if the flash compiler could have reported the line number with the problem.
It would have save me a lot of debugging.

Thanks again for your input Dale and Mark.

"Dale" <dale_benedict (AT) flightcraft (DOT) ca> wrote