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

[Alois Zoitl <alois.zoitl@xxxxxx>]

Hi,

I spent the last weeks looking more detailed into FORTE code and
compiled stuff that could/should be cleaned in the future. Some of
these are breaking the FB APi and as promised I collected them together
in a wiki page [1].

Please have a look and let us know what you think on them. We are also
happy if you have any further ideas.

Cheers,
Alois

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



On Fri, 2018-08-10 at 16:51 +0200, Alois Zoitl wrote:
> 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
> 
> _______________________________________________
> 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