[go-nuts] [ANN] Renderview v0.1.0 with go mod, Gio, and Fyne support

[howardcshaw]

Four years ago I posted Renderview, a simple GUI wrapper that lets you take 
any image generation function in your code and turn it into an interactive 
GUI program with panning, optional zooming, and depending on backend 
choice, parameter editing.

https://github.com/TheGrum/renderview

I have updated it to support go modules, and added support for the recently 
appearing Gio and Fyne GUI toolkits. They are both operational, if a bit 
oddly. I tested Gio on Windows yesterday when I had a chance, and it did 
build, but for some reason, did not respond to mouse movements, only mouse 
scrolling, and I have not resolved that issue yet.

So now, in addition to serving as a quick and dirty tool for exercising 
your image generating or algorithm visualizing code, the code-base itself 
serves as a comparative implementation of the same task in Shiny,  go-gtk, 
GoTK3, Gio, and Fyne.

I did attempt implementations in a few other environments with no success - 
I need some path to go from an image.Image to a displayed image onscreen, 
and could not find a mechanism to do this in a few of the libraries. 
(Granted, I didn't find a way to do it in go-gtk or GoTK3 either - I brute 
forced it since they at least gave access to the memory backing an onscreen 
image. So the source also provides an example of converting from an 
image.RGBA and an image.NRGBA to the internal format of GTK images.)

I still need to go back through and fix-up the interactions to remove data 
races, but they don't seem to have affected the performance or behavior so 
far.

Howard C. Shaw III

-- 
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/0be68b05-88da-4b8d-a186-aec9099f8530%40googlegroups.com.

Re: [go-nuts] help with using %q in fmt

[Ian Lance Taylor]

On Fri, Feb 21, 2020 at 4:35 PM 'simon place' via golang-nuts
 wrote:
>
> basically i want to save a file name in a file (with some url styling for 
> human readability);
>
> https://play.golang.org/p/sWYbyU7nuSo
>
> which works, but not with a space in the name;
>
> https://play.golang.org/p/sswqBRL8dZW
>
> it needs to be quoted, so i figure '%q' is for this;
>
>
>> %q a double-quoted string safely escaped with Go syntax
>
>
>
> but it doesn't work;
>
> https://play.golang.org/p/2QT-2UH4TsZ
>
> how can the format not match, when its the same one?
>
> nothing else a can think of, like quotes in the format itself, does either, 
> so i'm stuck.

In your program the type has a scan method that ignores the rune
parameter.  So the %q passed to fmt.Fscanf is irrelevant.  What
matters is the format character used in the Scan method, which is %v.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUp49gTaUan%2B6zm9OVmNNEXW604q48kMyOsQRUmt4oJow%40mail.gmail.com.

[go-nuts] help with using %q in fmt

['simon place' via golang-nuts]

basically i want to save a file name in a file (with some url styling for 
human readability);

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

which works, but not with a space in the name;

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

it needs to be quoted, so i figure '%q' is for this;


%q  a double-quoted string safely escaped with Go syntax
>
>

but it doesn't work;

https://play.golang.org/p/2QT-2UH4TsZ

how can the format not match, when its the same one? 

nothing else a can think of, like quotes in the format itself, does either, 
so i'm stuck.


-- 
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/cc663cb7-8282-4ede-8be2-3fcf15b35799%40googlegroups.com.

Re: [go-nuts] Preserving extra properties using JSON unmarshal / marshal?

['Eric Johnson' via golang-nuts]

Understand all that. It doesn't help.

Asking the question a different way, as concrete code always clarifies. For 
something like the following snippet of code:

const testJSON = `{
"first_name": "first",
"last_name": "last",
"favorite_color": "orange",
"age": 92
}`

func TestUnmarshalling(t *testing.T) {
var res struct {
FirstName string `json:"first_name"`
LastName  string `json:"last_name"`
}
err := json.Unmarshal([]byte(testJSON), )
assert.NoError(t, err)
out, err := json.MarshalIndent(, "", "\t")
assert.NoError(t, err)
assert.Equal(t, testJSON, string(out))
}

Is there anything I can do to the "res" struct" to preserve the 
"favorite_color" and "age" properties from the original JSON, so that the 
final assert.Equal() passes? Ideally, as I indicated in the original post, 
it would be something along the lines of an additional struct member that 
acts as the catch-all for any values not found for the struct. (hence the 
line "Extras map[string]interface{} `json:",extra" that I put in my 
example.)

Stepping through the standard library, it seems pretty clear that the 
standard library simply discards JSON properties that it doesn't map to 
fields. I think the crucial lines 
 (decode.go, 753-769) 
indicate that if a field is not found, no target value ("subv") is set, and 
then the resulting data is discarded.

Since the standard library doesn't support it, I'm wondering if there are 
any other reliable JSON encode / decode libraries out there that might?

I have three options, that I can tell:

   - Find an alternate library that supports something like this (hence the 
   post)
   - Use the standard library by implementing the Unmarshaler interface on 
   the struct, use normal unmarshaling for the known fields, then also 
   unmarshal as a map[string]interface{}, remove all the fields that I don't 
   want, and store the results in the "Extra" field myself. This will result 
   in double-parsing each struct and a lot of extra boilerplate code. Then 
   also need to do appropriate somethings to implement Marshal as well.
   - Fork the standard library JSON package, add the support myself, and 
   submit it back as a possible enhancement(!).
   
Using the standard library as is seems like a bad option, given the extra 
boilerplate that would be required for each struct. I'm hoping someone has 
already made an implementation that does this!

Eric.

On Friday, February 21, 2020 at 1:41:20 PM UTC-8, Chris Burkert wrote:
>
> Take a Look at 
> https://blog.golang.org/json-and-go:
>
> The json package uses map[string]interface{} and []interface{}values to 
> store arbitrary JSON objects and arrays; it will happily unmarshal any 
> valid JSON blob into a plain interface{} value. The default concrete Go 
> types are:
>
>- bool for JSON booleans,
>
>
>- float64 for JSON numbers,
>
>
>- string for JSON strings, and
>
>
>- nil for JSON null.
>
>
> Does this help?
>
> 'Eric Johnson' via golang-nuts > 
> schrieb am Fr. 21. Feb. 2020 um 19:00:
>
>> If I've got a structure like this:
>>
>> type jsonData struct {
>> FirstName string `json:"first_name"`
>> LastName  string `json:"last_name"`
>> }
>>
>> I can marshal / unmarshal JSON as:
>> {
>>   "first_name": "first",
>>   "last_name": "last"
>> }
>>
>> What if my input JSON is this:
>> {
>>   "first_name": "first",
>>   "last_name": "last",
>>   "favorite_color": "orange",
>>   "age": 92
>> }
>>
>> Is there an existing library to have a structure that's something like 
>> this:
>>
>> type jsonData struct {
>> FirstName string `json:"first_name"`
>> LastName  string `json:"last_name"`
>> Extrasmap[string]interface{} `json:",extras"`
>> }
>>
>> Such that a JSON unmarshal and marshal will preserve the data of the 
>> original JSON?
>>
>> I think I can probably make something work with the standard library, 
>> except that it will require extra marshaling / unmarshaling steps that will 
>> be annoying to reproduce for each structure that needs to capture extra 
>> data. So I'm hoping there's a better solution?
>>
>> Eric
>>
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/630827e2-8277-4231-9ab1-31881198a386%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 

Re: [go-nuts] Re: asm/amd64: is it safe to use NO_LOCAL_POINTERS in this scenario?

[Ian Lance Taylor]

On Fri, Feb 21, 2020 at 7:38 AM Iskander Sharipov  wrote:
>
> If the original question is not clear, I can re-phrase it like this: what 
> happens if a function marked with NO_LOCAL_POINTERS contains heap pointers on 
> its frame?
>
> My understanding is that these pointers will not count as something that is a 
> pointer and if there will be no other pointers to that data, it will be 
> claimed by GC. But if there are other pointers that keep that data reachable, 
> what are other consequences that can happen?

When the code calls gofunc1, it may find that there is not enough
stack space, which will cause the runtime to copy the stack to a new
location.  When copying the stack the runtime will examine all
pointers on the stack, and, if they point to locations elsewhere on
the stack, adjust them to point to the new stack location.  So if the
pointers passed to your function happen to point to locations on the
stack, and you use NO_LOCAL_POINTERS, then they will not be adjusted,
and your program will have dangling pointers leading to memory
corruption or other problems.

Ian


> On Friday, February 21, 2020 at 4:12:01 PM UTC+1, Iskander Sharipov wrote:
>>
>> Hi all.
>>
>> I have an asm function that is defined like this:
>>
>> // func f(x *T1, y *T2)
>> TEXT ·f(SB), 0, $32-16
>>   NO_LOCAL_POINTERS
>>   // It does call a few Go functions, this is why
>>   // I need some frame space, to put their arguments there.
>>   MOVQ , 0(SP)
>>   MOVQ , 8(SP)
>>   CALL ·gofunc1(SB)
>>   MOVQ 16(SP), AX // Save result
>>   // ...more such calls, args take up to 32 bytes.
>>   RET
>>
>> It has 2 pointer arguments and frame with size=32 bytes.
>> All that frame space is only used for function call arguments,
>> asm function itself does not spill data to the stack.
>>
>> Arguments to Go functions can contain pointers.
>> All of them come from the 2 f() arguments (x and y).
>>
>> So the question is: how safe it's to use NO_LOCAL_POINTERS here?
>>
>> If NO_LOCAL_POINTERS is removed, I can't do a CALL, since runtime needs a 
>> stack map.
>>
>> Note that the asm code is simplified, but all statements given above still 
>> hold: stack frame only
>> holds pointers that are reachable via f() arguments and it's only used to 
>> pass arguments to (normal) Go functions.
>>
>> This sentence from the asm docs adds more confusion:
>>>
>>> Because stack resizing is implemented by moving the stack, the stack 
>>> pointer may change during any function call: even pointers to stack data 
>>> must not be kept in local variables.
>>
>>
>> I'm not sure what it means by "local variables". When doing asm, you can 
>> only imagine local variables as stack-saved values.
>>
>> I found this part of code that gives some insights, but I can't make a 
>> reliable conclusion about my case out of that.
>>
>> Thank you in advance. :)
>
> --
> 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/83b51508-0e2b-4d5b-80a7-97a3931ec5e4%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/CAOyqgcWQQGGdKx3u%2BU1pW%3DSoGBX%2B595g_6jCuKtQ_bhbD6vGNQ%40mail.gmail.com.

Re: [go-nuts] Preserving extra properties using JSON unmarshal / marshal?

[Chris Burkert]

Take a Look at
https://blog.golang.org/json-and-go:

The json package uses map[string]interface{} and []interface{}values to
store arbitrary JSON objects and arrays; it will happily unmarshal any
valid JSON blob into a plain interface{} value. The default concrete Go
types are:

   - bool for JSON booleans,


   - float64 for JSON numbers,


   - string for JSON strings, and


   - nil for JSON null.


Does this help?

'Eric Johnson' via golang-nuts  schrieb am
Fr. 21. Feb. 2020 um 19:00:

> If I've got a structure like this:
>
> type jsonData struct {
> FirstName string `json:"first_name"`
> LastName  string `json:"last_name"`
> }
>
> I can marshal / unmarshal JSON as:
> {
>   "first_name": "first",
>   "last_name": "last"
> }
>
> What if my input JSON is this:
> {
>   "first_name": "first",
>   "last_name": "last",
>   "favorite_color": "orange",
>   "age": 92
> }
>
> Is there an existing library to have a structure that's something like
> this:
>
> type jsonData struct {
> FirstName string `json:"first_name"`
> LastName  string `json:"last_name"`
> Extrasmap[string]interface{} `json:",extras"`
> }
>
> Such that a JSON unmarshal and marshal will preserve the data of the
> original JSON?
>
> I think I can probably make something work with the standard library,
> except that it will require extra marshaling / unmarshaling steps that will
> be annoying to reproduce for each structure that needs to capture extra
> data. So I'm hoping there's a better solution?
>
> Eric
>
>
> --
> 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/630827e2-8277-4231-9ab1-31881198a386%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/CALWqRZqikwfQ9RJNUWtt3YKSkFcfFYFn9LadOzFEq7Gsfga7cA%40mail.gmail.com.

Re: [go-nuts] Bound checks elimination hint.

[Robert Engels]

Curious, in the cases of where you were able to eliminate the bounds checks 
what was the performance difference in the overall process?

I would be very surprised, even in matrix type loops, that this makes an 
appreciable difference given modern cpu branch predictors. 

I think a better area of attack would be adding cpu vector operations support. 

> On Feb 21, 2020, at 1:20 PM, Bruno Albuquerque  wrote:
> 
> 
> [now sending to the entire group]
> 
> And the plot thickens.
> 
> https://play.golang.org/p/P2JPI42YJa8
> 
> Basically, this is a very simple loop iterated with different step increments.
> 
> For step increments of 1, 2, 4, 5 and 10, there are no bound checks.
> 
> For step increments of 3, 6, 7, 8 and 9 there are bound checks.
> 
> So, in this simplified case, if the step divides the length evenly, then 
> there are no bound checks. If it does not, then bound checks are inserted.
> 
> This seems to be an unnecessary check as the actual relevant thing is to make 
> sure that the index is not equal to or greater than the slice length. Either 
> that or I am missing something
> 
>> On Fri, Feb 21, 2020 at 10:24 AM Bruno Albuquerque  wrote:
>> This is interesting. If I simplify the loop to something like this:
>> 
>> nrgbaData := make([]byte, len(rgbData)+(len(rgbData)/3))
>> 
>> _ = nrgbaData[len(rgbData)]
>> 
>> for i := 0; i < len(rgbData); i++ {
>> nrgbaData[i] = rgbData[i]
>> }
>> 
>> then the bounds check at the line inside the for loop is removed.
>> 
>> But if I change it to this:
>> 
>> nrgbaData := make([]byte, len(rgbData)+(len(rgbData)/3))
>> 
>> _ = nrgbaData[len(rgbData)]
>> 
>> for i := 0; i < len(rgbData); i += 3 {
>> nrgbaData[i] = rgbData[i]
>> }
>> 
>> then the bounds check is not eliminated.
>> 
>> Considering it is still guaranteed that "i" inside the loop will never be 
>> equal to or greater than len(rgbData), I do not understand why the bounds 
>> check is now required.
>> 
>> Any ideas?
>> 
>> 
>>> On Fri, Feb 21, 2020 at 10:07 AM Bruno Albuquerque  wrote:
>>> Nope. Bound checks are still there. I am puzzled by this one.
>>> 
>>> 
 On Fri, Feb 21, 2020 at 9:34 AM Sebastien Binet  wrote:
 
 
> On Fri, Feb 21, 2020 at 5:36 PM Bruno Albuquerque  wrote:
> I wrote some simple code to convert a RGB24 image represented as a []byte 
> to a NRGBA image (also as a []byte), like so:
> 
> https://play.golang.org/p/Y7ICg7t4_nd
> 
> Unfortunately, the performance is lacking here and I am trying to improve 
> it. The first low hanging fruit seems to be taking advantage of BCE:
> 
> $go test -bench .
> goos: linux
> goarch: amd64
> BenchmarkNRGBA-8   484   2636344 ns/op
> 
> $ go test -gcflags="-B" -bench .
> goos: linux
> goarch: amd64
> BenchmarkNRGBA-8   855   1654882 ns/op
> 
> Unfortunately, I could not find an incantation that would remove the 
> bound checks. My naive attempt was to just do
> 
> _ = nrgbaData[len(nrgbaData)-1]
> 
> at around line 7 in the program above but this did not help and added one 
> extra bound check.
> 
> Funny enough, if I do 
> 
> _ = nrgbaData[len(nrgbaData)]
> 
> all the bound checks seem to be eliminated but, obviously, the program 
> panics at this line.
 what about:
_ = nrgbaData[:len(nrgbaData)]
 
 does this also remove the bound checks?
 
 -s
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAEd86Tw_1qLzK4HEw9rA06Wqnrtzs6CuzMT6VAK3Y40Bs7yPBw%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/A74C610B-37C5-4658-A9F0-73742D9B5B93%40ix.netcom.com.

Re: [go-nuts] setting up a hardened https server in go 1.13

[Kevin Chadwick]

>But without a list of vulnerabilities, this sounds to me like FUD.

Fud implies intentional deceit, not the case.

Now that you have made me think about it then if security is your priority over 
performance then OpenHttpd certainly provides better protection of the TLS key 
and various server functions and leverages better OS protection at the cost of 
a vulnerability putting the OS at greater risk but an exploit in net/http would 
more likely give almost immediate ownership of the whole server but less likely 
the OS.

Re-acting to vulnerabilities isn't security, avoiding their affect is. Using 
golang especially where great care cannot be afforded is one such way. 

Personally I wish net/http used more than one user and processes but it is 
still fantastic.

-- 
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/FAD9D76F-CB4B-4815-AA52-2D68BBBE1659%40gmail.com.

Re: [go-nuts] Bound checks elimination hint.

[Bruno Albuquerque]

[now sending to the entire group]

And the plot thickens.

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

Basically, this is a very simple loop iterated with different step
increments.

For step increments of 1, 2, 4, 5 and 10, there are no bound checks.

For step increments of 3, 6, 7, 8 and 9 there are bound checks.

So, in this simplified case, if the step divides the length evenly, then
there are no bound checks. If it does not, then bound checks are inserted.

This seems to be an unnecessary check as the actual relevant thing is to
make sure that the index is not equal to or greater than the slice length.
Either that or I am missing something

On Fri, Feb 21, 2020 at 10:24 AM Bruno Albuquerque  wrote:

> This is interesting. If I simplify the loop to something like this:
>
> nrgbaData := make([]byte, len(rgbData)+(len(rgbData)/3))
>
> _ = nrgbaData[len(rgbData)]
>
> for i := 0; i < len(rgbData); i++ {
> nrgbaData[i] = rgbData[i]
> }
>
> then the bounds check at the line inside the for loop is removed.
>
> But if I change it to this:
>
> nrgbaData := make([]byte, len(rgbData)+(len(rgbData)/3))
>
> _ = nrgbaData[len(rgbData)]
>
> for i := 0; i < len(rgbData); i += 3 {
> nrgbaData[i] = rgbData[i]
> }
>
> then the bounds check is not eliminated.
>
> Considering it is still guaranteed that "i" inside the loop will never be
> equal to or greater than len(rgbData), I do not understand why the bounds
> check is now required.
>
> Any ideas?
>
>
> On Fri, Feb 21, 2020 at 10:07 AM Bruno Albuquerque  wrote:
>
>> Nope. Bound checks are still there. I am puzzled by this one.
>>
>>
>> On Fri, Feb 21, 2020 at 9:34 AM Sebastien Binet  wrote:
>>
>>>
>>>
>>> On Fri, Feb 21, 2020 at 5:36 PM Bruno Albuquerque  wrote:
>>>
 I wrote some simple code to convert a RGB24 image represented as a
 []byte to a NRGBA image (also as a []byte), like so:

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

 Unfortunately, the performance is lacking here and I am trying to
 improve it. The first low hanging fruit seems to be taking advantage of 
 BCE:

 $go test -bench .
 goos: linux
 goarch: amd64
 BenchmarkNRGBA-8   484   2636344 ns/op

 $ go test -gcflags="-B" -bench .
 goos: linux
 goarch: amd64
 BenchmarkNRGBA-8   855   1654882 ns/op

 Unfortunately, I could not find an incantation that would remove the
 bound checks. My naive attempt was to just do

 _ = nrgbaData[len(nrgbaData)-1]

 at around line 7 in the program above but this did not help and added
 one extra bound check.

 Funny enough, if I do

 _ = nrgbaData[len(nrgbaData)]

 all the bound checks seem to be eliminated but, obviously, the program
 panics at this line.

>>> what about:
>>>_ = nrgbaData[:len(nrgbaData)]
>>>
>>> does this also remove the bound checks?
>>>
>>> -s
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEd86Tw_1qLzK4HEw9rA06Wqnrtzs6CuzMT6VAK3Y40Bs7yPBw%40mail.gmail.com.

Re: [go-nuts] Bound checks elimination hint.

[andrey mirtchovski]

got it down to two:

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

On Fri, Feb 21, 2020 at 11:24 AM Bruno Albuquerque  wrote:
>
> This is interesting. If I simplify the loop to something like this:
>
> nrgbaData := make([]byte, len(rgbData)+(len(rgbData)/3))
>
> _ = nrgbaData[len(rgbData)]
>
> for i := 0; i < len(rgbData); i++ {
> nrgbaData[i] = rgbData[i]
> }
>
> then the bounds check at the line inside the for loop is removed.
>
> But if I change it to this:
>
> nrgbaData := make([]byte, len(rgbData)+(len(rgbData)/3))
>
> _ = nrgbaData[len(rgbData)]
>
> for i := 0; i < len(rgbData); i += 3 {
> nrgbaData[i] = rgbData[i]
> }
>
> then the bounds check is not eliminated.
>
> Considering it is still guaranteed that "i" inside the loop will never be 
> equal to or greater than len(rgbData), I do not understand why the bounds 
> check is now required.
>
> Any ideas?
>
>
> On Fri, Feb 21, 2020 at 10:07 AM Bruno Albuquerque  wrote:
>>
>> Nope. Bound checks are still there. I am puzzled by this one.
>>
>>
>> On Fri, Feb 21, 2020 at 9:34 AM Sebastien Binet  wrote:
>>>
>>>
>>>
>>> On Fri, Feb 21, 2020 at 5:36 PM Bruno Albuquerque  wrote:

 I wrote some simple code to convert a RGB24 image represented as a []byte 
 to a NRGBA image (also as a []byte), like so:

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

 Unfortunately, the performance is lacking here and I am trying to improve 
 it. The first low hanging fruit seems to be taking advantage of BCE:

 $go test -bench .
 goos: linux
 goarch: amd64
 BenchmarkNRGBA-8   484   2636344 ns/op

 $ go test -gcflags="-B" -bench .
 goos: linux
 goarch: amd64
 BenchmarkNRGBA-8   855   1654882 ns/op

 Unfortunately, I could not find an incantation that would remove the bound 
 checks. My naive attempt was to just do

 _ = nrgbaData[len(nrgbaData)-1]

 at around line 7 in the program above but this did not help and added one 
 extra bound check.

 Funny enough, if I do

 _ = nrgbaData[len(nrgbaData)]

 all the bound checks seem to be eliminated but, obviously, the program 
 panics at this line.
>>>
>>> what about:
>>>_ = nrgbaData[:len(nrgbaData)]
>>>
>>> does this also remove the bound checks?
>>>
>>> -s
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAEd86TwC19nJDwAe-kR6Ze8zPf4zjPQp0dMksPAwMwsXCGWRiw%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/CAK4xykXszWjjPf25Un8ze7g2F_epnSFB0BaJmWGhJ%2BpLE_Mm0Q%40mail.gmail.com.

Re: [go-nuts] setting up a hardened https server in go 1.13

[DrGo]

>
> On 2020-02-21 16:13, Amnon Baron Cohen wrote: 
>> > 
>> Default connection limits suggest it isn't production ready by default 
>> and so is 
>> the main reason...so define properly hardened, but also. 
>
>
> For an average schmuck like me, "hardened" means that I am not criminally 
neglecting an easy fix to a known vulnerability in the tools I am using 
(luckily I am not in charge of developing the 2020 voting apps). Ideally, 
net/http exports a function that hides the gory details that Filippo's 
article recommends. Another option is a set of clear up-to-date 
recommendations by the relevant Go Team.

Thanks,

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/604bcf07-a272-468b-a423-519fcbde1570%40googlegroups.com.

Re: [go-nuts] Bound checks elimination hint.

[Bruno Albuquerque]

This is interesting. If I simplify the loop to something like this:

nrgbaData := make([]byte, len(rgbData)+(len(rgbData)/3))

_ = nrgbaData[len(rgbData)]

for i := 0; i < len(rgbData); i++ {
nrgbaData[i] = rgbData[i]
}

then the bounds check at the line inside the for loop is removed.

But if I change it to this:

nrgbaData := make([]byte, len(rgbData)+(len(rgbData)/3))

_ = nrgbaData[len(rgbData)]

for i := 0; i < len(rgbData); i += 3 {
nrgbaData[i] = rgbData[i]
}

then the bounds check is not eliminated.

Considering it is still guaranteed that "i" inside the loop will never be
equal to or greater than len(rgbData), I do not understand why the bounds
check is now required.

Any ideas?


On Fri, Feb 21, 2020 at 10:07 AM Bruno Albuquerque  wrote:

> Nope. Bound checks are still there. I am puzzled by this one.
>
>
> On Fri, Feb 21, 2020 at 9:34 AM Sebastien Binet  wrote:
>
>>
>>
>> On Fri, Feb 21, 2020 at 5:36 PM Bruno Albuquerque  wrote:
>>
>>> I wrote some simple code to convert a RGB24 image represented as a
>>> []byte to a NRGBA image (also as a []byte), like so:
>>>
>>> https://play.golang.org/p/Y7ICg7t4_nd
>>>
>>> Unfortunately, the performance is lacking here and I am trying to
>>> improve it. The first low hanging fruit seems to be taking advantage of BCE:
>>>
>>> $go test -bench .
>>> goos: linux
>>> goarch: amd64
>>> BenchmarkNRGBA-8   484   2636344 ns/op
>>>
>>> $ go test -gcflags="-B" -bench .
>>> goos: linux
>>> goarch: amd64
>>> BenchmarkNRGBA-8   855   1654882 ns/op
>>>
>>> Unfortunately, I could not find an incantation that would remove the
>>> bound checks. My naive attempt was to just do
>>>
>>> _ = nrgbaData[len(nrgbaData)-1]
>>>
>>> at around line 7 in the program above but this did not help and added
>>> one extra bound check.
>>>
>>> Funny enough, if I do
>>>
>>> _ = nrgbaData[len(nrgbaData)]
>>>
>>> all the bound checks seem to be eliminated but, obviously, the program
>>> panics at this line.
>>>
>> what about:
>>_ = nrgbaData[:len(nrgbaData)]
>>
>> does this also remove the bound checks?
>>
>> -s
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEd86TwC19nJDwAe-kR6Ze8zPf4zjPQp0dMksPAwMwsXCGWRiw%40mail.gmail.com.

Re: [go-nuts] Bound checks elimination hint.

[Bruno Albuquerque]

Nope. Bound checks are still there. I am puzzled by this one.


On Fri, Feb 21, 2020 at 9:34 AM Sebastien Binet  wrote:

>
>
> On Fri, Feb 21, 2020 at 5:36 PM Bruno Albuquerque  wrote:
>
>> I wrote some simple code to convert a RGB24 image represented as a []byte
>> to a NRGBA image (also as a []byte), like so:
>>
>> https://play.golang.org/p/Y7ICg7t4_nd
>>
>> Unfortunately, the performance is lacking here and I am trying to improve
>> it. The first low hanging fruit seems to be taking advantage of BCE:
>>
>> $go test -bench .
>> goos: linux
>> goarch: amd64
>> BenchmarkNRGBA-8   484   2636344 ns/op
>>
>> $ go test -gcflags="-B" -bench .
>> goos: linux
>> goarch: amd64
>> BenchmarkNRGBA-8   855   1654882 ns/op
>>
>> Unfortunately, I could not find an incantation that would remove the
>> bound checks. My naive attempt was to just do
>>
>> _ = nrgbaData[len(nrgbaData)-1]
>>
>> at around line 7 in the program above but this did not help and added one
>> extra bound check.
>>
>> Funny enough, if I do
>>
>> _ = nrgbaData[len(nrgbaData)]
>>
>> all the bound checks seem to be eliminated but, obviously, the program
>> panics at this line.
>>
> what about:
>_ = nrgbaData[:len(nrgbaData)]
>
> does this also remove the bound checks?
>
> -s
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEd86TwuyTSizRPLaFjDnD0sX7_L7Y472UQ-27noPsBN9yKQrw%40mail.gmail.com.

Re: [go-nuts] setting up a hardened https server in go 1.13

[Amnon Baron Cohen]

On Friday, 21 February 2020 17:49:06 UTC, Kevin Chadwick wrote:
>
> On 2020-02-21 16:13, Amnon Baron Cohen wrote: 
> > 
> Default connection limits suggest it isn't production ready by default and 
> so is 
> the main reason...so define properly hardened, but also. 


hardened means following the recommendations of Filippo's blog post 
(which in practice adds about 30 lines to your code).

But without a list of vulnerabilities, this sounds to me like FUD.

-- 
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/c77967d6-d87f-433b-af7a-4b4e5775415c%40googlegroups.com.

[go-nuts] Preserving extra properties using JSON unmarshal / marshal?

['Eric Johnson' via golang-nuts]

If I've got a structure like this:

type jsonData struct {
FirstName string `json:"first_name"`
LastName  string `json:"last_name"`
}

I can marshal / unmarshal JSON as:
{
  "first_name": "first",
  "last_name": "last"
}

What if my input JSON is this:
{
  "first_name": "first",
  "last_name": "last",
  "favorite_color": "orange",
  "age": 92
}

Is there an existing library to have a structure that's something like this:

type jsonData struct {
FirstName string `json:"first_name"`
LastName  string `json:"last_name"`
Extrasmap[string]interface{} `json:",extras"`
}

Such that a JSON unmarshal and marshal will preserve the data of the 
original JSON?

I think I can probably make something work with the standard library, 
except that it will require extra marshaling / unmarshaling steps that will 
be annoying to reproduce for each structure that needs to capture extra 
data. So I'm hoping there's a better solution?

Eric


-- 
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/630827e2-8277-4231-9ab1-31881198a386%40googlegroups.com.

Re: [go-nuts] setting up a hardened https server in go 1.13

[Kevin Chadwick]

On 2020-02-21 16:13, Amnon Baron Cohen wrote:
> Interesting.
> 
> What vulnerabilities does OpenBSDs httpd protect against, which a properly
> hardened net/http does not?
> 
Default connection limits suggest it isn't production ready by default and so is
the main reason...so define properly hardened, but also.

https://marc.info/?l=openbsd-cvs=139879883203226=2
http://insanecoding.blogspot.com/2014/05/protecting-private-keys.html

> The problem with proxying through OpenBSD's server, nginx or any other server 
> is
> that there is another 
> moving part that you need to master, configure, monitor, 

httpd.conf is very simple.

> and which may have its own vulnerabilities.

There will be some truth to this, however I guess it is swapping out memory safe
go code for code running as multiple processes as different users, rather than
strictly increasing attack surface. In fact the pledge/simplicity etc. on the
fcgi interface may garner some protections. I haven't considered it much at all
though really, due to first point.

So I guess against a properly hardened is debateable for exploit but the
severity of exploit may be less likely, currently.

-- 
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/00946695-f131-8561-6bf6-c3866e8d06d9%40gmail.com.

Re: [go-nuts] Bound checks elimination hint.

[Sebastien Binet]

On Fri, Feb 21, 2020 at 5:36 PM Bruno Albuquerque  wrote:

> I wrote some simple code to convert a RGB24 image represented as a []byte
> to a NRGBA image (also as a []byte), like so:
>
> https://play.golang.org/p/Y7ICg7t4_nd
>
> Unfortunately, the performance is lacking here and I am trying to improve
> it. The first low hanging fruit seems to be taking advantage of BCE:
>
> $go test -bench .
> goos: linux
> goarch: amd64
> BenchmarkNRGBA-8   484   2636344 ns/op
>
> $ go test -gcflags="-B" -bench .
> goos: linux
> goarch: amd64
> BenchmarkNRGBA-8   855   1654882 ns/op
>
> Unfortunately, I could not find an incantation that would remove the bound
> checks. My naive attempt was to just do
>
> _ = nrgbaData[len(nrgbaData)-1]
>
> at around line 7 in the program above but this did not help and added one
> extra bound check.
>
> Funny enough, if I do
>
> _ = nrgbaData[len(nrgbaData)]
>
> all the bound checks seem to be eliminated but, obviously, the program
> panics at this line.
>
what about:
   _ = nrgbaData[:len(nrgbaData)]

does this also remove the bound checks?

-s

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAAV3P_CEHU%3D-BhhsPyjKZBuDDQDMGMsdFheA8EzALQvF61n87Q%40mail.gmail.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Eric Raymond]

This is a belated addition to my notes on the Go translation of 
reposurgeon. I'll be adding it to the revised version I post to golang-dev.

One extremely positive thing I must say before closing.  Translation from 
Python, which is a dreadful language to try to do concurrency in due to its 
global interpreter lock, really brought home to me how unobtrusively 
brilliant the Go implementation of Communicating Sequential Processes is.  
The primitives are right and the integration with the rest of the language 
is wonderfully seamless.  The Go port of reposurgeon got some very large 
speedups at an incremental-complexity cost that I found to be astonishingly 
low.  I am impressed both by the power of the CSP part of the design and 
the extreme simplicity and non-fussiness of the interface it presents.  I 
hope it will become a model for how concurrency is managed in future 
languages.


-- 
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/abc51fb9-0f98-47e6-91a3-d8950953bfdd%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Eric Raymond]

On Thursday, January 30, 2020 at 2:05:17 AM UTC-5, Liam wrote:
>
> I'd suggest re-posting this on golang-dev; I almost missed it as I rarely 
> read -nuts.
>

That's a good idea.  I think what I'll do is revise it lightly in view of 
some of the feedback I've gotten here and post it there.

-- 
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/152ab11e-2a6d-4ec7-83a4-4feccf66eca7%40googlegroups.com.

[go-nuts] Bound checks elimination hint.

[Bruno Albuquerque]

I wrote some simple code to convert a RGB24 image represented as a []byte
to a NRGBA image (also as a []byte), like so:

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

Unfortunately, the performance is lacking here and I am trying to improve
it. The first low hanging fruit seems to be taking advantage of BCE:

$go test -bench .
goos: linux
goarch: amd64
BenchmarkNRGBA-8   484   2636344 ns/op

$ go test -gcflags="-B" -bench .
goos: linux
goarch: amd64
BenchmarkNRGBA-8   855   1654882 ns/op

Unfortunately, I could not find an incantation that would remove the bound
checks. My naive attempt was to just do

_ = nrgbaData[len(nrgbaData)-1]

at around line 7 in the program above but this did not help and added one
extra bound check.

Funny enough, if I do

_ = nrgbaData[len(nrgbaData)]

all the bound checks seem to be eliminated but, obviously, the program
panics at this line.

I am using

go build -gcflags="-d=ssa/check_bce/debug=1"

to check for the bound checks.

What am I missing here? Any suggestions on how to make this work?

And while we are at it, adding goroutines to convert partitions of the
image also helps (2 goroutines gives a 50% increase in performance more or
less). Other these 2 things, any other suggestion s0on how to make it
faster?

Thanks in advance.

-- 
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/CAEd86TzSSNfRrCV7ZhTf_KGo_dxKon2vxysghTeYDiMdFxp9sw%40mail.gmail.com.

Re: [go-nuts] setting up a hardened https server in go 1.13

[Amnon Baron Cohen]

Interesting.

What vulnerabilities does OpenBSDs httpd protect against, which a properly 
hardened net/http does not?

The problem with proxying through OpenBSD's server, nginx or any other 
server is that there is another 
moving part that you need to master, configure, monitor, and which may have 
its own vulnerabilities.

Filippo, who wrote the blog, is now on the core go team, and working on Go 
Crypto and getting
hardened behaviour by default. See https://blog.filippo.io/hi/ and 
https://go.googlesource.com/proposal/+/master/design/cryptography-principles.md
This would be welcome, as hardening net/http requires a couple of dozen 
lines of boilerplate code.

As you say, his blog post is four years old, and four years is a long time 
in crypto land,
it would be great if we got some updated recommendation from Filippo.
The default behavior has been improved. SSLv3 for instance will be removed 
when 
Go 1.14 comes out (in a few days time). Perhaps we could coax Filippo to 
write 
a Go blog with his updated best practices?



On Friday, 21 February 2020 11:15:53 UTC, Kevin Chadwick wrote:
>
> On 2020-02-21 01:42, DrGo wrote: 
> > Are there more up-to-date recommendations for go 1.13? 
>
> Personally I run Go behind either app engine or via fcgi behind OpenBSD 
> httpd. 
> I'm not sure any other https server has the same level of key protection 
> as 
> revamped in OpenBSDs httpd (separate to LibreSSL), since heartbleed 
> (despite not 
> being as vulnerable as most). 
>

-- 
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/05e2f98e-e443-4fe6-b2b4-1f47a7eae730%40googlegroups.com.

[go-nuts] Re: asm/amd64: is it safe to use NO_LOCAL_POINTERS in this scenario?

[Iskander Sharipov]

If the original question is not clear, I can re-phrase it like this: what 
happens if a function marked with NO_LOCAL_POINTERS contains heap pointers 
on its frame?

My understanding is that these pointers will not count as something that is 
a pointer and if there will be no other pointers to that data, it will be 
claimed by GC. But if there are other pointers that keep that data 
reachable, what are other consequences that can happen?

On Friday, February 21, 2020 at 4:12:01 PM UTC+1, Iskander Sharipov wrote:
>
> Hi all.
>
> I have an asm function that is defined like this:
>
> // func f(x *T1, y *T2)
> TEXT ·f(SB), 0, $32-16
>   NO_LOCAL_POINTERS
>   // It does call a few Go functions, this is why
>   // I need some frame space, to put their arguments there.
>   MOVQ , 0(SP)
>   MOVQ , 8(SP)
>   CALL ·gofunc1(SB)
>   MOVQ 16(SP), AX // Save result
>   // ...more such calls, args take up to 32 bytes.
>   RET
>
> It has 2 pointer arguments and frame with size=32 bytes.
> All that frame space is only used for function call arguments,
> asm function itself does not spill data to the stack.
>
> Arguments to Go functions can contain pointers.
> All of them come from the 2 f() arguments (x and y).
>
> So the question is: how safe it's to use NO_LOCAL_POINTERS here?
>
> If NO_LOCAL_POINTERS is removed, I can't do a CALL, since runtime needs a 
> stack map.
>
> Note that the asm code is simplified, but all statements given above still 
> hold: stack frame only
> holds pointers that are reachable via f() arguments and it's only used to 
> pass arguments to (normal) Go functions.
>
> This sentence from the asm docs  adds 
> more confusion:
>
>> Because stack resizing is implemented by moving the stack, the stack 
>> pointer may change during any function call: even pointers to stack data 
>> must not be kept in local variables. 
>>
>
> I'm not sure what it means by "local variables". When doing asm, you can 
> only imagine local variables as stack-saved values.
>
> I found this part of code 
>  
> that gives some insights, but I can't make a reliable conclusion about my 
> case out of that.
>
> Thank you in advance. :)
>

-- 
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/83b51508-0e2b-4d5b-80a7-97a3931ec5e4%40googlegroups.com.

[go-nuts] asm/amd64: is it safe to use NO_LOCAL_POINTERS in this scenario?

[quasilyte]

Hi all.

I have an asm function that is defined like this:

// func f(x *T1, y *T2)
TEXT ·f(SB), 0, $32-16
  NO_LOCAL_POINTERS
  // It does call a few Go functions, this is why
  // I need some frame space, to put their arguments there.
  MOVQ , 0(SP)
  MOVQ , 8(SP)
  CALL ·gofunc1(SB)
  MOVQ 16(SP), AX // Save result
  // ...more such calls, args take up to 32 bytes.
  RET

It has 2 pointer arguments and frame with size=32 bytes.
All that frame space is only used for function call arguments,
asm function itself does not spill data to the stack.

Arguments to Go functions can contain pointers.
All of them come from the 2 f() arguments (x and y).

So the question is: how safe it's to use NO_LOCAL_POINTERS here?

If NO_LOCAL_POINTERS is removed, I can't do a CALL, since runtime needs a 
stack map.

Note that the asm code is simplified, but all statements given above still 
hold: stack frame only
holds pointers that are reachable via f() arguments and it's only used to 
pass arguments to (normal) Go functions.

This sentence from the asm docs  adds 
more confusion:

> Because stack resizing is implemented by moving the stack, the stack 
> pointer may change during any function call: even pointers to stack data 
> must not be kept in local variables. 
>

I'm not sure what it means by "local variables". When doing asm, you can 
only imagine local variables as stack-saved values.

I found this part of code 
 that 
gives some insights, but I can't make a reliable conclusion about my case 
out of that.

Thank you in advance. :)

-- 
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/a70f1cff-7b0e-452f-a105-7d84e7b5102b%40googlegroups.com.

Re: [go-nuts] setting up a hardened https server in go 1.13

[Kevin Chadwick]

On 2020-02-21 01:42, DrGo wrote:
> Are there more up-to-date recommendations for go 1.13?

Personally I run Go behind either app engine or via fcgi behind OpenBSD httpd.
I'm not sure any other https server has the same level of key protection as
revamped in OpenBSDs httpd (separate to LibreSSL), since heartbleed (despite not
being as vulnerable as most).

-- 
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/91e88441-d0d7-21af-07e8-c92ee122c317%40gmail.com.

[go-nuts] Re: [Proposal] Change how gofmt formats struct fields

[Brian Candler]

On Tuesday, 18 February 2020 18:16:57 UTC, Manlio Perillo wrote:
>
> Here is an example of a diff with a lot of noise, where the actual change 
> is very hard to see:
> https://gist.github.com/perillo/c5b3bdff9e8db9c89f316670d129c0dd
>
> Note that using `git diff -w` is not a solution, since it can only be used 
> locally.  The full diff will be shown by github and friends.
>
>
Then why not file a feature request against github?

BTW, I would use "git diff -b" rather than "git diff -w".  -b treats all 
sequences of one or more whitespace characters as equivalent, and ignores 
whitespace at end of line.  -w ignores whitespace completely, so "foobar" 
and "foo bar" are treated as the same.

-- 
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/7e469c10-c5cd-4e40-aac1-e6d5a39ce373%40googlegroups.com.