I agree, but am being a Devil’s advocate — and when I actually do bring name documentation into currency, I should like all my ducks in a row, and quacking on key. Thank you for the clarification.
1 Like
I made the changes.
Now, there are only three rules 
:
$ gmic h name
name (+):
"name1","name2",...,"nameN"
Set names of selected images.
* If no explicit image selection is given, image selection is assumed to be '[-N--1]', where 'N' is the number of specified arguments.
* If 'N' is higher than the number of images in selection, an error is thrown.
* If 'N' is lower than the number of images in selection, image names are assigned in a periodic way, i.e. 'name(selection[k]) = arg[k%N]'.
(equivalent to shortcut command '=>').
Example:
[#1] image.jpg name image blur[image] 2
Tutorial: https://gmic.eu/tutorial/name
1 Like
Excellent. Now I have to catch up the tutorial — maybe with some Funday! examples. Cheers!
1 Like
Ok, seems to work as stated (on MacOS)!
Still the (for me) new differentiation of selection ‘name A,B,C’ (all images selected, implicit) and ‘name[^] A,B,C’ (all images selected but none, explicit selection) should be documented. For name purposes its not bad to avoid numerous images named equally.
I think for scripting it could be helpful to know too, e.g. by the number of images in the list, negative (implicit), positive (explicit)
Well, that is what I’ve done, by telling about the implicit selection. I don’t think a word about the behavior for explicit selections is necessary, as it is… explicit…
The new rules ensure you get the same behavior of the name command wether you specify an explicit selection or use an implicit selection (in case both selections are the same of course!).
I don’t agree. Sometimes, naming the images with a common name is particularly useful, e.g. in the following case where you want to remove all images sharing a common property:
foreach { if ia<128 nm to_remove fi }
rm[to_remove]
Hmm, hmm, according your specification only the last of the list is named!
maybe ‘foreach { if ia<128 nm[^] to_remove fi }’ would be better.
No, you are right, thought the point without ‘foreach’ local environment.
hello
break do not breaks foreach loop:
jurek@debian_buster:~$ gmic 1x3 foreach break e =a== done q
[gmic]-0./ Start G’MIC interpreter.
[gmic]-0./ Input black image at position 0 (3 images [0] = 1x1x1x1, (…),[2] = 1x1x1x1).
[gmic]-1./*foreach/ Break current ‘foreach…done’ block.
[gmic]-1./*foreach/ Break current ‘foreach…done’ block.
[gmic]-1./*foreach/ Break current ‘foreach…done’ block.
[gmic]-3./ Quit G’MIC interpreter.
in repeat loop works:
Version 3.2.0 (pre-release #221109):~$ gmic 1x3 repeat 3 break e =a== done q
[gmic]-0./ Start G’MIC interpreter.
[gmic]-0./ Input black image at position 0 (3 images [0] = 1x1x1x1, (…),[2] = 1x1x1x1).
[gmic]-3./*repeat/ Break current ‘repeat…done’ block.
[gmic]-3./ Quit G’MIC interpreter.
2 Likes
I think that’s because a foreach ... done loop is basically equivalent to a nested flow such as repeat N local ... endlocal done, and in this context break just breaks the local...endlocal subgroup, so it behaves exacty as continue in this case.
This is probably not a good idea though.
I’ll see how I can change the code to actually break the loop.
This commit should fix the issue:
I’ll be able to post ne pre-release binaries with this fix included only on next monday unfortunately.
Thanks for reporting, this was super useful!
2 Likes
@jerzor New binary packages for development version 3.2.0 have been posted this morning, at: Index of /files/prerelease
Now, break() in a foreach loop should work as expected!
1 Like
@samj could you your API changes for 2.99.16+ directly integrate in official development release here 2.99.16 · Milestones · GNOME / GIMP · GitLab
I’m happy to announce that the automatic update of filters is back up and running since a few hours, for the version under development (3.2.0). Yippee!
2 Likes
3.2 is coming soon! Hurray!
It’s not what I said This was one of the blocking point, but there are many others remaining (the most important one is about the nn_lib still evolving “too much” for a stable release) + I still find bugs here and there (fixed one today).
1 Like
What do you mean obsolete? 2.99.16 is now in development. 3% at this current time. Milestones · GNOME / GIMP · GitLab
If you make API changes during the development, GMIC 3.2 will be supported for this 2.99.16 standard version.
I’m quite puzzled by a strange bug. I think it could be to do with the “dynamic” fill, perhaps threading not being disabled. This command used to work normally (shuffles vectors), but now does not:
gcd_shuffle : f "<begin(P=whd-2^-14);swap(I[int(u(P--))],I)"
Any clues?
Version 3.2.0 (pre-release #221123) (jammy)
Yes, in 3.2.0, most functions of the math parser that are not intended to return an obvious value, jut returns nan. This is the case, e.g., for draw(), copy(), … and swap().
So,
f "<begin(P=whd-2^-14);swap(I[int(u(P--))],I);I"
should fix your problem.
The reason for that is twofold:
- It was not always simple to remember what the corresponding returned value was. For instance, in
swap(), which value is returned, the first or the second? I must admit that it disturbed me a lot for a while Now that is definitely simpler. - This was sometimes leading to issues when you write longer pieces of code including conditions, with
if(cond,x,y)or ternary expressionscond?x:y. In these cases, the compiler requires that types ofxandymust be the same, and whenxandywere long expressions, it was easy to get tricked. for instance, ifxorywere ending with a function like the one discussed above, the returned types were incompatible and it was super hard to debug.
Now, the rules are simpler: math functions that are not intended to return a meaningful value just return the scalar nan.