Re: [4diac-dev] Proposed Breaking Changes for FORTE 1.10.0

[Alois Zoitl <alois.zoitl@xxxxxx>]

Hi,

as promised I wanted to give a little bit of summary on discussions
happening on mattermost on this topic. Yes we had quite some discussion
about this. 

To summerize it especially the second point would require even further
breaking changes. As I found in the mean-time a workaround that seems
for my first use-case even better I would like to refrain from
introducting the breaking changes in 4diac 1.10. 

Nonetheless I think we'll need to introduce some breaking changes in
FORTE and therefore I'm currently collecting all ideas so that we can
have most breaking changes within one release and hopefully then again
a long time of stableness the same as we had it for the last 8 years or
so. 

To already add a further topic: I think the time has come to allow the
standard C++ library into forte core. It could help us in reducing the
code complixity and improve performance in several places. And also
reduce some memory overhead (e.g., storing the fbs in the resources).
However I know that this can be quite problematic therefore I would
always do benchmarks and secondly I would call out if you have
platforms that do not offer a standard library. Please let us know!! 


I'm currently not sure where to collect them. An option would be the
4diac wiki [1]. What do you think?

Cheers,
Alois

[1] https://wiki.eclipse.org/Eclipse_4diac_Wiki


On Mon, 2018-07-30 at 09:06 +0200, Alois Zoitl wrote:
> Hi,
> 
> for quite some time I’m pondering about a breaking change in FORTE.
> Today I worked on monitoring of subapps there I noticed that we are
> also missing some information in FORTE that would result in a further
> breaking change in FORTE. Therefore I would like to present both here
> and get your feedback on how to proceed:
> 
> 1. The first change regards the handling of the
> CEventChainExecutionThread (CECET) within FBs. Currently on reception
> of an event the calling CECET is stored in an FB member var and then
> used for sending output events. This has the advantage that it does
> not
> need to be handed down the call stack within the FB (e.g.,
> executeEvent, enterStatexxx, sendOutputEvent). However it has the big
> drawback that each FB needs to have storage to for this pointer. As
> our
> typical call stack is most of the time 2 or 3 already after having
> more
> then 3 or 4 FBs in your device less memory would be used if we would
> not store this pointer. Furthermore it would make some concurrency
> issues easier. Therefore I would like to propose to remove the
> storage
> to CECET within FBs and move it to the stack. 
> 
> 2. The second change I would like to propose is required for
> monitoring
> subapps. Currently we manage FBs within resources following their
> sub-
> app hierarchy in so called FB containers. However for backwards
> compatibility FBs are not aware of this data structure and store only
> a
> pointer to their resource. Therefore it is  not possible for FBs to
> retrieve their full qualified name consisting of the subapp hierarchy
> they are contained in. In order to allow this a required change would
> be to change the reference to the resource to a reference to the fb
> container. As part of this change the constructor sequence of FBs
> would
> change.
> 
> I see both changes important for the future of FORTE. However both
> changes would require that all existing FBs will need adjustments and
> a
> new code generator would be required. Therefore putting this here for
> discussion. Maybe you have better ideas for solving this issue. 
> 
> Cheers,
> Alois
> 
> P.S.: If it is easier for you we can also discuss certain parts of
> this
> problem on the 4diac matter most channel (
> https://mattermost.eclipse.or
> g/eclipse), and I’ll put the outcomes to the mailing list.
> _______________________________________________
> 4diac-dev mailing list
> 4diac-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/4diac-dev