Works! What a strange behavior... I'll create the issue - or even two on the github later today.
Thanks Sebastien for your help! W dniu poniedziałek, 7 listopada 2016 12:58:52 UTC+1 użytkownik Sebastien Binet napisał: > > > > On Mon, Nov 7, 2016 at 12:44 PM, Seb Binet <seb....@gmail.com > <javascript:>> wrote: > >> >> >> On Sun, Nov 6, 2016 at 8:21 PM, Mateusz Dymiński <dymi...@gmail.com >> <javascript:>> wrote: >> >>> I haven't played with the plugin feature yet, but some things stand out >>>> to me about your code and I wonder if it is correct or not. >>>> Is there a difference in using go build vs go run, in the same way as >>>> you can get bad behaviour using go run with more complex apps? >>> >>> Have you tried moving those plugins to subdirs so that you don't have 3 >>>> mains in one location when running go build? >>> >>> >>> I tried to move the implementation to separate directories - no success. >>> Same thing with 'go run' and 'go build' and then run the binary. Changes >>> are already in the repo: https://github.com/mateuszdyminski/go-plugin >>> >>> Is it necessary to import the processor and printer libs just so that >>>> you can make specific interface values? If interfaces are satisfied >>>> implicitly, then why can't you just make an instance of your local >>>> concrete >>>> type without importing the interfaces? "Impl" should be able to satisfy a >>>> printer or processor without you explicitly importing and declaring it as >>>> one. Unless something is special about plugins? >>> >>> >>> The example in the repository is the simplest way to reproduce the bug >>> which I probably found in the plugin feature. >>> >>> The truth is that I would like to write the MapReduce implementation >>> where there is master process which coordinates the worker processes and >>> similar to the Hadoop user can submit the job which should be calculated by >>> the MapReduce. User has to write struct which should implement the >>> MapReduce interface - it tells to the workers how the 'map' and 'reduce' >>> phase should be calculated. In the same time this framework should be able >>> to calculate multiple jobs with multiple implementations of MapReduce and >>> that's why I need to load the different plugins multiple times. I guess >>> It's great use case for the new plugin feature. >>> >> >> it is probably a bug in stdlib's "plugin". >> >> but, if you modify your build's instructions from: >> cd printer-impl && go build -buildmode=plugin printer.go >> cd processor-impl && go build -buildmode=plugin processor.go >> go run main.go >> >> to: >> cd printer-impl && go build -buildmode=plugin . >> cd processor-impl && go build -buildmode=plugin . >> go run main.go >> >> (after having modified "main.go" to load "printer-impl/printer-impl.so" >> and "processor/processor-impl.so") >> >> everything works. >> >> (modifying plugin compilation to "go build -buildmode=plugin -o >> printer.so ." fails later with: >> panic: runtime error: invalid memory address or nil pointer dereference >> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 >> pc=0x7f23278e9cc0] >> >> goroutine 1 [running]: >> panic(0x498720, 0x6db110) >> /home/binet/dev/go/root/go/src/runtime/panic.go:531 +0x1cf >> os.(*File).write(0x0, 0xc42000c260, 0x13, 0x20, 0x20, 0xc42007c000, >> 0x7f2327914717) >> /home/binet/dev/go/root/go/src/os/file_unix.go:181 +0x50 >> os.(*File).Write(0x0, 0xc42000c260, 0x13, 0x20, 0x1, 0x1, 0x0) >> /home/binet/dev/go/root/go/src/os/file.go:142 +0x7e >> fmt.Fprintf(0x7f2327ba30e0, 0x0, 0x7f2327914707, 0x11, 0xc42004be68, 0x1, >> 0x1, 0xc420010180, 0xc42004be58, 0xc420010180) >> /home/binet/dev/go/root/go/src/fmt/print.go:182 +0xab >> fmt.Printf(0x7f2327914707, 0x11, 0xc42004be68, 0x1, 0x1, 0xc42001a120, >> 0xc42001a120, 0x0) >> /home/binet/dev/go/root/go/src/fmt/print.go:190 +0x77 >> >> github.com/mateuszdyminski/go-plugin/printer-impl.PrinterImpl.Print(0x4a53b0, >> >> 0x4) >> /home/binet/dev/go/root/path/src/ >> github.com/mateuszdyminski/go-plugin/printer-impl/printer.go:16 +0xac >> >> github.com/mateuszdyminski/go-plugin/printer-impl.(*PrinterImpl).Print(0x7f2327bbff20, >> >> 0x4a53b0, 0x4) >> <autogenerated>:1 +0x5b >> main.main() >> /home/binet/dev/go/root/path/src/ >> github.com/mateuszdyminski/go-plugin/main.go:26 +0x122 >> >> so that's probably another plugin bug.) >> > > ah. it seems that for the last issue, one "just" has to import "os" in > go-plugin/main.go. > and it magically fixes everything as a weird side-effect. > > -s > > -- 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.
