OUT! Darn period!!!

In gmic-community:
git diff 0b2c51bd..77ce6b37 # Mar 4 09:49:32 2025 +0100⇒Mar 4 14:54:18 2025 +0100

   <G'MIC code> # <comment>. =>
   <G'MIC code> # <comment>

It is likely I missed the memo, but why, in all include/*.gmic files, there is a ban on periods terminating inline comments? I lack the imagination to deduce a sensible reason.

Whatever that may be, it seems a bit of grist that could inform some far-future scripting tutorial.

Speaking of tutorials, I’m about to drop pieces of such. Not this weekend; probably next. Tutorial writing has been a sporadic activity this past year, but come the Ides of June, I’ll be retiring from New York City’s department of Housing and Preservation, and, gold watch in hand, will be concentrating a good deal more on various writing projects, G’MIC among them. Stay tuned to G’MIC Tutorial Fragments.

3 Likes

I noticed the period thing. Maybe David prefer to see comments without periods. I dunno.

Welcome back, it has been a while. G’MIC is a little faster now. There’s a few more math parser things.

I learned a few things like mimicking set/dictionary in G’MIC while you were away. So, I did things like rep_mode_blend which has two different algorithms depending on number of images. Also, did my own version of colormap 0 which is multithreaded.

You may want to note that multi-threading in G’MIC is not always the same. So, bugs can occur without taking into this into account. I had to change my combinatorics commands to account for that.

Well yes, sorry about this, it’s my fault (again!)

Indeed, in my personnal programming rules, I allow periods in end of comments only when the comment is not inlined. And yes, I’m a psychically disturbed person: I recently wrote a script that automatically detect and deletes all periods at the end of inline comments in my own source files.

And to test the script out, I tried it on all the gmic files on my disk (including the gmic-community include/ files). And I didn’t pay much attention when it was pushed to the server (originally I only wanted to do it for my own include file).

Now, I must confess that I’m completely incompetent when it comes to using git, so I preferred to leave this modification as it is, rather than trying to undo it on all the files that weren’t mine. I figured it probably wasn’t such a big deal.

Sorry if you thought this was something that was becoming mandatory! That’s not the case at all!

And by the way, I’m really happy to see @grosgood again, it’s been a while since we’ve heard from him! I hope all is well with you!

1 Like

Ah. Runaway script.

Doubt the “incompetency” bit. Perhaps less practiced in certain areas. I see no reason to revert; it’s harmless commentary changes, but for the terminally curious:

Starting with a clean, current repository with the local master branch up to date with its remote:

git revert --no-commit 77ce6b37

leaves the remote unaltered but changes your local master branch. The staging area becomes populated with altered files: those touched by commit 77ce6b37, but the changes introduced by 77ce6b37 have been removed (reverted) from those files.

Now, if you do nothing else but git commit… the reverted files become the objects of a new commit. Of course, you are at liberty to further alter your local master branch files before committing.

Omit option --no-commit and you do not have that liberty, you will immediately commence a commit session with the reverted files (sans changes introduced by 77ce6b37) being the objects of the new commit.

Whenever I embark upon something remotely dubious (which is nearly every time I do something), I start out creating a new branch:

$ git branch dubious # If `dubious` is not a branch, `git` creates it
$ git switch dubious
Switched to branch 'dubious'
$

From there, all my commits go to branch dubious.
If, from time to time, I want to list changes divergent from master:

git diff master

gives a Unix-like diff -u of all the differences between what I’ve done on dubious and the versions on branch master.

When I’ve convinced myself that every change on dubious is sane, I:

git switch master
git merge dubious

to migrate changes on dubious back to master. Branch dubious remains extant. This triggers a commit session which will get its own comment and commit hash. When, after testing on master, I’m really convinced that the changes are sane, I commit to the remote repository.

This is, of course, a double-commit strategy. It takes longer. But the additional branch-to-branch commit furnishes ample opportunities to catch errors locally. What is more, you have plenty of ways to diff between dubious and master to get fine-grained indications of what you are changing and when those changes have been committed. Finally, if it turns out that dubious is nothing but a total mess, you can:

git switch master
git branch -D dubious

and master is clean — so long as you hadn’t merged dubious into master at any previous commit. In that case, git revert on any (or all) of the merge commits is your friend.

Hope this helps.

EDIT: I neglected to mention that git revert… is best done as soon as possible, before subsequent commits pile on. Try this after other commits have accumulated and git will declare a CONFLICT (content): and expect you to manually resolve all the conflicts arising from subsequent commits. Painful. Tedious. git revert --abort cancels the revert operation and gets you back to a safe place.

I should be working on G’MIC tutorials, no (yes, you should)?

1 Like

I’ve learned some stuffs with your post, so I can’t tell what you should do, but I can tell that what you did is really great (and this also includes the G’MIC tutorials of course :wink: ).

Hi, can’t wait to read your next “nouvelles” ! ( Short stories)

1 Like