Integrator 2012: Panel insertion

I am now looking into one of the last missing features in I2012 which is inserting panels into a parent panel. This feature is potentially dangerous as one might cause infinite loops.

There are a couple of strategies I figured out in my mind:

  • sub-optimal: while rendering, the program keeps a count of the panel generation and if it goes past e.g. 10, it stops. The C64 engine could, however, loop forever even if I2012 does not.
  • optimal: detect an infinite loop at design time and prevent the insertion. This can get a bit tricky to implement as the loop might occur as a consequence of panels nesting into each other not directly but e.g. A contains B, B contains C, and C contain A.

I need to give things a thought. BTW, I found a similar discussion here. I will see what I come up with 🙂

This entry was posted in Retrocomputing, Technical and tagged , , , , , , , , , , . Bookmark the permalink.

5 Responses to Integrator 2012: Panel insertion

  1. Didi says:

    Dear Luigi,
    this is a nice, tricky problem! I think there´s only one chance, to solve it accurately. I can´t imagine a less effortful way other than doing this by using a recursive algorithm. You have to go through all possible branches, and each branch has to be checked separately & completely (from top to bottom) each time an iteration is added, if there´s a reference already occuring, or not.

    A one step more complex situation convinced me, that a shorter algorithm (with expanding a single list) would fail. For example:
    1 references to 2 and 3; 2 references to 4; 4 referenes to 3; 3 references to 5 and 2.
    So we get a loop in the first branch via 1 -> 2 -> 4 -> 3 -> 2.

    Hope this helps you forward to your personal solution!
    Didi 🙂

    • luigidifraia says:

      Hey Didi, thanks for that. I was able to put down a recursive algo this morning and I plan to implement it in the next few days 🙂

      • luigidifraia says:

        Code implemented! At the moment I am trying to understand why the compiler is complaining:

        [Warning] passing argument 1 of ‘g_slist_index’ from incompatible pointer type
        expected ‘struct GSList *’ but argument is of type ‘struct GSList *’

        Well, I see no incompatibility: what I pass is exactly what is expected. The compiler itself is confirming that 😀

        I’ll get back to this as soon as possible.

      • Didi says:

        Don´t forget to test your algorithm against false positives, besides loops occuring in the first/somewhere middle/last iteration-level/layer-depth. For example:
        1 uses 2 & 3; 2 uses 4 & 5; 3 uses 2 & 5; 4 uses 5; 5 uses 6.
        This is a nested case, but without any illegal loop. You may want to prevent illegal panel insertions ahead by filtering the loop-causing ones out, and not offering them in the selection list.
        I wish you great fun & success with your programming! And please don´t use virus-routines and that kind of stuff in your software in future times, otherwise there might be some ninjas knocking on your door some day!!! ;-D
        Didi

      • luigidifraia says:

        Yep, I see your point about false positives, Didi. I think I will put the implementation aside for a bit and go back to the abstract problem and check whether I can come up with a comprehensive test set to test with. I do believe the false positives as in your example are covered, but still there are a number of cases that I might not have thought of.

        I guess it’s clear now why this activity has been delayed for so long 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s