IntyBASIC "include" module limit??

[+DZ-Jay]

I was not aware that there was a limit to the number of modules you could include in your IntyBASIC program.  I just got this error:

Error: more than 50 INCLUDE used in line 331

 

So, apparently, you cannot include more than 50 modules.  This is distressing. 😬  I am going to have to figure out how to merge my modules to resolve this issue and avoid it in the future.  I wasn't planning on that, and I'm not done with the project.

 

Personally, I do not think there should be a limit; but if there must be one due to practical considerations, it should be rather high.  50 is much too small for anything other than a trivial program.  For easier maintenance and troubleshooting, I tend to break out my codes into many modules -- organized in contextual and logical groupings.  It's sort of a pain to have to wade through hundreds of lines of codes among dozens of subroutines in order to find the line you want.  (Christmas Carol, for example, consisted of over 200 modules, including code, data tables, bitmaps, animations, etc.)

 

I just thought it was weird, and the error took me by surprise.  The limit is not mentioned in the manual, nor had I heard it mentioned before.  Am I really the only weirdo that has ever broken his program into more than 50 files?

 

Anyway, I wish this limitation is raised in a future version of the compiler.  I also wish for the compiler to support nested "include" directives.  Oh, and as long as we are making wishes, I want a pony for Christmas.

 

     -dZ.

[carlsson]

Perhaps you can use a Makefile, that instead of including multiple source files, paste them together on the fly and feed the compiler?

[+DZ-Jay]

3 minutes ago, carlsson said:

Perhaps you can use a Makefile, that instead of including multiple source files, paste them together on the fly and feed the compiler?

Sure, that's one possible work-around; but it's just something I wasn't planning to deal with.  It will also make troubleshooting with the source-level debugger more painful, because my line numbers won't match.

 

I'm just surprised nobody has ever come across this. 🙁

 

    dZ.

[carlsson]

Perhaps it is a limitation of the C++ compiler to generate the IntyBASIC compiler, if it can't handle more than 50 input files at once?

[+DZ-Jay]

7 minutes ago, carlsson said:

Perhaps it is a limitation of the C++ compiler to generate the IntyBASIC compiler, if it can't handle more than 50 input files at once?

That would be fine, and I would live with it, of course.  I just wish I knew.  At the very least, there should be a note about it on the manual.

 

I have now 50 files, and they are mostly constants, macros, and core engine-related modules -- I have not even started creating graphics, animations, sounds, etc., which will surely take more files to house extensive data tables.  So, I have to figure out how to re-organize them in a way that gives me some headroom for what is to come, and does not make troubleshooting or perusing the code too cumbersome and burdensome.

 

It is probably not a problem for most people. But my little brain cannot deal with large files and hundreds of lines at once -- I get overwhelmed easily and my brain loses focus. ;(

Don't get me wrong, as far as limitations go, this one is one of the least bothersome.  It is just yet another one, so I am just a bit frustrated at the moment; but I will get over it.  *shrug*

 

    dZ.

[carlsson]

From the source code on GitHub:

 

class compiler {
private:
    ifstream input;
    ifstream included;
    ifstream included2;

[..]
    ifstream include[50];

 

The number 50 is hard coded into multiple places of the compiler source code. I wonder if the C++ compiler puts those input streams on the heap or something, and nanochess found out that 50 is a sweet number to not max out the heap. If you have a suitable environment, you could get the sources, change the number to a higher one, recompile the IntyBASIC compiler and see if you get segmentation fault or if it behaves properly.

[+DZ-Jay]

2 minutes ago, carlsson said:

From the source code on GitHub:

 

class compiler {
private:
    ifstream input;
    ifstream included;
    ifstream included2;

[..]
    ifstream include[50];

 

The number 50 is hard coded into multiple places of the compiler source code. I wonder if the C++ compiler puts those input streams on the heap or something, and nanochess found out that 50 is a sweet number to not max out the heap. If you have a suitable environment, you could get the sources, change the number to a higher one, recompile the IntyBASIC compiler and see if you get segmentation fault or if it behaves properly.

Thanks, but I think I'm not smart enough to be able to re-compile the compiler from source.  I haven't touched development tools other than simple editors and the scripting languages for several years now.  I'll leave that to the real programmers. 
 

I'll just sit in my little corner, "shout at the clouds" for a few minutes, and then just ... re-organize my code and deal with it.  

 

    dZ.

[carlsson]

7 minutes ago, DZ-Jay said:

I'm not smart enough to be able to re-compile the compiler from source.

Are you Team Windows, Team Mac OSX or Team Something Else? On Windows, I have the MinGW environment + msys shell. Except for the last step, to strip away debug strings from the final binary, the Makefile included with the code works right out of the box. If you run 64-bit Windows, I can supply you with an IntyBASIC compiler binary to try.

[+DZ-Jay]

1 minute ago, carlsson said:

Are you Team Windows, Team Mac OSX or Team Something Else? On Windows, I have the MinGW environment + msys shell. Except for the last step, to strip away debug strings from the final binary, the Makefile included with the code works right out of the box. If you run 64-bit Windows, I can supply you with an IntyBASIC compiler binary to try.

I'm on ... (checks the historical fossil record ...) team OS X 10.8.5 ... Intel chipset ... from way back in the ancient days of yore, when operating systems were named after large cats.

 

Do not worry too much about it.  I would like to release my source at some point, and it should be possible for anybody to build it with the stock compiler.  I do appreciate the offer very much. 👍🏻

 

    dZ.

[Crash7]

Hey I'm still trying to get my Sears controllers to work on the emulator both nostalgia and Joe's

 

I got the emulator up I still can't get the Sears pads hooked up to where I can use the keypad and have it recognize the second player.

 

Anybody has to hack file for Intellivision 2 controllers please send it my way thank you.

[carlsson]

2 minutes ago, DZ-Jay said:

team OS X 10.8.5

Ok. I know nothing about which development tools Apple may or may not supply with the operating system. I suppose I can set up a test project of my own with > 50 dummy files to be included and see how the compiler handles it.

[carlsson]

Ok, I moved 50 to a constant and changed it to 100. The g++ compiler doesn't seem to bother, and the resulting IntyBASIC compiler also doesn't crash out.

 

Of course my test program is the most plain you can imagine, consisting of 80 constants defined in one file each and the main program is an endless GOTO loop, so it might not be a realistic example of any limits you might encounter.

many-include.tar.bz2

[+nanochess]

I forgot completely why I put that silly limitation in the first place 🤔

[+DZ-Jay]

2 minutes ago, nanochess said:

I forgot completely why I put that silly limitation in the first place 🤔

 

No worries.  I just re-grouped my modules for the moment, so I am now way below 50.  :)

 

It would be nice if that limitation goes away in the future, or at least is increased significantly.

 

      -dZ.

[carlsson]

I still wonder if it could be due to the C++ compiler used, or perhaps the computer running the IntyBASIC compiler, how it allocates memory. I tried with 80 files which were below 20 bytes each. I imagine if each file was 20 kB or more, the situation might be different, though even then we're talking a few megabytes of RAM to allocate for input files which a computer from the 21th century shouldn't have any major issues with.

[+DZ-Jay]

3 minutes ago, carlsson said:

I still wonder if it could be due to the C++ compiler used, or perhaps the computer running the IntyBASIC compiler, how it allocates memory. I tried with 80 files which were below 20 bytes each. I imagine if each file was 20 kB or more, the situation might be different, though even then we're talking a few megabytes of RAM to allocate for input files which a computer from the 21th century shouldn't have any major issues with.

 

Or maybe nanochess just thought that 50 files ought to be enough for anybody ...

 

 

😄

[+Lathe26]

On 11/4/2023 at 1:21 PM, DZ-Jay said:

 

Or maybe nanochess just thought that 50 files ought to be enough for anybody ...

 

 

😄

Bill's 640K quote is always good for a laugh.  The weird thing is that the 640K limit was actually created by IBM.

[+nanochess]

12 hours ago, Lathe26 said:

Bill's 640K quote is always good for a laugh.  The weird thing is that the 640K limit was actually created by IBM.

Before EGA actually the limit was 768K.