Re: [go-nuts] liteide x30 released

[Adrian Sampaleanu]

Nice! Would you be able to provide QT5 binaries along with QT4, the way you 
do for OS X?

On Monday, July 4, 2016 at 7:52:55 AM UTC-4, parais...@gmail.com wrote:
>
> Great news, I love liteide which is for me the best Go IDE, no question. I 
> love the embedded Go Playground too, quite handy when it comes to try new 
> stuff in Go.
>
> Le lundi 4 juillet 2016 03:52:29 UTC+2, visualfc a écrit :
>>
>> Hi, all
>> liteide x30 released!
>> This version bug fix, support go1.7, add fakevim mode (thanks jsuppe 
>> https://github.com/jsuppe) , add quick open files (ctrl+p) and quick 
>> open editor (ctrl+alt+p) actions.
>>
>> LiteIDE Source code : https://github.com/visualfc/liteide
>> Gotools Source code : https://github.com/visualfc/gotools
>> Binary downloads : http://sourceforge.net/projects/liteide/files
>> Latest downloads : http://git.oschina.net/visualfc/liteide/attach_files
>>
>> ### 2016.7.2 Ver X30
>> * LiteIDE
>> * add new QuickOpen plugin
>> * add new FakeVim plugin, thanks for [jsuppe](
>> https://github.com/jsuppe)
>> * add custom env 
>> LITEIDE_TOOL_PATH/LITEIDE_PLUGIN_PATH/LITEIDE_RES_PATH
>> * LiteApp
>> * action tooltip shortcut show native text
>> * option keyboard map show native text
>> * QuickOpen
>> * quick open files action CTRL+P
>> * quick open editor action CTRL+ALT+P
>> * quick go to line action CTRL+L
>> * quick open help
>> * FakeVim
>> * editor add vim style mode editing
>> * LiteEditor
>> * add goto line start/end action
>> * add goto doc start/end action
>> * add goto previous/next line action
>> * add goto previous/next charater action
>> * add goto previous/next word action
>> * change '' braces only go source
>> * fix codecompleter number first
>> * MacOS fix move line up/down shortcut command+shift+up/down
>> * GolangEdit
>> * CTRL+mouse navigate preview source info
>> * LiteFind
>> * MacOS fix edit replace shortcut command+shift+F
>> * Welcome
>> * fix doc css style
>> * gotools
>> * types fix limit parser
>> * types simple field info
>>  
>>
>

-- 
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] Compiling very old version of Golang...

[Mike Lee]

Hello,

For this question please refer to commit 
0cafb9ea3d3d34627e8f492ccafa6ba9b633a213 of the Go repository.

This is a very early version of Go (2008).  I was just curious as to how it 
looked at the start. I don't have any experience in compilers/language 
design, can someone tell me how they executed this code? How did they run 
the Go code? No Makefile?

thanks :)

-- 
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] strings.SplitN(x, 1)

[Matt Harden]

Not quite always: https://play.golang.org/p/XEM4afSu57

On Mon, Jul 4, 2016 at 12:37 PM Tom Limoncelli  wrote:

> Does strings.SplitN(x, 1) always return []string{x}?
>
> https://play.golang.org/p/3vDg_BFfY9
>
> If so, I think the docs would be more clear if this was spelled out.
> For example...
>
> *** strings.go-OLD Mon Jul  4 15:33:24 2016
> --- strings.go Mon Jul  4 15:34:48 2016
> ***
> *** 266,271 
> --- 266,272 
>   // The count determines the number of substrings to return:
>   //   n > 0: at most n substrings; the last substring will be the
> unsplit remainder.
>   //   n == 0: the result is nil (zero substrings)
> + //   n == 1: the result is a list with one item (the value s)
>   //   n < 0: all substrings
>   func SplitN(s, sep string, n int) []string { return genSplit(s, sep, 0,
> n) }
>
> Tom
> --
> Email: t...@whatexit.orgWork: tlimonce...@stackoverflow.com
> Blog:  http://EverythingSysadmin.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.
>

-- 
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] strings.SplitN(x, 1)

[Tom Limoncelli]

Does strings.SplitN(x, 1) always return []string{x}?

https://play.golang.org/p/3vDg_BFfY9

If so, I think the docs would be more clear if this was spelled out.
For example...

*** strings.go-OLD Mon Jul  4 15:33:24 2016
--- strings.go Mon Jul  4 15:34:48 2016
***
*** 266,271 
--- 266,272 
  // The count determines the number of substrings to return:
  //   n > 0: at most n substrings; the last substring will be the
unsplit remainder.
  //   n == 0: the result is nil (zero substrings)
+ //   n == 1: the result is a list with one item (the value s)
  //   n < 0: all substrings
  func SplitN(s, sep string, n int) []string { return genSplit(s, sep, 0, n) }

Tom
-- 
Email: t...@whatexit.orgWork: tlimonce...@stackoverflow.com
Blog:  http://EverythingSysadmin.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.

Re: [go-nuts] Re: Golang Rabbit MQ Fanout Exchange Multiple Consumers

[Ross Salas]

This may help:
http://activemq.apache.org/how-does-a-queue-compare-to-a-topic.html


On Mon, Jul 4, 2016 at 8:22 AM, Giang Tran  wrote:

> it's because you use single queue for both of consumer, in fanout
> exchange, message is copy to all the queue bind to this exchange.
> Inorder to has 2 copy, you must have to use 2 queue(use different queue
> name).
>
>
> On Monday, July 4, 2016 at 10:09:03 PM UTC+7, Rakesh Goyal wrote:
>>
>>
>>
>> down votefavorite
>> 
>>
>> I am publishing messages in fanout exchange from Java application. I am
>> able to receive message in multiple consumer in Java. I have 2 consumers in
>> golang app but only one of the consumer (alternatively ) is receiving the
>> message (Not both of them for a published message).
>>
>> func HandleMessageFanout1(){
>>
>> conn := system.EltropyAppContext.RabbitMQConn
>>
>> channel, err := conn.Channel()
>>
>> if(err!=nil){
>> log.Println(err)
>> }
>> //forever := make(chan bool)
>>
>>
>>
>> deliveries,err := channel.Consume(
>> "example.queue", //queue
>> "qw",
>> true,
>> false,
>> false,
>> false,
>> nil)
>>
>> if(err!=nil){
>> log.Println(err)
>> }
>>
>> go func() {
>>
>> for d := range deliveries {
>> log.Printf("Message recived in fanout 1")
>> log.Printf("Received a message: %s", d.Body)
>> }
>> }()
>>
>> //<-forever
>>
>> }
>>
>> //2nd Consumer
>>
>> package consumer
>>
>> import (
>> "github.com/eltropy/shehnai/backend/golang/common-packages/system"
>> log "github.com/Sirupsen/logrus"
>> )
>>
>> func HandleMessageFanout2() {
>>
>> conn := system.EltropyAppContext.RabbitMQConn
>>
>> channel, err := conn.Channel()
>>
>> if (err!=nil) {
>> log.Println(err)
>> }
>>
>> //forever := make(chan bool)
>>
>> deliveries, err := channel.Consume(
>> "example.queue", //queue
>> "q2",
>> true,
>> false,
>> false,
>> false,
>> nil)
>>
>> if (err!=nil) {
>> log.Println(err)
>> }
>>
>> go func() {
>> for d := range deliveries {
>> log.Printf("Message recived in fanout 2")
>> log.Printf("Received a message: %s", d.Body)
>> }
>> }()
>>
>> //<-forever
>>
>> }
>>
>> I am using https://github.com/streadway/amqp library for rabbit mq.
>>
> --
> 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.

Re: [go-nuts] Unsure when two interfaces are considered identical

[Jon Bodner]

Ah, ok. I think I understand what you're saying. In my opinion, there's a 
difference between automatically type casting between a concrete type and 
an interface (or from one concrete type to another) and automatically 
casting between two compatible (or identical) interfaces. 

Not automatically converting anything involving a concrete type makes sense 
to me. But not automatically recognizing that two interfaces that implement 
the same methods are the same in some situations but not in others strikes 
me as a surprising limitation on implicit interfaces.

Thanks,

Jon

On Monday, July 4, 2016 at 11:24:18 AM UTC-4, Constantin Konstantinidis 
wrote:
>
> I understand your concern. What I like a lot in Go is the strong type side 
> that requires strict structure including naming.
> I'm only pointing that if the compiler cannot "type" a result, it should 
> always mention it.
>
> Regards,
>
> On Monday, July 4, 2016 at 5:16:57 PM UTC+2, Jon Bodner wrote:
>>
>> Hi Constantin,
>>
>> Thanks for responding.
>>
>> This is a case where I think the compiler should be perfectly capable of 
>> figuring out that ResultA and ResultB are identical, and allowing one to be 
>> substituted for the other. As the adapter shows, the compiler can figure 
>> this out when it's a return type, but can't figure it out when you want to 
>> match if a type implements a particular interface. That feels inconsistent 
>> to me, especially since it can be solved with a trivial adapter that 
>> doesn't even have to cast to work. 
>>
>> Ian pointed out that there was an issue recently created that addressed 
>> this. I'm hoping that it can make it into Go 1.8 and I'm interested in 
>> finding out what I can do to help that happen.
>>
>> Jon
>>
>> On Monday, July 4, 2016 at 10:54:03 AM UTC-4, Constantin Konstantinidis 
>> wrote:
>>>
>>> It seems to me that the compiling error is adequate guidance.
>>> fmt.Printf("%v %T",V.Calculate(2,8)) displays 10 %!T(MISSING)
>>> ie Calculate returns a untyped value.
>>> If you try to set the type by using the standard interface of type 
>>> CalcB fmt.Println(ib.Calculate(CalcB(i)).Result()) then the compiling error 
>>> is
>>>
>>> prog.go:40: cannot convert i (type int) to type CalcB:
>>> int does not implement CalcB (missing Calculate method)
>>> prog.go:40: cannot use CalcB(i) (type CalcB) as type int in argument to 
>>> ib.Calculate
>>>
>>>
>>> which confirms that Calculate method typed as ResultA fails probably 
>>> because the compiler considers unclear what should be achieved.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Monday, July 4, 2016 at 5:29:32 AM UTC+2, Ian Lance Taylor wrote:

 On Sun, Jul 3, 2016 at 12:27 PM, Jon Bodner  
 wrote: 
 > 
 > I'm working on a DAO adapter layer helper called Proteus 
 > (https://github.com/jonbodner/proteus), and ran into an interesting 
 quirk in 
 > what Go considers equivalent interfaces. I recreated a simplified 
 version of 
 > the issue is at https://play.golang.org/p/BS3-bUKtO9 . 
 > 
 > The code that I linked does not compile, with the error: 
 > 
 > V does not implement CalcB (wrong type for Calculate method) 
 > have Calculate(int) ResultA 
 > want Calculate(int) ResultB 
 > 
 > 
 > ResultA and ResultB are identical interfaces; both define a single 
 method 
 > Result that takes in no parameters and return an int. 
 > 
 > However, if I put in a wrapper around V, I can get it to work: 
 > https://play.golang.org/p/XUoZwsBaFn 
 > 
 > What I don't understand is that the wrapper doesn't do any casting of 
 > ResultA to ResultB, and that's OK in this situation. But the Go 
 compiler 
 > can't figure out that ResultA and ResultB are identical without that 
 > wrapper. Why is that? Why does the compiler fail the first case and 
 pass the 
 > second one? 

 ResultA and ResultB are assignable but not identical. 

 https://golang.org/ref/spec#Type_identity 
 https://golang.org/ref/spec#Assignability 

 For the specific case of interface types, you may be interested in 
 https://golang.org/issue/16209 . 

 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] Unsure when two interfaces are considered identical

[Constantin Konstantinidis]

I understand your concern. What I like a lot in Go is the strong type side 
that requires strict structure including naming.
I'm only pointing that if the compiler cannot "type" a result, it should 
always mention it.

Regards,

On Monday, July 4, 2016 at 5:16:57 PM UTC+2, Jon Bodner wrote:
>
> Hi Constantin,
>
> Thanks for responding.
>
> This is a case where I think the compiler should be perfectly capable of 
> figuring out that ResultA and ResultB are identical, and allowing one to be 
> substituted for the other. As the adapter shows, the compiler can figure 
> this out when it's a return type, but can't figure it out when you want to 
> match if a type implements a particular interface. That feels inconsistent 
> to me, especially since it can be solved with a trivial adapter that 
> doesn't even have to cast to work. 
>
> Ian pointed out that there was an issue recently created that addressed 
> this. I'm hoping that it can make it into Go 1.8 and I'm interested in 
> finding out what I can do to help that happen.
>
> Jon
>
> On Monday, July 4, 2016 at 10:54:03 AM UTC-4, Constantin Konstantinidis 
> wrote:
>>
>> It seems to me that the compiling error is adequate guidance.
>> fmt.Printf("%v %T",V.Calculate(2,8)) displays 10 %!T(MISSING)
>> ie Calculate returns a untyped value.
>> If you try to set the type by using the standard interface of type 
>> CalcB fmt.Println(ib.Calculate(CalcB(i)).Result()) then the compiling error 
>> is
>>
>> prog.go:40: cannot convert i (type int) to type CalcB:
>>  int does not implement CalcB (missing Calculate method)
>> prog.go:40: cannot use CalcB(i) (type CalcB) as type int in argument to 
>> ib.Calculate
>>
>>
>> which confirms that Calculate method typed as ResultA fails probably because 
>> the compiler considers unclear what should be achieved.
>>
>>
>>
>>
>>
>>
>> On Monday, July 4, 2016 at 5:29:32 AM UTC+2, Ian Lance Taylor wrote:
>>>
>>> On Sun, Jul 3, 2016 at 12:27 PM, Jon Bodner  
>>> wrote: 
>>> > 
>>> > I'm working on a DAO adapter layer helper called Proteus 
>>> > (https://github.com/jonbodner/proteus), and ran into an interesting 
>>> quirk in 
>>> > what Go considers equivalent interfaces. I recreated a simplified 
>>> version of 
>>> > the issue is at https://play.golang.org/p/BS3-bUKtO9 . 
>>> > 
>>> > The code that I linked does not compile, with the error: 
>>> > 
>>> > V does not implement CalcB (wrong type for Calculate method) 
>>> > have Calculate(int) ResultA 
>>> > want Calculate(int) ResultB 
>>> > 
>>> > 
>>> > ResultA and ResultB are identical interfaces; both define a single 
>>> method 
>>> > Result that takes in no parameters and return an int. 
>>> > 
>>> > However, if I put in a wrapper around V, I can get it to work: 
>>> > https://play.golang.org/p/XUoZwsBaFn 
>>> > 
>>> > What I don't understand is that the wrapper doesn't do any casting of 
>>> > ResultA to ResultB, and that's OK in this situation. But the Go 
>>> compiler 
>>> > can't figure out that ResultA and ResultB are identical without that 
>>> > wrapper. Why is that? Why does the compiler fail the first case and 
>>> pass the 
>>> > second one? 
>>>
>>> ResultA and ResultB are assignable but not identical. 
>>>
>>> https://golang.org/ref/spec#Type_identity 
>>> https://golang.org/ref/spec#Assignability 
>>>
>>> For the specific case of interface types, you may be interested in 
>>> https://golang.org/issue/16209 . 
>>>
>>> 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: Golang Rabbit MQ Fanout Exchange Multiple Consumers

[Giang Tran]

it's because you use single queue for both of consumer, in fanout exchange, 
message is copy to all the queue bind to this exchange.
Inorder to has 2 copy, you must have to use 2 queue(use different queue 
name).

On Monday, July 4, 2016 at 10:09:03 PM UTC+7, Rakesh Goyal wrote:
>
>
>
> down votefavorite 
> 
>
> I am publishing messages in fanout exchange from Java application. I am 
> able to receive message in multiple consumer in Java. I have 2 consumers in 
> golang app but only one of the consumer (alternatively ) is receiving the 
> message (Not both of them for a published message).
>
> func HandleMessageFanout1(){
>
> conn := system.EltropyAppContext.RabbitMQConn
>
> channel, err := conn.Channel()
>
> if(err!=nil){
> log.Println(err)
> }
> //forever := make(chan bool)
>
>
>
> deliveries,err := channel.Consume(
> "example.queue", //queue
> "qw",
> true,
> false,
> false,
> false,
> nil)
>
> if(err!=nil){
> log.Println(err)
> }
>
> go func() {
>
> for d := range deliveries {
> log.Printf("Message recived in fanout 1")
> log.Printf("Received a message: %s", d.Body)
> }
> }()
>
> //<-forever
>
> }
>
> //2nd Consumer
>
> package consumer
>
> import (
> "github.com/eltropy/shehnai/backend/golang/common-packages/system"
> log "github.com/Sirupsen/logrus"
> )
>
> func HandleMessageFanout2() {
>
> conn := system.EltropyAppContext.RabbitMQConn
>
> channel, err := conn.Channel()
>
> if (err!=nil) {
> log.Println(err)
> }
>
> //forever := make(chan bool)
>
> deliveries, err := channel.Consume(
> "example.queue", //queue
> "q2",
> true,
> false,
> false,
> false,
> nil)
>
> if (err!=nil) {
> log.Println(err)
> }
>
> go func() {
> for d := range deliveries {
> log.Printf("Message recived in fanout 2")
> log.Printf("Received a message: %s", d.Body)
> }
> }()
>
> //<-forever
>
> }
>
> I am using https://github.com/streadway/amqp library for rabbit mq.
>

-- 
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] Unsure when two interfaces are considered identical

[Ian Lance Taylor]

On Mon, Jul 4, 2016 at 8:11 AM, Jon Bodner  wrote:
>
> The issue you pointed at is exactly what I'd like to see.
>
> In my case, I'm providing an interface that matches what's in database/sql
> without creating an explicit dependency on database/sql (for cases when
> non-sql databases, or non-databases are used for data storage). I think this
> is a pretty common pattern in Go, writing code that consumes interfaces
> defined within the same project, even if the methods are identical to those
> on an interface in a third-party package.
>
> What would I need to do to get more consideration for including #16209 in Go
> 1.8?

It's a language change, and any change must be considered very
carefully.  It must also, of course,  be completely backward
compatible.

It would help to understand real use cases.  It would also help to
understand the drawbacks of the proposal.

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] Unsure when two interfaces are considered identical

[Jon Bodner]

Hi Constantin,

Thanks for responding.

This is a case where I think the compiler should be perfectly capable of 
figuring out that ResultA and ResultB are identical, and allowing one to be 
substituted for the other. As the adapter shows, the compiler can figure 
this out when it's a return type, but can't figure it out when you want to 
match if a type implements a particular interface. That feels inconsistent 
to me, especially since it can be solved with a trivial adapter that 
doesn't even have to cast to work. 

Ian pointed out that there was an issue recently created that addressed 
this. I'm hoping that it can make it into Go 1.8 and I'm interested in 
finding out what I can do to help that happen.

Jon

On Monday, July 4, 2016 at 10:54:03 AM UTC-4, Constantin Konstantinidis 
wrote:
>
> It seems to me that the compiling error is adequate guidance.
> fmt.Printf("%v %T",V.Calculate(2,8)) displays 10 %!T(MISSING)
> ie Calculate returns a untyped value.
> If you try to set the type by using the standard interface of type 
> CalcB fmt.Println(ib.Calculate(CalcB(i)).Result()) then the compiling error 
> is
>
> prog.go:40: cannot convert i (type int) to type CalcB:
>   int does not implement CalcB (missing Calculate method)
> prog.go:40: cannot use CalcB(i) (type CalcB) as type int in argument to 
> ib.Calculate
>
>
> which confirms that Calculate method typed as ResultA fails probably because 
> the compiler considers unclear what should be achieved.
>
>
>
>
>
>
> On Monday, July 4, 2016 at 5:29:32 AM UTC+2, Ian Lance Taylor wrote:
>>
>> On Sun, Jul 3, 2016 at 12:27 PM, Jon Bodner  
>> wrote: 
>> > 
>> > I'm working on a DAO adapter layer helper called Proteus 
>> > (https://github.com/jonbodner/proteus), and ran into an interesting 
>> quirk in 
>> > what Go considers equivalent interfaces. I recreated a simplified 
>> version of 
>> > the issue is at https://play.golang.org/p/BS3-bUKtO9 . 
>> > 
>> > The code that I linked does not compile, with the error: 
>> > 
>> > V does not implement CalcB (wrong type for Calculate method) 
>> > have Calculate(int) ResultA 
>> > want Calculate(int) ResultB 
>> > 
>> > 
>> > ResultA and ResultB are identical interfaces; both define a single 
>> method 
>> > Result that takes in no parameters and return an int. 
>> > 
>> > However, if I put in a wrapper around V, I can get it to work: 
>> > https://play.golang.org/p/XUoZwsBaFn 
>> > 
>> > What I don't understand is that the wrapper doesn't do any casting of 
>> > ResultA to ResultB, and that's OK in this situation. But the Go 
>> compiler 
>> > can't figure out that ResultA and ResultB are identical without that 
>> > wrapper. Why is that? Why does the compiler fail the first case and 
>> pass the 
>> > second one? 
>>
>> ResultA and ResultB are assignable but not identical. 
>>
>> https://golang.org/ref/spec#Type_identity 
>> https://golang.org/ref/spec#Assignability 
>>
>> For the specific case of interface types, you may be interested in 
>> https://golang.org/issue/16209 . 
>>
>> 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] function with goroutine returned will kill its goroutine?

[Jan Mercl]

On Mon, Jul 4, 2016 at 5:08 PM Kenshin Wang  wrote:

go func(i int) {
for {
next <- i
i++
}
}(start)

> could anyone can explain why the output is this?

A goroutine dies when it returns. A goroutine with an endless loop is
immortal (modulo unhandled panics).

-- 

-j

-- 
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] Unsure when two interfaces are considered identical

[Jon Bodner]

Hi Ian, 

The issue you pointed at is exactly what I'd like to see. 

In my case, I'm providing an interface that matches what's in database/sql 
without creating an explicit dependency on database/sql (for cases when 
non-sql databases, or non-databases are used for data storage). I think 
this is a pretty common pattern in Go, writing code that consumes 
interfaces defined within the same project, even if the methods are 
identical to those on an interface in a third-party package.

What would I need to do to get more consideration for including #16209 in 
Go 1.8?

Thanks,

Jon

On Sunday, July 3, 2016 at 11:29:32 PM UTC-4, Ian Lance Taylor wrote:
>
> On Sun, Jul 3, 2016 at 12:27 PM, Jon Bodner  > wrote: 
> > 
> > I'm working on a DAO adapter layer helper called Proteus 
> > (https://github.com/jonbodner/proteus), and ran into an interesting 
> quirk in 
> > what Go considers equivalent interfaces. I recreated a simplified 
> version of 
> > the issue is at https://play.golang.org/p/BS3-bUKtO9 . 
> > 
> > The code that I linked does not compile, with the error: 
> > 
> > V does not implement CalcB (wrong type for Calculate method) 
> > have Calculate(int) ResultA 
> > want Calculate(int) ResultB 
> > 
> > 
> > ResultA and ResultB are identical interfaces; both define a single 
> method 
> > Result that takes in no parameters and return an int. 
> > 
> > However, if I put in a wrapper around V, I can get it to work: 
> > https://play.golang.org/p/XUoZwsBaFn 
> > 
> > What I don't understand is that the wrapper doesn't do any casting of 
> > ResultA to ResultB, and that's OK in this situation. But the Go compiler 
> > can't figure out that ResultA and ResultB are identical without that 
> > wrapper. Why is that? Why does the compiler fail the first case and pass 
> the 
> > second one? 
>
> ResultA and ResultB are assignable but not identical. 
>
> https://golang.org/ref/spec#Type_identity 
> https://golang.org/ref/spec#Assignability 
>
> For the specific case of interface types, you may be interested in 
> https://golang.org/issue/16209 . 
>
> 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] Unused var written in closure

[Ian Lance Taylor]

On Sun, Jul 3, 2016 at 11:57 PM, Gordon Klaus  wrote:
> Ok, so strictly speaking there is no bug.  Both gc and gccgo are
> spec-compliant; gc just opts not to raise an error in this case.  (One might
> say it is a bug that gc doesn't raise the error consistently, but I don't
> think the spec says anything about consistency, only optionality.)

I think it is a bug in the gc compiler, and that bug is
https://golang.org/issue/3059 .

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] How does iota affect the types of the subsequent constants in a constant declaration?

[GMA_OWNER via golang-nuts]

Thanks for you confirmation.

-- 
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: How does iota affect the types of the subsequent constants in a constant declaration?

[GMA_OWNER via golang-nuts]

Le lundi 4 juillet 2016 02:25:06 UTC, Jingguo Yao a écrit :
>
> Take the following code as an example:
>
>
> package main
> import (
>   "fmt"
> )
> const (
>   First int64 = iota
>   Second
> )
> const (
>   One int64 = 1
>   Two = 2
> )
> func main() {
>   fmt.Printf("First type: %T, Second type: %T\n", First, Second)
>   fmt.Printf("One type: %T, Two type: %T\n", One, Two)
> }
>
>
> Running the above code produces:
>
>
> First type: int64, Second type: int64
> One type: int64, Two type: int
>
>
> Why is Second's type int64 instead of the default type int like Two? I 
> think
> that it is decided by the following rule from 
> https://golang.org/ref/spec#Constant_declarations. Is my understanding
> correct?
>
>
> > Within a parenthesized const declaration list the expression list
> > may be omitted from any but the first declaration. Such an empty
> > list is equivalent to the textual substitution of the first
> > preceding non-empty expression list and its type if any. Omitting
> > the list of expressions is therefore equivalent to repeating the
> > previous list. The number of identifiers must be equal to the number
> > of expressions in the previous list.
>
>
>

-- 
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: How does iota affect the types of the subsequent constants in a constant declaration?

[GMA_OWNER via golang-nuts]

Le lundi 4 juillet 2016 02:25:06 UTC, Jingguo Yao a écrit :
>
> Take the following code as an example:
>
>
> package main
> import (
>   "fmt"
> )
> const (
>   First int64 = iota
>   Second
> )
> const (
>   One int64 = 1
>   Two = 2
> )
> func main() {
>   fmt.Printf("First type: %T, Second type: %T\n", First, Second)
>   fmt.Printf("One type: %T, Two type: %T\n", One, Two)
> }
>
>
> Running the above code produces:
>
>
> First type: int64, Second type: int64
> One type: int64, Two type: int
>
>
> Why is Second's type int64 instead of the default type int like Two? I 
> think
> that it is decided by the following rule from 
> https://golang.org/ref/spec#Constant_declarations. Is my understanding
> correct?
>
>
> > Within a parenthesized const declaration list the expression list
> > may be omitted from any but the first declaration. Such an empty
> > list is equivalent to the textual substitution of the first
> > preceding non-empty expression list and its type if any. Omitting
> > the list of expressions is therefore equivalent to repeating the
> > previous list. The number of identifiers must be equal to the number
> > of expressions in the previous list.
>
>
>

-- 
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] Golang Rabbit MQ Fanout Exchange Multiple Consumers

[Rakesh Goyal]

down votefavorite 


I am publishing messages in fanout exchange from Java application. I am 
able to receive message in multiple consumer in Java. I have 2 consumers in 
golang app but only one of the consumer (alternatively ) is receiving the 
message (Not both of them for a published message).

func HandleMessageFanout1(){

conn := system.EltropyAppContext.RabbitMQConn

channel, err := conn.Channel()

if(err!=nil){
log.Println(err)
}
//forever := make(chan bool)



deliveries,err := channel.Consume(
"example.queue", //queue
"qw",
true,
false,
false,
false,
nil)

if(err!=nil){
log.Println(err)
}

go func() {

for d := range deliveries {
log.Printf("Message recived in fanout 1")
log.Printf("Received a message: %s", d.Body)
}
}()

//<-forever

}

//2nd Consumer

package consumer

import (
"github.com/eltropy/shehnai/backend/golang/common-packages/system"
log "github.com/Sirupsen/logrus"
)

func HandleMessageFanout2() {

conn := system.EltropyAppContext.RabbitMQConn

channel, err := conn.Channel()

if (err!=nil) {
log.Println(err)
}

//forever := make(chan bool)

deliveries, err := channel.Consume(
"example.queue", //queue
"q2",
true,
false,
false,
false,
nil)

if (err!=nil) {
log.Println(err)
}

go func() {
for d := range deliveries {
log.Printf("Message recived in fanout 2")
log.Printf("Received a message: %s", d.Body)
}
}()

//<-forever

}

I am using https://github.com/streadway/amqp library for rabbit mq.

-- 
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: can't install gomobile

[teja . neotech]

I am also facing the same problem but I didn't understand the solution 
given by @Elias Naur please could you elaborate  on the solution so I can 
get it working.

On Saturday, July 2, 2016 at 8:26:58 AM UTC+5:30, JM wrote:
>
> windows pro on 64x.  Anyone know what's going on here? Im using the 
> following reference. https://github.com/golang/go/wiki/Mobile
>
> C:\WINDOWS\system32>go get golang.org/x/mobile/cmd/gomobile
>
> C:\WINDOWS\system32>gomobile init
> gomobile: rename 
> C:\GoPath\pkg\gomobile\work-399306583\android-ndk-r12\toolchains\llvm\prebuilt\windows-x86_64\bin\clang
>  
> C:\GoPath\pkg\gomobile\android-ndk-r12\llvm\bin\clang: The system cannot 
> find the file specified.
>
> C:\WINDOWS\system32>
>

-- 
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] function with goroutine returned will kill its goroutine?

[Kenshin Wang]

>
>
> package main
>
> import "fmt"
>
> func main() {
> ca := createCounter(2)
> cb := createCounter(102)
> for i := 0; i < 5; i++ {
> a := <-ca
> fmt.Printf("A %d \nB %d \n", a, <-cb)
> }
>
> }
>
> func createCounter(start int) chan int {
> next := make(chan int)
> go func(i int) {
> for {
> next <- i
> i++
> }
> }(start)
> return next
> }
>
>
the output is:
A 2
B 102
A 3
B 103
A 4
B 104
A 5
B 105
A 6
B 106
 
could anyone can explain why the output is this?
especially, i don't understand when the goroutine will be destroyed,i think 
when the createCounter() function returned the goroutine will be killed, 
but it seems not ...
thank you






 

-- 
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] Unsure when two interfaces are considered identical

[Constantin Konstantinidis]

It seems to me that the compiling error is adequate guidance.
fmt.Printf("%v %T",V.Calculate(2,8)) displays 10 %!T(MISSING)
ie Calculate returns a untyped value.
If you try to set the type by using the standard interface of type 
CalcB fmt.Println(ib.Calculate(CalcB(i)).Result()) then the compiling error 
is

prog.go:40: cannot convert i (type int) to type CalcB:
int does not implement CalcB (missing Calculate method)
prog.go:40: cannot use CalcB(i) (type CalcB) as type int in argument to 
ib.Calculate


which confirms that Calculate method typed as ResultA fails probably because 
the compiler considers unclear what should be achieved.






On Monday, July 4, 2016 at 5:29:32 AM UTC+2, Ian Lance Taylor wrote:
>
> On Sun, Jul 3, 2016 at 12:27 PM, Jon Bodner  > wrote: 
> > 
> > I'm working on a DAO adapter layer helper called Proteus 
> > (https://github.com/jonbodner/proteus), and ran into an interesting 
> quirk in 
> > what Go considers equivalent interfaces. I recreated a simplified 
> version of 
> > the issue is at https://play.golang.org/p/BS3-bUKtO9 . 
> > 
> > The code that I linked does not compile, with the error: 
> > 
> > V does not implement CalcB (wrong type for Calculate method) 
> > have Calculate(int) ResultA 
> > want Calculate(int) ResultB 
> > 
> > 
> > ResultA and ResultB are identical interfaces; both define a single 
> method 
> > Result that takes in no parameters and return an int. 
> > 
> > However, if I put in a wrapper around V, I can get it to work: 
> > https://play.golang.org/p/XUoZwsBaFn 
> > 
> > What I don't understand is that the wrapper doesn't do any casting of 
> > ResultA to ResultB, and that's OK in this situation. But the Go compiler 
> > can't figure out that ResultA and ResultB are identical without that 
> > wrapper. Why is that? Why does the compiler fail the first case and pass 
> the 
> > second one? 
>
> ResultA and ResultB are assignable but not identical. 
>
> https://golang.org/ref/spec#Type_identity 
> https://golang.org/ref/spec#Assignability 
>
> For the specific case of interface types, you may be interested in 
> https://golang.org/issue/16209 . 
>
> 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] redirect already running processes stdout

[Konstantin Khomoutov]

On Fri, 1 Jul 2016 13:22:09 -0700 (PDT)
ethanlewis...@gmail.com wrote:

[...]
> I have multiple applications that have a lot of command line flags and
> didn't want to have to worry about executing them threw os.exec.

But this is super-simple to have in fact.
In the simplest case just stick os.Args of your Go program into the
command line you're building with os/exec.Cmd() and then all the
command-line arguments you pass to your Go wrapper will be passed to
the program it will call.

If you want it to be more fancy and have your Go program understand its
own command-line arguments, then first scan os.Args for a special
argument "--", and then use whatever precedes it as a set of
command-line arguments for your Go program through flag.NewFlagSet()
and the FlagSet's Parse() method, which accepts a slice of strings to
parse, and use what follows that special argument "--" as the
command-line arguments for the program to call.  That's a pretty
standard practice to handle such cases.

To reiterate, I think you're trying to approach your problem from the
wrong end.  Messing with ptrace()-ing a running program is kewl, but
real-world programming is not really about kewl solutions but rather
simple and robust ones (and that which could be understood by reading
the code after six months).

[...]

-- 
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] Re: Go-worker or goworker?

[Charl Matthee]

Hi,

On Sat, 2 Jul 2016 at 18:17 pjmul...@gmail.com
 wrote:

I need to make the same decision now. What path did you take?
>
This is a pretty old post of mine. But to answer your question, I ended up
going with *goworker*.

We still use it in production and it has not been the source of any issues
since 2013.

I ended up selecting it because it appeared to be better supported at the
time. A fair amount of time has passed since then and these projects have
moved on so it might be worthwhile doing some tests to solidify your
selection.

Good luck!



​
-- 

--
Ciao

Charl

"People demand freedom of speech as a compensation for the freedom of
thought which they seldom use."
 - Soren Kierkegaard

-- 
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] liteide x30 released

[paraiso . marc]

Great news, I love liteide which is for me the best Go IDE, no question. I 
love the embedded Go Playground too, quite handy when it comes to try new 
stuff in Go.

Le lundi 4 juillet 2016 03:52:29 UTC+2, visualfc a écrit :
>
> Hi, all
> liteide x30 released!
> This version bug fix, support go1.7, add fakevim mode (thanks jsuppe 
> https://github.com/jsuppe) , add quick open files (ctrl+p) and quick open 
> editor (ctrl+alt+p) actions.
>
> LiteIDE Source code : https://github.com/visualfc/liteide
> Gotools Source code : https://github.com/visualfc/gotools
> Binary downloads : http://sourceforge.net/projects/liteide/files
> Latest downloads : http://git.oschina.net/visualfc/liteide/attach_files
>
> ### 2016.7.2 Ver X30
> * LiteIDE
> * add new QuickOpen plugin
> * add new FakeVim plugin, thanks for [jsuppe](
> https://github.com/jsuppe)
> * add custom env LITEIDE_TOOL_PATH/LITEIDE_PLUGIN_PATH/LITEIDE_RES_PATH
> * LiteApp
> * action tooltip shortcut show native text
> * option keyboard map show native text
> * QuickOpen
> * quick open files action CTRL+P
> * quick open editor action CTRL+ALT+P
> * quick go to line action CTRL+L
> * quick open help
> * FakeVim
> * editor add vim style mode editing
> * LiteEditor
> * add goto line start/end action
> * add goto doc start/end action
> * add goto previous/next line action
> * add goto previous/next charater action
> * add goto previous/next word action
> * change '' braces only go source
> * fix codecompleter number first
> * MacOS fix move line up/down shortcut command+shift+up/down
> * GolangEdit
> * CTRL+mouse navigate preview source info
> * LiteFind
> * MacOS fix edit replace shortcut command+shift+F
> * Welcome
> * fix doc css style
> * gotools
> * types fix limit parser
> * types simple field info
>  
>

-- 
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] Re: Append to slice... what happens?

[rog1ue1]

Thank you Martin!

W dniu poniedziałek, 4 lipca 2016 08:11:12 UTC+2 użytkownik Martin Geisler 
napisał:
>
> Hi Rogue, 
>
> On Sun, Jul 3, 2016 at 5:13 PM,  > wrote: 
> > It seems i can't edit my original post so: 
>
> While it may not look like it from if you use the Google Groups 
> interface, emails are being sent out in the background when you post 
> to golang-nuts. So there's no way to edit anything, you can only send 
> follow up messages. 
>
> > There should be "So pointer from slice b is pointing to new array" 
>  instead 
> > of "So pointer from slice b is pointing to new slice" 
>
> Yes, that is correct. 
>
> > W dniu niedziela, 3 lipca 2016 17:05:06 UTC+2 użytkownik 
> rog...@gmail.com 
> > napisał: 
> >> 
> >> Thx Ian, 
> >> 
> >> So basically it's because we allocate new array in version without cap, 
> >> right?  Because it outgrows current cap. So pointer from slice b is 
> pointing 
> >> to new slice (i've checked they have different addresses for first 
> element) 
> >> different from a. 
> >> And in version with cap=10 we still append to the same array as there 
> is 
> >> no relocation, that's why we have same elements in both slices (they 
> point 
> >> to the same array). Right? 
>
> You got it! 
>
> The capacity of the slice tells you how much more room there is beyond 
> the length. If you set the capacity to the length, the next call to 
> append will conclude that there's no space in the underlying array and 
> proceed to allocate a new array, copy the data from the slide to the 
> new array, and return a slice into this new array. This breaks the 
> "link" between the old and new slices since they now refer to 
> different arrays. 
>
> -- 
> Martin Geisler 
>

-- 
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] why is my program retaining memory when len([]byte)>16384 ?

[mhhcbon]

Hi,

thanks for help!


But the problem might just be that you're writing many more bytes to 
> your encoder than you're reading from the file. 
>

Did you mean i should write it so ? Write(srcBuf[0:lenRead])

nrRead, err := src.Read(bufRead); // read from file
if err!= nil {
  break
}
fmt.Printf("read read len: %d\n", nrRead)

nwEnc, err := encoder.Write(bufRead[0:nrRead]) // write to encoder


This means the size of buf2 could be much larger than the original 
> file and also full of junk data from previous reads and zeroed bytes. 
>

One q i have here, is not buf2 supposed to be drained by the following call 
to Read, at least partially

_, err = buf2.Write(r) // write to decoder
fmt.Println(err)
if decoder==nil {
  decoder = flate.NewReader(buf2)
}
r2 := make([]byte, dReadSize*2)
_, err = decoder.Read(r2) // read from decoder // <- here, it should 
remove some data of buf2, no ?
fmt.Println(err)


Besides that, i totally agree this example code is full of wrongness, I 
rewrote it,

package main

import (
  "fmt"
  "os"
  "bytes"
  // "encoding/base64"
  "compress/flate"
  "io"
  "time"
)

func main () {
  // okSize := 16384
  // koSize := 64384
  // koSize := 16385 // yes 1 more and it breaks :s

  // change read size to 16384 and everything is ok
  fReadSize := 16385
  dReadSize := 64384 // dread seems not impacting

  src, _ := os.Open("src.avi")
  bufRead := make([]byte, fReadSize)

  bufEnc := new(bytes.Buffer)
  encoder, _ := flate.NewWriter(bufEnc, 9)

  bufDec := new(bytes.Buffer)
  var decoder io.ReadCloser

  for {

fmt.Println("---")
nrRead, err := src.Read(bufRead); // read from file
if err!= nil {
  break
}
fmt.Printf("read read len: %d\n", nrRead)

nwEnc, err := encoder.Write(bufRead[0:nrRead]) // write to encoder
fmt.Println(err)
fmt.Printf("encode write len: %d\n", nwEnc)
err = encoder.Flush()
fmt.Println(err)
encSlice := bufEnc.Bytes() // read from encoder
// fmt.Println(encSlice[0:20])
fmt.Printf("encode read len: %d\n", len(encSlice))
fmt.Printf("bufEnc len: %d\n", bufEnc.Len())
fmt.Printf("bufEnc cap: %d\n", bufEnc.Cap())

bufEnc.Truncate(0)
// fmt.Println("___")
// fmt.Println(encSlice[0:20])

// fmt.Println(r)
nwDec, err := bufDec.Write(encSlice) // write to decoder
fmt.Println(err)
fmt.Printf("decode write len: %d\n", nwDec)
if decoder==nil {
  decoder = flate.NewReader(bufDec)
}
sliceDec := make([]byte, dReadSize*2)
nrDec, err := decoder.Read(sliceDec) // read from decoder
fmt.Println(err)
fmt.Printf("decode read len: %d\n", nrDec)
fmt.Printf("bufDec len: %d\n", bufDec.Len())
fmt.Printf("bufDec cap: %d\n", bufDec.Cap())

time.Sleep( 1 * time.Second)
  }
}

Which after few iterations will yield

read read len: 16385

encode write len: 16385

encode read len: 15150
bufEnc len: 15150
bufEnc cap: 16320

decode write len: 15150

decode read len: 8
bufDec len: 51234
bufDec cap: 140569

So definitely the decoder is holding on something. Its cap and len are 
irremediably growing.

The thing now is if I try to read it twice time consecutively, 
the second will read will always yield 0 bytes and provide me an 
UnexpectedEOF error.
Does this error leaves the decoder in a unrecoverable state ? I m unsure.

Looks likes i can t drain it :x 


Le lundi 4 juillet 2016 06:17:51 UTC+2, Jesse McNelis a écrit :
>
> On Mon, Jul 4, 2016 at 3:35 AM, mhhcbon  > wrote: 
> > Hi, 
> > 
> > I have this program which reads file, flate encode then flate decode the 
> > data. 
> > 
> > I noticed that when i used different size for the slice of []byte to 
> read 
> > data, the program will retain memory when the size is > 16384. 
> > When its lower than this value everything is fine, but 16385 breaks. 
> > 
> > I don t quite understand the reason of this behavior, can someone help 
> me to 
> > understand what s going on there ? 
>
> I can't see anywhere that this program could be holding on to extra 
> memory it's not using. 
> But the problem might just be that you're writing many more bytes to 
> your encoder than you're reading from the file. 
>
> _, err := src.Read(b); // read from file 
>
> Read() isn't required to fill the whole buffer it's given. It can read 
> a single byte and return. 
> Because you're ignoring the value telling you how many bytes it read 
> you're passing the whole 16385 slice to your encoder even though you 
> might have read much less than 16385 bytes. 
>
> This means the size of buf2 could be much larger than the original 
> file and also full of junk data from previous reads and zeroed bytes. 
>
> Read() is a low level call that you should avoid calling directly 
> because it's tricky to get right. 
>
> For an example of how to properly call a Read() see the implementation 
> of io.Copy() 
> https://golang.org/src/io/io.go?#L366 
>

-- 
You received this message because you are subscribe

[go-nuts] Re: Matrix Library && colour uint32's vs uint8's

[Constantin Konstantinidis]

I noticed that you also use the image/color package. There uint8 are indeed 
mention for Color func. You fill in your matrix using uint8() but the type 
of the image might be lost between your routines as explained 
in https://blog.golang.org/go-image-package as you use src (generic) and 
not typed image.



On Sunday, July 3, 2016 at 6:07:34 PM UTC+2, simran g wrote:
>
> Hi All, 
>
> Could someone please point me to a good matrix library for Go (i'm sure 
> something exists, although i can't seem to find it!). 
>
> Am hoping to do some image manipulation for which being able to work with 
> matrices would be great.  
>
> Have written simple helper stuff for images (i used to find myself doing 
> the same a few time, so just put it in a library) ( 
> https://github.com/simran91/monkeysee ). 
>
> On another note, if you do look at the library above, you'll notice that 
> my source image at (
> https://github.com/simran91/monkeysee/blob/master/samples/rgb.png) and 
> destination image at (
> https://github.com/simran91/monkeysee/blob/master/samples/rgb-png-to-png-mod-SwapRGBtoGBR-autogenerated.png)
>  
> have colours messed up. 
>
> The colours were meant to have swapped, but the Red has gone into being an 
> Pink. 
>
> This i suspect is because when we call colour.RGBA() we get uint32's, but 
> when we set the colour using color.RGBA{r, g, b, a} they r,g,b,a have to be 
> uint8's 
> (File where i have to do the conversion: 
> https://github.com/simran91/monkeysee/blob/master/mimage/rgba-matrix-to-raw-data.go
> )
>
> Has anyone else come across this? I suspect there is a way to load up 
> color.RGBA and give it uint32's? Would appreciate any pointers in that 
> regard as well. 
>
> thanks,
>
> simran.
>

-- 
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] Re: Relaxing rules on slice comparison: would it make sense?

[Chad]

I realize that the issue might be about changing/ adding a builtin:

   - either add a builtin deep value Comparison function (via reflection)
   - or add a snapshot type refinement which triggers the allocation of an 
   immutable copy of a reference type 
   (and we would recover the behaviour of the string implementation which 
   is a special case of []byte snapshot, i.e. a value type*)

I would still expect the behaviour previously mentioned for the "==" 
operator.

(*) I keep using reference/value type terminology but it is indeed slightly 
tricky. But for lack of a better one...

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