Error 515 and large programs

[Matthias Kuhn]

Hi everybody,

I´ve strange problems with adding code to my old dos-program.

The program is 12018 lines long and when I add only one more

If... then ... else then I get the Error 515.

I´ve linked in some code and I use the segment command.

Any idea´s to avoid the mistake ???

Thanks for reply.


Matthias Kuhn

[Eric Pearson]

Matthias --

Error 515 is directly related to the $LINK metastatement, and (in my experience, at least) is not related to program size.

If this problem is related to adding code, maybe you could try moving your $LINK lines to the very beginning, or the very end, of your program? If you are using two or more "related" object files, make sure they are in the same $SEGMENT.

Perhaps you are $LINKing an external object, but you are not actually using it except in the new if-block? I'm pretty sure that PB's smart-linking system would eliminate the $LINK if the function was not actually called, and in that case you might be looking at an invalid object file that did not show up until you actually used it.

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited June 12, 2000).]

[Matthias Kuhn]

Hi Eric,

I´ve deleted one $segment command and moved one $link file to
the top. ---> Now it works fine !!! There are 10 segments and
one is 60k.

But I think it stands on sharky legs after the next program-
change. I´m afraid, that I have to make new the hole prog to
get it save in compiling errors.

Thanks for Your quick help.

Matthias Kuhn

------------------

[Eric Pearson]

> But I think it stands on sharky legs

I would not be too concerned... My largest PB/DOS program (over 311k) has segments that break down like this:

53k / 50k / 60k / 62k / 45k / 1k

...so PB is pretty clearly capable of handling large programs with no problems. (And that's a PBC "chain" module... no runtime library!)

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Mike Luther]

Mathias ..

Not to work about the final product of your work, in the grand sense with
PowerBASIC!

I've got, for example:

INCHANGE EXE 409830 6-06-00 5:36p 20232 FGI/WPI/RMI invt mgmt
PRADD EXE 358423 3-14-99 9:31p 22126 Profnl case creator
PRCHANGE EXE 366461 3-14-99 9:30p 22629 Profnl case editor
PRLIST EXE 351725 8-18-99 5:24a 21246 Profnl daysheet printer
PRLOG EXE 375110 3-22-99 6:49p 22699 Profnl logging program

All running in PB 3.5 out of more than 80 of these, many like it!
These are all exe sizes and those 20,000 numbers are the line count in
each one. None of them will run any longer in the PB IDE operation.
They all have to have the PBD Debugger enabled for test purposes and then
removed for normal use! Yes, you will find curious, what I think I've
proved are anomalies in the development part of things like you are seeing
as the code gets larger and larger. That's, particularly where it seems to
just cross 16K boundary lines in the main segment. However, weed your way
around the things like you seem to have found in the link deal. There are,
to my experience, a significant number of places where curious instability
in the development platform does present itself in very large and complex
programs. However, if you can work around them and the code will run on the
bench, unless the code seems to involve upper memory that doesn't work
exactly the same on all machines, it won't fail in the field.

I've become strangely quiet here about things like this in the scope of the
large project here, even though these things are can be a real burden,
especially in de-bugging operstions. If you can write around the things,
like simply moving a LINK statement a line or so, or temporarily adding a
useless line or two to get you past a phase point where things go berserk,
and the code stabilizes again, it seems to not be a factor in the final
product. In my case, the remainder of the work I need to finish my
suite to the target level, has simply, through common library modules, seen
them written in alternate ways to do exactly the same thing with a few more
or less lines. There is no rhyme nor reason why taking two steps to hand
code a job should solve the problem where a pre-defined function should
do to! However, it just happens! When the problem goes away .. it simply
vanishes!

Eventually you seem to get to a point for your style of how you code things,
where the problems you see like this simply are cured by the common code
you manage to create that doesn't have the flukes. Those problems that I
think I've seen and managed to illustrate are IDE related, are not related
to the operation of the finished code in PB 3.5 .. as we see it.



------------------
Mike Luther
[email protected]og.com

[Lance Edmonds]

Whilst it is easy to quote anecdotal evidence, the problem is that it is extremely rare for someone to submit a copy of the source code to PowerBASIC that demonstrates a "16k boundary problem" (or whatever name you want to give it).

To be fair to Mike Luther, we so have a good example that shows a problem with the PB 3.5 debugger mis-reporting the "current" line of code (when Stepping through), but that is NOT the same type of problem as has been described thus far in this thread, yet it is typical of the allegations that have been leveled at PowerBASIC from time to time, most often by the same particular group of programmers.

While PowerBASIC are not foolish enough to believe that there are no bugs in our products - no software developer can ever give a guarantee of 100% bug-free software - but in order for us to be able to even confirm (leave alone fix) any of these "unproven" bugs, we need some cooperation! Please!

This thread is a case in point. If you want to help to sort out what you believe is a compiler problem, then when you strike a problem, put aside a complete copy of the code. If you "magically" get the code working by doing "something" that seems an unlikely solution to a problem (ie, like rearranging function order or whetever), then make a copy of that code too. Next, zip the two set(s) of file(s) up, along with a description of the problem and what you did to fix it, and submit it to Tech Support.

If you don't do this we can't verify the cause. If we can't verify the problem and cause, we can't be expected to find and fix any alleged bugs. As (professional) programmers you must have some appreciation of this cycle with your own customers - you can't fix what you cannot see is broken.

If you feel that my response here is very defensive or oppressive, it is because (as someone else pointed out in another thread on this BBS), PowerBASIC do not appreciate false accusation of bugs!

As a Tech Support representative of PowerBASIC, I take all bug reports very seriously, as do *all* PowerBASIC staff members.

We don't mind receiving reports that turn out to be programmers errors (in fact we prefer that to be the outcome, and to date, almost all reports are so! ).

We are not here to debug your code for you though, so we don't expect you to submit code that you have made _no_ attempt to resolve yourself, but in all instances we apply an honest and ernest effort to identify the cause of the problem.

When we do establish bugs in our products, we *always* present the proof to R&D, who ultimately are responsible for fixing them.

Thank you for bearing with me in my little rant. The repeated accusation without proof tends to raise our temperatures a tad!

So on that note, Matthias, if you have a "before" and "after" of your code, please submit it!

Thanks!


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Matthias Kuhn]

Hi all,

thanks für the many reply´s und the encouragement especaly from Erik and Mike Luther.

I know that I ´m "not" perfect but I´m frustated, so I decided for me to make some things better in
further projekts:

1) No piece of the particular files code should be longer as 5 Screen´s.
The 6. Screen should start with a new file.

2) The using of complicated code in units makes sometimes problems.

3) It is simpler to chain severel pieces of code e.g :

start "main.exe"

call "print.exe attribute attribute" and after printing ..
call "main.exe attribute ... " to go on at the last point

instead of making one giant exe or chain module.

4) Lance it is not my opinion to say the compiler is bad, because the are some crasy error´s.

But as longer Your code is as more frequent are the crasy errors - in my experience.
So for me it is better to write shorter pieces and get less errors at all - and spend at lot
of time less to search the errors.


5) Before an After...: Lance I not try to send You example code but:

there are several files and it not my intention to make You a lot of work..
The files are in several directory´s.

file:list1.bas

Before:
$compile Chain
$include "s1"
$include "dos_dir.h"
$include "win_vir.h"
$segment 'old
$include "suchen" ' includes many files --- I´ve added one "if then else" in this part
$link "num.pbu"
declare sub num()
...
main
...
$include "fehler" '----> line of error 515



After:
-------
$compile Chain
$include "s1"
$include "dos_dir.h"
$include "win_vir.h"
$link "num.pbu"
declare sub num()
$include "suchen"
...
main
...
$include "fehler"


Regards

Matthias Kuhn

email:[email protected]


------------------

[Lance Edmonds]

I applaud your efforts Matthias, but unfortunately this is no better than just describing the problem...

We (PowerBASIC) need to be able to see and duplicate the problem at our end... we need to see the compiler produce the error and then start the debugging process to work out what is going wrong and where.

So, I'm afraid, unless you can send all the files that are part of the file that causes the compile-time problem, we can't really help you.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Matthias Kuhn]

Lance,

I understand You in seeing the real error.

This why I´ve done all my code, .bas .pbu pb.exe pbconfig.pb in one directory.
Only the directories Point Options Directories in the IDE I´ve deleted.

All environ path in my autoexec.bat was deleted and the PC was started again.
For savety I´ve compiled with alt-f9.

And what happend ? NOTHING !!! No error at all !

So I can`t send code to You to see the error.

Do You have any explanation ?

Regards

Matthias Kuhn

------------------

[Lance Edmonds]

Sorry, as I noted above, because I (we) have not been able to see the problem, we have no way of providing an explanation.

It's like being ask to say why a car crashed without seeing the accident scene, and the only information you have is that the car is blue.

If you ever think you are experiencing this type of issue again, immediately save a copy of the source code, so even if you make more changes to the code and the problem "disappears", you can still go back to the "saved" copy and (hopefully) reproduce the problem.

If you can do that, then we can certainly help to identify if the cause of the error is our product or something else... but only if you have a copy of the code that shows the problem and that can be sent to us for evaluation!

Thanks and good luck!


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>