{"action":"created","issue":{"url":"https://api.github.com/repos/fsantanna/ceu/issues/45","labels_url":"https://api.github.com/repos/fsantanna/ceu/issues/45/labels{/name}","comments_url":"https://api.github.com/repos/fsantanna/ceu/issues/45/comments","events_url":"https://api.github.com/repos/fsantanna/ceu/issues/45/events","html_url":"https://github.com/fsantanna/ceu/issues/45","id":115005168,"number":45,"title":"Emit statement never returns","user":{"login":"mterber","id":13783234,"avatar_url":"https://avatars.githubusercontent.com/u/13783234?v=3","gravatar_id":"","url":"https://api.github.com/users/mterber","html_url":"https://github.com/mterber","followers_url":"https://api.github.com/users/mterber/followers","following_url":"https://api.github.com/users/mterber/following{/other_user}","gists_url":"https://api.github.com/users/mterber/gists{/gist_id}","starred_url":"https://api.github.com/users/mterber/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mterber/subscriptions","organizations_url":"https://api.github.com/users/mterber/orgs","repos_url":"https://api.github.com/users/mterber/repos","events_url":"https://api.github.com/users/mterber/events{/privacy}","received_events_url":"https://api.github.com/users/mterber/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/fsantanna/ceu/labels/bug","name":"bug","color":"fc2929"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2015-11-04T09:05:21Z","updated_at":"2015-11-06T10:33:35Z","closed_at":"2015-11-05T20:35:12Z","body":"Hi,\r\n\r\nthe problem reported in #44 is fixed and doesn't appear anymore. But still my code doesn't behave the same way as it did before. So I guess issue #44 might not have been the root cause. I investigated the problem again and noticed that it appears in the following szenario:\r\n\r\n<pre><code>\r\ninput void KILL;\r\n\r\nclass OrgA with\r\n\tevent void evtA;\r\n\tevent void evtB;\r\ndo\r\n\tloop do\r\n\t\twatching evtA do\r\n\t\t\tloop do\r\n\t\t\t\tloop i in 3 do\r\n\t\t\t\t\tawait 1s;\r\n\t\t\t\t\t_printf(\"work!\\n\");\r\n\t\t\t\tend\r\n\t\t\t\temit evtB;\r\n\t\t\tend\r\n\t\tend\r\n\t\t_printf(\"exit WATCHING\\n\");\r\n\tend\r\nend\r\n\r\nclass OrgB with\r\ndo\r\n\tvar OrgA a;\r\n\t\r\n\tloop do\r\n\t\tawait a.evtB;\r\n\t\t_printf(\"before EMIT\\n\");\r\n\t\temit a.evtA;\r\n\t\t_printf(\"after EMIT\\n\");\r\n\tend\r\nend\r\n\r\nvar OrgB b;\r\n\r\nawait KILL;\r\n\r\nescape 42;\r\n</code></pre>\r\n\r\nThis one provides the following output:\r\n<pre><code>\r\nwork!\r\nwork!\r\nwork!\r\nbefore EMIT\r\nexit WATCHING\r\nwork!\r\nwork!\r\nwork!\r\nwork!\r\nwork!\r\nwork!\r\n... and so on ...\r\n</code></pre>\r\n\r\nMeans the <i>emit a.evtA</i> statement of 'OrgB' is never left! And this is exactly the problem I noticed in my code since I use newer versions of the Céu compiler.\r\n\r\nI guess the problem might appear because evtB is emitted within the watching block in 'OrgA' and in the same reaction chain that processes evtB the wachting block is terminated by 'OrgB' by emitting evtA. So this might be some kind of <b>\"we are sawing off the branch we are sitting on\"</b> problem!?\r\n\r\nIn the older version 89af57dc8d7eb9173daa7d96288f3c9efc9d624d of the Céu compiler the same code generates the following output:\r\n\r\n<pre><code>\r\nwork!\r\nwork!\r\nwork!\r\nbefore EMIT\r\nexit WATCHING\r\nafter EMIT\r\nwork!\r\nwork!\r\nwork!\r\nbefore EMIT\r\nexit WATCHING\r\nafter EMIT\r\nwork!\r\nwork!\r\nwork!\r\nbefore EMIT\r\nexit WATCHING\r\nafter EMIT\r\nwork!\r\nwork!\r\nwork!\r\n... and so on ...\r\n</code></pre>\r\n\r\nThe latest would be the expected behaviour (from my understanding)."},"comment":{"url":"https://api.github.com/repos/fsantanna/ceu/issues/comments/154374701","html_url":"https://github.com/fsantanna/ceu/issues/45#issuecomment-154374701","issue_url":"https://api.github.com/repos/fsantanna/ceu/issues/45","id":154374701,"user":{"login":"mterber","id":13783234,"avatar_url":"https://avatars.githubusercontent.com/u/13783234?v=3","gravatar_id":"","url":"https://api.github.com/users/mterber","html_url":"https://github.com/mterber","followers_url":"https://api.github.com/users/mterber/followers","following_url":"https://api.github.com/users/mterber/following{/other_user}","gists_url":"https://api.github.com/users/mterber/gists{/gist_id}","starred_url":"https://api.github.com/users/mterber/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mterber/subscriptions","organizations_url":"https://api.github.com/users/mterber/orgs","repos_url":"https://api.github.com/users/mterber/repos","events_url":"https://api.github.com/users/mterber/events{/privacy}","received_events_url":"https://api.github.com/users/mterber/received_events","type":"User","site_admin":false},"created_at":"2015-11-06T10:33:35Z","updated_at":"2015-11-06T10:33:35Z","body":"According to your new approach your example would look like this:\r\n\r\n<pre><code>\r\ninput void I;\r\nevent void e, f;\r\npar do\r\n    watching e do // 5\r\n        await I; // 1\r\n        emit f; // 3, aborted on 5\r\n// -----------------------------------------\r\n// code, that never executes\r\n// -----------------------------------------\r\n    end\r\n    await I;\r\n    escape 42;\r\nwith\r\n    await f; // 2\r\n    emit e; // 4, aborted on 5\r\n    _assert(0);\r\nwith\r\n    async do\r\n        emit I;\r\n        emit I;\r\n    end\r\nend\r\n</code></pre>\r\n\r\nSo what exactly is the difference between this approach and the behaviour before you introduced the \"new semantics\"? Isn't it the same?"}}