[teoz] [bug] [sequence] Activation is offset when with simultaneous deactivation

[valtusovs]

Describe the bug
When using teoz engine on the latest plantuml-1.2024.3.jar. When making a sequence diagram. When deactivating actor A and activating actor B, the B's activation box does not start at the arrow.

To Reproduce
Steps to reproduce the behavior:

Copy this file:

@startuml
!pragma teoz true

dummy -> A ++: first step

A -> A: test
A -> B --++: second step

B -> B: test
B -> C--: third step

@enduml

Save the resulting diagram.

Comment out "!pragma teoz true". Save the resulting diagram.

Expected behavior
The activation box of actor B starts at the "second step" arrow, like in the puma render.

Screenshots
teoz:

puma:

[jimnelson372]

I just wanted to let you know that I am looking at these teoz related lifeline issues. I've already found the solution for the --++ condition, but I'm looking at some related problems when & is used. So, my solution results in the teoz version looking very much like the puma version. Here's with my changes (not yet submitted):

[The-Lum]

Hi @jimnelson372

Could you have also a look on:

• Bug in calculating lifeline length backlog#9

@startuml
activate a
a -> a : put
deactivate a
@enduml

Thanks for your work.
Regards,
Th.

[jimnelson372]

Yes @The-Lum,

I had planned to return to the self message lifeline since for forum issue #15191 where the deactivation position changes depending on if it is the last message in the script or not.

In looking at the backlog#9 discussion, I realize the changes I needed to make to solve the --++ issue has stopped one of the workarounds for extending the self message activation, the use of delay as in:

@startuml
!pragma teoz true
activate a
a -> a : put
||0||
deactivate a
@enduml

For the --++ fix to work, I had to relax how many instructions away the deactivate occurs, since for --++ and some other conditions the activate could sometimes come before the deactivate and the processing was only looking at the very first of them (which is why --++ wasn't working). I had to do some additional relaxation in order to fix some of the parallel message issues. I haven't had a chance to see what it would take to get the ||0|| to force the delay in the deactivation again.

Also, I think we need both kinds of activation level endings on the self message. I notice that for the slanted messages, such as the following, PlantUML uses the arrow type to determine whether the deactivation should occur at the time the message is sent (if an async arrowhead ->>), or at the time the message is received (if it is a synchronous arrow head -> ).

b ->>(20) a --: async

Maybe self messages should have the same logic. Right now, it defaults to the form of a message return, where the source is deactivated and returns to the next lower state, as in:

@startuml
!pragma teoz true
a -> a ++: call
a ->> b: an async message happens\nwithin the call
a -->> a --: return
@enduml

Maybe there should be a new discussion or issue created for this. I'm not clear what the correct default and solution should be. Though I do believe I should restore the effect that ||0|| had prior to my other changes.

Jim N