[go-nuts] Update Mongodb fields with omitempty flag in Golang structure
Hi
I am working on a Coupon form in which I have some optional fields.
*Introduction:*
All the form field values are received as JSON and mapped into a Golang
structure. In the structure, I have added an "omitempty" flag with every
field. So only those form values are mapped which have some appropriate
value, rest of the values like 0, " ", false are ignored by the structure.
Here is the Golang structure
type Coupon struct {
Id int`json:"id,omitempty" bson:"_id,omitempty"`
Name string `json:"name,omitempty" bson:"name,omitempty"`
Code string `json:"code,omitempty" bson:"code,omitempty"`
Description string `json:"description,omitempty"
bson:"description,omitempty"`
Status bool `json:"status" bson:"status"`
MaxUsageLimitint`json:"max_usage_limit,omitempty"
bson:"max_usage_limit,omitempty"`
SingleUsePerUser bool `json:"single_use_per_user,omitempty"
bson:"single_use_per_user,omitempty"`}
*Problem:*
1.
When I save this form for the very first time, the form values that are
appropriate are saved into the Mongodb.
2.
Now I want to update that form and suppose there is a check box, which
was checked at the time of saving data. While updating form, the checkbox
is unchecked and form is submitted to save. Now as I have applied
"omitempty" flag in the structure, so its not mapping the empty value to
the checkbox field. Since the value is not mapped into the structure, its
not getting saved into the Database.
3.
When a user edits the form for the second time, it sees the same check
box as checked. (But practically, the value should be updated to the DB and
the check box should be displayed as unchecked.)
4.
I am using the same form data (in JSON format) in a REST API. In API,
while updating form data, if I mention only those values which are required
and don't pass the values which I don't want to update, then MongoDB is
overriding the whole document with the provided required values(Even those
values are also being overridden which I don't want to update as well as
don't pass in the API).
*Requirement:*
In future, I want to expose the REST API, So I don't want this thing to be
happened there. That is why I don't want to remove "omitempty" flag from
the structure fields.
Is there any way to save the empty form values or API data fields to the DB
while using omitempty flag in the structure?
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: A way to detect closed channel
Also since nobody else mentioned it, for completeness: the optional second argument to the receive will always tell you if the channel is already closed, if all you are doing is trying to distinguish the zero value from a closed versus unclosed channel. https://golang.org/ref/spec#Receive_operator -- 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: A way to detect closed channel
As others pointed out, you need to use a lock if you want to close a channel from multiple, possibly concurrent, code locations. Here is an example of how I handle such situations: https://github.com/glycerine/idem/blob/master/halter.go#L11 Feel free to use that library, or parts of it. In short, if you want an idempotent close, you have to replace close() with your own Close(). Meta comment: it was, in my view, a poor design decision in Go (not to allow multiple closes of a channel). For backwards compatibility reasons we are stuck with it now. Its a wart/minor annoyance in the grand scheme of things. Fortunately, the workarounds, while elaborate and slow, are very rarely on hot code paths. On Monday, November 6, 2017 at 6:59:51 PM UTC-6, Albert Tedja wrote: > > So, I just found out that closed channels always yield the zero value. > That means, a closed channel inside a select statement seems to always be > guaranteed to be executed. > > Since closing an already closed channel creates a panic, does this mean > then I can do this to make sure that the channel is closed only once? > -- 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] gccgo programs use which garbage collector?
Just a general question about the binaries produced by gccgo. To wit: Do these binaries use the same garbage collector as gc-produced binaries -- the highly-tuned/low-latency garbage collector that Rick and Austin work on -- or do they use something else? If else, what is used? 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: Announcing: Skylark in Go
Like Nate mentioned, I too like to try it instead of lua. Is there a good example on how to embed skylark to define custom logic. Thanks. On Monday, October 2, 2017 at 12:39:43 PM UTC-4, Alan Donovan wrote: > > I'm pleased to announce the launch of Skylark in Go: an interpreter for > Skylark, implemented in Go. > > github.com/google/skylark > > Skylark is a dialect of Python intended for use as a configuration > language. Like Python, it is an untyped dynamic language with high-level > data types, first-class functions with lexical scope, and garbage > collection. Unlike CPython, independent Skylark threads execute in > parallel, so Skylark workloads scale well on parallel machines. Skylark is > a small and simple language with a familiar and highly readable syntax. You > can use it as an expressive notation for structured data, defining > functions to eliminate repetition, or you can use it to add scripting > capabilities to an existing application. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] newbie trying unusual sort
You could define multiple types:
type bySubtotal []directory
type byName []directory
which have different Sort methods.
You could also define a type that includes a func(d0, d1 directory)
bool. The SortKeys example in the sort package docs
(https://golang.org/pkg/sort/#example__sortMultiKeys) covers this.
Personally, these days, I'd use sort.Slice and use it with two
different comparison functions.
On Tue, Nov 7, 2017 at 5:38 PM, rob wrote:
> Hi. I am trying to sort a slice of a struct using one of two different
> fields.
>
> type directory struct {
> name string
> subtotal int64
> }
>
> type dirslice []directory
>
> I want to sort a var of type dirslice by either name or subtotal. I
> understand how to sort by one of those, by defining
>
> func (ds dirslice) Less(i, j int) bool {
> return ds[i].subtotal < ds[j].subtotal
> }
>
> func (ds dirslice) Swap(i, j int) {
> ds[i], ds[j] = ds[j], ds[i]
> }
>
> func (ds dirslice) Len() int {
> return len(ds)
> }
>
> But I'm struggling w/ how to have a method that can use a different version
> of Swap, depending upon what I want.
>
> thanks,
>
> Rob Solomon
>
> --
> 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] newbie trying unusual sort
Look at the "Example (SortKeys)" part of https://golang.org/pkg/sort/
-rob
On Wed, Nov 8, 2017 at 12:38 PM, rob wrote:
> Hi. I am trying to sort a slice of a struct using one of two different
> fields.
>
> type directory struct {
> name string
> subtotal int64
> }
>
> type dirslice []directory
>
> I want to sort a var of type dirslice by either name or subtotal. I
> understand how to sort by one of those, by defining
>
> func (ds dirslice) Less(i, j int) bool {
> return ds[i].subtotal < ds[j].subtotal
> }
>
> func (ds dirslice) Swap(i, j int) {
> ds[i], ds[j] = ds[j], ds[i]
> }
>
> func (ds dirslice) Len() int {
> return len(ds)
> }
>
> But I'm struggling w/ how to have a method that can use a different
> version of Swap, depending upon what I want.
>
> thanks,
>
> Rob Solomon
>
> --
> 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] newbie trying unusual sort
Hi. I am trying to sort a slice of a struct using one of two different
fields.
type directory struct {
name string
subtotal int64
}
type dirslice []directory
I want to sort a var of type dirslice by either name or subtotal. I
understand how to sort by one of those, by defining
func (ds dirslice) Less(i, j int) bool {
return ds[i].subtotal < ds[j].subtotal
}
func (ds dirslice) Swap(i, j int) {
ds[i], ds[j] = ds[j], ds[i]
}
func (ds dirslice) Len() int {
return len(ds)
}
But I'm struggling w/ how to have a method that can use a different
version of Swap, depending upon what I want.
thanks,
Rob Solomon
--
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: Announcing: Skylark in Go
On 7 November 2017 at 15:54, Zellyn Hunter wrote: > Oh neat. So is it a sort of competitor to jsonnet? I guess jsonnet is > usually used to generate actual config files, not live-interpret executable > config. > Jsonnet is more of a templating language whereas Skylark is really arbitrary computation used to build data structures and express policy or behavior. Sorry if that's vague. Bazel is (unsurprisingly) a good example of Skylark: a build dependency graph consists of thousands of nodes, and for each node, Bazel executes, in parallel, a Skylark function to figure out what compile commands need to be executed for it. Fun fact: Dave (who developed Jsonnet) works down the corridor. There are at least three configuration languages developed from this one room. If nothing else it suggests we need smaller offices. -- 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: Announcing: Skylark in Go
Oh neat. So is it a sort of competitor to jsonnet? I guess jsonnet is usually used to generate actual config files, not live-interpret executable config. Zellyn On Tue, Nov 7, 2017 at 3:46 PM Alan Donovan wrote: > On 7 November 2017 at 15:36, Zellyn wrote: > >> An only-2x-slower than CPython interpreter is pretty cool. Just very >> curious what y'all are doing with it. >> > > Various infrastructure projects (such as Copybara) are using Skylark as a > configuration language since it has proven itself on a large scale within > Bazel, is familiar to everyone at Google, and is pretty rational for a > configuration language. Some of those projects use Go, or would use Go if > only it had an implementation of Skylark. > > -- 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: Announcing: Skylark in Go
On 7 November 2017 at 15:36, Zellyn wrote: > An only-2x-slower than CPython interpreter is pretty cool. Just very > curious what y'all are doing with it. > Various infrastructure projects (such as Copybara) are using Skylark as a configuration language since it has proven itself on a large scale within Bazel, is familiar to everyone at Google, and is pretty rational for a configuration language. Some of those projects use Go, or would use Go if only it had an implementation of Skylark. -- 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: Announcing: Skylark in Go
Bump, since y'all seem to be actively posting here :-) An only-2x-slower than CPython interpreter is pretty cool. Just very curious what y'all are doing with it. On Thursday, November 2, 2017 at 3:22:44 PM UTC-4, Zellyn wrote: > > This looks neat. Are you able to provide more context on what this is/will > be used for at Google? > -- 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: Announcing: Skylark in Go
On Tue, Nov 7, 2017 at 3:16 PM, Alan Donovan wrote: > On 7 November 2017 at 15:06, Ben Hoyt wrote: > >> >> 2x as fast as CPython sounds pretty good to me -- nice! >>> > No, CPython is 2x as fast as Skylark in Go. It's implemented in C, so it > can do things that are sadly impossible in Go, like implement a threaded > bytecode interpreter. > Sorry, I actually grokked what you said but then repeated it incorrectly. I meant to say: half as fast as CPython sounds pretty good. I'm curious why you wrote the dict implementation from scratch >> (hashtable.go) instead of using Go maps as a base, and adding a secondary >> data structure (slice of keys?) to keep track of insertion order? I'm >> presuming there's a good technical reason, but at first glance it seems >> like it would be faster and simpler to use Go maps to start with. >> > > There are many reasons Go maps would not work. First, they do not allow > you to define the hash function and equivalence relation for keys. Skylark > considers 1.0 == 1, for instance, whereas Go does not; also. Second, Go > maps require that keys be comparable, but Skylark tuples are represented as > slices, for example. Third, Go maps have non-deterministic iteration order > whereas Skylark maps are ordered by insertion. You could maintain a > separate slice of keys for the iteration order, but at that point you're > halfway to building you're own hash table. > > Why should Go maps be faster? Go's map is implemented in Go. There's no > reason a different implementation should be equally fast, or perhaps even > faster. The basic design of the Skylark-in-Go hash table is actually very > similar to Go's map. > Thanks for the thorough response, that's really helpful. I hadn't yet realized that Go maps don't allow you to define the hash / equality functions. And good point about Go's map also being implemented in Go too. I'm a lot more familiar with CPython internals, and was kind of assuming Go maps were written in C+asm, but it looks like the entire runtime is written in Go now (with a bit of assembly). -Ben -- 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: Announcing: Skylark in Go
On 7 November 2017 at 15:06, Ben Hoyt wrote: > > 2x as fast as CPython sounds pretty good to me -- nice! >>> >> No, CPython is 2x as fast as Skylark in Go. It's implemented in C, so it can do things that are sadly impossible in Go, like implement a threaded bytecode interpreter. I'm curious why you wrote the dict implementation from scratch > (hashtable.go) instead of using Go maps as a base, and adding a secondary > data structure (slice of keys?) to keep track of insertion order? I'm > presuming there's a good technical reason, but at first glance it seems > like it would be faster and simpler to use Go maps to start with. > There are many reasons Go maps would not work. First, they do not allow you to define the hash function and equivalence relation for keys. Skylark considers 1.0 == 1, for instance, whereas Go does not; also. Second, Go maps require that keys be comparable, but Skylark tuples are represented as slices, for example. Third, Go maps have non-deterministic iteration order whereas Skylark maps are ordered by insertion. You could maintain a separate slice of keys for the iteration order, but at that point you're halfway to building you're own hash table. Why should Go maps be faster? Go's map is implemented in Go. There's no reason a different implementation should be equally fast, or perhaps even faster. The basic design of the Skylark-in-Go hash table is actually very similar to Go's map. -- 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: Announcing: Skylark in Go
> On Thursday, November 2, 2017 at 9:42:27 PM UTC-4, Ben Hoyt wrote: >>> >>> I'm very curious how the performance of Skylark in Go compares to >>> Skylark in Java (and CPython 3.6 for that matter) -- any benchmarks on that? >>> >> > I don't have any rigorous comparisons, but my informal testing on a number > of small benchmarks suggests that CPython is about 2x faster than Skylark > in Go (in a single thread), and that Skylark in Go is about 10x faster than > Skylark in Java > 2x as fast as CPython sounds pretty good to me -- nice! I'm curious why you wrote the dict implementation from scratch (hashtable.go) instead of using Go maps as a base, and adding a secondary data structure (slice of keys?) to keep track of insertion order? I'm presuming there's a good technical reason, but at first glance it seems like it would be faster and simpler to use Go maps to start with. -Ben -- 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: Announcing: Skylark in Go
On Saturday, 4 November 2017 11:52:05 UTC-4, Keith Brown wrote: > > Are there any native golang tools simar to this which work on > Windows/Linux/OSX? > The Skylark interpreter doesn't make any particular assumptions about the CPU or OS, so it should be highly portable. Please file an issue if you find otherwise. On Thursday, November 2, 2017 at 9:42:27 PM UTC-4, Ben Hoyt wrote: >> >> I'm very curious how the performance of Skylark in Go compares to Skylark >> in Java (and CPython 3.6 for that matter) -- any benchmarks on that? >> > I don't have any rigorous comparisons, but my informal testing on a number of small benchmarks suggests that CPython is about 2x faster than Skylark in Go (in a single thread), and that Skylark in Go is about 10x faster than Skylark in Java. > -- 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: Short Term DSN for database/sql
Go1.10 will ship with a driver connector https://tip.golang.org/pkg/database/sql/driver/#Connector . It would be possible for a driver to provide a callback function that returned the most recent authentication parameters by using that. Thanks, -Daniel On Tuesday, November 7, 2017 at 5:34:20 AM UTC-8, Anthony Gruetzmacher wrote: > > It appears the Generic Interface for SQL (database/sql) does not support > the ability to use short lived DSN's for cases like AWS's IAM > Authentication to RDS instances. It appears that when doing its connection > pooling activities it always uses whatever DSN was passed initially on Open. > > 1) Is this correct. > 2) Assuming one is correct would the Golang project every consider adding > this feature? > 3) If the answer is yes. How would one go about either helping to get it > on the road map or better yet contributing this feature back to the > community? What is this process? > > Thanks, > Anthony Gruetzmacher > -- 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] Short Term DSN for database/sql
This does not help because if there is no connection in the connection pool the interface will open a new connection with previously supplied DSN from the sql.Open call. Anthony On Tuesday, November 7, 2017 at 7:22:00 AM UTC-8, Konstantin Khomoutov wrote: > > On Tue, Nov 07, 2017 at 12:06:27AM -0800, agru...@gmail.com > wrote: > > > It appears the Generic Interface for SQL (database/sql) does not support > > the ability to use short lived DSN's for cases like AWS's IAM > > Authentication to RDS instances. It appears that when doing its > connection > > pooling activities it always uses whatever DSN was passed initially on > Open. > > > > 1) Is this correct. > > 2) Assuming one is correct would the Golang project every consider > adding > > this feature? > > 3) If the answer is yes. How would one go about either helping to get it > on > > the road map or better yet contributing this feature back to the > community? > > What is this process? > > Does setting the maximum number of the idle (that is, pooled) database > connections [1] to a value equal or less than zero helps with this? > > 1. https://golang.org/pkg/database/sql/#DB.SetMaxIdleConns > > -- 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] XML Parsing Nested Elements
Thank you for the incredibly detailed response. It has really helped to
understand the situation.
I actually started with an iterative approach with a Decoder object and
this got very complex, very quickly. It worked but the code was unworkable
going forwards. I thought it might be worth trying this approach with an
Unmarshaller.
I didn't think of ignoring the namespace prefixes. You are right and after
checking over the definitions there are no conflicting names at all so this
works well.
Once again many thanks, the detailed write up I'm sure will help others.
On Tuesday, November 7, 2017 at 4:07:02 PM UTC, Konstantin Khomoutov wrote:
>
> On Tue, Nov 07, 2017 at 03:35:45AM -0800, les...@gmail.com
> wrote:
> > I am really struggling to access nested elements of an XML string and
> > suspect it is down to the namespaces. This string is obtained from a
> > larger document and is the "innerXML" of some elements. A simplified
> > version is at...
> >
> > I could probably do this with multiple structs but want to have this in
> a
> > single struct.
> >
> > https://play.golang.org/p/Een-guMNP9
> >
> > I can seem to read things at the root but cannot get them using the ">"
> > syntax at all. What am I doing wrong? Can I "insert" a namespace
> element
> > to assist it at all?
> >
> > I have manually removed the namespaces from this example to show what I
> > think should happen!?
> > https://play.golang.org/p/eCzbzgBYMq
>
> The chief problem with your approach is lack of error checking.
> The encoding/xml.Unmarshal() function returns an error value.
> Had you checked it for being set (not nil), it would have given you an
> immediate idea of what was wrong with your approach.
>
> Regarding namespaces, your hunch is correct: since your XML document is
> a fragment extracted from another document by a seemingly "textual"
> method, all those "XML namespace prefixes" — parts in the names of the
> elements which come before the ':' characters — have no meaning to the
> XML parser since they are not defined in the document itself.
>
> Unfortunately, currently there's no way to somehow explicitly define
> them anywhere (say, in an instance of encoding/xml.Decoder) before
> decoding, so you basically have three options:
>
> - Somehow textually stick their definition on the top element of your
> XML document fragrems, so, say, it reads something like
>
> xmlns:nxcm="http://example.com/another/namespace/uri/";
> ...>
>
> …and then parse the resulting document into a value of a struct
> type the tags on whose fields contain full namespaces in the names
> of the XML elements they're supposed to decode.
>
> - Use iterative approach by creating an instance of encoding/xml.Decoder
> and calling its Token() method.
>
> When it returns a token of the types StartElement or EndElement,
> their Name property can be examined to see what its "Space" and
> "Local" fields are.
>
> - Ignore the XML namespace prefixes completely.
>
> In your case this appears to be the simplest solution as the
> names of the elements appear to be unique anyway.
>
> The variant which checks for errors, ignores the XML namespace prefixes
> and also defines the field named "XMLName" on the type to check the
> name of the element it's supposed to unmarshal can be implemented
> as follows:
>
> 8<
> package main
>
> import (
> "encoding/xml"
> "log"
> )
>
> type TrackInformation struct {
> XMLName struct{} `xml:"trackInformation"`
>
> TimeAtPosition string `xml:"timeAtPosition"`
> Speed int`xml:"speed"`
>
> DepApt string
> `xml:"qualifiedAircraftId>departurePoint>airport"`
> ArrApt string `xml:"qualifiedAircraftId>arrivalPoint>airport"`
> Gufi string `xml:"qualifiedAircraftId>gufi"`
> }
>
> func main() {
>
> xmlToParse := `
>
>
> TEST
> KR32642300
>
> KJFK
>
>
> KJFK
>
>
> 245
>
> 2017-11-07T11:20:43Z
> `
>
> var trackInfo TrackInformation
> err := xml.Unmarshal([]byte(xmlToParse), &trackInfo)
> if err != nil {
> log.Fatal(err)
> }
> log.Println(trackInfo)
> }
> 8<
>
> Playground [1].
>
>
> A couple of more notes.
>
> - You can't use namespaces when defining the names of the nested
> elements. The wording of the documentation is a bit moot but it does
> explicitly state this: «If the
Re: [go-nuts] XML Parsing Nested Elements
On Tue, Nov 07, 2017 at 03:35:45AM -0800, lesm...@gmail.com wrote:
> I am really struggling to access nested elements of an XML string and
> suspect it is down to the namespaces. This string is obtained from a
> larger document and is the "innerXML" of some elements. A simplified
> version is at...
>
> I could probably do this with multiple structs but want to have this in a
> single struct.
>
> https://play.golang.org/p/Een-guMNP9
>
> I can seem to read things at the root but cannot get them using the ">"
> syntax at all. What am I doing wrong? Can I "insert" a namespace element
> to assist it at all?
>
> I have manually removed the namespaces from this example to show what I
> think should happen!?
> https://play.golang.org/p/eCzbzgBYMq
The chief problem with your approach is lack of error checking.
The encoding/xml.Unmarshal() function returns an error value.
Had you checked it for being set (not nil), it would have given you an
immediate idea of what was wrong with your approach.
Regarding namespaces, your hunch is correct: since your XML document is
a fragment extracted from another document by a seemingly "textual"
method, all those "XML namespace prefixes" — parts in the names of the
elements which come before the ':' characters — have no meaning to the
XML parser since they are not defined in the document itself.
Unfortunately, currently there's no way to somehow explicitly define
them anywhere (say, in an instance of encoding/xml.Decoder) before
decoding, so you basically have three options:
- Somehow textually stick their definition on the top element of your
XML document fragrems, so, say, it reads something like
http://example.com/another/namespace/uri/";
...>
…and then parse the resulting document into a value of a struct
type the tags on whose fields contain full namespaces in the names
of the XML elements they're supposed to decode.
- Use iterative approach by creating an instance of encoding/xml.Decoder
and calling its Token() method.
When it returns a token of the types StartElement or EndElement,
their Name property can be examined to see what its "Space" and
"Local" fields are.
- Ignore the XML namespace prefixes completely.
In your case this appears to be the simplest solution as the
names of the elements appear to be unique anyway.
The variant which checks for errors, ignores the XML namespace prefixes
and also defines the field named "XMLName" on the type to check the
name of the element it's supposed to unmarshal can be implemented
as follows:
8<
package main
import (
"encoding/xml"
"log"
)
type TrackInformation struct {
XMLName struct{} `xml:"trackInformation"`
TimeAtPosition string `xml:"timeAtPosition"`
Speed int`xml:"speed"`
DepApt string `xml:"qualifiedAircraftId>departurePoint>airport"`
ArrApt string `xml:"qualifiedAircraftId>arrivalPoint>airport"`
Gufi string `xml:"qualifiedAircraftId>gufi"`
}
func main() {
xmlToParse := `
TEST
KR32642300
KJFK
KJFK
245
2017-11-07T11:20:43Z
`
var trackInfo TrackInformation
err := xml.Unmarshal([]byte(xmlToParse), &trackInfo)
if err != nil {
log.Fatal(err)
}
log.Println(trackInfo)
}
8<
Playground [1].
A couple of more notes.
- You can't use namespaces when defining the names of the nested
elements. The wording of the documentation is a bit moot but it does
explicitly state this: «If the XML element contains a sub-element
whose name matches the prefix of a tag formatted as "a" or "a>b>c"…» —
notice that "the prefix of a tag" bit which actually means "the local
name of an element".
So when you need to match on full names of the elements, you'd have to
use nested structs so that each field stands for an element without
nesting, and the nesting is defined via your types rather than
tags on their fields.
- The XML decoder implements a "strict" mode, which is "on" by default.
What's interesting about it is that even when it's on, it turns a
blind eye on undefined XML namespace prefixes: «Strict mode does not
enforce the requirements of the XML name spaces TR. In particular it
does not reject name space tags using undefined prefixes. Such tags
are recorded with the unknown prefix as the name space URL.»
This means that you can use your undefined namespace prefixes "as is"
when decoding. [2] demonstrates this approach applied to the top-level
XML elements. You can't do this for that "a>b>c" notation in the tags
but you still can apply
Re: [go-nuts] Re: who does go compiler link executable to glibc without an apparent reason?
On Tue, Nov 7, 2017 at 1:28 AM, Howard Guo wrote: > Just noticed this statement from src/net/net.go: > > -- > On Unix systems, the resolver has two options for resolving names. > It can use a pure Go resolver that sends DNS requests directly to the > servers > listed in /etc/resolv.conf, or it can use a cgo-based resolver that calls C > library routines such as getaddrinfo and getnameinfo. > - > > However, using its recommended method to force usage of Go resolver still > results in a dynamic binary: > > export GODEBUG=netdns=go Setting the GODEBUG environment variable changes the behavior at run time. It does not affect how the program is built. As you've seen setting CGO_ENABLED=0 is a quick way to ensure that you get a static binary with no C code. But this does mean that the os/user package, and less frequently the net package, will not behave correctly in certain environments. If you are running in a Docker container or otherwise constrained environment this does not matter. 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] Short Term DSN for database/sql
On Tue, Nov 07, 2017 at 12:06:27AM -0800, agruet...@gmail.com wrote: > It appears the Generic Interface for SQL (database/sql) does not support > the ability to use short lived DSN's for cases like AWS's IAM > Authentication to RDS instances. It appears that when doing its connection > pooling activities it always uses whatever DSN was passed initially on Open. > > 1) Is this correct. > 2) Assuming one is correct would the Golang project every consider adding > this feature? > 3) If the answer is yes. How would one go about either helping to get it on > the road map or better yet contributing this feature back to the community? > What is this process? Does setting the maximum number of the idle (that is, pooled) database connections [1] to a value equal or less than zero helps with this? 1. https://golang.org/pkg/database/sql/#DB.SetMaxIdleConns -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] A way to detect closed channel
Instead of recover, I'd consider simply writing to the channel.
https://play.golang.org/p/ShoadwrwTQ
If it has to be a close, pass in additional state to close only once.
https://play.golang.org/p/pwO3JF60Cr
On Tue, Nov 7, 2017 at 3:32 AM roger peppe wrote:
> On 7 November 2017 at 00:59, Albert Tedja wrote:
> > So, I just found out that closed channels always yield the zero value.
> That
> > means, a closed channel inside a select statement seems to always be
> > guaranteed to be executed.
> >
> > Since closing an already closed channel creates a panic, does this mean
> then
> > I can do this to make sure that the channel is closed only once?
> >
> >
> > select {
> > case <- closedchan:
> > default:
> > close(closedchan)
> > }
>
> You can do that if you wrap it in a mutex so that nothing else
> can be doing the same thing at the same time. That's
> a common workaround for the fact that sometimes you want
> to be able to close a signal-only channel (chan struct{}) from
> a Close method that might be called multiple times.
>
> Another possibility might be to do this:
>
> func closeChan(c chan struct{}) {
> defer func() {
> // Catch the panic from closing an already-closed channel.
> recover()
> }()
> close(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.
>
--
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] graceful restart of app with more than one tcp Listener
On 2017-11-07 15:28, Vasiliy Tolstov wrote: > I know about it, but > https://github.com/rcrowley/goagain/issues/12 cant handle multiple listeners > https://godoc.org/github.com/facebookgo/grace/gracenet does not > support close the listener > https://github.com/fvbock/endless works with http , but i don't need > http server. https://github.com/One-com/gone More specifically: https://github.com/One-com/gone/daemon https://github.com/One-com/gone/sd Docs for some of this could use an overhaul. /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] graceful restart of app with more than one tcp Listener
2017-11-07 17:20 GMT+03:00 Steven Hartland : > There are a number of libraries which attempt to address this, ones I've > seen: > > https://github.com/fvbock/endless > https://github.com/rcrowley/goagain > https://github.com/facebookgo/grace > > I know about it, but https://github.com/rcrowley/goagain/issues/12 cant handle multiple listeners https://godoc.org/github.com/facebookgo/grace/gracenet does not support close the listener https://github.com/fvbock/endless works with http , but i don't need http server. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- 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] graceful restart of app with more than one tcp Listener
There are a number of libraries which attempt to address this, ones I've seen: * https://github.com/fvbock/endless * https://github.com/rcrowley/goagain * https://github.com/facebookgo/grace On 07/11/2017 13:33, Vasiliy Tolstov wrote: Hi! I have application that listens 2-4 tcp ports and i need to upgrade it while running. How can upgrade server and not dropping exiting connected apps (tcp nbd-client like apps)? I don't want to use haproxy or nginx before my app. As i understand i need master process that only listens sockets and fork child app and pass to it accepted connections. So i can upgrade by passing listening fd to new master process and forward new tcp connections to new child? But what can i do with already connected clients to previous child process? Does it possible to do what i need and not dropping exiting tcp connections? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] graceful restart of app with more than one tcp Listener
Hi! I have application that listens 2-4 tcp ports and i need to upgrade it while running. How can upgrade server and not dropping exiting connected apps (tcp nbd-client like apps)? I don't want to use haproxy or nginx before my app. As i understand i need master process that only listens sockets and fork child app and pass to it accepted connections. So i can upgrade by passing listening fd to new master process and forward new tcp connections to new child? But what can i do with already connected clients to previous child process? Does it possible to do what i need and not dropping exiting tcp connections? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- 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] Short Term DSN for database/sql
It appears the Generic Interface for SQL (database/sql) does not support the ability to use short lived DSN's for cases like AWS's IAM Authentication to RDS instances. It appears that when doing its connection pooling activities it always uses whatever DSN was passed initially on Open. 1) Is this correct. 2) Assuming one is correct would the Golang project every consider adding this feature? 3) If the answer is yes. How would one go about either helping to get it on the road map or better yet contributing this feature back to the community? What is this process? Thanks, Anthony Gruetzmacher -- 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: who does go compiler link executable to glibc without an apparent reason?
Thanks for the info! Kind regards, Howard On Tuesday, 7 November 2017 12:15:46 UTC+1, Dave Cheney wrote: > > Until recently some functions in the os/user package were only available > via glibc. > > The net package links to cgo by default to pick up the nss libraries, > which are important if your installation uses ldap. > > I argued that this should not be the default in the 1.5 release, that most > users deploying on Linux expected a static binary by default, however my > arguments were not sufficiently convincing. > > The tldr is rationale for the linking behaviour of a go binary is > implantation defined, and the go authors choose to make their > implementation use cgo where available. > > -- 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: [Request] Official golang debugger
You both make good point to why that might have it's issues. Taken into account the time mentioned it makes more sense to keep it separate and have it's own release cycle. Thanks for your input. On Tue, Nov 7, 2017 at 1:46 PM Dave Cheney wrote: > > > On Tuesday, 7 November 2017 22:29:29 UTC+11, Sotirios Mantziaris wrote: >> >> Apart from the time it would take to make changes to a tool in the >> toolchain i could come up with a reason for that: >> >> If a new feature gets added to go that would affect the debugger it would >> be tackled away as part of the release as opposed to wait for the final >> release and start implementing the new feature after the release. >> > > Anyone can download tip and build it, it almost always builds. > > >> As a example for the above could be the vendor support change that would >> be in the tool right away or the recent change to pprof not needing the >> binary to resolve symbols etc. >> > > I don't think these are very compelling arguments > > - vendoring is an illusion created by the go tool, the compiler is unaware > of it. > - the pprof change affects the pprof files written by the profiler, it is > unrelated to DWARF information written by the linker. > > >> >> Some tools a so core and should be in the toolchain like dependency >> management, debuggers, compiler etc... >> I had a hard time choosing a dependency management tool as they where so >> many of them. As soon dep was announced to be the standard tool, i switched >> immediately to it since this is not something i would like to thing when i >> write code, it is just tooling. >> >> This is just my thought. >> > > I'm on your side here, and my advice is do not yoke your debugging tool to > the go tool release cycle. > >> >> >> On Tue, Nov 7, 2017 at 11:33 AM Florin Pățan wrote: >> > For that tool, which is not the subject of this thread, the maintainers >>> are willing to pay the price of inclusion in the toolchain. >>> >>> As I stated in my original reply,I would hope we don't have to pay the >>> same price for the debugger. >>> >>> I don't understand why anyone thinks that inclusion in the toolchain, as >>> the toolchain is today is a good idea. The toolchain/standard library is >>> where all things stop evolving any any significant speed and stop being >>> able to break compatibil in favor of stability. If we'd have a 3 months >>> release cycle then this might be a different story. >>> >>> However it's ultimately not up to me to decide but I believe that the >>> more things we have outside of the toolchain / standard library, the >>> better. >>> >>> On Tue, 7 Nov 2017, 09:19 Sotirios Mantziaris, >>> wrote: >>> >> https://github.com/golang/dep/wiki/Roadmap The goal with dep is to be absorbed into the go toolchain. That's the path we're on, but it's up to the Go community - you! - to help us see it through. On Tue, Nov 7, 2017 at 11:16 AM Florin Pățan wrote: >>> dep is not part of the toolchain. > > On Tue, 7 Nov 2017, 08:38 Sotirios Mantziaris, > wrote: > >> would it not make sense them to keep dep out of the std toolchain to >> adapt faster to changes? >> >> On Tuesday, November 7, 2017 at 9:31:01 AM UTC+2, Dave Cheney wrote: >>> >>> If you reported an issue today, Nov 6, you could be waiting nearly 9 >>> months to see a fix in the next released version of Go. >>> >>> A project living outside the standard library has little going >>> against it other than you have to compile it yourself. >>> >>> On Tuesday, 7 November 2017 18:28:09 UTC+11, Sotirios Mantziaris >>> wrote: I do not know if the times you mentioned are indeed that long. If it is true then you actually have a good argument. On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan wrote: > > I hope not. Anything that ends up in the toolchain is slow to > change and adapt to user needs. If I have a problem with delve today, > I can > post an issue, fix it and get the next version of delve az quick as a > few > hours. If it would be in the toolchain it could take up to six months > to > get it released. > > On Tue, 7 Nov 2017, 07:04 Sotirios Mantziaris, > wrote: > >> Yes i know that, but i wonder if it is time to fully integrate >> delve in the go toolchain and ship it with every release like dep, >> which >> exists in another repository, but will be fullly integrated into the >> toolchain and the releases in some future version. >> >> On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan >> wrote: >>> >>> Delve is the one towards which the community rally since gdb, >>> still, doesn't play nice with goroutines. So, for all intents and >>> purposes, >>> delve is
Re: [go-nuts] Re: [Request] Official golang debugger
On Tuesday, 7 November 2017 22:29:29 UTC+11, Sotirios Mantziaris wrote: > > Apart from the time it would take to make changes to a tool in the > toolchain i could come up with a reason for that: > > If a new feature gets added to go that would affect the debugger it would > be tackled away as part of the release as opposed to wait for the final > release and start implementing the new feature after the release. > Anyone can download tip and build it, it almost always builds. > As a example for the above could be the vendor support change that would > be in the tool right away or the recent change to pprof not needing the > binary to resolve symbols etc. > I don't think these are very compelling arguments - vendoring is an illusion created by the go tool, the compiler is unaware of it. - the pprof change affects the pprof files written by the profiler, it is unrelated to DWARF information written by the linker. > > Some tools a so core and should be in the toolchain like dependency > management, debuggers, compiler etc... > I had a hard time choosing a dependency management tool as they where so > many of them. As soon dep was announced to be the standard tool, i switched > immediately to it since this is not something i would like to thing when i > write code, it is just tooling. > > This is just my thought. > I'm on your side here, and my advice is do not yoke your debugging tool to the go tool release cycle. > > > On Tue, Nov 7, 2017 at 11:33 AM Florin Pățan > wrote: > >> For that tool, which is not the subject of this thread, the maintainers >> are willing to pay the price of inclusion in the toolchain. >> >> As I stated in my original reply,I would hope we don't have to pay the >> same price for the debugger. >> >> I don't understand why anyone thinks that inclusion in the toolchain, as >> the toolchain is today is a good idea. The toolchain/standard library is >> where all things stop evolving any any significant speed and stop being >> able to break compatibil in favor of stability. If we'd have a 3 months >> release cycle then this might be a different story. >> >> However it's ultimately not up to me to decide but I believe that the >> more things we have outside of the toolchain / standard library, the >> better. >> >> On Tue, 7 Nov 2017, 09:19 Sotirios Mantziaris, > > wrote: >> >>> https://github.com/golang/dep/wiki/Roadmap >>> >>> The goal with dep is to be absorbed into the go toolchain. That's the >>> path we're on, but it's up to the Go community - you! - to help us see it >>> through. >>> >>> On Tue, Nov 7, 2017 at 11:16 AM Florin Pățan >> > wrote: >>> dep is not part of the toolchain. On Tue, 7 Nov 2017, 08:38 Sotirios Mantziaris, >>> > wrote: > would it not make sense them to keep dep out of the std toolchain to > adapt faster to changes? > > On Tuesday, November 7, 2017 at 9:31:01 AM UTC+2, Dave Cheney wrote: >> >> If you reported an issue today, Nov 6, you could be waiting nearly 9 >> months to see a fix in the next released version of Go. >> >> A project living outside the standard library has little going >> against it other than you have to compile it yourself. >> >> On Tuesday, 7 November 2017 18:28:09 UTC+11, Sotirios Mantziaris >> wrote: >>> >>> I do not know if the times you mentioned are indeed that long. >>> If it is true then you actually have a good argument. >>> >>> On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan wrote: I hope not. Anything that ends up in the toolchain is slow to change and adapt to user needs. If I have a problem with delve today, I can post an issue, fix it and get the next version of delve az quick as a few hours. If it would be in the toolchain it could take up to six months to get it released. On Tue, 7 Nov 2017, 07:04 Sotirios Mantziaris, wrote: > Yes i know that, but i wonder if it is time to fully integrate > delve in the go toolchain and ship it with every release like dep, > which > exists in another repository, but will be fullly integrated into the > toolchain and the releases in some future version. > > On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan > wrote: >> >> Delve is the one towards which the community rally since gdb, >> still, doesn't play nice with goroutines. So, for all intents and >> purposes, >> delve is the official debugger and the Go Team and Delve Team do >> work >> together to give us a better debugging experience. But sometimes the >> problems that need to be fixed are just too hard to do so quickly. > > -- > You received this message because you are subscribed to a topic in
[go-nuts] Re: Why does go run cmd does not accept a directory as an input
On Tuesday, 7 November 2017 22:22:43 UTC+11, Vladimir Varankin wrote: > > Thank you, Dave, for the response. > > > You’ll have a more enjoyable go experience if you structure your code > into packages and use go build or preferably go install. > > To be fair, I don't think that having the ability to do build + run in one > go command goes against the fact that it's worth to write code in a proper > modular way. And I don't see how splitting "main" package into several > files goes against it as well. > > It feels there is nothing wrong with the idea of making "go run" more than > a command that one should never use in a real project. > Have you tried go run dir/*.go ? That should work well enough. > > Regarding the use of "go build/install", could you talk more, what > benefits do they provide for the development process. I only aware of > incremental builds, that speed up the compilation time, which, in my > experience, isn't that bad for a small/middle size daemons. > sure, i wrote about it a while ago here, https://dave.cheney.net/2014/06/04/what-does-go-build-build > > > On Tuesday, November 7, 2017 at 1:21:52 PM UTC+3, Dave Cheney wrote: >> >> Real talk: go run is for examples as large as one would type into the >> playground. Nothing more. >> >> You’ll have a more enjoyable go experience if you structure your code >> into packages and use go build or preferably go install. > > -- 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] XML Parsing Nested Elements
I am really struggling to access nested elements of an XML string and suspect it is down to the namespaces. This string is obtained from a larger document and is the "innerXML" of some elements. A simplified version is at... I could probably do this with multiple structs but want to have this in a single struct. https://play.golang.org/p/Een-guMNP9 I can seem to read things at the root but cannot get them using the ">" syntax at all. What am I doing wrong? Can I "insert" a namespace element to assist it at all? I have manually removed the namespaces from this example to show what I think should happen!? https://play.golang.org/p/eCzbzgBYMq -- 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: [Request] Official golang debugger
Apart from the time it would take to make changes to a tool in the toolchain i could come up with a reason for that: If a new feature gets added to go that would affect the debugger it would be tackled away as part of the release as opposed to wait for the final release and start implementing the new feature after the release. As a example for the above could be the vendor support change that would be in the tool right away or the recent change to pprof not needing the binary to resolve symbols etc. Some tools a so core and should be in the toolchain like dependency management, debuggers, compiler etc... I had a hard time choosing a dependency management tool as they where so many of them. As soon dep was announced to be the standard tool, i switched immediately to it since this is not something i would like to thing when i write code, it is just tooling. This is just my thought. On Tue, Nov 7, 2017 at 11:33 AM Florin Pățan wrote: > For that tool, which is not the subject of this thread, the maintainers > are willing to pay the price of inclusion in the toolchain. > > As I stated in my original reply,I would hope we don't have to pay the > same price for the debugger. > > I don't understand why anyone thinks that inclusion in the toolchain, as > the toolchain is today is a good idea. The toolchain/standard library is > where all things stop evolving any any significant speed and stop being > able to break compatibil in favor of stability. If we'd have a 3 months > release cycle then this might be a different story. > > However it's ultimately not up to me to decide but I believe that the more > things we have outside of the toolchain / standard library, the better. > > On Tue, 7 Nov 2017, 09:19 Sotirios Mantziaris, > wrote: > >> https://github.com/golang/dep/wiki/Roadmap >> >> The goal with dep is to be absorbed into the go toolchain. That's the >> path we're on, but it's up to the Go community - you! - to help us see it >> through. >> >> On Tue, Nov 7, 2017 at 11:16 AM Florin Pățan >> wrote: >> >>> dep is not part of the toolchain. >>> >>> On Tue, 7 Nov 2017, 08:38 Sotirios Mantziaris, >>> wrote: >>> would it not make sense them to keep dep out of the std toolchain to adapt faster to changes? On Tuesday, November 7, 2017 at 9:31:01 AM UTC+2, Dave Cheney wrote: > > If you reported an issue today, Nov 6, you could be waiting nearly 9 > months to see a fix in the next released version of Go. > > A project living outside the standard library has little going against > it other than you have to compile it yourself. > > On Tuesday, 7 November 2017 18:28:09 UTC+11, Sotirios Mantziaris wrote: >> >> I do not know if the times you mentioned are indeed that long. >> If it is true then you actually have a good argument. >> >> On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan wrote: >>> >>> I hope not. Anything that ends up in the toolchain is slow to change >>> and adapt to user needs. If I have a problem with delve today, I can >>> post >>> an issue, fix it and get the next version of delve az quick as a few >>> hours. >>> If it would be in the toolchain it could take up to six months to get it >>> released. >>> >>> On Tue, 7 Nov 2017, 07:04 Sotirios Mantziaris, >>> wrote: >>> Yes i know that, but i wonder if it is time to fully integrate delve in the go toolchain and ship it with every release like dep, which exists in another repository, but will be fullly integrated into the toolchain and the releases in some future version. On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan wrote: > > Delve is the one towards which the community rally since gdb, > still, doesn't play nice with goroutines. So, for all intents and > purposes, > delve is the official debugger and the Go Team and Delve Team do work > together to give us a better debugging experience. But sometimes the > problems that need to be fixed are just too hard to do so quickly. -- 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/topic/golang-nuts/UY6pvL8qeIw/unsubscribe . To unsubscribe from this group and all its topics, 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 a topic in the Google Groups "golang-nuts" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/UY6pvL8qeIw/unsubscribe. To unsubscribe from this group and all its topics, send an email to golang-nut
[go-nuts] Re: Why does go run cmd does not accept a directory as an input
Thank you, Dave, for the response. > You’ll have a more enjoyable go experience if you structure your code into packages and use go build or preferably go install. To be fair, I don't think that having the ability to do build + run in one go command goes against the fact that it's worth to write code in a proper modular way. And I don't see how splitting "main" package into several files goes against it as well. It feels there is nothing wrong with the idea of making "go run" more than a command that one should never use in a real project. Regarding the use of "go build/install", could you talk more, what benefits do they provide for the development process. I only aware of incremental builds, that speed up the compilation time, which, in my experience, isn't that bad for a small/middle size daemons. On Tuesday, November 7, 2017 at 1:21:52 PM UTC+3, Dave Cheney wrote: > > Real talk: go run is for examples as large as one would type into the > playground. Nothing more. > > You’ll have a more enjoyable go experience if you structure your code into > packages and use go build or preferably go install. -- 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: who does go compiler link executable to glibc without an apparent reason?
Until recently some functions in the os/user package were only available via glibc. The net package links to cgo by default to pick up the nss libraries, which are important if your installation uses ldap. I argued that this should not be the default in the 1.5 release, that most users deploying on Linux expected a static binary by default, however my arguments were not sufficiently convincing. The tldr is rationale for the linking behaviour of a go binary is implantation defined, and the go authors choose to make their implementation use cgo where available. -- 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: who does go compiler link executable to glibc without an apparent reason?
Do you by any chance know what the rationale would be? Kind regards, Howard On Tuesday, 7 November 2017 11:55:22 UTC+1, Dave Cheney wrote: > > The net and os/user packages will force dynamic linking unless > CGO_ENABLED=0 or you are cross compiling. -- 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] who does go compiler link executable to glibc without an apparent reason?
The net and os/user packages will force dynamic linking unless CGO_ENABLED=0 or you are cross compiling. -- 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: who does go compiler link executable to glibc without an apparent reason?
Thanks very much Karan, that's indeed a good approach for this challenge.
Here is the output from a dynamically linked executable:
abort
__errno_location
fprintf
fputc
free
freeaddrinfo
fwrite
gai_strerror
getaddrinfo
getnameinfo
malloc
mmap
munmap
nanosleep
pthread_attr_destroy
pthread_attr_getstacksize
pthread_attr_init
pthread_cond_broadcast
pthread_cond_wait
pthread_create
pthread_mutex_lock
pthread_mutex_unlock
pthread_sigmask
setenv
sigaction
sigaddset
sigemptyset
sigfillset
sigismember
stderr
strerror
unsetenv
vfprintf
Now this initiative of go compiler producing a dynamic executable looks
quite redundant.
I shall find some time to reduce this go project, file an issue, and see if
go developers can share more insights.
Kind regards,
Howard
On Tuesday, 7 November 2017 11:21:26 UTC+1, Karan Chaudhary wrote:
>
> With a quick look, it seems "net" is not the only pkg which depends on
> cgo, though by default it uses pure Go DNS resolver only.
>
> I tested on small program:
> package main
>
> import (
> "fmt"
> "net/http"
> )
>
> func main() {
>
> fmt.Println("Hello, playground")
> http.ListenAndServe(":", nil)
>
> }
>
> Which is dynamically linked if CGO_ENABLED=1 is set, and statically
> linked if CGO_ENABLED=0 is set, irrespective of GODEBUG=netdns=go .
> Diffing the cgo symbols from ELFs from the 2 cases shows that enabling cgo
> adds 61 more functions:
> _cgo_b0c710f30cfd_C2func_
> _cgo_b0c710f30cfd_C2func_
> _cgo_b0c710f30cfd_Cfunc__
> _cgo_b0c710f30cfd_Cfunc_f
> _cgo_b0c710f30cfd_Cfunc_f
> _cgo_b0c710f30cfd_Cfunc_g
> _cgo_b0c710f30cfd_Cfunc_g
> _cgo_b0c710f30cfd_Cfunc_g
> cgo_context_function
> _cgo_get_context_function
> _cgo_panic
> _cgo_panic
> _cgo_release_context
> _cgo_sys_thread_start
> _cgo_topofstack
> _cgo_topofstack
> _cgo_try_pthread_create
> _cgo_wait_runtime_init_do
> net._cgo_b0c710f30cfd_C2f
> net._cgo_b0c710f30cfd_Cfu
> net._cgo_b0c710f30cfd_Cfu
> net._cgo_b0c710f30cfd_Cfu
> net._cgo_b0c710f30cfd_Cfu
> net._cgo_cmalloc
> net.cgoIPLookup
> net.cgoLookupIP
> net.cgoLookupIPCNAME
> net.cgoLookupIPCNAME.func
> net.cgoLookupIPCNAME.func
> net.cgoLookupIPCNAME.func
> net.cgoLookupPort
> net.cgoLookupServicePort
> net.cgoLookupServicePort.
> net.cgoLookupServicePort.
> net.cgoLookupServicePort.
> net.cgoPortLookup
> runtime.cgoAlwaysFalse
> runtime/cgo(.bss)
> runtime.cgocallback
> runtime.cgoCheckArg
> runtime.cgoCheckPointer
> runtime.cgoCheckUnknownPo
> runtime._cgo_panic_intern
> runtime/cgo(.rodata)
> runtime/cgo(.rodata.str1.
> runtime/cgo(.rodata.str1.
> runtime/cgo(.text)
> runtime.cgoUse
> x_cgo_callers
> x_cgo_init
> x_cgo_inittls
> x_cgo_mmap
> x_cgo_munmap
> x_cgo_notify_runtime_init
> x_cgo_set_context_functio
> x_cgo_setenv
> x_cgo_sigaction
> x_cgo_sys_thread_create
> x_cgo_threadentry
> x_cgo_thread_start
> x_cgo_unsetenv
>
> Here we can see "net" is not the only pkg that uses CGO, but runtime uses
> it as well.
> These can be explored to understand more.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Is there a way or lib to read a binary into a sturct{len int32;data [len]int32}
On Tue, Oct 31, 2017 at 04:36:20PM +0800, hui zhang wrote:
[...]
> > > Is there a way or lib to read a binary into a this structure in one line
> > > code?
> > >
> > > how about more complicate struct ?
> > > type complicatestrt struct {
> > > len int32
> > > strData []variastrt
> > > }
[...]
> > - Write some complicated code which uses reflection -- just like
> > the stock encoding/binary does -- to understand how to interpret the
> > fields of any custom struct type based on that type's tags (or just
> > "shape" -- that is, the types and relative order of its fields).
> >
> > For the latter, take into account that while there's no mention of the
> > format of the field tag in the language spec, the convention for their
> > format is documented at [4]:
> >
> > | By convention, tag strings are a concatenation of optionally
> > | space-separated key:"value" pairs. Each key is a non-empty string
> > | consisting of non-control characters other than space (U+0020 ' '),
> > | quote (U+0022 '"'), and colon (U+003A ':'). Each value is quoted using
> > | U+0022 '"' characters and Go string literal syntax.
> >
> > Hence you could come up with something like:
> >
> > type variastrt struct {
> > len int32 `var:"value:data endian:big"`
> > data []int32 `var:"endian:little"`
> > }
> >
> > And then you'd reflect over the type the user supplied to your
> > unmarshaling code, and in that reflection code you'd parse the field's
> > tag, get the value associated with the "var" key and parse that, in
> > turn, to know the name of the field to unmarshal the value into, and the
> > endianness of the elements of that value (if applicable).
[...]
> > 4. https://golang.org/pkg/reflect/#StructTag
> Thank you very much
> I know something like below could do. The problem has some one did it ? I
> don't know how to use the tag string.
> type variastrt struct {
> len int32 `var:"value:data endian:big"`
> data []int32 `var:"endian:little"`
> }
I'm not sure what you're asking about.
As I have said, if you would like to implement the indicated approach,
you would need to write code which obtains tags defined on the fields of
a user-programmed type, parses them and acts based on the results.
I have shown you what is the codified policy on the format of the struct
field tags (they are not defined by the Go language specification but
everyone agrees upon that policy which I cited in my first reply to this
thread). To inspect at runtime the type of a user-supplied variable,
and then further inspect its properties — such as fields of a struct
type, you need to use the standard package "reflect".
If you want to learn how to reflect over any custom user-defined type
using the standard package "reflect" and deal with the tags defined on
the fields of such a type, I'd suggest looking at the standard package
encoding/json and encoding/xml which make heavy use of these tags.
--
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: who does go compiler link executable to glibc without an apparent reason?
With a quick look, it seems "net" is not the only pkg which depends on
cgo, though by default it uses pure Go DNS resolver only.
I tested on small program:
package main
import (
"fmt"
"net/http"
)
func main() {
fmt.Println("Hello, playground")
http.ListenAndServe(":", nil)
}
Which is dynamically linked if CGO_ENABLED=1 is set, and statically linked
if CGO_ENABLED=0 is set, irrespective of GODEBUG=netdns=go .
Diffing the cgo symbols from ELFs from the 2 cases shows that enabling cgo
adds 61 more functions:
_cgo_b0c710f30cfd_C2func_
_cgo_b0c710f30cfd_C2func_
_cgo_b0c710f30cfd_Cfunc__
_cgo_b0c710f30cfd_Cfunc_f
_cgo_b0c710f30cfd_Cfunc_f
_cgo_b0c710f30cfd_Cfunc_g
_cgo_b0c710f30cfd_Cfunc_g
_cgo_b0c710f30cfd_Cfunc_g
cgo_context_function
_cgo_get_context_function
_cgo_panic
_cgo_panic
_cgo_release_context
_cgo_sys_thread_start
_cgo_topofstack
_cgo_topofstack
_cgo_try_pthread_create
_cgo_wait_runtime_init_do
net._cgo_b0c710f30cfd_C2f
net._cgo_b0c710f30cfd_Cfu
net._cgo_b0c710f30cfd_Cfu
net._cgo_b0c710f30cfd_Cfu
net._cgo_b0c710f30cfd_Cfu
net._cgo_cmalloc
net.cgoIPLookup
net.cgoLookupIP
net.cgoLookupIPCNAME
net.cgoLookupIPCNAME.func
net.cgoLookupIPCNAME.func
net.cgoLookupIPCNAME.func
net.cgoLookupPort
net.cgoLookupServicePort
net.cgoLookupServicePort.
net.cgoLookupServicePort.
net.cgoLookupServicePort.
net.cgoPortLookup
runtime.cgoAlwaysFalse
runtime/cgo(.bss)
runtime.cgocallback
runtime.cgoCheckArg
runtime.cgoCheckPointer
runtime.cgoCheckUnknownPo
runtime._cgo_panic_intern
runtime/cgo(.rodata)
runtime/cgo(.rodata.str1.
runtime/cgo(.rodata.str1.
runtime/cgo(.text)
runtime.cgoUse
x_cgo_callers
x_cgo_init
x_cgo_inittls
x_cgo_mmap
x_cgo_munmap
x_cgo_notify_runtime_init
x_cgo_set_context_functio
x_cgo_setenv
x_cgo_sigaction
x_cgo_sys_thread_create
x_cgo_threadentry
x_cgo_thread_start
x_cgo_unsetenv
Here we can see "net" is not the only pkg that uses CGO, but runtime uses
it as well.
These can be explored to understand more.
--
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] Why does go run cmd does not accept a directory as an input
Real talk: go run is for examples as large as one would type into the playground. Nothing more. You’ll have a more enjoyable go experience if you structure your code into packages and use go build or preferably go install. -- 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] Why does go run cmd does not accept a directory as an input
Currently `go run` accepts a file or a list of ".go" files: ``` % go help run usage: go run [build flags] [-exec xprog] gofiles... [arguments...] ``` For me, it doesn't seem to be obvious, why can't "go run" accept the directory that contains files of the main package as an input? Note, I'm aware of the ability to pass a list of all main's files, using a wildcard selector, e.g. `go run cmg/*.go`. But I want to understand if there is any particular reason it works this way, or this is how cmd's implemented and the behaviour might be extended in future releases? -- 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: [Request] Official golang debugger
That statement is pretty aspirational. I think it is likely that the go tool could grow the ability to understand repository tags, but beyond that I wouldn’t bet on one specific tool. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] A way to detect closed channel
gross. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] A way to detect closed channel
If you're using it as a signal to trigger only on close and not sending
any data, you should use chan struct{}, the reason for this is is that
the empty struct consumes zero storage
.
Also there is a multi-valued assignment form of the receive operator
, which reports whether a
received value was sent before the channel was closed.
Dave Cheney's article curious channels
is also relate so
worth a read.
Regards
Steve
On 07/11/2017 00:59, Albert Tedja wrote:
So, I just found out that closed channels always yield the zero value.
That means, a closed channel inside a select statement seems to always
be guaranteed to be executed.
Since closing an already closed channel creates a panic, does this
mean then I can do this to make sure that the channel is closed only once?
|
select{
case<-closedchan:
default:
close(closedchan)
}
|
Golang playground: https://play.golang.org/p/LSrTh0HC2K
It seems to work. Just want to confirm here before start doing this
everywhere in my code.
--
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] Re: Data persistence in go routine in defer
Yes it will work as "x" is within scope.
https://play.golang.org/p/dhBahtIVGb
On Tuesday, 7 November 2017 14:42:47 UTC+5:30, Abhijit Desai wrote:
>
> I want to log MyStruct value in "defer + go routine" so that logging
> will not affect total execution time of the the request which works
> fine as serving request is not taking 5+seconds...
>
> my question is.. will I get value of "x" in "defer + go routine" as main
> module already exit
>
> r.POST("/search", func(c *gin.Context) {
> var x MyStruct
> x := new(MyStruct)
> defer func() {
> go func() {
> time.Sleep(5000 * time.Millisecond) // for
> checking if main request is waiting for this...
> log(x)
> }()
> }()
>
>if c.Bind(&x) == nil {
> DoWork()
>}
> }
>
--
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: [Request] Official golang debugger
For that tool, which is not the subject of this thread, the maintainers are willing to pay the price of inclusion in the toolchain. As I stated in my original reply,I would hope we don't have to pay the same price for the debugger. I don't understand why anyone thinks that inclusion in the toolchain, as the toolchain is today is a good idea. The toolchain/standard library is where all things stop evolving any any significant speed and stop being able to break compatibil in favor of stability. If we'd have a 3 months release cycle then this might be a different story. However it's ultimately not up to me to decide but I believe that the more things we have outside of the toolchain / standard library, the better. On Tue, 7 Nov 2017, 09:19 Sotirios Mantziaris, wrote: > https://github.com/golang/dep/wiki/Roadmap > > The goal with dep is to be absorbed into the go toolchain. That's the > path we're on, but it's up to the Go community - you! - to help us see it > through. > > On Tue, Nov 7, 2017 at 11:16 AM Florin Pățan > wrote: > >> dep is not part of the toolchain. >> >> On Tue, 7 Nov 2017, 08:38 Sotirios Mantziaris, >> wrote: >> >>> would it not make sense them to keep dep out of the std toolchain to >>> adapt faster to changes? >>> >>> On Tuesday, November 7, 2017 at 9:31:01 AM UTC+2, Dave Cheney wrote: If you reported an issue today, Nov 6, you could be waiting nearly 9 months to see a fix in the next released version of Go. A project living outside the standard library has little going against it other than you have to compile it yourself. On Tuesday, 7 November 2017 18:28:09 UTC+11, Sotirios Mantziaris wrote: > > I do not know if the times you mentioned are indeed that long. > If it is true then you actually have a good argument. > > On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan wrote: >> >> I hope not. Anything that ends up in the toolchain is slow to change >> and adapt to user needs. If I have a problem with delve today, I can post >> an issue, fix it and get the next version of delve az quick as a few >> hours. >> If it would be in the toolchain it could take up to six months to get it >> released. >> >> On Tue, 7 Nov 2017, 07:04 Sotirios Mantziaris, >> wrote: >> >>> Yes i know that, but i wonder if it is time to fully integrate delve >>> in the go toolchain and ship it with every release like dep, which >>> exists >>> in another repository, but will be fullly integrated into the toolchain >>> and >>> the releases in some future version. >>> >>> On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan wrote: Delve is the one towards which the community rally since gdb, still, doesn't play nice with goroutines. So, for all intents and purposes, delve is the official debugger and the Go Team and Delve Team do work together to give us a better debugging experience. But sometimes the problems that need to be fixed are just too hard to do so quickly. >>> >>> -- >>> 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/topic/golang-nuts/UY6pvL8qeIw/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, 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 a topic in the >>> Google Groups "golang-nuts" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/golang-nuts/UY6pvL8qeIw/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. >>> >> -- > Kind Regards, > > S. Mantziaris > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] A way to detect closed channel
On 7 November 2017 at 00:59, Albert Tedja wrote:
> So, I just found out that closed channels always yield the zero value. That
> means, a closed channel inside a select statement seems to always be
> guaranteed to be executed.
>
> Since closing an already closed channel creates a panic, does this mean then
> I can do this to make sure that the channel is closed only once?
>
>
> select {
> case <- closedchan:
> default:
> close(closedchan)
> }
You can do that if you wrap it in a mutex so that nothing else
can be doing the same thing at the same time. That's
a common workaround for the fact that sometimes you want
to be able to close a signal-only channel (chan struct{}) from
a Close method that might be called multiple times.
Another possibility might be to do this:
func closeChan(c chan struct{}) {
defer func() {
// Catch the panic from closing an already-closed channel.
recover()
}()
close(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.
[go-nuts] Re: who does go compiler link executable to glibc without an apparent reason?
Just noticed this statement from src/net/net.go: -- On Unix systems, the resolver has two options for resolving names. It can use a pure Go resolver that sends DNS requests directly to the servers listed in /etc/resolv.conf, or it can use a cgo-based resolver that calls C library routines such as getaddrinfo and getnameinfo. - However, using its recommended method to force usage of Go resolver still results in a dynamic binary: export GODEBUG=netdns=go Welp, have to dig deeper. On Sunday, 5 November 2017 17:12:52 UTC+1, Howard Guo wrote: > > Hello fellow gophers. > > I've a small number of go programs that only use standard library > functions without any 3rd party library dependency. A strange behaviour was > observed during compilation (go build) - most of them compile into static > executable, but few of them end up linking to glibc. Without an exception, > all of them compile into static executable when CGO_ENABLED=0 is set prior > to compilation, and their runtime behaviour doesn't change at all. > > What could be the obscure reasons for go compiler to link executable to > glibc? > > Thanks. > > Kind regards, > Howard > -- 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: [Request] Official golang debugger
https://github.com/golang/dep/wiki/Roadmap The goal with dep is to be absorbed into the go toolchain. That's the path we're on, but it's up to the Go community - you! - to help us see it through. On Tue, Nov 7, 2017 at 11:16 AM Florin Pățan wrote: > dep is not part of the toolchain. > > On Tue, 7 Nov 2017, 08:38 Sotirios Mantziaris, > wrote: > >> would it not make sense them to keep dep out of the std toolchain to >> adapt faster to changes? >> >> On Tuesday, November 7, 2017 at 9:31:01 AM UTC+2, Dave Cheney wrote: >>> >>> If you reported an issue today, Nov 6, you could be waiting nearly 9 >>> months to see a fix in the next released version of Go. >>> >>> A project living outside the standard library has little going against >>> it other than you have to compile it yourself. >>> >>> On Tuesday, 7 November 2017 18:28:09 UTC+11, Sotirios Mantziaris wrote: I do not know if the times you mentioned are indeed that long. If it is true then you actually have a good argument. On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan wrote: > > I hope not. Anything that ends up in the toolchain is slow to change > and adapt to user needs. If I have a problem with delve today, I can post > an issue, fix it and get the next version of delve az quick as a few > hours. > If it would be in the toolchain it could take up to six months to get it > released. > > On Tue, 7 Nov 2017, 07:04 Sotirios Mantziaris, > wrote: > >> Yes i know that, but i wonder if it is time to fully integrate delve >> in the go toolchain and ship it with every release like dep, which exists >> in another repository, but will be fullly integrated into the toolchain >> and >> the releases in some future version. >> >> On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan wrote: >>> >>> Delve is the one towards which the community rally since gdb, still, >>> doesn't play nice with goroutines. So, for all intents and purposes, >>> delve >>> is the official debugger and the Go Team and Delve Team do work >>> together to >>> give us a better debugging experience. But sometimes the problems that >>> need >>> to be fixed are just too hard to do so quickly. >> >> -- >> 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/topic/golang-nuts/UY6pvL8qeIw/unsubscribe >> . >> To unsubscribe from this group and all its topics, 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 a topic in the >> Google Groups "golang-nuts" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/golang-nuts/UY6pvL8qeIw/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. >> > -- Kind Regards, S. Mantziaris -- 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: [Request] Official golang debugger
dep is not part of the toolchain. On Tue, 7 Nov 2017, 08:38 Sotirios Mantziaris, wrote: > would it not make sense them to keep dep out of the std toolchain to adapt > faster to changes? > > On Tuesday, November 7, 2017 at 9:31:01 AM UTC+2, Dave Cheney wrote: >> >> If you reported an issue today, Nov 6, you could be waiting nearly 9 >> months to see a fix in the next released version of Go. >> >> A project living outside the standard library has little going against it >> other than you have to compile it yourself. >> >> On Tuesday, 7 November 2017 18:28:09 UTC+11, Sotirios Mantziaris wrote: >>> >>> I do not know if the times you mentioned are indeed that long. >>> If it is true then you actually have a good argument. >>> >>> On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan wrote: I hope not. Anything that ends up in the toolchain is slow to change and adapt to user needs. If I have a problem with delve today, I can post an issue, fix it and get the next version of delve az quick as a few hours. If it would be in the toolchain it could take up to six months to get it released. On Tue, 7 Nov 2017, 07:04 Sotirios Mantziaris, wrote: > Yes i know that, but i wonder if it is time to fully integrate delve > in the go toolchain and ship it with every release like dep, which exists > in another repository, but will be fullly integrated into the toolchain > and > the releases in some future version. > > On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan wrote: >> >> Delve is the one towards which the community rally since gdb, still, >> doesn't play nice with goroutines. So, for all intents and purposes, >> delve >> is the official debugger and the Go Team and Delve Team do work together >> to >> give us a better debugging experience. But sometimes the problems that >> need >> to be fixed are just too hard to do so quickly. > > -- > 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/topic/golang-nuts/UY6pvL8qeIw/unsubscribe. > To unsubscribe from this group and all its topics, 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 a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/UY6pvL8qeIw/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.
[go-nuts] Data persistence in go routine in defer
I want to log MyStruct value in "defer + go routine" so that logging will
not affect total execution time of the the request which works fine as
serving request is not taking 5+seconds...
my question is.. will I get value of "x" in "defer + go routine" as main
module already exit
r.POST("/search", func(c *gin.Context) {
var x MyStruct
x := new(MyStruct)
defer func() {
go func() {
time.Sleep(5000 * time.Millisecond) // for
checking if main request is waiting for this...
log(x)
}()
}()
if c.Bind(&x) == nil {
DoWork()
}
}
--
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: [Request] Official golang debugger
would it not make sense them to keep dep out of the std toolchain to adapt faster to changes? On Tuesday, November 7, 2017 at 9:31:01 AM UTC+2, Dave Cheney wrote: > > If you reported an issue today, Nov 6, you could be waiting nearly 9 > months to see a fix in the next released version of Go. > > A project living outside the standard library has little going against it > other than you have to compile it yourself. > > On Tuesday, 7 November 2017 18:28:09 UTC+11, Sotirios Mantziaris wrote: >> >> I do not know if the times you mentioned are indeed that long. >> If it is true then you actually have a good argument. >> >> On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan wrote: >>> >>> I hope not. Anything that ends up in the toolchain is slow to change and >>> adapt to user needs. If I have a problem with delve today, I can post an >>> issue, fix it and get the next version of delve az quick as a few hours. If >>> it would be in the toolchain it could take up to six months to get it >>> released. >>> >>> On Tue, 7 Nov 2017, 07:04 Sotirios Mantziaris, >>> wrote: >>> Yes i know that, but i wonder if it is time to fully integrate delve in the go toolchain and ship it with every release like dep, which exists in another repository, but will be fullly integrated into the toolchain and the releases in some future version. On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan wrote: > > Delve is the one towards which the community rally since gdb, still, > doesn't play nice with goroutines. So, for all intents and purposes, > delve > is the official debugger and the Go Team and Delve Team do work together > to > give us a better debugging experience. But sometimes the problems that > need > to be fixed are just too hard to do so quickly. -- 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/topic/golang-nuts/UY6pvL8qeIw/unsubscribe. To unsubscribe from this group and all its topics, 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.
