Re: [go-nuts] help with bazil.org/fuse

[Julian Phillips]

On 07/09/2016 01:08, Dan Kortschak wrote:

On Wed, 2016-09-07 at 09:05 +0930, Dan Kortschak wrote:

> These are just the flags passed to open. If you want to act on the
> truncate flag, do it once within open, not on every single
subsequent
> call to write.
>
That makes sense. So, we're narrowing down on my field of ignorance.

Am I right in thinking then that I should be just doing
`append((*f)[:off], b...)[:len(*f)+len(b)]` in the body of
Bytes.WriteAt?


It turns out that while that is an error, it is not the cause of the
problem.

The truncate operation that is causing the later out of bounds is the
explicit call to truncate(0):

err = f.Truncate(0)
if err != nil {
log.Fatalf("unexpected error truncating rw buffer: %v", err)
}
_, err = f.Write(data) // Causes panic in server below.

The write causes a WriteAt(data, off) where off is the size of the file
prior to the truncate call.

So the question is how do I ensure that the kernel sees that the file
size has been reduced.


The Truncate call has done that, however Write writes to the file 
offset, not the end of the file - so you need to change the file offset.


The truncate syscall doesn't change the file offset, so you need a Seek 
to do that (see truncate(2), lseek(2)).


Write should not expect that req.Offset is always within the current 
file size, it is entirely valid to read/write any offset you like.


(e.g. from lseek(2): The lseek() function allows the file offset to be 
set beyond the end of the file (but this does not change the size of the 
file).  If data is later written at this point, subsequent reads of the 
data in the gap (a "hole") return null bytes ('\0') until data is 
actually written into the gap.)


--
Julian

--
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 to build mock class?

[Simon Ritchie]

I think your problem is this:  You have a piece of code that uses a class.  
You have two classes, one real, one mock and you want to write some client 
code that can use either of them.  Is that right?

If you want to use mocking, you must write your classes in the appropriate 
way, so you may need to rework your solution.

There is an example of mocking in Donovan and Kernighan on page 309.  They 
show a function that uses a object called out that is an io.Writer.  The 
io.Writer is an interface and there are a number of structures (classes) 
available that satisfy it.  The out object is created outside the function 
that's being tested, so client code doesn't know what out is, it just knows 
that it satisfies the io.Writer interface.  The real application supplies 
an io.Writer that writes to the standard output channel and the test code 
supplies a different io.Writer which it can examine at the end of the test.

Another way to achieve the same effect is to pass the object into the 
function as a parameter, and declare the parameter as an interface.

So, if you are going to mock your class, you need to create an interface 
that the class satisfies.  In go, you can create the interface, and then 
create the structure, or you can create the structure and add the interface 
later.  Your structure MyClass has two methods, so you could write this 
interface:

type MyClass interface {

Object() (int)

PrintInfo()
}

Then rename your structure RealMyClass and create another one MockMyClass.  
Both should have methods object() and PrintInfo(), so they both satisfy the 
MyClass interface.  Write the code that uses the class so that it only 
knows that it is uses a MyClass.  

Essentially, you have three pieces of code, (a) a function that uses a 
class, which is the piece that you are going to test, (b) some code that 
tests (a) and (c) some code in your real application that uses (a).  (b) 
and (c) must both create a class that satisfies the interface and then call 
the function (a), supplying that class.  In your case, (b) would create a 
MockMyClass and (c) would create a RealMyClass.  (a) only knows that it is 
receiving a MyClass.

Small problem: you can't have two pieces of code in the same package with 
the same public methods, so you have to put RealMyClass and MockMyClass in 
different packages, ie in different directories.  I would put the interface 
and RealMyClass in the same package and create a separate directory 
structure for my mocks.

Bigger problem: an interface can only describe the class methods, so 
whatever the calling code needs to do, it must do it by calling class 
methods.  In your case, your client code can call PrintInfo() and 
Object().  This is why you may need to rework your code.

It's only possible to mock well-behaved structures.  A good example of 
something that can't be mocked is getting the URL from the Request object 
of the net/http package.  Request has a public field called URL.  If you 
have a Request object called request and you want to get hold of the URL 
embedded in it, you do this:

request.URL

That's not a call to a method, so you can't write an interface that 
describes this.  Request has some class methods, so you can create an 
interface that it satisfies, but that interface can't describe the 
behaviour of extracting the URL.  A function that's not a class method is 
another example of something that can't be mocked.

In other words, to support mocking, you must design your classes from the 
start so that they can be used through interfaces.

That's not to say that your real structures can't have public fields or 
functions that are not methods.  It's just that the code that you are going 
to test can't use them.  The piece that creates the object knows what it 
really is - a MockMyClass or whatever - so it can use its extra public 
fields and so on.  Only (a) has to work through the interface.  So, your 
mock object may have all sorts of extra features that allow the test code 
to extract useful information from it, and those don't need to be described 
by the interface.

You can create your own mock classes, but there are a number of frameworks 
that will create mocks to order for you.  This is one, and the home page 
includes a survey of others that are available:  
https://github.com/petergtz/pegomock.

A mocking framework creates a general-purpose mock object that can be 
controlled at runtime.  At the start of your test, you can say things like 
"when object() is called for the first time, return 3, and when it's called 
for the second time, return 2".  At the end of the test you can say 
something like "check that object() was called exactly twice".

Some people think that these mocking frameworks are unnecessary, or even a 
bad idea.  Certainly, it takes a bit of time to figure out how they work.  
My attitude is, you can use a mock that you create yourself or you can 
generate one using one of these frameworks, and you should use whate

Re: [go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

[sascha.l.teichmann via golang-nuts]

2016-09-06 22:47 GMT+02:00, Jason E. Aten :
> nice! would you mind releasing under an MIT or BSD license? I think it
> would be

It's MIT licensed now.

> worth posting the hashmap alone as a reusable library.

Maybe. For the shootout I prefer the embedded variant to
to demonstrate it is do-able without resorting to 3rd party libs.

> I hope you submit your code... I would be great to be on par with java all
> around! here's the instructions --
> 
> http://benchmarksgame.alioth.debian.org/play.html

I will try. Currently my Go version is ~10% faster than the Java one. 

-- 
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: In case you missed it: language benchmarks for Go 1.7, and language adoption

[sascha.l.teichmann via golang-nuts]

Am Mittwoch, 7. September 2016 11:12:21 UTC+2 schrieb 
sascha.l@googlemail.com:

> > I hope you submit your code... I would be great to be on par with java 
> all
> > around! here's the instructions --
> > 
> > http://benchmarksgame.alioth.debian.org/play.html
>
> I will try. Currently my Go version is ~10% faster than the Java one. 
>

https://alioth.debian.org/tracker/index.php?func=detail&aid=315484&group_id=100815&atid=413122
 

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

Re: [go-nuts] Go string to uintptr

[Luke Mauldin]

Thank you for the help, that worked.  I don't want to use cgo directly 
because of the compile overhead and because cgo prevents debugging on 
Windows.

Another question, if there is a C function with the declaration: void 
returnOutCString(char ** out)
I can call the function using:
var retPtr unsafe.Pointer
proc.Call(uintptr(retPtr))

But how do I convert retPtr to a Go String?

On Tuesday, September 6, 2016 at 4:13:01 PM UTC-5, Andy Balholm wrote:

> If you use cgo, there is a helper function C.CString to do this. 
>
> You can convert the string to a []byte, append 0 (for a null-terminated 
> string), and take the address of the first byte. 
>
> Andy

-- 
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: In case you missed it: language benchmarks for Go 1.7, and language adoption

['Isaac Gouy' via golang-nuts]

On Wednesday, September 7, 2016 at 2:12:21 AM UTC-7, 
sascha.l@googlemail.com wrote:

>
> Maybe. For the shootout I prefer the embedded variant to
> to demonstrate it is do-able without resorting to 3rd party libs.
>

Unfortunately, k-nucleotide now explicitly requires use of a built-in / 
library HashMap. Programs that used a custom hash-table implementation have 
been replaced.

By "library" I don't mean a custom hash table implementation that you've 
put into a library.

-- 
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] Why don't the embedded T1 and T2 clash?

[T L]

package main

import "fmt"

func main() {
var t3 T3
t3.T1.a = 5
t3.T2.a = 3
t3.T1.f() // 5
t3.T2.f() // 3
t3.f() // 5 // <-> t3.T1.f()
t3.a = 7 // <=> t3.T1.a = 7
t3.T1.f() // 7
t3.T2.f() // 3
}

type T1 struct {
a int
}

func (t T1) f() {
fmt.Println(t.a)
}

type T2 struct {
T1
}

type T3 struct {
T1
T2
}

-- 
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] reasonable or not?

[T L]

package main

import "fmt"

func main() {
var t2 T2
t2.a = 5
t2.T1.a = 3
t2.f() // 3
t2.T1.f() // 3
}

type T1 struct {
a int
}

func (t T1) f() {
fmt.Println(t.a)
}

type T2 struct {
T1
a int
}

-- 
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] Why don't the embedded T1 and T2 clash?

[T L]

// 11.go
package main
import "fmt"


func main() {
var is []interface{}
fmt.Println(is...)

var t3 T3
t3.T1.a = 5
t3.T2.a = 3
t3.T1.f() // 5
t3.T2.f() // 3
t3.f() // 5 // <-> t3.T1.f()
t3.a = 7 // <=> t3.T1.a = 7
t3.T1.f() // 7
t3.T2.f() // 3
}

type T1 struct {
a int
}

func (t T1) f() {
fmt.Println(t.a)
}

type T2 struct {
T1
//a int
}

type T3 struct {
T1
T2
}

-- 
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] Why don't the embedded T1 and T2 clash?

[Jan Mercl]

On Wed, Sep 7, 2016 at 4:42 PM T L  wrote:

See https://golang.org/ref/spec#Selectors and explain why do you think a
clash should happen.
-- 

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

Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

[T L]

On Wednesday, September 7, 2016 at 10:56:38 PM UTC+8, Jan Mercl wrote:
>
> On Wed, Sep 7, 2016 at 4:54 PM T L > 
> wrote:
>
> https://golang.org/doc/go1compat
>

yes, risk exists?
 

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

Re: [go-nuts] reasonable or not?

[Shawn Milochik]

If you asked a specific question it would be really helpful in answering
you.

If you mean the fact that t2.f() returns the same result as t2.T1.f(), then
yes -- that's how embedding works in Go if there is no conflicting name at
the same level.

-- 
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] reasonable or not?

[Jan Mercl]

On Wed, Sep 7, 2016 at 4:56 PM T L  wrote:

Reasonable.

-- 

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

Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

[Jan Mercl]

On Wed, Sep 7, 2016 at 4:54 PM T L  wrote:

https://golang.org/doc/go1compat

-- 

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

Re: [go-nuts] Go string to uintptr

[Tamás Gulácsi]

That's tricky if you don't know the length, as you must search for the 0 byte.
a:=([1<<20]byte(unsafe.Pointer(retPtr)))
var b string
for i:=0;i<1<<20;i++{ if a[i]==0 {b=string(a[:i])}}

-- 
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] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

[T L]

.

-- 
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: In case you missed it: language benchmarks for Go 1.7, and language adoption

[sascha.l.teichmann via golang-nuts]

Am Mittwoch, 7. September 2016 16:32:19 UTC+2 schrieb Isaac Gouy:
>
>
>
> On Wednesday, September 7, 2016 at 2:12:21 AM UTC-7, 
> sascha.l@googlemail.com wrote:
>
>>
>> Maybe. For the shootout I prefer the embedded variant to
>> to demonstrate it is do-able without resorting to 3rd party libs.
>>
>
> Unfortunately, k-nucleotide now explicitly requires use of a built-in / 
> library HashMap. Programs that used a custom hash-table implementation have 
> been replaced.
>
> By "library" I don't mean a custom hash table implementation that you've 
> put into a library.
>

Okay, I made https://bitbucket.org/s_l_teichmann/fastmap/overview which 
offers uint64 to int mapping.
There is no special code for k-nukleotide in this library. It is custom in 
the way that I've wrote it
and it is optimized, but there is no good reason to not use it in other 
projects, too.

It is Free Software / Open Source covered by the MIT license. So it can be 
used by other people, too.

If this does not count the Benchmark game follows a skewed defintion of a 
library.

Can you eleborate please, what a library is? And how do you think does this 
match to the library definition
in terms of Go?

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

Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

[T L]

On Wednesday, September 7, 2016 at 10:56:38 PM UTC+8, Jan Mercl wrote:
>
> On Wed, Sep 7, 2016 at 4:54 PM T L > 
> wrote:
>
> https://golang.org/doc/go1compat
>
>
Then how to write compatibility safe atomic pointer reads/writes code? Do I 
must use atomic.Value for pointers?
 

> -- 
>
> -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: gomobile init should have a flag if we want only IOS or Android

[Tristian Azuara]

I feel that it would be useful, a while ago we were only doing Android 
Go/mobile development and it forced the iOS download; consider opening an
issue here: https://github.com/golang/go/issues

On Monday, August 29, 2016 at 7:22:14 AM UTC-7, Abhishek Sinha wrote:
>
> While doing gomobile init on OSX, I get the following error
> gomobile: xcrun --show-sdk-path: exit status 1
> xcrun: error: SDK "iphoneos" cannot be located
> xcrun: error: SDK "iphoneos" cannot be located
> xcrun: error: unable to lookup item 'Path' in SDK 'iphoneos'
>
> Seems like xcode needs to be installed. Shouldn't there be a flag to 
> override this as one may exclusively want to use his device for android 
> development
>

-- 
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 1.7 Release Candidate 6 is released

[decrew09]

Go Gopher Toy on Kickstarter 


понедельник, 8 августа 2016 г., 23:44:40 UTC+3 пользователь Chris Broadfoot 
написал:
>
> Hello gophers,
>
> We have just released go1.7rc6, a release candidate for Go 1.7.
> Some say that it's the best one yet.
> It is cut from release-branch.go1.7 at the revision tagged go1.7rc6.
>
> Please help us by testing your Go programs with the release, and
> report any problems using the issue tracker:
>   https://golang.org/issue/new
>
> You can download binary and source distributions from the usual place: 
>   https://golang.org/dl/#go1.7rc6
>
> To find out what has changed in Go 1.7, read the draft release notes:
>   https://tip.golang.org/doc/go1.7
>
> Documentation for Go 1.7 is available at:
>   https://tip.golang.org/
>   
> A comprehensive list of changes since rc5 is here:
>   https://github.com/golang/go/compare/go1.7rc5...go1.7rc6
>   
> We plan to issue Go 1.7 in a week's time (August 15).
>
> Cheers,
> Chris
>

-- 
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] Handling multiple things happening at the same time

[Matt Davies]

Evening all

We're writing a new app and we'd like it to do a number of things at the 
same time.

We're planning on using gocron https://github.com/jasonlvhit/gocron to 
schedule grabbing some files from another source, then reformatting those 
files and placing them into a folder in the app.

That's all working fine.

What we now need to do is serve those file up from that folder all of the 
time using http.ListenAndServe.

Am I on the right track here?

https://tour.golang.org/concurrency/1

Or maybe gocron can schedule the http.ListenAndServe to run all the time?

Any tips or advice greatly appreciated.






-- 
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] Pointer literal

['Mihai B' via golang-nuts]

Hi there, 

Any HTTP API with PATCH support needs to use pointers on basic types. 
Therefore I'm wondering if there is any will/proposal to make pointer 
initialisation easier to work with basic types. The `standard` way is quite 
verbose so it seems that most APIs use functions for every possible type[1].
  I think these kind of functions should be provided in the standard 
library or preferably the syntax should be extended to support pointer 
literals < i.e. something like x := &("hello") ; x := &T("hello") x := 
&(30)  >;  .
  Some real world examples of APIs that reinvent the pointer initialisation 
google[2], amazon aws[3], github[4]. 


Mihai.


[0]
d := "new description"
r := T{Description:&d}
[1] 
func NewInt32(i int32)*int32{}

[2] https://github.com/google/google-api-go-client/issues/54
[3] https://godoc.org/github.com/aws/aws-sdk-go/aws
[4] https://godoc.org/github.com/google/go-github/github

-- 
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] Handling multiple things happening at the same time

[Asit Dhal]

Hi Matt,

You should run the cronjob in a separate process and the FileServer in 
another process.


mux := http.NewServeMux()
fs := http.FileServer(http.Dir("fileserver"))
mux.Handle("/", fs)
http.ListenAndServe(":8080", mux)


The FileServer package provided by the standard library will be good(and 
small). In this way, you just separate the responsibility between two 
processes.



On 9/7/2016 17:43, Matt Davies wrote:

Evening all

We're writing a new app and we'd like it to do a number of things at 
the same time.


We're planning on using gocron https://github.com/jasonlvhit/gocron to 
schedule grabbing some files from another source, then reformatting 
those files and placing them into a folder in the app.


That's all working fine.

What we now need to do is serve those file up from that folder all of 
the time using http.ListenAndServe.


Am I on the right track here?

https://tour.golang.org/concurrency/1

Or maybe gocron can schedule the http.ListenAndServe to run all the time?

Any tips or advice greatly appreciated.






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


--
Warm Regards,
Asit Dhal
http://asit-dhal.github.io/

--
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] reasonable or not?

[Asit Dhal]

Hi,

Both t2.f() and t2.T1.f() call the same method.

t2.f() calls t2.T1.f() (struct embedding). Inside T1.f(), value of a is 3.

t2.T1.f() calls directly.

Yes, this is reasonable.

If you want absolutely clear to thing to happen, then try this

package main

import "fmt"

func main() {
var t2 T2
t2.a = 5
t2.T1.a = 3
t2.f()
t2.T1.f()
}

type T1 struct {
a int
}

func (t T1) f() {
fmt.Println("T1: ", t.a)
}

type T2 struct {
T1
a int
}

func (t T2) f() {
fmt.Println("T2: ", t.a)
}


On 9/7/2016 16:56, T L wrote:


package main

import "fmt"

func main() {
var t2 T2
t2.a = 5
t2.T1.a = 3
t2.f() // 3
t2.T1.f() // 3
}

type T1 struct {
a int
}

func (t T1) f() {
fmt.Println(t.a)
}

type T2 struct {
T1
a int
}
--
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.


--
Warm Regards,
Asit Dhal
http://asit-dhal.github.io/

--
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: In case you missed it: language benchmarks for Go 1.7, and language adoption

['Isaac Gouy' via golang-nuts]

On Wednesday, September 7, 2016 at 8:15:09 AM UTC-7, 
sascha.l@googlemail.com wrote:

>
> If this does not count the Benchmark game follows a skewed defintion of a 
> library.
>
 

I'm sorry that you don't seem to understand what is expected.



> Can you eleborate please, what a library is? 
>

 Examples were given in the description:

http://attractivechaos.github.io/klib/#About

http://concurrencykit.org/index.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.

[go-nuts] Some code review

[nakotoffana]

I recently decided to make a small framework for my hobby-project needs. 
Inspired a little bit on revel.

I would like to get some advice or criticism about the code. I am a newbie 
at Go but I want to keep improving

This is the main repository of the framework 
https://github.com/yaimko/yaimko and here is a little skeleton about how it 
should be used https://github.com/yaimko/skeleton I know there is nothing 
new or fancy about this but I want to know if what I am doing its right or 
no.

There is no database support or tests  (except for the config parser) at 
the moment

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.

Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

[Ian Lance Taylor]

On Wed, Sep 7, 2016 at 8:16 AM, T L  wrote:
>
> On Wednesday, September 7, 2016 at 10:56:38 PM UTC+8, Jan Mercl wrote:
>>
>> On Wed, Sep 7, 2016 at 4:54 PM T L  wrote:
>>
>> https://golang.org/doc/go1compat
>>
>
> Then how to write compatibility safe atomic pointer reads/writes code? Do I
> must use atomic.Value for pointers?

Perhaps you could explain what kind of compatibility risk you are
concerned about that is not covered by the Go 1 compatibility
guarantee.  Please give an example of code that will work today but
that you think may stop working in future releases.  Thanks.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Pointer literal

[Ian Lance Taylor]

On Wed, Sep 7, 2016 at 8:42 AM, 'Mihai B' via golang-nuts
 wrote:
>
> Any HTTP API with PATCH support needs to use pointers on basic types.
> Therefore I'm wondering if there is any will/proposal to make pointer
> initialisation easier to work with basic types. The `standard` way is quite
> verbose so it seems that most APIs use functions for every possible type[1].
>   I think these kind of functions should be provided in the standard library
> or preferably the syntax should be extended to support pointer literals <
> i.e. something like x := &("hello") ; x := &T("hello") x := &(30)  >;  .
>   Some real world examples of APIs that reinvent the pointer initialisation
> google[2], amazon aws[3], github[4].

I'm not aware of any current proposal for this.  Any change like this
should go through the proposal process.  Note that the barrier for
language changes at this point is extremely high.

I'm skeptical that we could support &T(e) as T can itself contain
parentheses, so the result would be difficult to parse correctly.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] src/log/log.go: What makes it expensive in this code of log.go?

[Ian Lance Taylor]

On Tue, Sep 6, 2016 at 9:00 AM,   wrote:
>
> Hey, It's commented "release lock while getting caller info - it's
> expensive" in source code of /src/log/log.go line:150.
>
> I'm confused with what makes it expensive if we didn't unlock the l.mu ?
> Does goroutines have context ?

As the comment suggests, `runtime.Caller` is not especially fast.


> What will happen if I moved the _, file, line, ok =
> runtime.Caller(calldepth) like below? Is better than the upper one ?
>
> func (l *Logger) Output(calldepth int, s string) error {
> now := time.Now() // get this early.
> var file string
> var line int
>
> //moved here
> var ok bool
> _, file, line, ok = runtime.Caller(calldepth)
>
> l.mu.Lock()
> defer l.mu.Unlock()
>
> l.buf = l.buf[:0]
> if l.flag&(Lshortfile|Llongfile) != 0 {
> if !ok {
> file = "???"
> line = 0
> }
> l.formatHeader(&l.buf, now, file, line)
> }
>
> l.buf = append(l.buf, s...)
> if len(s) == 0 || s[len(s)-1] != '\n' {
> l.buf = append(l.buf, '\n')
> }
> _, err := l.out.Write(l.buf)
> return err
> }

This approach has to advantage of not holding the lock but the
disadvantage of calling runtime.Caller in all cases, although it's
only necessary when Lshortfile or Llongfile is set.  In particular
note that neither flag is set by default, so calling runtime.Caller in
all cases penalizes all log calls for the benefit of a minority.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

[sascha.l.teichmann via golang-nuts]

Am Mittwoch, 7. September 2016 18:20:28 UTC+2 schrieb Isaac Gouy:
>
>
>
> On Wednesday, September 7, 2016 at 8:15:09 AM UTC-7, 
> sascha.l@googlemail.com wrote:
>
>>
>> If this does not count the Benchmark game follows a skewed defintion of a 
>> library.
>>
>  
>
> I'm sorry that you don't seem to understand what is expected.
>

I do. But you still miss the point that 3rd party libs are just software
written by someone. If I follow your logic if some else (not me)
posts my solution (what is possible ... its free software) using my library
it will be accepted. Lets do this.

Taking this benchmark would only be possible if the 3rd party exists.
So you would have forbidden Ken and Dennis to create a benchmark entry for C
in the early days?  Because there were no such libs.
Theoretically speaking .. but I hope you get the point.
  

>
>> Can you eleborate please, what a library is? 
>>
>
>  Examples were given in the description:
>
> http://attractivechaos.github.io/klib/#About
>
> http://concurrencykit.org/index.html
>

But this are just two third party libraries, like mine. So where is the 
difference?
They may be larger, okay. But there is nothing in the rules which says that 
they
have to be complex and at least a few years old and so on and so on.
If you want to enforce this the description text has to be adjusted.
And no it's not about cheating, it's about software making.

I think an important fact of the Go ecosystem is the usage of small fitting 
libraries.


BTW: The godoc of my library can be found here:
https://godoc.org/bitbucket.org/s_l_teichmann/fastmap

-- 
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] help with bazil.org/fuse

[Julian Phillips]

On 07/09/2016 10:39, Dan Kortschak wrote:

On Wed, 2016-09-07 at 09:22 +0100, Julian Phillips wrote:

On 07/09/2016 01:08, Dan Kortschak wrote:
> On Wed, 2016-09-07 at 09:05 +0930, Dan Kortschak wrote:
>> > These are just the flags passed to open. If you want to act on the
>> > truncate flag, do it once within open, not on every single
>> subsequent
>> > call to write.
>> >
>> That makes sense. So, we're narrowing down on my field of ignorance.
>>
>> Am I right in thinking then that I should be just doing
>> `append((*f)[:off], b...)[:len(*f)+len(b)]` in the body of
>> Bytes.WriteAt?
>>
> It turns out that while that is an error, it is not the cause of the
> problem.
>
> The truncate operation that is causing the later out of bounds is the
> explicit call to truncate(0):
>
> err = f.Truncate(0)
> if err != nil {
> log.Fatalf("unexpected error truncating rw buffer: %v", err)
> }
> _, err = f.Write(data) // Causes panic in server below.
>
> The write causes a WriteAt(data, off) where off is the size of the file
> prior to the truncate call.
>
> So the question is how do I ensure that the kernel sees that the file
> size has been reduced.

The Truncate call has done that, however Write writes to the file
offset, not the end of the file - so you need to change the file 
offset.


The truncate syscall doesn't change the file offset, so you need a 
Seek

to do that (see truncate(2), lseek(2)).


That is at odds with the behaviour of this program
https://play.golang.org/p/wcazRYxRzy


Not here.  The resulting file is 31 bytes, with 19 leading NULs.  You 
won't see the NULs if you just cat the file though.



(though reading ftruncate(2) does point to further errors in my
implementation).


--
Julian

--
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] Go 1.7.1 is released

[Chris Broadfoot]

Hi gophers,

We have just released Go version 1.7.1, a minor point release.

This release includes fixes to the compiler, runtime, documentation, and the
compress/flate, hash/crc32, io, net, net/http, path/filepath, reflect, and 
syscall packages.
https://golang.org/doc/devel/release.html#go1.7.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with "git 
checkout go1.7.1" and build as usual.

Thanks to everyone who contributed to the release.

Chris

-- 
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] help with bazil.org/fuse

[Dan Kortschak]

Thank you so much, Julian. That makes everything clear.

On Wed, 2016-09-07 at 19:02 +0100, Julian Phillips wrote:
> Not here.  The resulting file is 31 bytes, with 19 leading NULs.  You 
> won't see the NULs if you just cat the file though.


-- 
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] Why don't the embedded T1 and T2 clash?

[xiiophen]

On Wednesday, 7 September 2016 15:59:50 UTC+1, Jan Mercl wrote:
>
> On Wed, Sep 7, 2016 at 4:42 PM T L > 
> wrote:
>
> See https://golang.org/ref/spec#Selectors and explain why do you think a 
> clash should happen.
> -- 
>
> -j
>

More specifically this (in the spec)

"For a value x of type T or *T where T is not a pointer or interface type, 
x.f denotes the field or method at the shallowest depth in T where there is 
such an f."


Covers the above behaviour 

and (from the same section)

" If there is not exactly one f with shallowest depth, the selector 
expression is illegal."


is not the case here - so works..

Thanks for bringing this up - is actually quite an obscure point. 

-- 
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] What was the rationale behind using braces for scoping?

[Anmol Sethi]

I’m not here to argue for using indentation for scoping. I just want to know 
why go decided to go with braces (hehe).

No but seriously, I only found a section on the FAQ that says "Go uses brace 
brackets for statement grouping, a syntax familiar to programmers who have 
worked with any language in the C family.”

Is there any other reason aside from familiarity that go went with braces for?

-- 
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] What was the rationale behind using braces for scoping?

[Rob Pike]

Familiarity and clean parsing. See blog.golang.org/2012/splash.article near
the end of section 4.

-rob


On Thu, Sep 8, 2016 at 10:13 AM, Anmol Sethi  wrote:

> I’m not here to argue for using indentation for scoping. I just want to
> know why go decided to go with braces (hehe).
>
> No but seriously, I only found a section on the FAQ that says "Go uses
> brace brackets for statement grouping, a syntax familiar to programmers who
> have worked with any language in the C family.”
>
> Is there any other reason aside from familiarity that go went with braces
> for?
>
> --
> 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.

Re: [go-nuts] What was the rationale behind using braces for scoping?

[Anmol Sethi]

That link is dead. I found https://talks.golang.org/2012/splash.article

That seems to be what you meant, thanks.

But the wording is a bit confusing. E.g. it says that "Some observers objected 
to Go's C-like block structure with braces, preferring the use of spaces for 
indentation.” Block structure with braces works fine with the use of spaces for 
indentation? I think that is supposed to say block structure with indentation.

> On Sep 7, 2016, at 8:26 PM, Rob Pike  wrote:
> 
> Familiarity and clean parsing. See blog.golang.org/2012/splash.article near 
> the end of section 4.
> 
> -rob
> 
> 
> On Thu, Sep 8, 2016 at 10:13 AM, Anmol Sethi  wrote:
> I’m not here to argue for using indentation for scoping. I just want to know 
> why go decided to go with braces (hehe).
> 
> No but seriously, I only found a section on the FAQ that says "Go uses brace 
> brackets for statement grouping, a syntax familiar to programmers who have 
> worked with any language in the C family.”
> 
> Is there any other reason aside from familiarity that go went with braces for?
> 
> --
> 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.

Re: [go-nuts] What was the rationale behind using braces for scoping?

[Rob Pike]

Sorry, yes, I typed the link from uncaffeinated memory. You found the one I
was referring to.

The wording is fine.

-rob


On Thu, Sep 8, 2016 at 10:40 AM, Anmol Sethi  wrote:

> That link is dead. I found https://talks.golang.org/2012/splash.article
>
> That seems to be what you meant, thanks.
>
> But the wording is a bit confusing. E.g. it says that "Some observers
> objected to Go's C-like block structure with braces, preferring the use of
> spaces for indentation.” Block structure with braces works fine with the
> use of spaces for indentation? I think that is supposed to say block
> structure with indentation.
>
> > On Sep 7, 2016, at 8:26 PM, Rob Pike  wrote:
> >
> > Familiarity and clean parsing. See blog.golang.org/2012/splash.article
> near the end of section 4.
> >
> > -rob
> >
> >
> > On Thu, Sep 8, 2016 at 10:13 AM, Anmol Sethi  wrote:
> > I’m not here to argue for using indentation for scoping. I just want to
> know why go decided to go with braces (hehe).
> >
> > No but seriously, I only found a section on the FAQ that says "Go uses
> brace brackets for statement grouping, a syntax familiar to programmers who
> have worked with any language in the C family.”
> >
> > Is there any other reason aside from familiarity that go went with
> braces for?
> >
> > --
> > 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.

Re: [go-nuts] Go string to uintptr

[Nigel Tao]

On Thu, Sep 8, 2016 at 1:03 AM, Tamás Gulácsi  wrote:
> for i:=0;i<1<<20;i++{ if a[i]==0 {b=string(a[:i])}}

The first part of that could be "for i := range a".

You probably want a "break" statement in there too. :-)

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

Re: [go-nuts] Go string to uintptr

[Nigel Tao]

On Thu, Sep 8, 2016 at 1:03 AM, Tamás Gulácsi  wrote:
> a:=([1<<20]byte(unsafe.Pointer(retPtr)))

Also, the type needs to be pointer-to-array, not array.

a:=(*[1<<20]byte)(unsafe.Pointer(retPtr))

-- 
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] Pointer literal

[Dan Kortschak]

On Wed, 2016-09-07 at 08:42 -0700, 'Mihai B' via golang-nuts wrote:
> Any HTTP API with PATCH support needs to use pointers on basic types. 
> Therefore I'm wondering if there is any will/proposal to make pointer 
> initialisation easier to work with basic types. The `standard` way is
> quite 
> verbose so it seems that most APIs use functions for every possible
> type[1].

The approach I use in places like this is to add a small helper that
does the work. For your examples it would look like this:

func stringPtr(s string) *string { return &s }


r := T{Description: stringPtr("new description")}


-- 
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] JPEG to RGB issues

[Nigel Tao]

JPEG is not a pixel-exact format, even in YCbCr color space. Different
Discrete Cosine Transformation implementations may produce slightly
different YCbCr and hence RGB values, and still be considered valid
JPEG implementations.

For example, libjpeg is just one software implementation, in one
programming language, but it has multiple FDCT / IDCT implementations
(e.g. 4 different jidct???.c files). Some use floating point math.
Some use fixed point (integer) math, especially useful if your CPU
doesn't support floating point in hardware. Some implementations are
"fast", which are indeed as advertised, but have worse quality on some
measures. They're all valid, spec-compliant implementations, but they
have different rounding errors, and won't give identical RGB results
on all inputs.

Newer image formats like WebP have tightened up the variety in valid
decodings, but JPEG is what it is.

I'm therefore unsurprised that Go's decoding can differ slightly from
whatever OpenCV uses.

-- 
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: In case you missed it: language benchmarks for Go 1.7, and language adoption

[Clark Wierda]

On Wednesday, September 7, 2016 at 1:01:23 PM UTC-4, 
sascha.l@googlemail.com wrote:
>
>
> Am Mittwoch, 7. September 2016 18:20:28 UTC+2 schrieb Isaac Gouy:
>>
>>
>> On Wednesday, September 7, 2016 at 8:15:09 AM UTC-7, 
>> sascha.l@googlemail.com wrote:
>>
>>>
>>> If this does not count the Benchmark game follows a skewed defintion of 
>>> a library.
>>>
>>  
>>
>> I'm sorry that you don't seem to understand what is expected.
>>
>
> I do. But you still miss the point that 3rd party libs are just software
> written by someone. If I follow your logic if some else (not me)
> posts my solution (what is possible ... its free software) using my library
> it will be accepted. Lets do this.
>
> Taking this benchmark would only be possible if the 3rd party exists.
> So you would have forbidden Ken and Dennis to create a benchmark entry for 
> C
> in the early days?  Because there were no such libs.
> Theoretically speaking .. but I hope you get the point.
>   
>
>>
>>> Can you eleborate please, what a library is? 
>>>
>>
>>  Examples were given in the description:
>>
>> http://attractivechaos.github.io/klib/#About
>>
>> http://concurrencykit.org/index.html
>>
>
> But this are just two third party libraries, like mine. So where is the 
> difference?
> They may be larger, okay. But there is nothing in the rules which says 
> that they
> have to be complex and at least a few years old and so on and so on.
> If you want to enforce this the description text has to be adjusted.
> And no it's not about cheating, it's about software making.
>
> I think an important fact of the Go ecosystem is the usage of small 
> fitting libraries.
>
> BTW: The godoc of my library can be found here:
> https://godoc.org/bitbucket.org/s_l_teichmann/fastmap
>
>
Apparently, you can only use approved libraries that produce the ranking he 
wants.

-- 
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: In case you missed it: language benchmarks for Go 1.7, and language adoption

[Jason E. Aten]

Observe that the java benchmark continues to be allowed to use an
accelerated hash table library.

-- 
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] What was the rationale behind using braces for scoping?

[Anmol Sethi]

Additionally, I found Rob’s talk here https://youtu.be/VoS7DsT1rdM?t=1263 that 
also explains the decision.

> On Sep 7, 2016, at 8:13 PM, Anmol Sethi  wrote:
> 
> I’m not here to argue for using indentation for scoping. I just want to know 
> why go decided to go with braces (hehe).
> 
> No but seriously, I only found a section on the FAQ that says "Go uses brace 
> brackets for statement grouping, a syntax familiar to programmers who have 
> worked with any language in the C family.”
> 
> Is there any other reason aside from familiarity that go went with braces for?
> 
> -- 
> 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.

Re: [go-nuts] Go string to uintptr

[Gulácsi Tamás]

Thanks!

Nigel Tao  ezt írta (időpont: 2016. szept. 8., Cs
3:23):

> On Thu, Sep 8, 2016 at 1:03 AM, Tamás Gulácsi 
> wrote:
> > a:=([1<<20]byte(unsafe.Pointer(retPtr)))
>
> Also, the type needs to be pointer-to-array, not array.
>
> a:=(*[1<<20]byte)(unsafe.Pointer(retPtr))
>

-- 
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 to build mock class?

[Simon Ritchie]

When I said that you can only mock well-behaved classes, I should have said 
more.

When I say mock, I mean something that satisfies an interface and drives a 
test.  You can also use what I call a dummy to drive your test.  To me a dummy 
is a real structure, such as an http Request, which you create and fill in with 
just enough data for your test.  The main difference between a dummy and a mock 
is that when you call a method in a mock, you can very easily make it return 
any value that you want.  Since a dummy is an instance of a structure that you 
didn't write, it may not be so easy to persuade one of its methods to return a 
particular value.

Some people might call all of those things mocks.

-- 
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: Auto-complete with Go-mode in Emacs

[morozoandrei]

I know this is about 4 years late, however reading through the docs I found 
out that you need to run go install on the "main" package to get 
auto-complete to recognize all the packages that are part of the file you 
are working on. it can be found here https://github.com/nsf/gocode#misc

basically to build out the tree and force auto-complete to build its tree 
and dictionary I guess it needs this command, so whenever you create a new 
package and import it into main you will need to run go install for it to 
register

-- again this forum seems dead but hopefully someone in need will find this 
info useful. (this is for auto-complete and go-eldoc)

On Tuesday, October 30, 2012 at 4:30:00 PM UTC-4, Luke Mauldin wrote:
>
> Was a solution ever found to this problem?  I am working on this as well 
> and it works fine if I do {struct}. and then it gives me the members. 
>  However, if I have a function local to the package I have to type . in 
> order to get an auto-completion list.  Is there any way that I can change 
> this or maybe type "Ctrl-Tab", etc... to get the auto complete list?
>
> Luke
>
> On Friday, October 26, 2012 1:27:26 PM UTC-5, kitsi...@gmail.com wrote:
>>
>> me too. i don't know why need to start emacs from terminal window.
>>
>> thanks
>>
>> On Wednesday, September 19, 2012 12:55:44 PM UTC+8, Jon Hirschtick wrote:
>>>
>>> Works for me on my Mac (Gnu Emacs 24.2.1 built for Cocoa), but have to 
>>> start it from a Terminal window:
>>>
>>> $ open -a emacs
>>>
>>> My ~/.emacs looks a lot like the other examples posted.
>>>
>>> Good luck,
>>>
>>> - Jon
>>>
>>> On Thursday, September 6, 2012 12:08:52 AM UTC-5, Tahir Hashmi wrote:

 I've been trying to get auto-complete-mode to be activated by default 
 with go-mode in Emacs, but my efforts so far have been futile. More 
 details 
 on this question at stackoverflow: 
 http://stackoverflow.com/questions/12278990/auto-complete-with-go-mode

 I'm hoping someone on this list might be able to answer it better. This 
 issue is killing my productivity, not because I can't write code without 
 auto-completion but because I can't get over the fact that something so 
 simple should result in so much pain. ;-)

 TIA

 -- 
 Tahir Hashmi

>>>

-- 
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] Gomobile vendoring?

[Matthew Erickson]

Hello everyone,

We've been running into a vendoring issue regarding our toolset recently. 
Namely, breaking changes to gomobile will happen within one of our release 
cycles (such 
as 
https://github.com/golang/mobile/commit/2f75be449fbada35ca42f481f9878ba7f02a7e7d
 
), and cause our builds to break. Is there a means by which we can 
effectively vendor gomobile as a command, or ought we fork it and merge 
with upstream every so often? Changing our build scripts to point to a fork 
isn't a big deal, but I was wondering how others here have solved this 
problem.

-- Matt

-- 
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 1.7.1 is released

[h . yuhai]

Great! Thx!

On Thursday, September 8, 2016 at 5:20:31 AM UTC+8, Chris Broadfoot wrote:
>
> Hi gophers,
>
> We have just released Go version 1.7.1, a minor point release.
>
> This release includes fixes to the compiler, runtime, documentation, and 
> the
> compress/flate, hash/crc32, io, net, net/http, path/filepath, reflect, and 
> syscall packages.
> https://golang.org/doc/devel/release.html#go1.7.minor
>
> You can download binary and source distributions from the Go web site:
> https://golang.org/dl/
>
> To compile from source using a Git clone, update to the release with "git 
> checkout go1.7.1" and build as usual.
>
> Thanks to everyone who contributed to the release.
>
> Chris
>

-- 
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] Support of diffie-hellman-group-exchange-sha1

[FY]

 

Hello, 

Am I missing something ?

I am trying to use the exchange algorithm called 
"diffie-hellman-group-exchange-sha1" It looks like Go does not support it


>From this link 

 , 
it looks like it is only supporting 

const (
kexAlgoDH1SHA1  = "diffie-hellman-group1-sha1"
kexAlgoDH14SHA1 = "diffie-hellman-group14-sha1"
kexAlgoECDH256  = "ecdh-sha2-nistp256"
kexAlgoECDH384  = "ecdh-sha2-nistp384"
kexAlgoECDH521  = "ecdh-sha2-nistp521"
kexAlgoCurve25519SHA256 = "curve25519-sha...@libssh.org"
)


thanks

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