Release of G'MIC 3.0

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 :slight_smile:
4 Likes

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.

@David_Tschumperle

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.

1 Like

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.

https://github.com/dtschump/gmic/commit/9360600a188edb7c70fe4594a4b88093f0404f16

Very good, thanks @David_Tschumperle .
Not easy to find similar enough +command meanings!

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 apply command on a duplicated selection. If not found, it throws an error.
  • When 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.

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?