Can it also be used to convert and insert strings in dynamic arrays using da_push, etc?
Had to move the second sep into the if $val condition (a check to see if mode is activated or not), else it would create a list with a leading , if you select modes in the GUI, and it would not work in gimp sometimes, but nothing breaking. That was a bit puzzling because yesterday it worked perfectly and today it would just but on me without any code change. Looks like it works now. Let’s wait tomorrow 
Yes. One word of warning though, G’MIC can have multiple numbers for a single character. Once I figure out that isssue as my rep_string_permutations needs it addressed, I’ll let you know. For now, too busy refactoring two commands.
That’s ok, I was just asking 
Because G’MIC follows the UTF-8 variable character encoding standard.
All bytes have leading administrative bits and trailing encoding bits. Read the administrative bits to ensure that the byte stream is UTF-8, and not random gibberish.
Concatenate together the encoding bits to get the code point, the numeral uniquely encoding one Unicode character. The code point for Latin capital A (LATIN CAPITAL LETTER A) is hexadecimal 0x41 (Formal notation: U+0041). It occupies one byte in a UTF-8 stream. The code point for 𝋲 (MAYAN NUMERAL EIGHTEEN) is hexadecimal 0x1D2F2 (Formal notation: U+1D2F2). It occupies four bytes in a UTF-8 stream.
Here’s the scheme for determining how many bytes encode a UTF-8 code point. Starting with the first byte in the stream:
- The initial bit of the leading byte is zero (0) and constitutes a one byte encoding. The remaining seven bits are encoding bits and can encode UTF-8 characters in the range U+0000 to U+007F — the original 128 character ASCII encoding. Otherwise:
- The initial bit of the leading byte is one (1). This and the subsequent one, two or three trailing bytes encode a UTF-8 character.
a. Trailing bytes must begin with the two initial bits set to10; the remaining six bits of trailing bytes carry portions of the encoding.
b. Leading bytes beginning with110identify a two byte encoding. the five trailing bits of the leading byte and six bits of the trailing byte together provide eleven bits of encoding. These encompass the range U+0080 through U+07FF; 1,920 code points.
c. Leading bytes beginning with1110identify a three byte encoding. the four trailing bits of the leading byte and the twelve bits of the two trailing bytes provide sixteen bits of encoding. These encompass the range U+0800 through U+FFFF; 61,440 code points.
d. Leading bytes beginning with11110identify a four byte encoding. The three trailing bits of the leading byte and eighteen bits of the three trailing bytes provide twenty one bits of encoding. These encompass the range U+010000 through U+10FFFF; 1,048,576 code points.
A UTF-8 stream consists of leading bytes followed by zero, one, two or three trailing bytes. So long as the leading administrative bits follow the pattern above, you can identify the byte width, strip out the administrative bits and concatenate together the encoding bits. That’s the code point. See Encoding in the Wikipedia article for an illustrative table.
Hope this helps.
No, it isn’t - What does this output in Linux? - #14 by David_Tschumperle .
It’s encoding agnostic, and this means I need to account for that from the cli side of thing and .gmic file encoding side of thing. But, I will see to that when I get back to my string-related commands.
And I have written UTF-8 tools in G’MIC to address some limitations.
Most of the issue is changing the encoding from the cli side of thing into array of char position id and then convert it back. Some might use UTF-8 related tools, I don’t know.
Hello,
in 3.3.6pre i’m often seeing this epileptic behaviour with display :
Here’s the debug info:
Xterm.log.AsaRem.2024.03.23.17.16.52.12619.tar.gz (1.1 MB)
Looks like the window keeps resizing until it’s at screen height, something like that.
On what system ?
Linux Asahi (Fedora 39 arm64).
I’ve just built G’MIC again and it’s the same problem, but sometimes it works fine.
At first, using window first then display would solve the problem but not anymore.
Hi @prawnsushi. Thank you for posting the debug log.
Emacs slicing-and-dicing reports 1,248 Enter Scope lines lurking among those 115,246 lines composing the log. Of those scope entries, 872 are into _display_rmn, making it a hot spot candidate.
It is a little temporary command defined around line 2019 of a fairly recent gmic_stdlib.gmic (commit 2b59444a on the develop branch, Wed Mar 20); this command in the guise of $0_rmn : nmd 2,$""* rm[${}]", where $0 ⇒ _display. Its arguments are image collection names, for each collection, it marks that one image in the set with the highest display list index; it returns the aggregate indices in status; these high-indexed candidates are then culled with remove.
I don’t think any criminal charges can be lodged against this temporary display list cleaning utility, but that it is called frequently illustrates the issue. The bulk of its career occurs in the so-commented # Enter user interaction for loop from lines 2,136 ⇒ 3,878 of gmic_stdlib.gmic, in the body of _display, and therein lies the rub.
Much as I enjoy the custom command implementations of display/_display, these are now things that debug can dive into and report on — exhaustively! — whenever window events induce calls to _display. _display, trying to keep up with window events while debugging lines are being emitted, is not a pretty state of affairs. I’ve found that simple mouse-over movements induces similar debug-induced paroxysmal behavior.
Tutorial Land hasn’t caught up with this issue. Somewhere, I need to write: “if using display as a kind of a break point, avoid debug, and if using debug avoid display — including the oft-overlooked implicit call to display that occurs at the end of top-level pipelines.” These command line pipelines are the ones that do not commit to any particular display list disposition, such as outputting images or removing them.
When approaching a circumstance where I might have mixed debug and display in the past, I set verbosity levels instead and leave debug in the kit.
Yes, I’ve noticed this too. But I didn’t move the mouse this time.
Do you want me to post the verbose output? Actually I wanted to post this first because I thought the debug output was just impossible to read ( for me), but maybe you could…
I have not been able to reproduce the specific issue of gmic debug sp creating a G’MIC display window that — seemingly on its own — self-expands vertically until it occupies the entire height of the root display. I observe the usual debug/display interactions, those which I went on about in my previous post.
No — I am perfectly fine in dealing with debug dumps and was suggesting use of the verbose command only as a way to generally avoid mixing debug with display.
However, you do remind me that I am not following the basic procedure of fault isolation. These self-expanding windows: do they only occur when you use debug with sample? Or have you used sample without debug and observed self-resizing windows? That is:
$ gmic sp
sometimes produces the self-expanding window phenomenon, yes? no?
Thank you for checking. I am seeking to determine if debug is an intrinsic part of the phenomenon or an innocent bystander.
Don’t have a PC right now but yes, it happens without invoking debug, with any pipeline. EDIT: it is actually random but very frequent. Maximizing the window stops the odd behaviour, until next call, which may or may not show the symptoms.
I think it’s ok if I call display from qmic_qt. ( Will verify).
Maybe it’s my system, I’m not sure, because I’ve seen this before, last year I think.
Btw I have a similar problem with virtual box on another pc where the VM window is being resized too until I maximize it. But gmic is fine on this pc.
Could it be related to the use of Wayland maybe ?
G’MIC uses X11 on Linux to manage display windows, and maybe the X11 compatibility layer provided by Wayland does not work exactly the same as in the original X11.
It more than probably is. I know Asahi uses Wayland.
Possible. Seems that @prawnsushi is on a Wayland-based distribution, to quote the good folk at Asahi Fedora Remix “Whether you’re a KDE enthusiast or a GNOME lover, Fedora Asahi Remix comes right out of the box with a 100% Wayland environment, bringing you the newest desktop and display server technologies, which are a perfect match for Apple hardware.”
Xwayland strives to be compatible with X11, and is there for X11 applications that have yet to be ported to Wayland, but folks at Archlinux don’t think that 100% seamless compatibility is there, nor, methinks, will it ever be there. Xwayland is an intermediary bridge, not a permanent solution.
I am native X11 here.
That will be a big deal for G’MIC in the future.
Recoding the CImgDisplay class in native Wayland will be hard. I’m certainly not going to do it, as I have less and less time to program.
Does this mean G’MIC development might be in a crossroad? I know sometimes developers quit when outside circumstances makes maintainability a big problem.
In the 15 years I’ve been developing G’MIC, I’ve always tried to remain as independent as possible from third-party libraries, keeping only the bare minimum and only mature libraries that don’t change version every month.
The fact that X11 is being abandoned in favor of Wayland poses a real problem for me, because it means I would have to recode an entire CImg class (the CImgDisplay class) using Wayland’s native API, which is a lot of work (and I don’t even know if it’s possible).
And it’s very tedious to do.
So, personally, I’m not interested in doing it without any help.
So, either we find someone motivated to start this “low-level” class conversion (and then I’ll be probably of some help), or we’ll eventually have to completely disable G’MIC’s display capabilities in the future, at least under Linux (under Windows, G’MIC uses the gdi32 lib, which is still usable).
Don’t think this will happen anytime soon, though. Wayland has been under construction since 2008 or so — which, I think, speaks to the complexity of building a display server. And the presence of Xwayland speaks to the broad reluctance to fully port X11-based desktop applications to it. Wayland isn’t done yet; X11 is mature code that may not be pretty, but it just works. It may be an intermediary bridge, but I expect that Xwayland will be a part of the Wayland project for some time to come.
And that’s the rub. Good people get hired, get busy. Even in this small discussion group, participants don’t seem to have an abundance of free time.