Additional global variables in gmic

Hi, I am testing gmic cli and the gmic gimp plugin on several different OS, like Mac, (virtual) Windows, linux, Windows wsl (windows subsystem linux) and Android Termux app!

I think it would be helpful to have in gmic global variables with the targetOS, perhaps similar to the naming in the gmic download section, the targetOS build date (and time) of gmic and a custom function returning the compilation date (and time) of update<version>.gmic! This info could extend the printout of “gmic +v”.

Ah, and possibly it would be helpful for Mac users to add some information similar to Python, e.g.

MacOS:
MacPorts (see instructions in GIMP Downloads for Mac):

  • port install gmic gmic-gimp

Partha McGimp build: “www.partha.com

By the way, actually official Gimp for Mac is only recent with MacPorts. Seemingly there is nobody to update Gimp native for Mac. MacPorts is at the beginning a bit cumbersome, still lateron it is quite easy and allows also the build of prereleases from git without problem.

2 Likes

Yes, that would make sense to me as well.
What I do in my own G’MIC CLI builds is that if the CLI has been called without any parameters, I call cimg::info() to spit out some info that G’MIC already has collected about the features built into it and the system it is running on:
info

@David_Tschumperle: I assume it is currently not possible to access the data from cimg::info() from within the G’MIC CLI or at least trigger the output?

Not bad, most of the info I proposed is there. An internal function similar the CImg examples could allow to extract the necessary information in gmic.

Haven’t checked, but maybe these are available already as internal defines (“cimg_display”, etc.)?

What I propose is we define some new global variables in the interpreter, just as those already predefined (see G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Substitution Rules).
Then I can write a new info command that outputs the same kind of info than cimg::info() on the stdout.

From what I see in the output of cimg::info(), what is really missing is the OS type, so probably a $_os variable could be good.
But apart from that, what kind of information is that really useful ? The list of libs linked against the gmic executable maybe ?

So, tonight, I’ve added two predefined global variables:

  • $_os that can be { windows | linux | osx | bsd | unix | unknown }.
  • $_flags which tells what compilation flags have been enabled when compiling the G’MIC interpreter.

For instance, with my freshly compiled gmic:

$ gmic e OS=\$_os e FLAGS=\$_flags 
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ OS=linux
[gmic]-0./ FLAGS=curl,fftw3,jpeg,opencv,openexr,openmp,png,tiff,vt100,zlib
[gmic]-0./ End G'MIC interpreter.

That should help!

2 Likes

Cool, thanks!

Thank you, David, another progress!

Still I had thought also the OS flavors are of interest.

My opinion is that global variables have only few interest if they are used only to display information. On the contrary, the information they give should be compared with something in order to make some part of G’MIC commands specific to a particular case (e.g. a particular OS).
I’m not sure having a variable $_os that can take thousands of different values would be really useful in that context.

If you really need details about an OS, then maybe a system call (with exec) to e.g. lsb_release -a could be a better choice.

You are right, still looking back in this list to trace errors or problems the way gmic is compiled would help. How that information is stored or hidden in the final product is not the problem. lsb_release is one way to get information about the running system, but try to find such a method for all available systems, your g’mic is relatively widespread…

By the way, with this new _os global variable is_windows and is_macos should be superfluous or replaced.

However, your work is much appreciated, I thought to simplify a bit the exchange…

I agree with you, having a G’MIC command that do so maybe not that easy to implement. But on the other side, I’m not sure G’MIC is the software that should be used to return very precise information about the running OS. After all, this is only an image processing framework :slight_smile:

Probably superfluous in the long term yes. I’ll probably remove them in the future.

No worries. I also appreciate your suggestions and bug reports a lot. G’MIC code wouldn’t be at this point without your help.