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.
2026/04/30: Release of G’MIC 3.7.5.
1 Like
Had to dig (since I’m still on 2.10x; lol), but the update works well; the preview operation (and subsequent execution of preset) seems faster to me as well, but I could just be imagining things. lol
2026/05/13: Release of G’MIC 3.7.6.
Compiling 3.7.6 for Gimp 3.2.4 (PPA) and kubuntu 24.04
…just wondering… Source code a good bit smaller than 3.7.5
No CImg.h and gmic_stdlib_community.h in the file. Not a problem as they are pulled in providing you are online. Offline …then compile fails. …just wondering
Edit: better say the 3.7.6 plugin works fine
1 Like
Thanks @rich2005 .
Indeed, there must be something wrong in my source package building script.
I’ve fixed this issue for 3.7.6 “manually” though.
Thanks for letting me know !
Today, I’ve started the work on next milestone for G’MIC, which will be version 4.0.0.
The idea is to build a version of G’MIC where the language syntax and API is frozen, and where developement will be focused on stability and performance afterwards.
After almost 18 years of evolving the G’MIC scripting language, I’ve converged on a language that feels close to what I had in mind: concise, powerful, and generic enough to code pretty much whatever you want with it (even things that can be quite far removed from image processing 
).
I’ve already released a pre-version on the G’MIC website, so feel free to test and report any bugs or strange behaviors !
Thanks!
1 Like
I kind of like the {:string} idea. By the way, there’s a pull request in gmic-community regarding a documentation of my library for others to use. I kinda wanted to wait till to the end of the year to mention that, but now that 4.0.0 is on the horizon, I thought to mention it.
Salut David,
I took a look at the 4.0.0_pre version with GIMP 3.2.2 on Xubuntu 26.04.
I tried most of the filters in the “official” section (so not in testing) and most of them seem to work correct.
A few notes though.
-
In the About section > What’s new? there is some computer code on the top of the list, like so.
-
Filter Dreamy watercolour gives an error :
- Preview error when using Upscale_CNN2x :
Well, this was a good occassion to revisit your incredible set of filters, I saw quite some new ones. Thanks for working 18 years on G’MIC plus the years before on GreyCstoration, kudos !
1 Like
Hi @paulmatthijsse ,
That’s a very useful test, thank you !
Concerning your issues:
- What you see in the What’s New section is a japanese translation of some of the filters. I thought I had disabled that but apparently, this is not the case. I will check that!
- About Dreamy Watercolour : Indeed, I’ve completely recoded the filter ‘Transfer Color [Variational]’ (will made an announcement later about this), so I need to fix the code of Dreamy Watercolour to call the new filter.
- About the Upscale_CNN2x : It seems the neural network data you have locally on your disk uses quite old G’MIC commands. Could you please try the ‘Update Neural Network’ button, it should download an updated version of the network file ?
Thanks again for the tests and the encouragements !
Argh, that’s not expected :/. Will investigate this as well.
This comes and goes. I wonder if there is a more better way of keeping this at bay…
Well, a compile for 'buntu 24.04 / Mint 22 and Gimp 3.2.4 (PPA) / QT5 (plugin only)
No problems here with dreamy_watercolor. Neural networks updated and Upscale CNN2x works (although slowly)
No point being too serious about anything.
1 Like
Hi @paulmatth ,
Just in case you have a little time. I’d be interested in getting a G’MIC log to analyze the crash of the plug-in with the [CNN2x] Upscale filter when you click the “Update Neural Network".
Would it be possible for you to enable logging in hte G’MIC-Qt (an option in the settings; select Output Messages → Debug (Log File))?
Then, select the filter, make it crash and send me the file %APPDATA%/gmic/gmic_qt_log ?
(without doing anything else with G’MIC of course ).
That would help a lot!
Thanks by advance,
D.