StonyBrook Modula 2 : Maximum names limit reached

[Wolfgang Greiner]

Hi,
we have a serious problem with StonyBrook Modula 2 Version 4.0 Build 31.

We maintain a huge project with 940 modules containing 700 thousand lines of
code and it
is still growing.

When compiling we get the error message:

2>> Internal error in file .\Main.mod at line 1
2>> -- Maximum names limit reached
2>> compiler-> Compiler exception
1>> Internal Error: Contact tech support

The SBM2 manual says:
"Maximum number of unique identifier names per module/package = 65535.
This includes symbols from all imported modules/packages."

It seems to include even the symbols in *indirectly* imported modules.

A test project to show the problem can be seen here:
http://115683.webhosting36.1blu.de/modLimit.zip

At the moment, we avoid the problem by commenting out unneeded
constants in DEF-Modules but this is only a temporary solution.

Unfortunately the manufacturer Gogesch Micro Systems, Inc. is no longer
in business.

Is there any way to increase the maximum number of unique identifiers?

Can anyone give me the email adress of Norman Black or Richard Gogesch?


Kind regards,
Wolfgang Greiner

[Martin Brown]

Post by Wolfgang Greiner
Hi,
we have a serious problem with StonyBrook Modula 2 Version 4.0 Build 31.
We maintain a huge project with 940 modules containing 700 thousand
lines of code and it
is still growing.
2>> Internal error in file .\Main.mod at line 1
2>> -- Maximum names limit reached
2>> compiler-> Compiler exception
1>> Internal Error: Contact tech support
"Maximum number of unique identifier names per module/package = 65535.
This includes symbols from all imported modules/packages."
It seems to include even the symbols in *indirectly* imported modules.
http://115683.webhosting36.1blu.de/modLimit.zip
At the moment, we avoid the problem by commenting out unneeded
constants in DEF-Modules but this is only a temporary solution.
Unfortunately the manufacturer Gogesch Micro Systems, Inc. is no longer
in business.
Is there any way to increase the maximum number of unique identifiers?

I would not have thought so now - its limitations stem from way back
when INTEGER types were 16bit by default. You might find it worth trying
to compile the package with XDS M2 to see if a port to a new compiler
would help. Dunno what its limitations on symbol tables are either.

Post by Wolfgang Greiner
Can anyone give me the email adress of Norman Black or Richard Gogesch?

Sorry long lost contact. In the same vein anyone still have a valid
email address for either of Bob Kushlis, or Scott Robbins?

Regards,
Martin Brown

[Wolfgang Greiner]

Hi Martin,

thank you for your answer.

I would prefer to avoid switching to another compiler because we used many
of the SBM2 extensions (classes, generic modules , etc.) so it would be a
lot of work.

And besides the identifier limit we are very very content with SBM2 .

Regards,
Wolfgang Greiner

Post by Wolfgang Greiner
Is there any way to increase the maximum number of unique identifiers?

I would not have thought so now - its limitations stem from way back when
INTEGER types were 16bit by default. You might find it worth trying to
compile the package with XDS M2 to see if a port to a new compiler would
help. Dunno what its limitations on symbol tables are either.

Post by Wolfgang Greiner
Can anyone give me the email adress of Norman Black or Richard Gogesch?

Sorry long lost contact. In the same vein anyone still have a valid email
address for either of Bob Kushlis, or Scott Robbins?

[Martin Brown]

Post by Wolfgang Greiner
Hi Martin,
thank you for your answer.

Hi Wolfgang,

Sorry it isn't much help. Is it only publically visible global
identifiers in the DEF modules that cause trouble? Or do internal
symbols in the implementation modules count against your global tally.

Post by Wolfgang Greiner
I would prefer to avoid switching to another compiler because we used many
of the SBM2 extensions (classes, generic modules , etc.) so it would be
a lot of work.
And besides the identifier limit we are very very content with SBM2 .

Good compiler in it's day. But getting a bit long in the tooth now.

The way I dealt with a similar problem in the past was to create a
deadwood detector that scanned modules to look for any symbols declared
or imported and never used. This kept us going for a while longer (same
sort of symbol table overflow problem but a different compiler). Had to
be used with care as it didn't understand enumerated types...

Regards,
Martin Brown

Post by Wolfgang Greiner

Post by Martin Brown

Post by Wolfgang Greiner
Is there any way to increase the maximum number of unique identifiers?

I would not have thought so now - its limitations stem from way back
when INTEGER types were 16bit by default. You might find it worth
trying to compile the package with XDS M2 to see if a port to a new
compiler would help. Dunno what its limitations on symbol tables are
either.

Post by Wolfgang Greiner
Can anyone give me the email adress of Norman Black or Richard Gogesch?

Sorry long lost contact. In the same vein anyone still have a valid
email address for either of Bob Kushlis, or Scott Robbins?

[Wolfgang Greiner]

Hi Martin,

even symbols in the implementation modules count. (but not all)
Thanks for the idea of a deadwood detector. I do this manually at the
moment.

My dream is just getting an update from Norman Black 8-) (like in the old
days...)

Regards

Wolfgang Greiner

Post by Martin Brown
Sorry it isn't much help. Is it only publically visible global
identifiers in the DEF modules that cause trouble? Or do internal symbols
in the implementation modules count against your global tally.

Post by Wolfgang Greiner
I would prefer to avoid switching to another compiler because we used many
of the SBM2 extensions (classes, generic modules , etc.) so it would be
a lot of work.
And besides the identifier limit we are very very content with SBM2 .

Good compiler in it's day. But getting a bit long in the tooth now.
The way I dealt with a similar problem in the past was to create a
deadwood detector that scanned modules to look for any symbols declared or
imported and never used. This kept us going for a while longer (same sort
of symbol table overflow problem but a different compiler). Had to be used
with care as it didn't understand enumerated types...

[jan272]

Post by Wolfgang Greiner
My dream is just getting an update from Norman Black 8-) (like in the old
days...)

nice dream! I used to have a similar dream; roger carvalho making a
linux release of his fst.

NOW, I'm mighty glad he ddn't do it, so I was forced to go with mocka
0608.

you can do the same; your project is still within reasonable size.
murus is much bigger, yet it compiles without errors. just spend some
time with it. you'll get a better os in with e deal for free. sooner
or later you will -have- to do this step anyway.

[George]

Post by jan272
NOW, I'm mighty glad he ddn't do it, so I was forced to go with mocka
0608.

Mocka 0608m preferred.

Post by jan272
you can do the same; your project is still within reasonable size.
murus is much bigger, yet it compiles without errors. just spend some
time with it. you'll get a better os in with e deal for free. sooner
or later you will -have- to do this step anyway.

And how does he convince his customers to switch?

[jan272]

Post by George
Mocka 0608m preferred.

It is free of charge. And it is a fine compiler.

Post by George

sooner or later you will -have- to do this step anyway.

And how does he convince his customers to switch?

Mocka is free of charge. Dr Maurer has no customers. He works for
engineers. And engineers know: you cannot infinitely patch an old
design, no matter how good the old design was, in its hay days....

The Stony Brook symbol table needed a symbol counter, for some silly
reason. If you know why the counter is there, you may be able to
tinker out the counter. In a linked list, the NIL pointer will signal
end of list. No counter required. And it doesn't make sense to keep
track of local variables. So my guess is: you found a bug!

[Marco van de Voort]

Post by Wolfgang Greiner
even symbols in the implementation modules count. (but not all)
Thanks for the idea of a deadwood detector. I do this manually at the
moment.

Did you try to build incrementally and see if that makes a difference?

Of course if it is the linker that still won't help :-)

[Wolfgang Greiner]

Yes, I tried that, but it didn´t help. The limit seems to be the number of
symbols
in the SYM-Files that are directly or indirectly imported + the number of
sysmbols
in the importing Module itself.

Post by Marco van de Voort
Did you try to build incrementally and see if that makes a difference?
Of course if it is the linker that still won't help :-)

[tbreeden]

Wolfgang,

Post by Martin Brown
The way I dealt with a similar problem in the past was to create a
deadwood detector that scanned modules to look for any symbols declared
or imported and never used. This kept us going for a while longer (same
sort of symbol table overflow problem but a different compiler). Had to
be used with care as it didn't understand enumerated types...

It sounds as if the string table is full here.

If Stony Brook works like the ETH compilers, I suspect you must import
fewer modules to get any benefit, because the import pass reads into
the string table everything in the SYM files imported. It does include
indirectly imported stuff in the SYM file (but they will not be
duplicated in the string table).

I think you might look at breaking up the main program into
independent modules. If you can do this such that the resulting
modules do different functions you may be able to get by with
importing different subsets of all the definition modules into each
new module representing a section of the program.

Good luck,

Tom

[Wolfgang Greiner]

Yes, I am afraid I will finally have to do break it up into independent
modules.

At the moment I comment out unused constants in Libraries and save names
by "reusing" the parameters of Procedures in DEF-Files.
eg.
renaming
PROCEDURE LoadLibraryExW(lpLibFileName : ARRAY OF CHAR;
hFile : HANDLE;
dwFlags : DWORD) : HINSTANCE;

to

PROCEDURE LoadLibraryExW(a: ARRAY OF CHAR;
b: HANDLE;
c: DWORD) : HINSTANCE;

helps if the names a, b and c are already used elsewhere

Post by tbreeden
It sounds as if the string table is full here.
If Stony Brook works like the ETH compilers, I suspect you must import
fewer modules to get any benefit, because the import pass reads into
the string table everything in the SYM files imported. It does include
indirectly imported stuff in the SYM file (but they will not be
duplicated in the string table).
I think you might look at breaking up the main program into
independent modules. If you can do this such that the resulting
modules do different functions you may be able to get by with
importing different subsets of all the definition modules into each
new module representing a section of the program.

[jan272]

Post by Wolfgang Greiner
At the moment I comment out unused constants in Libraries and save names
by "reusing" the parameters of Procedures in DEF-Files.
PROCEDURE LoadLibraryExW(a: ARRAY OF CHAR;
b: HANDLE;
c: DWORD) : HINSTANCE;
helps if the names a, b and c are already used elsewhere

A lot of work, but eventually you will run in another shortcoming of
the obsolete compiler.

The best solutions are (in order)
- use a more recent compiler for Linux or Windows (XDS, Mocka, GM2,
Gardens Point)
- use another language like Oberon (i.e. OOP for Modula)
- patch the compiler

All options are laborious. The longer you wait with choosing one of
these three, the harder it will be when you will be FORCED to abandon
SB.

[cvs]

Post by jan272

Post by Wolfgang Greiner
At the moment I comment out unused constants in Libraries and save names
by "reusing" the parameters of Procedures in DEF-Files.
PROCEDURE LoadLibraryExW(a: ARRAY OF CHAR;
                         b: HANDLE;
                         c: DWORD) : HINSTANCE;
helps if the names a, b and c are already used elsewhere

A lot of work, but eventually you will run in another shortcoming of
the obsolete compiler.
The best solutions are (in order)
 - use a more recent compiler for Linux or Windows (XDS, Mocka, GM2,

As far as I remember SB closed down in 2004 being a well maintained
product with great support; the last version of Mocka was released in
2006 but this was a maintainance release so the compiler would work
again with newer Linux systems. Development stopped years earlier
(already unmaintained in 2003 why it fell out of the SuSe
distribution). So while I think Mocka is a great compiler (and I would
like at least to see the homepage reappear at GMD) switching to it
would mean a switch to an even older one - the same aplies to GPM
(.NET-versions not counted) and XDS (became freeware in 2002 or 03,
maintainance only to keep the compiler working on newer systems).

Post by jan272
Gardens Point)
 - use another language like Oberon (i.e. OOP for Modula)
 - patch the compiler
All options are laborious. The longer you wait with choosing one of
these three, the harder it  will be when you will be FORCED to abandon
SB.

[jan272]

Post by cvs
As far as I remember SB closed down in 2004 being a well maintained
product with great support; the last version of Mocka was released in
2006 but this was a maintainance release so the compiler would work
again with newer Linux systems.

lets face it. modula-2 is not dead. it just never lived.

it is my preferred programming language. but I also prefer two
wheelers for transport. and linux as OS.

superficial is the word that describes best the current era. modula-2
has depth, so it does not fit in.

when you have a big program written in an obsoleted modula-2 compiler
you have to consider changing over to something more of this age. a
fine altenative to any wirthian language is mike spiveys obc
interpiler. see http://fruttenboel.verhoeven272.nl/obc/index.html
spivey is alive and working. obc is astonishing good and fast. and it
is cross platform.

it's time for a change.

[Chris Burrows]

Post by Wolfgang Greiner
Yes, I am afraid I will finally have to do break it up into
independent modules.

Have you tried contacting TERRA Datentechnik? They still advertise SBM2 for
sale:

http://www.terraterra.ch/modula-2/sb-m2-v4.html

Regards,
Chris Burrows
CFB Software
http://www.cfbsoftware.com/modula2

[jan272]

Post by Chris Burrows
http://www.terraterra.ch/modula-2/sb-m2-v4.html

the price list dates back to 1999....

but that doesn't mean a thing, of course... ;0)

[Chris Burrows]

Sorry long lost contact. In the same vein anyone still have a valid email
address for either of Bob Kushlis, or Scott Robbins?

Try looking for these on LinkedIn as well.

Chris.

[Chris Burrows]

Post by Wolfgang Greiner
Can anyone give me the email adress of Norman Black or Richard Gogesch?

Norman Black is contactable via LinkedIn:

http://www.linkedin.com

--
Regards,
Chris Burrows
CFB Software
http://www.cfbsoftware.com/modula2

[Rugxulo]

Hi,
What exactly does the program do?? I mean, damn, that's a big
project!! You should win the Wirth 2011 prize or something. You should
get a autographed letter of commendation in the mail any day
now. ;-))

P.S. I kinda agree with the other guy that switching compilers is
inevitable, but I sympathize that some are better than others at
certain things. You mentioned classes and generics, so presumably GM2
(or even CM3, perhaps!) would suffice. I know that's not what you want
to hear, but outside of a lot of workarounds or a minor miracle ....

Post by Wolfgang Greiner
we have a serious problem with StonyBrook Modula 2 Version 4.0 Build 31.
We maintain a huge project with 940 modules containing 700 thousand lines of
code and it is still growing.
2>> Internal error in file .\Main.mod at line 1
2>> -- Maximum names limit reached
2>> compiler-> Compiler exception
1>> Internal Error: Contact tech support
"Maximum number of unique identifier names per module/package = 65535.
 This includes symbols from all imported modules/packages."
It seems to include even the symbols in *indirectly* imported modules.
At the moment, we avoid the problem by commenting out unneeded
constants in DEF-Modules but this is only a temporary solution.

[Wolfgang Greiner]

Post by Rugxulo
Hi,
What exactly does the program do?? I mean, damn, that's a big
project!! You should win the Wirth 2011 prize or something. You should
get a autographed letter of commendation in the mail any day
now. ;-))

It´s a medical practice software.

Post by Rugxulo
P.S. I kinda agree with the other guy that switching compilers is
inevitable, but I sympathize that some are better than others at
certain things. You mentioned classes and generics, so presumably GM2
(or even CM3, perhaps!) would suffice. I know that's not what you want
to hear, but outside of a lot of workarounds or a minor miracle ....

We started over 20 years ago with TDI Modula with GEM/TOS (Atari ST) then
we switched to Megamax Modula and then we switched to Windows with
Stony Brook Modula.

You can imagine that switching compilers or even the OS is nothing I dream
of. 8-)

[jan272]

Post by Wolfgang Greiner
It´s a medical practice software.

Kalt!

Post by Wolfgang Greiner
We started over 20 years ago with TDI Modula with GEM/TOS (Atari ST) then
we switched to Megamax Modula and then we switched to Windows with
Stony Brook Modula.

in that case, switching compilers is a routine matter for you!

automate as much as possible and SELL the translator....

Post by Wolfgang Greiner
You can imagine that switching compilers or even the OS is nothing I dream
of.

resistance is futile. you have no choice, all options on SB are out.

perhaps you should contact dr Christian Maurer of FU Berlin. he's a
nice guy because he is german too.... he might have some sound ideas.