"Out of string space"

[Jark]

(Splitting the TC-Lib into modules). That's what I get after too many .bi Includes in a prog (knowing it works when all the subs are in the same module). What does that mean... ? Is there a special way to integrate modules in a prog that avoids this issue ?

[Meg]

Well one thing is this: make sure for each module that you ONLY include .bi files that contain subs/functions used by that module.

imagine this is your program, broken up into subs:

Code:

MAIN (Module)
    Program.Run (Sub)
    Program.Init (Sub)
    Program.End (Sub)
GRAPHICS (Module)
    Show.Line (Sub)
    Show.Circle (Sub)
SOUND (Module)
    Play.Note (Sub)
    Play.Song (Sub)

let's say that you have a LIB with two functions: One that Clears the screen (yeah, yeah I know.. CLS.. just pretend!) and one that prints text to the screen. So maybe the .BI looks like this:

Code:

LIBRARY.BI
    DECLARE SUB ClearScreen ()
    DECLARE SUB PrintText (t$)

Okay, now if you call both of those functions in all three of your modules, you'd need to REM $INCLUDE 'LIBRARY.BI' three times, once at the start of each module.

If no routine in your SOUND module uses any of the variables, subs, or functions declared in LIBRARY.BI, you don't need to include it in that module.

Furthermore, let's say that the situation looks like this:

Code:

MAIN module needs ClearScreen AND PrintText.
GRAPHICS module needs just ClearScreen.
SOUND module needs just PrintText.

It seems like you'd need to include the whole library in all three modules. However, you can get around this by making a sub in ONE module that calls the library sub/function, and then just include the lib in THAT module. Your program would then look like this:

Code:

MAIN (Module)
    ClrScrn (Sub)
    PrntTxt (Sub)
    Program.Run (Sub)
    Program.Init (Sub)
    Program.End (Sub)
GRAPHICS (Module)
    Show.Line (Sub)
    Show.Circle (Sub)
SOUND (Module)
    Play.Note (Sub)
    Play.Song (Sub)

see? You only INCLUDE the library in the first module, not in the other two. the two new subs you make in the first module simply call the subs ClearScreen and PrintText (from the .LIB), passing along whatever arguments you supply:

Code:

SUB ClrScrn ()
    CALL ClearScreen ()
END SUB

SUB PrntTxt (t$)
    CALL PrintText(t$)
END SUB

You can now call these NEW subs from any module, and because the LIB is included in the module that's got these new subs, it will pass along the information as if the LIB's sub was included in the calling module. (i.e. you could call ClrScrn from GRAPHICS module, and it would be just like calling ClearScreen from GRAPHICS module, only without having to $INCLUDE the LIB into the GRAPHICS module).

When you compile the program, every time it encounters the $INCLUDE metacommand, it's the same as having typed in the entire library into your code at that point. So the fewer times you $INCLUDE a lib, the less likely you are to encounter memory / string space errors.

I hope this helps!

*peace*

Meg.

[Antoni Gual]

Your SOURCE is too big to fit in the IDE. Splitting it into modules solves only the problem of the compiled modules size, but the use of the include files overloads even more the IDE. Ideas:
Avoid using the IDE: use a text editOr and compile and link from the command line.
If you don't want to leave the IDE, make a QLB from the modules you have already debugged, and load it with the IDE, it avoids a lot of source. If you want to compile you will have to do a lib too.

[Jark]

Well, I will save that page in order to understand everything...

I managed to compile a TCDemo.exe after a lot of attempts. I still have a stack overflow with the Mdb Explorer, and that means I have to think about creating a qlb, maybe.

These progs are the biggest I've done : the funny thing is that I can compile an exe when everything is in the same .bas, but that include stuff is a real pain in the ass...

And remember, Antoni, I would like to integrate XMS ! For the Buddhabrot, in fact...

The mouse is OK now : 16x16, 9 levels greyscale, and fast enough...

[relsoft]

Stack Overflow. Are you by chance using recursion?

[Antoni Gual]

Stack overflow causes:
1.- Too many levels of recursion
2.- You are exiting a GOSUB otherwise than using RETURN
3.- A LOT of local variables in a SUB /FUNCTION maybe combined with 1
4.- Recursion without an exit condition

2 and 4 are just improper programming, I suppose you are not in this case.

3 and 1 can be solved making STATIC all variables that are re-initialised at each SUB/FUNCTION call, it saves some stack space. Also you can use CLEAR at the top of the program to increase stack space.

[Jark]

It's not a stack overflow during a direct run (I had this issue a few weeks ago, but it's OK now: too many passed variables in subs), it happens during a compilation attempt :

TCGUI.obj : fatal error L1070: BC_DATA : segment size exceeds 64K

pos: 128 Record type: 98

How can I debug that ?

[Glenn]

manual, you can't. (It suggests recompiling and linking with the "large memory model", but I don't think QB gives you the option of specifying different memory models.) You need to rewrite something, i.e., change how you're doing whatever it is that's causing LINK a problem.

[Meg]

...to cut the $includes out of the module that's giving you the segment size above 64k, it'd most likely work.

i had the same error in my program.

*peace*

Meg.

[Antoni Gual]

BC_DATA exceeds 64K? And the solution is use the large model?
Maybe you are putting too much COMMON variables in the data segment.
Try making some COMMON arrays $DYNAMIC...