Having #show <> lines in the encoding raises an unrelated "element not found" error

[TamaraAtanasoska]

It seems that the additional atoms that these lines produce raise an "element not found" error, and point to an unrelated element. It would be great to either ignore their output, force comment the line #show <> while running the program, or maybe catch this and show a more informative error.

[susuhahnml]

Hi! Do you have an example for this? Or which lines do you mean by "these lines"?

[TamaraAtanasoska]

Hi! Do you have an example for this? Or which lines do you mean by "these lines"?

Sorry, that wasn't clear enough. I meant the lines that start with #show. I used the same file to run just in clingo and whenever I had these trailing lines starting with #show at the bottom of the file I normally ran with clinguin(the file where my logic rules lived), I would get an error that would point to a random unrelated element in the context of the "element not found" error. The code is here, but the file is private as part of the course and I can't make it public. I can send the project maybe by email, or is there a way to ask @javier-romero to add you there? They are currently commented out at the bottom, but once uncommented the error pops up.

[javier-romero]

Hi, I just gave @susuhahnml access to the repo of @TamaraAtanasoska.

[TamaraAtanasoska]

Thank you very much @javier-romero 🙏 @susuhahnml if you uncomment the lines starting with #show at the bottom and run the contents in the /src repository as you would do normally with clinguin, the error should happen. Let me know please if it reproduces in your machine, if not I will look into simplifying it or looking into why it happens in my setup specifically.

[alexl4123]

Hi @javier-romero,

could I also have access to the repo (or to another example where the error occurs, to reproduce the error), as I was not able to reproduce the error locally?

[javier-romero]

Hi @alexl4123, I can do that if @TamaraAtanasoska is fine with it.

@TamaraAtanasoska: can I give @alexl4123 (who works with @susuhahnml) access to your repo?

[TamaraAtanasoska]

@javier-romero yes absolutely! @alexl4123 you can look at the commits maybe and their messages, there might be something there too(I don't remember any more exactly). I am also fine if you'd like to have a short call if it is still not working out, I can reproduce it on my machine and we can see what is setup specific.

[javier-romero]

Thank you @TamaraAtanasoska!

@alexl4123: you should have received the invitation

[alexl4123]

Hi @javier-romero and @TamaraAtanasoska
thanks a lot and I received the invitation :)
I'll keep you updated on this issue.

[alexl4123]

Hi @TamaraAtanasoska and @javier-romero :)
I have good news, on the development branch this issue should be fixed now.

The essential issue was that when a ''#show'' statement was specified, only those atoms (with a ''#show'') were used as input to the second solve phase (which is relevant for the UI). Therefore certain atoms which are needed by the UI might not be present, which in turn led to the behavior you faced. In more detail, this led to the issue of the UI being a forest instead of being a tree.

Now it is assured that always all atoms are taken into account, those with and those without a show statement :)

[TamaraAtanasoska]

Awesome @alexl4123! Thanks for taking a look and finding the root cause 🥇