from:"martin"

Hi guys,

at first I though I really like the idea of how Go deals with error 
management and handling, but the more Go code I look at or try to program, 
the more I get scared about checking errors every second line in every 
given block of code.

Take a look at this example here from "Build Web Application with Golang":

// insert
stmt, err := db.Prepare("INSERT INTO userinfo(username, departname, created) 
values(?,?,?)")
if err != nil {
  // handle error
}
res, err := stmt.Exec("astaxie", "研发部门", "2012-12-09")
if err != nil {
  // handle error
}
id, err := res.LastInsertId()
if err != nil {
  // handle error
}
fmt.Println(id)
// update
stmt, err = db.Prepare("update userinfo set username=? where uid=?")
if err != nil {
  // handle error
}
res, err = stmt.Exec("astaxieupdate", id)
if err != nil {
  // handle error
}
affect, err := res.RowsAffected()
if err != nil {
  // handle error
}


Seriously? And yes, I have read https://blog.golang.org/errors-are-values...

The best case reduction I found is:

...
res, err = stmt.Exec("astaxieupdate", id)
checkError(err)
...

Still, I need this after each line of calling a function which may return 
an error.

I bet this is not pleasant to do in larger code bases and it also takes 
away focus from what is actually happening.

50-80% of all lines of code in my example deal with error handling?

This is not good. Seriously.

And don't get me wrong, there is a lot of things I really like, love and 
adore about Go, but catching errors needs an improved syntax!

And I am not proposing try...catch here. 

How about introducing a new piece of syntax 

"watch if   " 

which tells the compiler to watch out for changes in a given SimpleStmt

The same code as above would look like this:

var err Error

watch if err != nil {
  // handle error(s)
}

// insert
stmt, err := db.Prepare("INSERT INTO userinfo(username, departname, 
created) values(?,?,?)")
res, err := stmt.Exec("astaxie", "研发部门", "2012-12-09")
id, err := res.LastInsertId()
fmt.Println(id)

// update
stmt, err = db.Prepare("update userinfo set username=? where uid=?")
res, err = stmt.Exec("astaxieupdate", id)
affect, err := res.RowsAffected()


   - The "watch if" would be executed after each assignment of any of the 
   variables used in SimpleStmt of the statement.
   - Multiple "watch if" would be executed in order or appearance
   - The "watch if" could be used like "defer..." inside functions
   - The "watch if" would work in its full scope of the watched variables

I am not a language expert, so may be there is a saner way of expression 
what I want to achieve.

But bottom line is, there should by an easier to read and write way to deal 
with errors in Go.


Martin





-- 
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: error handling needs syntactical sugar

On Monday, September 4, 2017 at 10:48:06 PM UTC+2, Tamás Gulácsi wrote:
>
> Why do you Prepare a statement if you don't reuse it? Just use a db.Exec.

Just wanted to show a pattern which I see very often in Go code. Its not a 
working example, and I am not asking for improvements in that code. 

But concretes aside: error handling IS important!
>

Yes it is. But as my example shows, it should not get annoying.

> But if such code bothers you, create some helper type / function: see one 
> Andy+Brad pair programming video where they create an errWriter struct 
> which is an io.Writer, and just writes to the underlyin Write. Untill the 
> first error. From then on it always returns the fist error.
>

The problem with ANY error handling solution within the existing Go syntax 
will require one of three things:

   - Wrap the call which you need to check the error for
   - Wrap the check into a function, to save code lines
   - Do some tricks to check the error at the end of a block

Neither one of these methods is satisfying for me. I need to be able to 
produce readable, concise code which does the right thing.

-- 
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] error handling needs syntactical sugar

Axel, 

thanks for the reply.

As I already replied to Tomas, I am not looking for improvements in this 
particular case where I need to call an SQL database.

An no, I dont want to wrap all function I use into something which collects 
the errors for me.

Let's say you want to log & panic & exit after any error.

How do you do that, without putting code after each statement or wrapping?

You can't. And that's why I am proposing to be a little bit open to new 
ideas.

Every modern language I know of has some sort of try...catch construct.


Martin




On Monday, September 4, 2017 at 10:57:51 PM UTC+2, Axel Wagner wrote:
>
> See, e.g. here 
> <https://groups.google.com/d/topic/golang-nuts/ROr5jveMQvg/discussion> or 
> here 
> <https://groups.google.com/d/topic/golang-nuts/68J-mLCC1JI/discussion> for 
> previous discussions of very similar (even mostly identical) proposals.
>
> What I always dislike about these kinds of proposals is, that they are 
> encouraging not handling errors, but instead just passing them up-stack. In 
> general, all of the sites where you are checking for errors will signify 
> different error conditions, that should be communicated differently 
> upstream. For example:
>
> db.Prepare("INSERT INTO userinfo(username, departname, created) 
> values(?,?,?)")
> -> This could fail for basically two reasons: Either communication with 
> your database somehow failed (e.g. a broken network connection), in which 
> case you want to return the equivalent of an HTTP 503 error, or the syntax 
> of your statement is wrong, in which case I'd argue panic'ing would be the 
> correct thing - at the very least, returning the equivalent of a 500.
>
> stmt.Exec("astaxie", "研发部门", "2012-12-09")
> -> Either a 503. Or 400, 403, 409…
>
> res.LastInsertId()
> -> 500 or 501?
>
> The issue is, that by simply checking for nil and passing it along, you 
> are *not handling your error*. Different error conditions require different 
> error handling and what the correct error handling is, depends heavily on 
> the application. An ENODIR error in one line of code can signify a totally 
> different error condition than the same error two lines later. So all of 
> these proposals are born out of an exception-style idea of how error 
> handling is supposed to work; deep within the call stack something goes 
> wrong and that something is then just bubbled up to be someone else's 
> problem. Good error handling just can't be well abbreviated in this way - 
> at least not generically. It's too application-specific for that.
>
> On Mon, Sep 4, 2017 at 8:27 PM, > 
> wrote:
>
>> Seriously? And yes, I have read 
>> https://blog.golang.org/errors-are-values...
>>
>> The best case reduction I found is:
>>
>> ...
>> res, err = stmt.Exec("astaxieupdate", id)
>> checkError(err)
>> ...
>>
>> Still, I need this after each line of calling a function which may return 
>> an error.
>>
>
> A better take-away from that blog post would have been, to orient yourself 
> around the example of a writer given. You could, for example, provide a 
> one-time abstraction that wraps *sql.DB and collects the error. I'd agree 
> that the sql package tends to not be amazing for that, because of its set 
> of interdependent types, it is still possible. For example, with this 
> <https://play.golang.org/p/kdgBUqWeR->, you could write
>
> d := &errDB{db: d}
> stmt := d.Prepare("INSERT INTO…")
> res := stmt.Exec(…)
> id := res.LastInsertId()
> stmt := d.Prepare("UPDATE…")
> res := stmt.Exec(…, id)
> affect := res.RowsAffected()
> return d.err
>
> Now… this isn't really nice either (see above. sql isn't really 
> well-designed for this. You'd probably try and implement a driver for this, 
> but sql doesn't make that easy either). And it's a bad idea for all the 
> same reasons the watch-proposal isn't a great idea here. But it illustrates 
> a far more effective take-away from that blog post.
>  
>
>>
>> I bet this is not pleasant to do in larger code bases and it also takes 
>> away focus from what is actually happening.
>>
>> 50-80% of all lines of code in my example deal with error handling?
>>
>> This is not good. Seriously.
>>
>> And don't get me wrong, there is a lot of things I really like, love and 
>> adore about Go, but catching errors needs an improved syntax!
>>
>> And I am not proposing try...catch here. 
>>
>> How about introducing a new piece of syntax 
>>
>> "watch if

[go-nuts] Re: error handling needs syntactical sugar

Hi Dorival,

thanks for supporting me with my idea.

And yes, after writing my post yesterday I was thinking, "watchif" or even 
simply "watch".

And yes, today I am more in favor of simply *"watch"*.

And yes, we can constrain this to the context of one function (like defer), 
I am ok with that. 

What you are describing how you work with errors and how you spent hours 
adding 

*if err != nil*

that is *exactly* my point.

On could nicely write this

...
watch err!=nil {
  handle_sql_error(err)
}
...

Of course, watch could also be used to not watch out for errors but any 
other places where new values to get assigned to variables.

Martin

>
>>

-- 
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] error handling needs syntactical sugar

2017-09-05 Thread martin . rode


>
>
> You don't. But it's a bad idea. And "I want to make writing bad code 
> easier" isn't a very convincing argument for a language-change.
>

Ok, than I want to

   - Make it easier to read and follow
   - Make it possible to handle errors in one place instead of 10

I see you point, and yes, I am also against bubbling errors all the way to 
the top and let it end in "an unknown error occurred", don't get me wrong!

BUT my point is, what do I do with 10 or more sql statements, when it 
doesn't really matter which one fails why?

Some libraries only return error and an explanation as a String (e.g. 
Postgres), so you don't really have a choice but return anyway.
 

>
> You can't. And that's why I am proposing to be a little bit open to new 
>> ideas.
>>
>
> And how open are you to the idea that good error handling isn't about 
> writing the least amount of code or bubbling up an error in the most 
> efficient way, but about *handling errors*? Because you haven't really 
> replied to that part.
>

I hope my sentence above explains that. Another idea would be: Look at 
common go code and see how often people just check for err != nil 10 times 
in a single function, calling always the SAME error handler. In programming 
you sometimes simply want to get things done and if it is really not 
important where exactly an error occurred, a construct like my `watch` 
comes in handy.

 

>
> (and FTR, one of the points I was making is, that this isn't a new idea. 
> It's proposed fairly frequently)
>  
>
>> Every modern language I know of has some sort of try...catch construct.
>>
>
> Go is modern and doesn't have it. So this seems cherry-picked.
>

Well, I am not saying Go needs it to, I am saying there is a demand for 
error handling of some sort.

C had nothing besides returning -MYERRORCONST, Go can return errors more 
explicitly, but in its current state it is not saving me much in terms of 
lines of code compared to C nor does it help with readability.

And, I have another argument against your "I want people to deal with their 
errors". You cannot force people into too much. That's why you see SOOO 
much Go code which simply copy & pastes long long chains of "if err != nil" 
statements.

Martin

-- 
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] error handling needs syntactical sugar

2017-09-05 Thread martin . rode

Dorival,

thanks for counting your error calls, but without any other number showing 
the size of your project they cannot really put in perspective ;-)

And I think *watch* should not only be function bound, but bound to the 
current scope, same as *var*.

Martin


On Tuesday, September 5, 2017 at 9:20:10 AM UTC+2, Dorival Pedroso wrote:
>
> And I've written 231 error messages (I use a function called chk.Err() to 
> do so):
> find . -iname "*.go" -exec grep -inH "chk.Err" {} \; | wc -l
> 231
>
> See the messages here: 
> https://gist.github.com/cpmech/d2e36dcbe277cd72605f3732d79c798b 
>
> And I have a feeling that I've done only 20% of the error messages... 
> (lots of work still needed...)
>
>
> On Tuesday, September 5, 2017 at 5:15:16 PM UTC+10, Dorival Pedroso wrote:
>>
>> I'm working on a Go project right now and I realised I've written 569 "if 
>> err != nil":
>> find . -iname "*.go" -exec grep -inH "if err != nil" {} \; | wc -l
>> 569
>>
>>
>> On Tuesday, September 5, 2017 at 4:57:45 PM UTC+10, Axel Wagner wrote:
>>>
>>>
>>>
>>> On Tue, Sep 5, 2017 at 8:49 AM,  wrote:
>>>
>>>> Axel, 
>>>>
>>>> thanks for the reply.
>>>>
>>>> As I already replied to Tomas, I am not looking for improvements in 
>>>> this particular case where I need to call an SQL database.
>>>>
>>>> An no, I dont want to wrap all function I use into something which 
>>>> collects the errors for me.
>>>>
>>>> Let's say you want to log & panic & exit after any error.
>>>>
>>>> How do you do that, without putting code after each statement or 
>>>> wrapping?
>>>>
>>>
>>> You don't. But it's a bad idea. And "I want to make writing bad code 
>>> easier" isn't a very convincing argument for a language-change.
>>>
>>> You can't. And that's why I am proposing to be a little bit open to new 
>>>> ideas.
>>>>
>>>
>>> And how open are you to the idea that good error handling isn't about 
>>> writing the least amount of code or bubbling up an error in the most 
>>> efficient way, but about *handling errors*? Because you haven't really 
>>> replied to that part.
>>>
>>> (and FTR, one of the points I was making is, that this isn't a new idea. 
>>> It's proposed fairly frequently)
>>>  
>>>
>>>> Every modern language I know of has some sort of try...catch construct.
>>>>
>>>
>>> Go is modern and doesn't have it. So this seems cherry-picked.
>>>  
>>>
>>>>
>>>>
>>>> Martin
>>>>
>>>>
>>>>
>>>>
>>>> On Monday, September 4, 2017 at 10:57:51 PM UTC+2, Axel Wagner wrote:
>>>>>
>>>>> See, e.g. here 
>>>>> <https://groups.google.com/d/topic/golang-nuts/ROr5jveMQvg/discussion> or 
>>>>> here 
>>>>> <https://groups.google.com/d/topic/golang-nuts/68J-mLCC1JI/discussion> 
>>>>> for 
>>>>> previous discussions of very similar (even mostly identical) proposals.
>>>>>
>>>>> What I always dislike about these kinds of proposals is, that they are 
>>>>> encouraging not handling errors, but instead just passing them up-stack. 
>>>>> In 
>>>>> general, all of the sites where you are checking for errors will signify 
>>>>> different error conditions, that should be communicated differently 
>>>>> upstream. For example:
>>>>>
>>>>> db.Prepare("INSERT INTO userinfo(username, departname, created) 
>>>>> values(?,?,?)")
>>>>> -> This could fail for basically two reasons: Either communication 
>>>>> with your database somehow failed (e.g. a broken network connection), in 
>>>>> which case you want to return the equivalent of an HTTP 503 error, or the 
>>>>> syntax of your statement is wrong, in which case I'd argue panic'ing 
>>>>> would 
>>>>> be the correct thing - at the very least, returning the equivalent of a 
>>>>> 500.
>>>>>
>>>>> stmt.Exec("astaxie", "研发部门", "2012-12-09")
>>>>> -> Either a 503. Or 400, 403, 409…
>>>>>
>>

[go-nuts] Re: error handling needs syntactical sugar

2017-09-05 Thread martin . rode

Dorival,

I think we can celebrate already if we achieve anything with this 
discussion. Let's not ask for too much, plus let's not make it too 
complicated.

I think your proposed "watch err", hides too much and does too little.

You can simply write (the inline code editor is broken, BTW)

func ... {
var err
watch err != nil {
// handle error
return
}
// do stuff
yo1, err := do_stuff1()
yo2, err := do_stuff2()
yo3, err := do_stuff3()
}


Martin


On Tuesday, September 5, 2017 at 9:32:50 AM UTC+2, Dorival Pedroso wrote:
>
> Hi Martin;
>
> What about two commands "*watch*" and "*watchif*"?
>
> The first works as the "*var*" command and the second as the "*if*" 
> command.
>
> "*watch*" does:
>
>1. In a function with *error* as an output (anywhere): returns in case 
>the *err* declared with *watch err* (or *watch myerror*) becomes 
>non-nil. *watch err* would declare *err*" as *var* does. Most use 
>cases would put *watch err* at the beginning of a function (although 
>this is optional as it is with *defer*)
>2. In a test function; aka TestSomething(something *testing.T), *watch 
>err error* would declare *err* (or *watch myerror error*) and if an 
>error occurs, it would call something.FailNow() after (printing the error 
>message?---still need to think this part better)
>3. In the main function: *watch err error* would print the error 
>message (or maybe pipe to stderr) and os.Exist(1)
>4. *watchif err != nil {HERE}* would be more powerful because it would 
>allow us to do other things. But the mechanism is similar (as you proposed 
>initially): if *err* becomes non-nil anywhere, the execution in *HERE* 
>would take place.
>
> Cheers!
>
>
> On Tuesday, September 5, 2017 at 4:55:59 PM UTC+10, 
> marti...@programmfabrik.de wrote:
>>
>> Hi Dorival,
>>
>> thanks for supporting me with my idea.
>>
>> And yes, after writing my post yesterday I was thinking, "watchif" or 
>> even simply "watch".
>>
>> And yes, today I am more in favor of simply *"watch"*.
>>
>> And yes, we can constrain this to the context of one function (like 
>> defer), I am ok with that. 
>>
>> What you are describing how you work with errors and how you spent hours 
>> adding 
>>
>> *if err != nil*
>>
>> that is *exactly* my point.
>>
>> On could nicely write this
>>
>> ...
>> watch err!=nil {
>>   handle_sql_error(err)
>> }
>> ...
>>
>> Of course, watch could also be used to not watch out for errors but any 
>> other places where new values to get assigned to variables.
>>
>> Martin
>>
>>>
>>>>

-- 
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: error handling needs syntactical sugar

2017-09-07 Thread martin . rode

On Tuesday, September 5, 2017 at 10:39:05 AM UTC+2, Rob 'Commander' Pike 
wrote:
>
> If you find that lines like if err != nil are a significant fraction 
> of non-test code, your code probably needs a better error handling 
> strategy, not a language change. I have done measurements in the past 
> and although people complain a lot about the presence of that 
> statement, it shows up much less often in practice than people claim, 
> and when it does appear a lot it's usually because the programmer is 
> not thinking enough about how errors should work. 
>

Well, I can try to find more examples, but whenever you interact with say 
SQL or other libraries, errors can occur at each call into that library.

Very often it is enough to check the errors for one block (think try... 
catch)

The problem with all suggested solutions so far is, that it requires 
wrapping function calls of some sort.

Personally, I don't like this. There are calls (say to interact with an SQL 
library), and once you start wrapping them in order for an improved error 
management, the solution is very local and personal and less readable.

This does not support Go's idea of producing readable code across 
developers and styles.

After all the responses in this thread, I thought about my proposal a 
little more carefully, so how about this, and it is a construct which can 
be used not only for errors:

watch err != nil {
yo1, err = do_stuff1()
yo2, err = do_stuff2()
yo3, err = do_stuff3()
} then {
// handle your error
}

This statement could be used for other cases as well, it is easy to read 
and understand, and it saves the programmer from line duplication.

Martin

-- 
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] SIGILL: illegal instruction when making cgo call

2017-11-01 Thread martin . ostrovsky

Hello,

Encountered this issue running a statically compiled binary that uses cgo 
(Compiled using go1.8.3). It works OK on one CPU type but not on another. 
The binary is built on a server which is neither of the two below. Is this 
a Go issue or something to do with how the C library is built (gcc version 
mismatch, compiler flags etc.)?  

SIGILL: illegal instruction
PC=0x1283c22 m=0 sigcode=2
signal arrived during cgo execution
goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x11a2c80, 0xc4219e9c70, 0x4e7e960)
/usr/local/go/src/runtime/cgocall.go:131 +0xe2 fp=0xc4219e9c30 
sp=0xc4219e9bf0
xxx-wv._Cfunc_d2v_init(0x4e7e9a0, 0x4e7e9d0, 0xc, 0x4e7e960, 0x0, 0x0)
/tmp/go-build684597318/xxx-wv/_obj/_cgo_gotypes.go:137 +0x4e 
fp=0xc4219e9c70 sp=0xc4219e9c30
xxx-wv.NewFromFile(0xc430df8fc0, 0x26, 0xc430df9170, 0x26, 0x101, 0x0, 0x0, 
0x0, 0x0, 0x10005, ...)
/home/ubuntu/go/src/xxx-wv/wv.go:100 +0xe5 fp=0xc4219e9cf0 sp=0xc4219e9c70
xxx-ent.init.1()
/home/ubuntu/go/src/xxx-ent/ent.go:132 +0x425 fp=0xc4219e9ef0 
sp=0xc4219e9cf0
xxx-ent.init()
/home/ubuntu/go/src/xxx-ent/util.go:109 +0x2cc fp=0xc4219e9f68 
sp=0xc4219e9ef0
xxx-api.init()
/home/ubuntu/go/src/xxx-api/s.go:203 +0x89 fp=0xc4219e9f78 sp=0xc4219e9f68
main.init()
/home/ubuntu/go/src/xxx.go:122 +0x8e fp=0xc4219e9f88 sp=0xc4219e9f78
runtime.main()
/usr/local/go/src/runtime/proc.go:173 +0x1ca fp=0xc4219e9fe0 sp=0xc4219e9f88
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:2197 +0x1 fp=0xc4219e9fe8 
sp=0xc4219e9fe0
goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:2197 +0x1
goroutine 20 [syscall]:
os/signal.signal_recv(0x0)
/usr/local/go/src/runtime/sigqueue.go:116 +0x104
os/signal.loop()
/usr/local/go/src/os/signal/signal_unix.go:22 +0x22
created by os/signal.init.1
/usr/local/go/src/os/signal/signal_unix.go:28 +0x41
rax0x4e7f130
rbx0x7fff1a258190
rcx0x7fff1a257e18
rdx0x0 
rdi0x7fff1a257e20
rsi0x1283e2a
rbp0x7fff1a2581b8
rsp0x7fff1a257e20
r8 0x1283e2a
r9 0x7fff1a257a50
r100x301fdb0
r110x1283e2a
r120x4e7f130
r130x4e7f150
r140x7fff1a257e50
r150x7fff1a257fe0
rip0x1283c22
rflags 0x10206
cs 0x33
fs 0x0 
gs 0x0 


Architecture for the server that doesn't work:

processor: 7
vendor_id: GenuineIntel
cpu family: 6
model: 44
model name: Intel(R) Xeon(R) CPU   X5680  @ 3.33GHz
stepping: 2
microcode: 0x15
cpu MHz: 3325.000
cache size: 12288 KB
physical id: 1
siblings: 4
core id: 3
cpu cores: 4
apicid: 7
initial apicid: 7
fpu: yes
fpu_exception: yes
cpuid level: 11
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc 
aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes 
hypervisor lahf_lm ida arat dtherm
bogomips: 6650.00
clflush size: 64
cache_alignment: 64
address sizes: 40 bits physical, 48 bits virtual
power management:

The same binary works properly on a server with this architecture:

processor: 7
vendor_id: GenuineIntel
cpu family: 6
model: 45
model name: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
stepping: 7
microcode: 0x70d
cpu MHz: 2900.000
cache size: 20480 KB
physical id: 1
siblings: 4
core id: 3
cpu cores: 4
apicid: 7
initial apicid: 7
fpu: yes
fpu_exception: yes
cpuid level: 13
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc 
aperfmperf pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt 
tsc_deadline_timer aes xsave avx hypervisor lahf_lm ida arat pln pts dtherm
bogomips: 5800.00
clflush size: 64
cache_alignment: 64
address sizes: 42 bits physical, 48 bits virtual
power management:

-- 
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: Random panic in production with Sprintf

2019-05-02 Thread Anthony Martin

What version of Go are you using?

XXX ZZZ  once said:
> fmt.(*pp).fmtString(0xc023c17740, 0x0, 0x5, 0xc00076)
> /usr/local/go/src/fmt/print.go:448 +0x132
> fmt.(*pp).printArg(0xc023c17740, 0x9978e0, 0xc016a68a30, 0x76)
> /usr/local/go/src/fmt/print.go:684 +0x880
> fmt.(*pp).doPrintf(0xc023c17740, 0xa6e22f, 0x5, 0xc048c27818, 0x1, 0x1)
> /usr/local/go/src/fmt/print.go:1112 +0x3ff
> fmt.Sprintf(0xa6e22f, 0x5, 0xc048c27818, 0x1, 0x1, 0x80, 0xa36200)
> /usr/local/go/src/fmt/print.go:214 +0x66

This shows signs of memory corruption. The last argument passed to
fmtString (0xc00076) should be the same as the last argument
passed to printArg (0x76 or 'v') but it has some high bits set. Also,
the pointer to the format string data changes from 0xa6e22f (which is
probably in the .rodata section of the binary) to 0x0.

Something is amiss.

  Anthony

-- 
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: Random panic in production with Sprintf

2019-05-02 Thread Anthony Martin

Ian Lance Taylor  once said:
> I don't *think* the format string is changing.  I think the 0 is from
> the string being printed, not the format string.  They both happen to
> be length 5.

Misled by the pair of fives. Mea culpa.

  Anthony

-- 
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] Interesting public commentary on Go...

2019-05-23 Thread Anthony Martin

Sam Whited  once said:
> This is especially a problem when these proposals further tie Go to
> Google web services run by the Go team (though I'm veering off into a
> separate problem here). To me this feels like it's almost a type of
> vertical integration and it's an absolutely disgusting thing to do, and
> I don't use that word lightly. Not because I think the Go team is
> planning on doing anything bad with the information all Go users will
> now be sending to them, or because I think Google executives are putting
> down mandates and influencing Go, but because we don't know what future
> Go team members or Google execs will do. We don't know who will be
> running the Go project in 10 or 20 years, so the Go team now should be
> making sure they limit the potential for abuse, especially when they
> work for a company with a long history of anti- competitive behavior and
> abuse of its size and power.

How do you square this opinion with the fact that the Go team
went out of their way to enable the use of third-party module
proxies, something that is good for the community but would be
of little practical use to Google?

  Anthony

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20190523222743.GA28121%40alice.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

2019-06-03 Thread Martin Schnabel

Hi,

is my impression correct, that this proposal adds types as values to the
language? It's seems like it does the section 'Unnamed generic
arguments'. That by itself would go a long way and warrants some
discussion, I'd say.

If so, then why use a new keyword 'gen'? Why not 'type' itself.
It would have some symmetry with how the func and struct keywords are
used for closures and unnamed structs. The 'type' keyword has no
possible meaning in the parameter list currently.

I use the 'gen' keyword a lot as identifier, mostly for generators
and generated code. While nobody can claim to use 'type'. This would
make converting code so much easier, if this proposal is accepted.

Just a though. Please tell me whether this would be possible.

Thanks for your work, it's much appreciated.
Martin

On 30.05.19 14:08, Michal Strba wrote:

Hi Gophers! :)

I've been thinking about generics in Go 2 ever since the original
contracts proposal and few days ago, ideas finally clicked. One of the
main things about this proposal is that it deliberately omits the
ability to restrict the set of types a function can work with. This is a
limitation, but I hope to convince you that we can still do a vast
majority of the things we were missing, when we were missing generics.

I'd love to share my proposal with you and engage in a good faith
conversation.

Link to the proposal.
<https://gist.github.com/faiface/e5f035f46e88e96231c670abf8cab63f>

Here's what the proposal covers:

1. Syntax of a new gen keyword.
2. Generic functions.
3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in
newfunction).

4. Semantics of generic values (ability to use them as map keys, ...).
5. Generic array lengths.
6. Reflection and interface{}.
7. Generic types (with two examples: Listand Matrix).
8. Generic methods and their limitations due to reflection.
9. Generic interfaces.
10. List of things this proposal can't do.

Thanks,
faiface

--
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
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/6f5f0785-93f7-475a-991c-fc919c5e6730%40googlegroups.com
<https://groups.google.com/d/msgid/golang-nuts/6f5f0785-93f7-475a-991c-fc919c5e6730%40googlegroups.com?utm_medium=email&utm_source=footer>.

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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/739d147e-162d-14fc-a13a-9e7962f074e2%40mb0.org.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

2019-06-03 Thread Martin Schnabel

Hi Michal,

I would argue that the 'const' keyword would by more correct. Because 
the array length is and needs to be constant anyway. And it has 
currently no valid meaning in a parameter list, just like with
the 'type' keyword. However i would argue that the array length, if 
written as part of the array syntax, as in '[n]elem' does not need an 
explicit keyword qualifier, because - again - it's unambiguous in the 
parameter context. Would you agree?

Best regards
  Martin

On 03.06.19 14:20, Michal Strba wrote:

Hi Martin.

The proposal adds types as "values", but not really. You can only accept 
a type to a function, but you cannot return a type. That makes the 
system far from a dependent type system, even with the support for 
generic array lengths.

Being able to return types from functions and use those functions in 
types is what brings all the power (and complexity) of dependent typing, 
but what I proposed is just a simple system for explicit type anotation 
directly in the function signature.

Regarding the 'gen' keyword, I chose it because I propose not only 
generic types, but also generic array lengths. But you are right that 
using 'type' would probably be better. Do you think that using the 
'type' keyword also in the context of generic array lengths would be fine?

On Mon, Jun 3, 2019, 12:53 Martin Schnabel <mailto:m...@mb0.org>> wrote:

Hi,

is my impression correct, that this proposal adds types as values to
the
language? It's seems like it does the section 'Unnamed generic
arguments'. That by itself would go a long way and warrants some
discussion, I'd say.

If so, then why use a new keyword 'gen'? Why not 'type' itself.
It would have some symmetry with how the func and struct keywords are
used for closures and unnamed structs. The 'type' keyword has no
possible meaning in the parameter list currently.

I use the 'gen' keyword a lot as identifier, mostly for generators
and generated code. While nobody can claim to use 'type'. This would
make converting code so much easier, if this proposal is accepted.

Just a though. Please tell me whether this would be possible.

Thanks for your work, it's much appreciated.
    Martin

On 30.05.19 14:08, Michal Strba wrote:
 > Hi Gophers! :)
 >
 > I've been thinking about generics in Go 2 ever since the original
 > contracts proposal and few days ago, ideas finally clicked. One
of the
 > main things about this proposal is that it deliberately omits the
 > ability to restrict the set of types a function can work with.
This is a
 > limitation, but I hope to convince you that we can still do a vast
 > majority of the things we were missing, when we were missing
generics.
 >
 > I'd love to share my proposal with you and engage in a good faith
 > conversation.
 >
 > Link to the proposal.
 > <https://gist.github.com/faiface/e5f035f46e88e96231c670abf8cab63f>
 >
 > Here's what the proposal covers:
 >
 > 1. Syntax of a new gen keyword.
 > 2. Generic functions.
 > 3. Unnamed generic arguments (a.k.a. a way to gve a type to the
built-in
 > newfunction).
 > 4. Semantics of generic values (ability to use them as map keys,
...).
 > 5. Generic array lengths.
 > 6. Reflection and interface{}.
 > 7. Generic types (with two examples: Listand Matrix).
 > 8. Generic methods and their limitations due to reflection.
 > 9. Generic interfaces.
 > 10. List of things this proposal can't do.
 >
 > Thanks,
 > faiface
 >
 > --
 > 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
<mailto:golang-nuts%2bunsubscr...@googlegroups.com>
 > <mailto:golang-nuts+unsubscr...@googlegroups.com
<mailto:golang-nuts%2bunsubscr...@googlegroups.com>>.
 > To view this discussion on the web visit
 >

https://groups.google.com/d/msgid/golang-nuts/6f5f0785-93f7-475a-991c-fc919c5e6730%40googlegroups.com

 >

<https://groups.google.com/d/msgid/golang-nuts/6f5f0785-93f7-475a-991c-fc919c5e6730%40googlegroups.com?utm_medium=email&utm_source=footer>.
 > 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,
s

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

2019-06-03 Thread Martin Schnabel

I agree. That is a good point. I consider arrays an edge case. Although 
still important, it will probably not be all too common. So the extra 
verbosity should not be a problem.

I am happy you generally agree and think these minor tweaks can make a 
big difference for the roll-out of the proposed feature, if accepted.

I also think, that this is one of the better proposals. It at least
feels more like go, syntax-wise, than most, except for the num part, 
which seems like an afterthought.

Again thank you for your work exploring this!

Best regards
  Marin

On 03.06.19 15:49, Michal Strba wrote:
'const' could be fine too. I guess this is mostly a matter of personal 
preference.

Regarding the array length syntax. It does require qualifying for two 
reasons:

1. Unnamed arguments.
2. Using 'gen' (or 'type', 'const') makes it easy to say "gen is not 
allowed in the return types", which is an important rule. Without 
qualification, this rule would be hard to express.

On Mon, Jun 3, 2019, 15:26 Martin Schnabel <mailto:m...@mb0.org>> wrote:

Hi Michal,

I would argue that the 'const' keyword would by more correct. Because
the array length is and needs to be constant anyway. And it has
currently no valid meaning in a parameter list, just like with
the 'type' keyword. However i would argue that the array length, if
written as part of the array syntax, as in '[n]elem' does not need an
explicit keyword qualifier, because - again - it's unambiguous in the
parameter context. Would you agree?

Best regards
    Martin

On 03.06.19 14:20, Michal Strba wrote:
 > Hi Martin.
 >
 > The proposal adds types as "values", but not really. You can only
accept
 > a type to a function, but you cannot return a type. That makes the
 > system far from a dependent type system, even with the support for
 > generic array lengths.
 >
 > Being able to return types from functions and use those functions in
 > types is what brings all the power (and complexity) of dependent
typing,
 > but what I proposed is just a simple system for explicit type
anotation
 > directly in the function signature.
 >
 > Regarding the 'gen' keyword, I chose it because I propose not only
 > generic types, but also generic array lengths. But you are right
that
 > using 'type' would probably be better. Do you think that using the
 > 'type' keyword also in the context of generic array lengths would
be fine?
 >
 > On Mon, Jun 3, 2019, 12:53 Martin Schnabel mailto:m...@mb0.org>
 > <mailto:m...@mb0.org <mailto:m...@mb0.org>>> wrote:
 >
 >     Hi,
 >
 >     is my impression correct, that this proposal adds types as
values to
 >     the
 >     language? It's seems like it does the section 'Unnamed generic
 >     arguments'. That by itself would go a long way and warrants some
 >     discussion, I'd say.
 >
 >     If so, then why use a new keyword 'gen'? Why not 'type' itself.
 >     It would have some symmetry with how the func and struct
keywords are
 >     used for closures and unnamed structs. The 'type' keyword has no
 >     possible meaning in the parameter list currently.
 >
 >     I use the 'gen' keyword a lot as identifier, mostly for
generators
 >     and generated code. While nobody can claim to use 'type'.
This would
 >     make converting code so much easier, if this proposal is
accepted.
 >
 >     Just a though. Please tell me whether this would be possible.
 >
 >     Thanks for your work, it's much appreciated.
 >         Martin
 >
 >
 >     On 30.05.19 14:08, Michal Strba wrote:
 >      > Hi Gophers! :)
 >      >
 >      > I've been thinking about generics in Go 2 ever since the
original
 >      > contracts proposal and few days ago, ideas finally
clicked. One
 >     of the
 >      > main things about this proposal is that it deliberately
omits the
 >      > ability to restrict the set of types a function can work with.
 >     This is a
 >      > limitation, but I hope to convince you that we can still
do a vast
 >      > majority of the things we were missing, when we were missing
 >     generics.
 >      >
 >      > I'd love to share my proposal with you and engage in a
good faith
 >      > conversation.
 >      >
 >      > Link to the proposa

Re: [go-nuts] Parsing time zone +07:00

2019-07-02 Thread Martin Schnabel

the format time uses a minus sign '-' instead of a plus

https://play.golang.org/p/pXDXm0KmwTz

have fun!

On 02.07.19 20:11, 'Константин Иванов' via golang-nuts wrote:

https://play.golang.org/p/4Rr2xVGKnQg

|
packagemain

import(
"fmt"
"time"
)

constin="+03:00"// "2019-07-02T19:28:39.403+03:00"

constTIME ="+07:00"// "2006-01-02T15:04:05.999+07:00"

func main(){
fmt.Println(time.Parse(TIME,in))
}
|

Got << parsing time "+03:00" as "+07:00": cannot parse "3:00" as "+07:00" >>

Godoc says:

Numeric time zone offsets format as follows:

-0700 ±hhmm
-07:00 ±hh:mm
-07±hh

Am I doind something wrong or it is bug?

--
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
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/5c6cdaa3-b549-4583-aa19-d4231605953e%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/001734e0-8b48-6a89-9a04-4ec46b782e80%40mb0.org.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Citation Needed

2019-07-08 Thread Martin Schnabel





On 06.07.19 08:50, go je wrote:

Is the Category "Games" gaining attention in the go community?
Are the Developers writing for production level?
Do we have an examples?
image.png

I would guess, that most of respondents using go for game development, 
use it on the server side. Think multi-, browser- or mobile-games.


Have fun!

--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/935eda32-0317-b643-e07e-ab941f60255d%40mb0.org.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Does invoking a method with an interface variable avoid dependency analysis?

2019-07-08 Thread Martin Schnabel





On 08.07.19 02:51, Il-seob Bae wrote:

As per the spec ,

A reference to a method m is a method value or method expression of
the form t.m, where the (static) type of t is not an interface type,
and the method m is in the method set of t. It is immaterial whether
the resulting function value t.m is invoked.


In other words, the mere presence of an interface variable guarantees 
/no/ dependency analysis? Here, I did a test 
, but it indeed suffers the 
analysis. Any thoughts?




The key part is that i has dependencies and is not ready and d has no
dependencies and is ready for initialization. If you change the
initialization expression of d from a constant to a function you see
initialization in source order.

https://play.golang.org/p/0D8Lxw_KBz-

--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/455d59c2-5e22-5071-717e-8b12b3c0b110%40mb0.org.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Does invoking a method with an interface variable avoid dependency analysis?

2019-07-08 Thread Martin Schnabel


sorry. i misunderstood your question. the paragraph you quoted refers to
reference to methods values (t.m) or expressions (T.m) and not method
calls t.m() as in your example. does that help solve the question?

On 08.07.19 20:09, Martin Schnabel wrote:



On 08.07.19 02:51, Il-seob Bae wrote:

As per the spec <https://golang.org/ref/spec#Package_initialization>,

    A reference to a method m is a method value or method expression of
    the form t.m, where the (static) type of t is not an interface type,
    and the method m is in the method set of t. It is immaterial whether
    the resulting function value t.m is invoked.


In other words, the mere presence of an interface variable guarantees 
/no/ dependency analysis? Here, I did a test 
<https://play.golang.org/p/8Fo4nUgGLBP>, but it indeed suffers the 
analysis. Any thoughts?




The key part is that i has dependencies and is not ready and d has no
dependencies and is ready for initialization. If you change the
initialization expression of d from a constant to a function you see
initialization in source order.

https://play.golang.org/p/0D8Lxw_KBz-



--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0f2e0bf3-d156-8507-155c-620f41342ede%40mb0.org.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] get interface and method name

2019-07-12 Thread Martin Schnabel


Because AccountService.Create is a method expression you can get to the
interface type by inspecting its first argument. Then you could check
the interface type for all methods and compare the input and output
parameters. This however is brittle and only works if you can guarantee
that there is no other method in the interface with the same parameter
lists.

So i would think using the runtime package is the only and therefor
best option for what you are asking.

Have fun!


On 12.07.19 11:06, Vasiliy Tolstov wrote:

чт, 11 июл. 2019 г. в 00:27, Ian Lance Taylor :


On Wed, Jul 10, 2019 at 1:40 PM Vasiliy Tolstov  wrote:


Hi! i have interface like

type AccountService interface {
   Create(context.Context) error
}

if i need to get string representation of this interface from passed
AccountService.Create how can i do that?

Now i create POC like this:
parts := 
strings.Split(runtime.FuncForPC(reflect.ValueOf(iface).Pointer()).Name(),
".")
return parts[len(parts)-2] + "." + parts[len(parts)-1]

it returns string "AccountService.Create"
Does it possible to get this not using runtime? only via reflect and
may be without strings ?


Can you show us a working example in the Go playground to demonstrated
what you are looking for?

If your interface is named AccountService, I would not expect any
method to be named AccountService.Create.  The Create method will be
defined on other types converted to the interface type, not on the
interface type itself.  So I'm not sure what you are actually looking
for.

Ian


https://play.golang.org/p/VZhO4KdKk-J
I need to return textual representation of interface name and method name.



--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1dbff307-443d-826c-8ecb-339107f7e573%40mb0.org.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Get struct type , save and reconstruct empty struct later

2019-07-20 Thread Martin Schnabel

If you only need any unnamed struct type you can create one with reflect
from the field information that you can write to text somewhere.

https://godoc.org/reflect#StructOf

These unnamed struct types however do not have any methods and do not
wrap embedded named type methods.

Otherwise you probably want to register your struct types on program
initialization; for later lookup and so that they are part of the
compiled binary. The gob package does it like that for example.

Have fun!

On 20.07.19 10:44, Vasiliy Tolstov wrote:
Thanks, something like this, but i need to store type in string or 
[]byte in db, and based on this create new empty struct.

сб, 20 июл. 2019 г., 10:55 Jan Mercl <0xj...@gmail.com 
>:

On Sat, Jul 20, 2019 at 9:28 AM Vasiliy Tolstov mailto:v.tols...@selfip.ru>> wrote:

 > Hi. I have reflection based question.
 > I need to store type of struct passed to func and later based on
this stored type reconstruct empty needed struct.
 > Does this possible ?

Not sure I understood the question:
https://play.golang.org/p/5AEn3IsKObo

--
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 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACaajQsO90D5iDOZEpsgwbPBgEu%3DU8eLpYeg%3D2b2odAcp55f9g%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/df1d238c-4884-93a3-c5de-0fc56a3c928e%40mb0.org.

Re: [go-nuts] Regarding strings replace functions issues

2019-08-27 Thread Martin Schnabel


You can use the go playground to share an example. Like this:

https://play.golang.org/p/8RJXT-e91T5

As you can see in that example both functions work as expected.
We can only guess what the problem might be without a concrete
example.

One guess would be that your input has not the newline byte, but
instead the escaped sequence '\' and 'n'? Then you would need
to use the escape sequence for the slash in the search string:

https://play.golang.org/p/O-c76dM_E5B


On 27.08.19 20:06, Durga Someswararao G wrote:

Hi,

Can anyone help me in this case.

I was reading byte data(array of bytes) from another process and 
converted that data to string. Now I am trying to replace escape 
sequences \n with strings.Replace function but golang not detecting it.


Even I tried with bytes.Replace function but no use.

Also observed even strings.Contains function also not detecting \n.

Eg:

strings.Replace("String1\nString2", "\n", "golang",-1 )

Please help to solve this Issue. Can anyone share any issues with 
strings package while after converting bytes to string.


--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/80a19b01-6843-0b44-1ace-e7b73a0e62c9%40mb0.org.

Re: [go-nuts] Regarding strings replace functions issues

2019-08-28 Thread Martin Schnabel

Somewhere in your code producing the text you seem to escape the
the escape sequence for the newline character.

"\n" is a string with the escape sequence for the newline character '\n'
"\\n" is a string with escaped slash and a lowercase n '\\' 'n'

Again, without seeing the code we can only guess. Here is another one:
Go has raw string literals using back-ticks `like this` those literals
do not use escape sequences (`\n` == "\\n" && `\\` == ""). Could it
be, that you accidentally used those raw string literals in the producer
code with the newline escape sequence that is not supported?

On 28.08.19 12:32, Durga Someswararao G wrote:

Hi,

Manually I tried but here my concern is shall I get the reason, Why that
was happening like that?

I am trying to debug strings.Replace is not working.

Thanks.

On Wed, Aug 28, 2019 at 3:52 PM Michel Levieux > wrote:

Hi,

Isn't it that from the other side, you escape the string, or call a
method that does it before sending it via tcp? That would explain
that all the "\n" become "\\n".

Le mer. 28 août 2019 à 12:17, Durga Someswararao G
mailto:durgasomeswararao...@gmail.com>> a écrit :

Hi Tamás,

But even in other side also I am using golang to convert string
into bytes. Using tcp connection with net package I am getting
data from other process.

FYI
When I try to replace string with \\n it was working fine.

Like below:
processoutput = strings.Replace("String 1\n String
2","\\n","'@_@_@'",-1)

On Wed, Aug 28, 2019 at 3:26 PM Tamás Gulácsi
mailto:tgulacs...@gmail.com>> wrote:

That means that other process speaks some other encoding,
not utf-8, which the strings package waits.
Use golang.org/x/text/encoding
to convert to utf-8.

--
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
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/golang-nuts/865188f0-405e-45ee-82b9-7f6d24f1d49f%40googlegroups.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
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGr83pA%2Bvrkg-bYkOs-qjsqxkOgEjoGTmigtJsr0hO287w%40mail.gmail.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
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGrM47a%3Dj6Zbk1caY46FYUG7fXC2J0z0QvoJtSp69b6NCQ%40mail.gmail.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/2c202a4b-1db1-2247-d374-814f66c81b0c%40mb0.org.

Re: [go-nuts] Regarding strings replace functions issues

2019-08-28 Thread Martin Schnabel

Go has a fantastic and very readable language specification with all
the details: https://golang.org/ref/spec#String_literals

(To my surprise the effective go document does not explain raw string
literals, but uses them in the web server example in the template
string)

Another guess by Michel is that you call a string quote function
like strconv.Quote either directly or indirectly on the producer side.

The following playground link demonstrates some ways you could arrive
at a quoted string. https://play.golang.org/p/-QRz7x00Shn

However, then you would also see double quotes enclosing the quoted text
in your output.

To summarize: we found out that your problem has nothing to do with
strings.Replace, but instead with the way your producer writes its
output. We have two general ideas how this could be the case but
can only help you find the issue if you share reproducible examples.

On 28.08.19 13:15, Martin Schnabel wrote:

Somewhere in your code producing the text you seem to escape the
the escape sequence for the newline character.

"\n" is a string with the escape sequence for the newline character '\n'
"\\n" is a string with escaped slash and a lowercase n '\\' 'n'

On 28.08.19 12:32, Durga Someswararao G wrote:

Hi,

Manually I tried but here my concern is shall I get the reason, Why
that was happening like that?

I am trying to debug strings.Replace is not working.

Thanks.

On Wed, Aug 28, 2019 at 3:52 PM Michel Levieux
mailto:m.levi...@capitaldata.fr>> wrote:

Hi,

Isn't it that from the other side, you escape the string, or call a
method that does it before sending it via tcp? That would explain
that all the "\n" become "\\n".

Le mer. 28 août 2019 à 12:17, Durga Someswararao G
mailto:durgasomeswararao...@gmail.com>> a écrit :

Hi Tamás,

But even in other side also I am using golang to convert string
into bytes. Using tcp connection with net package I am getting
data from other process.

FYI
When I try to replace string with \\n it was working fine.

Like below:
processoutput = strings.Replace("String 1\n String
2","\\n","'@_@_@'",-1)

On Wed, Aug 28, 2019 at 3:26 PM Tamás Gulácsi
mailto:tgulacs...@gmail.com>> wrote:

That means that other process speaks some other encoding,
not utf-8, which the strings package waits.
Use golang.org/x/text/encoding
<http://golang.org/x/text/encoding> to convert to utf-8.

-- 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
<mailto:golang-nuts%2bunsubscr...@googlegroups.com>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/golang-nuts/865188f0-405e-45ee-82b9-7f6d24f1d49f%40googlegroups.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
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGr83pA%2Bvrkg-bYkOs-qjsqxkOgEjoGTmigtJsr0hO287w%40mail.gmail.com

<https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGr83pA%2Bvrkg-bYkOs-qjsqxkOgEjoGTmigtJsr0hO287w%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
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
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGrM47a%3Dj6Zbk1caY46FYUG7fXC2J0z0QvoJtSp69b6NCQ%40mail.gmail.com
<https://groups.google.com/d/msgid/golang-nuts/CA%2Ba9DGrM47a%3Dj6Zbk1caY46FYUG7fXC2J0z0QvoJtSp69b6NCQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
You received this message because you are subscribed to the Google Groups

[go-nuts] Re: ls: unsupported SSLv2 handshake received

2019-09-18 Thread Anthony Martin

Prabhash Rathore  once said:
> Looking at comment, it seems Golang does not support SSLv2 and SSLV3.

The crypto/tls package can support SSLv3 if you set tls.Config.MinVersion
to tls.VersionSSL30, but only as a server.

> I am reaching out to see if there is anyway possible to add support for 
> older SSL versions or if there are any workarounds. In SMTP world, there 
> are lots of clients who still use old SSL builds and we would like to be 
> able to support them on our MTA servers.

I think it's unlikely that SSLv2 will be supported. There is a very
old discussion about this at https://github.com/golang/go/issues/3930
that you might want to check out.

Cheers,
  Anthony

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20190918084123.GA4577%40alice.

[go-nuts] JWT validation only in Middleware

2019-09-26 Thread Martin Palma

Hello,

I'm in the process of writing an HTTP API with Go. I use a middleware for 
generating and validating JWT tokens. On any incoming request the 
middleware checks the JWT and validates it. If valid it adds it to the 
request header and calls the next handler. 

Is it save to use the JWT in the next handler without validating it again 
and using the claims?

Best,
Martin

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/69d031e5-2a11-4904-84d6-1e67c0bc85a9%40googlegroups.com.

Re: [go-nuts] JWT validation only in Middleware

2019-09-27 Thread Martin Palma

Yes the handler are arranged as follows:

OAuth2Middleware (JWT token creation on login / JWT validation) ->
InputValidationMiddleware (decoding and validating user input and checks if
the user has the rights to view/request the data according to the claims in
the JWT) -> API Handler (decoding user input and talking to the backend,
return response to the user)

You are right the OAuth2Middlware could instead of passing the token after
validation also pass the claims using the request context. That's right.

Thank you for the feedback.

On Thu, 26 Sep 2019 at 21:36, burak serdar  wrote:

> On Thu, Sep 26, 2019 at 1:14 PM Martin Palma  wrote:
> >
> > Hello,
> >
> > I'm in the process of writing an HTTP API with Go. I use a middleware
> for generating and validating JWT tokens. On any incoming request the
> middleware checks the JWT and validates it. If valid it adds it to the
> request header and calls the next handler.
> >
> > Is it save to use the JWT in the next handler without validating it
> again and using the claims?
>
> If you make sure you have those two handlers in that order, then the
> answer is yes.
>
> Another approach is to validate the JWT in the first handler, and put
> the claims into the request context for the next handler, so the next
> handler doesn't even deal with the JWT, and gets the claims from the
> context. This assumes the second handler won't be called if JWT
> doesn't validate.
>
> >
> > Best,
> > Martin
> >
> > --
> > 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.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/69d031e5-2a11-4904-84d6-1e67c0bc85a9%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANMxC7C_kXNmX1_RCCYwCS3X-7dTrLc_sfzLi-F8mLpcffMY2A%40mail.gmail.com.

[go-nuts] Interface method return other interface?

2019-10-09 Thread Martin Palma

I'm wondering If it is ok (or good Go code) if an interface method returns 
an other interface? Here an example:

type Querier interface {
 Query() string
}

type Decoder interface {
 DecodeAndValidate() Querier
}


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/531f29a6-ea2e-4416-a0d0-ce697dc7a09b%40googlegroups.com.

Re: [go-nuts] Interface method return other interface?

2019-10-10 Thread Martin Palma

Thank you all for your feedback and input. Shame on me that I didn't
look hard enough through the stdlib for getting some examples, but
thanks Axel for pointing that out.

On Thu, Oct 10, 2019 at 3:11 AM Robert Engels  wrote:
>
> Ugh. Every time I see that I cringe
>
> > On Oct 9, 2019, at 7:58 PM, burak serdar  wrote:
> >
> > On Wed, Oct 9, 2019 at 5:48 PM 'Axel Wagner' via golang-nuts
> >  wrote:
> >>
> >> There's loads of precedence in the stdlib:
> >>
> >> https://godoc.org/net/http/#FileSystem.Open
> >> https://godoc.org/net/http#File.Stat
> >> https://godoc.org/net#Conn.LocalAddr
> >> https://godoc.org/database/sql/driver/#Driver.Open
> >> https://godoc.org/image#Image.ColorModel
> >> https://godoc.org/reflect/#Type.Elem
> >> And don't forget that error itself is an interface.
> >>
> >> Honestly, if you need it, go for it. There are definitely places where 
> >> it's over abstraction to do it, but I don't think there's a good or 
> >> universal rule you can use to decide which is which.
> >>
> >> FWIW, I tend to disagree with the "return structs, accept interfaces" 
> >> advise in general. If go had variant func/methods, that would be useful 
> >> guidance. But as it stands, it is too often necessary to violate it (every 
> >> usage of an error return value is in fact such a violation). And the 
> >> "accept interfaces" part tends to lead to over abstraction (I would 
> >> probably agree with "consider accepting interfaces if they already exist" 
> >> though).
> >
> >
> > There is one point you need to remember when returning interfaces:
> > make sure you handle nil correctly:
> >
> > type S struct {}
> >
> > type I interface {}
> >
> > func f() *S {
> >  return nil
> > }
> >
> > func g() I {
> >  x:=f()
> >  return x
> > }
> >
> > Above, g() is not nil. The correct code would be:
> >
> > func g(() I {
> >  x:=f()
> >  if x==nil {
> >   return nil
> >  }
> >  return x
> >
> > }
> >
> >
> >>
> >>> On Wed, Oct 9, 2019 at 9:39 AM Martin Palma  wrote:
> >>>
> >>> I'm wondering If it is ok (or good Go code) if an interface method 
> >>> returns an other interface? Here an example:
> >>>
> >>> type Querier interface {
> >>> Query() string
> >>> }
> >>>
> >>> type Decoder interface {
> >>> DecodeAndValidate() Querier
> >>> }
> >>>
> >>>
> >>> --
> >>> 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.
> >>> To view this discussion on the web visit 
> >>> https://groups.google.com/d/msgid/golang-nuts/531f29a6-ea2e-4416-a0d0-ce697dc7a09b%40googlegroups.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.
> >> To view this discussion on the web visit 
> >> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHHtn5t3TZOCG4xA_3kVbNqY2_xo7EtHoLyhi6P28ku9g%40mail.gmail.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.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqp-n0UaxQVpPVgJKayNzY6Voe5QRL4n7MoqmQMavL3oiQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANMxC7BHfFNduYVqY8xnZyTL8oPzZ2r15ApeGRsVW60Xckswng%40mail.gmail.com.

[go-nuts] Re: [security] Go 1.13.2 and Go 1.12.11 are released

2019-10-18 Thread Anthony Martin

Katie Hockman  once said:
> The Go 1.13.2 release also includes a fix to the compiler that prevents
> improper access to negative slice indexes in rare cases. Affected code, in
> which the compiler can prove that the index is zero or negative, would have
> resulted in a panic in Go 1.12.11, but could have led to arbitrary memory
> read and writes in Go 1.13 and Go 1.13.1. This is Go issue
> golang.org/issue/34802.

Well that's not good. Maybe next time you should lead with the arbitrary
memory r/w instead of the comparatively minor nil-deref panic. I almost
missed it while skimming the end.

Cheers,
  Anthony

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20191018235835.GA118207%40alice.

[go-nuts] Re: mutual TLS authentication (sometimes)

2019-11-20 Thread Anthony Martin

Matthew Zimmerman  once said:
> I've also thought about authenticating on a different domain name
> auth.service then redirecting to data.service or something like that where
> the cookie would be issued to the *.service domain, however that's still
> one tls.Config and using SNI with tls.Config.GetCertificate() and I don't
> know of a way to change the tls.Config.ClientAuth for a server based upon
> the SNI.
> 
> Any ideas?

% go doc crypto/tls Config.GetConfigForClient
package tls // import "crypto/tls"

type Config struct {
// GetConfigForClient, if not nil, is called after a ClientHello is received
// from a client. It may return a non-nil Config in order to change the 
Config
// that will be used to handle this connection. If the returned Config is 
nil,
// the original Config will be used. The Config returned by this callback 
may
// not be subsequently modified.
//
// If GetConfigForClient is nil, the Config passed to Server() will be used 
for
// all connections.
//
// Uniquely for the fields in the returned Config, session ticket keys will 
be
// duplicated from the original Config if not set. Specifically, if
// SetSessionTicketKeys was called on the original config but not on the
// returned config then the ticket keys from the original config will be 
copied
// into the new config before use. Otherwise, if SessionTicketKey was set in
// the original config but not in the returned config then it will be copied
// into the returned config before use. If neither of those cases applies 
then
// the key material from the returned config will be used for session 
tickets.
GetConfigForClient func(*ClientHelloInfo) (*Config, error)

// ... other fields elided ...
}
%

Cheers,
  Anthony

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20191120091723.GA87289%40alice.

Re: [go-nuts] Weird slice of struct

2019-12-04 Thread Martin Schnabel





On 04.12.19 22:40, cstige...@gmail.com wrote:

Hello Golang nuts group.

I've tested golang's slice and got a weird result.

Anyone can explain it?



the variable ss in the for range loop is one and the same variable, with 
a different value of AA for each iteration. it has only one address.
after the for loop is done the variable has the value of the last 
iteration. you can declare a new variable within the block scope that 
changes between iterations:


https://play.golang.org/p/UMsez9sX9xO

hope that helps

--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d2a1c349-0b4c-9e4f-efbe-e19ed8c4f473%40mb0.org.

Re: [go-nuts] runtime: split stack overflow

2016-08-26 Thread martin . strenge

Hi,

It took a while to understand what's going on.
 

> I'm not sure which part of the os/signal docs you are thinking of. 


I'm referring to "Go programs that use cgo or SWIG", last paragraph ("If 
the Go signal handler is invoked on a non-Go thread not running Go code 
[...]"). I couldn't get any information about the crash in C from the Go 
signal handler. It remained silent and just quitted the program.

Crashes in Go code will work regardless of whether they are running on 

threads started by C or not.  So I assume you are talking about 
> crashes in C.  How do you want to handle those crashes?  Do you just 
> want to try to dump the stack?  How do you want to handle other C 
> threads when one C thread crashes? 
>

Yes, I meant crashes in C. I want to create a crash dump file and dump all 
C threads and Go routines. 

I do agree that your code should work in principle, and I'm not sure 
> why it doesn't. 
>
> If all you wan to do is handle SIGSEGV when it occurs in a C thread, 
> it may work to call signal.Notify(c, syscall.SIGSEGV).  The channel 
> will receive a signal wen a SIGSEGV occurs in C code.  At that point 
> it's not safe to continue, but it is safe to take whatever action you 
> like to dump C threads.  I'm not sure this will work, because it 
> depends on what happens when the SIGSEGV signal handler returns to the 
> C code that triggered the SIGSEGV. 
>

The reason for the morestack call is, that sigtramp is not called in my 
code example. The sa_tramp seems to be overwritten in my call to 
sigaction(int,struct sigaction*,struct sigaction*) and I cannot retrieve 
the original trampoline function via __sigaction(int, struct __sigaction*, 
struct sigaction*), to call it in my handler. Calling it directly would 
probably not work anyway, as sigtrampgo already calls sigreturn, but I want 
to be able to do calculations in the C handler if the Go handler has 
returned. So, I'm quite stuck here. Do you have any ideas?

I will open another thread to discuss the "correct way" to create a crash 
dump file for Go and C, and discuss my experiments. I'll leave this thread 
for the signal handler replacement on Darwin.

Thanks!
Martin

-- 
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] runtime: split stack overflow

2016-08-26 Thread martin . strenge


>
> Interesting.  Maybe we need to change this line in setsig in 
> runtime/os_darwin.go 
> *(*uintptr)(unsafe.Pointer(&sa.__sigaction_u)) = fn 
> to be 
> *(*uintptr)(unsafe.Pointer(&sa.__sigaction_u)) = 
> unsafe.Pointer(funcPC(sigtramp))  
>

That's not possible, the signatures of sa_tramp and sa_sigaction do not 
match:

/* union for signal handlers */ 
union __sigaction_u { 
void (*__sa_handler)(int);
void (*__sa_sigaction)(int, struct __siginfo *, void *);
}; 

/* Signal vector template for Kernel user boundary */
struct __sigaction {
union __sigaction_u __sigaction_u; /* signal handler */ 
void (*sa_tramp)(void *, int, int, siginfo_t *, void *);
sigset_t sa_mask; /* signal mask to apply */
int sa_flags; /* see signal options below */
}; 

Martin 

-- 
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] runtime: split stack overflow

2016-08-29 Thread martin . strenge


>
> OK, then perhaps we need setsig in os_darwin.go to set 
> the sigaction field to a new function, written in assembler, like 
> sigtramp, but taking just the sigaction arguments.  


Could you please explain, why it is necessary to use sa_tramp with a custom 
function instead of using the default one and do it like in Linux?
 

> And presumably not 
> calling sigreturn. 
>

... and save all registers in plan9 sigtramp functions.

I'll open an issue.

Thanks,
Martin

-- 
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] runtime: split stack overflow

2016-08-29 Thread martin . strenge


>
> I'm only talking about changing Darwin. 
>

Sorry, I meant pushing the gcc callee-saved registers in the assembly 
sigtramp functions (for example in sys_darwin_amd64.s) as it is done in 
crosscall2. I ran into the issue, that the content in the rbx register was 
overwritten by the sigfwdgo() function as plan9 does not have the same 
register saving rules.

Martin

-- 
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] Creating a crash dump file with Go and C stack traces

2016-08-30 Thread martin . strenge

Hi,

I have a Go executable that uses a shared C library which spawns it own 
threads. In case of a crash (in Go or C code), I want to dump all 
stacktraces of all C threads and Go routines into a crash dump file. Go 
does not handle signals in non-Go threads executing non-Go code, so I have 
to install a custom C signal handler to handle those cases. And as Go does 
not invoke a preinstalled C handler in case of crashes in Go code, the C 
handler has to be registered after the Go handler.

After some experiments - restricted to Linux amd64 - I got it working 
somehow (https://gist.github.com/trxa/302c5dbe9055ef287da9139e68d0a93e). 
But it feels a bit hacky with some drawbacks and I wonder if somebody can 
propose a better solution or improvements.


How it basically works:

The Go handlers are stored when the C handler gets installed. 
If invoked, for example by a SIGSEGV, the handler opens a file and writes 
the stack trace of the current thread into that file.
Then, it signals all other threads to dump their stack into the file too.
After all threads are dumped, the IP of the failing instruction is saved 
and the Go handler is invoked by calling it directly to keep the ucontext 
of the crash.
After the Go handler has returned, it is checked whether the IP of the 
uc_mcontext has been changed by Go.
If it is changed, the IP points to runtime.sigpanic which triggers a panic 
and dumps the Go routine stacks to STDERR. 
If it is not changed, the crash was in non-Go code on a non-Go thread and 
Go does not handle the crash. In that case, the IP register in uc_mcontext 
is set to the function pointer of an exposed Cgo function which calls 
panic() to dump the stack to STDERR.
Before returning from the C handler, the STDERR file descriptor is replaced 
by the crash dump file descriptor, so that Go panics into the file. (The Go 
handlers should probably be restored before returning, if Go still wants to 
backtrace the threads via SIGQUIT itself.)
After the C handler has returned, runtime.sigaction or the cgo function is 
executed and does not return. 


Here are the disadvantages and things to watch out, which makes the 
solution a bit creepy:

1. signal.Notify has to be called for all signals you want to handle for C 
crashes, although they are not handled in Go. Otherwise the Go handler does 
not return in the "non-Go-code/thread" case, but creates a core dump.

2. Setting the IP to a cgo function to be executed when the handler 
returns, makes the program panicing synchronously, as with 
runtime.sigpanic, but is probably not async-signal-safe, for example if it 
has to request more stack.
A workaround would be to panic in Go, if the signal is read from the notify 
channel. In addition, the C handler must not return to avoid reexecution of 
the faulting instruction. This can be done by putting the thread to sleep. 
Doing this is probably even more platform independent, but that way, a 
synchronous signal from C is handled as an asynchronous one and you don't 
have a chance to distinguish it in Go by the information you get (in case 
you only want to dump and continue for asynchronous signals).

3. Cloning the STDERR file descriptor to point to a file feels also a bit 
fragile compared to directly writing to it. Another thread might write to 
it. The fd cannot be closed (except maybe in a global destructor) and the 
OS would have to flush the buffers correctly (or I have to use synchronous 
write mode, which slows writing the dump down tremendously).

4. There are duplicate stack traces, and it's not always obvious to match a 
thread stack trace to the running go routine.

5. It would be desirable to have the stack trace of the failing instruction 
redundantly in the crash file and in the log file, but with this solution 
it is only possible for C frames and the first Go frame on top of the 
thread, at least if you use a common unwinder library.

There might be more.


>From my point of view, a better solution would be, when Go has an option 
(maybe via GOTRACEBACK env var) to trace C threads as well, for example by 
using the cgo traceback functions introduced in Go 1.7. Also setting a file 
descriptor/handle as target for a dump should be allowed (maybe in addition 
to the dump on STDERR). In addition to the cgo traceback functions, there 
might be one or more functions for gathering additional information, which 
will be printed in the crash dump. A use case for that would be a list of 
loaded modules/libraries or environment variables.
I can imagine that it's easier said than done, but that's what I would 
prefer.


Thanks for your opinions!
Martin

-- 
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] cgo and OSX "main thread"

2016-09-09 Thread Martin Bertschler

There is also a great wiki article on how to execute functions on the main 
thread from multiple goroutines. It helped me a lot when I did some GUI 
development experiments.
https://github.com/golang/go/wiki/LockOSThread

-- 
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] Idea for versioning in the new Go package manager.

2016-10-26 Thread Martin Bertschler

Hello Gophers!

Yesterday I attended a tech meetup and was introduced to the Elm language 
<http://elm-lang.org/>. The one thing that really stuck with me was how the 
Elm package manager handles semantic versioning for the package developers. 
As soon as things are added to the packages API, the minor version of the 
package is automatically bumped, and if the existing API of the package is 
changed, the major version is bumped.

I think this could be a great idea for the new package manager, since the 
whole Go ecosystem values stability and great tooling a lot. Some benefits 
of this feature that I can imagine:

   - Not having to think about the next version number, especially in small 
   projects where I just want to publish some new code. Let the tool just 
   choose one for you.
   - No accidental changes the public API during development, the tool 
   would point out the API changes to you before publishing. If you didn't 
   intend the change you could fix it.
   - Always correct usage of semantic versioning, that the whole ecosystem 
   can depend on. This could enable automatic updates to always the newest 
   patch version. 

Implementing it should not be hard because we already have things like 
https://golang.org/cmd/api/.

The full specification on how Elm handles that can be found here: 
https://github.com/elm-lang/elm-package. 

What are your thoughts on this matter?

Best,
Martin

-- 
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] Oxymoron: language spec: ``untyped boolean value''

2016-11-02 Thread Martin Steffen

Hi, in the language spec, e.g. in connection with ``type assertions'' and 
``special forms'', like 

v, ok = x.(T)

it's stated that it yield (in ok) an additional value which is both  untyped 
and boolean
(an ``untyped boolean value'').

How should one interpret that? If ok behaves like a boolean, why is it 
considered as untyped?

Martin


-- 
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] Oxymoron: language spec: ``untyped boolean value''

2016-11-02 Thread Martin Steffen

Thanks for all the replies. Basically it is  more like a puzzlement over 
choice of terminology,
not so much what the meaning resp. purpose of the ``special form'' of 
assignments (with ``ok'') is.

So calling the use of "ok"  an ``untyped boolean'' it seems a bit 
Go-specific (and/or go-implementation-centric)
terminology. Indeed the section about "constants" (mentioned in an earlier 
reply) sheds some light,  in 
that it's a special case of how the Go specification speaks about typing 
issues surrounding literals.

But still, the sentence in that section of the language specification there 
spelling it out as

"An untyped constant has a default type" (*)

sounds ``oxymoronic'' to the unsuspecting: something  is called "untyped"
_but_  at the same time ``has a type''. Of course it's the official
specification, so it is how it formulated as it is and one can live with 
it.  but still a
bit strange manner of speaking. 

PS: oxymoron means not being a self-contradictory statement as such, but a 
formulation that "appears to be contradictory''  
which upon first reading applies to the formulation (*) at least for me :-)

On Wednesday, November 2, 2016 at 12:04:39 PM UTC+1, Pietro Gagliardi 
(andlabs) wrote:
>
> It means there is no specific type name, but the resultant type must 
> either be bool or convertible to bool:
>
> type A bool
> var n int
> var ok A
> n, ok = x.(int)
>
> Using bool here is not common, but you see this with int and float, etc. 
> Untyped constants is one of the most prominent Go features.
>
> On Nov 2, 2016, at 4:09 AM, Martin Steffen  > wrote:
>
> Hi, in the language spec, e.g. in connection with ``type assertions'' and 
> ``special forms'', like 
>
> v, ok = x.(T)
>
> it's stated that it yield (in ok) an additional value which is both  untyped 
> and boolean
> (an ``untyped boolean value'').
>
> How should one interpret that? If ok behaves like a boolean, why is it 
> considered as untyped?
>
> Martin
>
>
>
> -- 
> 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] Oxymoron: language spec: ``untyped boolean value''

2016-11-02 Thread Martin Steffen

Thanks.

I may have been imprecise using ``implementation specific''. I did not mean 
it in the 
C-like manner that the ``meaning''  of some (typed) value depends on the 
platform (length of some words) or the choice of the compiler
writer for a given platform. 

I meant more: the _terminology_ of being untyped may reflect an internal 
treatment of how the go compiler treats
those things: inside the go-compiler, the ``static phase''/type 
checker/type inferencer may treat 
for instance literals as being in  one of 
two states: one which is called "untyped", where said flexibility (or 
polymorphism if you wish) is  possible, and one where this
is not immediatly possible (without conversion). These to states are called 
"untyped" and "typed" in the compiler. In that way, I meant "implementation 
specific". 

Fair enough. I also understand why this flexibility in typing is very 
desirable, useful etc. 

The only thing I maintain is that, if one would ask me (not that it's  
generally recommended), 
I'd had not chosen to call  the phenomenon of  this form of flexible or 
polymorphiic handling
of literals  in a typed language as "untypedness"  
(even if that's accepted terminology in the Go community). 

For me (with my background), I would have called 5 to be "polymorphically 
typed" in that it can carry more
than one type (namely as you said, all types which are ``compatible'' with 
int without conversion).
.

Likewise I maintain that while internally consistent and meaninfull 
thereby, 
purely from the point of view from usage of English.
a sentence  from 

https://golang.org/blog/constants. 

like 
  "an untyped constant has a default type" 

is confusing, especially for beginners: I would simply not call something 
which has a (default)  type "untyped"
(even if the mechanism justifying the distinction is useful). Again one can 
say, the compiler treats it as not having a 
final type yet, but when the time comes for decision, then a type will be 
chosen and then checked to
be compatible with bool. All fine, but reads  confusing for outsiders (the 
mechanism itself is clearer than the terminology),

But I get the _idea_ behind the notion of being "untyped", which is the 
important part, thanks for the discussion. 

But it's a really a terminology question. I only can't imagine explaining 
it to students: ``remember, true is untyped, 
but it can only be used as if it had  type bool''.  

On Wednesday, November 2, 2016 at 2:34:56 PM UTC+1, Ian Lance Taylor wrote:
>
> On Wed, Nov 2, 2016 at 4:27 AM, Martin Steffen  > wrote: 
> > 
> > So calling the use of "ok"  an ``untyped boolean'' it seems a bit 
> > Go-specific (and/or go-implementation-centric) 
> > terminology. Indeed the section about "constants" (mentioned in an 
> earlier 
> > reply) sheds some light,  in 
> > that it's a special case of how the Go specification speaks about typing 
> > issues surrounding literals. 
>
> It's Go-specific, but in the context of Go it's meaningful.  It's not 
> implementation-centric.  Remember that in Go if you write 
>
> type B1 bool 
> type B2 bool 
> var v1 B1 
> var v2 B2 
>
> then it is a type error to write 
>
> v1 = v2 
>
> So an untyped boolean, like an untyped int, etc., is a value that can 
> be assigned to any type whose underlying type is bool without 
> requiring a type conversion. 
>
> It may help to read https://golang.org/blog/constants. 
>
> 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] Shuffle Items in a Slice

2016-06-24 Thread Martin Geisler

On Fri, Jun 24, 2016 at 1:05 PM, dc0d  wrote:
>
> Hi;
>
> To shuffle items in a slice I'm doing this:
>
> var res []Item
>
> //fill res logic
>
> shuffle := make(map[int]*Item)
> for k, v := range res {
>  shuffle[k] = &v
> }
> res = nil
> for _, v := range shuffle {
>  res = append(res, *v)
> }
>
> Which inserts items into a map then ranges over that map. Ranging over a map 
> in Go returns the items in random order.
>
> 1 - I thought it's a cool trick!
> 2 - Is anything bad about doing this?

While iteration over a map is said to be random, it isn't specified
exactly how "random" the iteration is. The spec says

  https://golang.org/ref/spec#RangeClause
  The iteration order over maps is not specified and is not guaranteed
to be the same from one iteration to the next.

That is, the iteration order should not to be relied upon. A simple test like

  https://play.golang.org/p/czRE3pbMzc

shows this: the keys are printed in a scrambled order. When I run this
on my machine, I get a different order every time, but on the
playground the order seems to be fixed and I get "0 5 7 1 2 3 4 6 8 9"
every time. My guess would be that an external input is used to
initialize the hash function used behind the scene -- and on the
playground that input somehow has a fixed value.

Unless you're build a toy application, my advice would be to use a
real random generator to generate indexes into the map. Use these
indexes to swap elements and permute the array as Konstantin mentioned
(https://en.wikipedia.org/wiki/Fisher–Yates_shuffle).

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

Hi Henry,

On Mon, Jun 27, 2016 at 3:55 AM, Henry  wrote:
> If you were to change the code a bit as follows 
> https://play.golang.org/p/VwtWRQBrEe , it will work as you expect.
>
> I think it is probably safer to instantiate a slice without specifying the 
> initial capacity.

Having the capacity larger than the number of used elements (the
length of the slice) is indeed the problem. However, not specifying
the capacity can also fail you. Here I changed the numbers of elements
appended slightly and print the capacity after each operation:

  https://play.golang.org/p/WBTRvgJJKW

As you can see, append will over-allocate and set the capacity of the
underlying array to 4 when we go from an empty slice to a slice with
length 3. This in turn makes the following appends to a and b share
the 4th slot in the array and appending to a will ultimately update
the value you see in b.

In your example you were "lucky" since you started with a = [1, 2] and
cap(a) = 2. When you create b, append notices that the capacity is
exhausted and *creates a new underlying array for b*. After that step,
a and b are no longer "entangled" like this and updates to one cannot
affect the other.

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

On Mon, Jun 27, 2016 at 12:34 AM, Jan Mercl <0xj...@gmail.com> wrote:
> On Mon, Jun 27, 2016 at 12:26 AM Peter Kleiweg  wrote:
>
>> I don't know what I expected, but it's weird. Don't mess with slices.
>
> Well, working as expected, considering slice backing array is possibly
> shared wrt the result of append. (Or other slice op, b/c slices _are_
> values.)
>
> However, it's easy to avoid the append sharing when/where not desirable:
> https://play.golang.org/p/oIFHamYWB-

To unpack what Jan wrote a little: when slicing, you can specify a
third integer which becomes the capacity of the new slice. So

  b := a[:len(a):len(a)]

will create a new slice b with len(b) = len(a) and cap(b) = len(a).
Without the third argument, cap(b) = cap(a). When cap(a) > len(a) you
have the situation where append(a, 123) is quick: is can just insert
the element into the underlying array without having to reallocate
anything.

So the line

  b := append(a[:len(a):len(a)], 3, 4)

does two things: it slices a to obtain a new slice with a lower than
normal capacity. Because the capacity exactly matches the length of
the new slice, trying to append to it is guaranteed to reallocate the
underlying array. So append makes a new, larger array and copies
len(a) elements into it. It then writes 3 and 4 into the new array as
well before returning a slice of the array. That slice becomes b.

>From that point onwards, a and a are no longer connected via the
underlying array.

BTW, I was about to say that you could simplify the line one step further with

  b := append(a[::len(a)], 3, 4)

but that gives a compilation error:

  prog.go:11: middle index required in 3-index slice

I wonder what the rationale is for this? It seems inconsistent to me
since the second (middle) index has a useful default (len(a)) that is
used when there are only two indexes used.

-- 
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] Re: Shuffle Items in a Slice

Hi Val

On Fri, Jun 24, 2016 at 2:48 PM, Val  wrote:
> 2 implementations here :
> http://www.programming-idioms.org/idiom/10/shuffle-a-list/1564/go
>
> As for the map iteration trick, the runtime doesn't guarantee to randomize
> anything, although it often tries to, so developers don't rely on some
> specific order.

That's a nice feature and very helpful when writing tests... otherwise
you end up with a test that works fine on one version/architecture and
"suddenly" breaks later.

Randomizing the order "on purpose" is probably also done for security
reasons. Python works much the same, and some years ago, the CPython
VM began randomizing the dict (map) type. The problem was that
carefully crafted input would trigger a worst-case scenario in the
hash table used behind the scenes and suddenly make your server crawl
to a halt.

The input could be HTTP headers, for example, with carefully chosen
names: these are normally read from the client and used as keys in a
map. With the right keys, you can trigger hash collisions and make the
map allocate much more memory than you would expect with typical keys.

Having the runtime add a bit of randomness to the keys prevents this
scenario. When the randomness changes at every execution, it further
helps the developers by highlighting the nondeterministic iteration
order of the hash table.

> I've seen (in the past) some map iterations consistently not
> randomized at all. This behaviour may have evolved, but don't rely on it.

That's good advice :-)

-- 
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] Shuffle Items in a Slice

On Fri, Jun 24, 2016 at 2:54 PM, Val  wrote:
> The playground caches everything, so running multiple times the same program
> will just serve the previously generated output.

Thanks, that's good to know! Makes a lot of sense too.

> Also in the playground everything is frozen at some point in the past : the
> clock, the randomness sources, and you can't make outgoing requests to
> import randomness from the network.

I found this blog post with a lot more background information:

  https://blog.golang.org/playground

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

Hi Ian,

On Mon, Jun 27, 2016 at 8:18 PM, Ian Lance Taylor  wrote:
> On Sun, Jun 26, 2016 at 10:55 PM, Dan Kortschak
>  wrote:
>> On Mon, 2016-06-27 at 07:49 +0200, Martin Geisler wrote:
>>> BTW, I was about to say that you could simplify the line one step
>>> further with
>>>
>>>   b := append(a[::len(a)], 3, 4)
>>>
>>> but that gives a compilation error:
>>>
>>>   prog.go:11: middle index required in 3-index slice
>>>
>>> I wonder what the rationale is for this? It seems inconsistent to me
>>> since the second (middle) index has a useful default (len(a)) that is
>>> used when there are only two indexes used.
>>
>> As I remember it, during the design discussions the possibility of using
>> the shortened syntax you show above was considered, but rejected as an
>> opening to bug entry (too much semantic weight on a single repeated
>> character).
>
> Yes.  And, also, the default for the middle index is not wholly
> obvious.  Should it be len(a) or (new) cap(a)?  In your example those
> happen to have the same value, but of course in general they do not.

Hmm, that's a good point that I hadn't considered :-) I figured it
would be len(a) so that

  a[x::z] = a[x:len(a):z]

That keeps the defaults intact from normal 2-index slicing.

For the indices to be in range, you must have z >= y where y = len(a).
So maybe one could argue that the middle index y could be clamped at
z, that is, the middle index y could be set to min(z, len(a)). That
way you can have a slice with length 10 and still write

  a[2::4] = a[2:min(4, 10):4] = a[2:4:4]

where there indices are all in range.

I see how this becomes more complicated than I initially thought... is
that the kind of mess you were thinking of? :-)

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

On Fri, Jul 1, 2016 at 3:15 AM, Chad  wrote:
> No, it's actually fine. You are comparing values.
>
> A slice being a struct under the hood, for slices you would compare the
> structs (slice headers)

Yes, when you remember that a slice is a just a small struct with a
pointer and some bookkeeping information (length, capacity), then you
can compare two slices easily. So with

  a := []int{10, 20, 30}
  b := a[:]

then a == b would be fast: simply compare the pointers and the
bookkeeping information. Direct value equality between the structs
gives you the expected and correct answer.

But what about

  []int{10, 20} == []int{10, 20}

where the two slices refer to different underlying arrays? I think you
argue that this comparison should be false?

I would hope that slices from different underlying arrays could be
compared for equality based on their values, just like strings can.
Two strings (that are not slices from the same original string) can be
compared for equality just fine. I hope Go takes the shortcut when the
strings refer to the same memory and otherwise does the slower
per-byte comparison. The same could perhaps apply to slices in
general.

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

On Fri, Jul 1, 2016 at 12:48 PM, Chad  wrote:
> On Friday, July 1, 2016 at 12:11:43 PM UTC+2, Martin Geisler wrote:
>>
>> On Fri, Jul 1, 2016 at 3:15 AM, Chad  wrote:
>> > No, it's actually fine. You are comparing values.
>> >
>> > A slice being a struct under the hood, for slices you would compare the
>> > structs (slice headers)
>>
>> Yes, when you remember that a slice is a just a small struct with a
>> pointer and some bookkeeping information (length, capacity), then you
>> can compare two slices easily. So with
>>
>>   a := []int{10, 20, 30}
>>   b := a[:]
>>
>> then a == b would be fast: simply compare the pointers and the
>> bookkeeping information. Direct value equality between the structs
>> gives you the expected and correct answer.
>>
>> But what about
>>
>>   []int{10, 20} == []int{10, 20}
>>
>> where the two slices refer to different underlying arrays? I think you
>> argue that this comparison should be false?
>
>
> Yes. And it is. A slice is not an array. Or an open-ended array.

Right, a slice is just view into an array :-)

I was hinting at the (lack of) symmetry with how strings work.

Two strings that share no underlying memory can compare equal, so I
think it would be reasonable if equality between slices followed the
same principle. Put differently, strings are "magic" and don't follow
normal rules for comparison, in particular, they don't use direct
value comparison. Here I'm assuming that

  https://golang.org/pkg/reflect/#StringHeader

shows us how strings are implemented: a small struct with a pointer
and a length. If string comparison were to use value semantics, a and
b could not compare equal in this little example

  a := "hello world"
  b := make([]byte, len(a))
  os.Stdin.Read(b)

since the pointer in a would differ from the pointer in b. Yet a == b
is true when you enter "hello world" :-) So we see the magic slip
through the cracks...

Given that, one could argue that it would be consistent to have
[]int{1} == []int{1} be true -- it's just yet another exception to the
rule that things are compared by value. It's not super pretty, though,
but I my opinion the illusion of prettyness has already been broken
with how some builtin types get special treatment here and there.

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