[go-nuts] Re: Gobot Beaglebone Black GPIO question...

[Curtis Paul]

I'm at a loss...

https://godoc.org/gobot.io/x/gobot#Eventer

I think the first thing is that I'm not sure I understand how to diagnose 
this codehow to validate it's doing what I think it may or may not be 
doing.

-- 
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] Re: Gobot Beaglebone Black GPIO question...

[Curtis Paul]

I put a fmt.Println() at the beginning and end of that work function and 
they both print, so it appears they are only running once...then it's no 
longer waiting for input.

-- 
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] Re: Gobot Beaglebone Black GPIO question...

[Curtis Paul]

>
> Not sure
>

It's fairly common demo code that more then a few people have used.
Maybe it's wrong...
 

> https://godoc.org/gobot.io/x/gobot/drivers/gpio#ButtonDriver
>

 

-- 
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] Re: Gobot Beaglebone Black GPIO question...

[silviucapota]

Hmm... I actually looked at that .On method. It does in fact call 
Subscribe(),  then spawns a go routine. Strange, so maybe it is a device 
specific issue.

Maybe try to move those .On handlers before the work := func() block, just 
in case...

On Monday, 12 February 2018 00:41:58 UTC-5, Silviu Capota Mera wrote:
>
> Hi Curtis,
>
> I used to play a bit with a Beaglebone Black a few years ago, but it's now 
> gathering dust at my father's place. I really liked it at the time.
>
> Can you double check that you are correctly using your *work := func() 
> ...* construct ?
>
> Here's what that documentation of the gobot.NewRobot initializer says at: 
> https://github.com/hybridgroup/gobot/blob/master/robot.go#L104
> "func(): The work routine the robot will execute once all devices and 
> connections have been initialized and started"
>
> Could it be that your two *"button.On(...)"* handlers are actually only 
> executed once, then they are lost for ever ?
>
> Maybe you can try using the Subscribe method ? 
> https://github.com/hybridgroup/gobot/blob/master/eventer.go#L108
>
> e,g, *myEventsChan := button.Subscribe()*  (just before the *work := 
> func()* block , then launch a go routing with that channel as a parameter 
> ? )
>
> Just a thought
>
> Cheers,
> Silviu
>
>
> On Sunday, 11 February 2018 23:21:57 UTC-5, Curtis Paul wrote:
>>
>> Anybody out there have any experience with BeagleBone Black and gobot?
>> I need some advice on how I could go about troubleshooting this...or if 
>> you know what the issue is, etc...
>>
>> I have a very simple Gobot/GPIO Button circuit.  
>> It should show output when button is pushed and then again when released, 
>> but it doesn't do anything.
>> It's not working.
>>
>> Running image BBB-blank-debian-9.3-iot-armhf-2018-02-04-4gb.img.xz.  (I 
>> also tried the version posted on the BeagleBone site)
>> Modified /boot/uEnv.txt according to instructions at 
>> https://gobot.io/documentation/platforms/beaglebone.
>>
>> I can see all the gpio's in /sys/class/gpio.
>>
>> I'm using gpio67, so I cat the value file and see 0 when button is not 
>> pushed, then see 1 when button is pushed.  I know my circuit is good.
>>
>> This is my gobot code for interacting with the button:
>> FYI...P8_8 is gpio67
>>
>> package main
>>
>> import (
>> "fmt"
>>
>> "gobot.io/x/gobot"
>> "gobot.io/x/gobot/drivers/gpio"
>> "gobot.io/x/gobot/platforms/beaglebone"
>> )
>>
>> func main() {
>> beagleboneAdaptor := beaglebone.NewAdaptor()
>> button := gpio.NewButtonDriver(beagleboneAdaptor, "P8_8")
>>
>> work := func() {
>> button.On(gpio.ButtonPush, func(data interface{}) {
>> fmt.Println("button pressed")
>> })
>>
>> button.On(gpio.ButtonRelease, func(data interface{}) {
>> fmt.Println("button released")
>> })
>> }
>>
>> robot := gobot.NewRobot("buttonBot",
>> []gobot.Connection{beagleboneAdaptor},
>> []gobot.Device{button},
>> work,
>> )
>>
>> robot.Start()
>> }
>>
>>
>> This is what it looks like when the code runs.  No errors, etc...
>> Push the button and don't get any of the Println's.
>>
>> 2018/02/12 04:14:03 Initializing connections...
>> 2018/02/12 04:14:03 Initializing connection BeagleboneBlack-65FB3BAE ...
>> 2018/02/12 04:14:03 Initializing devices...
>> 2018/02/12 04:14:03 Initializing device Button-51E1127C ...
>> 2018/02/12 04:14:03 Robot buttonBot initialized.
>> 2018/02/12 04:14:03 Starting Robot buttonBot ...
>> 2018/02/12 04:14:03 Starting connections...
>> 2018/02/12 04:14:03 Starting connection BeagleboneBlack-65FB3BAE...
>> 2018/02/12 04:14:03 Starting devices...
>> 2018/02/12 04:14:03 Starting device Button-51E1127C on pin P8_8...
>> 2018/02/12 04:14:03 Starting work...
>>
>> I should be seeing "button pressed" when I press the P8_8 buttonbut I 
>> don't see anything.
>>
>>

-- 
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] Re: Gobot Beaglebone Black GPIO question...

[silviucapota]

Hi Curtis,

I used to play a bit with a Beaglebone Black a few years ago, but it's now 
gathering dust at my father's place. I really liked it at the time.

Can you double check that you are correctly using your *work := func() ...* 
construct ?

Here's what that documentation of the gobot.NewRobot initializer says 
at: https://github.com/hybridgroup/gobot/blob/master/robot.go#L104
"func(): The work routine the robot will execute once all devices and 
connections have been initialized and started"

Could it be that your two *"button.On(...)"* handlers are actually only 
executed once, then they are lost for ever ?

Maybe you can try using the Subscribe method 
? https://github.com/hybridgroup/gobot/blob/master/eventer.go#L108

e,g, *myEventsChan := button.Subscribe()*  (just before the *work := func()* 
block , then launch a go routing with that channel as a parameter ? )

Just a thought

Cheers,
Silviu


On Sunday, 11 February 2018 23:21:57 UTC-5, Curtis Paul wrote:
>
> Anybody out there have any experience with BeagleBone Black and gobot?
> I need some advice on how I could go about troubleshooting this...or if 
> you know what the issue is, etc...
>
> I have a very simple Gobot/GPIO Button circuit.  
> It should show output when button is pushed and then again when released, 
> but it doesn't do anything.
> It's not working.
>
> Running image BBB-blank-debian-9.3-iot-armhf-2018-02-04-4gb.img.xz.  (I 
> also tried the version posted on the BeagleBone site)
> Modified /boot/uEnv.txt according to instructions at 
> https://gobot.io/documentation/platforms/beaglebone.
>
> I can see all the gpio's in /sys/class/gpio.
>
> I'm using gpio67, so I cat the value file and see 0 when button is not 
> pushed, then see 1 when button is pushed.  I know my circuit is good.
>
> This is my gobot code for interacting with the button:
> FYI...P8_8 is gpio67
>
> package main
>
> import (
> "fmt"
>
> "gobot.io/x/gobot"
> "gobot.io/x/gobot/drivers/gpio"
> "gobot.io/x/gobot/platforms/beaglebone"
> )
>
> func main() {
> beagleboneAdaptor := beaglebone.NewAdaptor()
> button := gpio.NewButtonDriver(beagleboneAdaptor, "P8_8")
>
> work := func() {
> button.On(gpio.ButtonPush, func(data interface{}) {
> fmt.Println("button pressed")
> })
>
> button.On(gpio.ButtonRelease, func(data interface{}) {
> fmt.Println("button released")
> })
> }
>
> robot := gobot.NewRobot("buttonBot",
> []gobot.Connection{beagleboneAdaptor},
> []gobot.Device{button},
> work,
> )
>
> robot.Start()
> }
>
>
> This is what it looks like when the code runs.  No errors, etc...
> Push the button and don't get any of the Println's.
>
> 2018/02/12 04:14:03 Initializing connections...
> 2018/02/12 04:14:03 Initializing connection BeagleboneBlack-65FB3BAE ...
> 2018/02/12 04:14:03 Initializing devices...
> 2018/02/12 04:14:03 Initializing device Button-51E1127C ...
> 2018/02/12 04:14:03 Robot buttonBot initialized.
> 2018/02/12 04:14:03 Starting Robot buttonBot ...
> 2018/02/12 04:14:03 Starting connections...
> 2018/02/12 04:14:03 Starting connection BeagleboneBlack-65FB3BAE...
> 2018/02/12 04:14:03 Starting devices...
> 2018/02/12 04:14:03 Starting device Button-51E1127C on pin P8_8...
> 2018/02/12 04:14:03 Starting work...
>
> I should be seeing "button pressed" when I press the P8_8 buttonbut I 
> don't see anything.
>
>

-- 
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] Cross-compiling error for runtime package in go1.9.4 (works in go1.9.2)

[Ian Lance Taylor]

On Sun, Feb 11, 2018 at 1:00 PM,   wrote:
>
> I'm building a package that depends on Go's runtime package. Using the
> following compilation flags:
>
> CGO_ENABLED=0 GOOS=freebsd GOARCH=amd64
>
> I get a successful compilation using go1.9.2. After updating to go1.9.4, I
> get the following error and compilation stops:
>
> # runtime
> cgo.go:9:3: //go:cgo_export_static main only allowed in cgo-generated code
>
> I'm running on Linux/amd64. Anybody else hitting this error?

I can't recreate this problem.  Do you have GOROOT set in the environment?

Ian

-- 
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] Re: Cross-compiling error for runtime package in go1.9.4 (works in go1.9.2)

[Curtis Paul]

Did you try with CGO_ENABLED=1

Also, maybe CC= needs a valuelike gcc.

-- 
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] Re: Cross-compiling error for runtime package in go1.9.4 (works in go1.9.2)

[Curtis Paul]

Did you try with CGO_ENABLED=1

Also, maybe CC= needs a valuelike gcc.

On Sunday, February 11, 2018 at 9:45:31 PM UTC-7, Matt R. wrote:
>
> I'm building a package that depends on Go's runtime package. Using the 
> following compilation flags:
>
> CGO_ENABLED=0 GOOS=freebsd GOARCH=amd64
>
> I get a successful compilation using go1.9.2. After updating to go1.9.4, I 
> get the following error and compilation stops:
>
> # runtime
> cgo.go:9:3: //go:cgo_export_static main only allowed in cgo-generated code
>
> I'm running on Linux/amd64. Anybody else hitting this error?
>

-- 
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] Cross-compiling error for runtime package in go1.9.4 (works in go1.9.2)

[matthew5384]

I'm building a package that depends on Go's runtime package. Using the 
following compilation flags:

CGO_ENABLED=0 GOOS=freebsd GOARCH=amd64

I get a successful compilation using go1.9.2. After updating to go1.9.4, I 
get the following error and compilation stops:

# runtime
cgo.go:9:3: //go:cgo_export_static main only allowed in cgo-generated code

I'm running on Linux/amd64. Anybody else hitting this error?

-- 
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] Looking for an expert GO Developer for Unity Technologies

[Adrian Brown]

Hi all
I am looking for a Senior Backend Developer (Golang Expert) for our amazing 
Unity Studio down in the New Forest (Nr Southampton, UK).  The guys there 
are involved in flexible multiplayer hosting solutions for AAA Video Games. 
 This is a priority role for Unity Technologies and benefits include 
relocation, private health, private dental, pension and Unity Stock 
Options.  To take a look at the job description visit our careers site 
here. https://careers.unity.com/position/backend-developer/960799.  any 
questions my email address is adri...@unity3d.com 

-- 
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] Gobot Beaglebone Black GPIO question...

[Curtis Paul]

Anybody out there have any experience with BeagleBone Black and gobot?
I need some advice on how I could go about troubleshooting this...or if you 
know what the issue is, etc...

I have a very simple Gobot/GPIO Button circuit.  
It should show output when button is pushed and then again when released, 
but it doesn't do anything.
It's not working.

Running image BBB-blank-debian-9.3-iot-armhf-2018-02-04-4gb.img.xz.  (I 
also tried the version posted on the BeagleBone site)
Modified /boot/uEnv.txt according to instructions at 
https://gobot.io/documentation/platforms/beaglebone.

I can see all the gpio's in /sys/class/gpio.

I'm using gpio67, so I cat the value file and see 0 when button is not 
pushed, then see 1 when button is pushed.  I know my circuit is good.

This is my gobot code for interacting with the button:
FYI...P8_8 is gpio67

package main

import (
"fmt"

"gobot.io/x/gobot"
"gobot.io/x/gobot/drivers/gpio"
"gobot.io/x/gobot/platforms/beaglebone"
)

func main() {
beagleboneAdaptor := beaglebone.NewAdaptor()
button := gpio.NewButtonDriver(beagleboneAdaptor, "P8_8")

work := func() {
button.On(gpio.ButtonPush, func(data interface{}) {
fmt.Println("button pressed")
})

button.On(gpio.ButtonRelease, func(data interface{}) {
fmt.Println("button released")
})
}

robot := gobot.NewRobot("buttonBot",
[]gobot.Connection{beagleboneAdaptor},
[]gobot.Device{button},
work,
)

robot.Start()
}


This is what it looks like when the code runs.  No errors, etc...
Push the button and don't get any of the Println's.

2018/02/12 04:14:03 Initializing connections...
2018/02/12 04:14:03 Initializing connection BeagleboneBlack-65FB3BAE ...
2018/02/12 04:14:03 Initializing devices...
2018/02/12 04:14:03 Initializing device Button-51E1127C ...
2018/02/12 04:14:03 Robot buttonBot initialized.
2018/02/12 04:14:03 Starting Robot buttonBot ...
2018/02/12 04:14:03 Starting connections...
2018/02/12 04:14:03 Starting connection BeagleboneBlack-65FB3BAE...
2018/02/12 04:14:03 Starting devices...
2018/02/12 04:14:03 Starting device Button-51E1127C on pin P8_8...
2018/02/12 04:14:03 Starting work...

I should be seeing "button pressed" when I press the P8_8 buttonbut I 
don't see anything.

-- 
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] Wrapping executable that takes input and output files such that it uses stdin and stdout instead (using named pipes)

[Or Rikon]

That's a really nice trick. Thanks for sharing.

On Sunday, February 11, 2018 at 3:48:09 AM UTC-5, Michael Houston wrote:
>
> If you're using Bash or some other unix-y shell which supports it, you can 
> produce the same effect with built-in syntax:
>
> https://unix.stackexchange.com/a/64011
>
> In Bash, you can use the command1 <( command0 ) redirection syntax, which 
>> redirects command0's stdout and passes it to a command1 that takes a 
>> filename as a command-line argument. This is called *process 
>> substitution* .
>>
>
> Mike.
>  
>
> On Saturday, February 10, 2018 at 12:57:52 PM UTC, Or Rikon wrote:
>>
>> I actually fixed this a couple of days ago (see here 
>> ) without realizing what the 
>> issue was, but now I understand! Thank you!
>>
>> On Fri, Feb 9, 2018 at 10:27 PM Matt Harden  wrote:
>>
>>> You need to close fIn after the copy is done. As it is now, fIn.Close() 
>>> happens after io.Copy(os.Stdout, buf), which completes after your cat 
>>> command finishes. But cat won't finish until its input pipe returns EOF, 
>>> which happens after fIn.Close().
>>>
>>> On Wed, Feb 7, 2018 at 5:46 PM Or Rikon  wrote:
>>>
 Hi!

 I asked this previously on Stack Overflow but so far have not received 
 a response, so I figured I will try here as well.

 I'm trying to wrap an executable that takes an input and output file 
 paths as arguments, such that it will be possible to provide the input and 
 output as stdin and stdout.

 I've written a short script in Go that attempts to do this, but for 
 some reason which eludes me, it hangs forever.


 Here is the script:


 package main
 import (
 "bytes"
 "io"
 "log"
 "os"
 "strings"
 "syscall"

 "golang.org/x/sync/errgroup")
 /*
 Expected behavior:

 # Terminal 1
 $ go run main.go

 # Terminal 2
 $ cat inPipe > outPipe

 The go program is writing to inPipe and reading from outPipe

 Actual behavior: The program stalls
 */

 func main() {
 eg := {}

 inPipe := "inPipe"
 outPipe := "outPipe"

 if err := syscall.Mkfifo(inPipe, 0644); err != nil {
 log.Fatal(err)
 }
 defer os.Remove(inPipe)

 if err := syscall.Mkfifo(outPipe, 0644); err != nil {
 log.Fatal(err)
 }
 defer os.Remove(outPipe)

 fIn, err := os.OpenFile(inPipe, os.O_WRONLY, os.ModeNamedPipe)
 if err != nil {
 log.Fatal(err)
 }
 defer fIn.Close()

 eg.Go(func() error {
 _, err := io.Copy(fIn, strings.NewReader("123"))
 return err
 })

 fOut, err := os.OpenFile(outPipe, os.O_RDONLY, os.ModeNamedPipe)
 if err != nil {
 log.Fatal(err)
 }
 defer fOut.Close()

 buf := {}

 eg.Go(func() error {
 _, err := io.Copy(buf, fOut)
 return err
 })

 if err := eg.Wait(); err != nil {
 log.Fatal(err)
 }

 if _, err := io.Copy(os.Stdout, buf); err != nil {
 log.Fatal(err)
 }}

 -- 
 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...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>

-- 
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] type definitions and original types

[rajesh nataraja]

Thank you. That’s what I was looking for, I didn’t know it was added in 1.9.

Will checkout on 1.9.

Thanks
Rajesh

Sent from my iPhone

> On Feb 11, 2018, at 10:14 AM, Ian Lance Taylor  wrote:
> 
>> On Sun, Feb 11, 2018 at 7:52 AM, rajesh nataraja  wrote:
>> 
>> Yes I understand the strict type checking. But in the absence of macros, the
>> code becomes extremely awkward and sometimes  the simplicity that we beg for
>> gets undermined.
>> My intention trying to do this was two things:
>> 1. Reduce my line length in the code
>> 2. Avoid making changes to all parts of the code as I needed to use the same
>> type in a different package. I could not make package inclusions without
>> circular dependency.
>> 
>> A dynamic check by compiler to see if the type has been really modified
>> would be great. Like a pre processor check to simply replace the definitions
>> with original names could do this?
>> 
>> Any other way to achieve what I need?
> 
> I don't know what you need, but Go permits explicit type conversions.
> 
>x.b = T1(y)
> 
> It also permits type aliases.
> 
>type newt2 = a.T2
> 
> Ian

-- 
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] type definitions and original types

[Ian Lance Taylor]

On Sun, Feb 11, 2018 at 7:52 AM, rajesh nataraja  wrote:
>
> Yes I understand the strict type checking. But in the absence of macros, the
> code becomes extremely awkward and sometimes  the simplicity that we beg for
> gets undermined.
> My intention trying to do this was two things:
> 1. Reduce my line length in the code
> 2. Avoid making changes to all parts of the code as I needed to use the same
> type in a different package. I could not make package inclusions without
> circular dependency.
>
> A dynamic check by compiler to see if the type has been really modified
> would be great. Like a pre processor check to simply replace the definitions
> with original names could do this?
>
> Any other way to achieve what I need?

I don't know what you need, but Go permits explicit type conversions.

x.b = T1(y)

It also permits type aliases.

type newt2 = a.T2

Ian

-- 
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] type definitions and original types

['Axel Wagner' via golang-nuts]

On Sun, Feb 11, 2018 at 4:52 PM, rajesh nataraja 
wrote:

> Yes I understand the strict type checking. But in the absence of macros,
> the code becomes extremely awkward and sometimes  the simplicity that we
> beg for gets undermined.
> My intention trying to do this was two things:
> 1. Reduce my line length in the code
> 2. Avoid making changes to all parts of the code as I needed to use the
> same type in a different package. I could not make package inclusions
> without circular dependency.
>

> A dynamic check by compiler to see if the type has been really modified
> would be great. Like a pre processor check to simply replace the
> definitions with original names could do this?
>
> Any other way to achieve what I need?
>

I really don't understand what you *are* trying to achieve. You have only
posted example code and from that, all I understand is that you are trying
to declare two different types but treat them as if they're the same. If
they are the same type, don't declare it twice. If they are not the same
type, it doesn't make any sense to treat them as if they were. It would
probably help, if you could explain a bit what you are actually trying to
do, because there is probably a better way to deal with this.

FWIW, there is one way that you can circumvent the type safety of Go and
that is by using unsafe. But it is very likely not what you actually should
be doing.


>
> Thanks
> Rajesh
>
> Sent from my iPhone
>
> On Feb 10, 2018, at 10:57 PM, Axel Wagner 
> wrote:
>
> On Sun, Feb 11, 2018 at 7:27 AM, rajesh nataraja 
> wrote:
>
>> Compiler does not allow this, aren't they essentially all the same? What
>> is the reason this is not allowed?
>>
>
> Go is strictly typed. As such, it limits conversions (much more automatic
> ones) between types that are not the same.
> Types are characterized by two things: The data they hold and the
> operations you can do on them. The latter is, what you usually declare new
> types for. So, for examples, if I do
>
> type F struct{
> *bytes.Buffer
> }
>
> then an F is basically the same as a *bytes.Buffer - they have the same
> representation in memory. But I can then do
>
> func (f F) Write(p []byte) (n int, err error) {
> n, err = f.Buffer.Write(p)
> if err != nil {
> log.Printf("Error writing to buffer: %v", err)
> }
> return n, err
> }
>
> thus modifying the behavior of the type.
>
> Different type-declarations usually imply different operations on the same
> underlying data. In your case, it only makes sense to declare both T1 and
> T2, if they are supposed to do different things, even if they have the same
> structure. Different method-sets will usually use and enforce different
> invariants, so there are usually severe problems with intermixing them.
>
> So if what you want would be allowed - transparently converting between
> values with the same representation - that would essentially negate most of
> the point of the type-checker. By declaring two types you are explicitly
> stating, that you want them to be treated as different and Go's strict
> typing makes sure that you do.
>
>
>> Thanks
>> Rajesh.
>>
>> --
>> 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.
>>
>
>

-- 
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.