[Lazarus] WriteLn back to the GUI

[Sven Barth]

Am 25.10.2013 12:52 schrieb "ListMember" <listmember at letterboxes.org>:
>
> On 2013-10-25 10:53, Sven Barth wrote:
>>
>> Am 25.10.2013 01:06, schrieb ListMember:
>>>
>>> One of my aims (one which we discussed here a few years ago) is to rip
the parser and lexer from the compiler. I want to have a token tree
(including directives) from the mouth of the horse (so to speak).
>>
>> That will be quite complicated, because the scanner will not output the
directives it parsed (e.g. if you do a "consume(_SEMICOLON)" to parse a ";"
any directive between your current position and the next ";" will be
handled and the parser will not be notified of any changes (as a result of
these directives there might be changes in settings variables or defines
however).
>
>
> Unless there's a lot more deeper magic than I can fathom, I am guessing
the parser is parsing the directives if only to ignore code in that
directive block.
>
> If this is so (is it?), can't I inject/override some code in there to
emit a token for the directive as well as make it also parse the blocks it
normally would ignore?
>

No, the parser will never see those. After all that's one purpose of
ifdefs: to keep the parser from reading things that is couldn't possibly
parse. Directives are completely handled by the scanner.

>
>> Also the tree is not really possible to get a hold of, because a node
(e.g. a fornode for a for-in) might be immediately replaced by a whilenode
thus you'll never see that there was a for-in.
>
>
> So, I will need to catch things before they get optimized/transformed
into something else.. I love these tricks/traps.. :)
>

This often happens inside the typecheck passes whereby the following code
might do things dependant on that result.

> But, yes, all these shortcuts/pitfalls (for what I want to do) are quite
discouraging, yet the flip-side means any alternative independent of FPC
will always be lacking.
>

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).

>>> After all, both FPC and all the IDEs (Lazarus, fpGUI, MSEide+MSEgui
etc.) use FPC but the degree of integration between them is lacking, IMO.
>>
>> Because by the way it currently is you can easily switch the compiler
version and the compiler target. Each compiled compiler can only compile
for one architecture (but each supported OS of that architecture), so how
would you implement cross platform compilation then?
>
>
> Couldn't it be done through DLLs?
>
> I mean, compile the compiler into a dll where the name is an easily
format that tells (say) Lazarus what version it is, and its native and
target platforms are.
>
> At that point, it would need a stable (yet an extendable) API, but it
seems it is doable.
>
> [This, if it works, does not preclude a standalone compiler; a shim-like
exe simply uses one of those DLLs.]
>
> Or, have I just reinforced the assertion that ignorance is bliss? ;)

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 ^^)

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