Go func returns error if run from OS X app bundle about ui

[andlabs]

Thanks :) Yes, I'm guessing it's that the application's activation policy has already been set (that's the only Cocoa startup routine that returns an error status); I'll look into it.

To make a valid .app bundle, do I just need to drop the binary in Contents/MacOS, or do I need to have some plist files as well?

[krolaw]

You need a plist. Here's some info I had some success with:
http://stackoverflow.com/questions/1596945/building-osx-app-bundle

[andlabs]

Can you please send me your plist or whole app bundle structure? I can't get a working bundle based on the given link. Thanks.

[krolaw]

Cheers.

On 23 June 2014 11:19, Pietro Gagliardi [email protected] wrote:

Can you please send me your plist or whole app bundle structure? I can't
get a working bundle based on the given link. Thanks.

—
Reply to this email directly or view it on GitHub
#6 (comment).

Richard Warburton - MSc(Hons), PGDipSci, BE(Hons) -
http://richard.warburton.it/
[phone] - PO Box 56710, Dominion Road, Auckland 1446, New Zealand

[andlabs]

Actually better idea: can you try building the redo/ folder test binary (go test -c) and seeing if that will work? (Don't close the issue if it does; I'm going to follow up with a patch to paply to see if it stops working.)

[krolaw]

Yeah, I'm currently hitting:
$ go get -u github.com/andlabs/ui

github.com/andlabs/ui

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x15672]

goroutine 16 [running]:
runtime.panic(0x1dae60, 0x31a9e4)
/usr/local/go/src/pkg/runtime/panic.c:279 +0xf5
main.(_typeConv).Type(0x20837c2c0, 0x220837f5c0, 0x208414720, 0x1ecf,
0x208498c01)
/usr/local/go/src/cmd/cgo/gcc.go:1288 +0x1632
main.(_typeConv).Type(0x20837c2c0, 0x220837f550, 0x208414630, 0x1ecf, 0x1)
/usr/local/go/src/cmd/cgo/gcc.go:1189 +0x3dd6
main.(*typeConv).Type(0x20837c2c0, 0x220837f728, 0x208454600, 0x1ecf, 0x0)

Which may be related to https://code.google.com/p/go/issues/detail?id=8238
?

Happy to upgrade to tip, but the issue does not appear to be fixed.

Thoughts?

On 3 August 2014 04:49, Pietro Gagliardi [email protected] wrote:

Actually better idea: can you try building the redo/ folder test binary (go
test -c) and seeing if that will work? (Don't close the issue if it does;
I'm going to follow up with a patch to paply to see if it stops working.)

—
Reply to this email directly or view it on GitHub
#6 (comment).

Richard Warburton - MSc(Hons), PGDipSci, BE(Hons) -
http://richard.warburton.it/
[phone] - PO Box 56710, Dominion Road, Auckland 1446, New Zealand

[andlabs]

that IS issue 8238, buh... do the "Try changing that line to do nothing if there is no entry in the typedef map and see what happens." Ian recommended there

this is a great breaking issue but the redo likely won't be finished for 1.3.1 I know that much so by that time it won't really be an issue anymore

[krolaw]

Ok, it works fine.

Cheers.

On 4 August 2014 16:22, Pietro Gagliardi [email protected] wrote:

that IS issue 8238, buh... do the "Try changing that line to do nothing if
there is no entry in the typedef map and see what happens." Ian recommended
there

this is a great breaking issue but the redo likely won't be finished for
1.3.1 I know that much so by that time it won't really be an issue anymore

—
Reply to this email directly or view it on GitHub
#6 (comment).

Richard Warburton - MSc(Hons), PGDipSci, BE(Hons) -
http://richard.warburton.it/
[phone] - PO Box 56710, Dominion Road, Auckland 1446, New Zealand

[andlabs]

All right. Now does it break when you change

        [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];

in uitask_darwin.m to

        NSLog(@"current activation policy: %d", [NSApp activationPolicy]);
        if ([NSApp setActivationPolicy:NSApplicationActivationPolicyRegular] == NO) {
                NSLog(@"fail"); return NO;
        }
        NSLog(@"success");

? What does it print?

[krolaw]

It didn't break, window appeared, however:
5/08/14 11:21:14.890 test[49977]: fail

Cheers.

On 4 August 2014 19:09, Pietro Gagliardi [email protected] wrote:

All right. Now does it break when you change

    [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];

in uitask_darwin.m to

    NSLog(@"current activation policy: %d", [NSApp activationPolicy]);
    if ([NSApp setActivationPolicy:NSApplicationActivationPolicyRegular] == NO) {
            NSLog(@"fail"); return NO;
    }
    NSLog(@"success");

? What does it print?

—
Reply to this email directly or view it on GitHub
#6 (comment).

Richard Warburton - MSc(Hons), PGDipSci, BE(Hons) -
http://richard.warburton.it/
[phone] - PO Box 56710, Dominion Road, Auckland 1446, New Zealand

[andlabs]

What did the current activation policy line say?

What do you see if you runt he binary outside of the app bundle instead?

[krolaw]

5/08/14 11:21:14.890 test[49977]: current activation policy: 0
5/08/14 11:21:14.890 test[49977]: fail

For both inside and outside the app bundle.

On 5 August 2014 13:56, Pietro Gagliardi [email protected] wrote:

What did the current activation policy line say?

What do you see if you runt he binary outside of the app bundle instead?

—
Reply to this email directly or view it on GitHub
#6 (comment).

Richard Warburton - MSc(Hons), PGDipSci, BE(Hons) -
http://richard.warburton.it/
[phone] - PO Box 56710, Dominion Road, Auckland 1446, New Zealand

[andlabs]

Then I have absolutely no idea what's going on here. I'm going to assume NSApplication won't allow changing the activation policy to something else when the application is in an app bundle, even if the policy is the same! (0 is the regular activation policy indicating regular apps; this is what we want.)

I'll strip the error checking from the init code. It'll apply to the redo folder only for now.

Thanks again, and sorry for the delays/questions.