profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/StefanSalewski/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

StefanSalewski/gintro 175

High level GObject-Introspection based GTK3/GTK4 bindings for Nim language

StefanSalewski/NimProgrammingBook 37

Computer Programming with the Nim Programming Language -- A gentle Introduction

StefanSalewski/RTree 16

Generic RTree for Nim

StefanSalewski/cdt 11

Constrained Delaunay Triangulation (2D), incremental / fully dynamic

StefanSalewski/nim-chess4 11

Plain chess game written from scratch in Nim with GTK3 GUI, now using high level GUI API

StefanSalewski/GtkProgrammingBook 10

GTK GUI creation with the Nim programming language

StefanSalewski/Ruby-PCB-Router 10

Topological Rubberband Autorouter for Printed Circuit Boards

StefanSalewski/oldgtk3 6

Low level GTK3 bindings for Nim language, complete nimble package for GTK 3.22

StefanSalewski/RBR 6

Rubberband maze router for PCB traces

StefanSalewski/NEd 5

Plain GTK3-Sourceview based Nim editor with nimsuggest support

issue commentStefanSalewski/gintro

Cant install on arch

Fix is shipped as v0.9.6 now!

gavr123456789

comment created time in 2 days

created tagStefanSalewski/gintro

tagv0.9.6

High level GObject-Introspection based GTK3/GTK4 bindings for Nim language

created time in 2 days

push eventStefanSalewski/gintro

Stefan Salewski

commit sha a1e7486580b2b90deca783ed263a475febe52a72

v0.9.6 with libsoup 3.0 fix

view details

push time in 2 days

issue commentnim-lang/Nim

Wstringop-overflow for Nim 1.6 and Nim 1.7.1 with --gc:arc -d:useMalloc -d:release -d:lto

The executable is generated and works with valgrind with no errors. So it is more are gcc warning, but gcc seems to regard it as serious.

StefanSalewski

comment created time in 2 days

issue commentnim-lang/Nim

Wstringop-overflow for Nim 1.6 and Nim 1.7.1 with --gc:arc -d:useMalloc -d:release -d:lto

gcc version 11.2.0 stable version from Gentoo Linux. And error occured for hin as well: https://forum.nim-lang.org/t/8521#55214

StefanSalewski

comment created time in 2 days

issue openednim-lang/Nim

Wstringop-overflow for Nim 1.6 and Nim 1.7.1 with --gc:arc -d:useMalloc -d:release -d:lto

import times
var qt = "NGIQ" & $epochTime()
if true:#g_quark_try_string(qt) != 0:
  qt = "NGIQ" & $epochTime()
nim c -f --gc:arc -d:useMalloc -d:release -d:lto thisfile.nim
Hint: used config file '/home/salewski/Nim/config/nim.cfg' [Conf]
Hint: used config file '/home/salewski/Nim/config/config.nims' [Conf]
...........................................................................
CC: stdlib_digitsutils.nim
CC: stdlib_formatfloat.nim
CC: stdlib_dollars.nim
CC: stdlib_system.nim
CC: stdlib_times.nim
CC: gobject.nim
Hint:  [Link]
In function ‘memcpy’,
    inlined from ‘nimCopyMem’ at /tmp/salewski/.cache/nim/gobject_r/stdlib_system.nim.c:585:8,
    inlined from ‘copyMem_system_1709’ at /tmp/salewski/.cache/nim/gobject_r/stdlib_system.nim.c:588:2,
    inlined from ‘appendString’ at /tmp/salewski/.cache/nim/gobject_r/stdlib_system.nim.c:951:3,
    inlined from ‘NimMainModule’ at /tmp/salewski/.cache/nim/gobject_r/@mgobject.nim.c:156:1,
    inlined from ‘NimMainInner’ at /tmp/salewski/.cache/nim/gobject_r/@mgobject.nim.c:106:2:
/usr/include/bits/string_fortified.h:29:10: warning: ‘__builtin_memcpy’ writing 5 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
   29 |   return __builtin___memcpy_chk (__dest, __src, __len,
      |          ^
In function ‘memcpy’,
    inlined from ‘nimCopyMem’ at /tmp/salewski/.cache/nim/gobject_r/stdlib_system.nim.c:585:8,
    inlined from ‘copyMem_system_1709’ at /tmp/salewski/.cache/nim/gobject_r/stdlib_system.nim.c:588:2,
    inlined from ‘appendString’ at /tmp/salewski/.cache/nim/gobject_r/stdlib_system.nim.c:951:3,
    inlined from ‘NimMainModule’ at /tmp/salewski/.cache/nim/gobject_r/@mgobject.nim.c:140:1,
    inlined from ‘NimMainInner’ at /tmp/salewski/.cache/nim/gobject_r/@mgobject.nim.c:106:2:
/usr/include/bits/string_fortified.h:29:10: warning: ‘__builtin_memcpy’ writing 5 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
   29 |   return __builtin___memcpy_chk (__dest, __src, __len,
      |          ^
Hint: gc: arc; opt: speed; options: -d:release
41549 lines; 0.877s; 60.504MiB peakmem; proj: /tmp/hhh/gobject.nim; out: /tmp/hhh/gobject [SuccessX]
nim -v
Nim Compiler Version 1.7.1 [Linux: amd64]
Compiled at 2021-10-20
Copyright (c) 2006-2021 by Andreas Rumpf

git hash: 62701cd3b92677c2014cf70b1cf5a5ba6e0468bf
active boot switches: -d:release

created time in 2 days

issue commentStefanSalewski/gintro

Cant install on arch

You may try the fix with

nimble uninstall gintro nimble install gintro@#head

Fix is

$ diff ~/gintrotest/tests/gen.nim gen.nim 
3c3
< # v 0.9.6 2021-OCT-20
---
> # v 0.9.5 2021-OCT-01
403,404d402
<   if not ISGTK3 and (s == "libsoup"):
<     result &= "3"
4293,4298d4290
<   if namespace == "Soup":
<     if version == "2.4":
<       suff = ""
<     if version == "3.0":
<       suff = "3"
< 
4356d4347
<     main("Soup", "2.4") # process Soup before Nice, preventing the load of not matching libsoup version
4361c4352
<     #main("Soup", "2.4")
---
>     main("Soup")
4411,4412c4402
<     main("Soup", "3.0") # process Soup before Nice, preventing the load of not matching libsoup version
<     main("Nice") # https://discourse.gnome.org/t/some-libsoup-3-issue/7807/14 
---
>     main("Nice")
4416c4406
<     #main("Soup", "3.0")
---
>     main("Soup")
4477c4467
< # 4477 lines
---
> # 4467 lines

The trick is, that we process libsoup before libnice. And we create an additional module libsoup3 now. Indeed we have to process libnice in the GTK3 process as well as in the GTK4 process, as we do for all the other common modules. We need that to populate the gisup files, I initially forgot about that.

I was also able to install webkitgtk for GTK4, and to test gintro generating the bindings. But even a plain C test program does not work currently for GTK4 with webkit, we get a message of an internal webkit issue. But that is no gintro problem.

gavr123456789

comment created time in 3 days

push eventStefanSalewski/gintro

Stefan Salewski

commit sha 7ef13ff676636526516a520b3890cfdfc6226813

fix for libsoup3

view details

push time in 3 days

issue commentStefanSalewski/gintro

Cant install on arch

We have currently already 2 separate processes, one for the GTK3 related libs, and one for the GTK4 libs. Currently all seems to be fine when we generate libsoup2.4 and libnice together in the GTK3 process. What worries me a bit is what will happen when libnice switch to libsoup3. As noted in the forum thread, a really clean solution would be to start a new process for each single lib creation. For current libnice it works also, when we just process libsoup before libnice, then libsoup version seems not to matter.

gavr123456789

comment created time in 4 days

issue commentStefanSalewski/gintro

Cant install on arch

Have you followed the discussion on the GTK forum? The real issue seems to be that libnice internally uses libsoup2.4 still, and so gobject-introspection uses that libsoup somehow. Then later, when gobject-introspection shall process libsoup3 we get the crash. We can fix that for now, but what when later libnice switches to libsoup3?

gavr123456789

comment created time in 4 days

issue commentStefanSalewski/gintro

Cant install on arch

I was finally able to install libsoup3 from git sources and can now reproduce your issue.

I think fully disabling webkitgtk support for GTK4 is not a very good solution. I got webkitgtk with GTK4 to work in late 2020 already, and some Rust people seem to use this combination as well. Linux distributions may not yet ship it, as there are some NVidia issues. But later they will. I will investigate the issue in the next days.

gavr123456789

comment created time in 5 days

issue commentStefanSalewski/gintro

Cant install on arch

Fine that you get it working for you, but that is not a general fix, as most people want to use the versions 5.0 of course.

I still are not able to install libsoup 3, see https://discourse.gnome.org/t/can-not-compile-libsoup-3-from-git-sources/7809/4

so I can not test it. Maybe we should remove webkit and libsoup fully? I have the feeling that no one really needs that.

gavr123456789

comment created time in 6 days

issue commentStefanSalewski/gintro

Cant install on arch

You may have seen this thread in the GTK forum:

https://discourse.gnome.org/t/some-libsoup-3-issue/7807/3

So all that is not easy.

Yesterday I failed installing libsoup 3 from git sources on my Gentoo box, I will try again later.

Maybe you have already some basic Nim and Nimble knowledge, so you may be able to split the gintro install phase into a download and a run phase? In that case you could try to modify the gen.nim script to fix it.

I am doing such experiments not with nimble, but have prepared a special directory on my box, where I manually added some needed files from the oldgtk3 package, which are temporary needed to compile gen.nim. So I modify, compile and run gen.nim in that directory, and copy the generated files to ~/.nimble/pkgs/gintro-#v0.9.5/gintro

That is how I do it for many years now, but maybe at some time in future I will try to learn more about nimble.

Another person does some gintro development recently by temporary forking gintro. Then he modified the gen.nim script in his fork, and tries to install his fork. That way he was able to find a fix for his very old Debian Buster install. We then included that fix in recent version v0.9.5

gavr123456789

comment created time in 6 days

issue commentStefanSalewski/gintro

GTK Webkit?

Is it planned to add support for webkit? It could be useful in building small Nim gtk-based browsers.

We added it about one year ago, as one of the authors of the famous Bacon/Dingle paper (inspiration of Nim ARC memory management) asked for it. But unfortunately that person vanished fast, he wants to continue using Python.

So we may remove webkit again? Indeed I am not able to test it for GTK4 currently, as my Gentoo Linux does not support webkit with GTK4. I was able to compile GTK4 with webkit support from git sources maybe 6 months ago, and have tested gintro with that successfully that time, but my last attempt to install from git failed.

Currently we have some trouble with libsoup 3.0, which is related to webkit.

Webkit is really a large module, which needs some other modules again. So when nobody uses it, maybe we should just remove it.

codic12

comment created time in 6 days

issue commentStefanSalewski/gintro

Cant install on arch

But well, I may have an idea: libsoup 3.0 may be related to GTK4 only, in that case we may have to specify a version, 2.0 maybe, for GTK3 install. WE do that already for a few modules. Will investigate that soon.

gavr123456789

comment created time in 6 days

issue commentStefanSalewski/gintro

Cant install on arch

Yes, that may be the problem. I have only Soup-2.4.gir currently, and 3.0 seems not yet available as gentoo package, see https://packages.gentoo.org/packages/net-libs/libsoup

I will try to install libsoup from git sources in the next days and see if I can reproduce the issue. I guess it is not a real gintro problem but gobject-introspection related. GTK has not many GIR users, so unfortunately often we few gintro users are the first who discover such bugs.

gavr123456789

comment created time in 6 days

issue commentStefanSalewski/gintro

Cant install on arch

So it is a new error on your own computer? It was my feeling that you tried to install on a device like Raspberry Pi!

Is this a v0.9.5 issue? Can you still install older gintro? I think command should be

nimble uninstall gintro
nimble install gintro@#v0.9.4

Well I am not sure, never tried to install old versions.

Have you recently updated your GTK install? Or updated Nim or nimble? So what has changed?

Have to watch "Auslandsreport" on German NTV now, may come back later. Bye.

gavr123456789

comment created time in 6 days

issue commentStefanSalewski/gintro

Error: Invalid node kind nnkCall for macros.`$`

if it was exposing a gintro bug anyways.

We can always try to improve the connect macro to catch invalid calls better. But in real life it is not a real issue, as when you have learned Nim and gintro for a few weeks, you just generally do it right.

Rewriting all the gintro macros is indeed on the to do list, I was hoping all the years that maybe someone of the Nim experts would do it, instead sitting the whole day in from of the Nim IRC. But now Araq and a few other Nim devs seems to favour the fidget GUI toolkit, so I have not much hope. When we will have at least 100 really active gintro users I will do it myself, or hire someone to do it.

ITwrx

comment created time in 6 days

issue commentStefanSalewski/gintro

Error: Invalid node kind nnkCall for macros.`$`

Maybe this was intented:

import gintro/[gtk4, gdk4, glib, gio, gobject]

var home_box = newBox(gtk4.Orientation.horizontal)
var home_chooser_btn = newButtonFromIconName("folder-open")

proc home_chooser_btnCb(home_chooser_btn: Button; home_box: Box) =
    #home_box.remove(home_chooser_btn)
    #let notify_label = newLabel("home chooser box and button are gone!")
    #home_box.append(notify_label)
    echo "home chooser clicked"

#error triggered by next line
home_chooser_btn.connect("clicked", home_chooser_btnCb, home_box)
ITwrx

comment created time in 6 days

issue commentStefanSalewski/gintro

Error: Invalid node kind nnkCall for macros.`$`

This is invalid code:

home_chooser_btn.connect("clicked", home_chooser_btnCb(home_box, home_chooser_btn))

I am not sure what you intend, but you pass a proc call as last argument, while last argument should be justb the proc/callback name, e.g. like

home_chooser_btn.connect("clicked", home_chooser_btnCb) # or with optional ref object parameter
home_chooser_btn.connect("clicked", home_chooser_btnCb, myRefObjOrwidgetOrIntAndSuch)
ITwrx

comment created time in 6 days

issue commentStefanSalewski/gintro

[question/FR?] how to pass two widgets as parameters to callback?

Is there a way to pass two widgets?

The GTK callbacks have exactly one optional parameter. In C we have always to pass NULL if there is no optional parameter, but with Nim and gintro we can just leave it out. To pass more data, we generally create just an object which contains all data in its fields and pass that object. Well actually we pass a ref object. At least I am sure that it works with ref objects, we have used that often. The SDT tool should contain such code, maybe the drawingarea example too. But no reason to look there, it should just work. Often we pass other widgets, which are ref objects too. For plain objects, which live on the stack, the callback macro would have to copy the object into a ref object to extend life time. I am not sure is that may work. Same for tuples, passing tuples as optional arguments should generally work, but I think some years ago someone told us that it did not work, and I told him to just use a ref object. Feel free to investigate the shipped callback macros and improve them. Araq was never very happy with my macros, so you may rewrite them using only functions working on the AST, while I did a lot text manipulations that time, I think it was 2016. I recently added the macros section to the kids book, see http://ssalewski.de/nimprogramming.html#_macros_and_meta_programming. Let us know if there are errors or when we have to improve something.

ITwrx

comment created time in 6 days

issue commentStefanSalewski/gintro

Error: Invalid node kind nnkCall for macros.`$`

nim c -r EZMP.nim --gc:orc

Sometimes I really hate the "r" or "c -r" options of the Nim compiler. The may be OK for general use, but in case of bugs it is helpful to know exactly if it is a compiletime or runtime issue.

And please try --gc:refc and --gc:arc also.

ITwrx

comment created time in 6 days

issue commentStefanSalewski/gintro

Cant install on arch

Cant install on arch

Is this ARM 64 bit system (called aarch64)?

Please note that generally only fools posts images when a plain textual error message is sufficient. Real morons even posts full videos.

I will investigate this issue, but it has currently not a very high priority.

gavr123456789

comment created time in 6 days

issue commentStefanSalewski/gintro

[question] how to avoid type errors with child classes/objects?

We have v0.9.5 since a few days. My install is still called 0.9.2, but of course I have the actual files. Maybe we both should update.

nimble uninstall gintro nimble install gintro

That should give both of us v0.9.5

I read recently in the forum, that there is currently some trouble with recent nimble, so maybe we should be a bit careful.

$ grep -B5 "setPaintable\*" ~/.nimble/pkgs/gintro-#v0.9.2/gintro/gtk4.nim 

proc gtk_picture_set_paintable(self: ptr Picture00; paintable: ptr gdk4.Paintable00) {.
    importc, libprag.}

proc setPaintable*(self: Picture; paintable: gdk4.Paintable = nil) =

So why do you expect that proc setPaintable() should return a result? Does it in Rust?

import gintro/[gtk4, gdk4, glib, gobject, gio]

let media_file1 = gtk4.newMediaFileForFile(gio.newGFileForUri("rtsp://admin:passwd@192.168.1.5:554"))
let myPicture = gtk4.newPicture()
gtk4.setPaintable(myPicture, cast[gdk4.Paintable](media_file1))

Seems to compile fine. Of course I can not test the executable.

ITwrx

comment created time in 9 days

issue commentStefanSalewski/gintro

[question] how to avoid type errors with child classes/objects?

but it seems to me that one would need to be able to use interfaces over module boundaries all the time,

Yes, but the question is how often we really need interfaces over module boundaries? I don't know. When only in rare cases, then manually created converter procs may be good enough. I think in C and in most language bindings we have to do an explicit cast when using interfaces, so gintro is already a large improvement with its OR types. But look into file gtk4.nim, there are OR types used with dozen of data types. I wonder that this works at all. But well, maybe concepts are better. Maybe we would be able to extend the OR types for interfaces over module boundaries? But that is not really easy, I created the OR types solution five years ago and can not remember. You may look into the gen.nim generator file to check yourself.

ITwrx

comment created time in 9 days

issue commentStefanSalewski/gintro

[question] how to avoid type errors with child classes/objects?

For GTK4 we have these conversion procs which just do a cast:

const GTK4_EPI = """

proc getRootWidget*(self: Widget): Widget =
  let h = self.getRoot
  assert(toBool(g_type_check_instance_is_a(cast[ptr TypeInstance00](h.impl), gtk_widget_get_type())))
  #g_type_check_instance_is_a(cast[ptr TypeInstance00](result.impl), gt)))
  cast[Widget](h)

proc stringObject*(self: gobject.Object): StringObject =
  assert(toBool(g_type_check_instance_is_a(cast[ptr TypeInstance00](self.impl), gtk_string_object_get_type())))
  cast[StringObject](self)

proc fileInfo*(self: gobject.Object): gio.FileInfo =
  assert(toBool(g_type_check_instance_is_a(cast[ptr TypeInstance00](self.impl), g_file_info_get_type())))
  cast[gio.FileInfo](self)

but Gtk.MediaFile implements Gdk.Paintable

So this cast should compile and hopefully work:

$ grep -A7 gtk_picture_set_paintable ~/.nimble/pkgs/gintro-#v0.9.2/gintro/gtk4.nim 
proc gtk_picture_set_paintable(self: ptr Picture00; paintable: ptr gdk4.Paintable00) {.
    importc, libprag.}

proc setPaintable*(self: Picture; paintable: gdk4.Paintable = nil) =
  gtk_picture_set_paintable(cast[ptr Picture00](self.impl), if paintable.isNil: nil else: cast[ptr gdk4.Paintable00](paintable.impl))
  let paintable1 = gtk4.setPaintable(myPicture, cast[gdk4.Paintable](media_file1))

If you should get that working, next step would be to create a conversion proc to hide the ugly cast.

Note that your initial call of gtk4.setPaintable(media_file1) seems to make not much sense, as first parameter should be a Picture, and second parameter a Paintable or nil. For second parameter castgdk4.Paintable should hopefully work then.

See https://docs.gtk.org/gtk4/method.Picture.set_paintable.html

ITwrx

comment created time in 9 days

issue commentStefanSalewski/gintro

[question] how to avoid type errors with child classes/objects?

but Gtk.MediaFile implements Gdk.Paintable

My first guess is that the problem is that one data type is from module GTK and the other one from module GDK. Interfaces work well in gintro when all is in one single module, but not over module boundaries. To support the interfaces, gintro used OR-types currently. Automatically supporting that over module boundaries is not that easy, I think we would have to process all the modules multiple times during install. I think I can remember a few cases where we supported interfaces over module boundaries manually by providing a converter proc. Maybe you can try a plain cast. I will investigate this in more detail soon.

There has been some discussions to support GTK interfaces instead by or-types by concepts. But Nim's concept design changed recently, and I have to learn more about Nim's new concepts before I can decide if that may work.

ITwrx

comment created time in 9 days

issue commentStefanSalewski/gintro

[question] how to avoid type errors with child classes/objects?

Thanks for reporting, I will try to investigate this issue soon.

ITwrx

comment created time in 9 days

issue commentStefanSalewski/gintro

[FR] Modify gst example to use our gtk GUI instead of gst-launch

Unfortunately I can not really help you with GStreamer. It was never my intent to have all the gst modules actually in gintro. But then some years ago someone asked for it, and so I added it. And I added the plain video player example, by converting a C example. That guy vanished fast. Later we got someone who really used gstreamer on Windows 8.1, so it seems to work at least partially. But gstreamer is really complicated, it was a lot of effort to get all the gst modules to compile and to partly work.

GStreamer is really low level, so I would just use it from C, maybe from Rust. Well should be usable from Nim too, but there is not that much benefit from the Nim side. And I know nothing about gstreamer. On the GTK forum there is Mr. Dröge for GStreamer, who has a close relation to Rust. So maybe better use Rust.

ITwrx

comment created time in 15 days

push eventStefanSalewski/NimProgrammingBook

Stefan Salewski

commit sha 107b034d7fa3c13241da8e3b95b2858788572d9f

added pragma macro for iterator

view details

push time in 16 days