Good call. I forgot to add debug mode and didn’t realize that user could/should call itself.
I do that for two reasons:
- Enable debug mode for this file too (default inclusion don’t do that).
- Be sure all commands in the user gmic file will have priority over all the other sources.
Also, please note that I’ve uploaded a new pre-release yesterday that may (hopefully) fix your fullscreen problem with display
. Please tell me if it’s not the case.
Fix confirmed.
As noted before, I don’t think a variable outside of fill
or eval
can exist within the double quotes, unless I misunderstood this new feature. At least, it doesn’t seem to work on my system.
- 2021/07/16: Release of G’MIC 2.9.8.
Now ready for two weeks of vacations, without Internet
Enjoy!
@David_Tschumperle , hope you have good vacations.
Looking into the documentation, it would be very helpful for me to see or find easily new or changed (custom) commands, e.g. * new or changed command, † new or changed tutorial. Seemingly tutorial parts are isolated files, easily to recognize, changed or new custom commands are possibly recognized by diff in the update.gmic . I don’t know if the update.gmic could be stored in git for the differences?
In your gmic repository:
git tag --list
git diff master v.2.9.7 -- src/gmic_stdlib.gmic
furnishes a rich heads-up listing of what has changed in the standard library, though a bit of git-savvy needs to be in store to appreciate myriad diff
lines. For historical spelunking, one may substitute any pair of version tags for ‘master’ and ‘v.2.9.7’
I maintain a table at Command Tutorials with Ref, 1.6x, 2.9x indicators, to wit: “No tutorial”, “Antique Tutorial” and “Current Tutorial.” With a vanishingly small effort, I could add a “Last changed: DD-MM-YYYY” note at the footer of the tutorial, at least with the 2.9x versions, which are git-based — the repository maintains commit dates — and think that I shall. Be a bit of time before I retro-date the already-published 2.9x tutorials. Consider all 1.6x to be pre-2013, with the reliability of Ancient Phoenician Scrolls.
Very helpful tip Gary, I think I’ll start with some RE gym with the git diff.
Your latest 2.9.8 ( 2021-07-16) does not crash in GIMP 2.10.24 windows 64 bits
but your latest 2.9.9 (from today) prerelease does crash.
Works for me, with GIMP 2.10.24.
I’ve actually uploaded a new binary a few minutes ago, maybe this solves your issue.
Yes, your latest doesn’t crash, thank you very much.
Just a remark to +command specialization:
gmic h lissayous3d
*[gmic] No help available for command ‘lissayous3d’; did you mean ‘+lissajous3d’ ?. *
-
Try 'gmic -h' for global help.*
Maybe propose better ‘lissajous3d’ without the + sign ?
I have the update error on my laptop unfortunately. Not sure how I can replicate it as I have changed everything. It works on my desktop.
Still some problems with “+command”!
Seemingly does “command” precede “+command”, if the first is defined in updatexxx.gmic and the latter defined either in .gmic or in another gmic file!
I could not overload it by “+command”. In this situation e.g. gmic e $$command and gmic e $$+command are different !
Possibly I have the command specification not understood.
The rules are the followings:
- When
+command
is invoked, the interpreter first try to apply the latest definition of the specialization of+command
. If not found, it tries to applycommand
on a duplicated selection. If not found, it throws an error. - When
command
is invoked, the interpreter first try to apply the latest definition ofcommand
. If not found, it tries to apply a specialization of+command
. If not found, it throws an error.
If a specialization +command
of command
exists, then, yes, $$command
and $$+command
are different.
Thank you David, that is exactly what I see. I invoked the “command” always without “+”. However, this is only a temporary effect during addition of command specification +. I think the definition of “command” and “+command” should not differ in normal circumstances.
I’m not sure what you mean here. Maybe a simple example to discuss about it?