Yes, this is what I have. I am still super disorganized. Super organized compared to you, I guess.
#@gmic user
cli_start :
m path\to\user0.gmic
# etc.
Last I checked #@cli lines don’t work in imported *.gmic files and there are other quirks, including bugs that appear (like what I reported above).
Personnally, I have this in my cli_startcommand:
cli_start :
l[] m 1,$HOME/work/src/gmic/src/gmic_stdlib.gmic onfail endl
l[] m 1,$HOME/work/src/resources.gmic onfail endl
l[] m 1,$HOME/work/src/imageteam/imageteam.gmic onfail endl
l[] m 1,$HOME/.gmic onfail endl
md3d 3
This allows me to automatically import my command files with the debug mode activated (e.g. to get the line numbers displaying when an error occurs in one of my command).
This has worked for me for years.
Good call. I forgot to add debug mode and didn’t realize that user could/should call itself.
I do that for two reasons:
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.
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:
+command is invoked, the interpreter first try to apply the latest definition of the specialization of +command. If not found, it tries to apply command on a duplicated selection. If not found, it throws an error.command is invoked, the interpreter first try to apply the latest definition of command. 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.