[go-nuts] Re: json: cannot unmarshal array into Go struct field data.Members of type main.Members

[Frits van Bommel]

Rename your "slug string" to "Slug string" to make it public so the json 
package can write to it, and make the "Members" field of data a slice:
type Member struct {
Slug string
}
type data struct {
Members []Member
}

On Tuesday, October 9, 2018 at 2:46:02 PM UTC+2, pdbw...@gmail.com wrote:
>
>
> type Members struct {
> slug string `json:"slug"`
> }
> type data struct {
> Members Members //`json:"members"`
> }
>
> func main() {
>
> resp, err := http.Get("
> https://gist.githubusercontent.com/DQIJAO/e14c64ea610688e70228a9fb8c649b2c/raw/6cccd444c1ef65411aa3662b112634996b837414/bnk48.json
> ")
>
> defer resp.Body.Close()
>
> buf := new(bytes.Buffer)
> buf.ReadFrom(resp.Body)
> respByte := buf.Bytes()
> var data data
>
> err = json.Unmarshal(respByte, )
>
> if err != nil {
> fmt.Println(err)
>
> return
> }
>
> log.Println(data)
>
> }
>

-- 
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: allowed imports for go appengine

[Frits van Bommel]

Actually, the standard environment *does* allow (outbound) sockets, but 
with some restrictions (and not via the "net" package). Also, it's still in 
Beta.

The list of restrictions can be found here 
, and the API 
docs are here 
.



On Wednesday, October 3, 2018 at 1:40:33 AM UTC+2, kortschak wrote:
>
> I think that the project lead has decided to move to flex, so the issue 
> has become moot. 
>
> However, it would be nice for there to be some reasonably discoverable 
> documentation for these things. 
>
> The questions I would have had have been answered in what you wrote: we 
> want to have outbound sockets (via net.DialTCP, and in the first pass 
> access to syscall, but in the light of another answer from Ian, this 
> will likely go away). 
>
> thanks 
>
> On Mon, 2018-10-01 at 23:31 -0700, Stanley Iriele wrote: 
> > As mentioned elsewhere on this thread. Appengine flex allows you to 
> > use any  
> > golang package. Appengine standard is a different story. Appengine 
> > standard  
> > has come a long way, but generally speaking you can't use sockets, 
> > syscall,  
> > any package that imports syscall, and you can't make outbound http 
> > requests  
> > with anything other than appengine's urlfetch.  
> > 
> > Keep in mind that appengine standard is designed for stateless 
> > requests.  
> > Any clients you make need to be created per request. Is there a 
> > specific  
> > question that you have aside from general importability? 
> > 
> > On Monday, October 1, 2018 at 4:25:09 PM UTC-7, kortschak wrote: 
> > > 
> > > 
> > > I'd ask this at google-appengine-go, but there does not appear to 
> > > be  
> > > any real traffic to that group; numerous threads have only the 
> > > single  
> > > post that is the question being asked.  
> > > 
> > > The documentation for go appengine is woeful in terms of what is  
> > > allowed and what is not (previously I asked here and there 
> > > regarding  
> > > the requirements for passing `go vet -composites` without clear  
> > > response). Since I doubt I'll get a response there, I'll try my 
> > > luck  
> > > here:  
> > > 
> > > Is there documentation detailing which std packages are 
> > > allowed/banned  
> > > from appengine applications (obviously unsafe, but also net? 
> > > syscall?  
> > > etc?) Alternatively, can people here give a reasonably complete 
> > > list of  
> > > allowed/banned packages?  
> > > 
> > > thanks  
> > > Dan  
> > > 
> > > 
>

-- 
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: When using 'go mod vendor' why are there lots of files missing?

[Frits van Bommel]

 According to the help text that's the intended behavior:

usage: go mod vendor [-v]
>
> Vendor resets the main module's vendor directory to include all packages
> needed to build and test all the main module's packages.
> It does not include test code for vendored packages.
>
> The -v flag causes vendor to print the names of vendored
> modules and packages to standard error.
>

-- 
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: When should a RoundTripper close its connection?

[Frits van Bommel]

The best way is probably to replace the Response.Body before returning the 
result of http.ReadResponse() with an io.ReadCloser that also closes the 
underlying channel.

Replace the end of RoundTrip() with something like this (untested) code:
resp := http.ReadResponse(bufio.NewReader(ch), req)
resp.Body = channelCloser{ resp.Body, ch }
return resp
}

type channelCloser struct {
io.ReadCloser
ch ssh.Channel
}
func (cc *channelCloser) Close() error {
err := cc.ReadCloser.Close()
err2 := cc.ch.Close()
if err == nil {
err = err2
}
return err
}

This way the channel is closed when the body of the response is closed, and 
no sooner.

-- 
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] Returning a JSON object saved as a string in a database

[Frits van Bommel]

On Friday, August 11, 2017 at 6:43:39 AM UTC+2, Dmitriy Cherchenko wrote:
>
> Just to make sure: When marshalling a struct, will fields of 
> type json.RawMessage be ignored (simply inserted into the JSON object 
> without further processing)?
>

There's some *slight* processing:
- a check that it's valid JSON.
- removing insignificant whitespace.
- optionally: the HTML-escaping described in the documentation of 
json.Marshal  unless you're 
using a json.Encoder with this feature disabled.
but all of that's just a single pass over the string representation while 
copying it to the output 
. There's no 
unmarshal+re-marshal step if that's what you're worried about.

Oh, and if you use json.MarshalIndent() or json.Encoder.SetIndent() there's 
a separate indentation pass, but even that's still just string processing.

-- 
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: encoding/json: unexpected behaviour when unmarshalling into struct with interface{} field

[Frits van Bommel]

On Tuesday, May 2, 2017 at 10:53:36 PM UTC+2, Brian Stengaard wrote:
>
>
> On Tuesday, 2 May 2017 16:02:47 UTC-4, Pierre Curto wrote:
>>
>> Hello,
>>
>> My guess:
>> If you dont pass in a pointer, then you pass a value.
>> What would be the point of updating the value that you will never see and 
>> that will get discarded?
>> Hence it returns a map that provides the unmarshaled values so at least 
>> you have something to work with.
>>
>>>
>>>
> True, if I pass in a raw value wrapped in a blank interface. In this case 
> we are talking about a field on a struct that is already addressable - 
> which in turn makes the content of the struct field addressable - then why 
> not just update the underlying value?
>

You can't update a raw value in an interface, you can only replace it. (the 
interface value is addressable, but the value it contains isn't)
It works with pointers because only the data pointed to changes, not the 
pointer itself.

-- 
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] what is the best way to to convert c++ std::string to go string in cgo programing?

[Frits van Bommel]

Please reply to the mailing list (use "reply all").

On Thu, Apr 20, 2017 at 4:39 AM, hui zhang <fastfad...@gmail.com> wrote:

> Thank you , I believe most function will return string  instead of string&
> I  test return string function ,   as expected it return the wrong value
> as the string is invalid out of function.
>
> strdup is easier , thank you.
>
> call GoString(getpath().c_str()) in the CGetPath function
>
> Is that possible ?
>

Please refer to the end of that sentence, which you didn't quote: "but I'm
not familiar enough with cgo to know if that's possible."
(This is why replying to the mailing list is better, someone there might be
more familiar with cgo)



> 2017-04-19 16:40 GMT+08:00 Frits van Bommel <fvbom...@gmail.com>:
>
>> On Wednesday, April 19, 2017 at 9:10:16 AM UTC+2, hui zhang wrote:
>>>
>>> for  1) you mean
>>>>
>>>> char *CGetPath() {
>>>> return getpath().c_str();
>>>>   }
>>>
>>>
>>> this code will work ?
>>>
>>
>> That depends on whether getpath() returns a std::string or a (const)
>> std::string& (a (const) reference). It will work if it returns a reference
>> or const reference, but is not guaranteed to work if it doesn't (though it
>> may appear to do so in some cases, or for some implementations of the C++
>> standard lib) because the standard lib is not required to use a
>> reference-counted dynamic array. For example, it might instead choose to
>> copy the array every time or to allocate small strings using an in-object
>> buffer to avoid the overhead of dynamic allocation, and in both of those
>> cases the return value of c_str() is no longer valid when the function
>> returns.
>>
>> Also, if do you need to copy the string in C++ code:
>> strdup(getpath().c_str()) is better than malloc+strcpy (shorter and harder
>> to get wrong). Case in point: your implementation malloc'ed str.length()
>> bytes, failing to allocate an extra byte for the '\0' at the end.
>> Even better might be to call GoString(getpath().c_str()) in the CGetPath
>> function to ensure only a single copy is made, but I'm not familiar enough
>> with cgo to know if that's possible.
>>
>>
>>
>>> 2017-04-19 14:43 GMT+08:00 Konstantin Khomoutov <
>>> flat...@users.sourceforge.net>:
>>>
>>>> On Wed, 19 Apr 2017 14:23:09 +0800
>>>> hui zhang <fastf...@gmail.com> wrote:
>>>>
>>>> > 1)   getpath()  return a temp string,  its  c_str() pointer will be
>>>> > free out of function. So I use malloc
>>>>
>>>> I'm not completely sure you're correct.  C++ does not implement garbage
>>>> collection and the object on which you have called c_str() continues to
>>>> live on after getpath() returns.  Now let's cite the manual on c_str():
>>>>
>>>> | The pointer obtained from c_str() may be invalidated by:
>>>> | * Passing a non-const reference to the string to any standard library
>>>> |   function, or
>>>> | * Calling non-const member functions on the string, excluding
>>>> |   operator[], at(), front(), back(), begin(), rbegin(), end() and
>>>> |   rend().
>>>>
>>>> So I'd say in the sequence of calls I propose there's no chance of
>>>> anything quoted to happen -- basically the pointer returned by c_str()
>>>> gets passed to Go where C.GoString() copies the memory pointed to by it.
>>>>
>>>> Things may break if you somehow concurrently call into your C++ side
>>>> and those calls may access the same std::string object we're talking
>>>> about.  But if you do this, all bets are already off.
>>>>
>>>> > 2)  Assume we use the malloc way ,  are  C.GoString()   copying the
>>>> > pointer memory ?  for we need C.free() malloc memory.
>>>>
>>>> Yes, C.GoString() copies the memory.
>>>>
>>>> Yes, you always need to free() what was malloc()ed for you -- because
>>>> you own the returned pointer.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/golang-nuts/u7EtqL9SKV4/unsubscribe.
>> To unsubscribe from this group and all its topics, 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] what is the best way to to convert c++ std::string to go string in cgo programing?

[Frits van Bommel]

On Wednesday, April 19, 2017 at 9:10:16 AM UTC+2, hui zhang wrote:
>
> for  1) you mean 
>>
>> char *CGetPath() {
>> return getpath().c_str();
>>   }
>
>
> this code will work ?
>

That depends on whether getpath() returns a std::string or a (const) 
std::string& (a (const) reference). It will work if it returns a reference 
or const reference, but is not guaranteed to work if it doesn't (though it 
may appear to do so in some cases, or for some implementations of the C++ 
standard lib) because the standard lib is not required to use a 
reference-counted dynamic array. For example, it might instead choose to 
copy the array every time or to allocate small strings using an in-object 
buffer to avoid the overhead of dynamic allocation, and in both of those 
cases the return value of c_str() is no longer valid when the function 
returns.

Also, if do you need to copy the string in C++ code: 
strdup(getpath().c_str()) is better than malloc+strcpy (shorter and harder 
to get wrong). Case in point: your implementation malloc'ed str.length() 
bytes, failing to allocate an extra byte for the '\0' at the end.
Even better might be to call GoString(getpath().c_str()) in the CGetPath 
function to ensure only a single copy is made, but I'm not familiar enough 
with cgo to know if that's possible.

 

> 2017-04-19 14:43 GMT+08:00 Konstantin Khomoutov <
> flat...@users.sourceforge.net >:
>
>> On Wed, 19 Apr 2017 14:23:09 +0800
>> hui zhang  wrote:
>>
>> > 1)   getpath()  return a temp string,  its  c_str() pointer will be
>> > free out of function. So I use malloc
>>
>> I'm not completely sure you're correct.  C++ does not implement garbage
>> collection and the object on which you have called c_str() continues to
>> live on after getpath() returns.  Now let's cite the manual on c_str():
>>
>> | The pointer obtained from c_str() may be invalidated by:
>> | * Passing a non-const reference to the string to any standard library
>> |   function, or
>> | * Calling non-const member functions on the string, excluding
>> |   operator[], at(), front(), back(), begin(), rbegin(), end() and
>> |   rend().
>>
>> So I'd say in the sequence of calls I propose there's no chance of
>> anything quoted to happen -- basically the pointer returned by c_str()
>> gets passed to Go where C.GoString() copies the memory pointed to by it.
>>
>> Things may break if you somehow concurrently call into your C++ side
>> and those calls may access the same std::string object we're talking
>> about.  But if you do this, all bets are already off.
>>
>> > 2)  Assume we use the malloc way ,  are  C.GoString()   copying the
>> > pointer memory ?  for we need C.free() malloc memory.
>>
>> Yes, C.GoString() copies the memory.
>>
>> Yes, you always need to free() what was malloc()ed for you -- because
>> you own the returned pointer.
>>
>
>

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