[Oberon] Bluebottle limits reached

Dan Parnete dan.parnete at fastwebnet.it
Mon Mar 6 09:37:22 CET 2006

Roger Keller ha scritto:

>>After some days a server module without any COSNT declaration has 
>>reached the limit due to the huge SQL select statements it 
>>contains. I 
>>have solved it in some way, but this limit is definitely to low.
>wouldn't it be much more logical to store stuff like sql statements in any
>data file outside the code? wouldn't that be much better design?
In fact, after than incident, we store the sql statements in the XML 
database of framework.

>about the const section limits: the limit is coming from the compiler, not
>the object file format. in fact it's the compiler that generates the const
>section. there's not limit (except for the 2G limit of LONGINT) from the
>object files. so the thing that's new in the compiler is, that *every*
>constant that is exported is written to the const section (such that - later
>- the compiler can optionally use other module's constants from their
>respective const sections). on the other hand, every string you write (such
>as: AosOut.String("foo");) is added to the const section, of course.
That has decreased drastically the explicit CONST section capacity.

>so if you do reach the 16K limit with your libs and apps with the new
>release, isn't it rather likely that also with the old release you would,
>sooner or later, reach this limit?
That's obvious. The question is: is it necessary to keep this limit on 
16K, spacial after you have brake the 64k module limit? It looks to be so.
Our job is to find always a solution to a problem. The only question is 
witch is the best?
- to play inside the actual limits, for how long?
- to wait your decision to enlarge this limits, for how long?
- to try to build a tuned Bluebottle for our needs? it could be a good 
solution, but I'm not able to quantify the time it needs.
- to forgot the Bluebottle server and build a BBw Windows service  (and 
a Linux one)? I don't like it very much, it sound like a divorce.

All the best,
Dan Parnete

More information about the Oberon mailing list