Not fan of having shortcuts for the same command that behave differently.
BTW, naming all images can be done with: nm[^] name.
A quibble. You happened to illustrate a case where M%N=0, but we should also be explicit about M%N>0 where name arguments will be dropped with an odd lot. The present behavior:
gosgood@bertha ~ $ gmic 1 2 3 4 5 nm[^] A,B,C named A echo '${}' named B echo '${}' named C echo '${}' v -
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input black image at position 0 (1 image 1x1x1x1).
[gmic]-1./ Input black image at position 1 (1 image 2x1x1x1).
[gmic]-2./ Input black image at position 2 (1 image 3x1x1x1).
[gmic]-3./ Input black image at position 3 (1 image 4x1x1x1).
[gmic]-4./ Input black image at position 4 (1 image 5x1x1x1).
[gmic]-5./ Set names of images [0,1,2,3,4] to 'A,B,C'.
[gmic]-5./ Get all image indices with name 'A' for images [0,1,2,3,4] (case-sensitive).
[gmic]-5./ 0,3
[gmic]-5./ Get all image indices with name 'B' for images [0,1,2,3,4] (case-sensitive).
[gmic]-5./ 1,4
[gmic]-5./ Get all image indices with name 'C' for images [0,1,2,3,4] (case-sensitive).
[gmic]-5./ 2
uses name argument ‘C’ only once, for 5%3 = 2 means the size of the last (and second) group of images is 2; the first image of that last group acquires the name ‘A’, the second image of that last group acquires the name ‘B’. ‘C’ is unused in this last group.
Is this silent dropping of C allowed or an error?
Put another way, is M%N>0 always an error (new behavior), or only an error when M<N and permitted otherwise (present behavior: non-assignments for odd-lots is permitted)?
I think there shouldn’t be an error, if C is assigned at least once, which is the case if M%N>0 and N<M.
1 Like
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 Thanks for pointing out the bug. Welcome to the forum!
@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
No because it’s obsolete :o)
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.