import gobject var ttta: GObject var tttb: GTypeModule #var tttb: ptr GTypeModuleObj g_clear_object(ttta) g_clear_object(tttb)
Last line gives:
t2.nim(8, 14) Error: type mismatch: got (GTypeModule, proc (gpointer){.cdecl.}) but expected one of: glib.g_clear_pointer(pp: ptr gpointer, destroy: GDestroyNotify)
The above code is nonsense of course, but I was hoping it would compile. My real code is from a source view completion example and includes multiple modules. I tried to make a minimal example, but that one compiled fine.
GObject module is https://github.com/StefanSalewski/nim-gobject
from that module:
type
GTypeModule* = ptr GTypeModuleObj
GTypeModulePtr* = ptr GTypeModuleObj
GTypeModuleObj*{.final.} = object of GObjectObj
proc g_clear_object*(object_ptr: var GObject) {.importc: "g_clear_object",
libgobj.}
template g_clear_object*(object_ptr: expr): expr =
g_clear_pointer(object_ptr, g_object_unref)
My guess is, that the above template may cause the problems, because it has the same name as the proc. Have not yet tried to remove it from gobject module. That template was auto-generated, before I remove it, I have to check what it shall do and how I can replace it. But it is expected that it cause trouble?
Hi @Stefan_Salewski, I don't have an answer to your problem, sorry.
But I'd like to ask: Could you please use more informative subject-lines for your forum posts?
It should be possible to understand what a thread will be about, just by looking at the list of subject-lines in the forum index page. Subject-lines like "I may have a problem" and "Guess I am doing something wrong again" are not informative or descriptive.
More informative subject-lines for these threads might be "Hint: conversion from GObject to itself is pointless" and "Error: type mismatch, due to a template?" or "Does a template override a proc with the same name?".
If you solve your problems after you post questions about them, it would also be appreciated if you could post a short follow-up description of what the problem turned out to be, and how you solved it.
Thanks!
More informative subject-lines
I do fully agree. Generally is is very bad when people use stupid subject lines. It is also bad, when people write what they did and what not worked, instead of writing what they want to archive. And of course it is bad when people have an actual problem with code, and give no minimal example code.
So I am aware of this: Whenever possible I use a meaningful subject, write what I want to archive, and try to give a minimal example. For this post: I spent 30 minutes to make a minimal example without use of one of my GTK modules,showing this problem, but that one worked well. So I made a minimal example showing my problem, but involving one of my modules available at github. So only the subject line is left: Yesterday I had really no idea about a useful subject line. Your proposals may be indeed better -- I am not really sure. Maybe it would be fine when we are allowed to change the subject line when in the discussion it becomes clear what the core of it is. I think currently I can edit my post, but not the subject line. Maybe it would be even a good idea if it would be possible to completely delete threads in the forum -- personally I would like that, I hate all the garbage in the Internet. Another question is, if we should use other channels for "strange" problems. The problem with Forums is, that is is public visible, so all stupid content is generally bad. For the IRC channel -- I have used it for some very basic, simple questions. But I am not able to explain problems as the above there -- surely you will have noticed that English is not my native language. Now there is the mailing list -- I am willing to use that, but it is called something as Nim-Developer, so I guess it is more for discussion of core developer? An there is the Github bug tracker -- I have used that once, and will use it again when I am sure I found a bug.
stefan@AMD64X2 ~ $ mkdir foraraq
stefan@AMD64X2 ~ $ cd foraraq
stefan@AMD64X2 ~/foraraq $ git clone https://github.com/StefanSalewski/nim-glib
stefan@AMD64X2 ~/foraraq $ git clone https://github.com/StefanSalewski/nim-gobject
stefan@AMD64X2 ~/foraraq $ ln -s nim-glib/src/glib.nim
stefan@AMD64X2 ~/foraraq $ ln -s nim-gobject/src/gobject.nim
stefan@AMD64X2 ~/foraraq $ cp ~/araqproof/test.nim .
stefan@AMD64X2 ~/foraraq $ cat test.nim
import gobject
var ttta: GObject
var tttb: GTypeModule
#var tttb: ptr GTypeModuleObj
g_clear_object(ttta)
g_clear_object(tttb)
stefan@AMD64X2 ~/foraraq $ nim c test.nim
test.nim(8, 14) Error: type mismatch: got (GTypeModule, proc (gpointer){.cdecl.})
but expected one of:
glib.g_clear_pointer(pp: ptr gpointer, destroy: GDestroyNotify)
stefan@AMD64X2 ~/foraraq $ nim -v
Nim Compiler Version 0.10.3 (2015-03-04) [Linux: amd64]
Unfortunately my gobject and glib are still involved, I am not able to get a similar error with a module without imports. So I still think it is not a compiler bug.
stefan@AMD64X2 ~/foraraq $ pwd /home/stefan/foraraq stefan@AMD64X2 ~/foraraq $ cat t2.nim import gobject proc test_provider_dispose(gobject: GObject) = var ttta: GObject var tttb: gobject.GObject echo 0 stefan@AMD64X2 ~/foraraq $ nim c t2.nim t2.nim(6, 19) Hint: conversion from GObject to itself is pointless [ConvFromXtoItselfNotNeeded] t2.nim(6, 19) Error: type expected
Late in the evening, I thought that having type GObject in module gobject was the problem, and I was really going to rename all the stuff. But obviously it is only the name of the proc parameter :-)
Compiles fine now with Nim Compiler Version 0.10.3 (2015-03-19) [Linux: amd64].
Thanks for fixing.