Definitely not. The same image stack is shared between all parallel runs, so accessing (insert/delete an image) should never be done in parallel (I mean, without a lock).
This wouldn’t make sense, as you wouldn’t be certain of the order of the insertions/deletions (not to say that an image referenced in one thread could be destroyed by another thread).
Stepping back: I just realized that using braces before or after the do/while statement introduces syntactic ambiguity for the interpreter when parsing G’MIC’s language. As a result, I’ll need to revert this change and disallow the use of opening and closing braces in do...while loop syntax.
I know @Reptorian has started to use them. But please, do not use them anymore, as it will work only until the next release (3.7.3). Thanks.
What kind of syntactic ambiguity?
In theory, this is not really an “ambiguity” in the language syntax, but it’s a kind of “local ambiguity” from the interpreter point of view.
Let me show you an example and explain the issue:
Currently, an error appears for instance, when one wants to break or continue a loop that contains a do...while sub-loop.
For instance, the code below should be perfectly valid:
foo :
repeat inf {
break
do { echo foo } while u<0.5
}
But when one tries to run it:
$ gmic foo
[gmic]./ Start G'MIC interpreter (v.3.7.2).
[gmic] *** Error in ./foo/ (file '/home/tschumperle/.gmic', line #208) *** Command 'while': Not associated to a 'do' command within the same scope.
Explanation of the issue:
To be as fast as possible, the break command actually counts imbrication levels of sub-loops encountered after the current break point, so that it can guess where to jump (what loop it has to break/continue).
In the example above, the code part ... } while ... is considered to be equivalent to ... done while ... by the interpreter (because in the more general case, } is a shortcut for done, except when used in the end of a do...while block). So the interpreter counts it as two “closing” commands rather than a single one.
As the break/continue commands analyzes only a very “local” view of the source code (once again, for performance reasons), they have no way to distinguish between ... } while ... and ... done while ..., thus counting only one level of closing (correct) instead of two (incorrect).
I’ve thought about just trying to spot the ... } while ... pattern and in this case, ignore the } part when I found it (like in this case, } doesn’t mean done, so only one level of closing), but that’s not correct either because there are cases where ... } while ... actually means ... done while ... ! Just like in this case:
foo :
do l { echo toto } while u<0.5
From an human perspective, this is obvious that here, as do is not followed by {, then while does not have to be preceded by } , so } while should be just equivalent to while.
But this reasoning implies the code analysis cannot stay local anymore. In particular, if you have multiple nested do...while loops, we (or the interpreter) will have to remember for each loop, if the loop starts with do { or just do.
In terms of language analysis, it would still be posssible to make the interpreter deal with that issue, but with the cost slowing down considerably the action of commands break and continue : The complexity of the code analysis to find the target point would be really higher.
That’s why I think it’s better just to not allow do { ... } while ... and stick with the unique syntax do ... while ... we had before.
EDIT: And cherry on the cake, keeping this unique syntax actually makes code analysis slightly faster for the interpreter!
1 Like
2026/03/16: Release of G’MIC version 3.7.3.
What happened to updates? gmic up does nothing.