go-qml is broken under Go 1.6

[vially]

Running the gopher example fails with: panic: runtime error: cgo argument has Go pointer to Go pointer.

Most probably this has to do with the cgo changes present in Go 1.6

[nbgo]

Panic can be suppressed by setting the environment variable GODEBUG=cgocheck=0

[SjB]

I've been able to put some time into this issue. You can go check commit at 826359a.

I've been able to compile and run the customtype example.

I'll be cleaning thing up and adding some more testing.

[SjB]

More progress today:

Refactor: connectedFunction, TypeSpec, and valueFold all to support cgo Go pointer issue.

I was able to compile and run the gopher example.

latest commit at 0309d2d

[immesys]

Any chance of getting this merged in?

[immesys]

@SjB do you think your changes have addressed all the problems? This is a blocking issue for me

[amlwwalker]

@vially The answer to this problem is documented at the bottom of this readme. Its an easy fix: https://golog.co/blog/article/Using_Go_with_QML_part_1

[immesys]

@amlwwalker that is not a "fix", that simply disables the check...

[SjB]

@immesys I was able to run all the example except for snapweb. But the error with that example is a very different issue.

[immesys]

@SjB today I encountered some problems with your fix. From qml I call a go function which returns a go type. If I then try pass that go type to another go function (inside qml) it panics with "cannot find fold go reference". The same access pattern works fine without the fix and cgocheck=0.

Apart from that, everything has been working fine. Do you think this issue can be fixed?

[SjB]

@immesys can you send me some codes that would replicated this error.

[binary132]

Would love to see this fixed. Any ETA @SjB / @immesys? Can we get the example? @immesys, perhaps this is related to the new cgo rules?

(e.g. don't pass Go-allocated pointers to memory containing other Go-allocated pointers through C functions)

[immesys]

Hi, sorry @SjB, @binary132 I did not make a reproducer earlier, I've been pretty busy. Here it is:

https://github.com/immesys/go-qml-fix-problem

[cortex]

@SjB Your branch is working fine for me here: https://github.com/cortex/gopass Thanks! I hope we can get this merged soon!

[immesys]

Did someone try my reproducer?

[larryprice]

@SjB Works great for me - please submit a PR!

[immesys]

@SjB @larryprice @cortex the branch does not work completely yet. Take a look here:

https://github.com/immesys/go-qml-fix-problem

It cannot handle go -> qml -> go, whereas that used to work fine.

[binary132]

@immesys maybe we can get a PR with a unit test which can show the breakage under Go 1.6.

That way forks such as @SjB's can be shown by automated test to solve the problem, or not.

[binary132]

Or, you could open the PR against @SjB's fork containing your breaking test. That way he can fix the breakage in his fork before opening the PR against this repo.

[SjB]

Thanks @immesys for sending me your codes. I finally had a few hours to look into this.

good news is that I have found and fixed the bug. We can now use a Go struct in a qml component script.

Please test away and let me know if I should do a pull request.

[neclepsio]

@SjB I have a reproducer for another crash. As soon as the mouse is moved on the MouseArea, it crashes. The number for the unsupported data type is always different.

Could you please take a look?

panic: unsupported data type: 83738736

goroutine 1 [running, locked to thread]:
panic(0x4f6600, 0xc042090050)
    F:/Windows/Go/Go17/src/runtime/panic.go:500 +0x1af
github.com/neclepsio/qml.unpackDataValue(0x22afc0, 0xc042078030, 0x13, 0x5e7440)
    F:/Home-Mirror/Programming/Go-Workspace/src/github.com/neclepsio/qml/datatype.go:196 +0x412
github.com/neclepsio/qml.hookSignalCall(0x182f7b0, 0xc04207a010, 0x22afc0)
    F:/Home-Mirror/Programming/Go-Workspace/src/github.com/neclepsio/qml/qml.go:933 +0x189
github.com/neclepsio/qml._cgoexpwrap_f6d998d4cbab_hookSignalCall(0x182f7b0, 0xc04207a010, 0x22afc0)
    ??:0 +0x46
github.com/neclepsio/qml._Cfunc_applicationExec()
    ??:0 +0x48
github.com/neclepsio/qml.Run(0x5311f0, 0x0, 0x0)
    F:/Home-Mirror/Programming/Go-Workspace/src/github.com/neclepsio/qml/bridge.go:63 +0xd1
main.main()
    F:/Home-Mirror/Programming/Go-Workspace/src/github.com/neclepsio/qml-reproduce/test.go:28 +0x38

package main

import (
    "fmt"
    "os"

    "github.com/neclepsio/qml"
)

const test_qml = `
import QtQuick 2.2
import QtQuick.Controls 1.1

ApplicationWindow {
    width: 640
    height: 280

    MouseArea {
        objectName: "mouseArea"
        hoverEnabled: true

        anchors.fill: parent
    }
}
`

func main() {
    if err := qml.Run(run); err != nil {
        fmt.Fprintf(os.Stderr, "error: %v\n", err)
        os.Exit(1)
    }
}

func run() error {
    engine := qml.NewEngine()
    component, err := engine.LoadString("test.qml", test_qml)
    if err != nil {
        return err
    }

    win := component.CreateWindow(nil)

    mouseArea := win.Root().ObjectByName("mouseArea")
    mouseArea.On("positionChanged", func(mouseEvent qml.Object) {
    })

    win.Show()
    win.Wait()

    return nil
}

[SjB]

Thanks @neclepsio, for finding this bug, you can find the fix on my repo here f9db098

[mixedCase]

@SjB Are there any known bugs on your branch or could it be used in production? This repo is hopelessly dead, I assume there's no more funding by Canonical.

[immesys]

I would advise against production use. I eventually moved away because of numerous problems with qml types to go code and vice versa. It ends up being very time consuming to debug and work around.

[mixedCase]

@immesys Moved to any other package, language and/or toolkit?

[immesys]

Moved to C++/QML talking to go code over RPC

[neclepsio]

@mixedCase, I use @SjB's branch in production with no problem.

[vially]

Closing due to inactivity. Also, it seems unlikely this will get fixed since the project seems unmaintained at this point.

[Leopold-cz]

已收到您的邮件！蒋