[go-nuts] Re: map[X]Y or map[X]*Y ?

[jmontgomery]

In addition to the god points that others have made, there is a difference 
in the way that memory will be allocated. See 
https://play.golang.org/p/l6d4lODiDx and pay attention to the "delta" 
lines. In this particular example, using a map to a pointer does a Malloc 
for every map item, whereas using a map to value does not. For 10,000 items:

pointer delta : Alloc: 401248, TotalAlloc: 401248, Mallocs: 10543
value   delta : Alloc: 369512, TotalAlloc: 369512, Mallocs: 623


Of course, other uses could behave differently.

On Friday, May 12, 2017 at 8:00:00 AM UTC-4, aktungmak wrote:
>
> Setting aside the receiver types of methods for the moment, if we consider 
> the following declaration:
>
> type Y struct {
> //some fields
> }
>
> Which of the following would be "better" (from a speed and storage usage 
> viewpoint)?
>
> map[X]Y
> map[X]*Y
>
> If we consider that this map could be handed between different functions. 
> Does it make any difference to use a pointer? Or does it make no 
> difference, since the map is already a reference type and functions are 
> receiving a copy of the pointer to the map and not a copy of the map value?
>
> 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.

[go-nuts] Re: go test: no tests to run

[jmontgomery]

Yes, your tests should have the the *same *package name as your code, so in 
this case *package pybr*. They will not effect the package when built 
normally. They are only included when running *go test*. You also need to 
name your tests correctly, and they need a signature like:


func TestXxx(*testing.T)

See the testing package documentation .

- Jake

On Friday, April 21, 2017 at 2:47:25 PM UTC-4, Tong Sun wrote:
>
> Hi, 
>
> Thanks you all that helped. 
>
> I choose the first option, and am now facing a new problem -- when I run 
>
> go test -v ./...
>
> I got "no tests to run" even though I have a _test file:
>
> https://github.com/go-cc/cc-table/blob/master/cc-pinyin-range/pinyin_test.go
>
> For other directories, I got "no test files", which is obvious, but what 
> does this "no tests to run" mean and how can I fix it? 
>
> Is it because I'm using multiple words for my project name, and I use a 
> different package name within it? 
> I've defined a type "Pinyin" in that package, so "func ExamplePinyin()" or 
> even "func ExamplePinyin_output()" is a good name for testing, right?
> How can I make my above _test file work?
>
> Thanks
>
>
> On Wednesday, April 19, 2017 at 12:18:53 PM UTC-4, Chris Manghane wrote:
>>
>> There's definitely no idiom here. Do what the octokittens do and probably 
>> use the first or second option, in that order. The third seems awkward, 
>> unless the underscore has some specific meaning (like how _unix is used to 
>> compile architecture-specific code). And I'm not really sure if the 
>> capitalization in the fourth actually matters.
>>
>> Looking at the Go repos themselves, there are examples of both: 
>> gofrontend and sublime-build. It seems like go-frontend and sublimebuild 
>> would also be reasonable names for these as well so do whatever you feel 
>> like I guess.
>>
>> Thanks,
>> Chris
>>
>> On Wed, Apr 19, 2017 at 8:05 AM, Tong Sun  wrote:
>>
>>> On Wed, Apr 19, 2017 at 9:59 AM, Jan Mercl <0xj...@gmail.com> wrote:
>>>
 On Wed, Apr 19, 2017 at 3:48 PM Tong Sun  wrote:

 > what's your preference and why? 

 example.com/name/onenamenopunctutaionalllowercasetwotoninecharacters 

>>>
>>>  Hmm... does it meant to be sarcasm or actually recommendation? 
>>> Honestly, I tried to figure out the words from that long name but gave up 
>>> after *several* attempts. 
>>>
>>>
>>> b/c ~ what POSIX recommends for utility names.

>>>  
>>> Any urls maybe? 
>>>
>>> I was trying to find that myself, and found one page, 
>>>
>>> Utility Conventions
>>> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
>>>
>>> Which says, 
>>>
>>> Within POSIX.1-2008..., The utility in the example is named 
 *utility_name*, 
>>>
>>>
>>> i.e., separated with an underscore. 
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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

[go-nuts] Re: golint if/else stmt and early returns

[jmontgomery]

While there may be better ways to express what this logic, for clarity, 
here is the change that golint is actually suggesting:
// Load returns the list of partition found and their properties.
func (l *LinuxLoader) Load() ([]*Properties, error) {
//-
ret := []*Properties{}

if temp, err := runDf(); err != nil {
return ret, err
}
ret = PropertiesList(ret).Append(PropertiesList(temp))
//-
if temp, err := runLsLabel(); err != nil {
return ret, err
} else {
ret = PropertiesList(ret).Append(PropertiesList(temp))
}
//-
if temp, err := runLsUsb(); err != nil {
return ret, err
} else {
ret = PropertiesList(ret).Merge(PropertiesList(temp), "IsRemovable")
}
//-
if temp, err := runMount(); err != nil {
return ret, err
} else {
ret = PropertiesList(ret).Merge(PropertiesList(temp), "Label")
}
//-
return ret, nil
}

The change is at line 9.



On Thursday, March 16, 2017 at 1:11:28 PM UTC-4, mhh...@gmail.com wrote:
>
> Hi,
>
> golint will report
>
> if block ends with a return statement, so drop this else and outdent its 
> block (move short variable declaration to its own line if necessary) 
> (golint)
>
> for this code,
>
>
> // Load returns the list of partition found and their properties.
> func (l *LinuxLoader) Load() ([]*Properties, error) {
> //-
> ret := []*Properties{}
>
> if temp, err := runDf(); err != nil {
> return ret, err
> } else {
> ret = PropertiesList(ret).Append(PropertiesList(temp))
> }
> //-
> if temp, err := runLsLabel(); err != nil {
> return ret, err
> } else {
> ret = PropertiesList(ret).Append(PropertiesList(temp))
> }
> //-
> if temp, err := runLsUsb(); err != nil {
> return ret, err
> } else {
> ret = PropertiesList(ret).Merge(PropertiesList(temp), 
> "IsRemovable")
> }
> //-
> if temp, err := runMount(); err != nil {
> return ret, err
> } else {
> ret = PropertiesList(ret).Merge(PropertiesList(temp), "Label")
> }
> //-
> return ret, nil
> }
>
> Does it mean i should nest those stmts and let it be 4 level deep ?
> Is it the reco ?
>
> Is there something wrong about early returns ?
>
> 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] Cross compiling from Windows to Linux produces non-working go routines

[jmontgomery]

On Wednesday, March 8, 2017 at 9:50:09 AM UTC-5, Chris Hines wrote:
>
> The infinite loops in each function will busy loop and consume a core 
> without allowing the runtime scheduler a chance to run other goroutines on 
> that core. If your virtual machine doesn't have enough cores then some 
> goroutines may starve.
>
> Change the loops to select {} to block infinitely without busy looping and 
> see if that behaves as expected.
>

I like to use "<-make(chan interface{}) " as a one line "block forever" 
statement.

-- 
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 this race condition normal?

[jmontgomery]

On Sunday, February 19, 2017 at 3:41:13 AM UTC-5, Marwan abdel moneim wrote:
>
> i wanted to do it without a Mutex
> but there still something not clear to me, but i don't know what it is
> and i don't understand what "trigger" synchronization means
>
> i will keep reading, and go back to it later and see it i get it
>
> thanks for your help
>
>
To correctly do any sort of write access to the same location from multiple 
goroutines *will *require synchronization. Without it, your code will never 
be correct. It may work some of the time, or even all of the time on some 
platform with some version of the compiler. But it will never be guaranteed 
to always work, unless you use synchronization. If you really don't want to 
use a sync.Mutex , then you should look 
at sync/atomic . But be forewarned, 
doing anything but the most trivial synchronization with atomics is hard o 
get right.

On a more general note, I think there is sometimes an over eagerness to 
attempt "lock free". If you are trying to solve a real problem, I suggest 
thinking about channel based solutions. If they are not appropriate, just 
use sync.Mutex, or one of the other synchronization types. Only try to 
optimize to "lock free" (atomics) if you find there is an actual problem 
with lock contention under real conditions.  

-- 
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 declarations and the underlying type's methods

[jmontgomery]

 should mention that what you want can be achieved with composition using 
anonymous fields:

https://play.golang.org/p/vEKS70A-29

I know its not your original question, and this only works with `strcut` 
and `interface`, not build in types, like `int`. But it does give you the 
kind of behavior you were looking for. 


On Friday, January 20, 2017 at 2:59:08 AM UTC-5, Viktor Kojouharov wrote:
>
> Hello,
>
> Considering how easy it is to create new types based on underlying types, 
> how come the newly created ones do not delegate method calls to their 
> underlying types? Consider the following example:
>
> https://play.golang.org/p/Zs7Ve8ECk2
>
> In the example, calling `b.num()`  directly will not working, one will 
> have to manually do something like `Foo(b).num()` in order to invoke the 
> desired method. Why aren't these methods delegated automatically, similarly 
> to how they are delegated when dealing with embedded structs?
>

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