Despite various approaches to get the behaviour of group export and batch arrz export right (see #828 (comment)), inconsistencies in the generated code file(s) may still occur as the tests for #1235 revealed:
In certain cases, the code for shared subsroutines may be duplicated (one copy undue in the common library module, other copies in some of the dependent modules). It can be demonstrated by loading both the arrz files contained in the attached zip archive (unzip it first) into Arranger (where one of them ‒ PersonsAndDates.arrz ‒ is incomplete and refers to includables and routines of the other ‒ DateStuff.arrz) and then exporting PersonsAndDates_arrz, which contains two main diagrams, to e.g. Pascal or Oberon.
Issue1236_sample.zip
See the arrangement index:
The reason seems to be that some of the commonly used routines (isEarlierThan(2), writeDate(2), askDate(1)) are only indirectly referenced by one of the mains but directly referenced by the other one. So they may not have appeared as obviously shared from the top level and it slipped through that they depend on identical subroutines. In the event, they (and their subroutines) occur twice, hidden in both the library module and one of the main modules.
The exported code would work after having been cut into the suggested part files but the resulting redundancy is hardly acceptable. In addition, the second copy of the routine (typically in its due module) is lacking declarations (because they had been claimed by the first copy).
Despite various approaches to get the behaviour of group export and batch arrz export right (see #828 (comment)), inconsistencies in the generated code file(s) may still occur as the tests for #1235 revealed:
In certain cases, the code for shared subsroutines may be duplicated (one copy undue in the common library module, other copies in some of the dependent modules). It can be demonstrated by loading both the arrz files contained in the attached zip archive (unzip it first) into Arranger (where one of them ‒ PersonsAndDates.arrz ‒ is incomplete and refers to includables and routines of the other ‒ DateStuff.arrz) and then exporting PersonsAndDates_arrz, which contains two main diagrams, to e.g. Pascal or Oberon.
Issue1236_sample.zip
See the arrangement index:
The reason seems to be that some of the commonly used routines (
isEarlierThan(2),writeDate(2),askDate(1)) are only indirectly referenced by one of the mains but directly referenced by the other one. So they may not have appeared as obviously shared from the top level and it slipped through that they depend on identical subroutines. In the event, they (and their subroutines) occur twice, hidden in both the library module and one of the main modules.The exported code would work after having been cut into the suggested part files but the resulting redundancy is hardly acceptable. In addition, the second copy of the routine (typically in its due module) is lacking declarations (because they had been claimed by the first copy).