[Lazarus] up with Lazarus !

Mehmet Erol Sanliturk m.e.sanliturk at gmail.com
Thu Dec 2 16:55:49 CET 2021

On Thu, Dec 2, 2021 at 4:43 PM Marco van de Voort <fpc at pascalprogramming.org>

> Op 2-12-2021 om 14:37 schreef Mehmet Erol Sanliturk:
> > The fault is not in the program . If it were in the program I am sure
> > that it would produce a proper run time error . There is no such an
> > error . The run is terminated from different parts of the program by
> > the OSes  after a ( large number of thousand ) recursive entries into
> > almost
> > all of the involved procedures covering a very large portion of (
> > around ) 12000 procedures during transaction processing which involves
> > more recursions with respect to query .
> > When only the query part is used there is no problem . During small
> > transaction usage , again
> > there is no problem . Increasing system defined run time stack size is
> > not changing anything .
> >

> ulimit limits? Does it also happen running as root?
> Debian seems to have a 8k ulimit by default.  (type "ulimit -h")
> <-------- This limit is defined for shell .

At present my NFS server has not been running for more than a few years .
If I start it I need to determine how to restart my work . This will take
some time .

I did not try Debian . Many years ago I  attempted to use Debian , but
I found that Mandriva was more suitable for me . When Mandriva closed down
, I switched to Fedora .

At present I am using Fedora 25 :

[s at localhost ~]$ uname -a
Linux localhost.localdomain 4.13.16-100.fc25.x86_64 #1 SMP Mon Nov 27
19:52:46 UTC 20
17 x86_64 x86_64 x86_64 GNU/Linux
[s at localhost ~]$

[s at localhost ~]$ ulimit -h
bash: ulimit: -h: invalid option
ulimit: usage: ulimit [-SHabcdefilmnpqrstuvxT] [limit]
[s at localhost ~]$ ulimit -H
[s at localhost ~]$

[s at localhost ~]$ ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 30781
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 30781
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
[s at localhost ~]$ uname -a
Linux localhost.localdomain 4.13.16-100.fc25.x86_64 #1 SMP Mon Nov 27
19:52:46 UTC 20
17 x86_64 x86_64 x86_64 GNU/Linux
[s at localhost ~]$

Now I do not want to attempt to "improve" the existing operating systems
such improvements will not solve the inherent problems in developing and
large scale software stacks .

Reasons are shortly defined below .

My opinion about developing a new ( distributed and able to manage large
software stacks )
operating system is really a very important goal , because the existent
methods about
software development and maintenance is causing large amount of losses (
time , effort ,
money , ... ) . This structure based on ( let's say around )  1970
technology levels
are not suitable for today's requirements .

Many years ago when there was a need to a "secure programming language" for
large military system supporting software , the Ada is selected , but
failed ,
( with respect to my memory ( which I may be wrong )) because

(1) Ada was not able to compile itself due to its design ,
(2) The Ada compiler written in a "not-secure language" such as C could not
      a "secure compiler" for Ada .

In those days , ( I do not remember name of the computing scientist who
expressed the idea )
the expressed idea was " ... the present day software systems can not
support development of required secure software for such a large military
system ... " .

Software development ( with all its components ) is not different from
construction of buildings conceptually :

It is possible to construct a 1-storey building by using earth-bags , but
you can not stack
three of them to construct a 3-storey building . You need to use brick at
least .

You can not construct a 9-storey building buy stacking three 3-storey
buildings constructed
from brick : You need to use concrete .


Such technology and material changes are required during construction of
taller and taller
buildings .

During development of my program I have encountered a similar problem .

When the size of the program increased , it became necessary to change the
development system . When the size  of the program increased to a larger
level ,
the used method again collapsed , it became necessary to change the program
method once more .

These changes became necessary during increasing size of the program .

All of the ideas presented in "Software Engineering" literature usable in
small programs ( because they derived from small program projects )
are becoming useless  during increasing size of the program .

Instead of attempting "patching" of existing systems ( OS , compilers ,
etc. ) which they are
developed for small systems and have significant problems for management of
them ,
it is necessary to start a new set of software systems with a suitable
design and implementation .

Mehmet Erol Sanliturk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20211202/f765bc09/attachment-0001.html>

More information about the lazarus mailing list