Re: [go-nuts] Re: Is my understanding on numeric literals right?

[digg]

On Friday, January 12, 2018 at 2:42:20 AM UTC-5, Axel Wagner wrote:
>
> What do you mean by "potential type"? There is no such concept.
>
> The spec  is pretty clear, on the 
> subject, IMO. There is also this blog post 
> .
>
> The gist is: There are boolean, rune, integer, floating, complex and 
> string constants. Each of them can be used as values for different sets of 
> types - for boolean/string constants, the underlying types must be 
> bool/string. For numeric types, the value (roughly, details in the links 
> above) must be representable in the target type. This takes care of all the 
> clearly typed places a constant can appear (e.g. in an expression, a typed 
> const/var-declaration, a conversion…). Where that's not possible (e.g. an 
> untyped const/var-declaration, short variable declaration, when used in an 
> interface{} in an expression…) the default type of the literal (bool, rune, 
> int, float64, complex128 and string respectively) is assumed.
>
> What that means is, that you can use any rune/integer/float/complex 
> literal in any place where any numeric value is used (so anything with 
> underlying type {u,}int*, rune, float{32,64}, complex{64,128}, uintptr)* 
> as long as its value can be represented in the target type*. So, for 
> example this is legal , but this 
> is not .
>

Thanks for information.
 

>
> On Fri, Jan 12, 2018 at 8:07 AM, > wrote:
>
>> or 
>> an untype literal who has a *rune* potential type must also has an *int* 
>> potential type.
>> an untype literal who has an *int* potential type must also has a 
>> *float64* potential type.
>> an untype literal who has a *float64* potential type must also has a 
>> *complex128* potential type.
>>
>>
>> On Friday, January 12, 2018 at 1:34:08 AM UTC-5, di...@veryhaha.com 
>> wrote:
>>>
>>> An untyped rune literal/constant must have a popential int type.
>>> An untyped interger literal/constant must have a popential float64 type.
>>> An untyped floating-point literal/constant must have a popential 
>>> complex128 type.
>>>
>> -- 
>> 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] Re: Is my understanding on numeric literals right?

[digg]

then can I say
an untyped rune literal/constant is representable int type for sure.
an untyped interger literal/constant is representable float64 type for sure.
an untyped floating-point literal/constant is representable complex128 type 
for sure.

On Friday, January 12, 2018 at 2:42:20 AM UTC-5, Axel Wagner wrote:
>
> What do you mean by "potential type"? There is no such concept.
>
> The spec  is pretty clear, on the 
> subject, IMO. There is also this blog post 
> .
>
> The gist is: There are boolean, rune, integer, floating, complex and 
> string constants. Each of them can be used as values for different sets of 
> types - for boolean/string constants, the underlying types must be 
> bool/string. For numeric types, the value (roughly, details in the links 
> above) must be representable in the target type. This takes care of all the 
> clearly typed places a constant can appear (e.g. in an expression, a typed 
> const/var-declaration, a conversion…). Where that's not possible (e.g. an 
> untyped const/var-declaration, short variable declaration, when used in an 
> interface{} in an expression…) the default type of the literal (bool, rune, 
> int, float64, complex128 and string respectively) is assumed.
>
> What that means is, that you can use any rune/integer/float/complex 
> literal in any place where any numeric value is used (so anything with 
> underlying type {u,}int*, rune, float{32,64}, complex{64,128}, uintptr)* 
> as long as its value can be represented in the target type*. So, for 
> example this is legal , but this 
> is not .
>
> On Fri, Jan 12, 2018 at 8:07 AM, > wrote:
>
>> or 
>> an untype literal who has a *rune* potential type must also has an *int* 
>> potential type.
>> an untype literal who has an *int* potential type must also has a 
>> *float64* potential type.
>> an untype literal who has a *float64* potential type must also has a 
>> *complex128* potential type.
>>
>>
>> On Friday, January 12, 2018 at 1:34:08 AM UTC-5, di...@veryhaha.com 
>> wrote:
>>>
>>> An untyped rune literal/constant must have a popential int type.
>>> An untyped interger literal/constant must have a popential float64 type.
>>> An untyped floating-point literal/constant must have a popential 
>>> complex128 type.
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[go-nuts] Re: Any plans to add ASN.1 PER support?

[David Wahlstedt]

ASN.1 is still alive and present in telecom applications. The PER encoding 
is missing in the go library, unfortunately...

Den torsdag 11 januari 2018 kl. 20:04:50 UTC+1 skrev Pat Farrell:
>
> On Thursday, January 11, 2018 at 10:50:24 AM UTC-5, David Wahlstedt wrote:
>>
>> I wonder if there are any plans to add PER encoding/decoding support for 
>> ASN.1?
>> I have looked around, and it seems that there isn't any project 
>> supporting this, currently.
>>
>
> Wow, I haven't heard anyone ask for ASN.1 PER or DER in two decades.
> I know it still is listed in the specs, but  ASN.1 was  worse than XML
>

-- 
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] Non-Coherent Caches

[Chris Hopkins]

Hi All,
Does anyone know of an architecture that go runs on that has non-coherent 
data caches? If so, is there a mechanism in the language/tool chain to 
protect against the issues of this?

Background:
I was watching a video on the go trace tool 
(https://www.youtube.com/watch?v=ySy3sR1LFCQ) in this video he uses a 
technique I would never have thought safe. i.e. he declares an array of 
items and then uses a separate go routine on each item in the array. The 
logic making it safe being that each routine operates on a different 
element of the array, therefore no concurrent access.
Then it occurred to me it might not be safe after all. If you have 
Non-Coherent data caches for multiple cores then one cache could load a 
cache line and modify it. At a similar time a different cache does the same 
thing, but to a different address within that cache line. One of them 
evicts the line first, and its modification is overwritten by the last 
cache to have the line modified.

Some digging shows that all the CPU architectures I can find that I can run 
go on have coherent L1 data caches.

However I set out to prove this was safe:
https://play.golang.org/p/igfpqrX8Jc-

Playing with the trace tool implies that this might be because I can't get 
the scheduler to launch multiple routines running at the same time (hence 
adding in the heavyCpu function). Or at least sufficiently concurrent to 
agress this issue.
So it's fine, but it got me wondering if it were fine by accident or 
design. I'm sure there must be architectures out there where global 
coherency across all cores is not maintained, and if there is, I guess the 
scheduler would have to be aware of this - but I don't know how you could 
mitigate this if the example code is legal. If it is not legal, it doesn't 
seem to be detected by the tools.

Anyway thought I would share my ignorance again :-)

Regards

Chris

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

Re: [go-nuts] Re: Is my understanding on numeric literals right?

['Axel Wagner' via golang-nuts]

Hm, this thread has actually opened up a question I don't have a good
answer to.

On Fri, Jan 12, 2018 at 9:47 AM,  wrote:

> then can I say
> an untyped rune literal/constant is representable int type for sure.
>

Yes, rune is an alias for int32 and int is specified to have at least the
precision of an int32.


> an untyped interger literal/constant is representable float64 type for
> sure.
> an untyped floating-point literal/constant is representable complex128
> type for sure.
>

Now, this is where I don't have a good answer. The answer to both of these
is actually "no", but the compiler still allows it.

For example, the integer constant (1<<54)+1 is not representable as a
float64, contradicting the first statement.
Also, the floating-point constant math.Pi is not representable as a float64
and thus can't be represented by a complex128 either (as that has a float64
real part).
In both cases, the compiler rounds to the nearest representable value, but
does not complain. I tried reading in the spec why exactly, but so far I
couldn't.

Let's start with a constant declaration like this:
const x = float64((1<<54)+1)
* 1 and 54 are integer literals
, so they denote untyped
integer constants.
* That makes (1 << 54)+1 a constant expression
, resulting in another
untyped integer constant.
* We then convert that to float64, creating a typed constant; I would
argue, that in this case "The values of typed constants must always be
accurately representable as values of the constant type." *should* apply
(it's where the declaration would fail if, e.g., we'd use int32 instead),
but doesn't, for some reason. I'm not sure why (there is a section in
conversions  which specifies
rounding for floating-point constants; but in this case, we have an
integer-constant).

Another way to do the same thing would be:
const x float64 = (1<<54)+1
* Again, (1<<54)+1 is an untyped integer constant
* This time, we are creating a typed constant declaration
, though, requiring that
"the expressions must be assignable to that type"
* Assignability  of untyped
constants requires, again, that the constant is representable as a T, where
T in our case is float64. Which isn't the case, so, again, this *should*
fail, IMO, but doesn't.

Next, let's look at a declaration like
const x = float64(math.Pi)
* math.Pi is an untyped floating-point constant
* The section on Conversions  allows
a conversion of floating-point constants to a floating-point type, if the
value is representable after rounding. I don't understand the qualification
(because to me, rounding would seem to imply that the value is
representable), but in any case, this would allow for the conversion to
succeed and give the expected outcome.

But if we instead look at
const x float64 = math.Pi
* math.Pi is an untyped floating-point constant
* This time, we are not doing a conversion, but instead directly assign the
value in a constant declaration. That *should* again require the value to
be representable and thus fail.

Notably, the conversion section also talks about non-constant conversions
(and specifies rounding to precision for floats)


Now, the rules, in practice, seem to be equivalent to
1) In the "conversion" section, replace "x is a floating-point constant"
with "x is a non-complex numeric constant"
2) In various places about constants/constant expressions, replace
"representable" with "convertible", allowing them to fall back to the
rounding rule in the conversion section.

But I might also overlook something blatantly obvious that someone more
familiar with the spec can point out.


In either case, in practice, it seems true that
* You can always use an integer/rune-literal as a floating-point constant
(potentially incurring rounding)
* You can always use a floating-point literals as a complex constant
(potentially incurring rounding)
Note, however, that it doesn't matter *what* floating-point/complex
constant it is. I.e. you can also assign any integer-literal to a float32
and any floating-point literal to a complex64 and the compiler will just
round. There seems to be no way to statically assert that a literal is
representable as a floating-point/complex type.



>
> On Friday, January 12, 2018 at 2:42:20 AM UTC-5, Axel Wagner wrote:
>>
>> What do you mean by "potential type"? There is no such concept.
>>
>> The spec  is pretty clear, on the
>> subject, IMO. There is also this blog post
>> .
>>
>> The gist is: There are boolean, rune, integer, floating, complex and
>> string constants. Each of them can be used as values for different sets of
>> types - for boolean/string constants, the underlying types must be
>> bool/string. For nu

[go-nuts] Getting oauth2 token without verifying certificate option

[mdsalman]

Hi, 
I am trying to get the oauth2 token from an internal token provider. I am 
using this to get the oauth2 token- 

package main

import (
  "golang.org/x/oauth2/clientcredentials"
  "golang.org/x/net/context"
  "fmt"
  "golang.org/x/oauth2"
  "crypto/tls"
  "net/http"
)

func main(){

  // this should match whatever service has given you
  // client credential access
  config := clientcredentials.Config{
ClientID: "xx",
ClientSecret: "xx",
TokenURL: "https://10.2.54.203/api/oauth";,
  }

  tr := &http.Transport{
TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
  }


  // you can modify the client (for example ignoring bad certs or otherwise)
  // by modifying the context
  httpClient := &http.Client{Transport:tr}
  ctx := context.Background()
  ctx = context.WithValue(ctx, oauth2.HTTPClient,httpClient)

  tok,err := config.Token(ctx)

   if err != nil{
panic(err)
  }

  fmt.Println(tok)

}
I get the following error - Response: 
{"type":"http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html","title":"invalid_client","status":400,"detail":"The
 
client credentials are invalid"}

But I know that my credentials are correct as I am able to get the access 
token using the curl -k command with the same credentials.

When I use the default HTTP client(without insecure TLS verify set to 
true), I get an error saying no IP is present in the SANS certificate.

Can anyone help me out?


-- 
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 on processor without SSE

[nicolas . repentin]

Hi all

I'm searching how to compile golang to use it on an old 32bits cpu (AMD 
Geode) without SSE.

Any idea?

-- 
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: Is my understanding on numeric literals right?

[digg]

On Friday, January 12, 2018 at 5:11:10 AM UTC-5, Axel Wagner wrote:
>
> Hm, this thread has actually opened up a question I don't have a good 
> answer to.
>
> On Fri, Jan 12, 2018 at 9:47 AM, > wrote:
>
>> then can I say
>> an untyped rune literal/constant is representable int type for sure.
>>
>
> Yes, rune is an alias for int32 and int is specified to have at least the 
> precision of an int32.
>  
>
>> an untyped interger literal/constant is representable float64 type for 
>> sure.
>> an untyped floating-point literal/constant is representable complex128 
>> type for sure.
>>
>
> Now, this is where I don't have a good answer. The answer to both of these 
> is actually "no", but the compiler still allows it.
>
> For example, the integer constant (1<<54)+1 is not representable as a 
> float64, contradicting the first statement.
> Also, the floating-point constant math.Pi is not representable as a 
> float64 and thus can't be represented by a complex128 either (as that has a 
> float64 real part).
> In both cases, the compiler rounds to the nearest representable value, but 
> does not complain. I tried reading in the spec why exactly, but so far I 
> couldn't.
>
> Let's start with a constant declaration like this:
> const x = float64((1<<54)+1)
> * 1 and 54 are integer literals 
> , so they denote untyped 
> integer constants.
> * That makes (1 << 54)+1 a constant expression 
> , resulting in another 
> untyped integer constant.
> * We then convert that to float64, creating a typed constant; I would 
> argue, that in this case "The values of typed constants must always be 
> accurately representable as values of the constant type." *should* apply 
> (it's where the declaration would fail if, e.g., we'd use int32 instead), 
> but doesn't, for some reason. I'm not sure why (there is a section in 
> conversions  which specifies 
> rounding for floating-point constants; but in this case, we have an 
> integer-constant).
>
> Another way to do the same thing would be:
> const x float64 = (1<<54)+1
> * Again, (1<<54)+1 is an untyped integer constant
> * This time, we are creating a typed constant declaration 
> , though, requiring 
> that "the expressions must be assignable to that type"
> * Assignability  of untyped 
> constants requires, again, that the constant is representable as a T, where 
> T in our case is float64. Which isn't the case, so, again, this *should* 
> fail, IMO, but doesn't.
>
> Next, let's look at a declaration like
> const x = float64(math.Pi)
> * math.Pi is an untyped floating-point constant
> * The section on Conversions  allows 
> a conversion of floating-point constants to a floating-point type, if the 
> value is representable after rounding. I don't understand the qualification 
> (because to me, rounding would seem to imply that the value is 
> representable), but in any case, this would allow for the conversion to 
> succeed and give the expected outcome.
>
> But if we instead look at
> const x float64 = math.Pi
> * math.Pi is an untyped floating-point constant
> * This time, we are not doing a conversion, but instead directly assign 
> the value in a constant declaration. That *should* again require the 
> value to be representable and thus fail.
>
> Notably, the conversion section also talks about non-constant conversions 
> (and specifies rounding to precision for floats)
>
>
> Now, the rules, in practice, seem to be equivalent to
> 1) In the "conversion" section, replace "x is a floating-point constant" 
> with "x is a non-complex numeric constant"
> 2) In various places about constants/constant expressions, replace 
> "representable" with "convertible", allowing them to fall back to the 
> rounding rule in the conversion section.
>
> But I might also overlook something blatantly obvious that someone more 
> familiar with the spec can point out.
>
>
> In either case, in practice, it seems true that
> * You can always use an integer/rune-literal as a floating-point constant 
> (potentially incurring rounding)
> * You can always use a floating-point literals as a complex constant 
> (potentially incurring rounding)
> Note, however, that it doesn't matter *what* floating-point/complex 
> constant it is. I.e. you can also assign any integer-literal to a float32 
> and any floating-point literal to a complex64 and the compiler will just 
> round. There seems to be no way to statically assert that a literal is 
> representable as a floating-point/complex type.
>

Thanks for the info again.

It looks not every integer literal can be used as float32

const N = 1 << 128
const F float32 = N // constant 3.40282e+38 overflows float32
 
But I haven't found an integer literal which can't be used as float64.


>
>
>>
>> On 

[go-nuts] Re: How golang garbage collector works

[digg]

https://blog.golang.org/go15gc

On Thursday, January 11, 2018 at 10:50:24 AM UTC-5, golangguy wrote:
>
> Hi 
>
> I am new to golang, and had background in C/C++ , can you some one give me 
> information/explanation about how garbage collectors in golang works ?
>
> 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] how to add items to an array without append function.

[Shawn Milochik]

On Fri, Jan 12, 2018 at 2:11 AM, pradam 
wrote:

> Hi Shawn,
>
> Thank you, it was very helpful. I am not complaining about the language
> just exploring the how golang works.
>
>
Awesome! You're welcome. Sorry I misinterpreted your wording.

-- 
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: Is my understanding on numeric literals right?

[Marvin Renich]

* 'Axel Wagner' via golang-nuts  [180112 05:11]:
> Hm, this thread has actually opened up a question I don't have a good
> answer to.
> 
> On Fri, Jan 12, 2018 at 9:47 AM,  wrote:
> > an untyped interger literal/constant is representable float64 type for
> > sure.
> > an untyped floating-point literal/constant is representable complex128
> > type for sure.
> >
> 
> Now, this is where I don't have a good answer. The answer to both of these
> is actually "no", but the compiler still allows it.
> 
> For example, the integer constant (1<<54)+1 is not representable as a
> float64, contradicting the first statement.
> Also, the floating-point constant math.Pi is not representable as a float64
> and thus can't be represented by a complex128 either (as that has a float64
> real part).
> In both cases, the compiler rounds to the nearest representable value, but
> does not complain. I tried reading in the spec why exactly, but so far I
> couldn't.

Perhaps the following explains the intent (found at
https://golang.org/ref/spec#Constants):

  Implementation restriction: Although numeric constants have arbitrary
  precision in the language, a compiler may implement them using an
  internal representation with limited precision. That said, every
  implementation must:

∙ Represent integer constants with at least 256 bits.
∙ Represent floating-point constants, including the parts of a
  complex constant, with a mantissa of at least 256 bits and a
  signed binary exponent of at least 16 bits.
∙ Give an error if unable to represent an integer constant
  precisely.
∙ Give an error if unable to represent a floating-point or complex
  constant due to overflow.
∙ Round to the nearest representable constant if unable to represent
  a floating-point or complex constant due to limits on precision.

  These requirements apply both to literal constants and to the result
  of evaluating constant expressions. 

It seems that by "representable", when converting to a floating point
type, the spec means "can be rounded to, but must not overflow".  I
think the last bullet makes this explicit (i.e. every implementation
"must"...round to the nearest...).

...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] Non-Coherent Caches

[Ian Lance Taylor]

On Fri, Jan 12, 2018 at 2:03 AM, Chris Hopkins  wrote:
>
> Does anyone know of an architecture that go runs on that has non-coherent
> data caches? If so, is there a mechanism in the language/tool chain to
> protect against the issues of this?
>
> Background:
> I was watching a video on the go trace tool
> (https://www.youtube.com/watch?v=ySy3sR1LFCQ) in this video he uses a
> technique I would never have thought safe. i.e. he declares an array of
> items and then uses a separate go routine on each item in the array. The
> logic making it safe being that each routine operates on a different element
> of the array, therefore no concurrent access.
> Then it occurred to me it might not be safe after all. If you have
> Non-Coherent data caches for multiple cores then one cache could load a
> cache line and modify it. At a similar time a different cache does the same
> thing, but to a different address within that cache line. One of them evicts
> the line first, and its modification is overwritten by the last cache to
> have the line modified.
>
> Some digging shows that all the CPU architectures I can find that I can run
> go on have coherent L1 data caches.
>
> However I set out to prove this was safe:
> https://play.golang.org/p/igfpqrX8Jc-
>
> Playing with the trace tool implies that this might be because I can't get
> the scheduler to launch multiple routines running at the same time (hence
> adding in the heavyCpu function). Or at least sufficiently concurrent to
> agress this issue.
> So it's fine, but it got me wondering if it were fine by accident or design.
> I'm sure there must be architectures out there where global coherency across
> all cores is not maintained, and if there is, I guess the scheduler would
> have to be aware of this - but I don't know how you could mitigate this if
> the example code is legal. If it is not legal, it doesn't seem to be
> detected by the tools.

An incoherent cache would affect far more than the case you describe.
For example, it is straightforward and indeed common for multiple
different global variables to share a single cache line.  This is even
possible if the global variables are defined in different packages.
Yet it is clearly valid for different goroutines to set different
global variables simultaneously.

As far as I know no common processor architecture provides multiple
cores with an incoherent cache, as the programming model for such an
architecture is complex.  If Go is ever ported to such an
architecture, it will have to arrange for every global variable, and
every slice/array element, and every struct field, to live in a
different cache line.  That can be done easily enough by simply
setting the required alignment high enough for each data type.  Of
course this will make the cache somewhat less effective, but, so it
goes.

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] Go on processor without SSE

[Ian Lance Taylor]

On Fri, Jan 12, 2018 at 2:03 AM,   wrote:
>
> I'm searching how to compile golang to use it on an old 32bits cpu (AMD
> Geode) without SSE.
>
> Any idea?

Tell us exactly what you did and exactly how it failed.

Ian

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

Re: [go-nuts] Re: Updating specific elements of a big json file.

[Doğan Kurt]

That seems to be the only solution. Thanks.

On Friday, January 12, 2018 at 12:01:19 AM UTC+1, Burak Serdar wrote:
>
>
>
> On Jan 11, 2018 3:36 PM, "Doğan Kurt" > 
> wrote:
>
> I think i wasn't perfectly clear. When i say update i actually meant 
> insert, delete, update. 
>
> I will delete big blocks of elements, insert new ones and modify some. If 
> i have to deal with the json format, what's the point of using json 
> package. I can write a json tokenizer myself.
>
>
> You can unmarshal the json file to a map[string]interface{}, work on the 
> map, and then marshal it back. 
>
>
> On Thursday, January 11, 2018 at 10:55:36 PM UTC+1, Tamás Gulácsi wrote:
>>
>> Use json.Decoder.Token to walk through the whole file, modifying where 
>> needed, and just printing otherwise.
>
> -- 
> 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] how to add items to an array without append function.

[Marvin Renich]

* pradam  [180112 01:45]:
> I'm Newbie to golang,

Welcome to Go!  Many newbies often use "golang" rather than "Go" as the
language name, and most old-timers usually ignore this incorrect usage,
but golang is an artifact of the web site's hostname, golang.org.  Also,
using golang in web searches for Go language information can help make
the results more specific to the computer language rather than other
uses of "go".  However, in normal conversation, it is correct to use
"Go" for the name of the language.

A very good introduction to Go can be found at the Go Tour
«https://tour.golang.org/».

> var m []int   //array declaration

First, m is a slice of int, not an array of int.  An array is a type
that has a fixed number of elements.  A slice is a view into an array
that can vary in size.  An array would be declared with an explicit
size, as

var a [3]int

A very good explanation of slices and arrays can be found at
«https://blog.golang.org/go-slices-usage-and-internals».

> m = {1,2,3,4,5,6,7} // this throws error

The left side of the assignment above is an attempt to specify a
composite literal.  The correct syntax is

m = []int{1, 2, 3, 4, 5, 6, 7}

In other words, you must specify both the literal's type, []int, and its
value, {1, 2, 3, 4, 5, 6, 7}.  You could do the same for the array a
declared above (note the explicit size in the type; it must match the
size in the original declaration):

a = [3]int{23, 29, 31}

This is described in the language specification at
«https://golang.org/ref/spec#Composite_literals».

The complete language spec is extremely short compared to the specs for
most other computer languages.  Once you have completed the Go Tour and
have played with Go for a little bit, it is probably worth your time to
read the entire spec.

> so I have declared an array which takes only int items,
> 
> so I can append items to it with append function.:
> 
> m = append(m, 1,2,3,4,5,6,7,8,9)
> 
> but I want to insert items without using append function.

Again, the above blog entry about slices should help you understand how
to use slices and arrays more effectively.  The Go language is designed
to make it easier to reason about when memory is being allocated for a
new value than in dynamically typed languages such as Python or
JavaScript.  Because of this, an explicit function call to append is
necessary when appending to a slice might need to allocate a larger
backing array.

I hope this explanation and the above links help you to better
understand this terrific language!

...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] how to add items to an array without append function.

[pradam]

Hi Marvin,

Awesome explanation. I have learnt alot things through your mail.once again
you made my day.

Thank you

On 12-Jan-2018 9:31 PM, "Marvin Renich"  wrote:

> * pradam  [180112 01:45]:
> > I'm Newbie to golang,
>
> Welcome to Go!  Many newbies often use "golang" rather than "Go" as the
> language name, and most old-timers usually ignore this incorrect usage,
> but golang is an artifact of the web site's hostname, golang.org.  Also,
> using golang in web searches for Go language information can help make
> the results more specific to the computer language rather than other
> uses of "go".  However, in normal conversation, it is correct to use
> "Go" for the name of the language.
>
> A very good introduction to Go can be found at the Go Tour
> «https://tour.golang.org/».
>
> > var m []int   //array declaration
>
> First, m is a slice of int, not an array of int.  An array is a type
> that has a fixed number of elements.  A slice is a view into an array
> that can vary in size.  An array would be declared with an explicit
> size, as
>
> var a [3]int
>
> A very good explanation of slices and arrays can be found at
> «https://blog.golang.org/go-slices-usage-and-internals».
>
> > m = {1,2,3,4,5,6,7} // this throws error
>
> The left side of the assignment above is an attempt to specify a
> composite literal.  The correct syntax is
>
> m = []int{1, 2, 3, 4, 5, 6, 7}
>
> In other words, you must specify both the literal's type, []int, and its
> value, {1, 2, 3, 4, 5, 6, 7}.  You could do the same for the array a
> declared above (note the explicit size in the type; it must match the
> size in the original declaration):
>
> a = [3]int{23, 29, 31}
>
> This is described in the language specification at
> «https://golang.org/ref/spec#Composite_literals».
>
> The complete language spec is extremely short compared to the specs for
> most other computer languages.  Once you have completed the Go Tour and
> have played with Go for a little bit, it is probably worth your time to
> read the entire spec.
>
> > so I have declared an array which takes only int items,
> >
> > so I can append items to it with append function.:
> >
> > m = append(m, 1,2,3,4,5,6,7,8,9)
> >
> > but I want to insert items without using append function.
>
> Again, the above blog entry about slices should help you understand how
> to use slices and arrays more effectively.  The Go language is designed
> to make it easier to reason about when memory is being allocated for a
> new value than in dynamically typed languages such as Python or
> JavaScript.  Because of this, an explicit function call to append is
> necessary when appending to a slice might need to allocate a larger
> backing array.
>
> I hope this explanation and the above links help you to better
> understand this terrific language!
>
> ...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.
>

-- 
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: Is my understanding on numeric literals right?

[digg]

On Friday, January 12, 2018 at 9:00:34 AM UTC-5, di...@veryhaha.com wrote:
>
>
>
> On Friday, January 12, 2018 at 5:11:10 AM UTC-5, Axel Wagner wrote:
>>
>> Hm, this thread has actually opened up a question I don't have a good 
>> answer to.
>>
>> On Fri, Jan 12, 2018 at 9:47 AM,  wrote:
>>
>>> then can I say
>>> an untyped rune literal/constant is representable int type for sure.
>>>
>>
>> Yes, rune is an alias for int32 and int is specified to have at least the 
>> precision of an int32.
>>  
>>
>>> an untyped interger literal/constant is representable float64 type for 
>>> sure.
>>> an untyped floating-point literal/constant is representable complex128 
>>> type for sure.
>>>
>>
>> Now, this is where I don't have a good answer. The answer to both of 
>> these is actually "no", but the compiler still allows it.
>>
>> For example, the integer constant (1<<54)+1 is not representable as a 
>> float64, contradicting the first statement.
>> Also, the floating-point constant math.Pi is not representable as a 
>> float64 and thus can't be represented by a complex128 either (as that has a 
>> float64 real part).
>> In both cases, the compiler rounds to the nearest representable value, 
>> but does not complain. I tried reading in the spec why exactly, but so far 
>> I couldn't.
>>
>> Let's start with a constant declaration like this:
>> const x = float64((1<<54)+1)
>> * 1 and 54 are integer literals 
>> , so they denote untyped 
>> integer constants.
>> * That makes (1 << 54)+1 a constant expression 
>> , resulting in another 
>> untyped integer constant.
>> * We then convert that to float64, creating a typed constant; I would 
>> argue, that in this case "The values of typed constants must always be 
>> accurately representable as values of the constant type." *should* apply 
>> (it's where the declaration would fail if, e.g., we'd use int32 instead), 
>> but doesn't, for some reason. I'm not sure why (there is a section in 
>> conversions  which specifies 
>> rounding for floating-point constants; but in this case, we have an 
>> integer-constant).
>>
>> Another way to do the same thing would be:
>> const x float64 = (1<<54)+1
>> * Again, (1<<54)+1 is an untyped integer constant
>> * This time, we are creating a typed constant declaration 
>> , though, requiring 
>> that "the expressions must be assignable to that type"
>> * Assignability  of untyped 
>> constants requires, again, that the constant is representable as a T, where 
>> T in our case is float64. Which isn't the case, so, again, this *should* 
>> fail, IMO, but doesn't.
>>
>> Next, let's look at a declaration like
>> const x = float64(math.Pi)
>> * math.Pi is an untyped floating-point constant
>> * The section on Conversions  
>> allows 
>> a conversion of floating-point constants to a floating-point type, if the 
>> value is representable after rounding. I don't understand the qualification 
>> (because to me, rounding would seem to imply that the value is 
>> representable), but in any case, this would allow for the conversion to 
>> succeed and give the expected outcome.
>>
>> But if we instead look at
>> const x float64 = math.Pi
>> * math.Pi is an untyped floating-point constant
>> * This time, we are not doing a conversion, but instead directly assign 
>> the value in a constant declaration. That *should* again require the 
>> value to be representable and thus fail.
>>
>> Notably, the conversion section also talks about non-constant conversions 
>> (and specifies rounding to precision for floats)
>>
>>
>> Now, the rules, in practice, seem to be equivalent to
>> 1) In the "conversion" section, replace "x is a floating-point constant" 
>> with "x is a non-complex numeric constant"
>> 2) In various places about constants/constant expressions, replace 
>> "representable" with "convertible", allowing them to fall back to the 
>> rounding rule in the conversion section.
>>
>> But I might also overlook something blatantly obvious that someone more 
>> familiar with the spec can point out.
>>
>>
>> In either case, in practice, it seems true that
>> * You can always use an integer/rune-literal as a floating-point constant 
>> (potentially incurring rounding)
>> * You can always use a floating-point literals as a complex constant 
>> (potentially incurring rounding)
>> Note, however, that it doesn't matter *what* floating-point/complex 
>> constant it is. I.e. you can also assign any integer-literal to a float32 
>> and any floating-point literal to a complex64 and the compiler will just 
>> round. There seems to be no way to statically assert that a literal is 
>> representable as a floating-point/complex type.
>>
>
> Thanks for the info again.
>
> It looks not every integer litera

[go-nuts] json array order preserved?

[BigJohn]

Noob question... when I marshal an array into a JSON, is the order of that 
array preserved?

-- 
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] json array order preserved?

[Tamás Gulácsi]

Yes. Except when a coworker added a tricky MarshalJSON method to that type...

-- 
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] Dereferencing a pointer pointer interface value

[Peter Mogensen]

Hi,

I somehow ended up with an interface{} value being a **SomeStruct{}

... and I need to dereference it to an interface{} holding *SomeStruct{}
in a generic way (ie. without knowing about the type SomeStruct)

I'm not at all sure this is good idea or the right way for the specific
code, but out of curiosity, - can this be done in a non-unsafe way?

One would think the result is rather well defined.

In other words,

var x int = 7
xp := &x
xpp := &xp

var i1 interface{} = xpp

var i2 interface{}

i2 := SomeMagicNotSpecificToInt(i1)

yp := i2.(*int)

y := *yp  // y now == 7

/Peter

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

Re: [go-nuts] Dereferencing a pointer pointer interface value

['Axel Wagner' via golang-nuts]

On Fri, Jan 12, 2018 at 6:32 PM, Peter Mogensen  wrote:

> Hi,
>
> I somehow ended up with an interface{} value being a **SomeStruct{}
>
> ... and I need to dereference it to an interface{} holding *SomeStruct{}
> in a generic way (ie. without knowing about the type SomeStruct)
>
> I'm not at all sure this is good idea or the right way for the specific
> code, but out of curiosity, - can this be done in a non-unsafe way?
>

Yes, using reflection. Not using non-reflection, which is WAI. You should
always
* Specialize on specific types, thus knowing them
* Not care what's in the interface
* Reflect to write code that can handle ~anything (e.g. in encoding/json
and the like)


> One would think the result is rather well defined.
>

It's not. The value in the interface doesn't have to be a pointer, so this
is, in general, not defined at all.


>
> In other words,
>
> var x int = 7
> xp := &x
> xpp := &xp
>
> var i1 interface{} = xpp
>
> var i2 interface{}
>
> i2 := SomeMagicNotSpecificToInt(i1)
>
> yp := i2.(*int)
>
> y := *yp  // y now == 7
>
> /Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] Dereferencing a pointer pointer interface value

[Peter Mogensen]

On 2018-01-12 19:09, 'Axel Wagner' via golang-nuts wrote:
> One would think the result is rather well defined.
> 
> 
> It's not. The value in the interface doesn't have to be a pointer, so
> this is, in general, not defined at all.

No, but it's not like you cannot ask about interface{} in general.
I can do a type switch, asking:

func f(i interface{}) int {
  switch t := i.(type) {
  case int:
return t
  default:
 return 0
  }
}


Now I just wondered how to do something like a parameterized version of
that:

func f(i interface{}) o interface{} {
  switch t := i.(type) {
  case **:
 o = *t
  default:
 o = nil
  }
  return
}


When you say "well defined" you refer to that an interface{} can be
anything until you do reflection or type assertion.

When I say "well defined", I speak of whether it's in general is
ambiguous what is meant.

/Peter

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

[go-nuts] json: unmarshal map of structs

[Manlio Perillo]

Hi.

Consider this example:
https://play.golang.org/p/q7oEp40ZCIL

Unmarshal replaces the existing map entry with key "Postgres".
The documentation says:

To unmarshal a JSON object into a map, Unmarshal first establishes a 
map to use.
 If the map is nil, Unmarshal allocates a new map.
 Otherwise Unmarshal reuses the existing map, keeping existing entries.
 Unmarshal then stores key-value pairs from the JSON object into the 
map.
 The map's key type must either be a string, an integer, or implement 
encoding.TextUnmarshaler.

Does the reported behavior conform to the documentation?
Personally, I would have expected the program to not panic.


Thanks
Manlio Perillo

-- 
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] Dereferencing a pointer pointer interface value

['Axel Wagner' via golang-nuts]

On Fri, Jan 12, 2018 at 7:23 PM, Peter Mogensen  wrote:
>
> On 2018-01-12 19:09, 'Axel Wagner' via golang-nuts wrote:
> > One would think the result is rather well defined.
> >
> > It's not. The value in the interface doesn't have to be a pointer, so
> > this is, in general, not defined at all.
>
> No, but it's not like you cannot ask about interface{} in general.
> I can do a type switch, asking:
>

Yes, you can *test* if the dynamic value has a specific type (and extract
it if so). That is not the same as operating on the dynamic value (e.g. by
dereferencing it) *without* knowing its type.


> Now I just wondered how to do something like a parameterized version of
> that:
>

Go does not have parametrically polymorphic types - and even if it had,
there wouldn't be any sensible type you could assume here, given that it's
only known at runtime. There simply is no type that the extracted value
could have. Like, what would the type of t be in your example, in the
** case?

When you say "well defined" you refer to that an interface{} can be
> anything until you do reflection or type assertion.
>
> When I say "well defined", I speak of whether it's in general is
> ambiguous what is meant.


Yes, it is in general ambiguous what is meant.

You *can* generically dereference a pointer, but you have to use
reflection, which is the tool to be used on generic values that you don't
know the type of: https://play.golang.org/p/73lJyOlaIdL

I consider it unlikely that you actually want to do that, though. Unless
you are writing some generic encoder, that can operate on any type. But the
fact that you are asking about doubly-indirect pointer and dereferencing
them one layer deep, seems to suggest that you actually want to use a
specific type because you know what types you can have.

-- 
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: json: unmarshal map of structs

[SlothNinja]

You are unmarshalling into a map[string]interface{}.  Thus, the unmarshal 
function is basically not told what the value should be and thus unmarshals 
the JSON object into a map[string]interface.  If you want the value to be a 
Postgres struct, then config must specify a Postgres value.

See, e.g., https://play.golang.org/p/ER_6AL-PHQr.

Jeff

On Friday, January 12, 2018 at 1:30:10 PM UTC-5, Manlio Perillo wrote:
>
> Hi.
>
> Consider this example:
> https://play.golang.org/p/q7oEp40ZCIL
>
> Unmarshal replaces the existing map entry with key "Postgres".
> The documentation says:
>
> To unmarshal a JSON object into a map, Unmarshal first establishes a 
> map to use.
>  If the map is nil, Unmarshal allocates a new map.
>  Otherwise Unmarshal reuses the existing map, keeping existing entries.
>  Unmarshal then stores key-value pairs from the JSON object into the 
> map.
>  The map's key type must either be a string, an integer, or implement 
> encoding.TextUnmarshaler.
>
> Does the reported behavior conform to the documentation?
> Personally, I would have expected the program to not panic.
>
>
> Thanks
> Manlio Perillo
>

-- 
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: json: unmarshal map of structs

[Manlio Perillo]

Unfortunately that is not possible; it must be map[string]interface{} for 
my code to work correctly.

I easily, hoping there are no bugs, managed to patch gopkg.in/yaml.v2 to 
work as I want, but the code of github.com/naoina/toml and encoding.json 
are more complex:
https://pastebin.com/Arvz0WJB


Thanks
Manlio Perillo

Il giorno venerdì 12 gennaio 2018 22:27:07 UTC+1, SlothNinja ha scritto:
>
> You are unmarshalling into a map[string]interface{}.  Thus, the unmarshal 
> function is basically not told what the value should be and thus unmarshals 
> the JSON object into a map[string]interface.  If you want the value to be a 
> Postgres struct, then config must specify a Postgres value.
>
> See, e.g., https://play.golang.org/p/ER_6AL-PHQr.
>
> Jeff
>
> On Friday, January 12, 2018 at 1:30:10 PM UTC-5, Manlio Perillo wrote:
>>
>> Hi.
>>
>> Consider this example:
>> https://play.golang.org/p/q7oEp40ZCIL
>>
>> Unmarshal replaces the existing map entry with key "Postgres".
>> The documentation says:
>>
>> To unmarshal a JSON object into a map, Unmarshal first establishes a 
>> map to use.
>>  If the map is nil, Unmarshal allocates a new map.
>>  Otherwise Unmarshal reuses the existing map, keeping existing 
>> entries.
>>  Unmarshal then stores key-value pairs from the JSON object into the 
>> map.
>>  The map's key type must either be a string, an integer, or implement 
>> encoding.TextUnmarshaler.
>>
>> Does the reported behavior conform to the documentation?
>> Personally, I would have expected the program to not panic.
>>
>>
>> Thanks
>> Manlio Perillo
>>
>

-- 
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] Dereferencing a pointer pointer interface value

[Peter Mogensen]

On 2018-01-12 22:22, Axel Wagner wrote:
> Yes, you can *test* if the dynamic value has a specific type (and
> extract it if so). That is not the same as operating on the dynamic
> value (e.g. by dereferencing it) *without* knowing its type.

I know I can test the type. But the issue was specifically to
dereference the first pointer while keeping the actual object.
  
> Go does not have parametrically polymorphic types - and even if it had,
> there wouldn't be any sensible type you could assume here, given that
> it's only known at runtime. There simply is no type that the extracted
> value could have. Like, what would the type of t be in your example, in
> the ** case?

It seems we are constantly talking pass each other. There was two
questions here
1) Can it be done in Go as the Go spec is now?
2) Is it in general an ambigious task?

So let's assume we already have answered 1) with "no". (I guess)
It seems you are trying to argue that the answer to 2) is "YES", but
doing it with reference to current Go spec.

I'm perfectly aware that in a case in a type switch like this

switch t := i.(type) {
}

... t needs to have a type in each case clause, and the only type it can
have in lack of a specific type mentioned, is interface{}

But still ... that's an argument for 1) - not for 2)

> Yes, it is in general ambiguous what is meant.

No, I don't think so.

There nothing ambigious about generic operation of turning **T into *T.
The only reason it cannot be done here is because the deference operator
needs to operate on a concrete type and we have an interface{}.

It might not be meaningful to define an actual generic function
mechanism for this, since for the compiler to check the types there is
not much more than the dereferencing which can be done
But it is possible to state this in C++:

template
T *f(T **p) {
return *p;
}

... however, templates are kinda cheating.

... and that was all I was saying by it not being ambiguous.


> You /can/ generically dereference a pointer, but you have to use
> reflection, which is the tool to be used on generic values that you
> don't know the type of: https://play.golang.org/p/73lJyOlaIdL

Ahh... yes... I think I overlooked the Elem() method. It seems it allows
me to make an interface value of *T from an interface containing **T
without knowing the actual type of T.
... so the answer to the question is actually "yes" - that can be done
without unsafe.

> I consider it unlikely that you actually want to do that, though. Unless
> you are writing some generic encoder, that can operate on any type.

That's actually the case - or at least and decoder for now.

> But
> the fact that you are asking about doubly-indirect pointer and
> dereferencing them one layer deep, seems to suggest that you actually
> want to use a specific type because you know what types you can have.

No... If I knew the type, I would have said it.

However... I'm still not sure whether it actually solves what I'm trying
to do. But it did answer the question I posed out of curiosity.

Thanks,

Peter

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

[go-nuts] Re: Go on processor without SSE

[krolaw]

See: https://github.com/golang/go/issues/5266

Essentially, you need to recompile go with:
export GO386=387
export GOOS=linux
export GOARCH=386

Then you can successfully build using the same. (This allowed go to work on 
my Alix board.) Worked for Go 1.1beta, might still work now.

On Saturday, 13 January 2018 02:25:09 UTC+13, Nicolas Repentin wrote:
>
> Hi all
>
> I'm searching how to compile golang to use it on an old 32bits cpu (AMD 
> Geode) without SSE.
>
> Any idea?
>

-- 
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] Dereferencing a pointer pointer interface value

['Axel Wagner' via golang-nuts]

On Fri, Jan 12, 2018 at 11:23 PM, Peter Mogensen  wrote:

>
>
> On 2018-01-12 22:22, Axel Wagner wrote:
> > Yes, you can *test* if the dynamic value has a specific type (and
> > extract it if so). That is not the same as operating on the dynamic
> > value (e.g. by dereferencing it) *without* knowing its type.
>
> I know I can test the type. But the issue was specifically to
> dereference the first pointer while keeping the actual object.
>
> > Go does not have parametrically polymorphic types - and even if it had,
> > there wouldn't be any sensible type you could assume here, given that
> > it's only known at runtime. There simply is no type that the extracted
> > value could have. Like, what would the type of t be in your example, in
> > the ** case?
>
> It seems we are constantly talking pass each other. There was two
> questions here
> 1) Can it be done in Go as the Go spec is now?
> 2) Is it in general an ambigious task?
>
> So let's assume we already have answered 1) with "no". (I guess)
> It seems you are trying to argue that the answer to 2) is "YES", but
> doing it with reference to current Go spec.
>

But the answer to 2 is "no, not in a type-safe way". It necessarily
requires reflection. Even if we'd assume we somehow magically know that the
dynamical value of the interface is some pointer type. That doesn't
actually help us, in any reasonable way. We can dereference it, but we
wouldn't know what the thing it's pointing to is. Or to put it another way:
To dereference a pointer, you'd have to know - at the very least - the size
of the thing it's pointing to. And to do it in a type-safe way, you'd have
to know the *type* of the thing it's pointing to.

Yes, in theory, the compiler an inspect the type-info of the interface, see
that it's a pointer-type and then construct a new interface-value, with
dynamic type "type of the pointee" and dynamic value "pointee" - that's
reflection. I.e. the compiler would emit code for the equivalent of
v := reflect.ValueOf(v).Elem().Interface()
That is the best you can do, but in particular, you don't have any static
information about what the value is you are operating on, so you can't call
any methods on it, you can't dereference it, you can't do… anything with
it, really. Like, you can't actually do any better than what reflection
gives you - and reflection already works.

That's why I say that, if you know the type, use that knowledge to get
static assertions on it. If you don't use reflection. And that is
fundamentally all you can do in a statically typed language.

Your request is essentially equivalent to reflection as a language-feature,
which is essentially equivalent to making Go a dynamically typed language.

I'm perfectly aware that in a case in a type switch like this
>
> switch t := i.(type) {
> }
>
> ... t needs to have a type in each case clause, and the only type it can
> have in lack of a specific type mentioned, is interface{}
>
> But still ... that's an argument for 1) - not for 2)
>
> > Yes, it is in general ambiguous what is meant.
>
> No, I don't think so.
>
> There nothing ambigious about generic operation of turning **T into *T.
> The only reason it cannot be done here is because the deference operator
> needs to operate on a concrete type and we have an interface{}.
>
> It might not be meaningful to define an actual generic function
> mechanism for this, since for the compiler to check the types there is
> not much more than the dereferencing which can be done
> But it is possible to state this in C++:
>
> template
> T *f(T **p) {
> return *p;
> }
>

This is not the same. In the case of this C++ code, the actual type of T is
statically known. In your Go case of getting passed an interface{}, you
have no static information about the type (or rather: You have the
information that it's an interface{} value). This is what I meant when I
said, parametric polymorphism alone wouldn't even help you a priori; unless
it's instantiated at runtime (say, like in Python).

I don't know enough C++ to talk about this competently, but a quick
googling suggests the rough equivalent to Go's interfaces in C++ (in terms
of implementation) are polymorphic objects: Objects that keep dynamic type
info around. And I assume, if you'd actually try to do it using that, you'd
run into similar problems and would end up having to use typeid() - which
is the equivalent to reflection. But yes, as I said, I can't talk
competently about C++.

-- 
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] Dereferencing a pointer pointer interface value

['Axel Wagner' via golang-nuts]

uhm, there is a bit of a mix-up with the yes-vs-no thing and negating. I'm
apparently a bit tired, disregard the actual "no" and focus on the rest of
the reply, explaining why what you want can't be done :)

On Sat, Jan 13, 2018 at 1:35 AM, Axel Wagner 
wrote:

>
>
> On Fri, Jan 12, 2018 at 11:23 PM, Peter Mogensen  wrote:
>
>>
>>
>> On 2018-01-12 22:22, Axel Wagner wrote:
>> > Yes, you can *test* if the dynamic value has a specific type (and
>> > extract it if so). That is not the same as operating on the dynamic
>> > value (e.g. by dereferencing it) *without* knowing its type.
>>
>> I know I can test the type. But the issue was specifically to
>> dereference the first pointer while keeping the actual object.
>>
>> > Go does not have parametrically polymorphic types - and even if it had,
>> > there wouldn't be any sensible type you could assume here, given that
>> > it's only known at runtime. There simply is no type that the extracted
>> > value could have. Like, what would the type of t be in your example, in
>> > the ** case?
>>
>> It seems we are constantly talking pass each other. There was two
>> questions here
>> 1) Can it be done in Go as the Go spec is now?
>> 2) Is it in general an ambigious task?
>>
>> So let's assume we already have answered 1) with "no". (I guess)
>> It seems you are trying to argue that the answer to 2) is "YES", but
>> doing it with reference to current Go spec.
>>
>
> But the answer to 2 is "no, not in a type-safe way". It necessarily
> requires reflection. Even if we'd assume we somehow magically know that the
> dynamical value of the interface is some pointer type. That doesn't
> actually help us, in any reasonable way. We can dereference it, but we
> wouldn't know what the thing it's pointing to is. Or to put it another way:
> To dereference a pointer, you'd have to know - at the very least - the size
> of the thing it's pointing to. And to do it in a type-safe way, you'd have
> to know the *type* of the thing it's pointing to.
>
> Yes, in theory, the compiler an inspect the type-info of the interface,
> see that it's a pointer-type and then construct a new interface-value, with
> dynamic type "type of the pointee" and dynamic value "pointee" - that's
> reflection. I.e. the compiler would emit code for the equivalent of
> v := reflect.ValueOf(v).Elem().Interface()
> That is the best you can do, but in particular, you don't have any static
> information about what the value is you are operating on, so you can't call
> any methods on it, you can't dereference it, you can't do… anything with
> it, really. Like, you can't actually do any better than what reflection
> gives you - and reflection already works.
>
> That's why I say that, if you know the type, use that knowledge to get
> static assertions on it. If you don't use reflection. And that is
> fundamentally all you can do in a statically typed language.
>
> Your request is essentially equivalent to reflection as a
> language-feature, which is essentially equivalent to making Go a
> dynamically typed language.
>
> I'm perfectly aware that in a case in a type switch like this
>>
>> switch t := i.(type) {
>> }
>>
>> ... t needs to have a type in each case clause, and the only type it can
>> have in lack of a specific type mentioned, is interface{}
>>
>> But still ... that's an argument for 1) - not for 2)
>>
>> > Yes, it is in general ambiguous what is meant.
>>
>> No, I don't think so.
>>
>> There nothing ambigious about generic operation of turning **T into *T.
>> The only reason it cannot be done here is because the deference operator
>> needs to operate on a concrete type and we have an interface{}.
>>
>> It might not be meaningful to define an actual generic function
>> mechanism for this, since for the compiler to check the types there is
>> not much more than the dereferencing which can be done
>> But it is possible to state this in C++:
>>
>> template
>> T *f(T **p) {
>> return *p;
>> }
>>
>
> This is not the same. In the case of this C++ code, the actual type of T
> is statically known. In your Go case of getting passed an interface{}, you
> have no static information about the type (or rather: You have the
> information that it's an interface{} value). This is what I meant when I
> said, parametric polymorphism alone wouldn't even help you a priori; unless
> it's instantiated at runtime (say, like in Python).
>
> I don't know enough C++ to talk about this competently, but a quick
> googling suggests the rough equivalent to Go's interfaces in C++ (in terms
> of implementation) are polymorphic objects: Objects that keep dynamic type
> info around. And I assume, if you'd actually try to do it using that, you'd
> run into similar problems and would end up having to use typeid() - which
> is the equivalent to reflection. But yes, as I said, I can't talk
> competently about C++.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group a