[go-nuts] Re: what can I do about this interface conversion error

[alex . rou . sg]

If basicNode isn't the only struct that could be passed, I would argue that 
that's cleaner than checking for every possible type.
Also doing it that way means that your interface couldn't care less about 
the actual structure of the struct and so is much more flexible.
And they won't break if and when you decide to change the struct layout 
cause that doesn't matter anymore.

btw if the structs and interface are in different packages, you need to 
make those methods public or it wouldn't be able to call them. 

Can I suggest you join the golang discord chat server? You seem to be 
asking a lot of short answer questions and a chat server would give you 
faster response time than a forum.
https://discord.gg/7WhXAaF

On Wednesday, 2 May 2018 11:49:03 UTC+8, Mark Nahabedian wrote:
>
> Thanks for your help and patience Alex.  I guess I need to do something 
> like 
>
> https://play.golang.org/p/qURVD3of5oU 
>
> but I find it kind of unclean to have to add private methods to do this. 
>
> It wouldn't be appropriate to define a basicNode getter method on the node 
> interface since basicNode is just one possible implementstion. 
>
> Anyway, I'm past that problem. 
>
> Thank 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] Re: Go could really use a while statement

[Michael Jones]

The 'do' in this could be a 'for' if for allowed an optional 'while' after
the close brace.

On Tue, May 1, 2018 at 9:08 PM Louki Sumirniy <
louki.sumirniy.stal...@gmail.com> wrote:

> I have a preferred methtod for emulating do-while:
>
> notdone:=true
> for notdone {
>   
>   if  {
> notdone = false
>   }
> }
>
> I prefer to use a negative name because I don't see why I should use a
> unary operator when I can just use the word NOT and not incur any runtime
> cost.
>
> or
>
> for ! {
>   
> }
>
> The for is so awesome that the only that is theoretically missing is a
> do-while.
>
> Also, another way to do this would be using labels. If you put a label
> before the part beginning what you want to repeat, you can put a condition
> at the end that jumps to the label for your repeat condition. I think the
> label could even be Do:
>
> But it would be pretty cool if a do-while was added, since it won't break
> old code, but it will break using old versions prior to this addition. It
> would look like this
>
> do {
>
> } while 
>
> I suppose. Someone posted about a macro processor that probably could do
> something like this. I personally don't see the point because most of the
> time I can find a way to use the second construct I showed earlier - a
> condition that does not evaluate false until the inner block has executed
> at least once.
>
> On Tuesday, 1 May 2018 14:11:04 UTC+3, Hugh Fisher wrote:
>>
>>
>> Another observation from this novice Go programmer: I'm puzzled why
>> there's no while statement.
>>
>> I know it's possible to use a for, but it doesn't feel right to me. I
>> always
>> think of for loops as for iterating over data structures. Originally just
>> arrays, but languages like Python and Objective-C have extended for
>> loops to other collections as well. "Looping until some condition is met"
>> for me is a different control structure and needs a different keyword.
>>
>> There'd be overlap with the for statement, but if-then-else and switch
>> with boolean case overlap too.
>>
>> And since while has been a reserved keyword in a lot of programming
>> languages for many decades, I would bet a reasonable amount of
>> money that a while statement could be added to Go right now and not
>> break anyone's production code.
>>
>> cheers,
>> Hugh Fisher
>>
>> --
> 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.
>


-- 
Michael T. Jones
michael.jo...@gmail.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] Re: Go could really use a while statement

[Louki Sumirniy]

I have a preferred methtod for emulating do-while:

notdone:=true
for notdone {
  
  if  {
notdone = false
  }
}

I prefer to use a negative name because I don't see why I should use a 
unary operator when I can just use the word NOT and not incur any runtime 
cost.

or

for ! {
  
}

The for is so awesome that the only that is theoretically missing is a 
do-while. 

Also, another way to do this would be using labels. If you put a label 
before the part beginning what you want to repeat, you can put a condition 
at the end that jumps to the label for your repeat condition. I think the 
label could even be Do:

But it would be pretty cool if a do-while was added, since it won't break 
old code, but it will break using old versions prior to this addition. It 
would look like this

do {

} while 

I suppose. Someone posted about a macro processor that probably could do 
something like this. I personally don't see the point because most of the 
time I can find a way to use the second construct I showed earlier - a 
condition that does not evaluate false until the inner block has executed 
at least once.

On Tuesday, 1 May 2018 14:11:04 UTC+3, Hugh Fisher wrote:
>
>
> Another observation from this novice Go programmer: I'm puzzled why
> there's no while statement.
>
> I know it's possible to use a for, but it doesn't feel right to me. I 
> always
> think of for loops as for iterating over data structures. Originally just
> arrays, but languages like Python and Objective-C have extended for
> loops to other collections as well. "Looping until some condition is met"
> for me is a different control structure and needs a different keyword.
>
> There'd be overlap with the for statement, but if-then-else and switch
> with boolean case overlap too.
>
> And since while has been a reserved keyword in a lot of programming
> languages for many decades, I would bet a reasonable amount of
> money that a while statement could be added to Go right now and not
> break anyone's production code.
>
> cheers,
> Hugh Fisher
>
>

-- 
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: what can I do about this interface conversion error

[naha]

Thanks for your help and patience Alex.  I guess I need to do something like

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

but I find it kind of unclean to have to add private methods to do this.

It wouldn't be appropriate to define a basicNode getter method on the node 
interface since basicNode is just one possible implementstion.

Anyway, I'm past that problem.

Thank 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] Is GC affected by array size, and if so, when and how?

[Ian Lance Taylor]

On Tue, May 1, 2018 at 1:17 PM,   wrote:
>
> That is all as I anticipated, but I don't know where this is documented.

The fact that the GC does not scan the contents of a [1000]byte is not
user visible, so it doesn't really belong in user documentation.  I
would start with the long comment at the top of runtime/mbitmap.go.

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] proposal: embed static assets

[Ian Lance Taylor]

On Tue, May 1, 2018 at 1:28 PM, John Unland  wrote:
>
> So something like x/tools/cmd/assets or cmd/assets?

Yes.  I might use a name more like cmd/embed.


> I was just now thinking about it more today and I was wondering if something
> like this could maybe be implemented into go build. Like how you can assign
> variables at build time:
>
> go build -ldflags="-X main.Foo=Bar"
>
> Into something like...
>
> go build -ldflags="-X main.Asset1=./SomeFileA main.Asset2=./SomeFileB"
>
> Think this would take a little more effort to integrate in but it's a
> interesting concept thou.

Personally I think the code generation approach is simpler.

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] Re: what can I do about this interface conversion error

[alex . rou . sg]

You can't do that with interfaces, embedding struct or not. You can only 
call methods on interfaces or assert to a type.

On Wednesday, 2 May 2018 05:48:26 UTC+8, Mark Nahabedian wrote:
>
> b2 isn't in my most recent example.  Thus gets the error that n2.inputs is 
> not defined. 
>
> func (n1 *basicNode) OutputsTo(n2 node) { 
> n2.inputs = append(n2.inputs, n1) 
> n1.outputs = append(n1.outputs, n2) 
> }

-- 
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: what can I do about this interface conversion error

[naha]

b2 isn't in my most recent example.  Thus gets the error that n2.inputs is not 
defined.

func (n1 *basicNode) OutputsTo(n2 node) {
n2.inputs = append(n2.inputs, n1)
n1.outputs = append(n1.outputs, n2)
}

-- 
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: what can I do about this interface conversion error

[alex . rou . sg]

>
> That shows that basicNode's inputs and outputs fields are not visible as 
> fields of ActionNode or TestNode though.


Yup, struct embedding is just a shortcut to writing wrapper functions. 

Even if basicNode's fields gets promoted to ActionNode's fields, doing
b2 := n2.(*basicNode)
Wouldn't work anyway, they are still completely different named types and 
go is very strict on that.

On Wednesday, 2 May 2018 05:21:51 UTC+8, Mark Nahabedian wrote:
>
> I was expecting that since basicNode is anonymously embedded into TestNode 
> and ActionNode, that the methods and fields of basicNode would all be 
> present in TestNode and ActionNode.  In that case I'd have expected
>
> https://play.golang.org/p/gIvykcxFTmQ
>
> to have worked.  That shows that basicNode's inputs and outputs fields are 
> not visible as fields of ActionNode or TestNode though.
>
>
>
>
> On Tuesday, May 1, 2018 at 3:58:35 PM UTC-4, alex@gmail.com wrote:
>>
>> Struct embedding works like this:
>>
>> type ActionNode struct {
>> basicNode
>> }
>>
>> Turns into:
>>
>> type ActionNode struct {
>> basicNode basicNode
>> }
>>
>> func (a *ActionNode) OutputsTo(n2 node) {
>> a.basicNode.OutputsTo(n2)
>> }
>>
>> So basicNode will behave as a field of ActionNode with wrapper functions.
>> If you must embed and get basicNode out of a interface then you need to 
>> add to your interface a new method to get basicNode, e.g. 
>> https://play.golang.org/p/QhTmqeg9vgU
>>
>> On Wednesday, 2 May 2018 03:43:17 UTC+8, Mark Nahabedian wrote:
>>>
>>> I don't know why I'm getting this interface conversion error or what to 
>>> do about it.
>>>
>>> I define an interface, node, and a struct, basicNode that implements 
>>> behavior common to all nodes.  I also define ActionNode and TestNode which 
>>> both anonymously embed basicNode.
>>>
>>> basicNode implements OutputsTo which links the receiver with the node 
>>> passed as argument.
>>>
>>> I get the runtime error
>>>
>>> panic: interface conversion: main.node is *main.ActionNode, not 
>>> *main.basicNode
>>>
>>>
>>>
>>>
>>> Here's a playground link that exhibits my problem:
>>>
>>> https://play.golang.org/p/ZeIkJSd7qB0
>>>
>>> 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: what can I do about this interface conversion error

[naha]

I was expecting that since basicNode is anonymously embedded into TestNode 
and ActionNode, that the methods and fields of basicNode would all be 
present in TestNode and ActionNode.  In that case I'd have expected

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

to have worked.  That shows that basicNode's inputs and outputs fields are 
not visible as fields of ActionNode or TestNode though.




On Tuesday, May 1, 2018 at 3:58:35 PM UTC-4, alex@gmail.com wrote:
>
> Struct embedding works like this:
>
> type ActionNode struct {
> basicNode
> }
>
> Turns into:
>
> type ActionNode struct {
> basicNode basicNode
> }
>
> func (a *ActionNode) OutputsTo(n2 node) {
> a.basicNode.OutputsTo(n2)
> }
>
> So basicNode will behave as a field of ActionNode with wrapper functions.
> If you must embed and get basicNode out of a interface then you need to 
> add to your interface a new method to get basicNode, e.g. 
> https://play.golang.org/p/QhTmqeg9vgU
>
> On Wednesday, 2 May 2018 03:43:17 UTC+8, Mark Nahabedian wrote:
>>
>> I don't know why I'm getting this interface conversion error or what to 
>> do about it.
>>
>> I define an interface, node, and a struct, basicNode that implements 
>> behavior common to all nodes.  I also define ActionNode and TestNode which 
>> both anonymously embed basicNode.
>>
>> basicNode implements OutputsTo which links the receiver with the node 
>> passed as argument.
>>
>> I get the runtime error
>>
>> panic: interface conversion: main.node is *main.ActionNode, not 
>> *main.basicNode
>>
>>
>>
>>
>> Here's a playground link that exhibits my problem:
>>
>> https://play.golang.org/p/ZeIkJSd7qB0
>>
>> 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] proposal: embed static assets

[John Unland]

So something like *x/tools/cmd/assets* or *cmd/assets*?

I was just now thinking about it more today and I was wondering if 
something like this could maybe be implemented into *go build*. Like how 
you can assign variables at build time:

*go build -ldflags="-X main.Foo=Bar"*

Into something like...



*go build -ldflags="-X main.Asset1=./SomeFileA main.Asset2=./SomeFileB"*Think 
this would take a little more effort to integrate in but it's a interesting 
concept thou.

On Monday, April 30, 2018 at 2:57:12 PM UTC-5, Ian Lance Taylor wrote:
>
> On Mon, Apr 30, 2018 at 12:10 PM, John Unland  > wrote: 
> > 
> > Don't think so, I think most tools out there have the same basic premise 
> > behind embedding assets. I think it would be great to have one standard 
> tool 
> > into the stdlib. Since Go is a language for the web this would align 
> greatly 
> > with something like this. 
>
> I think the place for such a standardized tool would 
> golang.org/x/tools, along the lines of cmd/stringer which is there 
> today. 
>
> Ian 
>
>
> > On Monday, April 30, 2018 at 1:09:02 PM UTC-5, Ian Lance Taylor wrote: 
> >> 
> >> On Mon, Apr 30, 2018 at 7:03 AM, John Unland  
> wrote: 
> >> > 
> >> > Hey everyone I've been mulling over this for a couple of days, 
> thought I 
> >> > would get some feed back on the possibility of shooting a proposal to 
> >> > have 
> >> > embedding static assets into the stdlib. From the looks of it this 
> >> > wouldn't 
> >> > break Go 1 compatibility thou I'm wondering if it would be better to 
> >> > just 
> >> > have this apart of a Go 2 release instead. 
> >> > 
> >> > Any thoughts? 
> >> 
> >> How would this differ from something like 
> >> https://github.com/rakyll/statik , which I think could be invoked via 
> >> go:generate? 
> >> 
> >> 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...@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] Is GC affected by array size, and if so, when and how?

[time4dan]

That is all as I anticipated, but I don't know where this is documented.

Any chance you could point me in the right direction? Even in the source 
code, the closest I could come to an answer was something to do with type 
"spans", but I'm so unfamiliar with the terminology...

-- 
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 GC affected by array size, and if so, when and how?

[Ian Lance Taylor]

On Tue, May 1, 2018 at 1:00 PM,   wrote:
>
> I looked at the source but can't understand it well enough.
>
> If I allocate a [1000]byte, or a []byte, I understand the GC will need to
> mark the slice/array itself for collection. However, does the GC mark all
> the bytes within, and does the marking phase attempt to follow all the
> items?

A [1000]byte value holds no pointers, so the GC marks that value once
and does not look inside it.

A []byte holds a single pointer, to the backing array, and the backing
array holds no pointers, so the GC marks the []byte and the backing
array, and then stops.


> Will the GC pause longer if I allocate a large array?

No.

In any case GC pause times are essentially independent of the amount
of allocation you do, since the GC runs concurrently with the program.
Allocating larger values that contain pointers will cause the GC to do
more work, but it won't cause the GC to pause longer.


> Additionally, if the array type is actually [1]struct{*int}, then surely
> it must follow the array as those pointers may be the only references to
> some data somewhere. Does the GC know not to follow types that contain no
> references?

Yes, and yes.

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] Is GC affected by array size, and if so, when and how?

[time4dan]

I looked at the source but can't understand it well enough.

If I allocate a [1000]byte, or a []byte, I understand the GC will need to 
mark the slice/array itself for collection. However, does the GC mark all 
the bytes within, and does the marking phase attempt to follow all the 
items?

Will the GC pause longer if I allocate a large array?

Additionally, if the array type is actually [1]struct{*int}, then 
surely it must follow the array as those pointers may be the only 
references to some data somewhere. Does the GC know not to follow types 
that contain no references?

Thanks for any advice in this area.

-- 
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: what can I do about this interface conversion error

[alex . rou . sg]

Struct embedding works like this:

type ActionNode struct {
basicNode
}

Turns into:

type ActionNode struct {
basicNode basicNode
}

func (a *ActionNode) OutputsTo(n2 node) {
a.basicNode.OutputsTo(n2)
}

So basicNode will behave as a field of ActionNode with wrapper functions.
If you must embed and get basicNode out of a interface then you need to add 
to your interface a new method to get basicNode, 
e.g. https://play.golang.org/p/QhTmqeg9vgU

On Wednesday, 2 May 2018 03:43:17 UTC+8, Mark Nahabedian wrote:
>
> I don't know why I'm getting this interface conversion error or what to do 
> about it.
>
> I define an interface, node, and a struct, basicNode that implements 
> behavior common to all nodes.  I also define ActionNode and TestNode which 
> both anonymously embed basicNode.
>
> basicNode implements OutputsTo which links the receiver with the node 
> passed as argument.
>
> I get the runtime error
>
> panic: interface conversion: main.node is *main.ActionNode, not 
> *main.basicNode
>
>
>
>
> Here's a playground link that exhibits my problem:
>
> https://play.golang.org/p/ZeIkJSd7qB0
>
> 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] Go could really use a while statement

[Justin Israel]

On Wed, May 2, 2018, 1:56 AM Michael Jones  wrote:

> Maybe he meant "until" aka "do {...} while cond" -- this is a valuable and
> missing mechanism. The argument back in the day was that having just one
> looping construct was more friendly to tooling.
>

Based on this...

> I know it's possible to use a for, but it doesn't feel right to me. I
always
think of for loops as for iterating over data structures.

... I didn't think it meant a different construct like 'do while'.

It just comes down to how one thinks of for loops. To me, even though I
come from a Python background with a 'while' construct, I don't think of a
for loop in Go as specifically iterating over data structures. I think of
it as looping for the duration of a True condition. So that being said I
could see this being the same:

while item := range items {...}



> On Tue, May 1, 2018 at 5:45 AM Ian Lance Taylor  wrote:
>
>> On Tue, May 1, 2018 at 4:11 AM, Hugh Fisher 
>> wrote:
>> >
>> > Another observation from this novice Go programmer: I'm puzzled why
>> > there's no while statement.
>> >
>> > I know it's possible to use a for, but it doesn't feel right to me. I
>> always
>> > think of for loops as for iterating over data structures. Originally
>> just
>> > arrays, but languages like Python and Objective-C have extended for
>> > loops to other collections as well. "Looping until some condition is
>> met"
>> > for me is a different control structure and needs a different keyword.
>> >
>> > There'd be overlap with the for statement, but if-then-else and switch
>> > with boolean case overlap too.
>> >
>> > And since while has been a reserved keyword in a lot of programming
>> > languages for many decades, I would bet a reasonable amount of
>> > money that a while statement could be added to Go right now and not
>> > break anyone's production code.
>>
>> A `while` statement would presumably be exactly identical to a `for`
>> statement with a single condition.  So adding a `while` statement
>> would not add any power to the language, and would add an additional
>> keyword.  All language choices are a cost benefit decision.  In this
>> case the benefit is a looping construct that some people will find
>> clearer to read and write, and the cost is a new keyword that
>> everybody needs to learn, and that at this point in the language's
>> evolution will likely break some, even if not much, existing code.  I
>> don't think the benefit is worth the cost.
>>
>> 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.
>>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.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.
>

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

[go-nuts] what can I do about this interface conversion error

[naha]

I don't know why I'm getting this interface conversion error or what to do 
about it.

I define an interface, node, and a struct, basicNode that implements 
behavior common to all nodes.  I also define ActionNode and TestNode which 
both anonymously embed basicNode.

basicNode implements OutputsTo which links the receiver with the node 
passed as argument.

I get the runtime error

panic: interface conversion: main.node is *main.ActionNode, not *main.basicNode




Here's a playground link that exhibits my problem:

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

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] Windows OneDrive issue ..

[xiofen77]

I just discovered a problem running/compiling files that are 
accessed/backed up by windows OneDrive

(don't know when this started - worked a couple of months ago..)

So I have a simple go file at

C:\Users\xiool\OneDrive\go ie test.go

At the command line all variants of

go run C:/Users/xiool/OneDrive/go/test.go

give the error

package main: cannot find package "." in:
C:\Users\xiool\OneDrive\go

The files are stored offline on the computer, and simple replacements such 
as 

notepad.exe C:/Users/xiool/OneDrive/go/test.go

Work as expected


Build/install etc also fail. No issues outside the OneDrive directory. And 
no issues a few months back.

I assume this is a windows problem .. but what ??

Anyone else had this.. and a fix please ??

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

Re: [go-nuts] Go could really use a while statement

[xiofen77]

>
> On Tue, May 1, 2018 at 7:36 AM Alisdair  > wrote:
>
>> Isn't `for { ... if cond { break; } }` the same as `do {...} while cond`? 
>> Whilst having the benefits of not adding new keywords and maintaining the 
>> logic of the loop entirely within the block of the loop making it simpler 
>> to understand.
>>
>>
>>
Doesn't that check at initialization of the loop, while a "repeat until/do 
while" checks after at least one pass.. ? 

-- 
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.10.2 and Go 1.9.5 are released

[Nathan Kerr]

I updated my release related resources:

   - Go Release Timeline 
   - When Should You Upgrade Go? 
   
   
Nathan

On Tuesday, May 1, 2018 at 10:04:38 AM UTC-7, Andrew Bonventre wrote:
>
> Hi gophers,
>
> We have just released Go versions 1.10.2 and 1.9.6, minor point releases.
>
> These releases include fixes to the compiler, linker, and go command.
>
> View the release notes for more information:
> https://golang.org/doc/devel/release.html#go1.10.minor
>
> You can download binary and source distributions from the Go web site:
> https://golang.org/dl/
>
> To compile from source using a Git clone, update to the release with
> "git checkout go1.10.2" and build as usual.
>
> Thanks to everyone who contributed to the release.
>
> The Go Team
>
>

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

SV: [go-nuts] 1: json: cannot unmarshal array into Go value of typemain.Catcher or 2: json: cannot unmarshal object into Go value of typemain.Crypto4

[Michael Banzon]

You are declaring your struct as []struct and then using it as ”var collect 
[]Crypto4” effectively doubling the arraynes 

See this: https://play.golang.org/p/Q3RzNddeVVT

And on a side note: Please check your errors – especially if Things doesn’t 
work – a few err != nil along with fmt.Println’s will save the day 

-- 
Michael Banzon
https://michaelbanzon.com/

Fra: m_@li
Sendt: 1. maj 2018 16:05
Til: golang-nuts
Emne: [go-nuts] 1: json: cannot unmarshal array into Go value of 
typemain.Catcher or 2: json: cannot unmarshal object into Go value of 
typemain.Crypto4

Hi !
 I was searching relevant posts  regarding error "json: cannot unmarshal array 
into Go value of type main.Catcher" or "json: cannot unmarshal object into Go 
value of type main.Crypto4". These two error messages are linked to the same 
program (depends on when I change structure). Actually I have to write/display 
data on HTML file which will linked through local host port 8080. I could not 
understand where is the problem I have shared my code and link is attached here.
https://play.golang.org/p/DLOdEGS7hmG (I have quoted main problem with my code 
instead of write down all the code, means another function where I presented 
json data through api and it works good, but presentation of data on html file 
is the problem.
I have created slice like var collect []Crypto4 inside the function and 
unmarshall data through this variable, but still getting error and html file is 
not displaying data, instead of getting error which I wrote above in title. It 
would be so nice to guide me and point out the problem with possible solutions, 
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.

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

Re: [go-nuts] Go could really use a while statement

[Alisdair]

Isn't `for { ... if cond { break; } }` the same as `do {...} while cond`?
Whilst having the benefits of not adding new keywords and maintaining the
logic of the loop entirely within the block of the loop making it simpler
to understand.

On Tue, 1 May 2018 at 14:56, Michael Jones  wrote:

> Maybe he meant "until" aka "do {...} while cond" -- this is a valuable and
> missing mechanism. The argument back in the day was that having just one
> looping construct was more friendly to tooling.
>
> On Tue, May 1, 2018 at 5:45 AM Ian Lance Taylor  wrote:
>
>> On Tue, May 1, 2018 at 4:11 AM, Hugh Fisher 
>> wrote:
>> >
>> > Another observation from this novice Go programmer: I'm puzzled why
>> > there's no while statement.
>> >
>> > I know it's possible to use a for, but it doesn't feel right to me. I
>> always
>> > think of for loops as for iterating over data structures. Originally
>> just
>> > arrays, but languages like Python and Objective-C have extended for
>> > loops to other collections as well. "Looping until some condition is
>> met"
>> > for me is a different control structure and needs a different keyword.
>> >
>> > There'd be overlap with the for statement, but if-then-else and switch
>> > with boolean case overlap too.
>> >
>> > And since while has been a reserved keyword in a lot of programming
>> > languages for many decades, I would bet a reasonable amount of
>> > money that a while statement could be added to Go right now and not
>> > break anyone's production code.
>>
>> A `while` statement would presumably be exactly identical to a `for`
>> statement with a single condition.  So adding a `while` statement
>> would not add any power to the language, and would add an additional
>> keyword.  All language choices are a cost benefit decision.  In this
>> case the benefit is a looping construct that some people will find
>> clearer to read and write, and the cost is a new keyword that
>> everybody needs to learn, and that at this point in the language's
>> evolution will likely break some, even if not much, existing code.  I
>> don't think the benefit is worth the cost.
>>
>> 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.
>>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.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.
>

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

[go-nuts] Go 1.10.2 and Go 1.9.5 are released

[Andrew Bonventre]

Hi gophers,

We have just released Go versions 1.10.2 and 1.9.6, minor point releases.

These releases include fixes to the compiler, linker, and go command.

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.10.minor

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

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

Thanks to everyone who contributed to the release.

The Go Team

-- 
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] float accuracy when calculating Fibonacci numbers

[Marvin Renich]

* andrey mirtchovski  [180430 17:41]:
> > math.Pow does not give as precise answers as the C++ std lib.
> 
> math pow doesn't just multiply X by itself Y times, it uses a
> different algorithm:
> 
> https://golang.org/src/math/pow.go#L40

Sure, I understand that.  However, the current algorithm used by
math.Pow produces results that are far enough from the true value that
it is worth opening an issue.

> it would perhaps make sense to quantify the error margins that this
> algorithm introduces.

As far as the OP's question about why he needs to round in Go but
truncate in C++, I am not convinced that the error in math.Pow is
significant.

Binet's formula, given exact (non-computer limited) values and
calculations, will give exact integral values for the Fibonacci numbers.
If you start with the assumption that using Binet's formula with IEEE
floating point arithmetic will give results that are close enough to the
correct value that you will have no trouble determining which integer is
the right one, then the assumption that the error is between -0.5 and
+0.5 is much more reasonable than the assumption that the error is in
the range [0, 1).

It is certainly plausible that one could prove that the error will
always be positive, given known characteristics of the computer
program's implementation of pow, among other things, but without such
analysis, assuming that truncating the result will always give the
correct answer is naive.

I posit that the OP's C++ implementation only works because of specific
characteristics of C++ library pow function, the last-mantissa-bit
rounding of the value used for phi, and other aspects of the
implementation that have not be adequately analyzed to be certain that
the error is always positive.

In short, the OP's assumption that the algorithm in his C++ program is
correct is wrong; it just happens to work for the values tested.  Both
the C++ and the Go program should round the floating point result to get
the correct integer.

...Marvin

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

Re: [go-nuts] Go could really use a while statement

[Michael Jones]

Correct.

On Tue, May 1, 2018 at 7:36 AM Alisdair 
wrote:

> Isn't `for { ... if cond { break; } }` the same as `do {...} while cond`?
> Whilst having the benefits of not adding new keywords and maintaining the
> logic of the loop entirely within the block of the loop making it simpler
> to understand.
>
> On Tue, 1 May 2018 at 14:56, Michael Jones 
> wrote:
>
>> Maybe he meant "until" aka "do {...} while cond" -- this is a valuable
>> and missing mechanism. The argument back in the day was that having just
>> one looping construct was more friendly to tooling.
>>
>> On Tue, May 1, 2018 at 5:45 AM Ian Lance Taylor  wrote:
>>
>>> On Tue, May 1, 2018 at 4:11 AM, Hugh Fisher 
>>> wrote:
>>> >
>>> > Another observation from this novice Go programmer: I'm puzzled why
>>> > there's no while statement.
>>> >
>>> > I know it's possible to use a for, but it doesn't feel right to me. I
>>> always
>>> > think of for loops as for iterating over data structures. Originally
>>> just
>>> > arrays, but languages like Python and Objective-C have extended for
>>> > loops to other collections as well. "Looping until some condition is
>>> met"
>>> > for me is a different control structure and needs a different keyword.
>>> >
>>> > There'd be overlap with the for statement, but if-then-else and switch
>>> > with boolean case overlap too.
>>> >
>>> > And since while has been a reserved keyword in a lot of programming
>>> > languages for many decades, I would bet a reasonable amount of
>>> > money that a while statement could be added to Go right now and not
>>> > break anyone's production code.
>>>
>>> A `while` statement would presumably be exactly identical to a `for`
>>> statement with a single condition.  So adding a `while` statement
>>> would not add any power to the language, and would add an additional
>>> keyword.  All language choices are a cost benefit decision.  In this
>>> case the benefit is a looping construct that some people will find
>>> clearer to read and write, and the cost is a new keyword that
>>> everybody needs to learn, and that at this point in the language's
>>> evolution will likely break some, even if not much, existing code.  I
>>> don't think the benefit is worth the cost.
>>>
>>> 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.
>>>
>>
>>
>> --
>> Michael T. Jones
>> michael.jo...@gmail.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.
>>
>

-- 
Michael T. Jones
michael.jo...@gmail.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] Re: Looking for go programmers for game company

[matthewjuran]

I may be interested. Can you share background about your company here?

Thanks,
Matt

On Saturday, April 28, 2018 at 10:52:01 PM UTC-5, smga...@gmail.com wrote:
>
> Hey gophers. I have a multi platform game company that is also integrating 
> blockchain technology as well as crypto currency. I am looking for one or 
> two full time GO programmers. We are in Los Angeles but are running most 
> people remote. If you are a mid to high level programmer and interested, 
> please let me know. 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] 1: json: cannot unmarshal array into Go value of type main.Catcher or 2: json: cannot unmarshal object into Go value of type main.Crypto4

[m_@li]

Hi !

 I was searching relevant posts  regarding error "json: cannot unmarshal 
array into Go value of type main.Catcher" or "json: cannot unmarshal object 
into Go value of type main.Crypto4". These two error messages are linked to 
the same program (depends on when I change structure). Actually I have to 
write/display data on HTML file which will linked through local host port 
8080. I could not understand where is the problem I have shared my code and 
link is attached here.

https://play.golang.org/p/DLOdEGS7hmG (I have quoted main problem with my 
code instead of write down all the code, means another function where I 
presented json data through api and it works good, but presentation of data 
on html file is the problem.

I have created slice like var collect []Crypto4 inside the function and 
unmarshall data through this variable, but still getting error and html 
file is not displaying data, instead of getting error which I wrote above 
in title. It would be so nice to guide me and point out the problem with 
possible solutions, 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] Go could really use a while statement

[Michael Jones]

Maybe he meant "until" aka "do {...} while cond" -- this is a valuable and
missing mechanism. The argument back in the day was that having just one
looping construct was more friendly to tooling.

On Tue, May 1, 2018 at 5:45 AM Ian Lance Taylor  wrote:

> On Tue, May 1, 2018 at 4:11 AM, Hugh Fisher  wrote:
> >
> > Another observation from this novice Go programmer: I'm puzzled why
> > there's no while statement.
> >
> > I know it's possible to use a for, but it doesn't feel right to me. I
> always
> > think of for loops as for iterating over data structures. Originally just
> > arrays, but languages like Python and Objective-C have extended for
> > loops to other collections as well. "Looping until some condition is met"
> > for me is a different control structure and needs a different keyword.
> >
> > There'd be overlap with the for statement, but if-then-else and switch
> > with boolean case overlap too.
> >
> > And since while has been a reserved keyword in a lot of programming
> > languages for many decades, I would bet a reasonable amount of
> > money that a while statement could be added to Go right now and not
> > break anyone's production code.
>
> A `while` statement would presumably be exactly identical to a `for`
> statement with a single condition.  So adding a `while` statement
> would not add any power to the language, and would add an additional
> keyword.  All language choices are a cost benefit decision.  In this
> case the benefit is a looping construct that some people will find
> clearer to read and write, and the cost is a new keyword that
> everybody needs to learn, and that at this point in the language's
> evolution will likely break some, even if not much, existing code.  I
> don't think the benefit is worth the cost.
>
> 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.
>


-- 
Michael T. Jones
michael.jo...@gmail.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.

Re: [go-nuts] Go could really use a while statement

[Ian Lance Taylor]

On Tue, May 1, 2018 at 4:11 AM, Hugh Fisher  wrote:
>
> Another observation from this novice Go programmer: I'm puzzled why
> there's no while statement.
>
> I know it's possible to use a for, but it doesn't feel right to me. I always
> think of for loops as for iterating over data structures. Originally just
> arrays, but languages like Python and Objective-C have extended for
> loops to other collections as well. "Looping until some condition is met"
> for me is a different control structure and needs a different keyword.
>
> There'd be overlap with the for statement, but if-then-else and switch
> with boolean case overlap too.
>
> And since while has been a reserved keyword in a lot of programming
> languages for many decades, I would bet a reasonable amount of
> money that a while statement could be added to Go right now and not
> break anyone's production code.

A `while` statement would presumably be exactly identical to a `for`
statement with a single condition.  So adding a `while` statement
would not add any power to the language, and would add an additional
keyword.  All language choices are a cost benefit decision.  In this
case the benefit is a looping construct that some people will find
clearer to read and write, and the cost is a new keyword that
everybody needs to learn, and that at this point in the language's
evolution will likely break some, even if not much, existing code.  I
don't think the benefit is worth the cost.

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] Go could really use a while statement

[Hugh Fisher]

Another observation from this novice Go programmer: I'm puzzled why
there's no while statement.

I know it's possible to use a for, but it doesn't feel right to me. I always
think of for loops as for iterating over data structures. Originally just
arrays, but languages like Python and Objective-C have extended for
loops to other collections as well. "Looping until some condition is met"
for me is a different control structure and needs a different keyword.

There'd be overlap with the for statement, but if-then-else and switch
with boolean case overlap too.

And since while has been a reserved keyword in a lot of programming
languages for many decades, I would bet a reasonable amount of
money that a while statement could be added to Go right now and not
break anyone's production code.

cheers,
Hugh Fisher

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