Re: [go-nuts] Re: Go 1.8.1 is released

[ahochauwaaaaa]

Hello,

This issue might help you understand why:
https://github.com/golang/go/issues/12380

I hope one day Golang would be available without any restrictions :-(

Yoshiyuki

2017/05/08 0:36、abbasnagh...@gmail.com:

Why the Iranians have blocked?
Is free and open source language golang?
-- 
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] why received can be defined with/without pointer?

[Rader Lei]

if a method only defined for a pointer receiver, the compiler will add "*" 
before the caller silently.

Why pointer receiver? Try to change the value of a member. You will know 
the difference.

On Sunday, May 7, 2017 at 6:37:59 PM UTC+8, mhh...@gmail.com wrote:
>
> yes, sorry you scratched your head
>
> https://play.golang.org/p/Gg6Euyvsw6
>
> this example shows that it is possible to do all the things.
> hth.
>
> I m curious to know more about other questions.
> Maybe they are not good idea, or not technically achievable.
> Just curious.
>
>
> On Sunday, May 7, 2017 at 2:55:58 AM UTC+2, Ian Lance Taylor wrote:
>>
>> On Sat, May 6, 2017 at 3:39 AM,   wrote: 
>> > 
>> > Question about the receiver of a func. 
>> > 
>> > It can be defined as star/no star, and consumed as star/nostar. 
>> > 
>> > The understanding i have so far is, 
>> > it let the developer define the memory model he d like to use. 
>> > 
>> > It leads to cases such as 
>> > - define start/nostar on a type 
>> > - consume a stared type as a value 
>> > - consume a value type as a pointer 
>>
>> You are not permitted to define a method on a named type defines as a 
>> pointer type, so I don't understand your cases.  Can you describe them 
>> using actual Go code rather than words? 
>>
>> 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.

[go-nuts] Are Go test methods run serially?

[Dave Cheney]

The post over on stack overflow is confused. The behaviour of go test is to 
test multiple packages concurrently, inside a single package tests are executed 
serially by default. 

-- 
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] Are Go test methods run serially?

[Henry]

My understanding is that they are run serially. You need to call t.Parallel() 
in the beginning of each test to make it run in parallel with other tests.

-- 
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] adding context.Context to new code

[meirfischer]

I'm adding tracing to an existing code base with many packages and it seems 
the best way to have context's passed around is to just have every method 
take a context.Context. 

Is there any tooling for converting a code base/package to have:
(a) context.Context as the first parameter in each function - ctx 
context.Context
(b) for any function that has changed, have its callers (within that 
package) pass ctx as the first arg

The difficulty here seems to differentiate intra package calls from calls 
to standard/3rd party libraries which shouldn't be having new param.

-- 
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] Are Go test methods run serially?

[st ov]

Go test methods run in separate goroutines but those routines are run 
serially right?
So variable assignments shouldn't get stomped by other tests?

I saw a comment saying they're *concurrent*, but not *parallel* by default.
http://stackoverflow.com/questions/24375966/does-go-test-run-unit-tests-concurrently/24376644#24376644

How is it still considered concurrent if they're run serially?



-- 
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: Fully-qualified import paths and Pull Requests

[st ov]

Thanks for correcting my concerns!


On Thursday, May 4, 2017 at 8:52:02 PM UTC-7, Dave Cheney wrote:
>
>
>
> On Friday, 5 May 2017 13:37:26 UTC+10, st ov wrote:
>>
>> By "fork" I mean in the GItHub sense, the forking of original project 
>> *github.com/original/foo 
>> * through their console so that 
>> *github.com/me/foo 
>> * is created.
>>
>> And "clone" would be running "git clone 
>> https://github.com/original/foo.git; on my local machine so I have a 
>> local copy of the original project.
>>
>>
> Thank you for clarifying.
>  
>
>> Does it matter which I do first?
>>
>
> No, the order does not matter. You can fork the project on github, then 
> check out the upstream in its original location, then push to your fork, or 
> you could checkout the upstream, fork it, then push to your fork.
>
> Some rename the remote from origin to upstream, and add their fork as the 
> origin. Each to their own.
>  
>
>> Is there a chance someone could push a commit between those two events 
>> that would cause me some headache?
>>
>
> I guess, but this doesn't seem much different to forking any other github 
> repo.
>  
>
>>
>>
>>
>>
>>
>> On Wednesday, May 3, 2017 at 10:40:26 PM UTC-7, Dave Cheney wrote:
>>>
>>> This discussion could get confusing if we're not clear about our terms. 
>>> Could you please describe what the terms cloned and forked mean to you.
>>
>>

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

Re: [go-nuts] understanding utf-8 for a newbie

[Jan Mercl]

On Sun, May 7, 2017 at 8:39 PM peterGo  wrote:

> "[Rob Pike and Ken Thompson] they made sure it was backwards compatible
with ASCII."

> ASCII is 7-bits.

So is any UTF-8 encoded ASCII.

-- 

-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] understanding utf-8 for a newbie

[peterGo]

Sam,

"[Rob Pike and Ken Thompson] they made sure it was backwards compatible 
with ASCII."

ASCII is 7-bits.

Peter

On Sunday, May 7, 2017 at 11:29:53 AM UTC-4, Sam Whited wrote:
>
> On Sun, May 7, 2017 at 9:44 AM, rob solomon  > wrote: 
> > I now understand that the bytes may be different. 
>
> It's also worth noting that when Ken Thompson and Rob Pike (yes, the 
> same Rob Pike and Ken Thompson that created Go) created UTF-8, they 
> made sure it was backwards compatible with ASCII. Any characters that 
> are representable in ASCII will be the exact same bytes when encoded 
> to UTF-8. I'd be suprised if Windows didn't understand UTF-8 these 
> days, so it may be that you really don't need to "convert" your file 
> at all. 
>
> Here's a fun introduction to Unicode (with a brief discussion of 
> encoding methods), if you're interested: 
>
> http://reedbeta.com/blog/programmers-intro-to-unicode/ 
>
> —Sam 
>

-- 
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] understanding utf-8 for a newbie

[peterGo]

Sam,

"I'd be suprised if Windows didn't understand UTF-8 these days,"

Be surprised! For Unicode, Microsoft Windows uses UTF-16.

Peter

On Sunday, May 7, 2017 at 11:29:53 AM UTC-4, Sam Whited wrote:
>
> On Sun, May 7, 2017 at 9:44 AM, rob solomon  > wrote: 
> > I now understand that the bytes may be different. 
>
> It's also worth noting that when Ken Thompson and Rob Pike (yes, the 
> same Rob Pike and Ken Thompson that created Go) created UTF-8, they 
> made sure it was backwards compatible with ASCII. Any characters that 
> are representable in ASCII will be the exact same bytes when encoded 
> to UTF-8. I'd be suprised if Windows didn't understand UTF-8 these 
> days, so it may be that you really don't need to "convert" your file 
> at all. 
>
> Here's a fun introduction to Unicode (with a brief discussion of 
> encoding methods), if you're interested: 
>
> http://reedbeta.com/blog/programmers-intro-to-unicode/ 
>
> —Sam 
>

-- 
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.8.1 is released

[abbasnaghdix]

Why the Iranians have blocked?
Is free and open source language golang?

-- 
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] understanding utf-8 for a newbie

[Sam Whited]

On Sun, May 7, 2017 at 9:44 AM, rob solomon  wrote:
> I now understand that the bytes may be different.

It's also worth noting that when Ken Thompson and Rob Pike (yes, the
same Rob Pike and Ken Thompson that created Go) created UTF-8, they
made sure it was backwards compatible with ASCII. Any characters that
are representable in ASCII will be the exact same bytes when encoded
to UTF-8. I'd be suprised if Windows didn't understand UTF-8 these
days, so it may be that you really don't need to "convert" your file
at all.

Here's a fun introduction to Unicode (with a brief discussion of
encoding methods), if you're interested:

http://reedbeta.com/blog/programmers-intro-to-unicode/

—Sam

-- 
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] Unexpected need to use runtime.KeepAlive().

[Bruno Albuquerque]

I have this struct that has an associated method that simply call a C
function that might take a long time to use. It is defined more or less
like this:

import "C"

type Indexer struct {
  cIndexer *C.Indexer
}

func NewIndexer() *Indexer {
  i := {getCIndexerPointer()}
  runtime.SetFinalizer(i, (*Indexer).finalize)
}

func (i *Indexer) finalize() {
  freeCIndexertPointer(i.cIndexer)
}

func (i *Indexer) Commit() {
  callCCommit(i.cIndexer)
}

Then I have some code that uses an indexer object:

func Index() {
  i := NewIndexer()

  // Index documents calling Indexer methods.

  i.Commit()
}

For some corpus, the Commit() call above might take several minutes to
complete. It looks like that if the garbage collector kicks in when it is
running, the runtime thinks that it is ok to collect the object and this
triggers the finalizer that, in turn, deletes the internal C object that,
finally, make the C commit call to crash as the C struct it uses to do its
job was freed.

I am aware that a call to runtime.KeepAlive(i) after the Commit() call
should be enough to sort this up, but I am wondering why it is required at
all in this case. Isn't the fact that a method on a struct type is running
enough to avoid collection? If not, shouldn't it be? Or is this related to
the usage of CGO?

In any case, it was a bit unexpected to me (although I did guess that the
problem was this and adding debug to the finalizer helped confirming it). I
would go as far as to say this looks like a bug.

Thoughts?

-- 
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: understanding utf-8 for a newbie

[Tom Limoncelli]

I highly recommend "The Absolute Minimum Every Software Developer
Absolutely, Positively Must Know About Unicode and Character Sets (No
Excuses!)"
https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/

Plug: The Golang unicode decode/encode libraries are pretty confusing
if you aren't already an expert in Unicode.  I wrote
https://github.com/TomOnTime/utfutil to make certain things easier.

Tom

On Sat, May 6, 2017 at 8:47 PM, Sam Whited  wrote:
> On Sat, May 6, 2017 at 7:40 PM, peterGo  wrote:
>> Corrected, corrected link. I will get it right eventually!
>>
>> For UTF-8 to CP1252: https://play.golang.org/p/vzupJY78XB
>
> FWIW, if you do need CP1252 (you probably don't) it already exists in
> Go-land as one of the encodings specified in this package:
> https://godoc.org/golang.org/x/text/encoding/charmap
>
> —Sam
>
> --
> 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.



-- 
Email: t...@whatexit.orgWork: tlimonce...@stackoverflow.com
Blog:  http://EverythingSysadmin.com

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

[go-nuts] understanding utf-8 for a newbie

[rob solomon]

Thanks to those who answered.

I grew up in the EBCDIC vs ASCII era, and I've always expected that the 
bytes in the file were the same as those that represented a character.


I now understand that the bytes may be different.

Thanks guys.

-- rob solomon

--
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: Tags on Interface types

[Egon]

This doesn't sound like a real world problem, which means it's really 
difficult to comment on the problem.

Currently the marshaling would work, but not unmarshaling.

Also, you can achieve the similar effect with: 
https://play.golang.org/p/dmFCRT-D1h

On Sunday, 7 May 2017 02:56:35 UTC+3, Glen Newton wrote:
>
>
> I would like to propose allowing annotations (tags) on Interface types. 
> Only a subset of an Interfaces methods could be tagged. This subset is 
> defined as methods that have a single return type and take no parameters 
> (as a best practice, these methods should not change any state and be 
> thread safe...). 
>
> So let's use the 'Go by example Interface', found here:
> https://gobyexample.com/interfaces
> and
> https://play.golang.org/p/313UebA3rD
>
> I have an altered version of this, where I have capitalized the methods of 
> interest and added tags: https://play.golang.org/p/50oEQHeWVZ
>
> // _Interfaces_ are named collections of method
> // signatures.
>
> package main
>
> import "fmt"
> import "math"
>
> // Here's a basic interface for geometric shapes.
> type geometry interface {
> Area() float64 `json:"area"`
> Perim() float64 `json:"perimeter"`
> }
>
> // For our example we'll implement this interface on
> // `rect` and `circle` types.
> type rect struct {
> width, height float64
> }
> type circle struct {
> radius float64
> }
>
> // To implement an interface in Go, we just need to
> // implement all the methods in the interface. Here we
> // implement `geometry` on `rect`s.
> func (r rect) Area() float64 {
> return r.width * r.height
> }
> func (r rect) Perim() float64 {
> return 2*r.width + 2*r.height
> }
>
> // The implementation for `circle`s.
> func (c circle) Area() float64 {
> return math.Pi * c.radius * c.radius
> }
> func (c circle) Perim() float64 {
> return 2 * math.Pi * c.radius
> }
>
> // If a variable has an interface type, then we can call
> // methods that are in the named interface. Here's a
> // generic `measure` function taking advantage of this
> // to work on any `geometry`.
> func measure(g geometry) {
> fmt.Println(g)
> fmt.Println(g.Area())
> fmt.Println(g.Perim())
> }
>
> func main() {
> r := rect{width: 3, height: 4}
> c := circle{radius: 5}
>
> // The `circle` and `rect` struct types both
> // implement the `geometry` interface so we can use
> // instances of
> // these structs as arguments to `measure`.
> measure(r)
> measure(c)
> }
>
> What happens? When a tag processor is engaged on an interface containing 
> tags, instead of using value of the fields of a struct that are tagged, it 
> takes the value returned by the invocation of the methods that are tagged 
> (it invokes the method and uses the (single) value returned). 
>
> So what does this give us? It means I can have a list of type geometry 
> (interface) that contains both circle and square structs under the hood, 
> and I can walk through the list and (for example) serialize them, using the 
> serialization defined in the interface
>
> It gives a bit of generic feel to things, at least from a tags 
> perspective. [Sorry, I said the 'G' word]
>
> I guess reflect.Method  would 
> need a Tag StructTag  like 
> that in reflect.StructField. 
>
> I think this would be backward compatible, and just a handful of things 
> would need to be updated in reflect (from my limited knowledge) as well as 
> some minor changes to the compiler (??) and likely other things I don't 
> know about, like various tool chain stuff, etc, ??.
>
> Thanks,
> Glen
>

-- 
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 received can be defined with/without pointer?

[mhhcbon]

yes, sorry you scratched your head

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

this example shows that it is possible to do all the things.
hth.

I m curious to know more about other questions.
Maybe they are not good idea, or not technically achievable.
Just curious.


On Sunday, May 7, 2017 at 2:55:58 AM UTC+2, Ian Lance Taylor wrote:
>
> On Sat, May 6, 2017 at 3:39 AM,   wrote: 
> > 
> > Question about the receiver of a func. 
> > 
> > It can be defined as star/no star, and consumed as star/nostar. 
> > 
> > The understanding i have so far is, 
> > it let the developer define the memory model he d like to use. 
> > 
> > It leads to cases such as 
> > - define start/nostar on a type 
> > - consume a stared type as a value 
> > - consume a value type as a pointer 
>
> You are not permitted to define a method on a named type defines as a 
> pointer type, so I don't understand your cases.  Can you describe them 
> using actual Go code rather than words? 
>
> 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] Proper Way of Defining a Custom Context

[Peter Mogensen]

On 2017-05-07 11:58, dc0d wrote:

What's the proper way of defining a custom context?
Is it enough to wrap the methods of parent `context.Context`?


I did some experiments trying to extend the context.Context interface.
One quickly runs into endless troubles due to the reliance on global 
functions an the internal types of the context package.


/Peter

--
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] Proper Way of Defining a Custom Context

[dc0d]

What's the proper way of defining a custom context? 
Is it enough to wrap the methods of parent `context.Context`? Is it fine to 
add fields and methods (we can type-assert later on, down the chain)? 
Or one should just use the `WithValue` and stores everything inside the 
context and handle them using `Value(...)` method?

-- 
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] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[Sokolov Yura]

Where will you store reference counter for interior pointer?

type st struct { j int }
type at { i int; s st }
var a at
var s st
dealWithSt()
dealWithSt()

So, you have two choices:
- either you have to find base address for pointer on every rc 
increment/decrement - and it is quite expensive operation (with current GC it 
is done very rare),
- or you forbid interior pointers (and store a.s in separate location) - and 
then it is not Go language.

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