Re: [go-nuts] shiny driver.Main not returning

2017-09-07 Thread Nigel Tao
For the record, the OP filed https://github.com/golang/go/issues/21796

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] shiny driver.Main not returning

2017-09-07 Thread Dave MacFarlane
I don't have any particular insights explaining it, but I just tried
adding a print after at the end of my shiny-based text editor and (at
least on OS X), indeed, it never gets executed. It appears to be a bug
(at the very least, a documentation bug since it explicitly says it
returns.)


On Thu, Sep 7, 2017 at 3:08 PM,   wrote:
> Hi Dave,
>
> Thanks for the reply.
>
> My example above was stripped down for illustration purposes, not to make a
> useful graphical program.  I get the same result when creating a window.
>
> I've read through most of the examples, and have based my code on them,
> which works quite well.  I paint a billiard table on the main window and
> update ball positions via multicast messages, which are being read in
> another goroutine, which in turn sends ball positions on a channel, and a
> third goroutine receives from the channel and sends paint events (as well as
> custom events I create) to the window's EventDeque.  All this works well,
> but I want to clean up properly (e.g., leave the multicast group, release
> resources, etc.) if the program quits via the GUI.  I can put this all in a
> deferred function to the one passed to driver.Main, but at first I had it
> after the call to driver.Main.  I was wondering why this doesn't work.
>
> I'll add the the simple, stripped down, example above to make things clear.
> Here I create a window and then return, which panics.  I played around with
> this a while ago and figured that it has something to do with the lifecycle
> events.  (I also noticed that it panics if I call Send on the EventDeque too
> early, possibly before certain lifecycle events are placed on it?)  I'd like
> to understand better why it panics too!
>
> So if I run this:
>
> package main
>
> import (
> "fmt"
> "log"
>
> "golang.org/x/exp/shiny/driver"
> "golang.org/x/exp/shiny/screen"
> )
>
> func main() {
> fmt.Println("Starting.")
> driver.Main(func(s screen.Screen) {
> fmt.Println("I'm printed; you can see me.")
> w, err := s.NewWindow(&screen.NewWindowOptions{Title: "I Don't Return"})
> if err != nil {
> log.Fatal(err)
> }
> defer w.Release()
> fmt.Println("You can see me too.")
> return
> })
> fmt.Println("I'm not printed; alas, I can't be seen.")
> }
>
> I get this:
>
> william@hardy% go run main.go
>
> Starting.
>
> I'm printed; you can see me.
>
> You can see me too.
>
> panic: runtime error: invalid memory address or nil pointer dereference
>
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x40bac17]
>
>
> goroutine 1 [running, locked to thread]:
>
> golang.org/x/exp/shiny/driver/gldriver.preparedOpenGL(0x4367a20, 0x451eb10,
> 0x1)
>
> /Users/william/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:91 +0xb7
>
> golang.org/x/exp/shiny/driver/gldriver._cgoexpwrap_78313b9f6607_preparedOpenGL(0x4367a20,
> 0x451eb10, 0x1)
>
> golang.org/x/exp/shiny/driver/gldriver/_obj/_cgo_gotypes.go:345 +0x3f
>
> golang.org/x/exp/shiny/driver/gldriver._Cfunc_startDriver()
>
> golang.org/x/exp/shiny/driver/gldriver/_obj/_cgo_gotypes.go:305 +0x41
>
> golang.org/x/exp/shiny/driver/gldriver.main(0x4108550, 0x0, 0xc420053f10)
>
> /Users/william/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:107 +0x51
>
> golang.org/x/exp/shiny/driver/gldriver.Main(0x4108550)
>
> /Users/william/src/golang.org/x/exp/shiny/driver/gldriver/gldriver.go:26
> +0x2f
>
> golang.org/x/exp/shiny/driver.main(0x4108550)
>
> /Users/william/src/golang.org/x/exp/shiny/driver/driver_darwin.go:15 +0x2b
>
> golang.org/x/exp/shiny/driver.Main(0x4108550)
>
> /Users/william/src/golang.org/x/exp/shiny/driver/driver.go:24 +0x2b
>
> main.main()
>
> /Users/william/src/play/shiny/main.go:13 +0x7b
>
> exit status 2
>
> william@hardy%
>
>
> But if I add code to process events, it doesn't panic.  Adding such code and
> running this:
>
> package main
>
> import (
> "fmt"
> "image"
> "log"
>
> "golang.org/x/exp/shiny/driver"
> "golang.org/x/exp/shiny/screen"
> "golang.org/x/mobile/event/key"
> "golang.org/x/mobile/event/lifecycle"
> "golang.org/x/mobile/event/paint"
> "golang.org/x/mobile/event/size"
> )
>
> func main() {
> fmt.Println("Starting.")
> driver.Main(func(s screen.Screen) {
> fmt.Println("I'm printed; you can see me.")
> w, err := s.NewWindow(&screen.NewWindowOptions{Title: "I Don't Return"})
> if err != nil {
> log.Fatal(err)
> }
> defer w.Release()
>
> var b screen.Buffer
> defer func() {
> if b != nil {
> b.Release()
> }
> }()
>
> fmt.Println("You can see me too.")
> for {
> switch e := w.NextEvent().(type) {
> case lifecycle.Event:
> if e.To == lifecycle.StageDead {
> return
> }
> case key.Event:
> if e.Direction == key.DirPress && e.Modifiers == key.ModMeta {
> switch e.Code {
> case key.CodeQ:
> return
> }
> }
> case paint.Event:
> w.Upload(image.Point{}, b, b.Bounds())
> w.Publish()
> case size.Event:
> if b != nil {
> b.Release()
> }
> b, err = s.NewBuffer(e.Size())
> if err != nil {
> log.Fatal(err)
> }
> case error:
> log.Print(e)
> }
> }
> })
> fmt.Println("I'm not printed; alas, I can'

Re: [go-nuts] shiny driver.Main not returning

2017-09-07 Thread hanisch
Hi Dave,

Thanks for the reply.

My example above was stripped down for illustration purposes, not to make a 
useful graphical program.  I get the same result when creating a window.

I've read through most of the examples, and have based my code on them, 
which works quite well.  I paint a billiard table on the main window and 
update ball positions via multicast messages, which are being read in 
another goroutine, which in turn sends ball positions on a channel, and a 
third goroutine receives from the channel and sends paint events (as well 
as custom events I create) to the window's EventDeque.  All this works 
well, but I want to clean up properly (e.g., leave the multicast group, 
release resources, etc.) if the program quits via the GUI.  I can put this 
all in a deferred function to the one passed to driver.Main, but at first I 
had it after the call to driver.Main.  I was wondering why this doesn't 
work.

I'll add the the simple, stripped down, example above to make things clear. 
 Here I create a window and then return, which panics.  I played around 
with this a while ago and figured that it has something to do with the 
lifecycle events.  (I also noticed that it panics if I call Send on the 
EventDeque too early, possibly before certain lifecycle events are placed 
on it?)  I'd like to understand better why it panics too!

So if I run this:

package main

import (
"fmt"
"log"

"golang.org/x/exp/shiny/driver"
"golang.org/x/exp/shiny/screen"
)

func main() {
fmt.Println("Starting.")
driver.Main(func(s screen.Screen) {
fmt.Println("I'm printed; you can see me.")
w, err := s.NewWindow(&screen.NewWindowOptions{Title: "I Don't Return"})
if err != nil {
log.Fatal(err)
}
defer w.Release()
fmt.Println("You can see me too.")
return
})
fmt.Println("I'm not printed; alas, I can't be seen.")
}

I get this:

william@hardy% go run main.go

Starting.

I'm printed; you can see me.

You can see me too.

panic: runtime error: invalid memory address or nil pointer dereference

[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x40bac17]


goroutine 1 [running, locked to thread]:

golang.org/x/exp/shiny/driver/gldriver.preparedOpenGL(0x4367a20, 0x451eb10, 
0x1)

/Users/william/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:91 +0xb7

golang.org/x/exp/shiny/driver/gldriver._cgoexpwrap_78313b9f6607_preparedOpenGL(0x4367a20,
 
0x451eb10, 0x1)

golang.org/x/exp/shiny/driver/gldriver/_obj/_cgo_gotypes.go:345 +0x3f

golang.org/x/exp/shiny/driver/gldriver._Cfunc_startDriver()

golang.org/x/exp/shiny/driver/gldriver/_obj/_cgo_gotypes.go:305 +0x41

golang.org/x/exp/shiny/driver/gldriver.main(0x4108550, 0x0, 0xc420053f10)

/Users/william/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:107 +0x51

golang.org/x/exp/shiny/driver/gldriver.Main(0x4108550)

/Users/william/src/golang.org/x/exp/shiny/driver/gldriver/gldriver.go:26 
+0x2f

golang.org/x/exp/shiny/driver.main(0x4108550)

/Users/william/src/golang.org/x/exp/shiny/driver/driver_darwin.go:15 +0x2b

golang.org/x/exp/shiny/driver.Main(0x4108550)

/Users/william/src/golang.org/x/exp/shiny/driver/driver.go:24 +0x2b

main.main()

/Users/william/src/play/shiny/main.go:13 +0x7b

exit status 2

william@hardy%

But if I add code to process events, it doesn't panic.  Adding such code 
and running this:

package main

import (
"fmt"
"image"
"log"

"golang.org/x/exp/shiny/driver"
"golang.org/x/exp/shiny/screen"
"golang.org/x/mobile/event/key"
"golang.org/x/mobile/event/lifecycle"
"golang.org/x/mobile/event/paint"
"golang.org/x/mobile/event/size"
)

func main() {
fmt.Println("Starting.")
driver.Main(func(s screen.Screen) {
fmt.Println("I'm printed; you can see me.")
w, err := s.NewWindow(&screen.NewWindowOptions{Title: "I Don't Return"})
if err != nil {
log.Fatal(err)
}
defer w.Release()

var b screen.Buffer
defer func() {
if b != nil {
b.Release()
}
}()

fmt.Println("You can see me too.")
for {
switch e := w.NextEvent().(type) {
case lifecycle.Event:
if e.To == lifecycle.StageDead {
return
}
case key.Event:
if e.Direction == key.DirPress && e.Modifiers == key.ModMeta {
switch e.Code {
case key.CodeQ:
return
}
}
case paint.Event:
w.Upload(image.Point{}, b, b.Bounds())
w.Publish()
case size.Event:
if b != nil {
b.Release()
}
b, err = s.NewBuffer(e.Size())
if err != nil {
log.Fatal(err)
}
case error:
log.Print(e)
}
}
})
fmt.Println("I'm not printed; alas, I can't be seen.")
}

and either choose the Quit menu option on the top menu bar or hit 
Command-Q, I get this:

william@hardy% go run main.go

Starting.

I'm printed; you can see me.

You can see me too.

william@hardy%

Notice that "I'm not printed; alas, I can't be seen." is not printed to 
stdout, implying that driver.Main is not returning normally.

Can you point me somewhere to understand this better?

Thanks again for your help!

William


On Thursday, September 7, 2017 at 2:07:20 PM UTC-4, Dave MacFarlane wrote:
>
> What are you trying to do? I don't see the point in a shiny program 
> that doesn't even cre

Re: [go-nuts] shiny driver.Main not returning

2017-09-07 Thread Dave MacFarlane
What are you trying to do? I don't see the point in a shiny program
that doesn't even create a window. There's likely a loop internally in
the driver that's handling processing of events from the OS and since
you're never creating a window, it's never exiting (this is just a
guess, I haven't looked at the code lately.)

Have you looked at the samples in
https://github.com/golang/exp/tree/master/shiny/example? They're
likely a better place to start.


On Thu, Sep 7, 2017 at 12:32 PM,   wrote:
> I'm using shiny for a small internal project and noticed that driver.Main
> doesn't seem to return.
>
> The documentation for:
>
> func Main(f func(screen.Screen))
>
> in golang.org/x/exp/shiny/driver sates that "It returns when f returns."
>
> But when I run this:
>
> package main
>
> import (
> "fmt"
>
> "golang.org/x/exp/shiny/driver"
> "golang.org/x/exp/shiny/screen"
> )
>
> func main() {
> fmt.Println("Starting.")
> driver.Main(func(s screen.Screen) {
> fmt.Println("I'm printed; you can see me.")
> return
> })
> fmt.Println("I'm not printed; alas, I can't be seen.")
> }
>
> on a MacBook Pro running macOS Sierra Version 10.12.6 and go1.9 darwin/amd64
> that last print statement is not called.  It's as though os.Exit, or an
> equivalent, is being called somewhere within driver.Main and below, though I
> can't seem to find any such call in the source.
>
> I've tried to do a web search for this but didn't get any useful links
> either.  I understand that shiny is experimental and that development has
> paused recently, but I'm just trying to understand what's going on.
>
> Any help is very much appreciated!
>
> William
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
- Dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] shiny driver.Main not returning

2017-09-07 Thread hanisch
I'm using shiny for a small internal project and noticed that driver.Main 
doesn't seem to return.

The documentation for:

func Main(f func(screen .
Screen ))

in golang.org/x/exp/shiny/driver sates that "It returns when f returns."

But when I run this:

package main

import (
"fmt"

"golang.org/x/exp/shiny/driver"
"golang.org/x/exp/shiny/screen"
)

func main() {
fmt.Println("Starting.")
driver.Main(func(s screen.Screen) {
fmt.Println("I'm printed; you can see me.")
return
})
fmt.Println("I'm not printed; alas, I can't be seen.")
}

on a MacBook Pro running macOS Sierra Version 10.12.6 and go1.9 
darwin/amd64 that last print statement is not called.  It's as though 
os.Exit, or an equivalent, is being called somewhere within driver.Main and 
below, though I can't seem to find any such call in the source.

I've tried to do a web search for this but didn't get any useful links 
either.  I understand that shiny is experimental and that development has 
paused recently, but I'm just trying to understand what's going on.

Any help is very much appreciated!

William

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.