go-qml is broken under Go 1.7

[cers000]

No description provided.

[jeanlucmongrain]

no description? no details? no error?

worst issue report ever

[immesys]

Haha, I've got to save this one as an example of what not to do.

[prologic]

Whilst this is a crappy issue report; I'll tack on some details:

Many of the examples do not run when compiled under Go 1.7 (they do build however). Example error:

prologic@Jamess-MacBook
Sat Sep 03 02:00:27
~/tmp/qml/examples/gopher
 (v1) 2
$ go build

prologic@Jamess-MacBook
Sat Sep 03 02:00:34
~/tmp/qml/examples/gopher
 (v1) 0
$ ./gopher
panic: runtime error: cgo argument has Go pointer to Go pointer

goroutine 1 [running, locked to thread]:
panic(0x419a600, 0xc42009aac0)
        /usr/local/Cellar/go/1.7/libexec/src/runtime/panic.go:500 +0x1a1
gopkg.in/qml%2ev1._cgoCheckPointer0(0xc4202af500, 0xc42009aab0, 0x1, 0x1, 0xc42009a908)
        ??:0 +0x59
gopkg.in/qml%2ev1.registerType.func1()
        /Users/prologic/go/src/gopkg.in/qml.v1/qml.go:1052 +0x4eb
gopkg.in/qml%2ev1.hookIdleTimer()
        /Users/prologic/go/src/gopkg.in/qml.v1/bridge.go:190 +0x66
gopkg.in/qml%2ev1._cgoexpwrap_0ae46c052b10_hookIdleTimer()
        ??:0 +0x14
gopkg.in/qml%2ev1._Cfunc_applicationExec()
        ??:0 +0x41
gopkg.in/qml%2ev1.Run(0x41cbeb0, 0x0, 0x0)
        /Users/prologic/go/src/gopkg.in/qml.v1/bridge.go:63 +0xca
main.main()
        /Users/prologic/tmp/qml/examples/gopher/gopher.go:16 +0x69

[prologic]

I do not yet understand the error s I'm only very new to Golang myself :)

[mixedCase]

This is just #170, it should be closed as a duplicate.

[prologic]

Agreed

[cers000]

Is this Projects stop to develop?

[mixedCase]

@cers000 Yes, it looks dead.

[russel]

@cers000 @mixedCase Rather than just be upset and despondent because someone else has stopped doing stuff on a project, isn't it the right FOSS thing to fork the project and keep it going by getting new developers and contributors?

Alternatively get @niemeyer to add new owners and contributors to this project so that it can progress even in his absence.

[niemeyer]

Indeed. Apologies, but this is not a priority right now, and I cannot foresee when I'll be able to come back into it. Is there anyone at the moment with a fork that has fixes for the most relevant issues? Happy to include more contributors.

[russel]

@niemeyer Can I suggest you add a couple of other owners to this project, so that things can progress without you being put upon? This project is too much fun to lose.

I'd also suggest getting other people involved in the gopkg.in stuff so as to allow new releases as and when.

[niemeyer]

As I said, I don't mind adding other contributors. But it doesn't help to simply add anyone arbitrarily, as it won't change the situation. Which is why I ask: do we have any high profile forks right now, which would hint at a potential co-maintainer?

[neclepsio]

I think https://github.com/limetext/qml-go/ looks the most promising. Hoping they add Go 1.6 support soon.

[niemeyer]

@ricochet1k Hey, would you be interested in moving your changes here and becoming a co-maintainer? Do you expect to continue engaged in the project in the foreseeable future?

[prologic]

@ricochet1k friendly ping :)

[ricochet1k]

@niemeyer Sure, I could do that. I haven't had a lot of time to work on the lime-qml project recently, but I do want to get back to it. My 1.6 branch currently works, but I'm pretty sure it has a GC issue and needs a little cleanup to make sure references get cleaned up properly, which I'm sure I can do, I just haven't found the time.

[amlwwalker]

Hi All,

I ran into this error a while back. I can briefly explain what is going on here. go-qml passes (or receives, I can't remember) a pointer to a pointer to C code within the qml libraries. Doing so means that the Go garbarge collector cannot see whether the pointer has been released by the C code. This can lead to memory leaks so in go1.6 this was made a forbidden thing to do (and is only detected at runtime). So hence the error: cgo argument has Go pointer to Go pointer.

github.com/SjB/qml solves this in its latest branch, however SjB doesn't seem to be monitoring the repo, so I have forked it and although my knowledge of the low level api to the qml libraries is unknown to me, I am managing the code to make the examples work and plan to make small changes to make it convenient to use going forward. You can find it at https://github.com/amlwwalker/qml

I'm using it now actively, so I can help people get set up if they are struggling with post 1.6 qml and Go.

A

[jackman0]

@amlwwalker What does this mean? Can/will your code get merged into the github.com/go-qml/qml repo? Thank you.

[russel]

@niemeyer Might it be worth adding control of this repository to someone like Jamal Saepul Aziz ( @jamalsa , see #189) rather than have people forking and no-one knowing which the main QML binding for GGo is, it would be better for this repository to be the mainline.

[niemeyer]

@russel What I said earlier still stands:

Indeed. Apologies, but this is not a priority right now, and I cannot foresee when I'll be able to come back into it. Is there anyone at the moment with a fork that has fixes for the most relevant issues? Happy to include more contributors.
(...)
As I said, I don't mind adding other contributors. But it doesn't help to simply add anyone arbitrarily, as it won't change the situation. Which is why I ask: do we have any high profile forks right now, which would hint at a potential co-maintainer?

In other words, we need some tangible indication that whoever is coming on board will keep the project going for the foreseeable future. Without that, the individual forks are fine and a better way to represent the real status quo: we don't have an active maintainer.

[shayneoneill]

If this is dead, is there an alternative QML binding thats active?