Hello @PDN_GMIC ,
Yes, now the file to use is : http://gmic.eu/gmic_stdlib_community334.h
It natively includes all the “community” filters directly inside G’MIC.
1 Like
Does Gmic 3.3.4 work with 2.99.16 ?
GNU Image Manipulation Program version 2.99.16
git-describe: GIMP_2_99_16
Build: org.gimp.GIMP_official rev 0 for windows
# C compiler #
Using built-in specs.
COLLECT_GCC=C:/msys64/mingw64/bin/cc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-13.1.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/include --libexecdir=/mingw64/lib --enable-bootstrap --enable-checking=release --with-arch=nocona --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time --disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-libssp --disable-multilib --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev7, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --disable-libstdcxx-debug --with-boot-ldflags=-static-libstdc++ --with-stage1-ldflags=-static-libstdc++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (Rev7, Built by MSYS2 project)
# Libraries #
using babl version 0.1.107 (compiled against version 0.1.107)
using GEGL version 0.4.47 (compiled against version 0.4.47)
using GLib version 2.76.3 (compiled against version 2.76.3)
using GdkPixbuf version 2.42.10 (compiled against version 2.42.10)
using GTK+ version 3.24.38 (compiled against version 3.24.38)
using Pango version 1.50.14 (compiled against version 1.50.14)
using Fontconfig version 2.14.2 (compiled against version 2.14.2)
using Cairo version 1.17.8 (compiled against version 1.17.8)
GIMP-WARNING: gimp-2.99.exe: gimp_wire_read(): error
I use the latest G’MIC plugin in GIMP 2.10.36 , windows 64. Is there a way to make G’MIC use more memory?
Hi @iarga,
Correct me if I’m wrong, but I think G’mic will only use what is needed by the filter you are currently using. Why would it use more ram than needed?
And I think filter devs will preferably try to use the less ram posssible so it can run on most computers.
But using higher resolution images and many layers will obviously use more ram.
1 Like
There are a-priori no limit on the amount of RAM that G’MIC can use, unless you have some system settings that enable such constraints.
1 Like
That’s not necessarily true. Optimizations comes after. Readable and maintainable code comes first, then optimizations. Sometimes, I will optimize my work after new findings or is time.
My first time coding Fragment Blur, it took a day just to work on a decently-sized image with 64 GB Ram, but I got it down to near compiled speed with C# and multi-threaded at that. Another one is Stitch Distort, I work on readable code, but as soon as I have new findings, I was able to optimize it. And so on.
1 Like
That’s why I said preferably 
I might not be the 1st goal though.
I know I have to keep everything low since I only have 8gb of RAM… Got enough crashes because of that heh.
1 Like
@prawnsushi My system is so underpowered I stopped scripting all together. 
@Reptorian sure loves to optimize.
1 Like
Why don’t you just upgrade or borrow someone else’s PC? 
Upgrading needs $$$. Borrowing needs people willing to give it to him. Plus, with that much hiatus, he will need to take his time to recover to then have the mindset to code. Even I’m struggling with that as I been G’MICing a little less.
Well, i’m using my work laptop for G’mic. That’s why it’s a " mac " Linux.
blah blah
But it’s a bit faster that my pseudo gaming tower. And i can G’mic anywhere.
But i’m tempted to get something else with more ram, but i fear it might be slower than the M1 chip. Maybe i’ll just try to switch kde to lxde or something else.
Well, a potato pc wouldn’t stop me from making crappy filters anyway. I’d just “unsafely reboot” more often 
Looks like something went wrong with rotate_tileable :
<gmic>./rotate_tileable/*foreach/ Enter scope '*foreach/'.
<gmic>./rotate_tileable/*foreach/ Item[41]: 'theta:=atan2($p,$q)' -> 'theta:=atan2(1,1)', selection [].
[gmic]./rotate_tileable/*foreach/ Set local variable 'theta:=atan2(1,1)'->'0.78539816339744828'.
<gmic>./rotate_tileable/*foreach/ Item[42]: 'gcd:=gcd(h*$q,w*$p)' -> 'gcd:=gcd(h*1,w*1)', selection [].
[gmic]./rotate_tileable/*foreach/ Set local variable 'gcd:=gcd(h*1,w*1)'->'32'.
<gmic>./rotate_tileable/*foreach/ Item[43]: 'pw:=h*$q/$gcd' -> 'pw:=h*1/32', selection [].
[gmic]./rotate_tileable/*foreach/ Set local variable 'pw:=h*1/32'->'16'.
<gmic>./rotate_tileable/*foreach/ Item[44]: 'nw:=round($pw*w/cos($theta))' -> 'nw:=round(16*w/cos(0.78539816339744828))', selection [].
[gmic]./rotate_tileable/*foreach/ Set local variable 'nw:=round(16*w/cos(0.78539816339744828))'->'18102'.
<gmic>./rotate_tileable/*foreach/ Item[45]: 'gcd!=gcd(h*$p,w*$q)' -> 'gcd!=gcd(h*1,w*1)', selection [].
<gmic>./rotate_tileable/*foreach/ Command 'input': arguments = 'gcd!=gcd(h*1,w*1)'.
[gmic]./rotate_tileable/*foreach/ Input file 'gcd!=gcd(h*1' at position 1
[gmic]./rotate_tileable/*foreach/ *** Error *** Command 'input': File 'gcd!=gcd(h*1', format does not take any input options (options 'w*1)' specified).
[gmic] *** Error in ./rotate_tileable/*foreach/ *** Command 'input': File 'gcd!=gcd(h*1', format does not take any input options (options 'w*1)' specified).
gcd!=gcd(h*$p,w*$q) << “!=” looks suspicious ?
Is there an issue with https://gmicol.greyc.fr/? I recall there being more, including the ability to choose a sample image. Could be something being blocked from my end. It has been a while since I visited, so perhaps I am misremembering.
- 2024/03/12: Release of G’MIC 3.3.5.
2 Likes
Spurious gmic update error that is not reproducing. This gmic was built ~15 minutes ago, from the develop branch, commit: d56391e307de 2024-03-15 17:08:14.
FYI. Maybe no actions are needed. Details:
gosgood@bertha ~ $ gmic version
gmic: GREYC's Magic for Image Computing: command-line interface
Version 3.3.6 (pre-release #24031608)
(https://gmic.eu)
Copyright (c) Since 2008, David Tschumperlé / GREYC / CNRS.
(https://www.greyc.fr)
gosgood@bertha ~ $ gmic update
[gmic]./ Start G'MIC interpreter (v.3.3.6).
[gmic]./ Update command definition file '/home/gosgood/.config/gmic/update336.gmic' from the G'MIC server.free(): double free detected in tcache 2
Aborted
gosgood@bertha ~ $ ls -l ~/.config/gmic
total 0
gosgood@bertha ~ $ gmic update
[gmic]./ Start G'MIC interpreter (v.3.3.6).
[gmic]./ Update command definition file '/home/gosgood/.config/gmic/update336.gmic' from the G'MIC server.
[gmic]./ End G'MIC interpreter.
gosgood@bertha ~ $ ls -l ~/.config/gmic
total 5764
-rw-r--r-- 1 gosgood gosgood 5899433 Mar 16 09:04 update336.gmic
gosgood@bertha ~ $ sha256sum ~/.config/gmic
sha256sum: /home/gosgood/.config/gmic: Is a directory
gosgood@bertha ~ $ sha256sum ~/.config/gmic/update336.gmic
bd3b4517dfda3a49523cd6c49fde9bc89b446289b6d91c60a0c5e2817f0c71db /home/gosgood/.config/gmic/update336.gmic
No follow-on misbehavings with gmic. 
I’m interested by this @grosgood . A bug is a bug, whatever it can be reproduced easily or not
Is it possible you compile with make valgrind and do $ valgrind gmic update to see what happens?
Alternately, make debug , then $ gmic update is another hope to make the bug appear !
1 Like
Yes, but not right now. In the midst of domestic chores. But a Sunday Morning After Breakfast debug session is in the offing. Let’s see if a decent stack trace can be had…
Stay tuned.
2 Likes
Haven’t broken gmic as I did early this AM. That remains the single failure. Have tried ten or so times now using a generic gmic and one built through the valgrind Makefile target. These have all been unexceptional; they fetched their respective update files and installed them in $HOME/.config/gmic.
The following is a canonical run. gmic is /usr/bin/gmic, a v. 3.2.4 that (I think) came from a generic gmic.eu debian binary install package some time ago. ./gmic (in the local build directory) was built with the valgrind Makefile target against commit d56391e307de. TLDR; Identical behavior. The warning, per StackOverflow, is not something that an end-user needs to care about: Warning: set address range perms:.
gosgood@Alice ~/gmic/src $ valgrind --leak-check=full gmic update
==2710== Memcheck, a memory error detector
==2710== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2710== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==2710== Command: gmic update
==2710==
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Update command definition file '/home/gosgood/.config/gmic/update324.gmic' from the G'MIC server.==2710== Warning: set address range perms: large range [0x25328040, 0x35328048) (undefined)
==2710== Warning: set address range perms: large range [0x25328028, 0x35328060) (noaccess)
==2710== Warning: set address range perms: large range [0x4785e040, 0x5785e048) (undefined)
==2710== Warning: set address range perms: large range [0x4785e028, 0x5785e060) (noaccess)
[gmic]-0./ End G'MIC interpreter.
==2710==
==2710== HEAP SUMMARY:
==2710== in use at exit: 122,304 bytes in 1,378 blocks
==2710== total heap usage: 11,933,262 allocs, 11,931,884 frees, 2,281,102,963 bytes allocated
==2710==
==2710== LEAK SUMMARY:
==2710== definitely lost: 0 bytes in 0 blocks
==2710== indirectly lost: 0 bytes in 0 blocks
==2710== possibly lost: 0 bytes in 0 blocks
==2710== still reachable: 122,304 bytes in 1,378 blocks
==2710== suppressed: 0 bytes in 0 blocks
==2710== Reachable blocks (those to which a pointer was found) are not shown.
==2710== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==2710==
==2710== For lists of detected and suppressed errors, rerun with: -s
==2710== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
gosgood@Alice ~/gmic/src $ valgrind --leak-check=full ./gmic update
==2713== Memcheck, a memory error detector
==2713== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2713== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==2713== Command: ./gmic update
==2713==
[gmic]./ Start G'MIC interpreter (v.3.3.6).
[gmic]./ Update command definition file '/home/gosgood/.config/gmic/update336.gmic' from the G'MIC server.==2713== Warning: set address range perms: large range [0x25bbd040, 0x35bbd048) (undefined)
==2713== Warning: set address range perms: large range [0x25bbd028, 0x35bbd060) (noaccess)
==2713== Warning: set address range perms: large range [0x59c8e040, 0x69c8e048) (undefined)
==2713== Warning: set address range perms: large range [0x59c8e028, 0x69c8e060) (noaccess)
[gmic]./ End G'MIC interpreter.
==2713==
==2713== HEAP SUMMARY:
==2713== in use at exit: 122,304 bytes in 1,378 blocks
==2713== total heap usage: 12,704,383 allocs, 12,703,005 frees, 2,546,625,336 bytes allocated
==2713==
==2713== LEAK SUMMARY:
==2713== definitely lost: 0 bytes in 0 blocks
==2713== indirectly lost: 0 bytes in 0 blocks
==2713== possibly lost: 0 bytes in 0 blocks
==2713== still reachable: 122,304 bytes in 1,378 blocks
==2713== suppressed: 0 bytes in 0 blocks
==2713== Reachable blocks (those to which a pointer was found) are not shown.
==2713== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==2713==
==2713== For lists of detected and suppressed errors, rerun with: -s
==2713== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
So, whistling a little tune… 
1 Like
Built against 49f7a42cb45f (develop branch) this AM.
gosgood@bertha ~ $ gmic update
[gmic]./ Start G'MIC interpreter (v.3.3.6).
[gmic]./ Update command definition file '/home/gosgood/.config/gmic/update336.gmic' from the G'MIC server.
[gmic]./ End G'MIC interpreter.
All is well. All is good. No further comment unless it happens again. Got documentation to do…
1 Like
Thanks Garry.
I’ve worked a bit on the interpreter source code this week-end, so maybe you found a “temporary” bug that was unfortunately pushed.
I think I’ll write a post about what I made. This has absolutely no interest except for people following the advances of the G’MIC interpreter, but I’m quite happy about how it turned out.