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

[Robert Johnstone]

Hello,

Thanks for the quick reply.  I had not considered the write barriers, but 
if the Go objects are "live" longer than the held in C, it would work.

I definitely agree that there are risks associated with this approach.  We 
are giving up some of the safety of Go.  Unfortunately, we are using cgo 
for more than some computation, so we have live objects in C as well, and 
so we cannot completely escape the manual memory management required.

What is the state of plans for a moving garbage collector?  This would 
definitely wreck havoc if any pointers to Go memory were held in 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 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 
> complicating matters. 
> > 
> > 1) The Go objects in question are certainly on the heap. 
> > 2) The references in C are not needed to maintain the lifetime of the Go 
> objects. 
> > 
> > My understanding is that the main reason for the restriction is that Go 
> might move to a moving garbage collector.  At the moment, unless there is 
> definite work on this, I'm inclined to break the rule and let the C code 
> hold onto pointers to Go memory.  However, before committing to this 
> approach, I'd like to make sure I haven't missed any other reasons for the 
> prohibition. 
>
> There is more background on this at 
> https://github.com/golang/proposal/blob/master/design/12416-cgo-pointers.md 
> . 
>
> The Go compiler compiles code to use a write barrier when storing 
> pointers to memory.  The C compiler obviously does not.  When storing 
> a Go pointer in C code, no write barrier is executed.  This can cause 
> the garbage collector to be confused about whether the pointer is 
> reachable.  In particular, it is absolutely critical that C code never 
> store a Go pointer into Go memory. 
>
> Still, while you have to be careful and I recommend against it, you 
> may be able to get away with letting C code hold onto Go pointers 
> across calls, in C memory.  The Go values must be in the heap, not the 
> stack.  The Go values must be kept alive by existing Go pointers. 
>
> But it's risky and I personally would never do it.  Much better, if 
> possible, to use a handle.  Store the Go pointer in a map on the Go 
> side, and pass the map key, an integer, to the C side.  Then the C 
> side can pass the integer back, and Go code look it up in the map to 
> fetch the pointer. 
>
> Ian 
>

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

[go-nuts] CGO - Passing pointer to C

[Robert Johnstone]

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

1) The Go objects in question are certainly on the heap.
2) The references in C are not needed to maintain the lifetime of the Go 
objects.

My understanding is that the main reason for the restriction is that Go 
might move to a moving garbage collector.  At the moment, unless there is 
definite work on this, I'm inclined to break the rule and let the C code 
hold onto pointers to Go memory.  However, before committing to this 
approach, I'd like to make sure I haven't missed any other reasons for the 
prohibition.

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/151b1597-ad8b-4867-8542-e204599ead2e%40googlegroups.com.

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

[Robert Johnstone]

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 
bit of a smell.  

If you had instead written an example for an interface, the request would 
not seem so ridiculous:

  interface X {
const f() int
  }

(Not advocating a change to the language, just pointing out that the 
question should not be mocked)


On Thursday, 21 November 2019 13:01:09 UTC-5, burak serdar wrote:
>
> The way I read the original post what is being asked is, is it 
> possible to have the Go-equivalent of the following C++ code: 
>
> class X{ 
>   public: 
>   virtual int f() const =0; 
> } 
>
>
> > 
> > 
> > 
> > -Original Message- 
> > >From: burak serdar > 
> > >Sent: Nov 21, 2019 11:34 AM 
> > >To: Robert Engels > 
> > >Cc: advand...@gmail.com , golang-nuts <
> golan...@googlegroups.com > 
> > >Subject: Re: [go-nuts] Enforce immutability through static analysis 
> > > 
> > >On Thu, Nov 21, 2019 at 10:25 AM Robert Engels  > wrote: 
> > >> 
> > >> I don't think we are talking about the same thing. You can certainly 
> code an immutable object - just don't export any methods that mutate the 
> object, nor export ANY fields. 
> > > 
> > >Correct, we're talking about different things. The question is not 
> > >whether you can write an immutable object (yes you can), it is whether 
> > >there is a way to enforce the immutability of the receiver of a 
> > >method. 
> > > 
> > >If the method is exported and if the receiver contains pointers, there 
> > >can be no guarantee that the method will not modify values reachable 
> > >from the copy of the receiver. 
> > > 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> -Original Message- 
> > >> >From: burak serdar > 
> > >> >Sent: Nov 21, 2019 11:09 AM 
> > >> >To: Robert Engels > 
> > >> >Cc: advand...@gmail.com , golang-nuts <
> golan...@googlegroups.com > 
> > >> >Subject: Re: [go-nuts] Enforce immutability through static analysis 
> > >> > 
> > >> >On Thu, Nov 21, 2019 at 10:05 AM Robert Engels  > wrote: 
> > >> >> 
> > >> >> To clarify - the author of the package enforces immutability. With 
> Go’s design this can be a simple comment on the field. The package 
> shouldn’t be that large where this doesn’t work. 
> > >> > 
> > >> >The original problem remains: there is no way to enforce an 
> immutable receiver. 
> > >> > 
> > >> >> 
> > >> >> > On Nov 21, 2019, at 10:58 AM, Robert Engels <
> ren...@ix.netcom.com > wrote: 
> > >> >> > 
> > >> >> >  
> > >> >> > Correct, but if the receiver method is mutating it, then it is 
> not an immutable object. 
> > >> >> > 
> > >> >> > 
> > >> >> > 
> > >> >> > 
> > >> >> > -Original Message- 
> > >> >> >> From: burak serdar > 
> > >> >> >> Sent: Nov 21, 2019 10:53 AM 
> > >> >> >> To: Robert Engels > 
> > >> >> >> Cc: advand...@gmail.com , golang-nuts <
> golan...@googlegroups.com > 
> > >> >> >> Subject: Re: [go-nuts] Enforce immutability through static 
> analysis 
> > >> >> >> 
> > >> >> >>> On Thu, Nov 21, 2019 at 9:49 AM Robert Engels <
> ren...@ix.netcom.com > wrote: 
> > >> >> >>> 
> > >> >> >>> They can't unless the instance field is exported. Just hide it 
> via encapsulation with accessors. 
> > >> >> >> 
> > >> >> >> Can't do that with a receiver. All methods of a type are in the 
> same 
> > >> >> >> package as the type, so all fields are visible to the receiver. 
> > >> >> >> 
> > >> >> >> 
> > >> >> >>> 
> > >> >> >>> -Original Message- 
> > >> >> >>> From: advand...@gmail.com  
> > >> >> >>> Sent: Nov 21, 2019 10:15 AM 
> > >> >> >>> To: golang-nuts 
> > >> >> >>> Subject: [go-nuts] Enforce immutability through static 
> analysis 
> > >> >> >>> 
> > >> >> >>> Dear Gophers! 
> > >> >> >>> 
> > >> >> >>> I was wonder if it possible to force immutability on the 
> method receiver? I know Go doesn't support immutable types and that it is 
> possible to pass the receiver by value but if the receiver struct has a 
> field with a pointer type the method may still manipulate it: 
> > >> >> >>> 
> > >> >> >>> type Counter struct { 
> > >> >> >>> n *int 
> > >> >> >>> } 
> > >> >> >>> 
> > >> >> >>> func (c Counter) Render() string { 
> > >> >> >>> *c.n += 1 
> > >> >> >>> return strconv.Itoa(*c.n) 
> > >> >> >>> } 
> > >> >> >>> 
> > >> >> >>> I would like to force (or hint) the the user in writing 
> interface{ Render() string } implementations that don't manipulate the 
> method receiver. So that they can be considered 'pure' in the functional 
> sense of the word and can be called repeatedly without side effects. I 
> would like the user to be able to define implementations of interface{ 
> Render() string }such that I can safely call the method and use the 
> returned string to write a http.Reponse without it changing between 
> requests. 
> > >> >> >>> 
> > >> >> >>> I 

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

[Robert Johnstone]

Thank-you for the feedback.  I will also checkout the packages that you 
mentioned.  No need to reinvent the wheel.

Robert


On Wednesday, 25 September 2019 08:15:19 UTC-4, rog wrote:
>
> I've been using packages that use this technique for a long time now 
> (first gopkg.in/check.v1 <https://godoc.org/gopkg.in/check.v1>, and 
> latterly github.com/frankban/quicktest 
> <https://godoc.org/github.com/frankban/quicktest>), and I can confirm 
> that it works great. In general, tests can assume that they're being run in 
> the package source directory because 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:
>
>> I recently found the package github.com/matryer/is 
>> <https://godoc.org/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 package.  However, this does mean that the 
>> messages can not be created if the test binary is run on a separate 
>> machine, or in a sandbox.  I can't think of any cases where this would be 
>> an issue, but (as an example), it does break on the playground 
>> <https://play.golang.org/p/FNb9SuCXgaw>.
>>
>> Does anyone have experience with this technique in production?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/d7a801c1-17aa-4f4b-9e46-abcc36fd49ff%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/d7a801c1-17aa-4f4b-9e46-abcc36fd49ff%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

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

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

[Robert Johnstone]

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 package.  However, this does mean that the 
messages can not be created if the test binary is run on a separate 
machine, or in a sandbox.  I can't think of any cases where this would be 
an issue, but (as an example), it does break on the playground 
.

Does anyone have experience with this technique in production?

-- 
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/d7a801c1-17aa-4f4b-9e46-abcc36fd49ff%40googlegroups.com.

[go-nuts] Modules for packages without dependencies

[Robert Johnstone]

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 not clear 
whether or not these packages should have a go.mod file.  At most, it would 
specify the minimum version of go.  I don't see much impact on usability or 
maintenance either way.

For vendoring, it was best practice (?) that only top-level packages would 
vendor.  I'm wondering if this rule applies to modules.

Robert

-- 
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/5703984c-8000-4093-a7b2-0763ecfc4a76%40googlegroups.com.

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

[Robert Johnstone]

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() {
> for {
> atomic.LoadInt32()
> }
> wg.Done()
> }()
> go func() {
> for {
> m.Lock()
> n = 1
> m.Unlock()
> }
> wg.Done()
> }()
> wg.Wait()
> }
>
> Does it safe to use atomic read an int and write an int non-atomically but 
> in lock concurrently? Race detector will report it data race.
>

-- 
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/c8a2c785-e54f-4bf9-abe0-c1136225f521%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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 quality of their Go 
> code bases and why. Specifically, I'm asking if:
>
>1. There is a way to score a code base on quality that works with 
>idiomatic Go
>2. Use this metric in a CI system and fail the build if the quality 
>falls
>3. Use this metric in a team to detect trends over time and hot spots 
>where technical debt tends to accumulate
>
> It strikes me that Go is quite different to the usual set of popular 
> languages and that even the most basic measures (cyclomatic complexity for 
> example) may not be a good fit. 
>
> For example:
>
>1. Adding proper error handling increases measured complexity, but is 
>actually preferable to not handling errors
>2. A switch case where a case statement contains one or more commas is 
>actually more maintainable, but would probably have the same score as 
>individual case statements on separate lines
>
> There are already a lot of tools that analyse Go code in several different 
> ways - but which ones really work in the long term? 
>
> I'd like to ask the community which ones you've had good experiences with 
> - a test of a good tool could be that a better score results in more 
> idiomatic, maintainable 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/0825d556-a988-4035-816a-4250dd424bbf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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 Max 
need to be in the 80%?

Robert


On Thursday, 30 May 2019 14:26:34 UTC-4, Ian Lance Taylor wrote:
>
> One of my guidelines for an acceptable generics proposal is that 
> people can write Min and Max.  Your proposal admits that it doesn't 
> permit that.  I think that is a problem.  I'm fine with the general 
> idea of "do 80% of the job" but in practice people really do want to 
> write Min and Max.  I think they are part of the 80% that needs to be 
> handled, not the 20% that can be omitted. 
>

-- 
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/e91e761e-92cd-452a-a387-e0741ebacd66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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

https://gitlab.com/stone.code/parallel
https://godoc.org/gitlab.com/stone.code/parallel

-- 
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] floating point question

[Robert Johnstone]

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: 
> > 
> > 1.1*1.1 and 1.21 are untyped constants and have much higher precision at 
> which they are not equal. 
> > Does that mean that the Go compiler is using floats with more precision 
> than the runtime? 
>
> Yes, but it's also worth remembering that in general, in computing, it's 
> not a great idea to compare floats for absolute equality except for 
> specific constants (e.g. +/- zero, +/- infinity, NaN). 
>
> Is there an in-built intrinsic in Go for comparing floats within an 
> epsilon, or does that have to be done manually? 
>
>
> - Dave 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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 this program coverage so  
> go test -coverprofile coverage.out  -args 1 2 3 4
>
> myprogram_test.go
>
> func Test_main(m *testing.T) {
>main()
>
> }
>
>
> DEBUG  args= 
> [/var/folders/cp/561_gl9j1wzd8dgv_fn5mk7cgn/T/go-build225076203/b001/myprogram.test
>  
> -test.coverprofile=/var/folders/cp/561_gl9j1wzd8dgv_fn5mk7cgn/T/go-build225076203/b001/_cover_.out
>  
> 1 2 3 4]
> ERROR  invalid *args_len=: 6*
>
> the coverage flag has been add to args   cause program error,   invalid 
> args_len=: 6   
> How to resolve 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.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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 compiler, 
it might provide more guidance.



On Friday, 22 March 2019 00:39:34 UTC-4, Tom wrote:
>
> I've been stuck on this for a few days so thought I would ask the brains 
> trust.
>
> *TL;DR: *When I have native amd64 instructions mutating (updating the len 
> + values of a []uint64) a slice, I experience spurious & random memory 
> corruption when under heavy load (# runnable goroutines > MAXPROCS, doing 
> the same thing continuously), and only when the GC is enabled. Any 
> debugging ideas or things I should look into?
>
> *Background:*
>
> I'm calling into go assembly with a few pointers to slices (*[]uint64), 
> and that assembly is mutating them (reading/writing values, updating len 
> within capacity). I'm experiencing random memory corruption, but I can only 
> trigger it in the following scenarios:
>
>1. Heavy load - Doing a zillion things at once (specifically running 
>all my test cases in parallel) and maxing out my machine.
>2. Parallelism - A panic due to memory corruption happens faster if 
>--parallel is set higher, and never if not in parallel.
>3. GC - The panic never happens if the GC is disabled (of course, the 
>test process eventually runs out of memory).
>
> The memory corruption varies, but usually results in an element of an 
> unrelated slice being zero'ed, the len of a unrelated slice being zeroed, 
> or (less likely) a segfault.
>
> Tested on go1.11.2 and go1.12.1. I can only trigger this if I run all my 
> test cases at once (with --count at 8000 or so & using t.Parallel()). 
> Running thing serially or individually yields the correct behaviour.
>
> The assembly in question looks like this:
>
> TEXT ·jitcall(SB),NOSPLIT|NOFRAME,$0-24
> GO_ARGS
> MOVQ asm+0(FP), AX  // Load the address of the assembly 
> section.
> MOVQ stack+8(FP),   R10 // Load the address of the 1st slice.
> MOVQ locals+16(FP), R11 // Load the address of the 2nd slice.
> MOVQ 0(AX), AX  // Deference pointer to native code.
> JMP AX  // Jump to native code.
>
> And slice manipulation like this (this is a 'pop'):
>
>  MOVQ r13, [r10+8]   // Load the length of the slice.
>  DECQ r13// Decrements the len (I can guarantee this 
> will never underflow).
>  MOVQ r12, [r10] // Load the 0th element address.
>  LEAQ r12, [r12 + r13*8] // Compute the address of the last element.
>  MOVQ reg, [r12] // Load the element to reg.
>  MOVQ [r10+8], r13   // Write the len back.
>
> or 'push' like this (note: cap is always large enough for any pushes) ...
>
>  MOVQ r12, [r10]  // Load the 0th element address.
>  MOVQ r13, [r10+8]// Load the len.
>  LEAQ r12, [r12 + r13*8]  // Compute the address of the last element 
> + 1.
>  INCQ r13 // Increment the len.
>  MOVQ [r10+8], r13// Save the len.
>  MOVQ [r12],   reg// Write the new element.
>
>
> I acknowledge that calling into code like this is unsupported, but I 
> struggle to understand how such corruption can happen, and having stared at 
> it for a few days, I am frankly stumped. I mean, even if non-cooperative 
> preemption was in these versions of Go I would expect the GC to  abort when 
> it cant find the stack maps for my RIP value. With no GC safe points in my 
> native assembly, I dont see how the GC could interfere (yet the issue 
> disappears with the GC off??).
>
> *Questions:*
>
>1. Any ideas what I'm doing wrong?
>2. Any ideas how I can trace this from the application side and also 
>the runtime side? I've tried schedtrace and the like, but the output didnt 
>appear useful or correlated to the crashes.
>3. Any suggestions for assumptions I might have missed and should 
>write tests / guards for?
>
> Thanks,
> Tom
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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 use the colon, you are access a specific element.  Since the 
count is zero based, the valid indices are 0 through 5 inclusive.  Note 
that the type of the expression primes[6] is simply int.

Good luck.


On Thursday, 7 March 2019 10:32:04 UTC-5, Halbert.Collier Liu wrote:
>
> Hi.
>
> The code like below:
>
> package main
>
> import "fmt"
>
> func main() {
> primes := [6]int{2, 3, 5, 7, 11, 13}
> fmt.Println(primes[6:6]) .  // *OK*. return:   []
> //fmt.Println(primes[6]) .   // fail. out of bounds...
> }
>
> Why? 
>
> Is the golang grammatical feature? or anything else..
>
> Any help, please!
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

Hello,

Thank you for filing the two issues.  Both have been resolved.  Hopefully 
you won't find any other bugs... but if you do, please file an issue.

Robert


On Tuesday, 29 January 2019 16:15:01 UTC-5, Jake Montgomery wrote:
>
> This looks quite interesting for the types of simple apps I'm building 
> right now. However, I have discovered a couple of bugs. I don't see any way 
> to report them on bitbucket. 
>
> Are you taking bug reports, and if so, what is the best way to communicate 
> them?
> Are you taking outside pull requests for bug fixes?
>
> 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 
>> events, should roughly match what is available in HTML.  However, 
>> properties and events may be limited to support portability.  Additionally, 
>> styling of the controls will be limited, with the look of controls matching 
>> the native platform.
>>
>> A minimal example of a complete application can be found at 
>> https://godoc.org/bitbucket.org/rj/goey/example/onebutton.
>>
>> * README:  https://bitbucket.org/rj/goey/src/default/README.md
>> * godoc: https://godoc.org/bitbucket.org/rj/goey
>>
>> Feedback welcome.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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 to submit a bug report.  I 
look forward to the feedback...

Thank-you,

Robert


On Tuesday, 29 January 2019 16:15:01 UTC-5, Jake Montgomery wrote:
>
> This looks quite interesting for the types of simple apps I'm building 
> right now. However, I have discovered a couple of bugs. I don't see any way 
> to report them on bitbucket. 
>
> Are you taking bug reports, and if so, what is the best way to communicate 
> them?
> Are you taking outside pull requests for bug fixes?
>
> Thanks for the great 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.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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.")
// Return the error (if any) back to the caller.
return err
})


Internally, the package handles marshalling the callback to the GUI thread 
where is it called, and then marshalling the error value back to the 
callee.  The question is what should be done if the callback panics?

I'm confident that the panic needs to be recovered on the GUI thread, and 
then marshalled back to the callee.  This is easy to do, as the panic can 
be wrapped in a custom error.  For the callee, however, I'm not sure of the 
ideal behaviour.  I'd like to preserve the semantics of the panic, which 
would be calling panic on the caller's goroutine to restart unwinding the 
stack.  However, the resulting stack trace would point to the wrong 
location.

1) Are there any opinions on whether or not calling panic on the caller's 
thread is worthwhile, or is returning a PanicError a better?

2) Whether or not panic is called on the caller's thread, is there a way to 
capture the stack trace for the original panic?  The information must be 
available in the runtime, since if there is no recover, the runtime will 
print a stacktrace from the original location, but I did not see a way to 
access the data.  Otherwise, there may be very little information to help 
with debugging.

Robert

-- 
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] Using "er" and "able" for interfaces

[Robert Johnstone]

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 can be understood as subject/verb.  In this case, 
myvar is the reader, but it is passing the data back to you.  

Robert



On Thursday, 17 January 2019 14:48:30 UTC-5, Jakob Borg wrote:
>
> On 16 Jan 2019, at 15:42, Victor Giordano  > wrote:
>
>
> As far i can get to understand the english language (i'm not a native 
> speaker), the "er" seems to denotes or describe things in a more "active 
> way" (the thing that they actually do by itself), and the "able" describes 
> things in a more "passive way"  (the thing that you can "ask it/his/her" to 
> do). Do you find this appreciation correct?
>
>
> This was a mental stumbling block for me for a long time when I started 
> out with Go. For me, the "Reader" is the one who calls Read(), so an 
> io.Reader seemed like the opposite of what I wanted. I would have better 
> understood it as io.Readee. It works out better if I see the Reader as some 
> sort of intermediate entity that affects reads on whatever the underlying 
> thing is you want to read from… Or if I see it as just an 
> interface-indicating nonsense suffix, like a capital-I prefix…
>
> //jb
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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.  Instead, you should use shift and mask to 
extract the bytes (e.x, uint8(i>>16).  I expect the resulting code will be 
faster.

2)  Even if you keep the pointer arithmetic, you should defer taking the 
address until necessary.


Good luck.

Robert


On Sunday, 25 November 2018 11:10:09 UTC-5, Arkady M wrote:
>
> The code below consumes ~40% of the total execution time. According to 
> the profiler i := uint64(arg.(uint32)) is a major contributor
>
> // Cast the integer argument to uint64 and call a "writer"
> // The "writer" knows how many bytes to add to the binary stream
> // Type casts from interface{} to integer consume 40% of the overall
> // time. Can I do better? What is interface{} in Golang?
> func (b *Binlog) writeArgumentToOutput(writer writer, arg interface{}, 
> argKind reflect.Kind) error {
> // unsafe pointer to the data depends on the data type
> var err error
> switch argKind {
> case reflect.Int8:
> i := uint64(arg.(int8))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int16:
> i := uint64(arg.(int16))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int32:
> i := uint64(arg.(int32))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int64:
> i := uint64(arg.(int64))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint8:
> i := uint64(arg.(uint8))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint16:
> i := uint64(arg.(uint16))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint32:
> i := uint64(arg.(uint32))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint64:
> i := uint64(arg.(uint64))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int:
> i := uint64(arg.(int))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint:
> i := uint64(arg.(uint))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> default:
> return fmt.Errorf("Unsupported type: %T\n", reflect.TypeOf(arg))
> }
> return err
> }
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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, 
> 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 of the controls will be limited, with the look of controls matching 
> the native platform.
>
> A minimal example of a complete application can be found at 
> https://godoc.org/bitbucket.org/rj/goey/example/onebutton.
>
> * README:  https://bitbucket.org/rj/goey/src/default/README.md
> * godoc: https://godoc.org/bitbucket.org/rj/goey
>
> Feedback welcome.
>
>

-- 
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] [ANN] goey - Declarative, cross-platform GUIs

[Robert Johnstone]

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:
>
> Hello,
>
> I've taken a previous comment about screenshots seriously.  They will be 
> up in a little bit.
>
> The layout widgets are actually all platform-independent.  Initially, I 
> was relying on the layout widgets in GTK, but it was too hard to get 
> feature parity.  For a OSX port, layout will be easy, but it won't match 
> any platform specific guidelines without more work.
>
> - Robert
>
>
> On Monday, 10 September 2018 14:25:05 UTC-4, Robert Engels wrote:
>>
>> I wonder about the design, and how it will work. Since it uses the native 
>> components behind the scene, you will get great fidelity but the layout can 
>> be very difficult to accomplish.
>>
>> This is why Java’s Swing uses only a single native component (Canvas), 
>> and does all of the text/drawing/event handling in Java.
>>
>> I wouldn’t think an OSX port would be that hard, but before investing the 
>> effort, 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:
>>
>> Hello,
>>
>> There isn't a porting guide, but I can provide some guidance.  
>>
>> 1) In goey/base, copy widget_linux.go to widget_darwin.go to create stubs 
>> for Control and NativeElement, but don't worry about any implementation yet.
>>
>> 2) In goey, temporarily remove all of the files for the controls.  You 
>> need to implement three functions, 'run', 'do', and 'loop' to manage the 
>> GUI event loop.  Actually, if you look at the code for WIN32 and for GTK, 
>> you might find you that you don't need both 'run' and 'loop'.
>>
>> 3) In goey, implement Window for darwin.  Again, you can stub out most of 
>> the methods.  There is a example, ExampleNewWindow, which if you replace 
>> {} with nil, provide a minimal example of showing a window.  
>>
>> 4) At that point, you should have most of the difficult work done.  The 
>> next steps will be to port over the controls one-by-one, but the 
>> infrastructure will be in place, so that work con be done a small piece at 
>> a time.
>>
>> Let me know if that helps, or if you have any other questions.
>>
>> Robert
>>  
>>
>> On Friday, 7 September 2018 11:05:23 UTC-4, Robert Engels wrote:
>>>
>>> I might be able to do it if there was a “porting guide” that describes 
>>> what needs to be - 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 platform.  Sorry, no concrete plans.
>>>
>>> - Robert
>>>
>>>
>>>
>>> On Thursday, 6 September 2018 19:44:52 UTC-4, Richard Wilkes wrote:
>>>>
>>>> Hi, Robert.
>>>>
>>>> Do you have any plans to add macOS 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 
>>>>> events, should roughly match what is available in HTML.  However, 
>>>>> properties and events may be limited to support portability.  
>>>>> Additionally, 
>>>>> styling of the controls will be limited, with the look of controls 
>>>>> matching 
>>>>> the native platform.
>>>>>
>>>>> A minimal example of a complete application can be found at 
>>>>> https://godoc.org/bitbucket.org/rj/goey/example/onebutton.
>>>>>
>>>>> * README:  https://bitbucket.org/rj/goey/src/default/README.md
>>>>> * godoc: https://godoc.org/bitbucket.org/rj/goey
>>>>>
>>>>> Feedback welcome.
>>>>>
>>

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

[Robert Johnstone]

Hello,

I've taken a previous comment about screenshots seriously.  They will be up 
in a little bit.

The layout widgets are actually all platform-independent.  Initially, I was 
relying on the layout widgets in GTK, but it was too hard to get feature 
parity.  For a OSX port, layout will be easy, but it won't match any 
platform specific guidelines without more work.

- Robert


On Monday, 10 September 2018 14:25:05 UTC-4, Robert Engels wrote:
>
> I wonder about the design, and how it will work. Since it uses the native 
> components behind the scene, you will get great fidelity but the layout can 
> be very difficult to accomplish.
>
> This is why Java’s Swing uses only a single native component (Canvas), and 
> does all of the text/drawing/event handling in Java.
>
> I wouldn’t think an OSX port would be that hard, but before investing the 
> effort, 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:
>
> Hello,
>
> There isn't a porting guide, but I can provide some guidance.  
>
> 1) In goey/base, copy widget_linux.go to widget_darwin.go to create stubs 
> for Control and NativeElement, but don't worry about any implementation yet.
>
> 2) In goey, temporarily remove all of the files for the controls.  You 
> need to implement three functions, 'run', 'do', and 'loop' to manage the 
> GUI event loop.  Actually, if you look at the code for WIN32 and for GTK, 
> you might find you that you don't need both 'run' and 'loop'.
>
> 3) In goey, implement Window for darwin.  Again, you can stub out most of 
> the methods.  There is a example, ExampleNewWindow, which if you replace 
> {} with nil, provide a minimal example of showing a window.  
>
> 4) At that point, you should have most of the difficult work done.  The 
> next steps will be to port over the controls one-by-one, but the 
> infrastructure will be in place, so that work con be done a small piece at 
> a time.
>
> Let me know if that helps, or if you have any other questions.
>
> Robert
>  
>
> On Friday, 7 September 2018 11:05:23 UTC-4, Robert Engels wrote:
>>
>> I might be able to do it if there was a “porting guide” that describes 
>> what needs to be - 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 platform.  Sorry, no concrete plans.
>>
>> - Robert
>>
>>
>>
>> On Thursday, 6 September 2018 19:44:52 UTC-4, Richard Wilkes wrote:
>>>
>>> Hi, Robert.
>>>
>>> Do you have any plans to add macOS 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 
>>>> events, should roughly match what is available in HTML.  However, 
>>>> properties and events may be limited to support portability.  
>>>> Additionally, 
>>>> styling of the controls will be limited, with the look of controls 
>>>> matching 
>>>> the native platform.
>>>>
>>>> A minimal example of a complete application can be found at 
>>>> https://godoc.org/bitbucket.org/rj/goey/example/onebutton.
>>>>
>>>> * README:  https://bitbucket.org/rj/goey/src/default/README.md
>>>> * godoc: https://godoc.org/bitbucket.org/rj/goey
>>>>
>>>> Feedback welcome.
>>>>
>>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

Hello,

There isn't a porting guide, but I can provide some guidance.  

1) In goey/base, copy widget_linux.go to widget_darwin.go to create stubs 
for Control and NativeElement, but don't worry about any implementation yet.

2) In goey, temporarily remove all of the files for the controls.  You need 
to implement three functions, 'run', 'do', and 'loop' to manage the GUI 
event loop.  Actually, if you look at the code for WIN32 and for GTK, you 
might find you that you don't need both 'run' and 'loop'.

3) In goey, implement Window for darwin.  Again, you can stub out most of 
the methods.  There is a example, ExampleNewWindow, which if you replace 
{} with nil, provide a minimal example of showing a window.  

4) At that point, you should have most of the difficult work done.  The 
next steps will be to port over the controls one-by-one, but the 
infrastructure will be in place, so that work con be done a small piece at 
a time.

Let me know if that helps, or if you have any other questions.

Robert
 

On Friday, 7 September 2018 11:05:23 UTC-4, Robert Engels wrote:
>
> I might be able to do it if there was a “porting guide” that describes 
> what needs to be - 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 platform.  Sorry, no concrete plans.
>
> - Robert
>
>
>
> On Thursday, 6 September 2018 19:44:52 UTC-4, Richard Wilkes wrote:
>>
>> Hi, Robert.
>>
>> Do you have any plans to add macOS 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 
>>> events, should roughly match what is available in HTML.  However, 
>>> properties and events may be limited to support portability.  Additionally, 
>>> styling of the controls will be limited, with the look of controls matching 
>>> the native platform.
>>>
>>> A minimal example of a complete application can be found at 
>>> https://godoc.org/bitbucket.org/rj/goey/example/onebutton.
>>>
>>> * README:  https://bitbucket.org/rj/goey/src/default/README.md
>>> * godoc: https://godoc.org/bitbucket.org/rj/goey
>>>
>>> Feedback welcome.
>>>
>>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] A thought on contracts

[Robert Johnstone]

Good point.  We will definitely want a warning before inadvertently 
changing the contract...



On Friday, 7 September 2018 10:58:51 UTC-4, Tristan Colgate wrote:
>
> You lose the ability to see changes of contract in your diff (which I 
> think is the thing I most want).
>
>
> 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 forgo writing the contract in 
>> code, and rely on godoc to determine the contract for the documentation?
>>
>> The contracts will be useful if they are used to constrain the 
>> implementation.
>>
>> - Robert
>>
>>
>> On Thursday, 6 September 2018 18:18:13 UTC-4, soapboxcicero wrote:
>>
>>> If the contract for a type is entirely inferred in order to know the 
>>> types it accepts you have to read all of its code, every line. The 
>>> contract let's you boil that down to the salient points so you can 
>>> read line a few lines instead of a few hundred or a few thousand. 
>>> On Thu, Sep 6, 2018 at 3:15 PM Thomas Wilde  
>>> wrote: 
>>> > 
>>> > Thanks for the response. I think the question then becomes: if the 
>>> syntax in contract bodies was an unrestricted Go block, then why do I need 
>>> to repeat my function's operations in a contract? 
>>> > 
>>> > If the syntax of contract bodies is free, then the Go compiler could 
>>> easily deduce all my constraints from a function body directly -- no need 
>>> for a separate contract. 
>>> > 
>>> > Thanks again and all the best, 
>>> > - Tom 
>>> > 
>>>
>> > On Thu, Sep 6, 2018, 22:26 Ian Lance Taylor  wrote: 
>>>
>> >> 
>>> >> On Tue, Sep 4, 2018 at 7:41 AM, thwd  wrote: 
>>> >> > 
>>> >> > From the draft proposal I gather two open questions: 
>>> >> >  - How free or restricted should contract bodies be? 
>>> >> 
>>> >> I believe it's useful to have contract bodies simply be arbitrary 
>>> >> function bodies, as the current design draft suggests.  This is 
>>> >> because I believe that is conceptually the simplest choice.  You 
>>> don't 
>>> >> have to remember two different syntaxes, one for code and one for 
>>> >> contract bodies.  You just have to remember a single syntax, one you 
>>> >> must know in any case to write any Go code at all. 
>>> >> 
>>> >> >  - How many implicit constraints can be inferred from usage? 
>>> >> 
>>> >> As few as we can get away with. 
>>> >> 
>>> >> 
>>> >> > If too much syntax is allowed in contract bodies and no implicit 
>>> constraints 
>>> >> > are gathered: 
>>> >> > people will copy and paste function bodies into contracts to cover 
>>> all 
>>> >> > constraints. 
>>> >> 
>>> >> People do suggest that that will happen but I think it is extremely 
>>> >> unlikely in practice.  It's obviously a terrible coding style, and 
>>> >> almost all generic functions have trivial contract requirements. 
>>> >> 
>>> >> Ian 
>>> > 
>>> > -- 
>>> > You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group. 
>>>
>> > To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com. 
>>>
>> > For more options, visit https://groups.google.com/d/optout. 
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

Hello,

I would be very happy to support macOS, but unfortunately I don't have any 
experience on that platform.  Sorry, no concrete plans.

- Robert



On Thursday, 6 September 2018 19:44:52 UTC-4, Richard Wilkes wrote:
>
> Hi, Robert.
>
> Do you have any plans to add macOS 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 
>> events, should roughly match what is available in HTML.  However, 
>> properties and events may be limited to support portability.  Additionally, 
>> styling of the controls will be limited, with the look of controls matching 
>> the native platform.
>>
>> A minimal example of a complete application can be found at 
>> https://godoc.org/bitbucket.org/rj/goey/example/onebutton.
>>
>> * README:  https://bitbucket.org/rj/goey/src/default/README.md
>> * godoc: https://godoc.org/bitbucket.org/rj/goey
>>
>> Feedback welcome.
>>
>>

-- 
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] A thought on contracts

[Robert Johnstone]

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 contracts will be useful if they are used to constrain the 
implementation.

- Robert


On Thursday, 6 September 2018 18:18:13 UTC-4, soapboxcicero wrote:
>
> If the contract for a type is entirely inferred in order to know the 
> types it accepts you have to read all of its code, every line. The 
> contract let's you boil that down to the salient points so you can 
> read line a few lines instead of a few hundred or a few thousand. 
> On Thu, Sep 6, 2018 at 3:15 PM Thomas Wilde  > wrote: 
> > 
> > Thanks for the response. I think the question then becomes: if the 
> syntax in contract bodies was an unrestricted Go block, then why do I need 
> to repeat my function's operations in a contract? 
> > 
> > If the syntax of contract bodies is free, then the Go compiler could 
> easily deduce all my constraints from a function body directly -- no need 
> for a separate contract. 
> > 
> > Thanks again and all the best, 
> > - Tom 
> > 
> > On Thu, Sep 6, 2018, 22:26 Ian Lance Taylor  > wrote: 
> >> 
> >> On Tue, Sep 4, 2018 at 7:41 AM, thwd  > wrote: 
> >> > 
> >> > From the draft proposal I gather two open questions: 
> >> >  - How free or restricted should contract bodies be? 
> >> 
> >> I believe it's useful to have contract bodies simply be arbitrary 
> >> function bodies, as the current design draft suggests.  This is 
> >> because I believe that is conceptually the simplest choice.  You don't 
> >> have to remember two different syntaxes, one for code and one for 
> >> contract bodies.  You just have to remember a single syntax, one you 
> >> must know in any case to write any Go code at all. 
> >> 
> >> >  - How many implicit constraints can be inferred from usage? 
> >> 
> >> As few as we can get away with. 
> >> 
> >> 
> >> > If too much syntax is allowed in contract bodies and no implicit 
> constraints 
> >> > are gathered: 
> >> > people will copy and paste function bodies into contracts to cover 
> all 
> >> > constraints. 
> >> 
> >> People do suggest that that will happen but I think it is extremely 
> >> unlikely in practice.  It's obviously a terrible coding style, and 
> >> almost all generic functions have trivial contract requirements. 
> >> 
> >> Ian 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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 of the controls will be limited, with the look of controls matching 
the native platform.

A minimal example of a complete application can be found at 
https://godoc.org/bitbucket.org/rj/goey/example/onebutton.

* README:  https://bitbucket.org/rj/goey/src/default/README.md
* godoc: https://godoc.org/bitbucket.org/rj/goey

Feedback welcome.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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

I'm not arguing for default parameters.  The explanation 
in https://talks.golang.org/2012/splash.article#TOC_10 is good, given Go's 
philosophy.  

Robert


On Thursday, 23 August 2018 19:26:36 UTC-4, Ian Lance Taylor wrote:
>
> On Thu, Aug 23, 2018 at 4:20 PM, Masoud Ghorbani 
> > wrote: 
> > I didn't get the relation of function overloading with parameters 
> default 
> > value. actually, function overloading means define functions with 
> similar 
> > names. 
>
> Right.  After adding a default value for the parameter, you have two 
> functions with similar names: 
> F(int) 
> F() 
>
> It's exactly as though you overloaded F. 
>
> Ian 
>
>
> > On Friday, August 24, 2018 at 1:11:12 AM UTC+4:30, Ian Lance Taylor 
> wrote: 
> >> 
> >> On Thu, Aug 23, 2018 at 12:44 AM, Masoud Ghorbani 
> >>  wrote: 
> >> > 
> >> > Your opinion is like to say all of the python application should 
> rethink 
> >> > and 
> >> > re-write their structure because they used default values. I think 
> >> > having 
> >> > default values for parameters is just a feature which will make 
> codebase 
> >> > readable and smaller than before. 
> >> 
> >> Default values for parameters is in effect a simple form of function 
> >> overloading.  If F(int) has a default value for the parameter, then 
> >> you've overloaded F with another function F() that takes no arguments. 
> >> Go doesn't have function overloading in general, and it doesn't have 
> >> default parameter values either. 
> >> 
> >> Ian 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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 am not against it though) 
> and I find the the name `image/gc` a bit confusing (vector <-> image, gc ~ 
> garbage-collector).
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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 models fairly close the postscript model for drawing 2D 
graphics.  There is also duplication in the backends.  It would be nice if 
there was a standard ecosystem wide interface for painting 2D graphics.

I expect that providing implementations would be outside the scope of the 
language, but I see an approach similar to database/sql being useful here.  
There would be a package containing a standard interface to provide a 
graphics context (either image/gc or golang.org/x/image/gc).  

Has this been discussed elsewhere?  Would it be useful?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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.  Unfortunately, I don't have any measurements.

The second reason to avoid CGO is the difficulty of building on windows.  
However, if you only need to access DLLs, all FFI calls can be made using 
the syscall package, so CGO is not needed.

Robert


On Sunday, 27 May 2018 16:51:32 UTC-4, ati...@mail.ccsf.edu wrote:
>
> Hello,
>
> I would like you guys to suggest some GUI libraries that do not have any 
> HTML/CSS or C bindings, are cross platform and require no dependencies.
>
> When I say native, I mean no dependencies. I do not mean native to the OS. 
> This would be great but I don't see any available that have no C bindings. 
> I understand that to create a native to the OS experience there must be 
> calls to the OS API which in most cases use the C language.
>
> Before anyone asks why I do not want C bindings, it is because they do not 
> have good cross compilation support or good compile speeds.
>
> Suggestions appreciated, Thanks so much!
>

-- 
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] proposal: embed static assets

[Robert Johnstone]

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

The point being, the "standard" tool would not have to support everything, 
it could be a building block for other packages.  The key functionality 
would be embedding possibly large assets into the linked executable.  I 
haven't measured in a while, but embedding assets did have a significant 
impact on build times.  Finding the most efficient technique would be a 
usable block, all on its own.  Additional conveniences could be built on 
top.

Robert


On Wednesday, 2 May 2018 10:36:43 UTC-4, mbanzon wrote:
>
> I’m guessing that everyone who has a workflow where they currently embed 
> resources in their binary will have specific wishes to how it’ll function.
>
> The “easy” way to make serious proposals is to provide an experiment where 
> you demonstrate the change you are proposing with an implementation - this 
> will naturally require some work.
>
> My/our use of embedded resources include other programs but especially 
> frontends (html, css, javascript and images, fonts etc.) for web servers - 
> the current solution give us a crucial feature: The files are not embedded 
> during development/debugging where they change continually.
>
> There is no doubt that I’d welcome this feature in the standard Go 
> toolchain - where it is implemented or how the resource is embedded is not 
> really something I have a strong opinion about - but debugging capabilities 
> is ;-)
>
> -- 
> Michael Banzon
> https://michaelbanzon.com/
>
>
>
>
> Den 2. maj 2018 kl. 14.35 skrev Manlio Perillo  >:
>
> Il giorno mercoledì 2 maggio 2018 00:26:05 UTC+2, Ian Lance Taylor ha 
> scritto:
>>
>> On Tue, May 1, 2018 at 1:28 PM, John Unland  wrote: 
>> > 
>> > So something like x/tools/cmd/assets or cmd/assets? 
>>
>> Yes.  I might use a name more like cmd/embed. 
>>
>>
>> > I was just now thinking about it more today and I was wondering if 
>> something 
>> > like this could maybe be implemented into go build. Like how you can 
>> assign 
>> > variables at build time: 
>> > 
>> > go build -ldflags="-X main.Foo=Bar" 
>> > 
>> > Into something like... 
>> > 
>> > go build -ldflags="-X main.Asset1=./SomeFileA main.Asset2=./SomeFileB" 
>> > 
>> > Think this would take a little more effort to integrate in but it's a 
>> > interesting concept thou. 
>>
>> Personally I think the code generation approach is simpler. 
>>
>>
> It is simpler but, isn't it very inefficient with large assets, since the 
> compiler eats a lot of memory?
> Maybe a better choice is to directly embed the code into the executable 
> image, as an example appending a zip archive at the end of the executable 
> (this at least works with ELF on Linux).
>
> Using a zip archive appended to the end of the executable, you don't even 
> need to record the offset.
> The unzip tool just reports a warning:
> warning [xxx]:  ddd extra bytes at beginning or within zipfile
>
> I have not tested it with the archive/zip package.
>
>
> Manlio 
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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 will still need to 
synchronise access if you want to to reload without stopping the server, 
but that would just be the leaves.  Switching just the top-tier to a struct 
could help with the contention.


On Wednesday, 14 June 2017 14:45:25 UTC-4, James Pettyjohn wrote:
>
> I have an application which has all of it's text, multiple languages, 
> stored in XML on disk that is merged into templates on the fly. About 
> 100MB. Templates use dozens of strings for each render. 
>
> Currently this is loaded in full into memory in a bunch of tier hash maps. 
> They are lazy loaded and using multiple locks to perform reads but, unless 
> in dev mode, actually don't change throughout the lifetime of the 
> application and should be considered immutable.
>
> While workable at a smaller scale, it's slow at scale. The most important 
> factor is concurrent lookup speed, secondary concern is memory overhead. 
> And it cannot preclude periodic reload while doing dev.
>
> Is there a data structure or lib that suits this scenarios more than 
> others?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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 the 
function many times, and calculate those probabilities.  There is a whole 
field for statistical testing.


On Tuesday, 14 March 2017 23:45:22 UTC-4, Doug Ireton wrote:
>
> I'm a new Gopher and I'm working through "Learn Go" by Nathan Youngman 
> and trying to TDD the exercises to learn how to write testable Go code.
>
> I have a function to return a random spaceline 
>  from a string array.
>
> In Go, how do I test functions which depend on random numbers? And, yes, I 
> know that "math/rand" isn't truly random.
>
> Is it as simple as setting a seed right before I run my test, e.g. 
> rand.Seed(1)? Do I set rand.Seed(1) at the top of the _test.go file, or 
> at the beginning of each unit test?
>
> Also, am I seeding math.rand correctly in the Init() function? Will 
> seeding it in the Init() function override any seeding I do in my tests?
>
> My only other thought is to create an interface somehow to mock 
> rand.Intn(), but this seems like overkill and I don't know enough about 
> interfaces to know if this is inadvisable.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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 12:29:07 UTC-5, Fraser Hanson wrote:
>
> https://play.golang.org/p/05wZM9BhfB
>
> I'm working on some code that reads UTF32 and converts it to go strings. 
> I'm finding some surprising behavior when casting slices of runes to 
> strings.
>
>  runes := []rune{'©'}
>  fmt.Printf(" cast to string: (%s)\n", string(runes))
>  fmt.Printf("bytes in string: (%x)\n", string(runes))
> Output:
>
>  cast to string: (©)
> bytes in string: (c2a9) // <-- where's the C2 byte coming from??
>
>
> The weird part is that casting the rune slice to a string causes it to 
> pick up an additional leading character. 
>
> runesi 0x00-0x7f get nothing prepended.
> runes 0x80-0xbf gets a leading c2 byte as seen above.
> runes 0xc0-0xff gets a leading c3 byte.
> rune 0x100 gets a leading c4 byte.  Seems like a pattern here.
>
> The same thing happens if I add the runes into a bytes.Buffer with 
> WriteRune(), then print it out with bytes.Buffer.String().
>
> Can anyone explain this?  
> What's the correct way to convert a slice of runes into a string?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Johnstone]

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 working as expected, but wanted 
> to see if anyone knows what's going on exactly with this.
>
> Calling url.Parse() on a string containing all byte ASCII characters 
> (0-255 decimal), except the % (0x25) character, works as expected and 
> calling the String() method on it will produce a string with the Path 
> percent encoded properly.
>
> However, if you take out the # (0x23) character, percent encoding seems to 
> fail. This I believe is not specific to the # character, but I haven't 
> tested everything.
>
> Here's an example: https://play.golang.org/p/6KuknG9Kvx
>
> Any ideas?
>
> Thanks!
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.