go-qml / qml

QML support for the Go language
Other
1.96k stars 189 forks source link

go-qml is broken under Go 1.7 #179

Open cers000 opened 7 years ago

jeanlucmongrain commented 7 years ago

no description? no details? no error?

worst issue report ever

immesys commented 7 years ago

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

prologic commented 7 years ago

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 commented 7 years ago

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

mixedCase commented 7 years ago

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

prologic commented 7 years ago

Agreed

cers000 commented 7 years ago

Is this Projects stop to develop?

mixedCase commented 7 years ago

@cers000 Yes, it looks dead.

russel commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

niemeyer commented 7 years ago

@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 commented 7 years ago

@ricochet1k friendly ping :)

ricochet1k commented 7 years ago

@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 commented 7 years ago

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 commented 6 years ago

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

russel commented 5 years ago

@niemeyer Might it be worth adding control of this repository to someone like Jamal Saepul Aziz ( @jamalsa , see https://github.com/go-qml/qml/issues/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 commented 5 years ago

@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 commented 5 years ago

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