{"action":"created","issue":{"url":"https://api.github.com/repos/gnuradio/pybombs/issues/329","repository_url":"https://api.github.com/repos/gnuradio/pybombs","labels_url":"https://api.github.com/repos/gnuradio/pybombs/issues/329/labels{/name}","comments_url":"https://api.github.com/repos/gnuradio/pybombs/issues/329/comments","events_url":"https://api.github.com/repos/gnuradio/pybombs/issues/329/events","html_url":"https://github.com/gnuradio/pybombs/issues/329","id":154535175,"number":329,"title":"max recursion depth for $variables that cannot be found","user":{"login":"gr-sp","id":7341168,"avatar_url":"https://avatars.githubusercontent.com/u/7341168?v=3","gravatar_id":"","url":"https://api.github.com/users/gr-sp","html_url":"https://github.com/gr-sp","followers_url":"https://api.github.com/users/gr-sp/followers","following_url":"https://api.github.com/users/gr-sp/following{/other_user}","gists_url":"https://api.github.com/users/gr-sp/gists{/gist_id}","starred_url":"https://api.github.com/users/gr-sp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gr-sp/subscriptions","organizations_url":"https://api.github.com/users/gr-sp/orgs","repos_url":"https://api.github.com/users/gr-sp/repos","events_url":"https://api.github.com/users/gr-sp/events{/privacy}","received_events_url":"https://api.github.com/users/gr-sp/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/gnuradio/pybombs/labels/bug","name":"bug","color":"fc2929"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2016-05-12T17:15:10Z","updated_at":"2016-05-13T19:20:17Z","closed_at":null,"body":"I was attempting to build a recipe that had a custom $variable in the configure line of the recipe and I was presented with:\r\n`RuntimeError: maximum recursion depth exceeded while calling a Python object`\r\n\r\nAfter a little sleuthing I determined the cause: `var_replace_all` in recipe.py looks for `n_subs == 0` before it will return. However, for each match of each $variable for which a value cannot be found, that $variable is placed back into the substitution string and n_subs is incremented.\r\n\r\nE.g., in the string `\"hello $dolly\"` if a value cannot be found for `$dolly`, then `$dolly` is placed back into the returned string (by the `var_replace` function) and the returned string is the same as the input string (`\"hello $dolly\"`). When this happens the return value from `var_re.subn(var_repl, s)` is `(\"hello $dolly\", 1)` even though an actual substitution was not made. I think this is because the count (returned by `subn`) doesn't represent the number of substitutions but the number of times a match occurs; and the number of substitutions is assumed to equal the number of times a match occurs. But since we cannot find a value appropriate for the `$dolly` variable we substitute it with itself. There doesn't appear to be a mechanism for indicating to the `subn` method from the `var_replace` function that a substitution did not actually occur.\r\n\r\nSo, the end result is that `n_subs == 0` is never `True`.\r\n\r\nIgnoring the test for `n_subs == 0` and simply returning `s` from the method seems to work for me. However, I am reluctant to say that this a fix because I assume that someone had a reason for using `re.subn` and then performing a recursion instead of using `re.sub` with no recursion; I just don't know what that reason was."},"comment":{"url":"https://api.github.com/repos/gnuradio/pybombs/issues/comments/219136064","html_url":"https://github.com/gnuradio/pybombs/issues/329#issuecomment-219136064","issue_url":"https://api.github.com/repos/gnuradio/pybombs/issues/329","id":219136064,"user":{"login":"gr-sp","id":7341168,"avatar_url":"https://avatars.githubusercontent.com/u/7341168?v=3","gravatar_id":"","url":"https://api.github.com/users/gr-sp","html_url":"https://github.com/gr-sp","followers_url":"https://api.github.com/users/gr-sp/followers","following_url":"https://api.github.com/users/gr-sp/following{/other_user}","gists_url":"https://api.github.com/users/gr-sp/gists{/gist_id}","starred_url":"https://api.github.com/users/gr-sp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gr-sp/subscriptions","organizations_url":"https://api.github.com/users/gr-sp/orgs","repos_url":"https://api.github.com/users/gr-sp/repos","events_url":"https://api.github.com/users/gr-sp/events{/privacy}","received_events_url":"https://api.github.com/users/gr-sp/received_events","type":"User","site_admin":false},"created_at":"2016-05-13T19:20:17Z","updated_at":"2016-05-13T19:20:17Z","body":"I'll check it out sometime in the next few days...no problem. At a glance it looks like it would work.\r\n\r\nHowever, I would like to suggest that this is an \"all stop\" error. If there is a replacement variable in a recipe that can't be found, then I would argue that a missing configuration variable is a major problem. Of course, it totally depends on the specific variable in question as to the level of impact. But, let's assume that it's possible that somehow \"prefix\" is missing from the configuration (although this is extremely unlikely). What kind of impact would it have on the build if every instance of `$prefix` in every recipe was replaced with an empty string. To top it off, it would happen silently.\r\n\r\nI am thinking this would be a disaster for the user and the error they get may not even lead them to the conclusion that the \"prefix\" configuration value is missing. Obviously this is an extreme case, but I could imagine that someone would use a configuration variable liberally throughout a set of recipes and that configuration variable could be quite important for their use case. If it is a path (or part of a path) to a directory or a file it could be very bad."}}