Re: [Liberty-eiffel] compiler internals: live features

[Cyril ADRIAN]

Raphael,

I'm glad I misunderstood you.

Indeed the list traffic is not so high that we need yet another list. I also hope that discussing the compiler itself on this list will trigger some vocations :-)

Cheers,

Cyril

2014-09-15 20:29 GMT+02:00 Raphael Mack <address@hidden>:

Hi there,

I fear you misunderstood me. I NEVER wanted to make the list private and would even have recommended everyone to subscribe there too, I just thought of a separate list for details about compiler internals to allow simpler filtering. But: when I think of what should go on which list, it may sometimes be hard to make the right decision, so until the message count is too high we should stay with a single list ;-)

Regards,
Rapha

BTW: it is great to read message from new "names": warm welcome. If you want to tell a few words about yourselves: I'd be interested in what you do (in general, with Liberty) and who you all are!

Zitat von Cyril ADRIAN <address@hidden>:

Hi Rapha,

2014-09-14 20:22 GMT+02:00 Raphael Mack <address@hidden>:

as this might be interesting for any hacker who wants to read some
details, I suggest to discuss this publicly. @all: please tell us, if you
think this is too much for the public mailing list - then we might want to
add some "liberty-internals" list. If not and you are interested follow the
discussion and start providing patches for Liberty ;-)

SmartEiffel had a private discussion list. I don't intend to reproduce the
same mistake. Development should happen exclusively in public.


Zitat von Cyril ADRIAN <address@hidden>:

too. Don't hesitate to ask questions, I am not that good at explaining the
whole architecture from scratch.

so here is one:
assume we have an expanded type FILE_TOOLS, without any attributes and
another expanded class CLASSES_TREE_FACTORY with a single attribute
file_tools: FILE_TOOLS.

The struct for CLASSES_TREE_FACTORY is reduced to an int, which is good,
but the introspection doesn't currently work with this.

So would you consider the attribute CLASSES_TREE_FACTORY.file_tools a live
feature? - I'd think so, as it IS used, we only have not to emit the
attribute into the type struct...

I see your point: I overlooked the attribute generation in se_printT(). Is
that what you mean by "introspection doesn't work"?


And: who is responsible to detect the set of live types and features?

The `collect` feature. It traverses the whole tree from the main creation
feature (the one on the command line or in the ACE file) and marks
everything alive that it can reach. Secondary roots are CECIL calls.

See CODE.collect and SMART_EIFFEL.collect_from_root

Cheers,

Cyril