We love Lazarus and Pascal programming and anyone's best effort on this is deeply acknowledged.

Let us stick to the topic that unites us.

Etienne

Pascal walks into a bar
There are 100 000 Pascals in the bar!

Sorry, i am drunk. Keep bugs out of Lazarus!

On Wed, Dec 1, 2021, 14:13 Etienne Leblois via lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20211202/9dc265bd/attachment.html>

Sounds like you were pressured into making a joke...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20211202/f7a1e8be/attachment.html>

Op 1-12-2021 om 23:04 schreef Sergey Bodrov via lazarus:

Pascal walks into a bar There are 100 000 Pascals in the bar!

Nope, 100001, 100000 in the bar, and the one that just walked in.

That should be 33 in total!

On Thu, Dec 2, 2021 at 10:20 AM Marco van de Voort via lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20211202/1da871af/attachment.html>

Op 2-12-2021 om 10:19 schreef Marco van de Voort via lazarus:

... and then he left because there was no Atmosphere.

Since the subject is
"up with Lazarus"
can I ask one question as follows :

I have a Pascal program having ( around ) 12000 procedures and a small number of
units and it is compiled with Lazarus / Free Pascal only in Unix-like operating systems
such as Linux and FreeBSD .

(1)
After converting all of the variant records to non_variant records ( by removing "case " related part of its tag line , by keeping the tag variable ) ,

(2) There is no any "Initialization" , "Finalization" parts in units

(3) Nearly all of the constants , types , and records are marked with their unit names
such as Unit_A . constant_name , etc. .

Can I convert that program to JavaScript by using Lazarus ?

Later on I want to convert this program to C to link C sources from other permissively
licensed repositories directly and then use only C ( not Pascal any more ) , and use JavaScript
programs derived from that program where they are more suitable .

Your suggestions are appreciated very much .

With my best regards ,

Mehmet Erol Sanliturk

On Thu, Dec 2, 2021 at 12:57 PM Marco van de Voort via lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20211202/3bdd1043/attachment.html>

Op 2-12-2021 om 11:45 schreef Mehmet Erol Sanliturk:

 Can I convert that program to JavaScript by using Lazarus ?

Afaik the pas2js transpiler compiles to an low level javascript that might not be suitable for maintenance after. It is not intended for pascal to javascript source conversion, but to compile Pascal codebases to run on javascript only systems.

So this will probably all be manual converts.

Yes.

You can use pas2js to convert it to javascript; provided your program does not do any file IO or GUI, this should be relatively painlesss.

Michael.

This is not correct. The code is perfectly readable and maintainable. Some of the constructs used are of course specific to the pascal object language.

For instance I do all the debugging in Javascript, and this is perfectly doable. The code is very readable, and you should not have any problem stripping out what you think is too pascal-ish.

What you cannot expect to be able to do is recompile from pascal and have the compiler incorporate changes you made to the generated javascript.

Michael.

Thank you very much for your prompt replies .

After converting to C and JavaScript , Pascal will not be used for continuation of development .

I have another program set in Fortran about Statistical and Mathematical analyses .
These are convertible to C and working very well when they are executed .

I will continue to develop some parts for improvement in Fortran and then convert them
to C and push these programs as permissive licensed open sources into a suitable website maintaining such repositories ( as archived , enabling the people to use them freely without wasting them ) .

The Pascal program is an implementation of my PhD thesis about a multimedia knowledge base management system ( definition and management ) based on expert system rules .

The Fortran programs after conversion to C will be incorporated into this system and will become unusable independently .

Reason of leaving Pascal is to enable me to pursue the development by using a SINGLE language . Otherwise , I need to use Pascal , C and Fortran .

Another most important problem is the limitations of current operating systems .
The Lazarus / Free Pascal is able to generate excellently high quality machine code , but the
operating systems , both FreeBSD and Linux are tested , are not able to execute such a large
system , because the executable program is hitting the internal limit(s) of the operating systems and they are erasing the executable from the screen and terminating the run without any single message about why that action is applied .

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 .

This fact has blocked my development . Now I have decided to develop a NEW permissively
licensed operating system from SCRATCH by using mostly FreeBSD parts in C able to
manage ( not "Very" but ) "Large scale software stacks" .

This requires changes on ( design , implement ,test , maintain ) operations of software stacks
by using NEW compilation , linking ( actually not using it ) , and executing and testing , debugging of the programs distributed on not only NFS server networks but also using the Internet .

Process migration over distinct and different computing systems is a vital requirement because a knowledge base management system can not stop some computations over decades .

The problems are large and difficult to solve .

At present , the choice is

"To be or not to be . That's the only question ."

With my best wishes for all of you .

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

Op 2-12-2021 om 14:37 schreef Mehmet Erol Sanliturk:

ulimit limits? Does it also happen running as root?

Debian seems to have a 8k ulimit by default.  (type "ulimit -h")

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
unlimited
[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 because
such improvements will not solve the inherent problems in developing and using
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 produce
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 program
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 development
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>