Yes, there have been changes for command help lately.
There was actually a bug : the pattern h command were seek on the command line, and if found, the help for the command was displayed. But, this was also working in (rare) cases where the help was actually not requested, like in this example:
$ gmic 256,256,1,1,255 text h blur 10
^^ Here, I wanted to draw a “h” in the image, not displaying the help for blur ! ^^
I agree that this is unlikely to happen, but still, these cases don’t have to be misunderstood by the interpreter.
I’ve pushed a small fix a few minutes ago in the update file, so with $ gmic up , this could solve your problem. Let me know.
Seemingly command help in gmic cli does only print help texts starting with #@cli from the file update290.gmic, not from any other command file neither $_path_user nor any one loaded with command m?
Possibly it makes sense to add another parameter, the gmic file name, in command help, similar to my changed help command?`
#@cli kr_help : command : (no arg)
#@cli : Display help (optionally for specified command only) and exit.
kr_help : skip ${1=""},${2=1},${3=$_path_rc/update$_version.gmic}
if isfile([’$3’])
l[] cimgz:$3 k[0]
onfail l[] raw:$3,uchar k[0] onfail endl
endl
if $! k. fi
fi
if !$! return fi
y a y
+_help $1,$2 k[0]
if narg(${}) _help[0] ${},0 fi # In case of shortcut, display also help for shortcut command.
rm v 0 q
Am I right, that now the help command works for update290.gmic and $_path_user?
Wth command <file> loaded functions I still get no help! Seemingly there is no way back to the source? Hmm an uncommand <file> to remove all functions in that <file> wouldn’t be bad either, than there might be a pointer to the source with comments too?
After a quick check.
That’s probably because you are using the # character in some of your filter parameters, and the filter parser interpret that as the beginning of a comment, and thus discard the parameter.
Will check if this can be fixed easily.
I wonder if there is a way to force older versions to have the latest command set for testing purposes. Just thinking through the problem as someone who wants to commit regularly but is delayed or discouraged by the tedium described below.
I find it annoying to have to update the CLI binary to use my latest committed commands. It can be time consuming and confusing: I don’t know when I should delete my local *.gmic copies because I don’t know if I will have parity when I do update. I would have to delete it, save, update and then check command using e[] $$ method, and repeat. Sometimes, there is parity but then I purposefully or accidentally change something in my local file. This makes it harder to keep track of bugs or discrepancies because I have multiple copies of the same command.
I don’t use git locally on my end or have a software manager because I use win10 but I don’t think that would matter.
I always want to know what is going on from the perspective of someone who isn’t using the bleeding edge pre but is up to date a couple of releases ago. Moreover, I would like my commands to be available to a wider range of point releases.
I updated to Version 2.9.0 (pre-release #200225). I can confirm @KaRo’s issue. help doesn’t work anymore.
Continuing from my previous post, I would like the gmic output to indicate the current stable and pre. That would help save time. Perhaps installed version, stable version and pre version.
gmic: GREYC's Magic for Image Computing: command-line interface
(https://gmic.eu)
Version 2.9.0 (pre-release #200225)
And I would like the interpreter to indicate the version being used.
Hi @afre, I think I understand your point. Still I think also that David does not break backward compatibility without good reason.
I don’t have such a quick changing development, still I store my custom commands in $_path_user. And in the moment they appear in updatexxx.gmic I delete them locally. For older releases without update I use “command file” in $_path_user to have them defined. In your case even “command gmic-community/afre.gmic at master · dtschump/gmic-community · GitHub” works well.
Ok, the problem with help is not solved with “command”. Actually to get help everything has to be copied into $_path_rc !
I’d suggest $ gmic \$_path_rc/update290.gmic , whatever the version of G’MIC you are using.
This will work for the CLI interface. For the plug-in, having a link in folder $_path_rc, e.g. update285.gmic linked to update290.gmic.
This should not happen. help is working here. The only requirement is that you have the update290.gmic file present in your $_path_rc.
I don’t get it, have you a simple example that is not working as expected?
About the update compatibility break : I’m really sorry when it happens, I try to keep that to a minimum. Most commands of the stdlib will actually continue working with previous versions. I hope 2.9.0 will be ready as soon as possible so that people can easily get the updates.
A few things to fix before release, anyway.
Good idea. I will place a commented out