Re: [go-nuts] Go if else syntax .. suggested replacement

[Jan Mercl]

On Thu, Apr 25, 2019 at 8:58 PM  wrote:
>
> Rob : how can it be abused if the compiler wont allow nested ? operators ??

Rather easily. Just by fuzzilly mixing the otherwise purposely
distinct syntax of expressions and control flow.

-- 
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] Go if else syntax .. suggested replacement

[Jan Mercl]

On Wed, Apr 24, 2019 at 3:05 AM  wrote:
>
> It sure would be nice if Go syntax allowed programmers to replace
>
> if ( test) {
> ...do sonething
> }

That's not how Go's if statement looks. Gofmt will remove the
superficial parentheses around 'test'.

Wrt the rest of the proposal, today, this is valid code:

if test {
foo()
}
{
bar()
}

How would one write the it under the proposal?

-- 
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] cannot use CallBack (type func(*_Ctype_char, *_Ctype_char, _Ctype_ulong)) as type *[0]byte in argument to _Cfunc_reload_pattern_db

[Jan Mercl]

On Wed, Apr 24, 2019 at 10:47 AM Nitish Saboo  wrote:

> ./main.go:80:32: cannot use key (type *_Ctype_char) as type string in map 
> index

func CallBack(ckey *C.char, value *C.char, value_len C.size_t){
key := C.GoString(ckey)
if remap, ok := field_mappings[key]; ok {
fmt.Println(key, remap)
}
}


> ./main.go:91:21: cannot use CallBack (type func(*_Ctype_char, *_Ctype_char, 
> _Ctype_ulong)) as type *[0]byte in argument to _Cfunc_reload_pattern_db
> ./main.go:143:21: cannot use CallBack (type func(*_Ctype_char, *_Ctype_char, 
> _Ctype_ulong)) as type *[0]byte in argument to

See https://github.com/golang/go/wiki/cgo#function-variables:

"Because of the pointer passing rules Go code can not pass a
function value directly to C. "

-- 
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] cannot use CallBack (type func(*_Ctype_char, *_Ctype_char, _Ctype_ulong)) as type *[0]byte in argument to _Cfunc_reload_pattern_db

[Jan Mercl]

On Wed, Apr 24, 2019 at 1:51 PM Nitish Saboo  wrote:
>
> Hi,
>
> I followed the link 
> 'https://github.com/golang/go/wiki/cgo#function-variables' and  made the 
> following changes:
> 1)main.go
> package main
> //#cgo CFLAGS: -I./syslog-ng-3.6.2/
> //#cgo LDFLAGS: syslog-node.so
> //#cgo LDFLAGS: -L/usr/local/lib/ -lsyslog-ng
> //#cgo LDFLAGS: -L/usr/local/lib/syslog-ng -ldbparser
> //#cgo CFLAGS: -I.
> //void callOnMeGo_cgo(char *key, char *value, size_t value_len);  <

size_t is going to be undefined here.. Also the chars after ';' should
not be there

> // #include "syslog-node1.h"
> //#include 
> import "C"
>
> //export CallBack
> func CallBack(key *C.char, value *C.char, value_len C.size_t){
>
> if remap, ok := field_mappings[C.GoString(key)]; ok {
> fmt.Println(key, remap)//Need to check how field mappings work
> }
>
> }
>
> func ReloadPatternDB(opts Y){

Where from type Y comes?

>
> x := C.CString(opts.x)
> C.reload_pattern_db(x, 
> (C.key_value_cb)(unsafe.Pointer(C.callOnMeGo_cgo)));
>
> }
>
> 2)Created a file 'cfuncs.go'
> 
> package main

Package main must have func main(). Where it is?

-- 
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] Go if else syntax .. suggested replacement

[Jan Mercl]

On Wed, Apr 24, 2019 at 2:04 PM Mark Volkmann  wrote:

> The idea of adding the ternary operator to Go has been debated many times. 
> It’s clear that those in charge have a strong dislike for it. For me the lack 
> of the ternary operator is one of main things I dislike about Go. It’s nails 
> on a chalkboard for me to write a five line “if” statement when it could have 
> been a one line assignment statement.

That's a nice example why Go does not have the ternary operator.
Fitting five if statements into one line makes the code probably
unreadable just for the imaginary gain of saving some vertical screen
space.

-- 
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] Pass value from C code to GO code(CGO)

[Jan Mercl]

On Fri, Apr 26, 2019 at 12:54 PM Nitish Saboo  wrote:

> Can I pass a pointer to a value from Go to C, do some manipulation on it 
> within the C code and access the value from Go after the C code executes ?

The first part of the question is discussed in great detail here:
https://golang.org/cmd/cgo/#hdr-Passing_pointers

-- 
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] Pass value from C code to GO code(CGO)

[Jan Mercl]

On Fri, Apr 26, 2019 at 12:34 PM Nitish Saboo  wrote:
>
> Hi,
>
> I want to call C code from GO code.Once the C code gets executed I want to 
> pass the value back to the GO code.
> Can someone please guide me as in how to pass value back from C code to the 
> GO code.

What C type the value is? Do you want to pass it using a return value
of a C function called from Go or access the value from Go after the C
code executes or pass the value to a Go function called from a C
function?

Have you an example of what you tried and how/why it failed?

PS: Please note that the name of the programming language is Go.

-- 
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] Question about iterator implementation of golang map

[Jan Mercl]

On Mon, Jul 15, 2019 at 4:39 PM Aaron Lau  wrote:

> We won't update the map during the traversal process. So why use mapaccessK 
> to find the k & v again ?

The comment explains that very clearly:

> // The hash table has grown since the iterator was started.
> // The golden data for this key is now somewhere else.
> // Check the current hash table for the data.
> // This code handles the case where the key
> // has been deleted, updated, or deleted and reinserted.
> // NOTE: we need to regrab the key as it has potentially been
> // updated to an equal() but not identical key (e.g. +0.0 vs -0.0).
> rk, rv := mapaccessK(t, h, k)

Iteration does nut mutate the map, correct. But the code that iterates
the map may mutate it.

for k, v := range m {
   if cond(k, v) {
   m[2*k] = 3*v
}
}

-- 
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/CAA40n-Uu1uxvxj%3D6%2BTOUA4h-JbPoqtxsM5CHZnmp%2B1H8SvfSWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What is the fundamental unit of linking in Go?

[Jan Mercl]

Please provide a minimal, self contained demonstration code that reproduces
the problem. Then it should be hopefully easy to either explain why things
work they do or it'll be a nice test case for the fix to the issue this may
actually be. Thanks.

On Fri, Jun 28, 2019, 20:10  wrote:

> I have come up against something a bit strange and interesting that I
> didn't really expect from the Go compiler.
>
> I have a main which uses a structure created in a package, which contains
> a whole load of references to other packages.
>
> What I discovered is that even though only one of these included packages
> is used, the whole set still gets included in the binary.
>
> Am I right in saying that packages create a linker object file, as a
> whole, and every package imported is also linked?
>
> In the case of my application it means I now have to manually break up a
> whole load of nice pretty neat declarations into pieces that return
> generator functions, and each part has to come from a different package,
> meaning a folder and one tiny little source file.
>
> I couldn't find any reasonable terms that explained Go's linking
> mechanisms but it dawned on me as I thought about how each folder in the
> tree creates a binary object that is stitched together in the final binary,
> that there's really no way around this, and I suppose it makes nice neat
> little bite sized source files but for my case it was a surprise I hadn't
> expected.
>
> After building a giant conglomeration I realised for some cases (namely, a
> backend for a mobile app) that one has to design the folder tree to split
> the parts. It's something to keep in mind for multi-function binaries if
> you want to also offer single function binaries for specific parts that are
> only needed alone.
>
> I am probably, as usual, doing something unconventional and running up
> against things that nobody else ever thought of and discover something
> about a system that isn't obvious until you think about it, when one
> intends to do some particular thing.
>
> In terms of memory utilisation, there is really not a great deal of
> difference in terms of performance, I presume, except providing the ability
> to cut up the whole thing into small pieces, a tiny amount extra on disk
> but I presume the final memory use, since all is a monolithic (more or
> less) static binary, that once it unwraps all the entry points and relative
> references that there isn't (much) extra in memory. I suppose also if one
> is targeting a constrained environment, it would make sense to use -s -w to
> strip out the debug symbols.
>
> --
> 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/36de6c0d-23fe-4dfa-ad9a-89d9734c9701%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/CAA40n-XZ8Q6gQzMh9GtYHJOeUJve_m43eCBsr0KJJHaCJW9uaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Counter-counter-counter proposals

[Jan Mercl]

On Mon, Jul 1, 2019 at 4:50 AM Michael Jones  wrote:

> ... language design is about other people and other use cases than your own.

That nicely explains C++ existence.

-- 
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/CAA40n-UHdpZuAMTESusufRmmtBEt5cUyGAPo5F4wen9do%3DXyoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] for i := range

[Jan Mercl]

One ranges a copy of the array, the other does not:
https://play.golang.org/p/Z3InmyFqQN3

On Fri, Aug 16, 2019, 19:11 Vadim Maximov  wrote:

> Hi, all!
>
> Is *for.*..*range* over an address/reference of  an array faster than
> regular *for...range*? For instance:
>
> arr :=[...]int{1,2,3}
> for _,v := range {
>fmt.Println(v)
> }
>
> I heard that it  is slightly faster for huge arrays, but why is it so? And
> is it actually true (or makes sense)?
>
> --
> 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/33c85347-6b48-4e74-9718-15d5b7317f93%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/CAA40n-Us8bVh%2BuBpV4ku3qJkitK58kjMgLwuu6K8JbunJCYj7A%40mail.gmail.com.

Re: [go-nuts] Re: mutual exclusion algorithm of Dijkstra - strange behaviour

[Jan Mercl]

On Fri, Aug 16, 2019 at 8:09 PM  wrote:

> Meanwhile it is clear why things do not work:
> The Go-Scheduler is unable to allow to switch to another goroutine in 
> busy-waiting-loops -
> the only possibility to get around that problem is either to put 
> "switch-steps" into the source
> - either "time.Sleep(1)" or "runtime.Gosched()".
> I think that THIS SHOULD BE DOCUMENTED IN THE LANGUAGE SPECIFICATION !
>
> (See my book on https://maurer-berlin.eu/nspbuch - in it's 4th edition things 
> are mentioned.)

That conclusion is not correct and you should correct your book. The
code in the OP is racy. You cannot say anything meaningful about the
behavior of a racy Go program - it is undefined.

-- 
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/CAA40n-XQpGu%2BUt4hABbt7Hn%2BNt02s%2B_tbBjEZDrSQmzEV8gW5w%40mail.gmail.com.

Re: [go-nuts] Re: When doing "type X Y", is it a type alias or type redefinition or type adapter or something else?

[Jan Mercl]

On Tue, Aug 13, 2019 at 9:24 AM Volker Dobler
 wrote:

> Yes, of course. It declares a new named type X, the underlying
> type is Y which can be some predeclared type like int, some
> other named declared type (like MyFooType) or a "type literal"
> (a term I made up) like struct{X,Y float64; T string} or
> map[string]bool or chan time.Time .

"Type literal" is not made up, it's a well defined part of the
specification: https://golang.org/ref/spec#TypeLit ;-)

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

Re: [go-nuts] Go string and UTF-8

[Jan Mercl]

On Tue, Aug 20, 2019 at 3:17 PM Pierre Durand  wrote:
>
> Well, in my case I don't want to convert the []byte to hexadecimal string, 
> because it uses 2x more memory.
> The code contains a huge map where the key is an MD5 hash.

md5 hash is an array type and can be used as a map key directly:
https://golang.org/pkg/crypto/md5/#Sum

Example: https://play.golang.org/p/qp-LFWh2Jln

-- 
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/CAA40n-XHXyf4qEeGEVCR2-86wUWzWTnA2y4myjJBZbaCfcAUdA%40mail.gmail.com.

Re: [go-nuts] How to execute a command using root?

[Jan Mercl]

On Fri, Aug 30, 2019 at 8:49 AM Benjamin  wrote:

>Do anyone have any suggestions on this? Thanks.

IINM, what you want is not possible. Moreover, it should not be possible.

-- 
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/CAA40n-Uz6vSbeqr1cAZKqzAzvxoWwdE%3DxxWGsmBy62ZS8WNamw%40mail.gmail.com.

Re: [go-nuts] How to execute a command using root?

[Jan Mercl]

On Fri, Aug 30, 2019 at 8:53 AM Jan Mercl <0xj...@gmail.com> wrote:

> Moreover, it should not be possible.

But whitelisting certain users to run certain programs using sudo, but
no password, is possible.

-- 
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/CAA40n-X93RPG2sK4NO-M0PH78p8%2BcgKHxcgWQxj9i6qk9fa4Yw%40mail.gmail.com.

Re: [go-nuts] how to merge different struct to one struct

[Jan Mercl]

On Sat, Aug 24, 2019 at 5:25 AM Lee Rick  wrote:
>
> i want to do
> type A struct{ Name string}
> type B struct{Age int}
> type C struct{Address string}
>
> a, b, c := A{}, B{},C{}
> have a function
> d1 := merge(a,b)  //d1 like struct{Name string, Age int}
> d2 := merge(a,c)  //d2 like struct{Name string, Address string}
> d3 := merge(b,c) //d3 like struct{Age int, Address string}
>
>
> how to realize merge function? anyone can give me a demo

Is this the XY problem? What is the task/goal?

-- 
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/CAA40n-U%3DrJD8%3D_adUnK0hXjHzw23DLG5XS6LKYsh0PGSYEvcoQ%40mail.gmail.com.

Re: [go-nuts] Re: v1.13: Altered go.mod file in project after updating vim-go binaries

[Jan Mercl]

On Thu, Sep 5, 2019 at 8:18 PM  wrote:

> Running 'go get ...' inside a module can add indirect dependencies to go.mod.

I'm surprised. There's probably some rationale behind `go get` having
such side effects. Can anyone please shed some light on this?

-- 
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/CAA40n-WhnkL23wGLZkT-AtGeiL4b%2BzW1gNT8cBcpdY8hY89ucw%40mail.gmail.com.

Re: [go-nuts] Re: v1.13: Altered go.mod file in project after updating vim-go binaries

[Jan Mercl]

On Thu, Sep 5, 2019 at 8:51 PM Mihai Borobocea  wrote:

> $ go help module-get
> The 'go get' command changes behavior depending on whether the
> go command is running in module-aware mode or legacy GOPATH mode.
> …
> Get resolves and adds dependencies to the current development module
> and then builds and installs them.

Thanks for the pointer. I think that behavior is not a good idea. Yes,
it's convenient that when working on a module and realizing some
dependency is missing, `go get` handles updating `go.mod`. However at
the same time this breaks the workflow of possibly a big number of
people. The OP's :GoUpdateBinaries in vim-go is just one example. I
don't know how many people use `vim_go`, but the project has 10k+
stars. Developer's scripts/make files/go generate "scripts" etc, all
of that may legitimately invoke `go get` for things the module _is
not_ actually dependent on.

`go get` should do just one thing and do it well. Automagically
adjusting `go.mod` if one is found in the current directory (or in any
of its parents) when outside $GOPATH is IMO neither of that. Or it
should be enabled by a flag, like -um (update go.mod) or this is maybe
a job for some `go mod foo` command, not `go get`.

-- 
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/CAA40n-XXYVhQaQ0wd%3D29zqDc8hK6w%2BUvOaEMDjA8_Gepux_9_Q%40mail.gmail.com.

Re: [go-nuts] how to pass c array to golang efficiently

[Jan Mercl]

On Wed, Aug 7, 2019 at 3:17 AM hui zhang  wrote:

> //export Send
> func Send(confid string, len int, pcm *C.short) {
>//put c.short array to int16 slice/array efficiently , how ?
>// memcopy ?
> }

s := (*[^uint(0) >> 1]int16)(unsafe.Pointer(pcm))[:len] // s is
[]int16, len(s) = len

-- 
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/CAA40n-X-Ojb1tSxnBdSB771gE6F%2Bm4KQUX_FhVbZisMFG3EG2g%40mail.gmail.com.

Re: [go-nuts] Hexadecimal floats

[Jan Mercl]

There are several NaNs, but only a single bit pattern for IEEE754 infinity
(modulo the sign bit). So yes, your suggestion should work well. Thank you,
I'll give it a try.


On Sat, Jul 27, 2019, 07:44 Adrian Ho  wrote:

> On 26/7/19 9:20 PM, Jan Mercl wrote:
> > In a program that generates C, I'm using big.Float.Text
> > (https://golang.org/pkg/math/big/#Float.Text) to produce the exact
> > value of the C floating point literal. As it turns out, the function
> > does not support Inf values. Instead of encoding the exact bits of the
> > Inf value, the resulting string is simply "Inf".
> >
> > I'm looking for possibly existing, open source Go code that does the
> > conversion properly both for C floats (Go float32) and C doubles (Go
> > float64). So far I was not able to find anything. I can surely roll my
> > own code, but I'd very much like to use a well tested code if someone
> > can point me to such.
> >
> > TIA
>
> Section 7.12.4 of the C99 standard says that  defines the
> *INFINITY* macro to represent positive infinity, and the way it's
> defined in the standard suggests that negative infinity can be
> represented by simply negating that constant. Doing it this way works
> portably across all standard C compilers and architectures.
>
> Is there a reason you can't simply post-process Text() output to replace
> "Inf" with "INFINITY"? That's just a simple "if" test.
>
> --
> Best Regards,
> Adrian
>
> --
> 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/b6efb830-e465-fe37-8be4-27233e27d60f%4003s.net
> .
>

-- 
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/CAA40n-XKAQd5euW%2BHLwKR5wDwYnqH8F3%3D4hVic2GTG4VW-TZjg%40mail.gmail.com.

Re: [go-nuts] Hexadecimal floats

[Jan Mercl]

On Sat, Jul 27, 2019 at 7:44 AM Adrian Ho  wrote:

It works: 
https://gitlab.com/cznic/qbe/commit/0cdebdce50edb146df981b6b484bad57eddb9e94#97b5d71a8f6b71eb5bf032969fb4a29f9d89eef4_1175_1177

Thanks again.

-- 
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/CAA40n-XghOWagm8%3D4tDS8it7P7rHjz%2BmEASpepoo-d3mBRiokQ%40mail.gmail.com.

Re: [go-nuts] Go Library lists

[Jan Mercl]

On Tue, Aug 6, 2019 at 3:51 PM  wrote:

> If anyone knows of a currently maintained equivalent , please respond

Check https://github.com/golang/go/wiki/Projects

-- 
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/CAA40n-XF1Obi4O3uJpHczywUETM8L2VDf%3Do6%2BF%3DLxL7FHSvFSA%40mail.gmail.com.

Re: [go-nuts] Re: Question re fcns that return multiple values

[Jan Mercl]

On Tue, Aug 6, 2019 at 4:07 PM  wrote:
>
> Here a specific example:
>
> The following compiles and runs as expected
> m1x,m1y := ec.scalarMult(16,28,33)
> m2x,m2y := ec.scalarMult( 1,28,33)
> rx,ry := ec.add (m1x,m1y, m2x, m2y)
>
>
> However this stmt :rx,ry= ec.add(ec.scalarMult(16,28,33), ec.scalarMult( 
> 1,28,33))  gives the following compiler error ...
>
> # command-line-arguments
> .\ECurve.go:272:14: not enough arguments in call to ec.add
> .\ECurve.go:272:28: multiple-value ec.scalarMult() in single-value context

WAI, see https://golang.org/ref/spec#Calls


As a special case, if the return values of a function or method g are
equal in number and individually assignable to the parameters of
another function or method f, then the call f(g(parameters_of_g)) will
invoke f after binding the return values of g to the parameters of f
in order. The call of f must contain no parameters other than the call
of g, and g must have at least one return value. If f has a final ...
parameter, it is assigned the return values of g that remain after
assignment of regular parameters.


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

Re: [go-nuts] how to pass c array to golang efficiently

[Jan Mercl]

On Tue, Aug 6, 2019 at 11:11 AM hui zhang  wrote:

Please always send code to the ML as plain, black on white text.
And/or use play.golang.org. 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/CAA40n-UPL%2B5RrrOZdObniMfUaU-%3DN_JGWLMNQkC-KJeossV0Pw%40mail.gmail.com.

Re: [go-nuts] sqlite x ql

[Jan Mercl]

On Wed, Jul 17, 2019 at 4:34 PM Luis Furquim  wrote:

> Has anyone any information about performance comparison between Sqlite and Ql 
> (github.com/cznic/ql or modernc.org/ql)? Any bit of information would be 
> appreciated!

QL is slower. Sometimes dramatically slower. QL's query
planner/optimizer is very rudimentary. However, for some usage
scenarios the performance might be acceptable. I strongly suggest to
use the V2 backend wherever possible.

-- 
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/CAA40n-W6r9TztYvn5_cBWa8BcDP2ARAP_4O4e688ORf8SG7Rgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jan Mercl]

On Sat, Jul 20, 2019 at 9:28 AM Vasiliy Tolstov  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/CAA40n-XObyXZkDvMwouy52B9N-m8Rxi3PU-sPNRqJqycAXxq0w%40mail.gmail.com.

Re: [go-nuts] Re: About the Google logo on the new Go website

[Jan Mercl]

On Fri, Jul 19, 2019 at 10:39 PM Cassandra Salisbury  wrote:
>
> I encourage everyone to take a look at the code of conduct. I have had 
> multiple reports from this particular thread.

I, for one, have no idea why. But I guess Kafka would be delighted by
this mysteriosity.

-- 
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/CAA40n-XBFRVJjnt1OdKYOTLMh_-6pzCAZBaK5faaxXFD73eEdQ%40mail.gmail.com.

Re: [go-nuts] Re: About the Google logo on the new Go website

[Jan Mercl]

On Wed, Jul 17, 2019 at 8:07 AM Michael Jones  wrote:
>
> I'm a reader here, so @all includes me. In regards to Oracle, I was delighted 
> when they released VirtualBox under GPL and remain delighted that they pay 
> Oracle employees to enhance it and share their work.

I'm a thankful user of Oracles's VBox.

Now, WDYT about Oracle pushing copyrighting APIs through the ever
higher court levels? Is evilness of a company computed by summing its
good and bad moves? It's a yes from me and my scorecard for Oracle
says -Inf+1.

-- 
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/CAA40n-UD2oGZ3QU4PgXLmevyQ2jvvmJnw4nqV0jRc92riNNpXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] "Go to" one line before the declaration

[Jan Mercl]

On Wed, Jul 17, 2019 at 11:24 AM  wrote:
>
> Can somebody explain this code?
> How is the cpu doing? better than for{} ...

Who claims it's doing better than `for {}`? IDK, I haven't tested, but
I guess it should perform the same bad way.

> ... and select {} in CPU usage?

Now that's a different story. Using `select {}` should burn 0% CPU in
the goroutine that executed the statement.

PS: Please post source code as black text on white, and, if possible,
as plain text only.

-- 
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/CAA40n-WQ6tuo01fDNdEm2T0ba_5i7ttqE4VX%2BhgoONrZRo07uA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Hexadecimal floats

[Jan Mercl]

In a program that generates C, I'm using big.Float.Text
(https://golang.org/pkg/math/big/#Float.Text) to produce the exact
value of the C floating point literal. As it turns out, the function
does not support Inf values. Instead of encoding the exact bits of the
Inf value, the resulting string is simply "Inf".

I'm looking for possibly existing, open source Go code that does the
conversion properly both for C floats (Go float32) and C doubles (Go
float64). So far I was not able to find anything. I can surely roll my
own code, but I'd very much like to use a well tested code if someone
can point me to such.

TIA

-- 
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/CAA40n-WTVTm2LoYYdVBF2JOeCEDfRKT-8r1BApuESRDLVo-oRQ%40mail.gmail.com.

Re: [go-nuts] Need explaination for code

[Jan Mercl]

On Fri, Jul 26, 2019 at 8:15 PM thatipelli santhosh
 wrote:

> Can anyone please explain this piece of code? this would be more helpful to 
> me to understand this. Thank you!

I don't know what "explain this code" means in this case. But maybe
this can help: https://play.golang.org/p/t4yDlOwG-rv

-- 
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/CAA40n-WYbwC-Udv%3Df8%3D%2BkzW4pgxTnpx_uJyvk8zwrRNt%3D60pHA%40mail.gmail.com.

Re: [go-nuts] Clarification on unsafe conversion between string <-> []byte

[Jan Mercl]

On Mon, Sep 23, 2019 at 11:37 AM  wrote:

> ... and the problems with storing a uinptr in a variable are mostly related 
> to moving garbage collectors ...

Please note that even though, AFAIK, none of the Go compilers so far
uses a moving GC, it's not the only source of objects being moved
around. For a long time the gc Go compiler has moveable stacks and
things may reside in stack whenever the compiler decides it can and
wants to do it.

-- 
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/CAA40n-Wx-2yYwEL9pg2s9UX8Y7OMR0sfsFGd5R-Kje%2BmbhQ4sg%40mail.gmail.com.

Re: [go-nuts] Migrating Google App Engine Go app to Go 1.12

[Jan Mercl]

On Mon, Sep 30, 2019 at 12:34 PM Matthew Zimmerman  wrote:
>
> My notice said that apps continue to run, you just can't deploy new versions.
>
> "Starting on October 1, 2019, as per our deprecation policy, you will no 
> longer be able to deploy new versions of App Engine Standard applications 
> that use Go 1.9 and earlier. However, applications that have already been 
> deployed will continue to run."

Thanks for the update! Somehow I cannot find that email, but I recall
receiving it some weeks ago.

I've already unfortunately disrupted the service for about 15 minutes.
It's now restored. Further brief dropouts are possible. Apologies to
anyone affected.

-- 
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/CAA40n-VnMot4ro1znX5EdbdeigaO5SF4Nfg5q%2B1b3UcWefvc7w%40mail.gmail.com.

[go-nuts] Re: Migrating Google App Engine Go app to Go 1.12

[Jan Mercl]

On Mon, Sep 30, 2019 at 11:32 AM Jan Mercl <0xj...@gmail.com> wrote:

Panic mode off. Deployed, seems to work:
https://gitlab.com/cznic/modernc/commit/96339947ba67960ae5bd19b625b2816fdcc7af6e

Thanks to anyone who have read the OP.

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

[go-nuts] Migrating Google App Engine Go app to Go 1.12

[Jan Mercl]

Hi list.

The modernc.org domain go-get redirector is hosted at the Google App
Engine and provides access to all packages found at this time at
https://gitlab.com/cznic. Go code for the redirector iself is
published at https://gitlab.com/cznic/modernc. The instance dashboard
shows a warning: "A version of your app is using a deprecated version
of Go. Please upgrade before October 1, 2019. Learn more". The "Learn
more" links here:
https://cloud.google.com/appengine/docs/standard/go112/go-differences?hl=en_US&_ga=2.244421253.-1415549777.1569833277

I'm pretty lost after reading the docs. It's not just about changing
`runtime: go` to `runtime: go112` in the `app.yaml` file.

As I'm using the deprecated `appengine` package
(https://gitlab.com/cznic/modernc/blob/ed5d04d89c1e4c74a2742191d62d89437a534b42/main.go#L21),
I should migrate to the Google Cloud client library. The docs link
here: https://github.com/googleapis/google-api-go-client. However,
looking at the godocs here
https://godoc.org/google.golang.org/api/appengine/v1, I cannot see any
`Main` API call to replace the call at `main:21`.

The redirector has 10K+ requests daily and I need to do the upgrade today.

Please help me, 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/CAA40n-UAeExU9iAcqD7aMSeQjdwdAuvC9D1oXv64MYAJSUqAew%40mail.gmail.com.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Jan Mercl]

On Sun, Jun 30, 2019 at 3:19 PM Jesper Louis Andersen
 wrote:

> This is where the try-construct will definitely improve the ergonomics of the 
> programming.

With full respect to you opinion and/or personal preferences,
"definitely improve" is just and only that. I _definitely_ don't share
that opinion/personal preference.

-- 
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/CAA40n-VLoDYs_PS1BQMCEmS03YfsHoXBE4vb4cmjLjto4k94pg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Newbie question on slice bound checking

[Jan Mercl]

On Sun, Jun 16, 2019, 13:53 Ugorji Nwoke  wrote:

> I know this is an old thread, but is -B still supported?
>

That compiler flag provides compiling a program, semantic of which isn't
compatible with the Go language specification.

It's only valid use is to enable easy evaluation of the bounds checking
costs.

That said, I don't think the term "supported" applies. It's just a compiler
developer's tool.

-- 
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/CAA40n-UGio_%3Da36R06BXW286BMFj5yVToA65LNVR-F8gJMnbtw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [ANN] QBE compiler (proof of concept)

[Jan Mercl]

See: https://godoc.org/modernc.org/qbe/qbec

There's also qbefmt: https://godoc.org/modernc.org/qbe/qbefmt

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

Re: [go-nuts] strict type assignability to prevent arbitrary values

[Jan Mercl]

On Thu, Nov 7, 2019 at 11:58 AM bsr  wrote:

> Is there a way I can prevent this behavior.

Yes, if the rules for untyped literals are not wanted, make the
literal typed: https://play.golang.org/p/-f75y0Gb1Is

-- 
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/CAA40n-Xj1u03KyXWn9GGGzf8g%3DJj5us10Y379bQ4s-dn0sGs1Q%40mail.gmail.com.

Re: [go-nuts] Задача: Дано число int 324. Как получить 9?

[Jan Mercl]

On Wed, Dec 4, 2019 at 2:49 PM Vital Nabokov  wrote:
>
> Добрый день.
> Задача: №1 Дано число int 324. Как получить int 9?
> Задача: №2 Дано число string "324". Как получить int 9?

This mailing list is in English:
https://groups.google.com/forum/#!aboutgroup/golang-nuts

Please use the mailing list language for your posts, thank you.

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

Re: [go-nuts] Re: Why Iran is banned by Google?

[Jan Mercl]

On Mon, Dec 9, 2019 at 5:57 PM  wrote:

> So in simpler words, Google has banned Iran, right?

Wrong. Michael was, 5 years ago, very precise and clear about the
facts, which are exactly the opposite.

-- 
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/CAA40n-X_FnrLAoVnL10QgDz_3KDytCD8KXrN%3DK5wmN3xySdxTA%40mail.gmail.com.

Re: [go-nuts] Re: Inconsistent rounding with float printf ?

[Jan Mercl]

On Fri, Dec 6, 2019 at 6:04 PM Christophe Meessen
 wrote:

> I can't change expectations. It is to convert a byte count into a human 
> readable byte count ( with kB, MB, ... units).

So it was an XY problem?

No floating point operations are necessary to do that. Also, check
several existing libraries, for example this one:
https://github.com/dustin/go-humanize

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

Re: [go-nuts] Re: Where is the middle of Brazil?

[Jan Mercl]

On Sat, Dec 7, 2019 at 2:34 PM JuciÊ Andrade  wrote:

> I am pretty sure there are other ways to do it, but the method I devised is 
> simple and produces a good enough result. If somebody can put a hole in my 
> reasoning, feel free to do so.
>
> All the info I need are in a map, OK? So I downloaded a map from the 
> Internet. I choose a map that shows only the territory I am interested in and 
> nothing else:
>
> http://www.temasactuales.com/temasblog/wp-content/Images/mapa_do_brasil.gif
>
> The method goes like this: I scan the image counting every pixel that is not 
> background color. It gives my territory area. Then I divide that by 2 to 
> obtain half the area.
>
> I scan the image again from top to bottom, stopping when I reach half the 
> area. I draw a horizontal line dividing north and south. Finally I scan the 
> image from left to right stopping at half area and draw a vertical line 
> dividing east from west. The point I am interested in is in the intersection 
> of those two lines.

This method resembles determining the CG, but only very approximately.
How is your "middle" actually defined?

-- 
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/CAA40n-X_k0KyGrM77kBRUSkrUOLNSPn-0Rk9LGbCeoxkmYJ5Rg%40mail.gmail.com.

Re: [go-nuts] Extending an array 'The right way'. Guidence needed!

[Jan Mercl]

On Tue, Oct 15, 2019 at 12:16 PM Stuart Davies  wrote:

> I have a slice backed by an array.
>
> My understanding is that I can extend the slice (append)  up to the capacity 
> of the array.

I guess that by 'extend the slice' you mean reslicing. Yes, that can
be done while len <= cap. However, appending is a different operation,
performed by the predeclared function `append`.

Please let us know what is the ultimate goal you need to achieve. Best
is to share the minimal, compilable code you have already at the Go
playground: https://play.golang.org

-- 
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/CAA40n-ViG7%2Bk1UdDJ_mqCfw0_-fA%3DiDRvenHbajES65NjxGgdA%40mail.gmail.com.

Re: [go-nuts] Need help with godbus.

[Jan Mercl]

On Tue, Nov 19, 2019 at 5:21 PM Ken Bassford  wrote:

Please always post source code to the mail list in plain black on
white only, thank you.

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

Re: [go-nuts] About Libraries Versioning

[Jan Mercl]

On Wed, Nov 20, 2019 at 2:42 PM Eyal  wrote:

> The recommended way to create a new version for a go library is by copying 
> the library code to a v2 directory.

Only if the new version that breaks backward compatibility. Bug fixes
and/or new features do not need such switch.

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

Re: [go-nuts] [ANN] Golang Oriented to Aspects (goa) v0.0.1 is released!!!

[Jan Mercl]

On Mon, Nov 25, 2019 at 10:47 PM Iván Corrales Solera
 wrote:

> Source ode https://github.com/wesovilabs/goa
> Full documentation http://wesovilabs.github.io/goa

Would you mind changing the name of the language to the proper form
everywhere in the above quoted links? Some people may chose to just
walk away otherwise.

-- 
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/CAA40n-WUpSLENn3A-cnu2kgeuX-HYOyFvm18LNmtqjzpC6trrQ%40mail.gmail.com.

Re: [go-nuts] Change slice type

[Jan Mercl]

On Thu, Nov 28, 2019 at 3:16 AM Michael Jones  wrote:
>
> The general rule -- if there can be a general rule for risk behavior -- is 
> that CPUs like having addresses aligned on an integer multiple of the data 
> element size. So:
>
> access-as-byte data may be on any address (address&(1-1)==0),
> access as 2-byte data on a multiple of two address (address&(2-1)==0),
> access as 4-byte data on a multiple of four address (address&(4-1)==0),
> access as 8-byte data on a multiple of eight address (address&(8-1)==0),
> access as 16-byte data on a multiple of sixteen address (address&(16-1)==0),

It's a bit more complicated for struct fields on 386, some 8 byte data
are 4 byte aligned.

-- 
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/CAA40n-U7tcWxq65pOGZhk2oLfgR2z3fMpK1Z2un65tmjv9%3DQaw%40mail.gmail.com.

Re: [go-nuts] Re: [golang-dev] go.dev is live!

[Jan Mercl]

On Thu, Nov 14, 2019 at 5:55 AM Dan Kortschak  wrote:

> It looks like license detection needs work.
>
> See https://pkg.go.dev/gonum.org/v1/gonum?tab=overview and note it has
> a BSD 3 clause, as shown by GitHub's assessment (just above the "Clone
> or download" button) at https://github.com/gonum/gonum and the LICENSE
> file that it links to.

Moreover, such packages seem to be, as a side effect, non-discoverable
because their README and documentation are not indexed (nor
displayed). For example, searching for `pure go SQL database' has zero
results.

I don't care about automatic license recognizing, even though it's
admittedly a useful information for the site user. But I don't
understand why projects with unrecognized LICENSE file contents don't
show the README and the documentation.

I'll better leave the fact of hiding even the LICENSE file per se from
the user with the message `“Licenses” hidden due to license
restrictions.` without comment because I guess it's just a legal issue
I don't understand.

Any yes, all my packages that I tried are victims to the above issues.
Here's an example of a recognized LICENSE vs an  unrecognized one:

jnml@e5-1650:~/src/modernc.org/mathutil> diff -u ~/goroot/LICENSE LICENSE
--- /home/jnml/goroot/LICENSE 2019-09-10 14:24:54.469859557 +0200
+++ LICENSE 2019-09-10 14:36:43.347068286 +0200
@@ -1,4 +1,4 @@
-Copyright (c) 2009 The Go Authors. All rights reserved.
+Copyright (c) 2014 The mathutil Authors. All rights reserved.

 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions are
@@ -10,7 +10,7 @@
 copyright notice, this list of conditions and the following disclaimer
 in the documentation and/or other materials provided with the
 distribution.
-   * Neither the name of Google Inc. nor the names of its
+   * Neither the names of the authors nor the names of the
 contributors may be used to endorse or promote products derived from
 this software without specific prior written permission.

jnml@e5-1650:~/src/modernc.org/mathutil>

-- 
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/CAA40n-UNy5nuBDLN%2BeJZO6FPm8gRwmPKFXT7i4AprSui-SjXNA%40mail.gmail.com.

Re: [go-nuts] nil map assignment panics. can we do better?

[Jan Mercl]

On Tue, Sep 24, 2019 at 10:11 PM Marcin Romaszewicz  wrote:
>
> Could we have an operation like append() for slices?
>
> How about:
>
> m := insert(m, "key", "value").

A slice is a value but a map is implemented as a pointer. IOW, the
line of code quoted above updates only the locally visible copy of m.
All other copies of m are left at the old, possibly nil, value, but
that's not how maps in Go work. Once the map is initialized, all the
shared copies can access the same values/operations on it.

-- 
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/CAA40n-X06rRJh9%3Dehkv7OszkNx2Lg2UyLzFqHesS4HF5d%3DU7fA%40mail.gmail.com.

Re: [go-nuts] rebuild & reinstall pkg/tool/.../link

[Jan Mercl]

On Wed, Oct 9, 2019 at 12:10 PM Liam  wrote:
>
> I have the current 1.12 release from a Linux distro, installed in /usr/lib/go.
>
> If I patch the linker source, how would I rebuild and reinstall 
> pkg/tool/.../link ?

I think there are two options:

- Learn how to make the distro's package from sources.
- Install Go from sources: https://golang.org/doc/install/source.

-- 
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/CAA40n-Xv-vJm2a%2B_JzdPZtgZ72PxoCr6dsE7hfNdAupBM73s4Q%40mail.gmail.com.

Re: [go-nuts] Assigning a value to a function pointer

[Jan Mercl]

On Mon, Dec 23, 2019 at 2:49 PM  wrote:

> But I cannot find any way of assigning a value to the function pointer `f` 
> even using the `unsafe` package.

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

Note that while you can a pointer to a function, you rarely need that.
Function is just a value like int (in the very first approximation).

> My main reason for willing this is to be able to:
> - atomically load a dynamic address.

Depends very much on what a "dynamic address" is. Functions are
normally static. Functions literals a bit less, but actually the code
address is always fixed in both cases, only the closure parameter, if
any, differs.

-- 
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/CAA40n-Wj58nGdC2Mr4Z8gdFCH1O3Z3u9Fa0zx_9eeSh7Or7%3D7Q%40mail.gmail.com.

Re: [go-nuts] Re: [Go Spec]Confused about Assignability in Golang Specification

[Jan Mercl]

Type literals are a prime example of "undefined" types. For example as in
`var a []int`.

On Sun, Feb 23, 2020, 17:21 Jimu Yang  wrote:

> Thank you all.
> i read all about defined types on the doc
> https://golang.org/ref/spec#String_types
> now i know many defined types (string bool int ...  but which are the
> "undefined" types? i didn't find a direct answer.
> my thinking is that the "literals" which including all type literals are
> not defined types. The following code confirms that.
> could you give me a reference answer?
>
> type str string
> var s str = "sdwf"
>
> // boolean literal
> type boolean bool
> var b boolean = true
>
> // integer literal
> type integer int
> var i integer = 1
>
> // slice literal
> type strarr []string
> var strings []string = []string{"sfw"}
> var strs strarr = strings
>
> // pointer literal
> type stringptr *string
> var string1 string = "11"
> var ptr stringptr = 
>
>
>
>
>
>
> 在 2020年2月23日星期日 UTC+8下午9:19:34，Jimu Yang写道：
>>
>> I am reading the doc about Assignability in Golang Specification
>>  . It says:
>>
>> A value x is *assignable* to a variable
>>  of type T ("x is assignable to T")
>> if one of the following conditions applies:
>>
>>- ...
>>- x's type V and T have identical underlying types
>> and at least one of V or T is not
>>a defined  type.
>>- ...
>>
>>
>> type str string
>>
>> func main() {
>> string1 := "string"
>> var str1 str = "str1"
>> str1 = string1 // cannot use string1 (type string) as type str in
>> assignment
>> }
>>
>>
>> string1's type string and str have identical underlying type (string) and
>> string is not a defined type.
>>
>> So why cannot i assign string1 to str1?
>>
> --
> 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/55a9008d-a7f0-4de1-a420-57f6bbb19774%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/CAA40n-U3-J7ghx-tnaFg2XZgs118owu2z%3DGWDTg3%2BOdoF_Ow_A%40mail.gmail.com.

Re: [go-nuts] [Go Spec]Confused about Assignability in Golang Specification

[Jan Mercl]

Both string1 and str1 have defined types while the quoted specs rule says
"at least one of V or T is not a defined type.".

On Sun, Feb 23, 2020, 14:19 Jimu Yang  wrote:

> I am reading the doc about Assignability in Golang Specification
>  . It says:
>
> A value x is *assignable* to a variable
>  of type T ("x is assignable to T")
> if one of the following conditions applies:
>
>- ...
>- x's type V and T have identical underlying types
> and at least one of V or T is not
>a defined  type.
>- ...
>
>
> type str string
>
> func main() {
> string1 := "string"
> var str1 str = "str1"
> str1 = string1 // cannot use string1 (type string) as type str in
> assignment
> }
>
>
> string1's type string and str have identical underlying type (string) and
> string is not a defined type.
>
> So why cannot i assign string1 to str1?
>
> --
> 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/8fedba03-5aa1-4227-80c5-686a87a45cdd%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/CAA40n-VNBTMFFAETrgbXq8C6%3D5Ldjhr5mXQpQLMrHQPrnvM0YQ%40mail.gmail.com.

Re: [go-nuts] Re: Memory leak or GC feature ?

[Jan Mercl]

On Fri, Mar 6, 2020 at 4:55 PM Christophe Meessen <
christophe.mees...@gmail.com> wrote:

> It would have been convenient for detecting memory leaks to be able to
compare memory Alloc before and after the checked task and a really
complete GC.

That's not feasible. There are _always_ other runtime-started goroutines
running during execution of a program and they may allocate memory in no
predictable pattern.

Here's a sample run with Go 1.14 on Linux/amd64 (with added time stamps).

jnml@e5-1650:~/tmp/gc> date ; ./gc
Fri Mar  6 17:10:55 CET 2020
2020-03-06 17:11:15.47671116 +0100 CET m=+20.000226110 status: memUsed:
140296 allocs: 155 numGC 0
2020-03-06 17:11:35.476718873 +0100 CET m=+40.000234661 status: memUsed:
155376 allocs: 191 numGC 1
2020-03-06 17:11:55.476670923 +0100 CET m=+60.000185942 status: memUsed:
157248 allocs: 197 numGC 2
2020-03-06 17:12:15.476638267 +0100 CET m=+80.000153357 status: memUsed:
157264 allocs: 199 numGC 3
2020-03-06 17:12:35.476746762 +0100 CET m=+100.000262341 status: memUsed:
157264 allocs: 199 numGC 4
2020-03-06 17:12:55.476724863 +0100 CET m=+120.000240581 status: memUsed:
157280 allocs: 201 numGC 5
2020-03-06 17:13:15.476737116 +0100 CET m=+140.000252973 status: memUsed:
157280 allocs: 201 numGC 6
2020-03-06 17:13:35.476650054 +0100 CET m=+160.000165143 status: memUsed:
157376 allocs: 202 numGC 7
2020-03-06 17:13:55.476609855 +0100 CET m=+180.000124805 status: memUsed:
157376 allocs: 202 numGC 8
2020-03-06 17:14:15.476707245 +0100 CET m=+200.000222544 status: memUsed:
157472 allocs: 203 numGC 9
2020-03-06 17:14:35.47665699 +0100 CET m=+220.000172009 status: memUsed:
157568 allocs: 204 numGC 10
2020-03-06 17:14:55.476618049 +0100 CET m=+240.000133068 status: memUsed:
157776 allocs: 207 numGC 11
2020-03-06 17:15:15.476615426 +0100 CET m=+260.000130515 status: memUsed:
157768 allocs: 206 numGC 12
2020-03-06 17:15:35.476601977 +0100 CET m=+280.000116926 status: memUsed:
157768 allocs: 206 numGC 13
2020-03-06 17:15:55.476594814 +0100 CET m=+300.000109833 status: memUsed:
159528 allocs: 210 numGC 14
2020-03-06 17:16:15.476613143 +0100 CET m=+320.000128162 status: memUsed:
159528 allocs: 210 numGC 15
2020-03-06 17:16:35.476656056 +0100 CET m=+340.000171146 status: memUsed:
159528 allocs: 210 numGC 16
2020-03-06 17:16:55.476664258 +0100 CET m=+360.000179278 status: memUsed:
159528 allocs: 210 numGC 17
2020-03-06 17:17:15.476620428 +0100 CET m=+380.000135448 status: memUsed:
159528 allocs: 210 numGC 18
^C
jnml@e5-1650:~/tmp/gc>

As can be seen above, eventually the allocated memory goes down and
stabilizes, as predicted by Volker.

-- 
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/CAA40n-VEE15R9Lgpaq5RYAAb%3D6nwqOAx9UCgRL9A-B%3D1Lnc7eA%40mail.gmail.com.

Re: [go-nuts] Should it panic when set a channel to nil concurrently

[Jan Mercl]

On Mon, Mar 2, 2020 at 6:36 AM burak serdar  wrote:

> Why should it panic? The first goroutine simply sets the channel to
> nil. The second goroutine will either block reading from a non-nil
> channel, or block reading from a nil channel. There is no code in this
> program that would panic.

It can panic.

1) The channel receive sees that the channel is non nil
2) The other goroutine concurrently sets the channel to nil
3) GC kicks in and frees the channel memory
4) Something else allocates and overwrites the memory that was
previously used by the channel. That could be the GC itself.
5) The channel receive goroutine now continues to receive using memory
data that are no more representing a channel.

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

Re: [go-nuts] Should it panic when set a channel to nil concurrently

[Jan Mercl]

On Mon, Mar 2, 2020 at 6:56 AM burak serdar  wrote:

> At this point, channel receive is still holding a reference to the
> channel (right?), so GC cannot free it.

Depends very much on what code the compiler for channel receive
generates and on the code in the runtime that implements the channel
receive.

There are no data races that can be guaranteed 100% safe from the
language specification/memory model POV.

-- 
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/CAA40n-X2o4ttzSrpKzvhNbeyHFJdok5gpE-aMf6RJjjGLJoc7A%40mail.gmail.com.

[go-nuts] Re: [golang-dev] Go 1.14 Release Candidate 1 is released

[Jan Mercl]

On Wed, Feb 5, 2020 at 8:43 PM Carlos Amedee  wrote:

> We have just released go1.14rc1, a release candidate version of Go 1.14.

I am glad to report substantial improvements for a set of benchmarks of the
gocc
compiler[0], which is an experimental/WIP C compiler implemented in Go that
can
also produce Go code.

Note: The benchmarks are not benchmarking the compiler but the code
produced by the gocc compiler.



gocc commit bf916e5600, Tue Dec 24 17:01:06 2019 +0100

Go 1.13.7 linux/amd64

...

all_test.go:2092: goccgo   perlin.c   411.430ms  true  true
 true  13.769

...

all_test.go:2099: Considered tests: 24/24
all_test.go:2107:gcc   1.926479916s  1.000
all_test.go:2107:   gocc   2.084863963s  1.082
all_test.go:2107: goccgo   6.272091508s  3.256

Go 1.14rc1 linux/amd64

TestCompCert: all_test.go:2092: goccgo   perlin.c   159.321ms
 true  true  true   5.396

...

TestCompCert: all_test.go:2099: Considered tests: 24/24
TestCompCert: all_test.go:2107:gcc   1.945554301s  1.000
TestCompCert: all_test.go:2107:   gocc   2.073950104s  1.066
TestCompCert: all_test.go:2107: goccgo   4.853355485s  2.495



The cumulative index (gcc = 1) of executing a set of 24 benchmarks for the
Go backend went from 3.256
to 2.495 (-23%).

The worst performing test, perlin.c, was executing 13.769 times slower than
the code produced
by gcc with Go 1.13.7 and the Go backend. With Go 1.14rc1 this went down to
5.396 time slower (-60%).

Full results are enclosed in the attachments.



  [0]: https://godoc.org/modernc.org/gocc

-- 
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/CAA40n-UcH2n96EL4PU7%2B-Qbd6TcghZ%3DG0r2H6b4a2Q13E0%3DdTQ%40mail.gmail.com.


log-go1.13.7
Description: Binary data


log-go1.14rc1
Description: Binary data

Re: [go-nuts] Re: stringer command and generated String() function

[Jan Mercl]

On Tue, Feb 18, 2020 at 9:47 AM Brian Candler  wrote:
>
> Could you provide a link to where you found this code?  I imagine it was done 
> that way just for demonstrating some features of go, such as slicing and 
> array lookups.
>
> A simpler and faster way again would be to use a map.
> https://play.golang.org/p/ntjhesMsSA9

I don't see how could be map lookup possibly faster than slice
indexing. Have you some measurements to share?

Same applies to using the switch as suggested by Vincent.

In both cases, the branch predictor and or speculative execution in
modern CPUs, can completely mislead measuring small cases.

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

Re: [go-nuts] Re: stringer command and generated String() function

[Jan Mercl]

On Tue, Feb 18, 2020 at 10:37 AM Vincent Blanchon
 wrote:

> @Jan, yes definitely. By the way, here are some numbers from a benchmark I 
> made with 20 constants:
>
> name  time/op
> Stringer-4 4.16ns ± 2%
>
> StringerWithSwitch-4   3.81ns ± 1%
>
> StringerWithMap-4 28.60ns ± 2%

20 is a small number. In general, measuring things where one iteration
is in single digit nanoseconds can be misleading as discussed earlier.
The probably most important thing is how a chosen implementation
scales. To measure that, I suggest to make the number of the constants
in hundreds, if not thousands and having the loop exercise all the
paths, so the branch predictor cannot learn a single, happy one. In
any case, it's much safer to shift the time/op to at least
microseconds, otherwise the overhead of the test per se becomes
comparable to the measured thing and it just adds noise at minimum.

> @Pierre, the compilation check can also be done if we do not have a slice. In 
> my example with the switch, I still kept the compilation check.

I can't find any compile time check in your code (the one using the
switch) that can detect a constant has changed its value since
stringer was run.

-- 
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/CAA40n-WpoLbj9oeAH1nhNv%2BYROSFh1WGFN_5rBC41wnN%2B3aV6w%40mail.gmail.com.

Re: [go-nuts] Re: stringer command and generated String() function

[Jan Mercl]

On Tue, Feb 18, 2020 at 11:10 AM Vincent Blanchon
 wrote:

> @Jan Thank you for the feedback. I will try with a higher number of 
> constants. By the way, my benchmark tries all the path:
>
> func BenchmarkStringerWithSwitch(b *testing.B) {
>for i := 0; i < b.N ; i++  {
>   p := Pill(i%20)
>   _ = p.String()
>}
> }

That's IMO a very good approach. However, there's one potential trap.
The `_ = f()` thing may, or may not, get optimized away completely,
depending on the particular compiler and its version, if the compiler
can prove the called function is side effects free. The usual
workaround is, for example, to actually assign the returned value to a
package level variable _and_ read it afterwards. Like in

foo = p.String()
..

and later, just before returning

if foo == "" { // Assuming none of the string represenations are ""
b.Fatal()
}

-- 
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/CAA40n-XYxgR_D8XAtFX6JEd4%2BLAiTQumYxPZxdzH3vcVd1wi%3DQ%40mail.gmail.com.

Re: [go-nuts] Re: stringer command and generated String() function

[Jan Mercl]

On Tue, Feb 18, 2020 at 1:47 PM Vincent Blanchon
 wrote:

> However, in real code, I guess we will have that many constants, so it does 
> not make really sense to increase the number.

Design decisions may be driven by the desire to maximize the
performance in the average case or in the worst case scenario.

That's why Go has a regexp package that's slower in the average case
wrt PCRE, but it guarantees linear, not exponential, performance of
the worst case.

-- 
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/CAA40n-V8hcW5V-mJN8eALozxkUPD7mRuHBSkR%3DyrA1Yh0G7PZQ%40mail.gmail.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Jan Mercl]

On Tue, Feb 18, 2020 at 12:09 PM  wrote:
>
> Regarding pointers: For me, point number 2 (and 3) is the key that forces us 
> having some way of expressing emptiness in a pointer.

I'd say that nil pointers are not really special. It's just a sentinel
value. And we definitely need some sentinel value to mark the end of a
linked list, for example. If a language gets rid of nil/null
sentinels, it has to chose some other sentinel value for marking the
.next field as not being actually a next item in the list. So it does
not really solve much, if anything at all. And it enables completely
new bugs to exists in exchange for avoiding the nil/null pointer
dereference exception. Additionally it loses the nice and cheap HW
support for detecting of using the sentinel value on most CPUs.

-- 
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/CAA40n-WGNk5_QOzR75-AjQ65QU4Pn%3Dr9ixxSLHjcu5B7jwNQSQ%40mail.gmail.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Jan Mercl]

On Tue, Feb 18, 2020 at 12:44 PM  wrote:

> Well, other languages use the optional/maybe type.

The CPU does not care how humans call the abstraction. It has still to
do the same old thing: check some value for being equal/not equal to a
sentinel value or check a tag value for the same effect. That means
additional cost wrt to memory consumption. Additionally, now the
compiler may enforce the check everywhere when humans may know better.
So it buys more safety, undeniably, but as always, there are no free
lunches.

> The problem with nil-errors struck me hard in Go when I realized that, no 
> matter how many "recovers" I write in my server app, if a goroutine is 
> spawned and hits a nil pointer dereference, the whole server crashes. There 
> is no protection inside the language against this (let me know if there is a 
> way)

I'd say that's not solving the problem, but making it bigger. Do not
recover from nil panics, instead fix the nil dereference bug and avoid
the panic completely.

-- 
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/CAA40n-XVWcKk7-zN-5A%3DKTjA2LO7gyhv%2B63%2BB4Ftv1Ssih3NtA%40mail.gmail.com.

[go-nuts] Re: Proposal: Implement an interface based on function signature if method name is ambiguous. #37280

[Jan Mercl]

No need for a language change: https://play.golang.org/p/l7Cvf2fKzx4

-- 
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/CAA40n-WWkfdxQ77wVocD-rs9zYp-6oXB1oOe%3DuyamgWBa5GR3A%40mail.gmail.com.

Re: [go-nuts] Re: vim-go autocompletion / help for struct members / function parameters

[Jan Mercl]

On Sun, Feb 16, 2020 at 9:38 AM Johann Höchtl  wrote:
>
> Anybody? My question was not meant to criticize vim-go or gopls, if they 
> can't (yet) do what I want those tools to support me, but a honest questions 
> if I do not know how to use the tools.

I no more use vim-go, I've switched from vim-go to govim months ago,
so the only thing I can say is that AFAICT, both cases work for me in
govim. Struct fields are shown using , function arguments
documentation is available in a popup that's activated on mouse
hovering over the function 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/CAA40n-W0X2DH5VXK%3DGYdxZDgESaP0fzbQBkbOYBYbybR4rPowg%40mail.gmail.com.

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

[Jan Mercl]

On Wed, Feb 19, 2020 at 7:26 PM Wojciech S. Czarnecki  wrote:

> https://github.com/golang/go/issues/37299

"I propose to add an opt-in go fmt solution meant to minimize
whitespace changes to the block where a code author hinted at desired
comments position."

I believe the absence of any gofmt knobs (opt-ins) is a feature that's
not going away. You can always use your private fork, if you want. But
most people will not accept code that is not formatted by the
"standard" gofmt. Because again, the uniformity is the whole point of
gofmt's existence.

-- 
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/CAA40n-U%3DMomr0MMZcSpt5OdajMXF97G1XqmYhm8LLKVAiLXccA%40mail.gmail.com.

Re: [go-nuts] Language spec question: why is k, v := k, v allowed in a for loop with range?

[Jan Mercl]

On Sun, Jan 12, 2020 at 10:10 AM Silvan Jegen  wrote:

> So the declaration of the variables in the for loop itself is in outer
> scope compared to the body of the for loop?

The outer scope begins immediately after the keyword "for". The inner
one is an ordinary block scope and it begins immediately after the
'{'.

> In that case, redeclaring them
> in the inner scope (== the loop body) would not be allowed either, no?

This is valid: { a := 42; f(a) { a := 24; f(a) }}

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

Re: [go-nuts] Is the GC recovering storage when full slice expression reduce capacity ?

[Jan Mercl]

On Sat, Jan 11, 2020 at 4:43 AM  wrote:

>> But there's one guarantee - the "dead" slice portion after
>> cap will not be scanned by the collector if no other live object uses
>> it.
>
>
> That's not correct. If there is a reference to an object, the entire object 
> is live and is scanned, regardless of what the reference(s) looks like (ptr, 
> slice with small cap, slice with large cap).
> Again, this isn't in the spec - in principle the GC could not scan past the 
> largest capacity. But we don't currently do that.

Might be a low hanging optimization opportunity. But proving no other
references exist is possibly the blocking issue.

-- 
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/CAA40n-WXF0ToQV8Uv4JzXatgeXapo%2BpDyf-ik2j_yS40j6tytg%40mail.gmail.com.

Re: [go-nuts] Is the GC recovering storage when full slice expression reduce capacity ?

[Jan Mercl]

On Fri, Jan 10, 2020 at 9:52 AM Christophe Meessen
 wrote:
>
> It is possible to reduce the capacity of a slice by using the full slice 
> expression (https://golang.org/ref/spec#Slice_expressions).
>
> Now consider the following code where a is a 1MB slice. I then create b, a 
> slice of a, but with a much smaller capacity. Finally, I change the value of 
> a so that only b refers to the slice element storage.
>
> a := make([]byte, 100)
> b := b[:3:3]
> a = nil
>
> Will the garbage collector be able to recover the inaccessible space in the 
> slice element storage ?

Specification does not directly define this, so the answer is -
possibly. AFAICT, no current Go compiler can free partial heap
objects. But there's one guarantee - the "dead" slice portion after
cap will not be scanned by the collector if no other live object uses
it.

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

Re: [go-nuts] Enforcing a type name rather than a variable name

[Jan Mercl]

On Sat, Jan 4, 2020 at 12:28 AM  wrote:
>
> Hello,
>
> Is there any way to avoid the compilation error "*error is not a type" of 
> this example https://play.golang.org/p/gWNStGSCfTm ?
> I understand the variable named `error` hides the type named `error` but is 
> there some other syntax to specify the error type?

No. In every scope a name binds to only one thing. Once a variable
name in an inner scope hides a type name in an outer scope that type
is no more accessible unless it's also aliased to a different name and
that alias is not shadowed as well.

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

Re: [go-nuts] Assigning a value to a function pointer

[Jan Mercl]

On Mon, Dec 23, 2019 at 6:41 PM  wrote:

>> > But I cannot find any way of assigning a value to the function pointer `f` 
>> > even using the `unsafe` package.
>>
>> https://play.golang.org/p/qP5kuSCW6dO
>
> Thanks, unfortunately the asm shows that what gets into `f` is the stack 
> address of `f0` and not the address of the function:

Nothing unfortunate about it, that's a perfectly correct value. I
mentioned before that you don't want a pointer to a function but a
function value, that one is found in f0 in the example.

However, the value of f0 is _not_ the function's code address. Go
function values are a pointer to a variable length structure that
supports the closes over variables of the function.

-- 
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/CAA40n-W3%3Dm-r%3DYQtnwbQOmyA31GegS4tu5Wqm4oi9s0Bh2QOgw%40mail.gmail.com.

Re: [go-nuts] Re: C++ 11 to Golang convertor

[Jan Mercl]

On Mon, Apr 6, 2020 at 6:08 PM Andy Balholm  wrote:
>
> In looking back over some of these old conversations about converting C to 
> Go, I realized that there is some confusion about the different programs 
> named "c2go". There are basically 2:

Make it 3 please: modernc.org/gocc. Experimental, work in progress
etc., but I'd be grateful if anyone gives it a try and reports back
the failures.

-- 
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/CAA40n-XEETSLmQdW%2BwpN8k9BZwz3ABTavvMJgNvvup0BD4iiOw%40mail.gmail.com.

Re: [go-nuts] project mdencode first random file signature

[Jan Mercl]

On Sun, Jan 14, 2018 at 5:37 AM ankarame  wrote:

> mdencode is written in golang and uses an interface for pluggin formatters.

The name of the language is Go. There's no golang language.

-- 
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/CAA40n-XoJo9hAb74kfVo6bmLcUcA_HK4-6TjUuTs3L%2BKJrnAnA%40mail.gmail.com.

Re: [go-nuts] project mdencode first random file signature

[Jan Mercl]

On Mon, Apr 6, 2020 at 10:20 AM ankarame  wrote:

> That's not the point. It can be referred to as Golang.

Here's the point. One thing is how you call it and you _can_ call it
any way you like. The other thing is that there's no golang language.

I can call you John Lennon but you're not becoming him because of that.

-- 
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/CAA40n-UQ-quqb70ZJtnXnUAWip9mvw8b%3DSb%3D21z7Obdn-_Zg7Q%40mail.gmail.com.

Re: [go-nuts] project mdencode first random file signature

[Jan Mercl]

On Mon, Apr 6, 2020 at 10:00 AM ankarame  wrote:

> You can refer to it as Golang.

You can call it any way you like. But still there's no golang
language. Never was.

-- 
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/CAA40n-Wp49AoZPg0L1WZVMDmiNsNVMqy7pcE5k-r6nR0dtX5dA%40mail.gmail.com.

Re: [go-nuts] Does os.exec work ?

[Jan Mercl]

On Wed, Mar 25, 2020 at 7:30 PM  wrote:
>
> This simple command works correctly when submitted via the terminal, but the 
> same command submitted to os.exec does not !!
> .. and I can`t understand why...

os.Exec does not pass commands to the shell, but it is the case in the
terminal. Try something like this (not tested)

cmd := exec.Command("sh", "-c", "echo foo bar | tee test") // Just an
example, this is not fixing your code.

-- 
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/CAA40n-XR1-SEHQsNNDQ4bqSxLRY7DV-Zm%2Bi17%2B63-RqNU9j4Kg%40mail.gmail.com.

Re: [go-nuts] Re: Slice reuse + GC

[Jan Mercl]

On Fri, Mar 27, 2020 at 8:19 AM Leszek Kubik  wrote:

> A fix for the situation of the topic could be implemented by the slice type. 
> Imagine, if a slice value not only shared the pointer to the underlying 
> buffer but also a list with references to all other slices holding on to the 
> underlying buffer then such operation as s = s[x:y] could walk the list, find 
> and free all unreferenced values in the underlying buffer (perhaps even 
> assigning zero value to have consistent behavior regardless of []T or []*T). 
> Such operation would be deterministic. Of course there could be an 
> optimization in place, whenever the slice was derived from a named array, 
> just keep some flag instead of the list of references to all other slices. I 
> don't see how GC could achieve that in a consistent way since the GC may not 
> even do the swipe between calls like s = s[:x]; s = s[:cap(x)]. Unfortunately 
> I'm afraid that this would break some existing code (even if we also trim the 
> cap property) thus keeping in mind the original notion of a slice as a window 
> to some array makes sense to me.

For many, if not most programs the current approach is quite ok. The
suggested solution is non trivial, especially in terms of runtime and
memory consumption costs. Not only _all_ programs will get slower, but
the added memory overhead can sometimes dwarf the memory savings.

If a specific program has the problem of "zombie" slice elements,
which is BTW the same problem as keeping a short string sliced from of
a huge string, then in both the cases the solution is to make a copy
of the part that is needed to keep, thus allowing the GC to take care
of the original backing array.

-- 
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/CAA40n-WVFpUQDmf0oohmCG4tfSstUcszVJcgNnbAHs%2BJxHM%3DXg%40mail.gmail.com.

Re: [go-nuts] project mdencode first random file signature

[Jan Mercl]

On Mon, Apr 6, 2020 at 2:38 PM ankarame  wrote:

> The user group is named golang-nuts.
> Not go-nuts.

Yes, the _mailing list_ named golang-nuts definitely exists. We are
right here. Still there's no golang language. Never was.

Maybe someone creates one in the future. Google index/search will have
some fun figuring things out.

-- 
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/CAA40n-VGKTf3wKfhyqNdzniJa%2BRV7BDR99Z6X9wm3xaO-DE32g%40mail.gmail.com.

Re: [go-nuts] Converting a C char[] to []byte of string with cgo

[Jan Mercl]

On Thu, Apr 30, 2020 at 8:17 PM Dean Schulze  wrote:
>
> I must be missing something pretty simple, but I have a C struct like this:
>
> typedef struct line
> {
> char hostname[HOSTNAME_MAX];
> char ip[IP_MAX];
> ...
> }
>
> When I try to do the simple thing
>
> C.GoString(p.hostname)

An array of a fixed size within a C struct is a value (the same as in
Go), but C.GoString expects a pointer to a C.char. Try
`C.GoString()`.

Not tested. Note that if hostname is not properly zero terminated,
your code will crash or misbehave.

(Automatic array decay applies to C code, but not in Go.)

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

Re: [go-nuts] Converting a C char[] to []byte of string with cgo

[Jan Mercl]

On Thu, Apr 30, 2020 at 10:06 PM Dean Schulze  wrote:
>
> That gives this error (which I've gotten with just about everything I try):
>
> cannot use _name (type *[25]_Ctype_char) as type *_Ctype_char in 
> argument to _Cfunc_GoString

Oh yeah, should have been probably `C.GoString([0])`.
Forgot Go has stronger type discipline than C. (Not tried still.)

-- 
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/CAA40n-UCTF6U-fa-652vXMM_dc9AFfufZo1YQ%2BBEAniCcJp4HA%40mail.gmail.com.

Re: [go-nuts] Packet parsing in Go

[Jan Mercl]

On Tue, Apr 21, 2020 at 6:08 PM Rakesh K R  wrote:

> In C, we used to typecast this array of uint8_t to predefined structure.

Go has no casts. Regardless, one can do something similar using
unsafe. But then - how it's planned to deal with the situation when
the machine endianess does not match the order of the bytes in the
packet?

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

Re: [go-nuts] Any solution to hide my source code written in Go and make it a library to develop in Go as well

[Jan Mercl]

On Sat, May 16, 2020 at 9:11 PM Billy Cui  wrote:

> I searched all the websites for such a solution, until Go1.2 there was a 
> buildmode archive, but it did not supported after 1.2, in the mean time, it 
> really don't have enough source code protected.
>
> Then I try use buildmode c-archive/c-shared, of course c-archive is much 
> better, but both of them works not expected as my thought, it's long code so 
> I posted on stackoverflow:
>
> https://stackoverflow.com/questions/61817655/go-build-with-static-library-generate-by-go-itself
> https://stackoverflow.com/questions/61813996/go-call-so-file-built-in-golang-buildmode-c-shared

The only technical measure that can be reasonably expected to possibly
prevent reverse engineering of a compiled program is not giving anyone
access to it in the first place.

Protect your rights legally. Any kind of DRM does not really work.

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

Re: [go-nuts] Packages "Not found" at godoc.org

[Jan Mercl]

On Sun, May 10, 2020 at 11:22 AM Sebastien Binet  wrote:

> It seems like gitlab is going through some maintenance work (I get a 503 when 
> trying to reach the files of the packages you labeled as working).
> Perhaps it's just that (and some caching effect)?

Ah, you're right, now I'm getting a 503 from gitlab.com as well. When
I tried the same before OP it still worked.

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/CAA40n-VY%3DKSKfxRff7cvhVA8-9A3rRKJWMS1wHv6vvggerAQCg%40mail.gmail.com.

[go-nuts] Packages "Not found" at godoc.org

[Jan Mercl]

It came to my attention that some of my packages are not accessible at
godoc.org at the time of this writing (09:05 UTC).

A sample of URLs that report "Not Found":

https://godoc.org/modernc.org/strutil
https://godoc.org/modernc.org/mathutil
https://godoc.org/modernc.org/cc
https://godoc.org/modernc.org/b
https://godoc.org/modernc.org/gocc
https://godoc.org/modernc.org/qbe

It seems the problem is not in the redirector as at least some other
packages/commands work as usual, for example:

https://godoc.org/modernc.org/golex
https://godoc.org/modernc.org/ql
https://godoc.org/modernc.org/kv
https://godoc.org/modernc.org/sqlite

Has anyone a similar experience and/or some insight into the problem?

-- 
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/CAA40n-UM4%2BGu4ZeP_9_S2r_Rb8DWcp1X2aWUzv-hXV3DeD3u7A%40mail.gmail.com.

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

[Jan Mercl]

On Fri, May 8, 2020 at 2:46 PM  wrote:

> Or do I just fail to see the obvious...

'int' _is_ a defined type. It's predeclared in the universe scope.

-- 
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/CAA40n-X8o5M_bVOELywzN3TeU7dUbEbROVrAY7VzeDJko-vSDA%40mail.gmail.com.

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

[Jan Mercl]

On Fri, May 8, 2020 at 3:29 PM Christoph Berger
 wrote:

> So I conclude that the assignment of *int to intp succeeds because *int is 
> not a defined type and both *int and intp have the same underlying type *int.
>
> Looking through the ref spec I found a couple of places that mention some 
> defined types (esp., all numeric types and string). Is there an exhaustive 
> list available of all predefined types that technically count as defined 
> types?

Predeclared types are listed here:
https://golang.org/ref/spec#Predeclared_identifiers in the section
"Types:"

Note that they do not "technically count". If 'name' is binded to a
type in a declaration then type 'name' is a defined type. The rule is
universal. The difference is that eg. `*int` is not a name
(identifier), so it's a type literal defining a pointer to a
named/defined type.

-- 
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/CAA40n-U9L6f7jPTFSMZQYXcw9wumv0E7o0tnZt-SY2R5yjFhGw%40mail.gmail.com.

Re: [go-nuts] Waitgroup.done wont Panic?

[Jan Mercl]

On Thu, May 14, 2020 at 8:18 AM sperberstephan via golang-nuts
 wrote:
> Here:
> https://play.golang.org/p/76AzuAiVGxL
>
> I thougt If the waitgroup gets below 0 there should be a Panic.
> I understand that the goroutine is canceled. So maybe the defer Statement is 
> Not executed.
> But why is there No warning at the end of Main that some goroutines Had to be 
> canceled?

wg.Wait at line 18 does not wait for anything and the program exists
before the goroutine executing func worker even starts. IOW, wg.Done
at line 10 is not executed hence no panic.

-- 
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/CAA40n-Wd3PzEqG-9xjYT8_qAvR8KEKDwYSMz_YgN-5KhSBrKKA%40mail.gmail.com.

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

[Jan Mercl]

On Fri, May 8, 2020 at 4:31 PM Christoph Berger
 wrote:

> Unfortunately, the connection between "predeclared" (or "implicitly declared" 
> as the first paragraph says) and "defined" is not at all obvious. Especially 
> as the definition of "defined type" refers to types explicitly declared via 
> the "type" keyword.

The definition of "defined type" is correct and simple, no special
rules exists. The predeclared identifier `int` is declared that way,
except it's done by the compiler without the need to do it in user
code. See here: https://godoc.org/builtin#int

Of course, the builtin package is only a formal definiton, it has
special treatment by the compiler, so doing the same in user code
would be invalid. Still `int` is defined and treated as `type int
something` and it's thus a defined(named) type.

In the first approximation, any type represented by a name is a
defined type. Later came type aliases, so now it's a bit more
complicated b/c one can write also `type T = []U` where T is not a
defined type b/c []U is not a defined type.

-- 
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/CAA40n-WzJAWpg4TEcW%2BZ2G-1zcUFNiSS0ezJtz6077Z4U3uwUQ%40mail.gmail.com.

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

[Jan Mercl]

On Fri, May 8, 2020 at 5:57 PM Axel Wagner
 wrote:
>
> I'm happy to report, that I *think* I found an inconsistency with error not 
> being a defined type:
> https://play.golang.org/p/gpy6S17wzIM

I don't follow. Type of x is not a defined type and neither is type of
y. The underlying type of x is not the same as the underlying type of
y.

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

Re: [go-nuts] append slice concurrently without lock，after that panic occurred when iterate the slice

[Jan Mercl]

On Mon, Mar 9, 2020 at 4:16 PM Yuu LongXue  wrote:
>
> Hi all,
>
> Slice is not thread safe for write operation if without lock, this is true 
> and I know this feature. but recently, I got a panic which caused by writing 
> a slice concurrently with out lock occasionally and I can't figure out why.
>
> ### the process as below:
>   1. define a slice: var x []string
>   2. append to x concurrently without lock in multi goroutines
>   3. wait all goroutines to be done
>   4. iterate the x slice, panic occurred when read some element with index 
> i (i > 0 && i < len(x)-1) in the x
>
> ### the question is:
> In this case, the element with index 0 and index len(x) - 1 is ok to read, 
> but it exists a x[i](i > 0 && i < len(x)-1) that can't be 
> read and it will lead to panic[invalid memory address or nil pointer 
> dereference];

Slice is a multi word value. So writing it concurrently is not atomic
and it may eventually produce a value that's a mix of the concurrently
written values. After append it may happen that the slice's pointer to
the backing array points incorrectly to the old value but the len and
capacity are for the new value. Then it may happen that one can index
only to a certain extent, lower than would be using a non corrupted
slice value. Exact failure modes can be only guessed without more
info.

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

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

[Jan Mercl]

On Fri, May 8, 2020 at 10:58 PM 'Axel Wagner' via golang-nuts
 wrote:

> Well, that's what the nomenclature used to be. It was changed, because the 
> term got ambiguous and confusing once type-aliases got introduced. Turns out, 
> it's still confusing because people confuse "defined" and "declared".

Every name that represents a type and does not stand for a type alias
is a defined, formerly named type. The essence is in the existence of
the name for the type. If it's declared in user code of magically by
the compiler does not matter.

-- 
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/CAA40n-ULQuLo2s8sBbnxqTXVXA5Wvh9yirRAqQMjNbu%3DGQT4pw%40mail.gmail.com.

Re: [go-nuts] Weird problem that CPU is nearly 100%

[Jan Mercl]

On Fri, May 22, 2020 at 9:05 AM tokers  wrote:
>
> Thanks for you reply.
>
> Yeah, we have the plan to upgrade our go version to 1.13.10.

Note that 1.13 does not have goroutine preemption Ian was talking
about wrt 1.14.

-- 
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/CAA40n-V89dbZMuvkQ4ye13fRfvtYm-0_hJB%2B8a9fGS0JZwVT%3Dw%40mail.gmail.com.

Re: [go-nuts] go install puts my library .a file in the local directory instead of first component of GOPATH

[Jan Mercl]

On Sun, Sep 6, 2020 at 9:15 PM Dean Schulze  wrote:

> When I execute go install datepackage I get

This is may or may not be the cause, but please note that import paths
without a dot, like the one quoted above, are reserved
(https://github.com/golang/go/issues/32819#issuecomment-566671328) for
the stdlib and the toolchain, but the documentation has not yet been
updated.

-- 
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/CAA40n-ULciN38qsNL%2BZUsiDc3P2%2BR8Mz13%2BgNjNv4BMqo663Hg%40mail.gmail.com.

Re: [go-nuts] linux/arm struct alignment seems wrong

[Jan Mercl]

On Wed, Sep 9, 2020 at 1:45 PM 'Dan Kortschak' via golang-nuts
 wrote:

> I think it comes down to these lines in src/cmd/internal/sys/arch.go
> [1]
>
> ```
> var ArchARM = {
> Name:  "arm",
> Family:ARM,
> ByteOrder: binary.LittleEndian,
> PtrSize:   4,
> RegSize:   4,
> MinLC: 4,
> }
>
> var ArchARM64 = {
> Name:  "arm64",
> Family:ARM64,
> ByteOrder: binary.LittleEndian,
> PtrSize:   8,
> RegSize:   8,
> MinLC: 4,
> }
> ```
> this line in src/cmd/compile/internal/gc/main.go [2]
> ```
> Widthreg = thearch.LinkArch.RegSize
> ```
>
> and these lines in src/cmd/compile/internal/gc/align.go [3]
> ```
> case TINT64, TUINT64, TFLOAT64:
> w = 8
> t.Align = uint8(Widthreg)
> ```
>
> [1]https://golang.org/src/cmd/internal/sys/arch.go
> [2]https://golang.org/src/cmd/compile/internal/gc/main.go
> [3]https://golang.org/src/cmd/compile/internal/gc/align.go

Thank you very much for the thorough investigation.

If the intent is to have Go alignments/offsets of types compatible
with the C ABI then I think it's safe to say this is a bug.

And the existence of the syscall package, in some cases passing
Go-defined structs to the kernel that must be binary compatible with
their C definitions, IMO suggests that the intent is indeed 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/CAA40n-UFLsy0%3DSAWR3CM2YqVTWcEAgfQpkRaAn0LWkSQ%3DWeTcw%40mail.gmail.com.

Re: [go-nuts] linux/arm struct alignment seems wrong

[Jan Mercl]

On Wed, Sep 9, 2020 at 1:09 PM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> What does cgo -godefs give you? On my amd64 and arm64 I get this:
>
> ```
> ~/cznic $ cat main.go
> package main
>
> /*
> struct s {
> long long i;
> } x;
> */
> import "C"
>
> type S struct {
> i int64
> }
>
> type C_s C.struct_s
>
> ~/cznic $ go tool cgo -godefs main.go
> // Code generated by cmd/cgo -godefs; DO NOT EDIT.
> // cgo -godefs main.go
>
> package main
>
> type S struct {
> i int64
> }
>
> type C_s struct {
> I int64
> }
> ```

amd64
=

jnml@e5-1650:~/tmp$ go version
go version go1.15.1 linux/amd64
jnml@e5-1650:~/tmp$ cat main.go
package main

/*
struct s {
long long i;
} x;
*/
import "C"

type S struct {
i int64
}

type C_s C.struct_s
jnml@e5-1650:~/tmp$ go tool cgo -godefs main.go
// Code generated by cmd/cgo -godefs; DO NOT EDIT.
// cgo -godefs main.go

package main

type S struct {
i int64
}

type C_s struct {
I int64
}
jnml@e5-1650:~/tmp$

arm
===

pi@raspberrypi:~/src/tmp.tmp $ go version
go version go1.15.1 linux/arm
pi@raspberrypi:~/src/tmp.tmp $ cat main.go
package main

/*
struct s {
long long i;
} x;
*/
import "C"

type S struct {
i int64
}

type C_s C.struct_s
pi@raspberrypi:~/src/tmp.tmp $ go tool cgo -godefs main.go
// Code generated by cmd/cgo -godefs; DO NOT EDIT.
// cgo -godefs main.go

package main

type S struct {
i int64
}

type C_s struct {
I int64
}
pi@raspberrypi:~/src/tmp.tmp $

No difference between the outputs AFAICT. Seems good to me.

-- 
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/CAA40n-Xj22QAWdU-CjxibUhBEwxChm-HOORUUxbpfG2ihY0Sjg%40mail.gmail.com.

[go-nuts] linux/arm struct alignment seems wrong

[Jan Mercl]

Observation:

pi@raspberrypi:~/src/tmp.tmp $ go version
go version go1.15.1 linux/arm
pi@raspberrypi:~/src/tmp.tmp $ cat main.go
package main

/*

struct s {
long long i;
} x;

size_t align() {
return _Alignof(struct s);
}

*/
import "C"

import (
"fmt"
"unsafe"
)

type S struct {
i int64
}

func main() {
fmt.Printf(" C alignof struct s: %v\n", C.align())
fmt.Printf("Go alignof struct s: %v\n",
unsafe.Alignof(C.struct_s{}))
fmt.Printf("Go alignofS: %v\n", unsafe.Alignof(S{}))
}
pi@raspberrypi:~/src/tmp.tmp $ go run main.go
 C alignof struct s: 8
Go alignof struct s: 4
Go alignofS: 4
pi@raspberrypi:~/src/tmp.tmp $ uname -a
Linux raspberrypi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l
GNU/Linux
pi@raspberrypi:~/src/tmp.tmp $

My code relies on all the numbers being the same, ie. that Go will report
the same as C for both C.struct_s{} and S{}.
AFAICT Go and C agree on struct layout on linux/{amd64,386} perfectly in
all cases I've tested (thousands probably).

Is this a bug or are my expectations ill founded?

Thanks in advance for any insights.

-- 
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/CAA40n-Vdqc6QLzsYWgmzCRMvChiLbP1geLTWLpqF8Pw-ygqrAA%40mail.gmail.com.

Re: [go-nuts] linux/arm struct alignment seems wrong

[Jan Mercl]

On Wed, Sep 9, 2020 at 12:41 PM Dan Kortschak  wrote:

> I get the following
>
> ```
>  C alignof struct s: 8
> Go alignof struct s: 8
> Go alignofS: 8
> ~/cznic $ go version
> go version go1.15.1 linux/arm64
> ~/cznic $ uname -a
> Linux bildr 4.19.0-10-arm64 #1 SMP Debian 4.19.132-1 (2020-07-24)
> aarch64 GNU/Linux
> ```
>
> I have an arm64 linux running on my pi, maybe the armv7l behaviour is
> different.

Seems to be the case as armv7l is AFAIK a 32 bit only CPU. And arm64
is next on the list of my targets so thank you for the information.

But the question is still the same. Is it a bug or is my assumption
about Go and C agreeing on alignments/offsets invalid? I realizethe
specs say nothing in this regard.

-- 
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/CAA40n-XvvraqMF_5boDqFo%3DSVLdTo79bX-AJyAfQBJxVu1Tx4A%40mail.gmail.com.

Re: [go-nuts] linux/arm struct alignment seems wrong

[Jan Mercl]

On Wed, Sep 9, 2020 at 8:17 PM Ian Lance Taylor  wrote:

> Exact alignment/offset compatibility with the C ABI is not a goal.
> Sorry.  (It's actually harder than one might think to maintain that
> kind of compatibility.  For example, on x86, the C ABI uses one
> alignment for double variables and a different alignment for double
> variables that appear as a field in a struct.  Unless, of course, you
> use the -malign-double option.  And more generally some platforms have
> multiple C ABIs, including x86 if you count the MCU psABI.)
>
> The Go structs in the syscall package that need to match C structs are
> carefully written to work correctly.
>
> You may find the cgo -godefs option to be helpful, as it provides Go
> structs that exactly match C structs, given a particular set of
> compiler options.

Thanks a lot for the clarification. Assuming that IIRC, cgo -godefs
acquire the alignment/offset info by invoking the C compiler, it's
unfortunately not a good option for a project that aims to avoid CGo
in the first place. But I now think there's a feasible solution to
this problem, having not as high a cost as I feared first when reading
your answer. I shall see tomorrow.

Thanks again.

-- 
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/CAA40n-Vq1d2mFwmb4FVjuAdmCfa%3Du%2BoNBqEoGmY%2B_ba2j5WBWw%40mail.gmail.com.