Re: [go-nuts] Global variable not used, but it works fine

[Tyler Compton]

Go does not flag unused global variables, it is intended functionality.
I've personally found that unused global variables have a higher chance at
being benign than local variables, but there's probably an argument to be
made for flagging globals, too.

On Sat, Apr 21, 2018, 06:30  wrote:

>  What did you do?
> https://play.golang.org/p/aryK9Btv5kH
>
>  What did you expect to see?
> There should be a error "declared and not used"
>
>  What did you see instead?
> It seems work fine.
>
>  System details
>
> ```
> go version go1.10.1 windows/amd64
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="C:\Users\zps\AppData\Local\go-build"
> GOEXE=".exe"
> GOHOSTARCH="amd64"
> GOHOSTOS="windows"
> GOOS="windows"
> GOPATH="C:\Users\zps\go"
> GORACE=""
> GOROOT="C:\Go"
> GOTMPDIR=""
> GOTOOLDIR="C:\Go\pkg\tool\windows_amd64"
> GCCGO="gccgo"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments
> -fmessage-length=0
> -fdebug-prefix-map=C:\Users\zps\AppData\Local\Temp\go-build846935694=/tmp/go-build
> -gno-record-gcc-switches"
> GOROOT/bin/go version: go version go1.10.1 windows/amd64
> GOROOT/bin/go tool compile -V: compile version go1.10.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.
> 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: proposal: disallow implicitly comparing true with value of interface{} in a switch with no value

[Jérôme Champion]

The syntax is correct:  https://play.golang.org/p/t5Oi8vyCsbw
I don't think comparing an interface to a boolean in a switch is very 
common. It would need some strong evidence to justify adding an exception 
to the rule.

Le dimanche 22 avril 2018 02:53:14 UTC+2, Louki Sumirniy a écrit :
>
> Your syntax is wrong. I think you mean this:
>
> var someInterfaceValue interface{}
>
> // do something that puts a value in above variable
>
> switch someInterfaceValue {
>   case true:
> // do something
>   default:
> // do something else
> }
>
> On Saturday, 21 April 2018 16:30:22 UTC+3, b97...@gmail.com wrote:
>>
>> var someInterfaceValue interface{}
>> switch {
>> case someInterfaceValue:  // proposal: compile error: non-bool used 
>> as condition
>> case someInterfaceValue == true: // OK
>> }
>>
>> Sometimes carefulness is just not enough.
>> One may type a wrong variable as the case condition, or a incomplete 
>> condition.
>> Why is this special? Because it's commonly used.
>>
>

-- 
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 Slices Made From Same Array Concurrently

[Kaveh Shahbazian]

@Silviu

But no slice expansion is happening.

On Sunday, April 22, 2018 at 5:41:11 AM UTC+4:30, Silviu Capota Mera wrote:
>
> Hi Kaveh,
>
> Change the line:
> *ptr = append(*ptr, []byte(fmt.Sprint*f("%02d"*, k1))...)
>
> to
> *ptr = append(*ptr, []byte(fmt.Sprintf(*"%15d"*, k1))...)
>
> The buckets will overlap (more than 10 bytes) and you will get the race 
> triggered in the detector
>
> Silviu
>
>
> On Saturday, 21 April 2018 12:40:04 UTC-4, Kaveh Shahbazian wrote:
>>
>> @Ankit That's what I thought. Yet the code is accessing the same 
>> underlying array. That is the part that worries me and -race does not 
>> complain.
>>
>> @Louki Still no complain from -race! 
>> https://play.golang.org/p/dUt0QE63RDK
>>
>> On Saturday, April 21, 2018 at 7:01:25 PM UTC+4:30, Louki Sumirniy wrote:
>>>
>>> Unless you pass pointers in Go, every time you hop in and out of a new 
>>> scope any changes are discarded. This is why unless you type-bind with 
>>> pointers you don't actually have an OOP method, as the function will not 
>>> act upon the parent variable/structure.
>>>
>>> I think if you change your playground code to pass pointers into the 
>>> goroutines you'll either see race detector or clobbering.
>>>
>>> On Saturday, 21 April 2018 16:30:22 UTC+3, Ankit Gupta wrote:

 @Kaveh

 Slices are values but they refer to the same back array location. You 
 have created localized v which is appended inside goroutine which refer to 
 a location containing its own byte array of len=10. So, you are not really 
 referencing the same memory location as other v slice in the goroutine. 
 You 
 will be affected if you remove k,v:=k,v or append more than 10 bytes to v 
 inside goroutine which will take up space on next slice's bytes. 

 On Saturday, April 21, 2018 at 2:30:53 PM UTC+5:30, Kaveh Shahbazian 
 wrote:
>
> @ Louki Sumirniy
> Slices are values AFAIK. There is no passby pointer.
>
> And the point is, race detector does not flag anything: 
> https://play.golang.org/p/NC8mBwS1-0P
>


-- 
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: On Accepting Interfaces and Structs

[Kaveh Shahbazian]

The State type is just a POGO with no methods. The part that changes is the 
implementation of Clone() (State, error) method.

On Sunday, April 22, 2018 at 5:18:00 AM UTC+4:30, Louki Sumirniy wrote:
>
> I only just finally wrapped my head around this stuff and forgive me if I 
> have missed the point of the question but this is what my code has:
>
> type AbstractType alias/struct {}
>
> type abstractthing interface {
>   DoSomething(interface{})
> }
>
> func (a *AbstractType) DoSomething(b AbstractType) {
>
> }
>
> and then in my implementer:
>
> import ( 
>   "previousclass/path"
> )
>
> type ConcreteType alias/struct {}
>
> func (c *ConcreteType) DoSomething(t ConcreteType) {
>
> }
>
> You have to create a dummy function in the abstract type's source file in 
> order to use it in the superclass, as it effectively is, in order to use 
> its generalised functionality, but your app imports the second one, which 
> sucks up everything from the first and the function bound to the concrete 
> type overrides the abstract functions in the superclass, allowing you to 
> generalise part of the superclass and enable you to write a set of 
> functions with part of the implementation (for example, a tree store) while 
> letting you change the data type to something else. It's composition, as 
> opposed to inheritance.
>
> On Saturday, 21 April 2018 14:51:55 UTC+3, Kaveh Shahbazian wrote:
>>
>> Regarding "Accept interfaces, return concrete types", how can it be 
>> applied for structs that represent a payload/value?
>>
>> For example in package first, logger is defined as:
>>
>> type logger interface {
>> Debugf(template string, args ...interface{})
>> Errorf(template string, args ...interface{})
>> Infof(template string, args ...interface{})
>> }
>>
>> And package first only accepts a logger that implements the logger 
>> interface.
>>
>> Now lets assume there is a need for passing a struct too, like some 
>> config or state.
>>
>> This causes importing the original package that, that config or state 
>> struct resides in; while package first is happily accepting other things 
>> from that package using interfaces.
>>
>> For example in package second there is some tool that is represented 
>> using this interface in package first:
>>
>> type cloner interface {
>> Clone() (*second.State, error)
>> }
>>
>>
>> As it can be seen, now package first has to explicitly import package 
>> second, because of the type *second.State.
>>
>> Currently I break things by renaming the second package to something 
>> meaningless when importing like:
>>
>> type cloner interface {
>> Clone() (*p2nd.State, error)
>> }
>>
>> But this is not really a work around and package second leaks into the 
>> scope of package first anyway.
>>
>> Is there a way to actually achieve 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: proposal: disallow implicitly comparing true with value of interface{} in a switch with no value

[digg]

On Saturday, April 21, 2018 at 9:30:22 AM UTC-4, b97...@gmail.com wrote:
>
> var someInterfaceValue interface{}
> switch {
> case someInterfaceValue:  // proposal: compile error: non-bool used as 
> condition
> case someInterfaceValue == true: // OK
> }
>
> Sometimes carefulness is just not enough.
> One may type a wrong variable as the case condition, or a incomplete 
> condition.
> Why is this special? Because it's commonly used.
>

This proposal is equivalent to forbid the implicit bool "true" left operand.

-- 
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 Slices Made From Same Array Concurrently

[silviucapota]

Kaveh, for this particular circumstance, based on your playground snippet, 
that's why you got no race. 

As per the original 2013 race detector blog post, "Because of its design, 
the race detector can detect race conditions only when they are actually 
triggered by running code, which means it's important to run race-enabled 
binaries under realistic workloads."


On Sunday, 22 April 2018 07:56:48 UTC-4, Kaveh Shahbazian wrote:
>
> @Silviu
>
> But no slice expansion is happening.
>
> On Sunday, April 22, 2018 at 5:41:11 AM UTC+4:30, Silviu Capota Mera wrote:
>>
>> Hi Kaveh,
>>
>> Change the line:
>> *ptr = append(*ptr, []byte(fmt.Sprint*f("%02d"*, k1))...)
>>
>> to
>> *ptr = append(*ptr, []byte(fmt.Sprintf(*"%15d"*, k1))...)
>>
>> The buckets will overlap (more than 10 bytes) and you will get the race 
>> triggered in the detector
>>
>> Silviu
>>
>>
>> On Saturday, 21 April 2018 12:40:04 UTC-4, Kaveh Shahbazian wrote:
>>>
>>> @Ankit That's what I thought. Yet the code is accessing the same 
>>> underlying array. That is the part that worries me and -race does not 
>>> complain.
>>>
>>> @Louki Still no complain from -race! 
>>> https://play.golang.org/p/dUt0QE63RDK
>>>
>>> On Saturday, April 21, 2018 at 7:01:25 PM UTC+4:30, Louki Sumirniy wrote:

 Unless you pass pointers in Go, every time you hop in and out of a new 
 scope any changes are discarded. This is why unless you type-bind with 
 pointers you don't actually have an OOP method, as the function will not 
 act upon the parent variable/structure.

 I think if you change your playground code to pass pointers into the 
 goroutines you'll either see race detector or clobbering.

 On Saturday, 21 April 2018 16:30:22 UTC+3, Ankit Gupta wrote:
>
> @Kaveh
>
> Slices are values but they refer to the same back array location. You 
> have created localized v which is appended inside goroutine which refer 
> to 
> a location containing its own byte array of len=10. So, you are not 
> really 
> referencing the same memory location as other v slice in the goroutine. 
> You 
> will be affected if you remove k,v:=k,v or append more than 10 bytes to v 
> inside goroutine which will take up space on next slice's bytes. 
>
> On Saturday, April 21, 2018 at 2:30:53 PM UTC+5:30, Kaveh Shahbazian 
> wrote:
>>
>> @ Louki Sumirniy
>> Slices are values AFAIK. There is no passby pointer.
>>
>> And the point is, race detector does not flag anything: 
>> https://play.golang.org/p/NC8mBwS1-0P
>>
>

-- 
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: proposal: disallow implicitly comparing true with value of interface{} in a switch with no value

[Louki Sumirniy]

In that code, isn't the interface{} typing overridden by the value assigned 
to it? The override is compile-time, isn't it? Otherwise that condition 
would not evaluate to true. If you change the assignment to any other value 
the code will fall right through and no case will be executed. 

On Sunday, 22 April 2018 11:40:25 UTC+3, Jérôme Champion wrote:
>
> The syntax is correct:  https://play.golang.org/p/t5Oi8vyCsbw
> I don't think comparing an interface to a boolean in a switch is very 
> common. It would need some strong evidence to justify adding an exception 
> to the rule.
>
> Le dimanche 22 avril 2018 02:53:14 UTC+2, Louki Sumirniy a écrit :
>>
>> Your syntax is wrong. I think you mean this:
>>
>> var someInterfaceValue interface{}
>>
>> // do something that puts a value in above variable
>>
>> switch someInterfaceValue {
>>   case true:
>> // do something
>>   default:
>> // do something else
>> }
>>
>> On Saturday, 21 April 2018 16:30:22 UTC+3, b97...@gmail.com wrote:
>>>
>>> var someInterfaceValue interface{}
>>> switch {
>>> case someInterfaceValue:  // proposal: compile error: non-bool used 
>>> as condition
>>> case someInterfaceValue == true: // OK
>>> }
>>>
>>> Sometimes carefulness is just not enough.
>>> One may type a wrong variable as the case condition, or a incomplete 
>>> condition.
>>> Why is this special? Because it's commonly used.
>>>
>>

-- 
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] Question regarding runtime.ReadMemStats

[Ankit Gupta]

I ran a goroutine 3 times, at the end of each, I run runtime.GC() and print 
mem stats. Just before exiting program, I do it once more. This is what I 
get in each runs - 

HeapSys = 720896 Alloc = 48408 TotalAlloc = 62464 StackSys = 327680 Sys = 
2461696 GCSys = 63488 NumGC = 1 PauseTotalNs = 1680857
HeapSys = 720896 Alloc = 48408 TotalAlloc = 63496 StackSys = 327680 Sys = 
2461696 GCSys = 63488 NumGC = 2 PauseTotalNs = 1905615
HeapSys = 753664 Alloc = 48408 TotalAlloc = 64528 StackSys = 294912 Sys = 
2461696 GCSys = 63488 NumGC = 3 PauseTotalNs = 2123106
HeapSys = 786432 Alloc = 48280 TotalAlloc = 65560 StackSys = 262144 Sys = 
2461696 GCSys = 63488 NumGC = 4 PauseTotalNs = 2341283

While I understand most of the allocations in my program, I don't get why 
*HeapSys* is more than 15 times of *Alloc*. If this is reserved virtual 
space from OS, why does it have to be this big? Any reasons.

-- 
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: disallow implicitly comparing true with value of interface{} in a switch with no value

[roger peppe]

That's an interesting case. It does seem to me that if you have an
interface-typed value in a no-condition switch statement then it's quite
likely to be an accident. However, AFAICS this issue applies only to the
empty interface type, so ISTM that it is unlikely to be common.

It's too late for Go 1, as this would be a backwardly incompatible change.
It is possible that it might be worth adding as a go vet check though. It
would add weight if a search of a large corpus of Go code found a good
number of places where this form was used in error.

If it *was* a rule that the type must be bool, then it would be simple
enough to work around the restriction if you really did want an interface
in there - just add "== true".

On Sat, 21 Apr 2018 2:29 pm ,  wrote:

> var someInterfaceValue interface{}
> switch {
> case someInterfaceValue:  // proposal: compile error: non-bool used as
> condition
> case someInterfaceValue == true: // OK
> }
>
> Sometimes carefulness is just not enough.
> One may type a wrong variable as the case condition, or a incomplete
> condition.
> Why is this special? Because it's commonly used.
>
> --
> 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.
>

On 21 Apr 2018 14:29,  wrote:

var someInterfaceValue interface{}
switch {
case someInterfaceValue:  // proposal: compile error: non-bool used as
condition
case someInterfaceValue == true: // OK
}

Sometimes carefulness is just not enough.
One may type a wrong variable as the case condition, or a incomplete
condition.
Why is this special? Because it's commonly used.

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

-- 
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] oksvg and rasterx; SVG 2.0 path compliant renderer and rasterizer

[Steven Wiley]

Hi all,

I needed to write an SVG renderer; something that draws an SVG file onto an 
image (not to be confused with an SVG generator such as SVGo). I wanted to 
do this in native go, and not rely on wrapping pre-existing C code.

The golang 2D drawing packages  I could find were not capable of rendering 
stroked paths with joins like 'arc' or 'miter-clip', or specifying between 
ending a stroked path as an open line or a closed loop. So, in order to 
draw SVG 2.0  compliant stroked and 
dashed-stroked paths, I refactored and enhanced the raster package from  
the golang translation of freetype, used 
by many of the 2D packages, into a new package; rasterx 
. More information on the 
refactorization is available in the readme.

The SVG renderer, oksvg , processes only 
a basic sub-set of the SVG specification, but it is capable of faithfully 
rendering many, probably most, but certainly not all, of the free and 
commercial SVG icons available. I have been focusing on just the basics the 
path functions, and many elements like defs, gradients, or animations have 
not been added at this point. However, the full SVG 2.0 path specification 
is implemented and even exceeded, since rasterx can perform additional path 
functions that are not described by the SVG 2.0 specification. Also, when 
an SVG file is parsed, oksvg can be set to ignore, log, or error-out when 
reading an unrecognized SVG element.

So now we can render a large set of SVG icons in native go! I hope some of 
you find this useful. Please check it out and let me know what you think. 
The image below demonstrates the effect of some of the available joining 
and capping functions.

Cheers!


[image: TestShapes.png] 

-- 
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: proposal: disallow implicitly comparing true with value of interface{} in a switch with no value

[b97tsk]

Well, that "commonly used" is about the no-condition switch, so it's 
possible that one may make this kind of mistakes, which I did and was 
surprised for a moment that the Go compiler lived with 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Accessing Slices Made From Same Array Concurrently

[Kaveh Shahbazian]

Thanks Silviu,

Even when accessing the array directly in a concurrent manner, -race does 
not complain: https://play.golang.org/p/l-c2aPeOGwF

So, is this assumption correct? : As long as two goroutines are not 
modifying the same item in an array, accessing it is safe.

The initial intent was to implement a buffer pool; large arrays providing 
fixed length slices of (for example) 4KB length - and if the length of a 
message was above that, a slice would be allocated separately.

On Sunday, April 22, 2018 at 6:15:04 PM UTC+4:30, Silviu Capota Mera wrote:
>
> Kaveh, for this particular circumstance, based on your playground snippet, 
> that's why you got no race. 
>
> As per the original 2013 race detector blog post, "Because of its design, 
> the race detector can detect race conditions only when they are actually 
> triggered by running code, which means it's important to run race-enabled 
> binaries under realistic workloads."
>
>
> On Sunday, 22 April 2018 07:56:48 UTC-4, Kaveh Shahbazian wrote:
>>
>> @Silviu
>>
>> But no slice expansion is happening.
>>
>> On Sunday, April 22, 2018 at 5:41:11 AM UTC+4:30, Silviu Capota Mera 
>> wrote:
>>>
>>> Hi Kaveh,
>>>
>>> Change the line:
>>> *ptr = append(*ptr, []byte(fmt.Sprint*f("%02d"*, k1))...)
>>>
>>> to
>>> *ptr = append(*ptr, []byte(fmt.Sprintf(*"%15d"*, k1))...)
>>>
>>> The buckets will overlap (more than 10 bytes) and you will get the race 
>>> triggered in the detector
>>>
>>> Silviu
>>>
>>>
>>> On Saturday, 21 April 2018 12:40:04 UTC-4, Kaveh Shahbazian wrote:

 @Ankit That's what I thought. Yet the code is accessing the same 
 underlying array. That is the part that worries me and -race does not 
 complain.

 @Louki Still no complain from -race! 
 https://play.golang.org/p/dUt0QE63RDK

 On Saturday, April 21, 2018 at 7:01:25 PM UTC+4:30, Louki Sumirniy 
 wrote:
>
> Unless you pass pointers in Go, every time you hop in and out of a new 
> scope any changes are discarded. This is why unless you type-bind with 
> pointers you don't actually have an OOP method, as the function will not 
> act upon the parent variable/structure.
>
> I think if you change your playground code to pass pointers into the 
> goroutines you'll either see race detector or clobbering.
>
> On Saturday, 21 April 2018 16:30:22 UTC+3, Ankit Gupta wrote:
>>
>> @Kaveh
>>
>> Slices are values but they refer to the same back array location. You 
>> have created localized v which is appended inside goroutine which refer 
>> to 
>> a location containing its own byte array of len=10. So, you are not 
>> really 
>> referencing the same memory location as other v slice in the goroutine. 
>> You 
>> will be affected if you remove k,v:=k,v or append more than 10 bytes to 
>> v 
>> inside goroutine which will take up space on next slice's bytes. 
>>
>> On Saturday, April 21, 2018 at 2:30:53 PM UTC+5:30, Kaveh Shahbazian 
>> wrote:
>>>
>>> @ Louki Sumirniy
>>> Slices are values AFAIK. There is no passby pointer.
>>>
>>> And the point is, race detector does not flag anything: 
>>> https://play.golang.org/p/NC8mBwS1-0P
>>>
>>

-- 
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] Type func binding and interfaces

[Louki Sumirniy]

I essentially am trying to find an effective method in Go, preferably not 
too wordy, that lets me create an abstract data type, a struct, and a set 
of functions that bind to a different data type, and that I can write, 
preferably not in too much code, a change that allows the data type of the 
embedded data to be changed. It's basically kinda inheritance, but after 
much fiddling I found a hackish sorta way that isn't *too* boilerplate 
filled:

type nullTester func(*Bast, uint32) bool

type Bast struct {
  ...
  isNullnullTester
  ...
 }

func isNull(b *Bast, d uint32) bool {
  return d == 0
}

func NewBast() (b *Bast) {
  ...
  b.isNull = isNull
  ...
}

// IsNull - tests if a value in the tree is null
func (b *Bast) IsNull(d uint32) bool {
  return b.isNull(b, d)
}


Now, bear in mind I haven't shown all of the code. But there is a slice 
array in the Bast struct, and I it is defined as an interface{} and isNull 
is one of a set of operators that have to be written to match the type used 
in the slice store, this might be a bad example because it doesn't actually 
act on the interface typed slice, but the point here is just this:

It does not appear to be possible to make the type specification from the 
top line match the function signature of the type-bound function in the 
bottom of the code snippet. I haven't been able to find anything that shows 
that a func type can have a method binding.

https://github.com/calibrae-project/bast/blob/master/pkg/bast/bast.go is 
where my WiP lives. This slightly hacky solution seems sound to me, I just 
don't like to be forced to use workarounds like this. If a type signature 
cannot be written that matches a method, yet I can do it this way, I don't 
see what purpose this serves as far as any kind of correctness and 
bug-resistance issues go. I would have to deal with a lot more potential 
bugs if I had to concretely implemennt this library for the sake of 1 slice 
and 7 functions out of a much larger library that conceptually is intended 
to only deal with comparable, mainly numerical values anyway.

-- 
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: Type func binding and interfaces

[matthewjuran]

Interface types are useful when the data structure is varied. Why not an 
interface containing these varying functions as methods instead of function 
types?

Matt

On Sunday, April 22, 2018 at 5:20:12 PM UTC-5, Louki Sumirniy wrote:
>
> I essentially am trying to find an effective method in Go, preferably not 
> too wordy, that lets me create an abstract data type, a struct, and a set 
> of functions that bind to a different data type, and that I can write, 
> preferably not in too much code, a change that allows the data type of the 
> embedded data to be changed. It's basically kinda inheritance, but after 
> much fiddling I found a hackish sorta way that isn't *too* boilerplate 
> filled:
>
> type nullTester func(*Bast, uint32) bool
>
> type Bast struct {
>   ...
>   isNullnullTester
>   ...
>  }
>
> func isNull(b *Bast, d uint32) bool {
>   return d == 0
> }
>
> func NewBast() (b *Bast) {
>   ...
>   b.isNull = isNull
>   ...
> }
>
> // IsNull - tests if a value in the tree is null
> func (b *Bast) IsNull(d uint32) bool {
>   return b.isNull(b, d)
> }
>
>
> Now, bear in mind I haven't shown all of the code. But there is a slice 
> array in the Bast struct, and I it is defined as an interface{} and isNull 
> is one of a set of operators that have to be written to match the type used 
> in the slice store, this might be a bad example because it doesn't actually 
> act on the interface typed slice, but the point here is just this:
>
> It does not appear to be possible to make the type specification from the 
> top line match the function signature of the type-bound function in the 
> bottom of the code snippet. I haven't been able to find anything that shows 
> that a func type can have a method binding.
>
> https://github.com/calibrae-project/bast/blob/master/pkg/bast/bast.go is 
> where my WiP lives. This slightly hacky solution seems sound to me, I just 
> don't like to be forced to use workarounds like this. If a type signature 
> cannot be written that matches a method, yet I can do it this way, I don't 
> see what purpose this serves as far as any kind of correctness and 
> bug-resistance issues go. I would have to deal with a lot more potential 
> bugs if I had to concretely implemennt this library for the sake of 1 slice 
> and 7 functions out of a much larger library that conceptually is intended 
> to only deal with comparable, mainly numerical values anyway.
>

-- 
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 Slices Made From Same Array Concurrently

[silviucapota]

your assumption: "As long as two goroutines are not modifying the same item 
in an array, accessing it is safe."  is not entirely correct, or is 
incomplete. 
Even when only one goroutine is writing to that item, and a different one 
or more are reading, you still got a race, and the race detector will flag 
it. E.g. with 10 million iterations: https://play.golang.org/p/bpUQEyZMMy4


On Sunday, 22 April 2018 16:20:40 UTC-4, Kaveh Shahbazian wrote:
>
> Thanks Silviu,
>
> Even when accessing the array directly in a concurrent manner, -race does 
> not complain: https://play.golang.org/p/l-c2aPeOGwF
>
> So, is this assumption correct? : As long as two goroutines are not 
> modifying the same item in an array, accessing it is safe.
>
> The initial intent was to implement a buffer pool; large arrays providing 
> fixed length slices of (for example) 4KB length - and if the length of a 
> message was above that, a slice would be allocated separately.
>
> On Sunday, April 22, 2018 at 6:15:04 PM UTC+4:30, Silviu Capota Mera wrote:
>>
>> Kaveh, for this particular circumstance, based on your playground 
>> snippet, that's why you got no race. 
>>
>> As per the original 2013 race detector blog post, "Because of its design, 
>> the race detector can detect race conditions only when they are actually 
>> triggered by running code, which means it's important to run race-enabled 
>> binaries under realistic workloads."
>>
>>
>> On Sunday, 22 April 2018 07:56:48 UTC-4, Kaveh Shahbazian wrote:
>>>
>>> @Silviu
>>>
>>> But no slice expansion is happening.
>>>
>>> On Sunday, April 22, 2018 at 5:41:11 AM UTC+4:30, Silviu Capota Mera 
>>> wrote:

 Hi Kaveh,

 Change the line:
 *ptr = append(*ptr, []byte(fmt.Sprint*f("%02d"*, k1))...)

 to
 *ptr = append(*ptr, []byte(fmt.Sprintf(*"%15d"*, k1))...)

 The buckets will overlap (more than 10 bytes) and you will get the race 
 triggered in the detector

 Silviu


 On Saturday, 21 April 2018 12:40:04 UTC-4, Kaveh Shahbazian wrote:
>
> @Ankit That's what I thought. Yet the code is accessing the same 
> underlying array. That is the part that worries me and -race does not 
> complain.
>
> @Louki Still no complain from -race! 
> https://play.golang.org/p/dUt0QE63RDK
>
> On Saturday, April 21, 2018 at 7:01:25 PM UTC+4:30, Louki Sumirniy 
> wrote:
>>
>> Unless you pass pointers in Go, every time you hop in and out of a 
>> new scope any changes are discarded. This is why unless you type-bind 
>> with 
>> pointers you don't actually have an OOP method, as the function will not 
>> act upon the parent variable/structure.
>>
>> I think if you change your playground code to pass pointers into the 
>> goroutines you'll either see race detector or clobbering.
>>
>> On Saturday, 21 April 2018 16:30:22 UTC+3, Ankit Gupta wrote:
>>>
>>> @Kaveh
>>>
>>> Slices are values but they refer to the same back array location. 
>>> You have created localized v which is appended inside goroutine which 
>>> refer 
>>> to a location containing its own byte array of len=10. So, you are not 
>>> really referencing the same memory location as other v slice in the 
>>> goroutine. You will be affected if you remove k,v:=k,v or append more 
>>> than 
>>> 10 bytes to v inside goroutine which will take up space on next slice's 
>>> bytes. 
>>>
>>> On Saturday, April 21, 2018 at 2:30:53 PM UTC+5:30, Kaveh Shahbazian 
>>> wrote:

 @ Louki Sumirniy
 Slices are values AFAIK. There is no passby pointer.

 And the point is, race detector does not flag anything: 
 https://play.golang.org/p/NC8mBwS1-0P

>>>

-- 
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: Type func binding and interfaces

[Louki Sumirniy]

You will see in the code I linked in the previous message that I already do 
have the interfaces in there. They can't be bound to the struct directly 
because I can't specify a function type that matches the signature, thus 
the use of a wrapper, and the interface types in the parameters.

I just can't override them, and the great bulk of the code is not these 
small set of initialiser/allocator/comparator/getter/setter functions, so 
to have to search and replace through the whole thing, and maintain 
multiple nearly identical pieces of source code for the sake of 7 functions 
that are all very short, and differ between these versions, when everything 
else is the same... then I find a bug in one version, in the outer shell of 
the code and I have to merge every change of it into the other 5 
versions... it's extremely cumbersome. 

The solution I have shown is just the first thing that looks to me like it 
would work. I have read tons of tutorials about composition and 
polymorphism and embedding in go, and in the end I pieced this together 
from several different things I learned. I tried several different things. 
It just makes absolutely no sense to have to go through and add a load of 
maintenance work to my code just so I can create, expand, read, write and 
compare values stored within the otherwise identical data structure.

On Monday, 23 April 2018 01:44:43 UTC+3, matthe...@gmail.com wrote:
>
> Interface types are useful when the data structure is varied. Why not an 
> interface containing these varying functions as methods instead of function 
> types?
>
> Matt
>
> On Sunday, April 22, 2018 at 5:20:12 PM UTC-5, Louki Sumirniy wrote:
>>
>> I essentially am trying to find an effective method in Go, preferably not 
>> too wordy, that lets me create an abstract data type, a struct, and a set 
>> of functions that bind to a different data type, and that I can write, 
>> preferably not in too much code, a change that allows the data type of the 
>> embedded data to be changed. It's basically kinda inheritance, but after 
>> much fiddling I found a hackish sorta way that isn't *too* boilerplate 
>> filled:
>>
>> type nullTester func(*Bast, uint32) bool
>>
>> type Bast struct {
>>   ...
>>   isNullnullTester
>>   ...
>>  }
>>
>> func isNull(b *Bast, d uint32) bool {
>>   return d == 0
>> }
>>
>> func NewBast() (b *Bast) {
>>   ...
>>   b.isNull = isNull
>>   ...
>> }
>>
>> // IsNull - tests if a value in the tree is null
>> func (b *Bast) IsNull(d uint32) bool {
>>   return b.isNull(b, d)
>> }
>>
>>
>> Now, bear in mind I haven't shown all of the code. But there is a slice 
>> array in the Bast struct, and I it is defined as an interface{} and isNull 
>> is one of a set of operators that have to be written to match the type used 
>> in the slice store, this might be a bad example because it doesn't actually 
>> act on the interface typed slice, but the point here is just this:
>>
>> It does not appear to be possible to make the type specification from the 
>> top line match the function signature of the type-bound function in the 
>> bottom of the code snippet. I haven't been able to find anything that shows 
>> that a func type can have a method binding.
>>
>> https://github.com/calibrae-project/bast/blob/master/pkg/bast/bast.go is 
>> where my WiP lives. This slightly hacky solution seems sound to me, I just 
>> don't like to be forced to use workarounds like this. If a type signature 
>> cannot be written that matches a method, yet I can do it this way, I don't 
>> see what purpose this serves as far as any kind of correctness and 
>> bug-resistance issues go. I would have to deal with a lot more potential 
>> bugs if I had to concretely implemennt this library for the sake of 1 slice 
>> and 7 functions out of a much larger library that conceptually is intended 
>> to only deal with comparable, mainly numerical values anyway.
>>
>

-- 
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] Here are some solaris x86 binaries

[phil]

FYI, I've put together a solaris x86 page on my site for Go.

It provides go 1.10 binaries, as well as gccgo binaries, for Solaris 11.

http://www.bolthole.com/solaris/go-lang.html

-- 
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] Extension for type assertion of interface array

[nsakthi93]

Type assertion is not required in the given example (from array of structs 
to interface), But you need to assert if array of one interface is type 
casted to array of another interface. I started this thread to know whether 
this pattern requires a language level change to avoid unwanted array copy 
and code duplication for similar pattern of code. I agree that there are 
many ways in Golang to make this code run but shouldn't the language 
provide an extension to already available syntax to address this in simple 
and elegant way?


On Thursday, 19 April 2018 21:36:38 UTC+5:30, Jake Montgomery wrote:
>
> Yes, to use the functions above you will need to copy the slices of 
> landSpaceto slices of the respective interface types. But I you do not 
> need to do any type assertions. Like this: 
>
> https://play.golang.org/p/eFTUqpImyPc
> package main
>
> import (
> "fmt"
> )
>
> type landSpace struct{}
>
> func (*landSpace) Foo() {
> fmt.Println("Foo")
> }
>
> func (*landSpace) Bar() {
> fmt.Println("Bar")
> }
>
> type Shape interface {
> Foo()
> }
>
> type Property interface {
> Bar()
> }
>
> var a []*landSpace
>
> func processShapes(shapes []Shape) {
> for _, s := range shapes {
> s.Foo()
> }
> }
>
> func evaluateProperties(properties []Property) {
> for _, p := range properties {
> p.Bar()
> }
> }
>
> func main() {
> a = append(a, &landSpace{}, &landSpace{})
>
> var shapes []Shape
> for _, l := range a {
> shapes = append(shapes, l)
> }
> processShapes(shapes)
>
> var properties []Property
> for _, l := range a {
> properties = append(properties, l)
> }
> evaluateProperties(properties)
> fmt.Println("Hello, playground")
> }
>
> Is this what you meant? I see how something like shapes = a.([]Shape) would 
> be convenient to avoid having to do an explicit conversion. Hoever, until 
> Go has some form of generics,  it seems unlikely. Keep in mind that a Shape 
> and *landSpace are two different types, with different in memory 
> representations. So to avoid major language changes, the type assertion 
> would have to create a new slice anyway.
>
>
> On Thursday, April 19, 2018 at 12:59:12 AM UTC-4, Sakthi Natesan wrote:
>>
>> Usescases that I came across doesn't involve []interface{}. 
>>
>> My usecases will be similar to this sample code 
>> 
>>
>> type landSpace struct {
>> //consider that landSpace implements all functions from both Shape and 
>> property interfaces
>> ...
>> }
>> type Shape interface {
>> ...
>> }
>>
>>
>> type property interface {
>>
>> ...
>> }
>>
>>
>> var a []*landSpace
>>
>> func processShapes(shapes []Shape) {
>> //
>> }
>>
>> func evaluateProperties(properties []Property) {
>> //
>> }
>>
>>
>>
>> If I want to pass the variable 'a' to both the functions, then I have to 
>> write two functions to clone and typeAssert to respective interfaces.
>>
>>
>> On Wednesday, 18 April 2018 19:53:33 UTC+5:30, Jan Mercl wrote:
>>>
>>> On Wed, Apr 18, 2018 at 4:13 PM  wrote:
>>>
>>> When possible, avoid using '[]interface{}' and use just 'interface{}' 
>>> instead: https://play.golang.org/p/oPtPoGChkMZ.
>>>
>>>
>>> -- 
>>>
>>> -j
>>>
>>

-- 
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: Type func binding and interfaces

[Louki Sumirniy]

https://github.com/golang/go/issues/24996#issuecomment-383424588

It seems that (Type).FuncName in the assignment binds to the struct... I am 
glad I found an answer so quickly because my hackish solution was gonna be 
implemented today.

On Monday, 23 April 2018 02:20:47 UTC+3, Louki Sumirniy wrote:
>
> You will see in the code I linked in the previous message that I already 
> do have the interfaces in there. They can't be bound to the struct directly 
> because I can't specify a function type that matches the signature, thus 
> the use of a wrapper, and the interface types in the parameters.
>
> I just can't override them, and the great bulk of the code is not these 
> small set of initialiser/allocator/comparator/getter/setter functions, so 
> to have to search and replace through the whole thing, and maintain 
> multiple nearly identical pieces of source code for the sake of 7 functions 
> that are all very short, and differ between these versions, when everything 
> else is the same... then I find a bug in one version, in the outer shell of 
> the code and I have to merge every change of it into the other 5 
> versions... it's extremely cumbersome. 
>
> The solution I have shown is just the first thing that looks to me like it 
> would work. I have read tons of tutorials about composition and 
> polymorphism and embedding in go, and in the end I pieced this together 
> from several different things I learned. I tried several different things. 
> It just makes absolutely no sense to have to go through and add a load of 
> maintenance work to my code just so I can create, expand, read, write and 
> compare values stored within the otherwise identical data structure.
>
> On Monday, 23 April 2018 01:44:43 UTC+3, matthe...@gmail.com wrote:
>>
>> Interface types are useful when the data structure is varied. Why not an 
>> interface containing these varying functions as methods instead of function 
>> types?
>>
>> Matt
>>
>> On Sunday, April 22, 2018 at 5:20:12 PM UTC-5, Louki Sumirniy wrote:
>>>
>>> I essentially am trying to find an effective method in Go, preferably 
>>> not too wordy, that lets me create an abstract data type, a struct, and a 
>>> set of functions that bind to a different data type, and that I can write, 
>>> preferably not in too much code, a change that allows the data type of the 
>>> embedded data to be changed. It's basically kinda inheritance, but after 
>>> much fiddling I found a hackish sorta way that isn't *too* boilerplate 
>>> filled:
>>>
>>> type nullTester func(*Bast, uint32) bool
>>>
>>> type Bast struct {
>>>   ...
>>>   isNullnullTester
>>>   ...
>>>  }
>>>
>>> func isNull(b *Bast, d uint32) bool {
>>>   return d == 0
>>> }
>>>
>>> func NewBast() (b *Bast) {
>>>   ...
>>>   b.isNull = isNull
>>>   ...
>>> }
>>>
>>> // IsNull - tests if a value in the tree is null
>>> func (b *Bast) IsNull(d uint32) bool {
>>>   return b.isNull(b, d)
>>> }
>>>
>>>
>>> Now, bear in mind I haven't shown all of the code. But there is a slice 
>>> array in the Bast struct, and I it is defined as an interface{} and isNull 
>>> is one of a set of operators that have to be written to match the type used 
>>> in the slice store, this might be a bad example because it doesn't actually 
>>> act on the interface typed slice, but the point here is just this:
>>>
>>> It does not appear to be possible to make the type specification from 
>>> the top line match the function signature of the type-bound function in the 
>>> bottom of the code snippet. I haven't been able to find anything that shows 
>>> that a func type can have a method binding.
>>>
>>> https://github.com/calibrae-project/bast/blob/master/pkg/bast/bast.go 
>>> is where my WiP lives. This slightly hacky solution seems sound to me, I 
>>> just don't like to be forced to use workarounds like this. If a type 
>>> signature cannot be written that matches a method, yet I can do it this 
>>> way, I don't see what purpose this serves as far as any kind of correctness 
>>> and bug-resistance issues go. I would have to deal with a lot more 
>>> potential bugs if I had to concretely implemennt this library for the sake 
>>> of 1 slice and 7 functions out of a much larger library that conceptually 
>>> is intended to only deal with comparable, mainly numerical values anyway.
>>>
>>

-- 
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 Slices Made From Same Array Concurrently

[Tamás Gulácsi]

If there's no uncoordinated write and read/write of the same slot, then it's 
race-free.

Only reads does not need coordination.

I'm using a pattern alike: allocate a slice for the results, start the 
goroutines, each writing into it's own slot, then wait all of them to complete, 
and use the result array.
Here the "wait all" is crucial!

-- 
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 Slices Made From Same Array Concurrently

[Louki Sumirniy]

There does still need to be a mutex for reads on an element that is being 
written to. It's a minor edge case but it could cause a serious problem 
when it hoppens.

On Monday, 23 April 2018 08:36:38 UTC+3, Tamás Gulácsi wrote:
>
> If there's no uncoordinated write and read/write of the same slot, then 
> it's race-free.
>
> Only reads does not need coordination.
>
> I'm using a pattern alike: allocate a slice for the results, start the 
> goroutines, each writing into it's own slot, then wait all of them to 
> complete, and use the result array.
> Here the "wait all" is crucial!
>
>

-- 
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 Slices Made From Same Array Concurrently

[Kaveh Shahbazian]

@Silviu The code is mutating same item from two goroutines. While the 
original target is to create a buffer pool that their items is not being 
mutated from two goroutines - actually they can not do that because at a 
specific time only one goroutine has access to one buffer.

@Tamas Regarding "If there's no uncoordinated write and read/write of the 
same slot, then it's race-free", is it safe to use slices with a shared 
underlying array, to be mutated from different goroutine? Every goroutine 
has access to one slice and that slice is only accessible to that one 
goroutine - until the goroutine is done and returns the slice to the pool.

>

-- 
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: New tutorial:Code a simple P2P blockchain in Go!

[Ryan Yogan]

Absolutely fantastic!  The series of articles were fun to work through, 
and, for once the subject matter of block-chains just clicked for me!

On Saturday, April 14, 2018 at 7:53:09 PM UTC-7, no...@mycoralhealth.com 
wrote:
>
>
> https://medium.com/@mycoralhealth/code-a-simple-p2p-blockchain-in-go-46662601f417
>
> Hi Everyone,
> We will show you how to run a simple blockchain in a truly decentralized, 
> Peer-to-Peer fashion.
>
> Let us know what you think!
>
>
>
>

-- 
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: Avoiding html/template's escaping of the + in

[Ben Bullock]

On Sunday, 1 April 2018 05:47:09 UTC+9, iv...@vucica.net wrote:
>
>
> This still gets escaped:
>
> https://play.golang.org/p/eZxQrHy1vCE
>
> Is this a bug? How do I avoid html/template escaping this, while still 
> escaping
> href?
>

Use text/template and explicitly escape the things which need to be escaped.
 

-- 
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] liteide x33.3 released

[visualfc]

Hi all.
LiteIDE x33.3 released!
This version support import line jump to package source file, support import 
hints for all package (GOPATH / vendor) on code completer.
Refactor debug, move golang Debug/DebugTest to build menu, fix build debug 
gcflags for selected go version, and better support go1.10..

* LiteIDE Home

* LiteIDE Source code

* Release downloads
* 
* 

### 2018.04.23 Ver X33.3
* LiteIDE
 * support import jump to package source file
 * support import hints for all package on code completer
 * add build & debug action to build menu
 * fix build debug gcflags for go version
* LiteApp
 * fix tab style sheet for Qt5.9 on macOS
 * project wizard add gocmdex/gopkgex for anywhere
* LiteBuild
 * build config file add debug support
 * golang build add debug/debugtest action
 * fix golang build debug gcflags depends for go version
* LiteDebug
 * filesystem add debug file action
 * remove internal golang build function
* LiteEditor
 * reimplemented backspace quotes audo insert/remove action
* GolangCode
 * parser import package for GOPATH 
 * fix vendor import for code completer
 * add import hints for all package option (default)
 * add parser cgo completer list on editor
* GolangEdit
 * fix import line navigate show link source
 * add import line jump to package file list
* QuickOpen
 * add quickopenfolder implement
* gotools
 * add new debugflag action for print debug gcflags for go version
 * types find import dir check vendor
 * types add import info and doc
 * fix astview pkg nil check

Sent from YoMail for Gmail

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