Re: [go-nuts] Re: why not support explicit delete in golang?

[Jesse McNelis]

On Fri, May 28, 2021 at 4:51 PM cheng dong  wrote:

> Thank you for the clarification.
> sorry to break the general rule, i'm new to golang-nuts
>
> as to the question, i figured out i used wrong words, what i need in fact
> is1. a hint to tell compiler that some object are safe to alloc on stack(in
> case that we use it as interface so it escape from stack) 2. some concept
> like unique ptr that when it end it's life time, the object referenced can
> be deallocated immediately.
>

For Go to be memory safe the compiler can't trust your hint because you
could be wrong either by a mistake or by changes to future code
invalidating some assumption you had.
A feature like Rust's unique pointers (and thus also borrowing and
lifetimes) would require large changes to the language and completely
change what Go is.

If you want the features of Rust then use Rust.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAAuPoqf4%3D550o0u%2BatpbWrudzdx-%2B2s5fxL3%2BSecQS%2BTmQucQw%40mail.gmail.com.

Re: [go-nuts] Re: why not support explicit delete in golang?

[Jesse McNelis]

On Fri, May 28, 2021 at 12:56 PM cheng dong  wrote:

> to avoid false delete object, we could add some checking code in
> markDelete just like what we do with raceenable.
> one complicate case is internal pointer, we could recursively mark delete
> or mark delete internal pointer by hand ?
>

This idea has come up many times over the past 10 yrs. The problem comes
down to:
1. If we know that the markDelete is doing the delete in a memory safe way,
then we also know the life time of the object and can do the job of
markDelete automatically.
2. If we don't know that the markDelete is doing the delete in a memory
safe way then we lose memory safety.

Regards,
Jesse

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

Re: [go-nuts] prevent unnecessary escape to heap

[Jesse McNelis]

On Fri, Feb 5, 2021 at 12:32 PM Steve Roth  wrote:

>
> How can I implement a writeByte function, against an unknown io.Writer
> implementation, that doesn't allocate heap memory?
>
>
As you've correctly stated, because the call to .Write() is via an
interface the compiler can't tell whether any particular io.Writer will
hold on to that slice.
So there isn't a way to do what you want.

But also, writing individual bytes to an io.Writer is likely to be a very
slow thing to do so avoiding the allocation is the least of your worries.

bufio.Writer has a WriteByte() method precisely to avoid the allocation
problem you're encountering and it also avoids the slowness of writing
individual bytes to an io.Writer
https://golang.org/pkg/bufio/#Writer.WriteByte

- Jesse

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAAuPoqeT%2B31oXf%2BZRZEAsQc0NQX_XUUAQ6G6kZc4HZjkOM4OXA%40mail.gmail.com.

Re: [go-nuts] rin: return if nil syntactic sugar

[Jesse McNelis]

On Mon, Aug 31, 2020 at 3:31 PM Zakaria  wrote:

> If the objections on the too magical handle part, why not cut that part
> and retain the check part?
>
> Most of the time the we just forward the error on to the next level
> anyway. Handling error is rarely done and should be explicit.
>

It's important to note that Go has been around for >10 yrs and for the
whole of that time people have proposed this same concept just with varying
syntax.
The concept has been debated on this list for more than a decade. The core
developers are well aware of this possibility and its implications.

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

Re: [go-nuts] political fundraising on golang.org!

[Jesse McNelis]

On Mon, Jun 15, 2020 at 8:12 AM andrey mirtchovski 
wrote:

> Hi,
>
> I have a non-profit I'd like to support. Who do I ask to put a banner
> on golang.org for me?
>
> (reductio ad absurdum)
>

This sounds like a great idea to me. It would probably need to be a
non-profit that furthers the Go language by expanding the reach and appeal
of the community to underrepresented groups.
Perhaps someone could put together a policy on what kind of non-profits
that would involve and this could be an ongoing thing.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAAuPoqf1ubypBcmufX-TtvuubPnZ1xeHagg98m9%2BneTv0E0B%2BA%40mail.gmail.com.

Re: [go-nuts] Nondeterministic Behavior of for Loop Ranging Over a map

[Jesse McNelis]

On Tue, May 26, 2020 at 3:37 PM Paul Jolly  wrote:

> > Why the output of this code is nondeterministic?
>
> See https://golang.org/ref/spec#For_statements, specifically the "For
> statements with range clause" subheading, specifically this bullet:
>
> > 3. The iteration order over maps is not specified and is not guaranteed
> to be the same from one iteration to the next. If a map entry that has not
> yet been reached is removed during iteration, the corresponding iteration
> value will not be produced. If a map entry is created during iteration,
> that entry may be produced during the iteration or may be skipped. The
> choice may vary for each entry created and from one iteration to the next.
> If the map is nil, the number of iterations is 0.
>

The implementation actually intentionally makes the iteration order more
varied to avoid people relying on any particular ordering. So much so that
some people started relying on the order to be random

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAAuPoqcSrjTeX094JOQhnP-qeRiJOPnQS-3-EgqMd6ciGVz%3DkA%40mail.gmail.com.

Re: [go-nuts] Type of function parameter changes

[Jesse McNelis]

Hi,

You can simply do:

func P(args ...interface{}) {
   print("\n", args...)
}

The problem you encountered was that you were passing the args as a single
argument to print()

The 'var args' syntax collects the arguments and puts them in a slice. So
args in P() is a []interface{}.
You then pass that whole []interface{} as an argument to print(), for args
in print() gets a []interface{} where the first item in the slice is an
interface{} that contains a []interface{}, which isn't what you wanted.

By using the spread operator when passing the args slice to print(), you
get the pass the args slices multiple arguments to print().


On Sun, May 17, 2020 at 12:06 PM Amarjeet Anand <
amarjeetanandsi...@gmail.com> wrote:

> Hi
>
> Why does the type of a parameter passed to another function changes?
> For example:
>
> func P(args ...interface{}) {
>print("\n", args)
> }
>
> func print(seperator string, args ...interface{}) {
>for _, arg := range args {
>   fmt.Println("arg type: ", reflect.TypeOf(arg))
>
>   str := ""
>   switch v := arg.(type) {
>   case byte:
>  str = string(v)
>   case rune:
>  str = string(v)
>   case int:
>  str = strconv.Itoa(v)
>   case int64:
>  str = strconv.FormatInt(v, 10)
>   case string:
>  str = v
>   }
>   out.WriteString(str + seperator)
>}
> }
>
>
> Calling *P("one"[2]) *gives type as  *[]interface {}*
> where as directly calling *print("one"[2]) *gives type as *byte*
>
> *Why is it like this? *
> *And any way i can achieve this without putting switch in P() function?*
>
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CANFuhy-7NbdMw6UynmUS9HnakVpUaJ_SCP8vkr11Z27LcLnrPA%40mail.gmail.com
> 
> .
>


-- 
=
http://jessta.id.au

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAAuPoqfxNTkFfaSzXqE7h8TU7tWFMbN57joPx%3D%3DA%2Bo7%2ByA5Wkw%40mail.gmail.com.

Re: [go-nuts] Question re fcns that return multiple values

[Jesse McNelis]

On Tue, Aug 6, 2019 at 1:38 PM  wrote:

> For f1 defined as func f1(k1, k2, k3 int) (x1, x2 int) {..}
> and f2 defined as func f2(x,y int)   (xR int)   {..}
>
> Why does the compiler complain about the call stmt
> f2 ( f1 (1,2,3)  )   ??
>

I'm not sure what you're asking.
The compiler doesn't complain about this.
eg https://play.golang.org/p/0OKIsPLTipz

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

Re: [go-nuts] does struct pointer *a == *b make sense?

[Jesse McNelis]

On Fri, Nov 23, 2018 at 2:06 PM Youqi yu  wrote:
>
> type T {
>  Name string
> }
> a := {Name:"test"}
> b :={Name:"test"}
> *a == *b
> Hi, all, I am beginner at golang, I have a question that when compare struct 
> equality, I was told to use reflect.DeepEqual or make my own function. but 
> the result of above code is true. Does it mean struct a equals struct b?

Yes, they are equal. But how the equality is decided may not always be
what you want.
eg.

type T {
   Name string
   Child *T
}
a := {Name:"test", Child: {Name: "blah", Child: nil}}
b :={Name:"test", Child: {Name: "blah", Child: nil}}
*a == *b // false
reflect.DeepEqual(a,b) //true

-- 
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] cannot take the address of method()

[Jesse McNelis]

On Mon, Sep 24, 2018 at 5:33 AM, Tamás Király  wrote:
> Hi,
>
> can anyone explain why the following does not work?
> i want to have the return value's address not the method itself.
>
> package main
>
> func main() {
> //first
> addressofstring := ()
> }
>
> func method() string {
> return "value"
> }
>
> https://play.golang.org/p/UbJ7SK0m9w6

You can't take the address of a function call. The Go specification
has further explanation of what you can take the address of.
https://golang.org/ref/spec#Address_operators

The reason you can't take the address of a function call is that it's
ambiguous as to what memory location you're getting the address of. By
not having this as a feature there doesn't need to be a rule to
disambiguate that.

-- 
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] Having difficulty converting []byte to float

[Jesse McNelis]

On Fri, May 18, 2018 at 12:26 PM,   wrote:
> Hello all.  I am creating a custom exporter for FreeNAS
> https://github.com/Maelos/freenas_exporter and am stuck on the conversion of
> the string of bytes provided by the commands output to a float.  Here is my
> code, what I have tried, and my results:
>
> What I have tried and results (commented so you can try and see each
> https://play.golang.org/p/sevfk7Nt2w4

> Attempt 1 = binary.LittleEndian.Uint64([]bytes) to math.Float64frombits

You've got a 2 byte slice, but you need 8 bytes. You're getting an
'index out of range' because you need a slice of 8 bytes.


> Attempt 3 = Bytes to bytes.Reader to binary.Read(slice of bytes,
> binary.LittleEndian, floatVariableToFill) to error check

You've got 2 bytes in your bytes.Reader and you're trying to read 8
bytes from it, this is why you get an error.
A float64 is 8 bytes so you need at least 8 bytes in your bytes.Reader.

> Attempt 2 = bytes to string, String to float (strconv)

You are parsing the string "2\n" which isn't a string representation
of a float. So that's not going to work.
The fact that these bytes are ascii characters means that your other
attempts don't make a lot of sense. The ascii value for the character
'2' is 50 so even if your other attempts worked you'd get a float with
50 instead of the 2 you're expecting.

If you do f, err :=
strconv.ParseFloat(strings.TrimSpace(string(text)), 64) you'll trim
off the invalid '\n' and you'll just have a '2' that will parse
correctly.

-- 
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] multiple-value f1() in single-value context

[Jesse McNelis]

On Wed, Feb 28, 2018 at 12:23 PM, Alex Dvoretskiy
 wrote:
> Hello Golang-nuts
>
> Why it is not allowed to pass function result like this to return?:
>
> https://play.golang.org/p/YPeaeW_4WZ6
>
>
> Or it is allowed without declaring temporary variables i3, i4?

You need to assign the results of the call to f1() to variables that
you include in the return.
Using a function that returns multiple values in a context where a
single value is expected can cause a lot of confusion and is thus not
allowed.

-- 
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: Cannot take the adress of.....

[Jesse McNelis]

On Tue, Feb 27, 2018 at 4:01 PM,   wrote:
> var j int = 42
> var p *int
> p=(j) //this doesn't work
> fmt.Println(*p)
>

Yep, this is true.
You can't take the address of the return value of a function or a
conversion (which is conceptually just a function) because it doesn't
have a location in memory and thus doesn't have an address.
If you would like to take the address of a variable containing the
value returned from a function you'll need to assign that value to a
variable and take the address of that variable.

The relevant part of the language spec is
https://golang.org/ref/spec#Address_operators

- Jesse

-- 
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 a bug or am I missing something?

[Jesse McNelis]

On Tue, Dec 19, 2017 at 4:10 PM, Sasan Rose  wrote:
> Hi Jess
>
> Apologies for my bad example. Please kindly see my reply to Dave's post.
> Thanks

I fixed your example so that the slice called 'combination' isn't
shared with every slice in every iteration of the loop.
https://play.golang.org/p/s0WvBuZr_P

-- 
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 a bug or am I missing something?

[Jesse McNelis]

On Tue, Dec 19, 2017 at 8:54 AM, Sasan Rose  wrote:
> Please take a look at https://play.golang.org/p/BL4LUGk-lH

solutionNew = make([]int, 0)
solutionNew = append(solution, 2)

Is a strange thing to do, you create a new slice using make([]int, 0)
and then never use it.
perhaps you wanted to use copy()?


The problem you're encountering is slices can share backing arrays.
Each time you append to the slice called 'solution', you're modifying
the same backing array.

In your code:

/*You append 2 to solution creating a slice that points to the same
memory as 'solution'*/
 solutionNew = append(solution, 2)

/* You append this slice to a slice called slice */
 slice = append(slice, solutionNew)

/* You append a 4 to the same slice called 'solution' which shares
memory with slice you appended to your slice called 'slice' thus you
override the 2 you append to 'solution' with a 4*/
 solutionNew = append(solution, 4)

/* You append the slice to 'slice' so now there are two slices in
'slice' that refer to the same memory and thus have the same value */
 slice = append(slice, solutionNew)


- Jesse

-- 
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] Variadic assignable values and covariance

[Jesse McNelis]

On Fri, Dec 15, 2017 at 11:08 AM, Ivan Kurnosov  wrote:
> Jesse,
>
> what you quoted is an optimisation for the "Otherwise, the value passed is a
> new slice of type []T with a new underlying array whose successive elements
> ".
>
> Your quote says: if the final argument is assignable - it may be passed as
> is, without any copy involving.

I quoted the section that explains what the ... syntax does.
It's the only section in the spec that refers to that syntax.

The 'final argument' referred to here is the varadic argument of the function.

You can pass a slice as the value for a varadic argument by passing
the slice followed by ...

-- 
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] Inconsistency in gofmt

[Jesse McNelis]

On Wed, Dec 13, 2017 at 11:01 AM, Pablo Rozas Larraondo
 wrote:
> Hello,
>
> I'm curious to know if this is intended:
>
> https://play.golang.org/p/t353t8ZvL1

This is intentional. gofmt uses spacing to group expressions based on
precedence of operators.
eg.

(i+2)/2 + 1 //In this line it's clear that 2 is added to i, that value
is divided by 2 and then added to 1.
(i + 2) / 2 + 1 // The formating here make the order of precedence less clear


> Line 9 is formatted with spaces but line 10 has no spaces. It seems like
> adding +1 to the expression changes the behaviour of "gofmt". Wouldn't it be
> simpler for "gofmt" to always add spaces between the operators? Maybe
> someone knows the reason for this.

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

Re: [go-nuts] Any way to run functions in independent threads/processes in go?

[Jesse McNelis]

On Sun, Dec 10, 2017 at 6:38 PM, shockme  wrote:
> Hi,
>
> I'd like to know if there is any way to run go functions in independent
> threads/process, just like multiprocessing.Pool.apply.
>

Go has goroutines to allow for running code on different threads.
Running a Go function in a different process isn't possible, but it's
also not as useful as running a goroutine.

What is your use case that you need processes?

-- 
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] interface{} as type []interface{}

[Jesse McNelis]

On Fri, Nov 10, 2017 at 10:27 AM, Trig  wrote:
> Is it possible to have an interface{} as type []interface{}?

Yep, you can store a slice of interface{} in an interface{}
eg.

// interface{} holding an []interface{} holding ints
var a interface{} = []interface{}{1,2,3,4,5}

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

-- 
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] function variable scope

[Jesse McNelis]

On Sun, Nov 5, 2017 at 3:47 AM,   wrote:
> Hi,
>
> Newbie here.  I am trying to understand the scope of variables in go - I ran
> across an interesting situation and want to learn what is going on.  Why do
> these two functions yield different results:
> https://play.golang.org/p/SyyWOY3fXz
>
> My understanding was that declaring myint either way in the function was the
> same as far as scope is concerned - but obviously they are different
> somehow.  Do variables declared in the functions return section have a
> larger scope or live longer?  Or is something else going on here?  Just
> trying to understand what's going on.

In your first example you've got a variable called 'myint' that you're
returning the value of, and then incrementing that variable in your
defer.
During return the value is being copied out of that variable and in to
an unnamed variable that holds the return value of the function.

In your second example you're naming the return variable, assigning a
value to that return variable, copying the value of the variable back
in to itself when returning and then incrementing that variable in
your deferred function.

Named return variables are often useful for this because they can be
modified in defered functions that run after the return.

https://golang.org/ref/spec#Return_statements


- Jesse

-- 
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 code thread safety?

[Jesse McNelis]

On Thu, Nov 2, 2017 at 4:54 PM, sheepbao  wrote:
>
> the close function is thread safety? how about call `closed` at the same
> time.

It's not safe. Multiple goroutines can enter the 'default'  case in
that select and close() the channel multiple times.

"Sending to or closing a closed channel causes a run-time panic."
https://golang.org/ref/spec#Close

-- 
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: How to know if interface{} data is nil w/o reflecting?

[Jesse McNelis]

On Wed, Nov 1, 2017 at 3:42 AM,   wrote:
> Today you can't, Ayan.
>

It's very consistent, you can't compare an interface value reliably to
any untyped constant.
Because there is no way for the compiler to figure out what type it should take.

https://play.golang.org/p/4Fn0YNE2md

-- 
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] How to know if interface{} data is nil w/o reflecting?

[Jesse McNelis]

On Tue, Oct 31, 2017 at 2:25 AM,   wrote:
> I found this a little bit non sequitur - if I want to call interface
> function I have a perfect business to check if underlying object is not nil
> before call just to avoid panic on call. Besides underlying nil in interface
> may be used to signal condition for variety of types implementing this
> interface, and since there is no inheritance in Go - sometimes it's the only
> proper way to indicate such condition.

In Go you can call a method on nil without a panic, this means that
unless you know the type you don't know if a nil value of that type is
a valid value to call a method on or not. You would be making a big
assumption about the type contained within the interface{} if you
checked that value for nil.

Of course since you don't know the type of the value inside the
interface{} it might not even be a value comparable to nil, in which
case should the comparison return false or panic?

-- 
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] const struct

[Jesse McNelis]

On Fri, Sep 8, 2017 at 2:52 PM, DrGo  wrote:
> Sorry if this was asked before, but I could not find any relevant posts.
>
> Any reason why this struct literal (made up of fields that can be declared
> const) is not allowed?

https://golang.org/ref/spec#Constants describes what types of values
can be constants.

The reason structs can't be constants is to avoid confusion over
whether or not they're mutable.

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

Re: [go-nuts] A question about evaluation of channel’s send statement

[Jesse McNelis]

On Wed, Sep 6, 2017 at 2:26 AM, T L  wrote:
>
> I mean it can be viewed as a bug for inconsistency.
> But from the memory model view, it can also not be viewed as a bug.
>

It's not a bug. The code is clearly expecting some ordering between
internal operations within two goroutines, this is an incorrect
expectation because Go doesn't provide that kind of ordering.

In the line:
c <- *p

p can be deferenced at any time before the send and the send only has
to happen before the receive.

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

Re: [go-nuts] A question about evaluation of channel’s send statement

[Jesse McNelis]

On Tue, Sep 5, 2017 at 10:34 AM, Marlon Che  wrote:
> Hi everyone!
> Please help me figure out the two different results of following code:
>
> package main
>
> import (
> "fmt"
> "time"
> )
>
> func main() {
> var num = 10
> var p = 
>
> c := make(chan int)
>
> go func() {
> c <- *p // with this line we will get 11 from channel c
> //c <- num // with this line we will get 10 from channel c
> }()
>
> time.Sleep(2 * time.Second)
> num++
> fmt.Println(<-c)
>
> fmt.Println(p)
> }

You have a data race, what value you get from dereferencing p is
undefined, it could be 10, it could be 11, it could wipe your
harddrive or launch the missiles.

-- 
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] Struct overloading method issue

[Jesse McNelis]

On Sat, Sep 2, 2017 at 12:50 AM, BeaT Adrian  wrote:
> Hello, I ran into a strange scenario and I wanted to know if there is a
> better solution for it
>
> type A struct{}
>
> func (a *A) private() {}
> func (a *A) Public() {
>a.private()
> }
>
> type B struct {A}
>
> func (b *B) private() {}
>
> bi := B{}
> b.Public() //calls the A.Private
>

Go doesn't do inheritance only composition with method forwarding.
Trying to do it will make you sad.

The general solution to sharing code between two types is to write a
function that takes a common interface that both A and B implement.

eg.

type Privater interface {
  private()
}

func Public(p Privator){
p.private()
}

-- 
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] Regexp documentation error?

[Jesse McNelis]

On Fri, Aug 11, 2017 at 9:03 PM, Jens Hausherr  wrote:
> I see,
>
> I was just confused by the fact that fmt.Printf("%q/%v") apparently renders
> a nil array as an empty array ([]) while rendering other nil values (e.g.
> pointers) as .

Yep, a nil slice is also an empty slice. You can check it's length
(which will be zero), check it's capacity(which will be zero), range
over all the items it contains (which will be zero) and append items
to it.

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

Re: [go-nuts] Isn't it better just to panic when you send/recv on a nil channel instead of forever blocking?

[Jesse McNelis]

On Fri, May 5, 2017 at 1:35 PM, Ronald  wrote:
>
> So the question:
>
> Isn't it better just to throw a panic when user send/recv on a nil
> channel instead of forever blocking it? If not, what is the benefits?

There is value in the ability to have a select case be a nil channel.
In a select a nil channel is never ready to receive and thus isn't a
case that will proceed.
This is useful for allowing you to conditionally prevent certain cases
from proceeding by swapping out the channel for a nil.

While outside a select this behaviour isn't really useful, but for
consistency it works exactly the same.

-- 
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] Zero value of the map

[Jesse McNelis]

On Tue, Apr 18, 2017 at 10:04 PM, Tad Vizbaras  wrote:
> I am just curious what is the reason behind not making zero maps more
> useful? Is it space?

The problem is that maps are mutable.

var a map[int]int
a[1] = 1  // could be fine and useful.

var a map[int]int
someFunc(a)  // Does someFunc need to return the map or not?

If someFunc() allocates the map(because it got nil) by adding
something to it then it needs to return the map it allocated to it's
caller.
But if it didn't need to allocate because it got a valid map it
doesn't need to return the map.

The possibility that a function might be passed a nil map would then
mean that all functions that work with maps would need to always
return the map.











-- 
=
http://jessta.id.au

-- 
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: one GC implementation question

[Jesse McNelis]

On Wed, Mar 22, 2017 at 8:51 PM, T L  wrote:
>
>  More accurately, I think it should be: from the POV of a programmer, it's
> globals, and things reachable from each goroutine.
>

The only way to reach a value is through a variable in scope and the
only variables in scope are global or on the stack.

'heap pointers of local allocated memory blocks' are stored where ever
you put them, but you can only put them in places you can find by
using global or local stack variables.

-- 
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] Map value assignment inside if loop

[Jesse McNelis]

On Sat, Mar 11, 2017 at 10:14 PM, priyank pulumati
 wrote:
> Hello,
> Go newbie here
>
> func (data map[string] interface {}) {
>  if len(data) == 0 {
>  data := make(map[string]interface{})
>  data["user"], _ = store.GetUser(context.Get(req, "userid").(string))
>  } else {
>  data["user"], _ = store.GetUser(context.Get(req, "userid").(string))
>  }
>  log.Println(data["user"])
> }


Go has 'block scoping' where variables can be declared to be valid
within a block (usually between two curly braces {} )

Variables in inner blocks can have the same names as variables in
outer blocks but still be different variables. This is called
'shadowing'.

In your above code you have a variable called 'data' declared at the
scope of the function. You then declare a new variable also called
'data' within the true block of the if. These are different variables
even through they have the same name.

When you log.Println(data["user"]) at the end you're referring to the
variable 'data'  declared in the function scope and not the variable
called 'data' that you declared in the scope of the if block.

You probably want to use '=' instead of ':=' so you're assigning a
value to the existing variable and not declaring a new one.

Note that assigning a value to the function scoped variable 'data'
won't modify the value you passed in.  So if you're creating a new map
value you'll need to return it to the caller.

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

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

[Jesse McNelis]

On Fri, Mar 3, 2017 at 6:49 PM, T L  wrote:
> After all, the len and cap fields of any value of string and slice values
> are immutable.
>

This is slices and strings are currently.

A string  value contains a length and a pointer to some bytes.
A slice contains a length, capacity and a pointer to an array of it's type.


https://research.swtch.com/godata

-- 
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: Serve large files

[Jesse McNelis]

Try using os.Open to get a *File (which implements io.Reader), and then
> io.Copy to the response from the file.
>

You should use https://golang.org/pkg/net/http/#ServeFile that's what it
does. It will also handle requests with range headers for allowing the
client to fetch just a part of the file.

-- 
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] Beginner Question : Reassignment of counter variable inside for loop in https://github.com/golang/mobile/tree/master/example/flappy

[Jesse McNelis]

On Thu, Feb 23, 2017 at 8:59 AM, Victor Kovacs  wrote:
>
> // The ground.
>> for i := range g.groundY {
>> i := i
>> // The top of the ground.
>> newNode(func(eng sprite.Engine, n *sprite.Node, t clock.Time) {
>>
>
>  While this solves the issue I would like to understand what is happening.
> Any insight is appreciated.
>
>
This is a variant of https://golang.org/doc/faq#closures_and_goroutines

Your function literal captures a reference to the variables 'i' and 'j',
These variables are modified by the loop on the next iteration.

The reason for using i := i is to copy the value from the loop variable 'i'
in to a new variable also called 'i', which won't be modified by the next
iteration of the loop.

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

[Jesse McNelis]

On Sun, Feb 19, 2017 at 3:59 PM, Marwan abdel moneim  wrote:
> i'm reading a book about concurrency, and was doing some baby steps
> so i'm trying to manage a variable changes to be locked when a process
> starts and freed when it ends
>
> this is the initial code https://play.golang.org/p/qGraa8yQEc
> and this is my solution https://play.golang.org/p/wC9tcbpVjf
>
> my question is, when i run the last code through the race detector i get
> this
>
> while it actually works as it should be ( the first invoked goruotines lock
> the variable and even if it takes time, the other goroutines can't access
> the variable)
>
> so is there any problem here?
>

The problem is that assignment to a bool doesn't trigger
synchronisation between processors.
Each processor will continue to only see their own version of the
value of the variable 'locked', until such time as synchronisation
occurs.

A sync.Mutex will trigger synchronisation when locked and unlocked.

-- 
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 can't interface parameters auto-convert types that implement that interface?

[Jesse McNelis]

On Wed, Feb 8, 2017 at 5:41 PM,   wrote:
> satisfies the interface, but requires a type assertion. However,
>
> func (e E) Less(e2 Element) bool {
> return e.value < e2.value
> }
>

If this version of Less() satisfied the interface Node what happens
when I pass something that isn't an Element but also satisfies the
Node interface?
It gets very complicated to explain what the rules would be in the
various possible edge cases.

-- 
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] File transfer,but file size is zero

[Jesse McNelis]

On Tue, Feb 7, 2017 at 9:01 PM, Robert Hsiung  wrote:
> Hi all:
> I tried to upload file via SFTP,but the file size is zero when it is
> done.Any suggestions? Thanks so much.
> // Copy the file
>
> dstFile.WriteTo(srcFile)
>
> }
>

You're writing the empty destination file to the srcFile.
You probably want:

n, err = dstFile.ReadFrom(srcFile)

-- 
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] Multiplexing blocking call on Go routine

[Jesse McNelis]

On Thu, Jan 5, 2017 at 9:51 AM,   wrote:
> Hey guys,
>
>  So for some time now I have been trying to build a high performance Pub/Sub
> server in Go. I am using gorilla websocket library, which in it self has a
> Read, Write methods
> (https://godoc.org/github.com/gorilla/websocket#Conn.ReadMessage) that will
> block my current routine. In order to continuously listen to messages coming
> from client I spin off a go routine, reading from socket and pushing
> messages over a channel. Which I in-turn can use for doing select { } in
> another go routine. When I testing this thing for scaling, I just wrote some
> test code and turns out spinning off 1M go routines (doing nothing) results
> in ~8GB of memory usage on my windows machine.

You should compare this with a simple C program using epoll, you'll
find that maintaining a 1M connections uses quite a lot of memory.

>These go routines are doing
> nothing (sleeping) and it requires this much memory; which forced me to ask
> if I can multiplex such blocking calls on a single go routine. If I can do
> so I can spin off something like 1000 go routines and each one of them
> multiplexing 1000 connections (which in theory should require lesser memory
> that what I am currently getting).

But a real program won't holding 1M connections and doing nothing with them.
The cost of processing requests from those connections will be much
larger than the cost of a goroutine.


>  Any ideas how can one call muiltple socket reads (something like event
> loop) on single go routine.

There really isn't a way, The net package already provides a
lightweight way to maintain larger numbers of connections using
goroutines.


> Disclaimer: I know event loop may sound against the golang philosophy but I
> see no reason to pay such huge memory cost when most of them will be idle,
> waiting for something to come from user.

I think you're underestimating the memory cost of simply having 1M connections.

-- 
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] I see the usage of interface{} everywhere why don't it get declare in standard library and given a common name?

[Jesse McNelis]

On Fri, Dec 30, 2016 at 9:24 PM, San  wrote:
> I have a question.
> Since the usage of the blank interface is so popular.
> Why does it not get declared in the standard library?
>

Giving it a name has been discussed many times.
What would be a good name for it is still unclear.

-- 
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] Unexpected type switch case listing & equality behaviour for float64

[Jesse McNelis]

On Sat, Dec 31, 2016 at 3:26 AM, Uwe Dauernheim  wrote:
> It seem a float64 of value 0.0 as types interface{} can't be compared equal
> to 0 in an exhaustive case clause type list, but can be compared equal in
> almost any other scenario.
>
> https://play.golang.org/p/t2u2GGp565
>
> I find this unexpected. Could someone explain how case clause type lists in
> type assertions work?
> The language specification states:
>
>> In clauses with a case listing exactly one type, the variable has that
>> type; otherwise, the variable has the type of the expression in the
>> TypeSwitchGuard.
>
> In the provided playground is no TypeSwitchGuard given, so this rule should
> not affect behaviour.

switch g := f.(type) {
case int, int8, int16, int32, int64, uint, uint8, uint16, uint32,
uint64, float32, float64:
   //g is of type interface{}
}

"the expression in the TypeSwitchGuard" is 'f' which is of type
interface{} in this case. Thus 'g' has the type interface{} within the
case.

The comparison 'g == 0'  is false because 'g' contains a float64 and 0
is an 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.

Re: [go-nuts] Correct naming of Go !

[Jesse McNelis]

On Wed, Dec 28, 2016 at 12:26 AM, Ken Nakagama  wrote:
> Hi Everyone
>
> Across the ether of the Internet, Go! is referred to and keyworded
> differently.

Go! is a completely different language.
https://en.wikipedia.org/wiki/Go!_(programming_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.

Re: [go-nuts] gob ignores default values, bug or feature?

[Jesse McNelis]

On Sat, Dec 10, 2016 at 5:49 PM, Hoping White  wrote:
> Hi, all
>
> I find that gob encoding ignores fields when they have zero values.
> I wonder if this is a bug or an feature?
>

" If a field has the zero value for its type (except for arrays; see
above), it is omitted from the transmission."
https://golang.org/pkg/encoding/gob/#hdr-Encoding_Details

It's a feature, it makes gobs smaller.

-- 
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] Thinking OO virtual function in Go

[Jesse McNelis]

On 23 Nov. 2016 9:03 am, "Tong Sun"  wrote:
>
> So, once again, thinking in OO, I'll define all of the common variables
in base class, and common functionalities in virtual functions. How to make
that idea work in Go?
>
> For the above specific code, how to easily make "func Output" works?
>

You can use functions and embedding for code reuse and interfaces for
polymorphism.

In your example you've implemented Speak() method for each type and defined
a Speaker interface but then in Output() you don't call Speak().

If you have fields you want available through the Speaker interface then
you need to define getter methods for those fields and add them to the
interface.

You could also add a Speak() method to the Animal type which would then be
available on any type that embeds an Animal and would have direct access to
any fields on Animal.

You could define a Speak() function that all the Speak() methods call for
some common functionality.

How you structure it depends on what real world problem you're trying to
solve.

-- 
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] Thinking OO virtual function in Go

[Jesse McNelis]

On Wed, Nov 23, 2016 at 8:16 AM, Tong Sun  wrote:
> Hi,
>
> How to architect the OO's virtual function in Go?
>
> Please take a look at this (not working) Go program
> https://play.golang.org/p/qrBX6ScABp
>
> Please think of the "func Output()" as a very complicated function that I
> only want to define once at the base level, not to duplicate into each sub
> classes.
>
> How can I make it works so that the last output statement, instead of being,
>
> fmt.Printf("[%v] %s: [%0.2f]\n", k, v.Name(), v.Area())
>
>
> will be this instead:
>
> fmt.Printf("[%v] %s\n", k, v.Output())
>

You define a function:

func Output(s Shape) string {
   return s.Name() + "'s area size is " + s.Area()
}

Go uses interfaces for polymorphism.
Other OOP languages can use inheritance for polymorphism too, but Go
doesn't have inheritance.

-- 
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] Ignoring UTF-8 BOM when decoding JSON

[Jesse McNelis]

On Fri, Sep 23, 2016 at 9:37 PM, Mark Richman  wrote:
>
> Is there any way to tell Decode() to ignore the BOM, or do I have to peek at
> the first 3 bytes and skip them somehow?
>

What you need is an io.Reader that skips the BOM.
Luckily someone wrote a package for that.
https://github.com/spkg/bom

-- 
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] Newbie Struggling w/ Hashing

[Jesse McNelis]

On 20 Sep 2016 9:03 a.m., "Robert Solomon"  wrote:
>
> FileReadBuffer := make([]byte,ReadBufferSize);
> for {   // Repeat Until eof loop.
>   n,err := TargetFile.Read(FileReadBuffer);
>   if n == 0 || err == io.EOF { break }
>   check(err," Unexpected error while reading the target file on which
to compute the hash,");
>   hasher.Write(FileReadBuffer);
>   FileSize += int64(n);
> } // Repeat Until

The problem you encounter is that .Read() isn't required to fill the buffer
you give it, it can give you less than that.

Handling that requires you to slice the result
eg. hasher.Write(FileReadBuffer[:n]);

But you should avoid calling Read() and Write() and instead use higher
level functions like io.Copy() which will handle these low level details
for you.

Read the io package docs for more information.
https://golang.org/pkg/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: Why + and += operators for string but not slices?

[Jesse McNelis]

On 17 Sep 2016 12:31 p.m.,  wrote:
>
> Context enables homonyms in spoken languages and overloaded or
polymorphic notation in mathematics. Types do the same in programming
languages. The rationale for + over join() or cat() for string is equally
applicable to slices.

1+1 give you a new number that doesn't modify the original numbers being
added.
This is the expected way addition works.

In Go this also works for strings, "a"+"b" gives you "ab" and the original
strings are unmodified.

For slices this is different, two slices can refer to the same backing
array so slice1 + slice2 could either allocate a new slice and copy both
slices in to it, or it could modify slice1 by appending slice2.

If slice1 and slice2 refer to the same backing array, their addition could
change both of the original values, this addition can also effect slice3
that happens to also reference the same backing array.

append() isn't addition because of these properties.

-- 
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 a **T value can't call methods of *T and T if a *T value can call methods of T?

[Jesse McNelis]

On Tue, Aug 23, 2016 at 3:11 PM, T L  wrote:
> If a programmer will call it anyway, she/he doesn't care efficiency. What
> she/he cares is the convenience and cleanness.
> ppt.f() is surely cleaner than (*ppt).f(), right?
>

It shouldn't be convenient or look clean to do the wrong thing.
(*ppt).f() should look horrible because it is horrible.

-- 
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 a **T value can't call methods of *T and T if a *T value can call methods of T?

[Jesse McNelis]

> Why a **T value can't call methods of *T and T if a *T value can call methods 
> of T?

How many levels of auto dereferencing should there be?
Should *T still have the same method set as *T?

It's reasonable to set a sensible limit because pointer chasing is an
expensive operation.
So for anything more indirect than *T you need to explicitly show the
dereferencing.

-- 
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] Cast interface{} to []string

[Jesse McNelis]

On Sat, Aug 13, 2016 at 4:41 AM, Vasily Korytov  wrote:
> Hi,
>
> I have an interface{} variable that can be either string or a list of string
> (yes, that's bad design, I know).

Your code below indicates that you're storing a []interface{} not an []string.

> Have I overlooked something and there is a way to do it in a more graceful
> and effective way?

Could you instead store a []string in your interface{} instead of an
[]interface{}?

-- 
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 a function in standard lib to convert []T to a []interface{}?

[Jesse McNelis]

On Thu, Aug 4, 2016 at 3:33 PM, T L  wrote:
>
> With some special memory optimizations for slice, I think it is possible to
> make efficient conversions from []T to []interface.
> For example, we don't need to convert every element in []T to interface{},
> we can just use following struct to represent a special []interface{},
> the concrete type of all interface{} values in the []interface{} is the same
> one.
>>
>> type specialInterfaceSlice struct {
>>   typ *_type
>>   values []T
>> }
>

That avoids the copy, but makes it impossible to take the address of
an interface{} in that []interface{}.

-- 
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 a function in standard lib to convert []T to a []interface{}?

[Jesse McNelis]

On 4 Aug 2016 12:36 a.m., "T L"  wrote:
>
> Often, I need converting a []T to []interface{} to use the []interface as
a variable length parameter.
> But converting a []T for []interface{} in a for loop is neither clean nor
efficient.
>
> So is there a function in standard lib to convert []T to a []interface{}?
>

There is no function and it's not possible to define one in Go.

Define your own function for your specific type or avoid []interface{} if
you can. Usually what you want is to put a []T in an interface{} and use
reflect instead.

-- 
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] Will the real value allocated on heap copied when assigning an interface value to another?

[Jesse McNelis]

On Sun, Jul 31, 2016 at 5:10 PM, T L  wrote:
> By reading Ross Cox's article: http://research.swtch.com/interfaces
> I got an interface value is represented by a struct as the following:
>
>>
>> type interfaceStruct struct {
>> value *_value
>> inter *struct {
>> typ  _type
>> mhdr []imethod
>> }
>> }
>
>
> where value is a pointer pointing the real value allocated on heap.
>
> In my understanding, the real values stored in an interface value are read
> only.
> So I think there is no need to copy the real value on heap when assigning an
> interface value to another, is it right?
>

Yes, there is no need.

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

Re: [go-nuts] Using "map index expressions" as the value for a range loop

[Jesse McNelis]

On 8 Jul 2016 12:19 a.m., "Jan Mercl" <0xj...@gmail.com> wrote:
>
>  I did not expect the result I've got:
https://play.golang.org/p/ECno0PVdBF
>
> It seems like a bug to me.
>

Looks fine to me. The k in m[k] is the value of k before the assignment.

So the value at m["foo"] is assigned to m[""] and the value at m["bar"] is
assigned to m["foo"]

-- 
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 is my program retaining memory when len([]byte)>16384 ?

[Jesse McNelis]

On Mon, Jul 4, 2016 at 3:35 AM, mhhcbon  wrote:
> Hi,
>
> I have this program which reads file, flate encode then flate decode the
> data.
>
> I noticed that when i used different size for the slice of []byte to read
> data, the program will retain memory when the size is > 16384.
> When its lower than this value everything is fine, but 16385 breaks.
>
> I don t quite understand the reason of this behavior, can someone help me to
> understand what s going on there ?

I can't see anywhere that this program could be holding on to extra
memory it's not using.
But the problem might just be that you're writing many more bytes to
your encoder than you're reading from the file.

_, err := src.Read(b); // read from file

Read() isn't required to fill the whole buffer it's given. It can read
a single byte and return.
Because you're ignoring the value telling you how many bytes it read
you're passing the whole 16385 slice to your encoder even though you
might have read much less than 16385 bytes.

This means the size of buf2 could be much larger than the original
file and also full of junk data from previous reads and zeroed bytes.

Read() is a low level call that you should avoid calling directly
because it's tricky to get right.

For an example of how to properly call a Read() see the implementation
of io.Copy()
https://golang.org/src/io/io.go?#L366

-- 
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] golang poll/epoll/select

[Jesse McNelis]

On 25 Jun 2016 11:08 p.m., "Michael Soulier"  wrote:
>
> Sure, but when you read and get an EOF you return immediately, so the
goroutine would be busy waiting when there's nothing to read, would it not?
>

You'll only get an EOF if the file descriptor has been closed, if it's
closed then you're not going to be able to read anything more anyway.

What are you trying to do?

-- 
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] net.ListenUDP, ListenTCP & new go routine creation

[Jesse McNelis]

On 21 Jun 2016 12:42 a.m., "Manohar Kumar"  wrote:
>
> I am mainly interested in Linux and have to make these calls in a part of
the code where new OS thread creation isn't desirable. Please note that
changing that aspect of the design itself is not an option for me.

If you have a requirement that you need tight control over when threads are
created then Go isn't the language for you.

The net package makes a number of threads while it wait s on various
syscalls.

Can I ask why you need to avoid thread creation?

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