Re: [go-nuts] CGO - Passing pointer to C

C. Thank-you, Robert On Tuesday, 3 December 2019 22:39:35 UTC-5, Ian Lance Taylor wrote: > > On Tue, Dec 3, 2019 at 7:20 PM Robert Johnstone > wrote: > > > > The section on passing pointer to C in the cgo documentation is quite > clear that letting C hold pointer to G

[go-nuts] CGO - Passing pointer to C

Hello, The section on passing pointer to C in the cgo documentation is quite clear that letting C hold pointer to Go memory is not allowed. I'd like to better understand the limitation. Frankly, because of the architecture of a system I'm working on, the inability to transport pointers is

Re: [go-nuts] Enforce immutability through static analysis

This comment is a little unfair. There was at one time efforts to allow const as part of the type system. I believe that the specific motivation was to allow []const byte to ease conversions are eliminate conversions from strings. The current duplication of bytes and strings packages is a

Re: [go-nuts] Utility functions for package testing that read the source code

use they're entitled to read file > resources from there (for example from the testdata directory), so running > a test binary on a separate machine isn't useful in general unless you pull > across the other files too. > > > On Tue, 24 Sep 2019 at 14:52, Robert Johnstone > wrote

[go-nuts] Utility functions for package testing that read the source code

I recently found the package github.com/matryer/is , and really liked its trick of loading the source code (found using runtime.Callers) so that the the messages for test failures could be created automatically. Enough that I experimented with my own

[go-nuts] Modules for packages without dependencies

Hello, I'm looking at what I should do to keep my packages current with respect to modules. The tutorials have covered top-level packages, but I haven't seen any discussions around low-level packages. In particular, I have some low-level packages that rely only on the standard library. It's

[go-nuts] Re: Does this code safe?

In theory, the non-atomic store could tear with respect to the atomic load. On Friday, 5 July 2019 10:53:05 UTC-4, Cholerae Hu wrote: > > package main > > import ( > "sync/atomic" > "sync" > ) > > func main() { > var n int32 > var m sync.Mutex > var wg sync.WaitGroup > wg.Add(2) > go func() { >

[go-nuts] Re: A good indicator of code quality

You can look at https://goreportcard.com/ to get a look at some common metrics. There are also quite a few different linters (golint, revive, staticcheck, plus others). Robert On Thursday, 6 June 2019 15:58:19 UTC-4, Carl wrote: > > I'd like to know what people are using to measure the

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

Hello, I'm not sure that Min and Max need to be in the 80%. It's annoying to write them repeatedly, but they are also very short. The place where I typically miss generics is larger chunks of code, such as concurrency patterns. I'm certain others are looking at datatypes. Why do Min and

[go-nuts] [ANN] New package to convert loops into versions with concurrency

Hello Everyone, I'd like feedback on a new package designed so that it is easy to convert loops into version with limited concurrency. The concurrency is limited in the sense that the number of tasks running in parallel is limited, but otherwise you should be able to convert any loop into a

Re: [go-nuts] floating point question

There are multiple bit-representations for NaN, so even then, you can't compare for equality. On Monday, 15 April 2019 12:59:28 UTC-4, David Riley wrote: > > On Apr 15, 2019, at 12:47 PM, Miki Tebeka > wrote: > > > > On Monday, April 15, 2019 at 2:12:18 PM UTC+3, Jan Mercl wrote: > > > >

[go-nuts] Re: go test cover with args, coverage flag has been treat like an args.

Hello, I'd suggest wrapping your main to create a more testable interface. For example, see https://play.golang.org/p/_Zund5W4fb5. On Thursday, 11 April 2019 04:57:24 UTC-4, hui zhang wrote: > > my program take 4 args like > ./myprogram 1 2 3 4 > *args_len=: 5* > I want to test

[go-nuts] Re: Accessing *[]uint64 from assembly - strange memory corruption under heavy load - any ideas?

I don't see any memory barriers in your assembly. If you are modifying the backing array while it is being scanned by the GC, there could be some interaction. I don't know enough about the GC internals to say more than that. If you look at when memory barriers are inserted by the Go

[go-nuts] Re: why slice[len:len] okay, but slice[len] fail?

Hello, When you use the colon, you taking a subset of the data. Further, the notation is a closed/open. So a slice primes[6:6] is all of the element in the array with index >= 6 and index < 6, which is an empty set. Note that the type of the expression primes[6:6] is []int. When you don't

[go-nuts] Re: [ANN] goey - Declarative, cross-platform GUIs

> Thanks for the great work, > > > On Thursday, September 6, 2018 at 12:07:41 AM UTC-4, Robert Johnstone > wrote: >> >> This is an initial announcement of goey, a package for declarative, >> cross-platform GUIs. The range of controls, their supported properties and >>

[go-nuts] Re: [ANN] goey - Declarative, cross-platform GUIs

Hello, I'm glad that you are finding it useful, and I'm certainly taking bug reports. You could always submit a pull-request, but that would require an account with bitbucket. I have changed the settings for the issue tracker to accept anonymous users. If you try again, you should be able

[go-nuts] When marshalling values, should panics be preserved?

Hello, I'm working on a GUI library, and one of the facilities provided is a way to execute code on the GUI thread. The call site is pretty simple: err := Do(func() error { // Inside this closure, we will be executing only on the GUI thread. _, err := fmt.Println("Hello.") //

Re: [go-nuts] Using "er" and "able" for interfaces

Hello, Just to paint the bikeshed... The -er suffix makes sense for methods that follow the convention of naming methods after verbs. Forget io.Reader for a moment, and think of os.File. When you call the method Read, you are asking the instance to read from the file on disk. myvar.Read

[go-nuts] Re: is it possible to speed up type assertion?

Hello, Separate question, why are you passing an unsafe pointer to writer? You are (probably) forcing that int to escape to the heap. If you want to write an uint64, pass in a uint64. 1) I suspect that you are using pointer arithmetic inside writer, don't. The code will not be portable.

[go-nuts] Re: [ANN] goey - Declarative, cross-platform GUIs

Hello, In case anyone is still following, the readme includes some screenshots. https://bitbucket.org/rj/goey/src/default/README.md - Robert On Thursday, 6 September 2018 00:07:41 UTC-4, Robert Johnstone wrote: > > This is an initial announcement of goey, a package for declarative, &

Re: [go-nuts] [ANN] goey - Declarative, cross-platform GUIs

Look interesting. Thank-you for the link. - Robert On Friday, 14 September 2018 14:00:53 UTC-4, Robert Engels wrote: > > Robert, > > You might want to look at https://github.com/fyne-io/fyne > > R > > On Sep 11, 2018, at 8:24 AM, Robert Johnstone > wrote

Re: [go-nuts] Re: [ANN] goey - Declarative, cross-platform GUIs

I’d love to see the same ‘demo program’ run side by side between > linux and windows to check the fidelity - because this could be a show > stopped. > > Any plans for a more involved demo application? > > > On Sep 10, 2018, at 12:06 PM, Robert Johnstone > wrote: > &g

Re: [go-nuts] Re: [ANN] goey - Declarative, cross-platform GUIs

at least in general terms - rather than just looking at > the existing code and making a guess > > On Sep 7, 2018, at 10:01 AM, Robert Johnstone > wrote: > > Hello, > > I would be very happy to support macOS, but unfortunately I don't have any > experience on that

Re: [go-nuts] A thought on contracts

On Fri, 7 Sep 2018 at 15:56 Robert Johnstone > wrote: > >> Hello, >> >> This seems more like a question for tooling. It has already been >> discussed that there should be a tool to read a body and provide a >> minimised or canonical contract. Perhaps we for

[go-nuts] Re: [ANN] goey - Declarative, cross-platform GUIs

acOS support to this? > > - Rich > > On Wednesday, September 5, 2018 at 9:07:41 PM UTC-7, Robert Johnstone > wrote: >> >> This is an initial announcement of goey, a package for declarative, >> cross-platform GUIs. The range of controls, their supported properties and >

Re: [go-nuts] A thought on contracts

Hello, This seems more like a question for tooling. It has already been discussed that there should be a tool to read a body and provide a minimised or canonical contract. Perhaps we forgo writing the contract in code, and rely on godoc to determine the contract for the documentation? The

[go-nuts] [ANN] goey - Declarative, cross-platform GUIs

This is an initial announcement of goey, a package for declarative, cross-platform GUIs. The range of controls, their supported properties and events, should roughly match what is available in HTML. However, properties and events may be limited to support portability. Additionally, styling

Re: [go-nuts] Re: function's argument default value

Hello, This is misleading. With default arguments, there remains only one function definition, which makes it quite different from function overloading where there would be multiple definitions. Default parameters provides syntax sugar at the call site, but does not create additional

[go-nuts] Re: Does the ecosystem need a standard interface for vector graphic?

Agreed. image/vector would be better, but it would conflict with the existing golang.org/x/image/vector On Tuesday, 14 August 2018 18:45:58 UTC-4, George Moschovitis wrote: > > A general interface would be extremely useful (at least to me ;-). > I am not sure about the postscript-based API (I

[go-nuts] Does the ecosystem need a standard interface for vector graphic?

In two recent projects, I have run up to the problem of creating vector graphics. In one case, the project used gonum.org/v1/plot/vg to provide output, and in another github.com/llgcode/draw2d. I've also found golang.org/x/image/vector. In all of these cases, we have an interface that

[go-nuts] Re: Cross platform native(no dependencies) GUI options.

I'm not certain that blocking CGO because of compile speed should be a primary concern. The package that implements the interface to the underlying system should be built once and installed. After that, the impact on build speed should be no different than importing any other package.

Re: [go-nuts] proposal: embed static assets

Before there was a wide range of tools for embedding assets, I wrote my own. It is relatively complete, but it did not have a feature to create a debug mode for assets. However, the server took a command-line flag for debug mode, and would access assets through the file system instead of the

[go-nuts] Re: KVs store for large strings

I'm surprised that the memory overhead is significant - 100 MB is not that much. Assuming that you don't need atomic updates to the entire KV store, partition the keys. Does the periodic reload involve changing the keys? If not, you could map the dataset into nested structs. However, you

[go-nuts] Re: How do I test an func which depends on (pseudo)-random numbers, e.g. rand.Intn()?

If you are fixing the seed, you are probably over constraining your test. Even though you are calling rand, there must be some post-conditions that the function is supposed to guarantee. In this case, you probably expect all options to be returned with equal probability, so you should call

[go-nuts] Re: casting slice of rune to string picks up extra characters for some inputs

Hello, Strings are encoded using UTF-8, which is a multi-byte encoding. Different runes require different lengths to be encoded, and the prefix you noted is how that length is transmitted (although the ranges in your message don't seem to be correct). Robert On Tuesday, 28 February 2017

[go-nuts] Re: url.String() method fails to percent encode Path when certain characters are removed

Hello, The pound character (0x23) is the fragment identifier. I would have thought the fragment needs to be encoded as well, but from memory I'm not sure. Good luck, On Wednesday, 16 November 2016 08:18:54 UTC-5, Conner Hewitt wrote: > > Hi, > > I'm unsure if this is a bug or if this is