Sibyl developers

Martin Vieregg | 26 Jan 2006 12:57

"to do" things for WDsibyl

Hello,

Wolfgang and me have made a lot in the SPCC and if anyone is interested in getting some well-defined jobs, he
can ask Wolfgang.

I have seen that in the Windows SPCC, the components tEditList and especially tStringGrid (the table
component) do not work properly. If anyone likes to fix this bugs, you are welcome!!!

Then for the hardcore programmers, there's the need of reprogramming the getmem and freemem procedures in
system.pas or fixing the old code (a lot of assembler code). OS/2 and Windows do only allocate 4 kB parts of
memory and the program has to split this to smaller memory requirements. It seems that the code gets
defragmented in OS/2 and running Sibyl apps makes OS/2 slower on the long run; I myself have got problems in
making a proper shutdown after a long session of WDsibyl programming. Then a great number of getmem let
crash the application. You can test it with the editor which does not accept more than 10-20 MB text files.
(Normally there shouldn't be a limit.) Then I have casually crashes when using freemem. (The Windows
version is not tested yet at this point)
The freepascal.org compiler has this sources, but they are very complicated because of a great number of
supported OS. Perhaps we could catch the code from Gnu C.

-------------------

German:

Ich habe hier geschrieben daß ich und Wolfgang ziemlich viel Sachen in letzter Zeit gemacht haben und wir
gut Mitstreiter für klar umgrenzte Aufgaben brauchen könnten.

Eine leichtere Sache wären die Fehler in tStringGrid (Tabellencomponent) und tEditlist im Windows-Bereich.

Für unsere Hardcore-Programmierer wäre ein Neuschreiben oder Fixen von getmem und freemem
erforderlich, das bislang teilweise in Assembler geschrieben ist und wohl für einige Probleme

(Continue reading)

headers

Tomas Hajny | 26 Jan 2006 14:15

Re: "to do" things for WDsibyl

Martin Vieregg wrote:

Hello,

 .
 .
> Then for the hardcore programmers, there's the need of reprogramming the
> getmem and freemem procedures in system.pas or fixing the old code (a lot
 .
 .
> The freepascal.org compiler has this sources, but they are very
> complicated because of a great number of supported OS. Perhaps we could
> catch the code from Gnu C.

Actually, the main reasons for complexity of the FPC heap manager aren't
related to the number of supported platforms (there's no platform specific
code within the heap manager at all, AFAIK).

First of all, a heap manager is always a complex thing, and an efficient
one even more. Furthermore, there are always trade-offs between speed and
long-term memory usage (especially important for permanently running
processes like servers/daemons). Finally, there are inter-operability
issues resulting from a need to combine code created with different
compilers (e.g. using libraries written in C or whatever other language).
FPC heap manager tries to address all these issues (with not so bad
results, I'd say  ), and _that_ is the main source of complexity.

Let's start with the last two points: FPC heap manager is pluggable - you
can supply your own if it conforms to the specification. This addresses
both the inter-operability (you can use heap manager provided with some C

(Continue reading)