[Lazarus] WriteLn back to the GUI

[Sven Barth]

Sorry, pressed Send by accident... -.*

Am 26.10.2013 02:30 schrieb "ListMember" <listmember at letterboxes.org>:
>
> On 2013-10-25 14:53, Sven Barth wrote:
>
>> In my opinion that energy is better put into getting e.g. fcl-passrc up
to date and keep it that way (so that at least each release can handle code
that the compiler also accepts).
>
>
> You're, of course, right.
>
> But, never mind the question of which part of what team will maintain it
(and what triggers a maintenance request, other than a long after-the-fact
bug report), how do you make sure that --at any moment in time-- fcl-passrc
is up-to-date?
>
> I mean, suppose --using fcl-passrc-- we went through all the publicly
available code (repositories of FPC, Lazarus, etc.) and it reported no
errors, would it prove/guarantee that fcl-passrc is up-to-date?
>
> If we could say that with enouh conjfidence, I'd gladly shift my focus to
fcl-passrc.
>

The main tests for what FPC supports and what not is for one compiling (or
in this context at least "parsing") the compiler's source, the RTL and the
packages. Additionally there are the tests which should either succeed or
dail to compile/run (and when a new feature is added at least one test is
added). So in my opinion the ability to correctly parse compiler, RTL and
packages sources plus correctly parsing all tests that should compile and
failing all tests that should fail would be enough in my opinion.

The main maintenance would be by the FPC team, but patches are welcome and
if someone (e.g. you) "proves worthy" he can get SVN write to the
fcl-passrc directory.

>
>> I already had the idea with DLLs once myself.
>>
>> As long as the interface for exchanging options (and maybe also unit
locations ;) )is kept stable or at least backwards compatible this should
work. And as long as the heaps are kept seperate unloading a compiler
library should also solve the problem with memory leaks... (maybe add a
function to the API to get the current heap state ^^)
>>
>
> Naturally <g> I know nothing about the importance of heap especially in
this context or probbaly in any relevant context.
>
> How hard would it be?

As non-shared heap is the default, this would be no problem ^^

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20131026/9bc13859/attachment-0003.html>