Re: [go-nuts] Best practice for "main.go" to access members of a structure in the real package

[Marcin Romaszewicz]

Go doesn't have file scoped variables, only global variables and local
variables declared in functions, so your "file" scope variables are global
to their package.

Global variables aren't inherently bad, that's a bit of voodoo that some
ideological languages introduced, and people believe without question.

Now, as for your particular example, I've handled this in a different way
in my own code. Each of your packages can have a "RegisterFlags()" function
which registers its own command line flags, and returns a struct containing
the flags. You can implement another function called
"InitFromFlags(flagStruct...)". This way, there's no global state, and
package initialization is still decoupled from flags.


On Fri, Feb 17, 2023 at 9:18 PM Pat Farrell  wrote:

> I'm still struggling with how to setup my access.
> I'm building a library, say  tagtool   and it has a nice clean
> subdirectory with the files
> that make up the go package, each with
>
> package tagtool
>
> And I have a subdirectory called "cmd" that contains a near trivial main.go
> that calls the various tagtool.Mumble() func.
> So far, so good.
>
> But I've been using file/package level vars. This is clearly a bad thing.
> So I'm trying to bundle all the various vars into a struct, and
> I'll have my main.go call a
>
> func AllocateData() *GlobalVars {
> rval := new(GlobalVars)
> //.. do other init stuff
> return rval
> }
>
> This way we have the main holding the storage for what had been
> file/package level
> vars.
>
> Which is a good start. It works great if I capitalize all the variables.
> But I really don't want to make all of the variables in the struct be part
> of my public API. They are all implementation details. I need to be able to
> initialize various variables in the GlobalVars struct from my 'main.go'
>
> Right now, its mostly flag variables that I need. Stuff like
> flag.BoolVar(, "de", false, "debug on")
>
> The main.go doesn't really care about the values once the flag package has
> set them from the shell arguments, it just wants the tagtool
>
> Is there a "friend" declaration or import that lets the "package main"
> look into
> the package tagtool?
>
> Thanks
> Pat
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/d64ccb62-9134-4c66-8fb3-6ce1ffe19871n%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] go get created directories with exclamation points

[Marcin Romaszewicz]

Go converts uppercase characters to the corresponding lower case character
with an exclamation point in front of it to avoid case sensitivity
collisions on case insensitive filesystems. In my pkg/mod/github directory,
DataDog is the worst offender since it has changed capitalization over
time, so I have a "!d!a!t!a-!d!o!g" and a "!data!dog" directory, for
example. It's working as intended. I don't use Intellij for Go, but I've
had no problems with GoLand, also from JetBrains, since it knows how to
handle those escaped capital letters.

-- Marcin

On Wed, Jan 4, 2023 at 8:30 AM Dean Schulze 
wrote:

> I did go get to download some Azure SDK for Go modules.  This created
> directories with exclamation points in their names.  My code works from the
> command line, but Intellij won't recognize these modules.
>
> Why does go get create directories with exclamation points in their names?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9bec22e0-2a18-4cb4-b1d8-6c1e9848a58en%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Unmarshal variable JSON structures

[Marcin Romaszewicz]

Here is an example of what I mean.

https://go.dev/play/p/O6KIsxmSeaN

This is why I wrote a code generator, it's tedious by hand :)

On Mon, Dec 26, 2022 at 11:08 AM Marcin Romaszewicz 
wrote:

> This is a very annoying problem, and one that we hit a lot in my project (
> https://github.com/deepmap/oapi-codegen), where we generate Go models
> from OpenAPI specs, and the OpenAPI "AnyOf" or "OneOf" schema does
> precisely this.
>
> You can partially unmarshal; store your "type" field in a typed variable,
> and use json.RawMessage to defer parsing to later, when you know the type.
> This still gets annoying, because if your field names are dynamic, you need
> to override the default unmarshaling behavior to produce a map of field
> names to json.RawMessage. If you jump through these hoops, you can avoid
> parsing twice. Once you've partially parsed your object, you can create
> some functions on it, such as "AsAtype()" or "AsBType()", which switches on
> "type" and returns the correct concrete object.
>
> On Mon, Dec 26, 2022 at 10:04 AM Andrew Burian  wrote:
>
>> Hey all, wondering if there's an existing best practice for this so I'm
>> not reinventing the wheel.
>>
>> It's frustratingly common to have APIs where the response JSON can be one
>> of several distinct objects, and the indicator of which object has been
>> returned is itself a property of the object.
>>
>> So you might get a `{ "type": "aType", "aField" : ."..." }` or a `{
>> "type": "bType", "bField": "..." }` response from the same API.
>>
>> What's the best way to deserialize in these situations?
>>
>> Ideas I've tried so far:
>>
>>- Unmarhsal twice, once into a struct that just defines the `Type`
>>property and ignores all other fields, then again based on the type set 
>> the
>>first time.
>>Works, but for large objects it's extremely wasteful.
>>
>>- Unmarshal into a large struct that defines all possible subtypes as
>>anonymous struct fields so their declarations are treated as being on the
>>outer struct, then cast to the appropriate type after unmarshaling to mask
>>all the unfilled fields.
>>Again, works, but feels awful. It also presents a real issue when you
>>need to verify that no fields other than the expected fields for the given
>>type were present, which you can usually do with
>>Decoder.DisallowUnknownFields, but silently succeeds if one of the fields
>>is valid for a different object type.
>>
>> I'm trying to do this as much with stdlib as possible. I've looked into
>> some other libraries that make heavy use of JSON decoding and have seen
>> both my above ideas, as well as just entirely custom Unmarshaller
>> implementations. Hopefully it doesn't come to that.
>>
>> Cheers,
>> Andrew
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAPyCRsvvzzscpgfjj2vPQAi5_DVvrfhxLMu_OhuETzKAd7N1xQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAPyCRsvvzzscpgfjj2vPQAi5_DVvrfhxLMu_OhuETzKAd7N1xQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

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

Re: [go-nuts] Unmarshal variable JSON structures

[Marcin Romaszewicz]

This is a very annoying problem, and one that we hit a lot in my project (
https://github.com/deepmap/oapi-codegen), where we generate Go models from
OpenAPI specs, and the OpenAPI "AnyOf" or "OneOf" schema does precisely
this.

You can partially unmarshal; store your "type" field in a typed variable,
and use json.RawMessage to defer parsing to later, when you know the type.
This still gets annoying, because if your field names are dynamic, you need
to override the default unmarshaling behavior to produce a map of field
names to json.RawMessage. If you jump through these hoops, you can avoid
parsing twice. Once you've partially parsed your object, you can create
some functions on it, such as "AsAtype()" or "AsBType()", which switches on
"type" and returns the correct concrete object.

On Mon, Dec 26, 2022 at 10:04 AM Andrew Burian  wrote:

> Hey all, wondering if there's an existing best practice for this so I'm
> not reinventing the wheel.
>
> It's frustratingly common to have APIs where the response JSON can be one
> of several distinct objects, and the indicator of which object has been
> returned is itself a property of the object.
>
> So you might get a `{ "type": "aType", "aField" : ."..." }` or a `{
> "type": "bType", "bField": "..." }` response from the same API.
>
> What's the best way to deserialize in these situations?
>
> Ideas I've tried so far:
>
>- Unmarhsal twice, once into a struct that just defines the `Type`
>property and ignores all other fields, then again based on the type set the
>first time.
>Works, but for large objects it's extremely wasteful.
>
>- Unmarshal into a large struct that defines all possible subtypes as
>anonymous struct fields so their declarations are treated as being on the
>outer struct, then cast to the appropriate type after unmarshaling to mask
>all the unfilled fields.
>Again, works, but feels awful. It also presents a real issue when you
>need to verify that no fields other than the expected fields for the given
>type were present, which you can usually do with
>Decoder.DisallowUnknownFields, but silently succeeds if one of the fields
>is valid for a different object type.
>
> I'm trying to do this as much with stdlib as possible. I've looked into
> some other libraries that make heavy use of JSON decoding and have seen
> both my above ideas, as well as just entirely custom Unmarshaller
> implementations. Hopefully it doesn't come to that.
>
> Cheers,
> Andrew
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAPyCRsvvzzscpgfjj2vPQAi5_DVvrfhxLMu_OhuETzKAd7N1xQ%40mail.gmail.com
> 
> .
>

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

Re: [go-nuts] Re: Encrypting credentials config file in production and pseudo key rotation

[Marcin Romaszewicz]

Check out SOPS, we use it to commit encrypted secrets into Git and only
people with access to keys can see them.

https://github.com/mozilla/sops

On Sat, Oct 1, 2022 at 2:59 AM Peter Galbavy  wrote:

> We have a different requirement, which is opaquing of credentials in user
> visible config files. The company I work for has a basic way of doing this
> in the "real" product and I followed the same model for compatibility.
> There is, as yet, no auto rotation.
>
> Basically, we generate an OpenSSL "compatible" key file and use that to
> encode and decode the credentials. The key file is still local but
> can/should be on a different file system and only readable by the app
> owner. The config files can then be edited / communicated with less chance
> of leaks. The objective is to protect against casual mistakes, not against
> determined actors.
>
> I layered it, along with other local requirements, over viper so that
> "GetString" etc. just works.
>
> https://github.com/ITRS-Group/cordial/tree/main/pkg/config
>
> Peter
>
>
> On Friday, 30 September 2022 at 17:34:29 UTC+1 Ivan Buljan wrote:
>
>> Hello World
>>
>> This relates to that never ending question of securing the credentials in
>> production/staging envs, that is, avoiding storing them as plain text
>>
>> I am wondering if anyone could share their thoughts about the following
>> approach we are thinking of taking.
>>
>> Here we go:
>>
>> During build phase, an encryption key is generated and credentials are
>> encrypted with it.
>>
>> Once deployed, the instance decrypts credentials with the provided key
>> and does what it needs with them. Just before destroying the original files
>> (creds & key), the instance then generates a new encryption key and
>> re-encrypts a copy of credentials, which it keeps in memory. Newly
>> encrypted credentials along with the key are only dumped onto a filesystem
>> if the application panics and requires to be restarted, at which point the
>> same cycle key rotation decryption/encryption happens again.
>>
>> Is any security benefit with such approach?
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/d011891f-ab3f-41eb-8ad1-c90cbcf78a58n%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] encoding/json doesn't find marshal/unmarshal via type aliases

[Marcin Romaszewicz]

Aha! That is what I was missing. Thank you.

On Fri, May 20, 2022 at 7:37 AM 'Sean Liao' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> As explained above, `type AliasedDate Date` clears any methods you have
> defined on `Date`.
> But `Date` embeds `time.Time` which has its own `UnmrshalJSON`,
> which now gets promoted.
>
> So `Date.UnmsrshalJSON` calls your `UnmsrshalJSON`
> `AliastedDate.UnmsrshalJSON` calls `AliastedDate.Time.UnmsrshalJSON`
>
> On Fri, May 20, 2022 at 3:14 PM Marcin Romaszewicz 
> wrote:
>
>> Sorry about mixing up terms, however, my question still stands.
>>
>> encoding/json looks for the Marshaler/Unmarshaler interface
>> convertibility, and in this case, the compiler thinks that the redeclared
>> type does implement json.Unmarshaler. I extended my example to also do this
>> test via reflection.
>>
>> https://go.dev/play/p/TrxM2zxG2pX
>>
>> So, yes, it's a new type, but it seems to behave just like the base type.
>>
>> On Fri, May 20, 2022 at 12:35 AM Axel Wagner <
>> axel.wagner...@googlemail.com> wrote:
>>
>>> It's not an "aliased type". Type aliases take the form
>>> type A = B
>>> and they make the name A be interchangeable with the name B. What you
>>> have is a type declaration
>>> type A B
>>> which creates a fully new type, with a new method set, but the same
>>> underlying type as B.
>>>
>>> On Fri, May 20, 2022 at 9:28 AM Marcin Romaszewicz 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I've created a simple struct that wraps time.Time because I'd like to
>>>> unmarshal it differently from JSON than the default. It works great.
>>>>
>>>> However, when I pass a type alias of that struct to json.Marshal or
>>>> json.Unmarshal, the MarshalJSON and UnmarshalJSON functions aren't invoked,
>>>> despite both types conforming to the interfaces.
>>>>
>>>> Here's the shortest example I could make.
>>>> https://go.dev/play/p/pETWQB3CWxV
>>>>
>>>> This is where this came up:
>>>> https://github.com/deepmap/oapi-codegen/issues/579
>>>>
>>>> I did find a workaround, in redeclaring the MarshalJSON/UnmarshalJSON
>>>> on the aliased type, but I don't understand why this is necessary, and I'm
>>>> hoping someone who understands the innards of this better than I do could
>>>> enlighten me.
>>>>
>>>> Thanks,
>>>> -- Marcin
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "golang-nuts" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LuOa9sHFWxPxqYq_HtiQZ6_pUhCtMUOAL8Yq1X_UvyjJw%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LuOa9sHFWxPxqYq_HtiQZ6_pUhCtMUOAL8Yq1X_UvyjJw%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LvC7NY-wGXX9JUQAcGPohLB_puPz0F2Nehsq7Xx2zAZeg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LvC7NY-wGXX9JUQAcGPohLB_puPz0F2Nehsq7Xx2zAZeg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAGabyPpyzxzpqNy%3DqFo3pdRp2HT8Gks-xSB9e7KLmEVG%3DTb%2Bwg%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAGabyPpyzxzpqNy%3DqFo3pdRp2HT8Gks-xSB9e7KLmEVG%3DTb%2Bwg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

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

Re: [go-nuts] encoding/json doesn't find marshal/unmarshal via type aliases

[Marcin Romaszewicz]

Sorry about mixing up terms, however, my question still stands.

encoding/json looks for the Marshaler/Unmarshaler interface convertibility,
and in this case, the compiler thinks that the redeclared type does
implement json.Unmarshaler. I extended my example to also do this test via
reflection.

https://go.dev/play/p/TrxM2zxG2pX

So, yes, it's a new type, but it seems to behave just like the base type.

On Fri, May 20, 2022 at 12:35 AM Axel Wagner 
wrote:

> It's not an "aliased type". Type aliases take the form
> type A = B
> and they make the name A be interchangeable with the name B. What you have
> is a type declaration
> type A B
> which creates a fully new type, with a new method set, but the same
> underlying type as B.
>
> On Fri, May 20, 2022 at 9:28 AM Marcin Romaszewicz 
> wrote:
>
>> Hi All,
>>
>> I've created a simple struct that wraps time.Time because I'd like to
>> unmarshal it differently from JSON than the default. It works great.
>>
>> However, when I pass a type alias of that struct to json.Marshal or
>> json.Unmarshal, the MarshalJSON and UnmarshalJSON functions aren't invoked,
>> despite both types conforming to the interfaces.
>>
>> Here's the shortest example I could make.
>> https://go.dev/play/p/pETWQB3CWxV
>>
>> This is where this came up:
>> https://github.com/deepmap/oapi-codegen/issues/579
>>
>> I did find a workaround, in redeclaring the MarshalJSON/UnmarshalJSON on
>> the aliased type, but I don't understand why this is necessary, and I'm
>> hoping someone who understands the innards of this better than I do could
>> enlighten me.
>>
>> Thanks,
>> -- Marcin
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LuOa9sHFWxPxqYq_HtiQZ6_pUhCtMUOAL8Yq1X_UvyjJw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LuOa9sHFWxPxqYq_HtiQZ6_pUhCtMUOAL8Yq1X_UvyjJw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

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

[go-nuts] encoding/json doesn't find marshal/unmarshal via type aliases

[Marcin Romaszewicz]

Hi All,

I've created a simple struct that wraps time.Time because I'd like to
unmarshal it differently from JSON than the default. It works great.

However, when I pass a type alias of that struct to json.Marshal or
json.Unmarshal, the MarshalJSON and UnmarshalJSON functions aren't invoked,
despite both types conforming to the interfaces.

Here's the shortest example I could make.
https://go.dev/play/p/pETWQB3CWxV

This is where this came up:
https://github.com/deepmap/oapi-codegen/issues/579

I did find a workaround, in redeclaring the MarshalJSON/UnmarshalJSON on
the aliased type, but I don't understand why this is necessary, and I'm
hoping someone who understands the innards of this better than I do could
enlighten me.

Thanks,
-- Marcin

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

Re: [go-nuts] Slices of pointers or not?

[Marcin Romaszewicz]

It depends on what you do with it, and how you use it.

[]*Person is a slice of pointers, they're small.
[]Person is a slice of structs, they're bigger than pointers.

The first requires a level of indirection to access, the second doesn't.
The first requires no copying of structs when you're iterating or resizing,
while the second requires copying entire structs.

So, either could be faster based on what you do with it.

On Thu, Feb 3, 2022 at 5:10 PM Paulo Júnior 
wrote:

> Hi all.
>
> I hope you are well.
>
> Is there a big difference, in terms of performance or functionality,
> between declaring *[]*Person* or *[]Person* as a return type of a
> function?
>
> Code sample https://go.dev/play/p/tBAod1hZvYu
>
> Thank you and best regards.
> Paulo.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/964eb09d-cd5f-4da1-b1ca-cac3e9b5bb69n%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Re: Best timeOut for mongoDB context timeout in golang

[Marcin Romaszewicz]

SQL Databases also typically have query timeouts on the DB side. When you
cancel a context, the DB could still chug on that query for a while. For
example, https://www.postgresql.org/docs/current/runtime-config-client.html
(see statement_timeout). If you want to reliably cancel connections and not
swamp your DB with runaway queries, do both.

On Sun, Jan 16, 2022 at 1:24 PM Brian Candler  wrote:

> Oops, subject said mongoDB not SQL.  But I think the point stands.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6a5d0919-a828-41d4-8c53-722631013f68n%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] From interface to []rune

[Marcin Romaszewicz]

No, you can't. A string is not a []rune, but it can be type converted to
one, so you have to type convert your interface to string, then convert to
runes.

https://play.golang.com/p/GKITxGGYHZI

On Wed, Dec 8, 2021 at 5:44 AM Денис Мухортов 
wrote:

> Can i get data from interface to []rune like that:
> https://play.golang.com/p/XpXTeUgL-Tn
> If so, how??
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/92755612-a157-4cc8-b6f5-fe65610ee1d7n%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] nil

[Marcin Romaszewicz]

I updated your example with a couple of nil checks which work in this
situation, so have a look after reading that nil error link above.
https://go.dev/play/p/lsc72BWP-SO

On Thu, Dec 2, 2021 at 1:17 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Thu, Dec 2, 2021 at 10:13 AM Денис Мухортов
>  wrote:
>
> > How can the output of the program be explained? Why checking for nil
> gives false??
>
> Because it is not nil: https://go.dev/doc/faq#nil_error
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-X%2BDXBnc5KVe78m764k43E4QK%2BKPPZwWpJfLzwePKdCwQ%40mail.gmail.com
> .
>

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

Re: [go-nuts] templates in html

[Marcin Romaszewicz]

Have a look at this:
https://pkg.go.dev/html/template#Template.Funcs

You need to provide a map of function names to function references to the
template engine, otherwise, it has no idea what "stoneShop" is, because all
it sees is an interface{} and has no context to know that it's a function.
This data argument is explored via reflection, so if you reference
".Something", the template engine will look in data for a field with that
name.

The function map that I linked above is where you would provide your
"stoneShop" function.

On Tue, Oct 26, 2021 at 12:23 AM Денис Мухортов 
wrote:

> I need to pass data from the map[string]interface{} through the template
> I dont know why, but I catch the error:
> template: stone-card.html:2: function "stoneShop" not defined.
> Code in go:
> files := []string{
> dirWithHTML + "index.html",
> dirWithHTML + "stone-card.html",
> }
> tmp, err := template.ParseFiles(files...)
> if err != nil {
> fmt.Println(err)
> }
> err = tmp.Execute(w, block)
> if err != nil {
> log.Fatal(err)
> }
> stoneShop := stones()
> err = tmp.ExecuteTemplate(w, "stone", stoneShop)
> // var stoneShop map[string]interface{}
> if err != nil {
> log.Print(err)
> }
> Template Code:
> {{define "stone"}}
> {{range $key, $value := stoneShop}}
> 
> 
>   
> 
> 
>   
> {{$value.Name}}
>   
>   
> {{$value.Description}}
>   
>   
> {{$value.Rare}}
>   
>   
> Купить
> {{$value.Price}} C
>   
> 
> 
> {{end}}
> {{end}}
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/2edfe28a-d136-43a4-819e-081644d1683cn%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Problem using embed in Go 1.16

[Marcin Romaszewicz]

If you're not directly using symbols from embed, import it with an _ alias,
eg:

import _ "embed"

-- Marcin

On Sun, Oct 10, 2021 at 9:12 AM Tong Sun  wrote:

> Hi,
>
> I'm having problem using embed with Go 1.16. I'm getting ether
>
> - //go:embed only allowed in Go files that import "embed"
> - or imported and not used: "embed"
>
> The test code is published at
> https://github.com/suntong/lang/tree/master/lang/Go/src/ds/embed
>
> here are the details:
>
> If I remove the "embed" Go import, I'll get:
>
> $ go build
> # github.com/suntong/lang/lang/Go/src/ds/embed
> ./embeding.go:17:3: //go:embed only allowed in Go files that import "embed"
>
> If I add back the "embed" Go import, I'll get:
>
> $ go build
> # github.com/suntong/lang/lang/Go/src/ds/embed
> ./embeding.go:11:2: imported and not used: "embed"
>
> $ go version
> go version go1.16.6 linux/amd64
>
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Description:Debian GNU/Linux bullseye/sid
> Release:10.10
> Codename:   buster
>
> The main file:
>
> ---
> package main
>
> import (
> "embed"
> "flag"
> "fmt"
> "os"
> )
>
> //go:embed cpuArch.txt
> var cpuArch string
>
> func usage() {
> // Fprintf allows us to print to a specifed file handle or stream
> fmt.Fprintf(os.Stderr, "\nUsage: %s [flags] file [path ...]\n\n",
> "CommandLineFlag") // os.Args[0]
> flag.PrintDefaults()
> os.Exit(0)
> }
>
> func main() {
> fmt.Printf("Before parsing the flags\n")
> fmt.Printf("CPU: '%s'\n", cpuArch)
>
> flag.StringVar(, "cpu", "AMD64", "CPU Arch")
>
> flag.Usage = usage
> flag.Parse()
>
> // There is also a mandatory non-flag arguments
> if len(flag.Args()) < 1 {
> usage()
> }
>
> fmt.Printf("\nAfter parsing the flags\n")
> fmt.Printf("CPU: '%s'\n", cpuArch)
>
> }
> ---
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/4124bd7e-f5b1-4259-a433-05959021d05cn%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

[Marcin Romaszewicz]

I have this exact testing issue at my company, we have many Go services
which use Postgres in production, but are unit tested against SQLite.

The latest SQLite covers the vast majority of Postgres queries, so most
tests simply use an SQLite in-memory DB.

For the tests which require Postgres- specific functionality, such as
partitioned tables, for example, we use
https://github.com/testcontainers/testcontainers-go. This is a library
which talks to Docker and can create your test prerequisites as docker
containers and gives you connection information once they're up. This makes
unit tests incredibly slower, but at least functional.

The danger with mocking too much is that your unit tests end up testing the
mocks, and not anything remotely like your runtime environment, so we've
chosen to mock as little as possible.

-- Marcin

On Wed, Jul 28, 2021 at 4:09 AM Henry  wrote:

> On Wednesday, July 28, 2021 at 3:05:43 PM UTC+7 amits...@gmail.com wrote:
>
>> That sounds interesting - is the tool generating or is able to
>> generate SQL for different databases? That must have been a pretty big
>> effort to create such an abstraction.
>>
>>
> It produces different SQL for different databases. It supports a limited
> number of databases. Note that quite a number of Go ORM libraries already
> support multiple databases. So it is not new. The difference is that other
> ORM libraries usually provide a general purpose data access library,
> whereas ours generates more specific codes. Other than that, they serve a
> similar purpose.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9c81746a-4fb4-4fb5-8e5f-605169a3f2afn%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Go and GPUs

[Marcin Romaszewicz]

Graphics chips have a lot of proprietary IP, some of which the
manufacturers would like to keep secret. If you see source for one of these
drivers, you will have a good idea about the hardware organization, so they
keep everything secret. It stinks for us developers who want to write cross
platform open source. The best bet right now, in my opinion, is to write
CGO wrappers around platform native libraries, and sadly, they'll only work
on some OS/hardware combinations.


On Fri, Jun 25, 2021 at 8:53 AM Nikolay Dubina 
wrote:

> I tried to write down my own CUDA / NVIDIA GPU driver in native Go last
> weekend. To my great surprise, CUDA and pretty much all high performance
> software/hardware from NVIDIA is proprietary close-source C/C++ code.
> Meaning, you can't write native Go driver even if you wanted to. Forget Go,
> people are trying to reverse engineer it in C/C++ with limited success.
> From what I heard OpenCV is not a priority for NVIDIA either. Then I looked
> up what Apple is doing with their Neural Engine in latest chips. It too is
> closed-source Objective-C, Swift. I suspect situation with other powerful
> hardware is the same. Moore's law seem to be about GPU lately, and everyone
> is locking it in. Kind of not in the spirit open-source and Linux. That's
> quite bad state of affairs for Go and computing in general. Yikes!
>
> Just want to see what others are thinking.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/0913f098-700a-443f-bd02-2db7ad2408a6n%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] how break point work in multi-thread multi-core linux?

[Marcin Romaszewicz]

Threads are scheduled by the operating system, which has many syscalls to
manage their execution status. When Delve hits an interrupt (trap)
instruction for a breakpoint, it asks the OS to suspend all the other OS
threads. Goroutine thread stacks are managed by Go, and Delve inspects all
those stacks to show you goroutines. So, when a goroutine hits a
breakpoint, its underlying OS thread hits a trap, and in this trap handler,
all the other OS threads are stopped, see here for example:

https://github.com/go-delve/delve/blob/master/pkg/proc/native/proc_linux.go#L546

-- Marcin

On Wed, Jun 9, 2021 at 6:48 AM xie cui  wrote:

> as for as i known, in linux, seting a breakpoint means we set int 3
> instruction to the right place, it's easy to understand in single core os
> for me. but what happen when it's multi-core multi-thread enviroment like
> go program. using goland when set a breakpoint, when the breakpoint hit, it
> seems all the thread of the process is pause, how delve stop other thread
> that no run to the breakpoint, i am confused.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/2e6cadaa-51e4-49d5-9a49-6f6ee97d1055n%40googlegroups.com
> 
> .
>

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

[go-nuts] Releasing a V2 module and interacting with git branches

[Marcin Romaszewicz]

Hi All,

I need to release a V2 of my module. (
https://github.com/deepmap/oapi-codegen). I understand what to do on the Go
side in terms of the /v2 suffix and go.mod changes, but I'm a little bit
unclear how this works w.r.t git branches. Yes, I've looked at
https://golang.org/ref/mod#vcs-find

My plan is to do development in a "v2" branch, which which will
occasionally be rebased onto the "master" branch until that's no longer
feasible, at which point I'll cherry pick or port important commits from
master to v2.

The v2 branch will start off with an annotated tag named "v2.0.0-alpha".
and will begin to diverge from master, which is tagged with v1.x.x

When I am ready to release the V2 branch, I plan to do the following.

Top commit in master becomes a new branch, "v1", and any future V1 bug
fixes go here.

I will merge the V2 branch into master, and tag it as v2.0.0.

Does this sounds like a reasonable plan? I would like, for the time being,
for people to be able to work on V1 in master, and eventually master will
become V2 while V1 is a branch.

My alternative is to create a V1 branch today, and all future work in
master is V2.

-- Marcin

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

Re: [go-nuts] Re: Alternate implementations of regular expression matching?

[Marcin Romaszewicz]

I have nothing useful to contribute to this discussion, however, I've been
doing this long enough to remember Jamie Zawinski's quote about regular
expressions :)

Some people, when confronted with a problem, think "I know, I'll use
> regular expressions." Now they have two problems.
>

https://blog.codinghorror.com/regular-expressions-now-you-have-two-problems/

On Thu, Apr 1, 2021 at 3:36 PM Amnon  wrote:

> Worth mentioning Russ Cox's series of blog posts on Regular Expressions
> and their implementation https://swtch.com/~rsc/regexp/
>
>
>
> On Thursday, 1 April 2021 at 21:21:14 UTC+1 Brian Candler wrote:
>
>> If you can live with cgo dependencies, then you might want to look at a
>> go wrapper around PCRE, which is the "go-to" implementation for
>> fully-featured regexps.
>>
>> e.g. https://github.com/rubrikinc/go-pcre  (untested by me, and it's one
>> of several forks)
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/bb9db3d5-f9da-4324-80bf-48fbcc43b29en%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Can I import a package from a git submodule?

[Marcin Romaszewicz]

It's really annoying to deal with when you have private repositories, but
try to simply `import RepoB/bar` from ModuleA, and don't bother with the
submodule stuff. Module SHAs will replicate submodule functionality in a
way that's more compatible with the language.

On Wed, Mar 31, 2021 at 1:46 PM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> AIUI, if you nest modules (that is, a subdirectory of a module containing
> a directory with its own `go.mod`), the "inner" module is not considered
> part of the "outer" module. In particular, it would also not be included in
> the module zip (which is the primary way modules are distributed - *not* as
> repositories).
>
> So, AIUI, `foo/baz/bar` is technically a valid import path, but it's not
> "inside" module `foo`, so to speak.
>
> On Wed, Mar 31, 2021 at 9:46 PM cpu...@gmail.com 
> wrote:
>
>> Consider this layout:
>>
>>
>>- Repo A contains module foo
>>- Repo B contains module bar (of course ;)
>>- Repo B is added as submodule to repo A at /baz
>>
>>
>> I was expecting that I can
>>
>> import "foo/baz/bar"
>>
>> in repo A, but that leads to error ("no required module provides
>> package...").
>>
>> Shouldn't this work as the import path is a perfectly valid import path
>> inside module foo?
>>
>> Cheers,
>> Andi
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/1f2bab6e-47cf-4f80-9a66-3a8bad2869ban%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEbky861b0h%2B0SaRh13by3DtmpnrRTqjnAjT1wQ_CZkEg%40mail.gmail.com
> 
> .
>

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

[go-nuts] Question on module versioning expected behavior

[Marcin Romaszewicz]

I recently hit a little issue with go.mod versioning that's confusing me.
My go.mod is straightforward:
https://github.com/deepmap/oapi-codegen/blob/master/go.mod

One of the packages in there is kin-openapi at v0.47.0:
github.com/getkin/kin-openapi v0.47.0

We briefly had some code in the repo which referred to some files which
weren't present in kin-openapi@v0.47.0, but these files were present in
kin-openapi@0.52.0
https://github.com/deepmap/oapi-codegen/pull/322

I would have expected that files not being present in 0.47.0 would result
in a compiler error, but instead, what happened is that my go.mod had its
kin-openapi requirement increased to 0.52.0 automatically by go build.

It's surprising to me that Go is smart enough to figure out that a
subsequent version of that module contains what I'm looking for, and it
updates go.mod. In my case, this isn't the behavior that I wanted. So, is
there a way disable this automated roll-up? I want my code to break if I
refer to something in a newer package.

Thanks,
-- Marcin

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

Re: [go-nuts] running tests against benchmarks

[Marcin Romaszewicz]

What you want to do is common, but it's application-specific enough that
there aren't so many generalized solutions. What I've always done is create
a Go program which takes a while to run (I shoot for at least a minute)
which runs your BeefyFunc in various ways that make sense to you, then I
make a Jenkins Job which runs it on every commit on fixed hardware, and
uploads timings to some kind of metrics database like DataDog or
Prometheus. Both of those have alert triggers on outliers. I realize this
doesn't help much if you don't have DataDog, Prometheus or Jenkins.

-- Marcin

On Mon, Mar 15, 2021 at 10:45 AM Jeremy French  wrote:

> I keep running into this solution to a particular problem, but when I go
> to search on how to do it, I find that not only are there seemingly no
> solutions out there in search-results-land, there doesn't seem to be anyone
> else even asking about it.  This then leads me to suspect, that I'm going
> about it in completely the wrong mindset, and I'd appreciate anyone helping
> me see how everyone else is solving this problem.
>
> The issue is this:  Let's say I have some function - call it BeefyFunc() -
> that is heavily relied upon and executed many times per second in my
> high-traffic, high-availability critical application.  And let's say that
> BeefyFunc() is very complex in the sense that it calls many other functions
> which call other functions, etc, and these called functions are spread out
> all over the code base, and maintained by a broad and distributed
> development team (or even just one forgetful, overworked developer).  If
> BeefyFunc() currently executes at 80 ns/op on my development machine, I
> want to make sure that no one makes some change to an underlying function
> which causes BeefyFunc to balloon up to 800 ns/op.  And more to the point,
> if that ballooning does happen, I want someone to be notified, not to have
> to rely on a QA person's ability to notice a problem while scanning the
> benchmark reports.  I want that problem to be highlighted in the same way a
> test failure would be.
>
> So it seems like the logical solution would be to create a test that runs
> a benchmark and makes sure the benchmark results are within some acceptable
> range.  I realize that benchmarks are going to differ from machine to
> machine, or based on CPU load, etc.  But it seems like it would still be
> useful in a CI/CD situation or on my personal dev machine, where the
> machine hardware is stable and known and the CPU load can be reasonably
> predicted, that at least a sufficiently wide range for benchmarks could be
> reasonably enforced and tested for.
>
> Am I being stupid? Or is this a solved problem and it's just my google-fu
> that's failing me?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7adf598e-03a8-456a-a52f-824a8d1832e3n%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Golang Problems

[Marcin Romaszewicz]

We're not going to do your homework for you, but some things to consider:

- maps are good at associating values with names
- there's a strings.ToLower()
 function you will find
useful
- sort.Ints  sorts ints in ascending
order
- if s is a string, s[0] is a rune
- if r is a rune, string(r) is a 1 character string

These are bits of Go that you will find helpful in solving your assignment.

On Sat, Feb 27, 2021 at 7:02 PM Vignesh Kumar  wrote:

> Hello all,
>
> Thanks in advance. Please help me to finish this assignments.
>
> Write a program which will accept a string. This program should output all
> the characters and number of their occurrences, in order of their
> occurrences. So that, character appearing most number of times should be
> printed first and characters appearing least number of times (i.e. 1 time)
> should appear at the last. Capital and small characters should be
> considered as same. Only spaces in the input string should not be counted.
>
> Example: Input string is "Hello there", it should output: e: 3, h: 2, l:
> 2, o:1, i: 1, t : 1, r: 1 *
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b608f1a5-d833-4bf1-b954-61598e30f808n%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Contrary to popular opinion...

[Marcin Romaszewicz]

Given the writing on the wall that GOPATH is going away, what I have done
is created a single module where I keep all my own code, each different
experiment in its own subdirectory. I named it "github.com/...", but never
submitted it to github, so in the future I can do that without too much
fuss if I wanted to.

Having been writing Go heavily since 1.2, I find the all-code-in-one-module
approach to be the easiest so far.

-- Marcin


On Thu, Feb 25, 2021 at 4:21 PM Bob Alexander  wrote:

> Agreed -- module mode is great for "delivered code". But in a personal
> single machine single developer environment, all the extra complexity and
> manual overhead might not worth it. I'd guess that most students and
> hobbyists don't even use SCMs. My point was that GOPATH mode is good for
> them.
>
> On Thu, Feb 25, 2021 at 1:38 PM Robert Engels 
> wrote:
>
>> That is 100% true but a important point is that using GOPATH requires
>> manual dependency management via ‘vendoring’. This can be very labor
>> intensive and error prone - leading to security issues in your delivered
>> code.
>>
>> On Feb 25, 2021, at 3:08 PM, Bob Alexander  wrote:
>>
>> 
>> GOPATH mode does *not *limit your Go code to a single directory. I've
>> seen this misunderstanding stated in probably hundreds of various posts.
>>
>> $GOPATH allows specification of multiple directories.  I've used that
>> capability for several years to distribute my Go code to my personal
>> general library and to various application-specific libraries. Each of the
>> multiple GOPATH directories refers to a Go "workspace", so the result is my
>> general library workspace plus mini-workspaces in various application
>> directories -- each with src, pkg, and bin subdirectories. A single go
>> install installs all workspaces specified in your GOPATH at once, or you
>> can selectively build by temporarily changing the GOPATH.
>>
>> This is a pretty good setup for me, a decades-experienced software
>> engineer working in "programmer" mode for my personal development.
>>
>> Go's goal of ending GOPATH mode sounds like a choice to serve the
>> professional software engineer, and not the personal programmer. Module
>> mode is a good thing if you are publishing your code, but is a lot of
>> additional labor and cognitive load for us "programmers".
>>
>> I wonder if this might discourage adoption of Go by certain categories
>> such as college and high school students, non-software-engineer
>> professionals who write internal programs for their business, and curious
>> folks who want to introduce themselves to Go. It is s much easier to
>> set up my environment with GOPATH mode. In attempting conversion to MODULE
>> mode, I've spent lots of frustrating hours and it's still not working
>> perfectly!
>>
>> So, I am +1 for retention of GOPATH mode (as well as MODULE mode),
>> allowing Go users to make the choice of MODULE vs. GOPATH based on their
>> needs.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAKyHfRPYgop6YPgk3AcJ4Q43NgV%3D9KP%3DzgYja8Z6FJuc0UuPig%40mail.gmail.com
>> 
>> .
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAKyHfRPw125S_800nhBxV9UrqHCaet-8WAO2q%2B1Xah3dhNiS5w%40mail.gmail.com
> 
> .
>

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

Re: [go-nuts] Data Structure in Go

[Marcin Romaszewicz]

What are you looking to learn about data structures? Data structures in Go
work the same as in any other language conceptually, just the language
syntax to implement the concepts will be different. One of the most
commonly used books on data structures and algorithms is the Cormen,
Leiserson, Rivest, Stein book, Introduction to Algorithms
.
Section 3, Data Structures, is perhaps the best overview you can find.

-- Marcin

On Fri, Feb 19, 2021 at 8:57 AM Rahul kauraiya 
wrote:

> Hello Experts,
> I am completely new to this programming language. I am highly interested
> in learning data structures in Go.
> I am not able to find any good resource to learn in deep.
> Please share valuable resources to this thread.
>
> Thanks and  regards,
> Rahul Kauraiya
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/68cf3ce0-976c-474e-a617-95d54287n%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] R.I.P. Michael Jones

[Marcin Romaszewicz]

I will miss MTJ. I've worked with him on and off over 23 years, starting at
Silicon Graphics, then as a customer when he founded Intrinsic Graphics,
and finally in Google's GEO division. He was incredibly intelligent, a
great teacher, and an extreme pedant :) RIP, Michael.

-- Marcin

On Thu, Feb 4, 2021 at 3:13 PM Jan Mercl <0xj...@gmail.com> wrote:

>
> https://www.geospatialworld.net/blogs/goodbye-michael-jones-the-man-who-gave-the-power-of-maps-in-our-hands/
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-WMyrNU32vXVD4%2B0iMwSCRgvP5ZeP-W9oV6%2BiyprgfjGA%40mail.gmail.com
> 
> .
>

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

Re: [go-nuts] init() in package main won't run :-/

[Marcin Romaszewicz]

Your `var db=initDB()` runs before init(), and it returns an error, so the
program aborts.

Here's a change which initializes db explicitly in the init function, and
it works as you expect:
https://play.golang.org/p/xsUU2hfnx-w

The init function is called after all variable initializations happen, look
here:
https://golang.org/doc/effective_go.html#initialization

On Tue, Jan 12, 2021 at 9:27 AM Martin Ziebiker 
wrote:

> Hello, please does anyone know why init() won't run?
>
> Thank You very much!
>
> https://play.golang.org/p/0PDUJlF8X1w
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5809011a-ceaf-45ff-993b-59641dfabd7fn%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] sql string not interpolated as expected

[Marcin Romaszewicz]

Don't use fmt.Sprintf for the actual values, generate the positional
arguments yourself.

Something like:

q := "SELECT x FROM t WHERE y IN (%s)"

labelName := []string{'carnivore', 'mammal', 'vertebrate'}

var arrayArgs []string
for i := range labelName {
  arrayArgs = append(arrayArgs, fmt.Sprintf("$%d", i+1))
}

db.Exec(fmt.Sprintf(q, strings.Join(",", names)), arrayArgs...)

This will escape each element of the array - dynamically allocate


On Sun, Jan 3, 2021 at 2:21 PM Alexander Mills 
wrote:

> labels are variable arguments, so I don't know how to do it..i solved it
> for the time being using `fmt.Sprintf` but that leaves me vulnerable to sql
> injection I suppose.
>
>
> On Sun, Jan 3, 2021 at 8:58 AM 'Brian Candler' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> I think the nearest is:
>>
>> labelStrs := []interface{}{"carnivore", "mammal", "vertebrate"}
>> rows, err := c.Database.Db.Query(`
>> select id from mbk_user_label where label_name in (?,?,?)
>> `, labelStrs...)
>>
>> Of course, you may need to change the number of question-marks to match
>> len(labelStrs), but that's easily done with a helper function.  It would be
>> nice if a placeholder could be a list and expand accordingly, though.
>>
>> On Sunday, 3 January 2021 at 09:29:25 UTC Reto wrote:
>>
>>> On Sun, Jan 03, 2021 at 12:53:03AM -0800, Alexander Mills wrote:
>>> > rows, err := c.Database.Db.Query(`
>>> >
>>> > select *, (
>>> > select count(*) from mbk_file_label
>>> > where file_id = mbk_file.id and label_id IN (
>>> > select id
>>> > from mbk_user_label
>>> > where label_name IN (
>>> > $2
>>> > )
>>> > )
>>> > ) as xxx
>>> > from mbk_file
>>> > where user_id = $1
>>> > order by xxx DESC
>>> > `,
>>> > loggedInUserId,
>>> > labelStr,
>>> > )
>>> >
>>> >
>>> > then the query doesnt work and I dont know why?
>>>
>>> You might want to debug log your statements in the database engine...
>>> What you want to do is not what it's doing.
>>>
>>> You ask the sql engine to escape the input you give it.
>>>
>>> So your question becomes `where label_name in ('"carnivore", "mammal",
>>> "vertebrate"')`
>>> Meaning the string exactly as given as single element.
>>>
>>> Maybe that helps: https://stackoverflow.com/a/38878826/6212932 if you
>>> use postgres.
>>>
>>> Cheers,
>>> Reto
>>>
>> --
>> 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/PdzePaSYlUc/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/67dabe1f-e99a-43c4-a686-528227b38f28n%40googlegroups.com
>> 
>> .
>>
>
>
> --
> Alexander D. Mills
> New cell phone # (415)730-1805
> linkedin.com/in/alexanderdmills
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CA%2BKyZp6GO08_JY7jNuKuQNN-GQV%3DL%2B910Cq1jtu57NF%2BV%3DF-BQ%40mail.gmail.com
> 
> .
>

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

Re: [go-nuts] Generics - please provide real life problems

[Marcin Romaszewicz]

Those are simple examples of real world problems. I've been writing Go
since the very beginning, having worked at Google when it was released and
since I enjoy the language so much, I try to write all the backend server
code in Go that I can. In these years, I've had to write many code
generators to make my life a little easier, and they tend to be for data
structures or API models.

Generics would allow for writing less code, and re-using it more. As long
as it doesn't complicate the base language, why not? You don't have to use
them :)

On Wed, Dec 23, 2020 at 11:18 PM Martin Hanson 
wrote:

> I'm sorry, but this is not real life problems. This is exactly the problem
> with this proposal. It's based on nothing but small theoretical examples.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/16410701608794283%40vla5-c5051da8689e.qloud-c.yandex.net
> .
>

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

Re: [go-nuts] when do you use sync.Mutex instead of sync.RWMutex

[Marcin Romaszewicz]

Code using a simple sync.Mutex is also simpler, since you only have one way
to lock and unlock and you don't have to think about lock type when writing
code. In my opinion, use sync.Mutex, and if it proves to be inefficient,
start investigating alternatives. In most cases, your simple code will work
well enough. It's much more important to keep your critical sections small
and quick than tweaking mutex behavior.

As others have said, RWMutex is great for cache-like things, but could
actually work poorly in other access patterns.

On Sun, Dec 20, 2020 at 4:16 AM Robert Engels  wrote:

> A cache almost always uses a RW mutex or a lock free technique like copy
> on write/CAS to avoid contention.
>
> A simple mutex is fine for less performance critical code with guaranteed
> exclusive/sequential access needs. Many transaction modes are implemented
> with a simple lock/mutex.
>
> On Dec 20, 2020, at 6:59 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> 
> Unless I specifically know that a variable will be written rarely and read
> often, I tend to use `Mutex`. I'm too worried that the preferential
> treatment of write-locks in an `RWMutex` leads to surprising
> contention-issues if there isn't an overwhelming relationship between their
> frequencies. I also assume - given that it has the more complicated
> semantics - that a `Mutex` is generally cheaper than an `RWMutex`, all
> things being equal.
>
> So I tend to handle it the exact opposite of what you suggest - unless I
> have a specific reason to use `RWMutex`, I default to `Mutex`.
>
> On Sun, Dec 20, 2020 at 9:44 AM 김용빈  wrote:
>
>> we usually both read and write for a value. not only read, nor write.
>>
>> with that, I feel RWMutex is always right choice.
>>
>> when should I use Mutex instead of RWMutex?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/f597de36-b296-4f59-b756-adb1248387f5n%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEvPFgq-cQ41Bi%3D4OtaNait-k-2iXG3yWTb8Yj%2BjHDM3Q%40mail.gmail.com
> 
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/2A9FF454-BD0C-4594-B3E9-FD1364077689%40ix.netcom.com
> 
> .
>

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

Re: [go-nuts] printing an empty slice with fmt.Printf()

[Marcin Romaszewicz]

It's expected behavior.

Your for loop runs once for l=0, since your condition is <=0 because
len([]byte{}) is 0.

-- Marcin


On Fri, Dec 18, 2020 at 3:28 PM Jochen Voss  wrote:

> Hello,
>
> I can print slices of bytes as hex strings, using code like the following:
>
> x := []byte{0, 1, 2, 3}
> fmt.Printf("%02x", x[:l])
>
> This gives the output "00010203" as expected.  But this fails for the
> empty slice: running
>
> x := []byte{}
> fmt.Printf("%02x", x[:l])
>
> gives "00" instead of the empty string.  See
> https://play.golang.org/p/rvLLqydDDE6 for a demonstration.
>
> Is this a bug, or is this expected behaviour?
>
> All the best,
> Jochen
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/bb8774f3-aa17-4044-8435-ed1cd162976cn%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] When does net/http's Client.Do return io.EOF?

[Marcin Romaszewicz]

It's uncommon to talk directly to a server these days, instead, we have
proxies and load balancers along the way as well, and there are many
reasons that a connection would get closed and you'd get an io.EOF. It's
unlikely that the server received the request in this case, but it's
possible, depending on how the proxies work.

You need to design API's with that in mind. On the server side, you must
assume the client will retry, and so, you must reject duplicate requests.
On the client side, you should retry everything except an HTTP/400 class
error. It's now a common pattern that requests may include an idempotency
token of some kind to aid the server in rejecting duplicates.

-- Marcin



On Mon, Dec 7, 2020 at 2:58 AM Gregor Best  wrote:

> Hi!
>
> We're using a 3rd party provider's API to handle some of our customer
> requests. Interaction with their API consists of essentially POST'ing
> a small XML document to them.
>
>  From time to time, `net/http`'s `Client.Do` returns an `io.EOF`
> when sending the request. For now, the provider always reported
> those instances as "we didn't get your request".
>
> Cursory search in various Github issues and a glance at the source
> of `net/http` seems to indicate that `io.EOF` is almost always
> caused by the server closing the connection, but the client not
> getting the "it's now closed" signal before it tries to re-use the
> connection.
>
> FWIW, `fasthttp`'s HTTP client implementation treats `io.EOF` as
> "this request needs to be retried", but I don't know how much that
> knowledge transfers to `net/http`.
>
> Is my interpretation of the situation correct? Or are there other
> circumstances where the request _did_ end up at the remote end and
> `io.EOF` is returned?
>
> I guess what I'm asking is: Is it safe (as in: requests won't end
> up on the remote twice or more times) to retry POST requests when
> `Client.Do` returns an `io.EOF`?
>
> Note that disabling connection reuse (as was suggested by a number
> of stackoverflow posts) is an option that we'd like to avoid unless
> there's absolutely no other way to handle this.
>
> --
>Gregor Best
>b...@pferdewetten.de
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a31d42a5-6a81-0579-a380-b268d10f4eb0%40pferdewetten.de
> .
>

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

Re: [go-nuts] Syntactic Sugar Idea for Go 2.0: until/unless, and postfix conditionals

[Marcin Romaszewicz]

Indeed!

Go has while loops :)

for {
  // do some stuff
  if !condition { break }
}

instead of
{
  // do some stuff
} while condition

They are identical functionally, so why bother with the second syntax? You
then get into arguments about which one to use.

-- Marcin

On Tue, Nov 3, 2020 at 11:31 AM 'Amnon Cohen' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Languages often have a whole variety of loop constructs.
> C has for loops as well us while loops.
> Go adopts the principle from the Zen of python:
>
> *There should be one-- and preferably only one --obvious way to do it. *It
> takes a minimalist approach - there is only one looping construct: the for
> loop.
>
> This is an excellent decision, IMO.
>
>
>>>
> Red Sift is the power behind OnDMARC and OnINBOX.
>
> You can find us at 21A Noel Street, 4th Floor, London, W1F 8GR.
>
>
> Red Sift is a limited company registered in England and Wales. Registered
> number: 09240956. Registered office: Kemp House, 152 City Road, London,
> EC1V 2NX.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8d492b26-4784-448f-9714-79c43bc93527n%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Structs for JSON APIs and required fields... using pointers

[Marcin Romaszewicz]

I don't know if there's any standard practice to it. If the meaning of the
zero value and "not present" is different in your application, then
clearly, you can't use the zero value as you can't tell them apart, while
you can with a pointer. The sql package does it with a version of optionals
(https://golang.org/pkg/database/sql/#NullString), while others use
pointers as optionals. In my own project for validating API requests, I use
the swagger spec to validate (
https://github.com/deepmap/oapi-codegen#generated-server-boilerplate).

On Fri, Oct 30, 2020 at 1:45 PM Trig  wrote:

> What is the standard practice between required fields of a struct you're
> expecting to deserialize using JSON, and using pointers for this (if
> there's any correlation)?
>
> API defined a string as required.  Do you define it as a string and check
> for zero-value for that type, or *string and check for nil, etc.?  Any
> other situations/instances were it's best practice to user a pointer for
> defining struct fields over the standard type?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/26d5e7f0-83e0-40eb-8274-5d9791f29b77n%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Re: differentiate if a value was set or not

[Marcin Romaszewicz]

A concrete example of an "Optional" implementation in present in the sql
package:
https://golang.org/src/database/sql/sql.go?s=4943:5036#L178

In SQL, it's common to have "null" values be distinct from zero values, so
the DB package has a struct with the value and a flag whether the value was
present.

As others have said, you can already build this, it's just not part of
built in language syntax.

-- Marcin

On Fri, Oct 23, 2020 at 4:15 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> On Fri, Oct 23, 2020 at 12:17 AM Ian Lance Taylor  wrote:
>
>> So there are several possible approaches.  I'm guessing you want one
>> that is more implicit, but as a general guideline Go tends to prefer
>> explicit code.
>>
>>
> I don't think there is a good implicit approach to this problem. If you
> have a value that is optional, it has to be modeled as such in your system.
> The `*bool` representation is precise: `nil` maps to the bottom of the
> domain, and `true`/`false` maps to the values of the domain. The only way
> to work with such a type is to match on it to determine if the pointer is
> nil, followed by inspection of the boolean value. Generally, optional
> values need somewhere in the program where they are scrutinized, and you
> can't avoid that scrutiny. You can try to hide it with some clever implicit
> construction, but that is very likely to lead to subtle errors in programs.
> People might want to treat `nil` as an exception case, but it really isn't.
> It is a value like any other value, and should be treated as such in the
> program.
>
> The approach taken by e.g., OCaml is that there is no `nil` in the
> language at all. Rather, there is a `'a ref` type, but that cannot be
> initialized to be `nil`. It always references something valid. You can then
> mint your own `nil` by means of an option type:
>
> type 'a option = None | Some of 'a
>
> However, the underlying representation is much akin to that of a typical
> pointer value. What has this gained us? Well, we can now create
>
> type 'a option2 = None2 | Some2 of 'a
>
> for instance. This type is *different* from the first one, yet has the
> same underlying representation. Thus, we can avoid a problem in the Go
> `*bool` solution: namely conflation of pointer representations with
> optional values; we simply mint a new type. I think this is more explicit
> and more precise in representation. And it's solution would work well for
> the originally proposed case.
>
> As an aside, this leads to an important design point: if pointers are used
> as optional values (and not for the sake of sharing/optimization) stripping
> away the pointer often leads to code that is easier to work with since you
> avoid that pesky nil-check all over the place and can do with it in one
> place. Also, the astute reader might have caught on to the fact that the
> same observation holds true for error values, which in OCaml are defined as:
>
> type 'a err = Err of 'a
> type ('a, 'b) result = Err of 'a | Ok of 'b
>
> If we now recognize there is a unit type with one inhabitant, you can see
> that an `'a option` is really just a `(unit, 'b) result`. That is, there is
> a good type-theoretic reason for your observation.
>
>
>
>
>
> --
> J.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiWjsL-hyp3%2Bch8aRaHFxiFqZekbcHPVcftV7SpXLMiCeQ%40mail.gmail.com
> 
> .
>

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

Re: [go-nuts] Any embedded scripting language for Go

[Marcin Romaszewicz]

Lua is probably your easiest bet:
https://github.com/Shopify/go-lua

On Tue, Oct 20, 2020 at 10:33 PM Aravindhan K 
wrote:

> Hi,
>
> I am looking for a way to build interactive app,where user will be giving
> instructions to draw as a script,rendering of the script will be displayed
> live.
> I would like to use below 2d drawing package for same,
> github.com/fogleman/gg
>
> Is there scripting language that would be able generate bindings to
> arbiratory go packages back and forth? and I could embed it in Go App as
> well.
>
> Thanks,
> Aravindhan K
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAJn1S2PBV00Zb2Tpb%2Be02t5uAAKxOiFNJaiNX02ES_NT_FD91g%40mail.gmail.com
> 
> .
>

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

Re: [go-nuts] Golang slow performance inside for loop MySQL Queries

[Marcin Romaszewicz]

Can you connect to that DB any faster from the same machine not using Go?

-- Marcin

On Wed, Oct 21, 2020 at 3:43 AM Bill  wrote:

> Hello,
> I created the sql to fetch all info in one call instead of multiple calls
> per each row.
>
> One thing I noticed about golang is that when I ping my Remote DB from
> localhost (running in vscode) I get ping -> 1.573826274s. So I think this
> is the reason that all my calls to db are delayed.
> Have you any idea what can be the issue? Maybe a clean install of Golang
> in MacOSX could fix this issue? If I test the code in server (upload the
> binary) the response time is normal (200ms - 300ms).
>
> My Code to ping:
>
> begin := time.Now()
> err := Config.DB.Ping()
> log.Printf("Ping in %s (%v)", time.Since(begin), err)
> Στις Τρίτη, 20 Οκτωβρίου 2020 στις 8:19:16 μ.μ. UTC+3, ο χρήστης
> mar...@gmail.com έγραψε:
>
>> Go's database layer is generally pretty quick, I use it a lot, but your
>> code immediately sets off my DB alarms, because you are doing queries
>> within the body of another query loop, which means you're opening up lots
>> of connections, which could be slow.
>>
>> I'd reorganize as followd.
>>
>> - Cache the results of your first query into an array, it's only 6
>> results.
>> - Create two prepared statements, one for each query inside the loop.
>> - Loop over your array of 6 results, and execute each prepared statement
>> instead of parsing the query each time.
>>
>> By doing it this way, you should use 1 connection for the entire loop,
>> and you'll only be parsing statements once each.
>>
>> If this is still slow, I'd start looking at your database performance,
>> maybe.
>>
>> also, "defer rows.Close()" after you've checked if the query didn't
>> result an error. There are no rows to close if err != nil
>>
>> -- Marcin
>>
>>
>>
>> On Tue, Oct 20, 2020 at 9:52 AM  wrote:
>>
>>> I use Go with github.com/go-sql-driver/mysql to connect to MySQL. The
>>> performance in Go vs other languages is terrible or I'm missing something.
>>>
>>> I use Go for my REST API, an example is below:
>>>
>>> We have a table with posts. We fetch the posts, on each post we search
>>> favorites table (if user has favorited this post and if he likes it).
>>>
>>> posts := make([]*MembersModel.Post, 0, 6)
>>>
>>> postsResults, err := Config.DB.Query("SELECT id, b64, title,
>>> description, total_likes,  total_favorites, published_date  FROM posts
>>> ORDER BY id DESC LIMIT 6")
>>>
>>> defer postsResults.Close()
>>>
>>> if err != nil {
>>> fmt.Println(err)
>>> panic(err.Error())
>>> }
>>>
>>> for postsResults.Next() {
>>> var postID int
>>> var b64 string
>>> var title string
>>> var description string
>>> var total_likes int
>>> var total_favorites int
>>> var published_date string
>>>
>>> postsResults.Scan(, , , , _likes,
>>> _favorites, _date)
>>>
>>> var count int
>>> var favorited string
>>>
>>> fetchBookmarks := Config.DB.QueryRow("SELECT COUNT(*) FROM
>>> favorites where userID = ? and postID = ? and status = ?", userID, postID,
>>> "added").Scan()
>>>
>>> if fetchBookmarks != nil {
>>> fmt.Println("error")
>>> }
>>>
>>> if count == 0 {
>>> favorited = "no"
>>> } else {
>>> favorited = "yes"
>>> }
>>>
>>> var countSubmitted int
>>> var likedPost string
>>>
>>> fetchLikes := Config.DB.QueryRow("SELECT COUNT(*) FROM likes
>>> where userID = ? and postID = ? and status=?", userID, postID,
>>> "liked").Scan()
>>>
>>> if fetchLikes != nil {
>>> fmt.Println("error")
>>> }
>>>
>>> if countSubmitted == 0 {
>>> likedPost = "no"
>>> } else {
>>> likedPost = "yes"
>>> }
>>>
>>> post := {
>>> PostID:b64,
>>> Title: title,
>>> Description: description,
>>> Likes:   total_likes,
>>> PubDate:   published_date,
>>> Bookmarked:   favorited,
>>> Liked: likedPost,
>>> }
>>>
>>> posts = append(posts, post)
>>> }
>>>
>>> Average time to fetch these results -> 10 seconds!
>>>
>>> If I exclude the MYSQL calls inside the loop, the time to fetch these
>>> results is 300ms.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/e3f758d8-595f-4f0d-9aa6-d0b87899007fo%40googlegroups.com
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 

Re: [go-nuts] Golang slow performance inside for loop MySQL Queries

[Marcin Romaszewicz]

Go's database layer is generally pretty quick, I use it a lot, but your
code immediately sets off my DB alarms, because you are doing queries
within the body of another query loop, which means you're opening up lots
of connections, which could be slow.

I'd reorganize as followd.

- Cache the results of your first query into an array, it's only 6 results.
- Create two prepared statements, one for each query inside the loop.
- Loop over your array of 6 results, and execute each prepared statement
instead of parsing the query each time.

By doing it this way, you should use 1 connection for the entire loop, and
you'll only be parsing statements once each.

If this is still slow, I'd start looking at your database performance,
maybe.

also, "defer rows.Close()" after you've checked if the query didn't result
an error. There are no rows to close if err != nil

-- Marcin



On Tue, Oct 20, 2020 at 9:52 AM  wrote:

> I use Go with github.com/go-sql-driver/mysql to connect to MySQL. The
> performance in Go vs other languages is terrible or I'm missing something.
>
> I use Go for my REST API, an example is below:
>
> We have a table with posts. We fetch the posts, on each post we search
> favorites table (if user has favorited this post and if he likes it).
>
> posts := make([]*MembersModel.Post, 0, 6)
>
> postsResults, err := Config.DB.Query("SELECT id, b64, title, description,
> total_likes,  total_favorites, published_date  FROM posts ORDER BY id DESC
> LIMIT 6")
>
> defer postsResults.Close()
>
> if err != nil {
> fmt.Println(err)
> panic(err.Error())
> }
>
> for postsResults.Next() {
> var postID int
> var b64 string
> var title string
> var description string
> var total_likes int
> var total_favorites int
> var published_date string
>
> postsResults.Scan(, , , , _likes,
> _favorites, _date)
>
> var count int
> var favorited string
>
> fetchBookmarks := Config.DB.QueryRow("SELECT COUNT(*) FROM
> favorites where userID = ? and postID = ? and status = ?", userID, postID,
> "added").Scan()
>
> if fetchBookmarks != nil {
> fmt.Println("error")
> }
>
> if count == 0 {
> favorited = "no"
> } else {
> favorited = "yes"
> }
>
> var countSubmitted int
> var likedPost string
>
> fetchLikes := Config.DB.QueryRow("SELECT COUNT(*) FROM likes where
> userID = ? and postID = ? and status=?", userID, postID,
> "liked").Scan()
>
> if fetchLikes != nil {
> fmt.Println("error")
> }
>
> if countSubmitted == 0 {
> likedPost = "no"
> } else {
> likedPost = "yes"
> }
>
> post := {
> PostID:b64,
> Title: title,
> Description: description,
> Likes:   total_likes,
> PubDate:   published_date,
> Bookmarked:   favorited,
> Liked: likedPost,
> }
>
> posts = append(posts, post)
> }
>
> Average time to fetch these results -> 10 seconds!
>
> If I exclude the MYSQL calls inside the loop, the time to fetch these
> results is 300ms.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e3f758d8-595f-4f0d-9aa6-d0b87899007fo%40googlegroups.com
> .
>

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

Re: [go-nuts] net/http TLS issue

[Marcin Romaszewicz]

Having a passcode to protect a key file for a production service is
pointless, because you move the problem of storing the certificate securely
to the problem of storing the passcode securely, so might as well skip the
passcode and store the cert securely.

Your certificate is probably encoded as a PEM cert, so you'd have to
manually call https://golang.org/pkg/crypto/x509/#DecryptPEMBlock and
provide a password, then construct your listener yourself using the
unmarshaled certificate. So, how are you going to protect this passcode? Is
someone going to have to provide it every time you start?

Generally, in production systems, we use some kind of secret manager to
store that certificate, such as AWS Secrets Manager or encrypt it with KMS,
store it in Vault, etc. Ideally, you actually make a subordinate cert for
that service and rotate it at a reasonable interval.

On Fri, Oct 16, 2020 at 2:06 PM Rich  wrote:

> I don't know if we're the only company on the planet that demands the
> https keys have a passcode to them but I've been having a heck of a time
> trying to find a good way to serve https using a key with a passphrase.
>
> err := ListenAndServeTLS(addr, certFile, keyFile string
> , handler Handler
> )
>
> If they keyFile has a passcode this doesn't work and the examples I've
> seen take this one line and turn it into a much longer chunk of 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c75fc8f6-abe4-4614-8281-cef4cb315ac3n%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] ECDSA signature verification

[Marcin Romaszewicz]

Yes, in my experience, the C SSL libraries are much faster than Go's
implementation on curves P384 and P521, however, Go's tuned implementation
of P256 curves is comparable to OpenSSL performance (
https://golang.org/src/crypto/elliptic/). If you look in the directory I
linked, you'll see that it has assembly language implementations of the
P256 curve.

Practically, there isn't much reason today to use the P384 and P521 curves.
The security provided by P256 is very good, not known to be crackable
today, and it's a widely supported curve. P384 is reasonably well
supported, but not as widely, and P521 isn't well supported at all, since
it's not in the NSA Suite B crypto recommendations, which drive many crypto
standards.

-- Marcin


On Thu, Oct 8, 2020 at 8:40 AM Shobhit Srivastava 
wrote:

> Thanks for the detailed explanation for your issue.
> Thanks for the pointers for the library. Just a quick question, do you
> think calling C library from Go can give great results for 521 curve.
>
>
>
> On Thu, 8 Oct 2020, 21:03 Marcin Romaszewicz,  wrote:
>
>> My issue was slightly different than yours, in that I was burning way too
>> much CPU verifying 384 bit client certificates for TLS. The solution was to
>> have nginx do TLS termination, and proxy decrypted traffic to my Go server,
>> rather than doing TLS termination in Go.
>>
>> The first place I would start looking is either the LibreSSL or OpenSSL
>> libraries. LibreSSL is a cleanup of OpenSSL, which has grown messy over the
>> years. Both of these contain a crypto library which does what you want.
>> Here is what it looks like in LibreSSL:
>> https://man.openbsd.org/ECDSA_SIG_new.3
>>
>> -- Marcin
>>
>> On Thu, Oct 8, 2020 at 2:30 AM Shobhit Srivastava 
>> wrote:
>>
>>> Hey Marcin
>>>
>>> Can you give me the pointer on C library and if can be used in Cgo .
>>>
>>> Thanks
>>>
>>> On Wed, 7 Oct 2020, 22:27 Shobhit Srivastava, 
>>> wrote:
>>>
>>>> Yeah the inclination is towards 512 curve only so need to optimise it.
>>>>
>>>> Will check out the C library. Thanks
>>>>
>>>>
>>>>
>>>> On Wed, 7 Oct 2020, 22:22 Marcin Romaszewicz, 
>>>> wrote:
>>>>
>>>>> secp256r1 has been hand optimized for performance, the others haven't.
>>>>>
>>>>> If performance there matters to you, it's actually faster to call out
>>>>> to C libraries to verify 384 and 512 bit curves.
>>>>>
>>>>> On Wed, Oct 7, 2020 at 9:27 AM Shobhit Srivastava <
>>>>> simplysh...@gmail.com> wrote:
>>>>>
>>>>>> Hi All
>>>>>>
>>>>>> I have tried to do the performance analysis for different curve in
>>>>>> golang and got below output:
>>>>>> for secp256r1 I got 28000 Signature verified per second
>>>>>> for secp384r1 I got 1600 Signature verified per second
>>>>>> for secp521r1 I got 700 Signature verified per second
>>>>>>
>>>>>> Is there something I did wrong or is this the usual results?
>>>>>>
>>>>>> Let me know if someone has done performance comparison.
>>>>>>
>>>>>> Best,
>>>>>> Shobhit
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "golang-nuts" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to golang-nuts+unsubscr...@googlegroups.com.
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/golang-nuts/fdc14759-b995-43af-948d-cdb2201e4718n%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/golang-nuts/fdc14759-b995-43af-948d-cdb2201e4718n%40googlegroups.com?utm_medium=email_source=footer>
>>>>>> .
>>>>>>
>>>>>

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

Re: [go-nuts] ECDSA signature verification

[Marcin Romaszewicz]

My issue was slightly different than yours, in that I was burning way too
much CPU verifying 384 bit client certificates for TLS. The solution was to
have nginx do TLS termination, and proxy decrypted traffic to my Go server,
rather than doing TLS termination in Go.

The first place I would start looking is either the LibreSSL or OpenSSL
libraries. LibreSSL is a cleanup of OpenSSL, which has grown messy over the
years. Both of these contain a crypto library which does what you want.
Here is what it looks like in LibreSSL:
https://man.openbsd.org/ECDSA_SIG_new.3

-- Marcin

On Thu, Oct 8, 2020 at 2:30 AM Shobhit Srivastava 
wrote:

> Hey Marcin
>
> Can you give me the pointer on C library and if can be used in Cgo .
>
> Thanks
>
> On Wed, 7 Oct 2020, 22:27 Shobhit Srivastava, 
> wrote:
>
>> Yeah the inclination is towards 512 curve only so need to optimise it.
>>
>> Will check out the C library. Thanks
>>
>>
>>
>> On Wed, 7 Oct 2020, 22:22 Marcin Romaszewicz,  wrote:
>>
>>> secp256r1 has been hand optimized for performance, the others haven't.
>>>
>>> If performance there matters to you, it's actually faster to call out to
>>> C libraries to verify 384 and 512 bit curves.
>>>
>>> On Wed, Oct 7, 2020 at 9:27 AM Shobhit Srivastava 
>>> wrote:
>>>
>>>> Hi All
>>>>
>>>> I have tried to do the performance analysis for different curve in
>>>> golang and got below output:
>>>> for secp256r1 I got 28000 Signature verified per second
>>>> for secp384r1 I got 1600 Signature verified per second
>>>> for secp521r1 I got 700 Signature verified per second
>>>>
>>>> Is there something I did wrong or is this the usual results?
>>>>
>>>> Let me know if someone has done performance comparison.
>>>>
>>>> Best,
>>>> Shobhit
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "golang-nuts" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/golang-nuts/fdc14759-b995-43af-948d-cdb2201e4718n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/golang-nuts/fdc14759-b995-43af-948d-cdb2201e4718n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>

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

Re: [go-nuts] ECDSA signature verification

[Marcin Romaszewicz]

secp256r1 has been hand optimized for performance, the others haven't.

If performance there matters to you, it's actually faster to call out to C
libraries to verify 384 and 512 bit curves.

On Wed, Oct 7, 2020 at 9:27 AM Shobhit Srivastava 
wrote:

> Hi All
>
> I have tried to do the performance analysis for different curve in golang
> and got below output:
> for secp256r1 I got 28000 Signature verified per second
> for secp384r1 I got 1600 Signature verified per second
> for secp521r1 I got 700 Signature verified per second
>
> Is there something I did wrong or is this the usual results?
>
> Let me know if someone has done performance comparison.
>
> Best,
> Shobhit
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/fdc14759-b995-43af-948d-cdb2201e4718n%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Re: Proper way of mocking interfaces in unit tests - the golang way

[Marcin Romaszewicz]

On Mon, Oct 5, 2020 at 10:31 AM Vladimir Varankin 
wrote:

> > Or, it will be written as assert.Equal(got, want,
> fmt.Sprintf("MyFunction(%v)", input)), but that is harder to write, and
> therefore less likely to be written.
>
> That obviously depends on the implementation details but since we talk
> about testify the API is: assert.Equal(t, want, got, format, [args...]).
>

The testify assert/require code may be a little backwards and verbose when
compared to a naked t.Error(), however, it provides a lot of helper
functions for comparing types and values which results in much clearer,
shorter tests in the end. You can assert.EqualValues() to ignore type, for
example, or do deep compares without having to code that yourself. I'd say
it's wonderful.



>
> On Mon, 5 Oct 2020 at 18:45, Ian Lance Taylor  wrote:
>
>> On Mon, Oct 5, 2020 at 8:47 AM Viktor Kojouharov 
>> wrote:
>> >
>> > I don't find any difference between calling t.Errorf and
>> assert.Something with a provided message. Both will populate the test log,
>> with the later giving you more details exactly where things differ from the
>> expectation.
>>
>> The difference is that since people write t.Error while writing the
>> test, it's very easy to provide all the relevant information, which in
>> many cases will involve more than just the values being compared.  A
>> common example would be a message like "MyFunction(%v) = %v, want %v".
>> When using an assert style function, the message will tend to lose the
>> value passed to MyFunction.  Or, it will be written as
>> assert.Equal(got, want, fmt.Sprintf("MyFunction(%v)", input)), but
>> that is harder to write, and therefore less likely to be written.
>> (It's also less efficient in the common case, though for a test that
>> is unlikely to matter.)
>>
>> Ian
>>
>> --
>> 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/ZoJ5isoeea4/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXNV6bLQQUFmVn14xnxheALTKbv1_oQODovboLEziPKSw%40mail.gmail.com
>> .
>>
>
>
> --
> Vladimir Varankin
> vladi...@varank.in
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAGLqCMmj7NB3Sem0BDdyJBj-cxGXVmBY-6StRXAP6MvwZUyOnQ%40mail.gmail.com
> 
> .
>

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

Re: [go-nuts] Re: How to create UTC date without extra UTC string

[Marcin Romaszewicz]

See https://golang.org/pkg/time/#Time.Format

Here's how to use it. I think this is exactly what you want:
https://play.golang.org/p/3r0TFtOmtqF

On Wed, Sep 23, 2020 at 11:43 AM Alex Mills  wrote:

> My guess, is that a starting place would be something like:
>
>
> *var s = time.Now().UTC().String()[0:24]*
>
> an example of which looks like:
>
> "2020-09-23 18:41:43.1568"
>
> so I guess I just to know if there is a reliable way to parse that string
> back into a date using multiple programming languages.
>
>
>
> On Wednesday, September 23, 2020 at 11:39:08 AM UTC-7 Alex Mills wrote:
>
>> I have this date string:
>>
>> "2020-09-23 18:31:41.015852841 + UTC"
>>
>> the above is generated via:
>>
>>
>> *time.Now().UTC().String()*
>>
>> my question is, how can I generate a date string like this:
>>
>> "2020-09-23 18:31:41.0158"
>>
>> and how can I then parse it?  I dont need to indicate that it's UTC, I
>> can *assume* it's UTC.
>> But I want to include 4 decimal points.  1 digit more granular than
>> milliseconds, whatever that's called (trivia!).
>>
>> -alex
>>
>>
>>
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5aa0fbde-fc12-4e9a-a5bf-a8a1d8a76b76n%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Cross compiling for linux from dawin

[Marcin Romaszewicz]

Your compiler environment for C code is still building for Darwin, most
likely. You need to set up a cross compiler and use cgo (
https://golang.org/cmd/cgo/). $CC should invoke your cross compiler.

On Tue, Sep 22, 2020 at 11:19 AM Mixo Ndleve  wrote:

> Experiencing this problem when "github.com/cvigo/go_ibm_db" is imported
>
> ../../../go/pkg/mod/
> github.com/lunny/godbc@v0.0.0-20131220142036-57f94ee1eb13/api/api.go:13:9:
> undefined: SQLSMALLINT
> ../../../go/pkg/mod/
> github.com/lunny/godbc@v0.0.0-20131220142036-57f94ee1eb13/api/api.go:14:9:
> undefined: SQLUSMALLINT
> ../../../go/pkg/mod/
> github.com/lunny/godbc@v0.0.0-20131220142036-57f94ee1eb13/api/api.go:15:9:
> undefined: SQLUSMALLINT
> ../../../go/pkg/mod/
> github.com/lunny/godbc@v0.0.0-20131220142036-57f94ee1eb13/api/api.go:19:12:
> undefined: SQLSMALLINT
> ../../../go/pkg/mod/
> github.com/lunny/godbc@v0.0.0-20131220142036-57f94ee1eb13/api/api.go:20:12:
> undefined: SQLUSMALLINT
> ../../../go/pkg/mod/
> github.com/lunny/godbc@v0.0.0-20131220142036-57f94ee1eb13/api/api.go:21:12:
> undefined: SQLUSMALLINT
> ../../../go/pkg/mod/
> github.com/lunny/godbc@v0.0.0-20131220142036-57f94ee1eb13/api/api.go:22:12:
> undefined: SQLUSMALLINT
> ../../../go/pkg/mod/
> github.com/lunny/godbc@v0.0.0-20131220142036-57f94ee1eb13/api/api.go:23:12:
> undefined: SQLUSMALLINT
> ../../../go/pkg/mod/
> github.com/lunny/godbc@v0.0.0-20131220142036-57f94ee1eb13/api/api.go:24:12:
> undefined: SQLUSMALLINT
> ../../../go/pkg/mod/
> github.com/lunny/godbc@v0.0.0-20131220142036-57f94ee1eb13/api/api.go:25:12:
> undefined: SQLUINTEGER
> ../../../go/pkg/mod/
> github.com/lunny/godbc@v0.0.0-20131220142036-57f94ee1eb13/api/api.go:25:12:
> too many errors
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/bd1c2b60-8459-46d8-a022-0527f0fba150n%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] database/sql doesn't return error for query-string-destination if NULL bug or feature

[Marcin Romaszewicz]

Which sqlite driver are you using? That sounds like a bug.

On Fri, Sep 11, 2020 at 10:56 AM Stephan Lukits 
wrote:

> I passed a string-type pointer (as last destination) to a sql.DB.Query
> call which had a NULL value as field value. No error was returned and all
> other fields got the appropriate values but the connection was silently
> closed.  I noticed because it was an in-memory (sqlite3) database which all
> of a sudden appeard empty.
>
> I could fix the problem for me by passing a sql.NullString instead of a
> string destination.  Maybe its interesting to know.
>
> Kind regards Stephan
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/f639a2d4-46c0-4798-8be4-6fddd198ac5an%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Workflow and tools for JSON Schema generation

[Marcin Romaszewicz]

Oh wow, my email client showed your email in a truncated way, so i didn't
see you were already using my project, sorry for the silly response.

It would be possible to add external type definitions to oapi-codegen, I
believe. I'm in the process of thinking about a v2 version which is more
stable, and less convoluted. V1 was a learning experience.

On Fri, Sep 4, 2020 at 10:56 AM Marcin Romaszewicz 
wrote:

> Have you considered reversing the workflow? You write the OpenAPI spec,
> and have a code generator produce the Schemas and server boilerplate?
>
> If that's ok, check out my project :)
> https://github.com/deepmap/oapi-codegen
>
> We successfully use it for many API's in production.
>
> -- Marcin
>
>
> On Thu, Sep 3, 2020 at 12:06 AM Johann Höchtl 
> wrote:
>
>>
>> Hi,
>> I would like to accomplish the following:
>>
>> An existing golang package on github provides a struct definition I am
>> interested in to be used as part of a REST API interface I design
>>
>>1. I would like to automatically go generate json schema for this
>>struct
>>2. I would like to incorporate this generated schema into an OpenAPI
>>definition and generate go boilerplate for that
>>
>>
>> For step 2 I am using https://github.com/deepmap/oapi-codegen which
>> works great. It also supports $ref to external schemas.
>>
>> Still looking to accomplish step 1: I am searching for a tool which go
>> generates JSON schema from a golang source file or package. Any help?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/f0e099de-7008-478d-ba92-f2febd0c40bdn%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/f0e099de-7008-478d-ba92-f2febd0c40bdn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

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

Re: [go-nuts] Workflow and tools for JSON Schema generation

[Marcin Romaszewicz]

Have you considered reversing the workflow? You write the OpenAPI spec, and
have a code generator produce the Schemas and server boilerplate?

If that's ok, check out my project :)
https://github.com/deepmap/oapi-codegen

We successfully use it for many API's in production.

-- Marcin


On Thu, Sep 3, 2020 at 12:06 AM Johann Höchtl 
wrote:

>
> Hi,
> I would like to accomplish the following:
>
> An existing golang package on github provides a struct definition I am
> interested in to be used as part of a REST API interface I design
>
>1. I would like to automatically go generate json schema for this
>struct
>2. I would like to incorporate this generated schema into an OpenAPI
>definition and generate go boilerplate for that
>
>
> For step 2 I am using https://github.com/deepmap/oapi-codegen which works
> great. It also supports $ref to external schemas.
>
> Still looking to accomplish step 1: I am searching for a tool which go
> generates JSON schema from a golang source file or package. Any help?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/f0e099de-7008-478d-ba92-f2febd0c40bdn%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Re: Share GOMODCACHE between unix users

[Marcin Romaszewicz]

Yes, each user would populate their own module cache locally if using your
own proxy.

On Wed, Aug 19, 2020 at 10:04 AM wilk  wrote:

> On 19-08-2020, Marcin Romaszewicz wrote:
> > --71f06b05ad3dc9f8
> > Content-Type: text/plain; charset="UTF-8"
> >
> > I have many users building Go at my company, and instead of sharing the
> > module cache on the filesystem, a much better approach is to use a
> caching
> > module proxy, such as Athens (https://github.com/gomods/athens).
> >
> > See the documentation for the GOPROXY environment variable.
>
> With an alternate GOPROXY the GOMODCACHE of each users are still filled
> isn'it ?
>
> I've started an issue :
> https://github.com/golang/go/issues/40895
>
> --
> William Dodé
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/rhjm1l%24b2d%241%40ciao.gmane.io
> .
>

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

Re: [go-nuts] Share GOMODCACHE between unix users

[Marcin Romaszewicz]

I have many users building Go at my company, and instead of sharing the
module cache on the filesystem, a much better approach is to use a caching
module proxy, such as Athens (https://github.com/gomods/athens).

See the documentation for the GOPROXY environment variable.

-- Marcin

On Wed, Aug 19, 2020 at 9:39 AM wilk  wrote:

> Hi,
>
> I would like to have a global GOMODCACHE for all unix users, or a group of
> users to gain space and speed. I trust all the users.
>
> Using the same GOMODCACHE for all users doesn't works, the perms are only
> writable by the user running the build.
>
> Is there a workaround ? Could it be a feature ?
>
> Thanks
>
> --
> William
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/rhim4i%24u2p%241%40ciao.gmane.io
> .
>

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

Re: [go-nuts] Pipe multiple commands in golang

[Marcin Romaszewicz]

You have two options here.

One, is you execute a shell, and just tell the shell to run your command,
eg bash -c "strings dynamic_file_path | grep regex".

The other option is that you exec strings and grep independently, and
connect the two of them using an os.pipe, but it's a lot more work to do
this and get exiting working properly - you must close the pipe when either
side has an error, etc.



On Wed, Aug 12, 2020 at 8:41 AM thatipelli santhosh <
santhoshthatipelli...@gmail.com> wrote:

> Hi all,
>
> I have requirement to execute a command like cmd : *strings
> dynamic_file_path | grep regex*
>
> I don't know what is the best way to do this like any well known library
> or standard way.
>
> Can you please help here?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAN1Sb7y2DdZJP30cfxRKr%3DFKgFsc1Kp%2Bdzqe0pd3qAt4JDg6LQ%40mail.gmail.com
> 
> .
>

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

Re: [go-nuts] Re: Quick question about calling Set-Cookie twice in a row

[Marcin Romaszewicz]

The Go http code calls Header.Add() on your cookie, and Header.Add will
concatenate values together. If you want replacement semantics, you'll have
to clearout the "Set-Cookie" header on the response, or only add your final
cookie.

On Tue, Jul 14, 2020 at 4:58 PM B Carr  wrote:

> In my application, the most recent cookie value with the same name is
> returned on the next request.
>
> On Tuesday, July 14, 2020 at 1:54:56 PM UTC-6, atd...@gmail.com wrote:
>>
>> Hello,
>>
>> As I am writing some tests, I was wondering what should be the correct
>> behavior when http.SetCookie is called twice with cookies of a same name
>> but different values.
>>
>> For example, what should a user-agent see as the cookie value and hence,
>> what should it return back to the server with the next request?
>>
>> https://play.golang.org/p/nYDmcFcd8Qj
>>
>> Many 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/442794c0-c906-4472-ba8a-6017a22e19e8o%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] What can cause a process launched via os.exec to sporadically die from SIGPIPE

[Marcin Romaszewicz]

Thanks for the tip, I wasn't aware that happened! I'll use os.Pipe.

-- Marcin


On Mon, Jul 6, 2020 at 4:45 PM Ian Lance Taylor  wrote:

> On Mon, Jul 6, 2020 at 4:42 PM Marcin Romaszewicz 
> wrote:
> >
> > Yes, I am using io.Pipe, and passing in the PipeWriter side of it as
> Stdout and Stderr on Cmd.
>
> I'm glad you figured out the problem, but I want to note that you
> almost certainly want to be using os.PIpe rather than io.Pipe.
> io.Pipe is intended for communication between goroutines.  os.PIpe is
> used between processes.  If you use an io.PIpe as exec.Cmd.Stdout or
> exec.Cmd.Stderr, then the os/exec package will quitely create a pipe
> using os.PIpe, pass that to the child, and start a goroutine to read
> from that os.PIpe and write to the io.Pipe.
>
> Ian
>
>
>
>
> > I figured out the problem, though. The executable which I am launching
> is doing a write on a non-existent file descriptor upon shutdown, which
> generates a SIGPIPE, per strace:
> >
> > write(75,
> "\25\3\3\0\32,v\352\5!.v\3536\205\246N\33Y*\233t\354\246t\356Jf5\377\366",
> 31) = -1 EPIPE (Broken pipe)
> >
> > That file descriptor had never been opened - it seems to be a random
> value due to memory corruption.
> >
> >
> >
> > On Mon, Jul 6, 2020 at 3:15 PM Ian Lance Taylor  wrote:
> >>
> >> On Sun, Jul 5, 2020 at 4:14 PM Marcin Romaszewicz 
> wrote:
> >> >
> >> > On Sun, Jul 5, 2020 at 1:05 PM Ian Lance Taylor 
> wrote:
> >> >>
> >> >> On Sun, Jul 5, 2020 at 10:54 AM Marcin Romaszewicz <
> marc...@gmail.com> wrote:
> >> >> >
> >> >> > I'm hitting a problem using os.exec Cmd.Start to run a process.
> >> >> >
> >> >> > I'm setting Cmd.Stdio and Cmd.Stderr to the same instance of an
> io.Pipe, and spawn a Goroutine to consume the pipe reader until I reach
> EOF. I then call cmd.Start(), do some additional work, and call cmd.Wait().
> The runtime of the executable I launch is 15-30 minutes, and stdout/stderr
> output is minimal, a few 10's of kB during this 15-30 minute run.
> >> >> >
> >> >> > When the pipe reaches EOF or errors out, I close the pipe reader,
> exit the goroutine reading the pipe, and that's when cmd.Wait() returns,
> exactly as documented.
> >> >> >
> >> >> > This works exactly as described about 70% of the time. The
> remaining 30% of the time, cmd.Wait()  returns an error, which stringifies
> as "signal: broken pipe". I'm running thousands of copies of this
> executable across thousands of instances in AWS, so I have a big data set
> here. The broken pipe error happens at the very end when my exec'd
> executable is exiting, so as far as I can tell, it's run successfully and
> is hitting this error on exit.
> >> >> >
> >> >> > I realize that SIGPIPE and EPIPE are common ways that processes
> clean each other up, and that shells do a lot of work hiding them, so I've
> also tried using exec.Cmd to spawn bash, which in turn runs my executable,
> but I still get a lot of these deaths due to SIGPIPE.
> >> >> >
> >> >> > I've tried to reproduce this with simple commands - like `cat
> `, and none of these simple commands ever result in the
> broken pipe, and I capture all their output without issue. The command I'm
> running differs in that it uses quite a lot of resources and the machine is
> doing significant work when the executable is exiting. However, the sigpipe
> is being received by the application, not my Go code, implying that the Go
> side is closing the pipe. I can't find where this is happening.
> >> >> >
> >> >> > Any tips on how to chase this down?
> >> >>
> >> >> The executable is dying due to receiving a SIGPIPE signal.  As you
> >> >> know, that means that it made a write system call to a pipe that had
> >> >> no open readers.  If you're confident that you are reading all the
> >> >> data from the pipe in the Go program, then the natural first thing to
> >> >> check is the other possible pipe: if you are reading from stdout,
> >> >> check what happens on stderr, and vice-versa.
> >> >>
> >> >> Since that probably won't help, since you can reproduce it with some
> >> >> reliability, try running the whole system under strace -f.  That will
> >> >> show you the system calls both of your program and of the subprocess,
> >> >> and should let you determine exactly which write is trigge

Re: [go-nuts] What can cause a process launched via os.exec to sporadically die from SIGPIPE

[Marcin Romaszewicz]

Yes, I am using io.Pipe, and passing in the PipeWriter side of it as Stdout
and Stderr on Cmd.

I figured out the problem, though. The executable which I am launching is
doing a write on a non-existent file descriptor upon shutdown, which
generates a SIGPIPE, per strace:

write(75,
"\25\3\3\0\32,v\352\5!.v\3536\205\246N\33Y*\233t\354\246t\356Jf5\377\366",
31) = -1 EPIPE (Broken pipe)

That file descriptor had never been opened - it seems to be a random value
due to memory corruption.



On Mon, Jul 6, 2020 at 3:15 PM Ian Lance Taylor  wrote:

> On Sun, Jul 5, 2020 at 4:14 PM Marcin Romaszewicz 
> wrote:
> >
> > On Sun, Jul 5, 2020 at 1:05 PM Ian Lance Taylor  wrote:
> >>
> >> On Sun, Jul 5, 2020 at 10:54 AM Marcin Romaszewicz 
> wrote:
> >> >
> >> > I'm hitting a problem using os.exec Cmd.Start to run a process.
> >> >
> >> > I'm setting Cmd.Stdio and Cmd.Stderr to the same instance of an
> io.Pipe, and spawn a Goroutine to consume the pipe reader until I reach
> EOF. I then call cmd.Start(), do some additional work, and call cmd.Wait().
> The runtime of the executable I launch is 15-30 minutes, and stdout/stderr
> output is minimal, a few 10's of kB during this 15-30 minute run.
> >> >
> >> > When the pipe reaches EOF or errors out, I close the pipe reader,
> exit the goroutine reading the pipe, and that's when cmd.Wait() returns,
> exactly as documented.
> >> >
> >> > This works exactly as described about 70% of the time. The remaining
> 30% of the time, cmd.Wait()  returns an error, which stringifies as
> "signal: broken pipe". I'm running thousands of copies of this executable
> across thousands of instances in AWS, so I have a big data set here. The
> broken pipe error happens at the very end when my exec'd executable is
> exiting, so as far as I can tell, it's run successfully and is hitting this
> error on exit.
> >> >
> >> > I realize that SIGPIPE and EPIPE are common ways that processes clean
> each other up, and that shells do a lot of work hiding them, so I've also
> tried using exec.Cmd to spawn bash, which in turn runs my executable, but I
> still get a lot of these deaths due to SIGPIPE.
> >> >
> >> > I've tried to reproduce this with simple commands - like `cat
> `, and none of these simple commands ever result in the
> broken pipe, and I capture all their output without issue. The command I'm
> running differs in that it uses quite a lot of resources and the machine is
> doing significant work when the executable is exiting. However, the sigpipe
> is being received by the application, not my Go code, implying that the Go
> side is closing the pipe. I can't find where this is happening.
> >> >
> >> > Any tips on how to chase this down?
> >>
> >> The executable is dying due to receiving a SIGPIPE signal.  As you
> >> know, that means that it made a write system call to a pipe that had
> >> no open readers.  If you're confident that you are reading all the
> >> data from the pipe in the Go program, then the natural first thing to
> >> check is the other possible pipe: if you are reading from stdout,
> >> check what happens on stderr, and vice-versa.
> >>
> >> Since that probably won't help, since you can reproduce it with some
> >> reliability, try running the whole system under strace -f.  That will
> >> show you the system calls both of your program and of the subprocess,
> >> and should let you determine exactly which write is triggering the
> >> SIGPIPE, and let you verify that the read end of the pipe has been
> >> closed.
> >>
> >> And if that doesn't help, perhaps you can modify the subprocess to
> >> catch SIGPIPE and get a stack trace, again with the goal of finding
> >> out exactly what write is failing.
> >>
> >> Hope this helps.
> >
> >
> > Thanks for the tips.
> >
> > The comment on Stdout and Stderr on cmd says:
> >
> > // If Stdout and Stderr are the same writer, and have a type that can
> > // be compared with ==, at most one goroutine at a time will call Write.
> >
> > Using an io.Pipe shared between these two should result in both being
> drained correctly, right?
>
> I guess I don't see how that affects what I said one way or another.
>
> Although, let me back up a second: are you really using an io.Pipe
> rather than an os.Pipe?  An io.Pipe shouldn't lead to a SIGPIPE
> signal.
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29Lt6QWAxN6TnuXCm0bjRrmxZ%3DuOJX7K36gjzXJ5BrnaCBw%40mail.gmail.com.

Re: [go-nuts] What can cause a process launched via os.exec to sporadically die from SIGPIPE

[Marcin Romaszewicz]

On Sun, Jul 5, 2020 at 1:05 PM Ian Lance Taylor  wrote:

> On Sun, Jul 5, 2020 at 10:54 AM Marcin Romaszewicz 
> wrote:
> >
> > I'm hitting a problem using os.exec Cmd.Start to run a process.
> >
> > I'm setting Cmd.Stdio and Cmd.Stderr to the same instance of an io.Pipe,
> and spawn a Goroutine to consume the pipe reader until I reach EOF. I then
> call cmd.Start(), do some additional work, and call cmd.Wait(). The runtime
> of the executable I launch is 15-30 minutes, and stdout/stderr output is
> minimal, a few 10's of kB during this 15-30 minute run.
> >
> > When the pipe reaches EOF or errors out, I close the pipe reader, exit
> the goroutine reading the pipe, and that's when cmd.Wait() returns, exactly
> as documented.
> >
> > This works exactly as described about 70% of the time. The remaining 30%
> of the time, cmd.Wait()  returns an error, which stringifies as "signal:
> broken pipe". I'm running thousands of copies of this executable across
> thousands of instances in AWS, so I have a big data set here. The broken
> pipe error happens at the very end when my exec'd executable is exiting, so
> as far as I can tell, it's run successfully and is hitting this error on
> exit.
> >
> > I realize that SIGPIPE and EPIPE are common ways that processes clean
> each other up, and that shells do a lot of work hiding them, so I've also
> tried using exec.Cmd to spawn bash, which in turn runs my executable, but I
> still get a lot of these deaths due to SIGPIPE.
> >
> > I've tried to reproduce this with simple commands - like `cat
> `, and none of these simple commands ever result in the
> broken pipe, and I capture all their output without issue. The command I'm
> running differs in that it uses quite a lot of resources and the machine is
> doing significant work when the executable is exiting. However, the sigpipe
> is being received by the application, not my Go code, implying that the Go
> side is closing the pipe. I can't find where this is happening.
> >
> > Any tips on how to chase this down?
>
> The executable is dying due to receiving a SIGPIPE signal.  As you
> know, that means that it made a write system call to a pipe that had
> no open readers.  If you're confident that you are reading all the
> data from the pipe in the Go program, then the natural first thing to
> check is the other possible pipe: if you are reading from stdout,
> check what happens on stderr, and vice-versa.
>
> Since that probably won't help, since you can reproduce it with some
> reliability, try running the whole system under strace -f.  That will
> show you the system calls both of your program and of the subprocess,
> and should let you determine exactly which write is triggering the
> SIGPIPE, and let you verify that the read end of the pipe has been
> closed.
>
> And if that doesn't help, perhaps you can modify the subprocess to
> catch SIGPIPE and get a stack trace, again with the goal of finding
> out exactly what write is failing.
>
> Hope this helps.
>

Thanks for the tips.

The comment on Stdout and Stderr on cmd says:

// If Stdout and Stderr are the same writer, and have a type that
can// be compared with ==, at most one goroutine at a time will call
Write.

Using an io.Pipe shared between these two should result in both being
drained correctly, right?



> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29Lte-C%2BfZ8U4YAiOA%3DLrUJ1ZUMcZakDpQ4nOO0%2Bj_Ts%2B7A%40mail.gmail.com.

[go-nuts] What can cause a process launched via os.exec to sporadically die from SIGPIPE

[Marcin Romaszewicz]

Hi All,

I'm hitting a problem using os.exec Cmd.Start to run a process.

I'm setting Cmd.Stdio and Cmd.Stderr to the same instance of an io.Pipe,
and spawn a Goroutine to consume the pipe reader until I reach EOF. I then
call cmd.Start(), do some additional work, and call cmd.Wait(). The runtime
of the executable I launch is 15-30 minutes, and stdout/stderr output is
minimal, a few 10's of kB during this 15-30 minute run.

When the pipe reaches EOF or errors out, I close the pipe reader, exit the
goroutine reading the pipe, and that's when cmd.Wait() returns, exactly as
documented.

This works exactly as described about 70% of the time. The remaining 30% of
the time, cmd.Wait()  returns an error, which stringifies as "signal:
broken pipe". I'm running thousands of copies of this executable across
thousands of instances in AWS, so I have a big data set here. The broken
pipe error happens at the very end when my exec'd executable is exiting, so
as far as I can tell, it's run successfully and is hitting this error on
exit.

I realize that SIGPIPE and EPIPE are common ways that processes clean each
other up, and that shells do a lot of work hiding them, so I've also tried
using exec.Cmd to spawn bash, which in turn runs my executable, but I still
get a lot of these deaths due to SIGPIPE.

I've tried to reproduce this with simple commands - like `cat
`, and none of these simple commands ever result in the
broken pipe, and I capture all their output without issue. The command I'm
running differs in that it uses quite a lot of resources and the machine is
doing significant work when the executable is exiting. However, the sigpipe
is being received by the application, not my Go code, implying that the Go
side is closing the pipe. I can't find where this is happening.

Any tips on how to chase this down?

Thanks,
-- Marcin

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

Re: [go-nuts] [generics] Thank you Go team

[Marcin Romaszewicz]

I'd like to add a big +1 here. The proposal around contracts and generics
is solid from a conceptual perspective, and I enjoyed reading the rationale
behind what's supported, and what isn't, and I think this is a wonderful
addition to the language which keeps type safety in a very Go-like way
despite all the flexibility. It's really good language design, and the
syntax won't change what we can do with it. I look forward to simplifying a
lot of my code once this ships by reusing many data structures I've
implemented separately for many types. I have a whole team working on Go
code in production, so I just have to wait until it's shipped officially
and is stable.

Thank you Go Team. I was a Googler when Go was created, and I remember Rob
Pike saying that one of the reasons behind it was to keep programming fun,
to take out the drudge work, and it's been amazingly successful in that
regard.
-- Marcin

On Thu, Jun 18, 2020 at 7:17 PM Michael Jones 
wrote:

> I doubt this will help, but I have to try...
>
> Really smart and accomplished people have worked for a year to refine the
> generics approach--as the impressive updated design draft and the scholarly
> FeatherweightGo paper both demonstrate. The design is accompanied with
> tools to allow development and experience by any interested Go developer.
> This is marvelous. Thank you Go team and helpers!
>
> Let's post about substantial things in the design ("generic type switch
> necessary at day one" maybe, whatever) and not only about parenthesis. I'm
> going crazy here seeing all the comments about that. I mean, think of how
> hard they are working on this; parenthesis posts read like *More Cowbell *to
> me.
>
> Sorry for the outburst,
> Michael
>
> P.S. I challenge you to fully read the Featherweight Go paper and the
> design draft, as I did, and then come away thinking about the expression of
> the idea rather than the idea. I just can't comprehend it -- it is the
> ideas that hold power and beauty, that will transform our daily work.
>
> --
>
> *Michael T. jonesmichael.jo...@gmail.com *
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CALoEmQyzv%3D4JxtJjpqC6R5u%3DkwjMtYH%3Die9H3KQYWyB3U%2B1Ybg%40mail.gmail.com
> 
> .
>

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

Re: [go-nuts] Best practice for Database Open and Close connection

[Marcin Romaszewicz]

Behind the scenes, DB is actually a connection pool, not a single
connection, which will open new connections when you need them.

In our services - which do a LOT of DB work, we only open a single sql.DB
connection and share it among all our handlers. Whenever a handler does a
db.Whatever, the db object will allocate a real DB connection when needed,
so we only open and close the DB in the main function, and pass it down to
all the users. You only really need multiple sql.DB's if you open the DB
with different login arguments.

Generally, you want to do something like this wherever you open a sql.DB
connection:
db, err := sql.Open()
if err != nil { do error stuff}
defer db.Close()

If you have a single DB configuration, I'd recommend only having a single
global sql.DB that everything in your code shares.


On Wed, May 27, 2020 at 11:52 AM srikanth c  wrote:

> what is the best practice when we are using database\sql package for
> sql.Open and db.close(). I have scenario where i have to multiple function
> and each function is responsible to hit the database and fetch the data. In
> this case do we need write sql.open() and db.close() in each of those
> functions.
>
> Please find the three file and rough layout of my code. If I’m using this
> approach. what would be the best possible way to follow with best practices.
>
>1. *main.go*
>func main() {
>router := mux.NewRouter()
>controller :=
>controllers.Controller{}router.HandleFunc("/protectedEndpoint",
>controller.GetStudents).Methods(“GET”)
>router.HandleFunc("/signup", controller.GetBook).Methods(“GET”)
>router.HandleFunc("/login", controller.GetReports).Methods(“GET”)
>}
>2. *controller.go*
>
> func GetStudents(w http.ResponseWriter, r *http.request){
> //fetch request param and call the repository method to fetch data from db
> studentId := r.URL.Query().get("id)
> repository.GetStudents(studentId)
> }
>
> func GetBook(w http.ResponseWriter, r *http.request){
> //fetch request param and call the repository method to fetch data from db
> bookId := r.URL.Query().get("id)
> repository.GetBook(bookId)
> }
>
> func GetReports(w http.ResponseWriter, r *http.request){
> //fetch request param and call the repository method to fetch data from db
> studentId := r.URL.Query().get("id)
> repository.GetReports(studentId)
> }
>
>1. *repository.go*
>
> import database/sql
>
> func GetStudents(studentId int){
> db, err := sql.open( driverName, connectionString)
> if err != nil {
> log.panic(err)
> }
> defer db.close()
> row, err := db.query(“select * from student where studentId = :0”,
> studentId)
> if err != nil {
> log.panic(err)
> }
> defer row.close()
> //iterate through the row
> }
>
> func GetBook(bookId int){
> db, err := sql.open( driverName, connectionString)
> if err != nil {
> log.panic(err)
> }
> defer db.close()
> row, err := db.query(“select * from book where bookId = :0”, bookId)
> if err != nil {
> log.panic(err)
> }
> defer row.close()
> //iterate through the row
> }
>
> func GetReports(studentId int){
> db, err := sql.open( driverName, connectionString)
> if err != nil {
> log.panic(err)
> }
> defer db.close()
> row, err := db.query(“select * from reports where studentId = :0”,
> studentId)
> if err != nil {
> log.panic(err)
> }
> defer row.close()
> //iterate through the row
>
> }
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/2c3ca567-0923-4f63-9b79-a1fd46df0d21%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Get name of struct implementing interface using interface method, reflection

[Marcin Romaszewicz]

Go isn't polymorphic, whenever your String() function is called, it's on
BaseFoo, you have to do it like this:

https://play.golang.org/p/69rw0jRPalz

On Fri, May 8, 2020 at 1:43 PM Glen Newton  wrote:

> Thanks!
>
> Oh no, when I try that here: https://play.golang.org/p/RV-S4MJWYUi
> Did not work: similar results: instead of:
>
> BaseFoo
> BaseFoo
> BaseFoo
> BaseFoo
>
> now I get:
> main.BaseFoo
> main.BaseFoo
> main.BaseFoo
> main.BaseFoo
>
> Other suggestions?  :-)
>
> Thanks,
> Glen
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/53e2c85d-9417-4108-abe3-da436b146fb7%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Re: recommended approach for loading private keys requiring passwords

[Marcin Romaszewicz]

Haha, great minds think alike, as they say. One of my colleagues (from a
cloud security company) wrote basically the same thing in Go:
https://github.com/cloudtools/ssh-cert-authority

There's also a really fantastic product that works via signed SSH certs
called Teleport , from
Gravitational, also written in Go. The basic version is open source, but
the really useful version with things like SAML federation, is a paid
product.

On Sat, May 2, 2020 at 1:51 PM Brian Candler  wrote:

> The more I think about it, the more I like the self-referential nature of
> sshagentca talking to ssh-agent to sign certificates to distribute to
> another ssh-agent :-)
>
> The main security weakness I can see is that ssh-agent will sign any data
> you give it - hence anyone who gets direct access to the socket could sign
> themselves a certificate with infinite lifetime.  ssh-agent can run another
> process as a direct child, but I think they still communicate via a unix
> domain socket.
>
> BTW, I think sshagentca is a fantastic little project.  One of the things
> I've just tested is using a U2F token (ecdsa-sk), as introduced in OpenSSH
> 8.2.  It works perfectly with sshagentca, which then issues me with a
> regular key and certificate (ECDSA-CERT 384).  This type of key and
> certificate works with older versions of sshd, meaning you can use
> sshagentca to bootstrap your security from U2F keys without having to
> upgrade sshd on all your hosts. Very neat indeed.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6fc082c1-318f-4037-8d5b-aa9710e5eb23%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Is this a safe way to block main thread but not main goroutine?

[Marcin Romaszewicz]

As Thomas said, this will work for sure, though, and doesn't require any
manual setup, and you don't need to do funny business with CGO.

func main() {
  go doAllYourOtherStuff()
  blockOnDarwinEventLoop()
}

Done.


On Wed, Apr 29, 2020 at 1:44 PM Akhil Indurti  wrote:

> I want to mirror (or control) the event loop inside the main goroutine.
> The main goroutine should be the one to block for events. Plus, as long as
> it's safe, it doesn't seem needlessly complex to me.
>
> On Wednesday, April 29, 2020 at 4:38:27 PM UTC-4, Thomas Bushnell, BSG
> wrote:
>>
>> That seems needlessly complex. Why not just skip the weird init, and just
>> have main do a go to the thing you want to be not on the main thread, and
>> let the main thread do its thing?
>>
>> On Wed, Apr 29, 2020 at 4:19 PM Akhil Indurti  wrote:
>>
>>> I want to run the main goroutine on another thread besides the main
>>> thread, so that the main thread can block in darwin UI code. Is this a safe
>>> way to do it?
>>>
>>> package main
>>>
>>> /*
>>> #include 
>>> #include 
>>>
>>> void block() {
>>> printf("Blocking main thread? %d\n", pthread_main_np());
>>> while(1);
>>> }
>>> */
>>> import "C"
>>> import (
>>> "fmt"
>>> "runtime"
>>> )
>>>
>>> func init() {
>>> runtime.LockOSThread()
>>> go main()
>>> C.block()
>>> }
>>>
>>> func main() {
>>> fmt.Println("Blocking main goroutine?", C.pthread_main_np())
>>> }
>>>
>>>
>>> This prints out the following:
>>>
>>> $ go run threadtrick.go
>>> Blocking main thread? 1
>>> Blocking main goroutine? 0
>>>
>>> --
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/6b476ab1-c6b6-4f77-91d8-aba2dfbcc314%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5e80ed26-09c5-4133-875e-4b0f72e9e2af%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Json Parse Data [unexecpted non whitespace 1 to 28]

[Marcin Romaszewicz]

Ali, your example has several problems.

First, you do this:

var p Person
data, err := json.Marshal(p); if err != nil{
fmt.Println("Error", err)
}

What this does is encode an empty object, that's fine.

Next, you read the HTTP body from the request, and try to unmarshal that.

fmt.Println("Data", data)
err = json.NewDecoder(r.Body).Decode();if err != nil{
fmt.Println("Error2", err)
return
}

We have no idea what you're sending. If you are issuing a GET, there will
be no reasonable body, and the JSON parser will correctly tell you that
there is no data. Did you mean to initialize NewDecoder with "data"? If you
do so, your example works.

In order for your code to work properly, you need to do an HTTP POST to
/data on your handler with a JSON payload conforming to Person's schema.



On Tue, Apr 28, 2020 at 1:54 AM Ali Hassan  wrote:

> [image: Capture.JPG]
>
> Data : TYPE OF Json
>
>
>
> var member Member // struct where json
> data, err :=json.Marshall(member); if err != nil{ fmt.Printf("Error %s",
> err)}
> fmt.Printf("Data", data)
>
> err = json.NewDecoder(request.Body).Decode(); if err != nil {fmt.
> Printf("Error %s",err) // this is print "EOF"}
>
> unexpected non whitespaceing json parse data 1 to  colummn 28
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/950a3753-88bf-4748-ab58-e59707914b67%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Appending to a slice of an array on the stack

[Marcin Romaszewicz]

I added a little more to your example to illustrate my email points.
https://play.golang.org/p/eT5tKUniC1E

1) stack_array may or may not be on the stack, Go makes that choice.

2) slice := stack_array[:] Doesn't copy the data, it creates a slice
structure which wraps it.

3) Next, when you call slice = append(slice, 99), Go will allocate a new
backing buffer and copy the initial four values. Now you have a copy.
"slice".

A slice is just this struct:
https://golang.org/src/runtime/slice.go

type slice struct {14   array unsafe.Pointer15  len   int
16  cap   int17  }


When you create your initial slice, you get array = stack_array, len = 4,
cap = 4.

When you append the next element, you get
array = , len=5, cap=5. The first 4 elements will have been
copied.

-- Marcin

On Sat, Apr 18, 2020 at 10:26 AM Miguel D 
wrote:

> Hello everyone.
> I'm learning the go language and I have some questions regarding the
> implementation of slices.
>
> *$ cat slice_stack.go *
> package main
>
> import "fmt"
>
> func main() {
> stack_array := [4]int{1,2,3,4}
> // !- I assume this is on the stack, like a local int[4] would be in
> C.
>
> slice := stack_array[:] // Does this copy the data to the heap?
> // or just get a slice to the mem on the
> stack?
> for i := 0; i<25; i++ {
> slice = append(slice, 99) // Does this copy the data to the heap
> on first append?
> }
>
> fmt.Println(stack_array)
> fmt.Println(slice)
> }
>
>
> *$ go run slice_stack.go *
> [1 2 3 4]
> [1 2 3 4 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99
> 99 99 99]
>
> Is it common to get slices to arrays on the stack? Am I wrong when I say
> *stack_array* is on the stack?
> Thank you.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/221259d6-8cd2-4f51-b67d-757a0f802e7b%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Any reason why this type conversion is not allowed?

[Marcin Romaszewicz]

Go doesn't do any implicit type conversions, and it's quite consistent
about that. The only things which are type "converted" are untyped
constants.

I would love for this to work too, by the way, since I often come up with
something like:

var a []interface{}
var b []SomethingConcrete

I would love to be able to assign a to b without having to loop, but it
won't work because their sizes are completely different, so the compiler
can't emit a single conversion of this type, since one structure isn't
safely coercible to the other type. This would be along the lines of
reinterpret_cast<> in c++, which can corrupt memory.


On Mon, Apr 13, 2020 at 6:56 PM Glen Huang  wrote:

> Given
>
> type Data []byte
> s := [][]byte{{1},{2}}
>
> I wonder why this conversion isn't allowed?
>
> []Data(s)
>
> Seems pretty straightforward. Maybe I miss some edge cases where things
> won't square?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/26c4bcfc-f67b-4638-a812-dce9c8c9b275%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] If in doubt prefer to wrap errors with %v, not %w?

[Marcin Romaszewicz]

In my opinion, this is a much nicer errors package than Go's library, and
I've been using it everywhere:
https://github.com/pkg/errors

Instead of fmt.Errorf("%w"), you do errors.Wrap(err, "message"), and
errors.Unwrap(...) where you want to inspect the error. It's much more
explicit and less error prone.

-- Marcin


On Sun, Mar 22, 2020 at 1:06 PM Adrian Ratnapala 
wrote:

> Part of the culture of Go is that we are careful to promise as little
> as possible in APIs, as we will be stuck with those promises long into
> the future.
>
> Now with Go 1.13  we can do `fmt.Errorf("It broken: %w")` which means
> the same thing as `fmt.Errorf("It broken: %v")` except callers get
> better ways to inspect the result.  But as the Go blog says, this
> means the use of "%w" becomes a way to expose an API:
>
> > In other words, wrapping an error makes that error part of your API. If
> you don't want to commit to supporting that error as part of your API in
> the future, you shouldn't wrap the error.
>
> Given the preference for *not* introducing APIs, doesn't that mean
> authors should stick to "%v" until they have clear reasons for using
> "%w". After all, it's always possible to switch to "%w" later.
>
>
> --
> Adrian Ratnapala
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAN%2BHj7jgoMSoyTpcOL%3Da2Rd51MvO%2Bgp0XRzTHjtNZcqPdK8zOg%40mail.gmail.com
> .
>

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

Re: [go-nuts] How to break-out of martini middleware

[Marcin Romaszewicz]

Martini is defunct, but Gin took their torch and ran with it. I use such
http routing frameworks as part of my day job, and would recommend the
three following ones.
1) Echo (https://github.com/labstack/echo)
2) Gin (https://github.com/gin-gonic/gin)
3) Chi (https://github.com/go-chi/chi)

I would also pick them in that order of preference. Echo is very similar to
Gin, except instead of passing struct pointers around, it uses interfaces
which you can mock, and their middleware API is more flexible, precisely
allowing to to short circuit the middleware chain wherever you want, it's
up to you. Chi is much more minimal.

I'm a big proponent of spec driven development when it comes to HTTP API's,
and also have released a package to generate your server boiler plate
(works best with Echo) from an OpenAPI v3.0 specification.
https://github.com/deepmap/oapi-codegen


-- Marcin

On Sun, Mar 15, 2020 at 9:11 AM Jake Montgomery  wrote:

> Note that Martini is not maintained anymore
>>
>
> I hope this is not too off topic, but when choosing a third party go
> package it is really important to consider whether the package is being
> maintained. In my experience it is worth steering clear of any complex
> package that is not being actively maintained, for a variety of reasons.
> Its usually the second thing I check. A quick glance at
> https://github.com/go-martini/martini shows that no code changes have
> been made in the last 4 years and the readme starts with: "NOTE: The
> martini framework is no longer maintained."
>
> If you do decide to take on such a package be prepared to dive deep into
> the code, since you will likely have to fix bugs in it, and make features
> changes yourself when needed. Additionally, it is often difficult to get
> support, even on SO.
>
> Your question is reasonable, and IMHO posting it here was appropriate. I
> hope you get an actual answer, but I would not count on it.
>
>
> On Saturday, March 14, 2020 at 10:05:07 PM UTC-4, kortschak wrote:
>>
>> Note that Martini is not maintained anymore and the original author had
>> a fair bit to say about the merits or otherwise of the packages (via
>> the wayback machine since codegangsta.io is no longer live):
>>
>>
>>
>> https://web.archive.org/web/20160518054801/https://codegangsta.io/blog/2014/05/19/my-thoughts-on-martini/
>>
>> On Sat, 2020-03-14 at 15:18 -0700, al...@oresoftware.com wrote:
>> > I am looking for answer to this SO overflow question:
>> >
>> >
>>
>> https://stackoverflow.com/questions/60679922/how-to-break-out-of-martini-middleware
>> >
>> > In essence, I am wondering how to send the response, and *not* invoke
>> > any of the subsequent middleware that is declared as part of the
>> > chain for that matching request.
>> > There is a boolean flag on http.Response called http.Response.Close.
>> >
>> > It's possible that martini reads from http.Response.Close to see if
>> > it should invoke the remaining middleware or not, but if so that
>> > seems like an imperfect practice/methodology.
>> >
>> > -alex
>> > --
>> > 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 golan...@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/golang-nuts/b0dbef78-8d0a-49c7-8feb-b3f96ef377ea%40googlegroups.com
>> > .
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ae01f686-9b9e-4409-b1ce-6c23d83c7ed3%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Using modules with private repos

[Marcin Romaszewicz]

There is really no nicer way. You do not have to make those .insteadOf
overrides in your global git config, though, you can do it in the local git
config for your Go repository to contain the damage. You will also find
that private repositories don't work nicely with things like the Athens
module proxy, since you don't want your CI/CD systems hitting public
servers.

-- Marcin

On Wed, Mar 11, 2020 at 1:07 PM Dean Schulze 
wrote:

> The docs for modules assume that you'll be publishing your golang modules
> (actually a git push) to the few public repos that golang has built in
> support for.  I want to use a private repo, but there doesn't seem to be
> any docs for that.  This post
> 
>  has
> some suggestions, but it relies on entries in .gitcofig that will interfere
> with normal access to those public repos.  It doesn't mention using ssh
> keys for authentication.  I assume this is what go does for the public
> reops it has built in support for.
>
> I hope there is a better way.  Is there?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c49ab83c-315c-4de1-9225-7f34d9cf395d%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] how to design log package to avoid allocations

[Marcin Romaszewicz]

I'm using Uber's zap logger in production systems (
https://github.com/uber-go/zap). It is designed to emit structured JSON
logs and do the minimal amount of allocations possible. It's a completely
different interface from Go's log package, but that is where the efficiency
comes from. I'd highly recommend it, and the JSON logs are easy to ingest
into services like Datadog or Sumologic.

-- Marcin

On Mon, Mar 9, 2020 at 9:52 AM Vasiliy Tolstov  wrote:

>
>
> пн, 9 мар. 2020 г. в 19:36, Axel Wagner :
>
>> IMO, there really isn't a super good answer. The simple answer is: You
>> need to delay the actual `fmt.Sprintf` call as long as possible. Which
>> generally means, that the interface you consume (to allow the user to
>> direct and configure logging) will need to reflect formatting and all kinds
>> of things that the user actually doesn't want to deal with. So it's hard to
>> find a good tradeoff between API simplicity and usability and not
>> allocating in this case.
>>
>> Another, maybe unforseen problem, is that you don't want logging to
>> interfere with production. It's a painful lesson to learn, that synchronous
>> logging can take down a production service with ease. If you want to be
>> prepared for that and reduce the runtime overhead of logging, you will have
>> to make it asynchronous. But that's fundamentally at odds with the above
>> goal of delaying formatting - the user will usually not expect arguments to
>> loggers to be used after the logging call returns. Buffering a formatted
>> string avoids that of course.
>>
>>
> Thanks! So i think that most simple case is check each time log level ,
> and output log only if level satisfied.
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CACaajQshiJaz%2BAJ_Tm5VbTW8FDfP0QyLvzj_KCGDTAM7RpiPrg%40mail.gmail.com
> 
> .
>

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

Re: [go-nuts] Go without garbage collector

[Marcin Romaszewicz]

Your paper proves your conclusions given your assumptions :) When there is
no GC runtime in a language, you are open to managing memory however you
see fit, and there are lots of models which are more efficient than
reference counted smart pointers or whatever. I've worked on many realtime
systems in my life, and in those, we take a completely different strategy -
preallocate everything, since you can't fragment memory and can't call out
to sbrk() since either of those could knock you off the predictable path.
When you have object pools of some kind, allocation and deallocation is
stupendously fast, you modify a pointer in an array. Not allocating is a
lot faster than the fastest allocator. Yes, I'm being kinda facetious here,
but these papers assume that you have a programming model with a generic
memory management system. Given that assumption, I can see how a GC
language could be faster, but how appropriate is it when the memory
footprint is fixed (such as on a game console) or when predictable
performance is very important (realtime systems).

-- Marcin

On Tue, Feb 11, 2020 at 9:00 PM robert engels  wrote:

> I found a more recent academic paper that proves my conclusions:
>
>
> https://www.researchgate.net/publication/326369017_From_Manual_Memory_Management_to_Garbage_Collection
>
> I am sure you can search and find many more, but the principles stated in
> the above are going to apply regardless.
>
> On Feb 11, 2020, at 10:53 PM, robert engels  wrote:
>
> Here is a paper from 2005
> https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf that proves
> otherwise.
>
> GC techniques have radically improved since then, some with hardware
> support, so much so that it is no longer a contest.
>
> To reiterate though, if you don’t have dynamic memory management - which
> is essentially allocate and forget - that will “probably" be faster (many
> GC systems have an extra level of indirection).
>
> You can write robust systems without dynamic memory, but it is very very
> difficult - beyond the skills of most developers.
>
> So most developers resort to dynamic memory at some point - and once you
> do that - GC will crush your manual memory management techniques.
>
> On Feb 11, 2020, at 10:31 PM, alex.besogo...@gmail.com wrote:
>
> Actually, it was not proven. And in practice manual memory management
> seems to be outperforming GC in majority of cases.
>
> On Tuesday, February 11, 2020 at 5:59:26 PM UTC-8, robert engels wrote:
>>
>> It’s been PROVEN that GC outperforms all manual memory management except
>> in EXTREMELY isolated cases (very non-traditional allocation or
>> deallocation patterns).
>>
>> It’s all about constraints and tolerances.
>>
>> You design a “system” that takes both into account - if not, you’re not
>> engineering, you're guessing.
>>
>> On Feb 11, 2020, at 4:29 AM, deat...@gmail.com wrote:
>>
>> What about #vlang ? https://vlang.io/
>>
>> On Sunday, 17 June 2012 22:40:30 UTC+2, nsf wrote:
>>>
>>> On Sun, 17 Jun 2012 11:48:53 -0700 (PDT)
>>> ⚛ <0xe2.0...@gmail.com> wrote:
>>>
>>> > > You can't have Go syntax without a garbage collector.
>>> > >
>>> >
>>> > I wouldn't be so sure about it.
>>> >
>>>
>>> Let me rephrase myself. When someone says "I want Go without garbage
>>> collection" it means a person wants a feel he has with Go, but at the
>>> same time without garbage collection. At least that's my case. I wanted
>>> exactly that. And you can't have that. You can build a language similar
>>> to Go without GC, but you won't get a feel of Go. At least, I couldn't
>>> do it. And maybe it's kind of obvious, but when there is a need to
>>> manage memory, that factor alone creates a different programmer mindset.
>>> And in my opinion what Go does so well for a programmer is establishing
>>> its own mindset that gives a very nice and smooth development process.
>>> What we call "a feel of Go".
>>>
>>> That's actually very same mistake that leads to talks like "where is my
>>> feature X? I want feature X in your language". And the problem here is
>>> that a language is not just a collection of features, it's a
>>> composition of features. You can't just stick something in and make it
>>> better (see C++) and you can't throw something out. Every feature
>>> addition/removal affects the language as a whole, mutating it to a
>>> different state. And in my opinion GC is a critical feature that allows
>>> you to have memory safety and (well, let's put it that way) memory
>>> safety is one of the major features in Go.
>>>
>>> So.. think about it. "I want Go with templates" and "I want Go without
>>> garbage collection" are very similar things. Both hide the desire of
>>> improving/changing something without realization that this will affect
>>> other areas dramatically.
>>>
>>> And to make a summary: I tried that, I did that mistake thinking you
>>> can build something out of Go just by taking parts you like and mixing
>>> them in some weird way. I was stupid (to make it clear, I'm not
>>> 

Re: [go-nuts] Why Discord is switching from Go to Rust

[Marcin Romaszewicz]

On Fri, Feb 7, 2020 at 11:43 AM Robert Engels  wrote:

> I didn’t look into the project but reading between the lines here I am
> betting that Java would perform as well as Rust in this case. This is an
> example of where not having  generational GC hurts badly - since it appears
> that most of their heap would be very long lived objects.
>
>
I've been running Go, Java, C++ and Python code in wide scale production
for years, so have some background for comparison here. Java's garbage
collector is not great either. Pretty much the biggest challenge of running
Java services is constantly tuning JVM args to keep it from either taking
down your machine, or sabotaging its own performance. It's a never ending
battle. A non-GC language app can have a memory leak, but it's obvious, and
it's a bug, while with Java's GC, and to a much lesser extent Go, you can
have runaway memory usage which isn't necessarily the result of a bug, but
a language behavior. Currently, I'm predominantly running services in Java,
which interact with Hadoop, and Go, which make REST API's backed by
databases and some limited interaction with Hadoop. With the Go services,
most of our engineers time is spent writing the initial code and tests.
With Java, most of their time is spent chasing Java memory allocation
issues. I think the place the effort goes speaks volumes about how well the
GC works in both languages.


> On Feb 7, 2020, at 12:57 PM, Marcin Romaszewicz  wrote:
>
> 
> You're not oversimplifying. GC incurs a price, and that's performance. If
> you have a program which manages its own memory optimally for its usage
> pattern, it will be more efficient than a generic GC that has to handle all
> usage patterns. I use Go everywhere I can, since the tradeoff between
> programmer work and performance is phenomenal, but where latency or
> throughput really matter, it's still a compiled language without generic
> garbage collection. I'm sure there are many things that Rust will perform
> at better than Go, but that's not a statement about one language being in
> any way better than the other, just different.
>
> On Fri, Feb 7, 2020 at 10:40 AM Tyler Compton  wrote:
>
>> It would have been nice to see performance measurements from a more
>> recent Go version. That said, it makes sense to me that Rust would be a
>> better choice for this kind of application, where the main performance
>> bottleneck is the sheer number of objects in memory. A language where you
>> get to express more about the life-cycle of these objects should perform
>> better. I say this as someone that knows very little about Rust, so I'm
>> probably greatly oversimplifying.
>>
>> On Fri, Feb 7, 2020 at 4:25 AM Everton Marques 
>> wrote:
>>
>>> I think Go is way better than Rust, but it is amusing to see why people
>>> pick one over another.
>>>
>>> "Remarkably, we had only put very basic thought into optimization as the
>>> Rust version was written. Even with just basic optimization, Rust was able
>>> to outperform the hyper hand-tuned Go version. This is a huge testament to
>>> how easy it is to write efficient programs with Rust compared to the deep
>>> dive we had to do with Go."
>>>
>>>
>>> https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/c3d9fc18-b750-48d7-b0b8-fd78afdbbf29%40googlegroups.com
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2wEHsC0fo32srrrJnXnLA2-s%2BzJ82JF7T96NqtQBkUVQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2wEHsC0fo32srrrJnXnLA2-s%2BzJ82JF7T96NqtQBkUVQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.googl

Re: [go-nuts] Why Discord is switching from Go to Rust

[Marcin Romaszewicz]

You're not oversimplifying. GC incurs a price, and that's performance. If
you have a program which manages its own memory optimally for its usage
pattern, it will be more efficient than a generic GC that has to handle all
usage patterns. I use Go everywhere I can, since the tradeoff between
programmer work and performance is phenomenal, but where latency or
throughput really matter, it's still a compiled language without generic
garbage collection. I'm sure there are many things that Rust will perform
at better than Go, but that's not a statement about one language being in
any way better than the other, just different.

On Fri, Feb 7, 2020 at 10:40 AM Tyler Compton  wrote:

> It would have been nice to see performance measurements from a more recent
> Go version. That said, it makes sense to me that Rust would be a better
> choice for this kind of application, where the main performance bottleneck
> is the sheer number of objects in memory. A language where you get to
> express more about the life-cycle of these objects should perform better. I
> say this as someone that knows very little about Rust, so I'm probably
> greatly oversimplifying.
>
> On Fri, Feb 7, 2020 at 4:25 AM Everton Marques 
> wrote:
>
>> I think Go is way better than Rust, but it is amusing to see why people
>> pick one over another.
>>
>> "Remarkably, we had only put very basic thought into optimization as the
>> Rust version was written. Even with just basic optimization, Rust was able
>> to outperform the hyper hand-tuned Go version. This is a huge testament to
>> how easy it is to write efficient programs with Rust compared to the deep
>> dive we had to do with Go."
>>
>>
>> https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/c3d9fc18-b750-48d7-b0b8-fd78afdbbf29%40googlegroups.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2wEHsC0fo32srrrJnXnLA2-s%2BzJ82JF7T96NqtQBkUVQ%40mail.gmail.com
> 
> .
>

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

Re: [go-nuts] Question about 'import' statement

[Marcin Romaszewicz]

All the files get downloaded to your $GOPATH/src or $GOPATH/pkg, depending
on whether modules are enabled.

Everything gets compiled together into the same static executable, so yes,
the files get compiled.

The order of imports should not matter in well written code, but you can
always create scenarios where importing something tweaks global state, give
this a read:
https://golang.org/ref/spec#Program_execution

On Mon, Feb 3, 2020 at 11:40 AM joe mcguckin 
wrote:

> Do all the files listed in the 'import' statement get pulled in and
> compiled, or merely scanned to resolve function references etc.
>
> As someone who grew up on 'C', it seems a bit weird to not have an
> 'include' mechanism and its headers.
>
> Does the it matter what order the files appear in the import clause?
>
> Thanks,
>
> joe
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6c63ed3c-a8d8-4b40-879b-725c1a440635%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] [Proposal] database/sql: add interface that unite DB and Tx

[Marcin Romaszewicz]

I have that exact interface in all of my DB code, and I never use sql.Tx or
sql.DB directly. You don't need Go's libraries to adopt this at all, just
use your own.

On Wed, Jan 15, 2020 at 11:20 PM Mhd Shulhan  wrote:

> ## Problem
>
> At some point we have a function that receive an instance of database
> connection to query rows in specific table.
>
> Let's say that function F() accept DB that query table T.
>
> If function F() called with DB instance, it will query only rows that has
> been committed into database.
>
> IF function F() called with Tx instance, it will query all rows including
> the one that has not been committed yet into database.
>
> Since DB and Tx are different types, we will have two functions that
> almost have identical code,
>
> func F(db *sql.DB) (output int) {
>   q := `SELECT … FROM T WHERE …`
>   err := db.QueryRow(q).Scan()
>   …
>   return output
> }
>
> func FWithTx(tx *sql.Tx)(output int) {
>   q := `SELECT … FROM T WHERE …`
>   err := tx.QueryRow(q).Scan()
>   …
>   return output
> }
>
>
> ## Proposed solution
>
> Add an interface Session (the name is not fixed yet) to package sql with
> the following signature,
>
> type Session interface {
> func Exec(query string, args ...interface{}) (Result, error)
> func ExecContext(ctx context.Context, query string, args
> ...interface{}) (Result, error)
> func Prepare(query string) (*Stmt, error)
> func PrepareContext(ctx context.Context, query string) (*Stmt, error)
> func Query(query string, args ...interface{}) (*Rows, error)
> func QueryContext(ctx context.Context, query string, args
> ...interface{}) (*Rows, error)
> func QueryRow(query string, args ...interface{}) *Row
> func QueryRowContext(ctx context.Context, query string, args
> ...interface{}) *Row
> }
>
> Session interface is combination of DB and Tx that contains all identical
> methods.
>
>
> ## Rationale
>
> Without Session, user will have two functions that have the same code,
>
> By using Session, we can minimise duplicate code in the user level. for
> example using the previous problems definition the function F() become one,
>
> func F(session sql.Session)(output int) {
>   q := `SELECT … FROM T WHERE …`
>   err := session.QueryRow().Scan()
>   …
>   return output
> }
>
>
> ## Discussion
>
> Any thought about this proposal?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/C8AB29FF-7A85-445A-B09E-A0E7CB322A4C%40gmail.com
> .
>

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

Re: [go-nuts] types lookup for error interface type

[Marcin Romaszewicz]

Error is an interface, so its type depends on the implementation satisfying
that interface. You can't just create an "error", since they don't exist,
all that exists are implementation satisfying the error interface. That's
what you're doing with NewSignature.

Could you just create an implementation of the error interface and
instantiate one of those?





On Sat, Dec 14, 2019 at 1:07 AM Dan Kortschak  wrote:

> In the go/types package there is an easy way to obtain a types.Type for
> basic builtin types. This doesn't exist for the error type.
>
> Is there an easier way to get a types.Type representing error than by
> using NewInterfaceType, NewFunc and NewSignature functions (I am
> assuming that the nil *types.Package is what should be used for the
> call to NewFunc).
>
> thanks
> Dan
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/4fb681518e2e36e0d0564394546dd7879dd8f96a.camel%40kortschak.io
> .
>

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

Re: [go-nuts] How to mock structs with interdependent interface methods?

[Marcin Romaszewicz]

I face similar problems in a lot of production Go code which I write. I do
have an answer for this, but it's not pretty. Your code would look
something like this:

type ResourceGetter interface {
GetResource(id string) (*Resource, error)
}

type ResourceManagerImpl struct {
  rg ResourceGetter
}

func (r *ResourceManagerImpl) GetResource(id string) (*Resource, error) {
  return r.rg.GetResource(id)
}

Then, you'd move your implementation of GetResource to ResourceGetterImpl.
You can then stub in a mock ResourceGetter in your test, and the
GetAllResources function is none the wiser.

Using so many interfaces has a nice side effect - I can pass things around
using their minimal function footprint to make the code generally easier to
refactor and test.

-- Marcin


On Thu, Dec 12, 2019 at 2:29 PM  wrote:

> I am having trouble writing unit tests in Go for a rather common
> use-case/pattern.
>
>
> Imagine, if you will, something like this:
>
>
> package main
>
> type Resource struct {
> name string}
>
> type ResourceManager interface {
> GetResource(id string) (*Resource, error)
> GetAllResources() ([]*Resource, error)}
>
> type ResourceManagerImpl struct {}
>
> func (r *ResourceManagerImpl) GetResource(id string) (*Resource, error) {
> resource := {}
> var err error
>
> // fetch resource.
> // ...
>
> return resource,  err}
>
> func (r *ResourceManagerImpl) GetAllResources() ([]*Resource, error) {
> var resources []*Resource
> var err error
>
> // for _, id := range ids {
> //  resource = r.GetResource(id)
> //  resources = append(resources, resource)
> // }
>
> return resources, err}
>
>
> It's a common pattern to have the GetAllResources invoke GetResource 
> repeatedly
> as-needed.
>
>
> I can use gomock or testify to test all permutations of GetResource. But,
> when testing GetAllResource, I'd like to mock GetResource. Otherwise,
> testing would become sort-of-a nightmare. This is how one would do it in
> easymock or mockito in case of Java using partial mocks. But, it's not
> clear how the same could be achieved in Golang.
>
>
> Specifically, I couldn't find how to partially mock the struct. Most
> suggestions revolve around breaking such structs but in this case, the
> struct is already at its bare minimum. It seems like a fair ask to not
> break the ResourceManager interface (into single and multi) for the sake
> of testing as that would not make much sense and would be kludgy at best
> and wouldn't scale well as more such methods make into the interface.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/3c22e3fc-b3ad-47e7-9e41-400856423e58%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] How to have fixed xml attributes "Header"

[Marcin Romaszewicz]

Your code creates an array for manifests ([]Manifest), and puts one entry
in there for each package, so encoding/xml is dutifully doing what you
asked it to do :)

You need to change your object structure so that you have one manifest with
a single header, and a list of packages.

Something like this:
https://play.golang.org/p/erzmyjt3Xwf



On Thu, Dec 12, 2019 at 10:18 AM paresh patil 
wrote:

> Hi Marcin,
>
> Thanks for writing back I will sure try your code
>
> I'm attaching the zip folder which has the complete code. It needs some
> corrections as well,
>
> Let me know your thoughts
>
> Thanks
>
> On Thu, Dec 12, 2019 at 6:14 PM Marcin Romaszewicz 
> wrote:
>
>> Could you share your code which isn't working?
>>
>> Here's a simple example of how you would do something like that, but not
>> knowing your code, it might not be helpful.
>> https://play.golang.org/p/H-9eCTYJxTA
>>
>>
>> On Thu, Dec 12, 2019 at 9:57 AM paresh patil 
>> wrote:
>>
>>> Hi,
>>>
>>>
>>> I'm new to Go and finding it interesting to learn. I'm not a developer
>>> or programmer, but I have interest in learning to code
>>>
>>> I'm working on a project to convert csv file to xml file. The code
>>> executes and I'm able to generate a xml file. But the file is not in the
>>> expected format. I seek some help
>>>
>>> I'm expecting the below results in xml output:
>>>
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>>
>>> However what I get is as below:
>>>
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>>
>>> Please help
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/085e7f7b-105e-48f1-9e09-55f0b5e40136%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/085e7f7b-105e-48f1-9e09-55f0b5e40136%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

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

Re: [go-nuts] How to have fixed xml attributes "Header"

[Marcin Romaszewicz]

Could you share your code which isn't working?

Here's a simple example of how you would do something like that, but not
knowing your code, it might not be helpful.
https://play.golang.org/p/H-9eCTYJxTA


On Thu, Dec 12, 2019 at 9:57 AM paresh patil 
wrote:

> Hi,
>
>
> I'm new to Go and finding it interesting to learn. I'm not a developer or
> programmer, but I have interest in learning to code
>
> I'm working on a project to convert csv file to xml file. The code
> executes and I'm able to generate a xml file. But the file is not in the
> expected format. I seek some help
>
> I'm expecting the below results in xml output:
>
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
>
> However what I get is as below:
>
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
>
> Please help
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/085e7f7b-105e-48f1-9e09-55f0b5e40136%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Re: Where is the middle of Brazil?

[Marcin Romaszewicz]

As a bonus challenge, try to compute the population center of Brazil :) One
way of finding the center is minimizing the integral of all distances to a
point, but for population, these points now have weight.

Like Michael above, I spent years working on Google Earth, and the code
running in the latest Earth client app for doing label placement, polygon
placement and center finding is my code. It's fun stuff!

-- Marcin



On Sat, Dec 7, 2019 at 11:05 AM JuciÊ Andrade  wrote:

> Yes, I understand it is impossible to chose the "correct way" of
> determining the center. This week I learnt there are at least a handful of
> places claiming to be the "center" of Brazil, with monuments and whatnot.
>
> The search for a solution is an interesting endeavor per se. Programming
> is supposed to be fun after all.
>
> Several things amazed me:
> . the variety of proposed methods. A guy in Germany collected the position
> and area of every county in Brazil and proceeded with the math. Another guy
> proposed to draw a map on carton paper, cut it and find the center of
> gravity. Etc;
> . the rich geographical data available for anyone to use;
> . the language packages and libraries to handle geographical data;
> . the enviable knowledge some people have on the matter;
> . the willing to learn a new topic just for the sake of it;
> . the unwillingness to learn a new topic just for the sake of it;
>
> Anyway, it was a delightful experience. 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/26ee692b-1807-46cd-b211-90f07af9d631%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Разбить массив чисел на два массива

[Marcin Romaszewicz]

Well, in that case: https://play.golang.org/p/DhSC_xF0jPW  :)



On Sun, Dec 1, 2019 at 12:34 PM Daniela Petruzalek <
daniela.petruza...@gmail.com> wrote:

> I'm not sure if that is a good idea 
>
> https://play.golang.org/p/Mj77pgsaVsB
>
> Daniela Petruzalek
> Software Engineer
> github.com/danicat
> twitter.com/danicat83
>
>
> Em dom., 1 de dez. de 2019 às 17:07, Marcin Romaszewicz 
> escreveu:
>
>> It's very simple to do that:
>> https://play.golang.org/p/1i7pI2OXmej
>>
>>
>>
>> On Sun, Dec 1, 2019 at 8:22 AM Vital Nabokov 
>> wrote:
>>
>>> Разбить массив чисел на два массива?
>>> Split an array of numbers into two arrays?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/dc7702b6-9b12-4e2a-9295-78e821836ee5%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/dc7702b6-9b12-4e2a-9295-78e821836ee5%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LvDdnipcTmp2_n9Lzbx0rob5JKnFgvuv93r-AJvwsMnAg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LvDdnipcTmp2_n9Lzbx0rob5JKnFgvuv93r-AJvwsMnAg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

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

Re: [go-nuts] Разбить массив чисел на два массива

[Marcin Romaszewicz]

It's very simple to do that:
https://play.golang.org/p/1i7pI2OXmej



On Sun, Dec 1, 2019 at 8:22 AM Vital Nabokov  wrote:

> Разбить массив чисел на два массива?
> Split an array of numbers into two arrays?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/dc7702b6-9b12-4e2a-9295-78e821836ee5%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Is anyone aware of a blocking ring buffer implementation?

[Marcin Romaszewicz]

To give a little bit more background on what I was doing - I have an API
endpoint which is used to download large amounts of data that is backed by
S3 in AWS. Using an io.Pipe to simply proxy from S3 tops out at around
30MB/sec due to single threaded S3 performance and setup time. I wrote an
adapter around it which downloads increasingly more S3 chunks in parallel,
until my producer rate starts to exceed the consumer rate - now I'm getting
upwards of a 1GB/sec on really large files. The only tricky bit is
sequencing chunks for feeding into the io.Pipe, but there's few of them, so
an array with a mutex around it works just fine. I didn't have to write the
ring buffer in the end.

Working in Go is a joy at times like this - having a multi threaded chunked
fetcher hiding behind a single threaded HTTP GET all the while not
buffering too much data is a fiendishly hard thing to do in other languages
due to the nature of their threading libraries and the sparse library
support for asynchronous primitives. I've done stuff like this in the past
in the IRIX kernel (don't laugh), or in C/C++ and pthreads, and each of
those would have been days of work to get right instead of half a day of
writing simple code to glue together available library functions.

-- Marcin

On Thu, Nov 21, 2019 at 9:48 PM Robert Engels  wrote:

> I would just copy and paste the stdlib pipe.go and change the ctor to take
> a size for the channel. I’m pretty sure that is all that is needed to fix
> the problem.
>
> On Nov 21, 2019, at 11:18 PM, Marcin Romaszewicz 
> wrote:
>
> 
> I am in fact replacing an io.Pipe implementation, because I need to buffer
> some data. io.Pipe doesn't buffer, it just matches up read and writes with
> each other.
>
> What I'm effectively doing is producing chunks of data at a certain rate
> from one server, and forwarding them to another. Due to the latency of
> issuing the read from the server, I need to do some pre-fetch into a
> buffer, but I don't want to prefetch to much.
>
> With the pipe implementation, my reader had many stalls waiting for the
> server to produce the next  chunk. The server can produce data a lot
> quicker than the reader can read, however, setup time is high. It's a
> complicated mess :)
>
> On Thu, Nov 21, 2019 at 8:37 PM Robert Engels 
> wrote:
>
>> The OP specifically requested io.Reader/Writer interfaces.
>>
>> A pipe is what he wants. Not a ring buffer. (A pipe essentially has a
>> ring buffer in the implementation though).
>>
>> > On Nov 21, 2019, at 10:20 PM, Dan Kortschak  wrote:
>> >
>> > There is this: https://godoc.org/bitbucket.org/ausocean/utils/ring
>> >
>> > It has been used in production fairly extensively.
>> >
>> >> On Thu, 2019-11-21 at 19:47 -0800, Marcin Romaszewicz wrote:
>> >> Hi All,
>> >>
>> >> Before I reinvent the wheel, and because this wheel is particularly
>> >> tricky
>> >> to get right, I was wondering if anyone was aware of a a library
>> >> providing
>> >> something like this
>> >>
>> >> - conforms to io.Reader
>> >> - conforms to io.Writer
>> >> - Contains a buffer of fixed size, say, 64MB. If you try to write
>> >> when the
>> >> buffer is too full, write blocks. When you try to read from an empty
>> >> one,
>> >> read blocks.
>> >>
>> >> This describes the behavior of make(chan byte, 64 * MB), however, it
>> >> doesn't seem to be efficient to do this with a channel. Say I'm
>> >> transferring a few hundred GB via this mechanism. A chan of byte
>> >> would need
>> >> a few hundred billion byte writes, and a few hundred billion reads.
>> >> Doesn't
>> >> sound like it could be efficient at all. You can't implement this
>> >> with a
>> >> channel of []byte, because you'd violate your buffering limit if you
>> >> pass
>> >> too large of a byte array, so you'd have to chop things up into
>> >> blocks, but
>> >> maybe that's simpler than a full fledged blocking ring buffer.
>> >>
>> >> Anyhow, I've implemented such things in various OS level plumbing, so
>> >> I
>> >> know I can do it in Go much more easily, just hoping to avoid it :)
>> >>
>> >> Thanks for any advice,
>> >> -- Marcin
>> >>
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to golang-nuts+unsubscr...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/152a954eaa3eea02514e71bb142904480241ad6c.camel%40kortschak.io
>> .
>>
>>

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

Re: [go-nuts] Is anyone aware of a blocking ring buffer implementation?

[Marcin Romaszewicz]

I am in fact replacing an io.Pipe implementation, because I need to buffer
some data. io.Pipe doesn't buffer, it just matches up read and writes with
each other.

What I'm effectively doing is producing chunks of data at a certain rate
from one server, and forwarding them to another. Due to the latency of
issuing the read from the server, I need to do some pre-fetch into a
buffer, but I don't want to prefetch to much.

With the pipe implementation, my reader had many stalls waiting for the
server to produce the next  chunk. The server can produce data a lot
quicker than the reader can read, however, setup time is high. It's a
complicated mess :)

On Thu, Nov 21, 2019 at 8:37 PM Robert Engels  wrote:

> The OP specifically requested io.Reader/Writer interfaces.
>
> A pipe is what he wants. Not a ring buffer. (A pipe essentially has a ring
> buffer in the implementation though).
>
> > On Nov 21, 2019, at 10:20 PM, Dan Kortschak  wrote:
> >
> > There is this: https://godoc.org/bitbucket.org/ausocean/utils/ring
> >
> > It has been used in production fairly extensively.
> >
> >> On Thu, 2019-11-21 at 19:47 -0800, Marcin Romaszewicz wrote:
> >> Hi All,
> >>
> >> Before I reinvent the wheel, and because this wheel is particularly
> >> tricky
> >> to get right, I was wondering if anyone was aware of a a library
> >> providing
> >> something like this
> >>
> >> - conforms to io.Reader
> >> - conforms to io.Writer
> >> - Contains a buffer of fixed size, say, 64MB. If you try to write
> >> when the
> >> buffer is too full, write blocks. When you try to read from an empty
> >> one,
> >> read blocks.
> >>
> >> This describes the behavior of make(chan byte, 64 * MB), however, it
> >> doesn't seem to be efficient to do this with a channel. Say I'm
> >> transferring a few hundred GB via this mechanism. A chan of byte
> >> would need
> >> a few hundred billion byte writes, and a few hundred billion reads.
> >> Doesn't
> >> sound like it could be efficient at all. You can't implement this
> >> with a
> >> channel of []byte, because you'd violate your buffering limit if you
> >> pass
> >> too large of a byte array, so you'd have to chop things up into
> >> blocks, but
> >> maybe that's simpler than a full fledged blocking ring buffer.
> >>
> >> Anyhow, I've implemented such things in various OS level plumbing, so
> >> I
> >> know I can do it in Go much more easily, just hoping to avoid it :)
> >>
> >> Thanks for any advice,
> >> -- Marcin
> >>
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/152a954eaa3eea02514e71bb142904480241ad6c.camel%40kortschak.io
> .
>
>

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

[go-nuts] Is anyone aware of a blocking ring buffer implementation?

[Marcin Romaszewicz]

Hi All,

Before I reinvent the wheel, and because this wheel is particularly tricky
to get right, I was wondering if anyone was aware of a a library providing
something like this

- conforms to io.Reader
- conforms to io.Writer
- Contains a buffer of fixed size, say, 64MB. If you try to write when the
buffer is too full, write blocks. When you try to read from an empty one,
read blocks.

This describes the behavior of make(chan byte, 64 * MB), however, it
doesn't seem to be efficient to do this with a channel. Say I'm
transferring a few hundred GB via this mechanism. A chan of byte would need
a few hundred billion byte writes, and a few hundred billion reads. Doesn't
sound like it could be efficient at all. You can't implement this with a
channel of []byte, because you'd violate your buffering limit if you pass
too large of a byte array, so you'd have to chop things up into blocks, but
maybe that's simpler than a full fledged blocking ring buffer.

Anyhow, I've implemented such things in various OS level plumbing, so I
know I can do it in Go much more easily, just hoping to avoid it :)

Thanks for any advice,
-- Marcin

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

Re: [go-nuts] Re: [64]byte()[:]

[Marcin Romaszewicz]

It's not even worth calling bytes.Equal to see if a bunch of bytes is zero.
A more efficient way would be to simply loop over them and check for
non-zero.

-- Marcin

On Sat, Nov 16, 2019 at 4:00 PM Kevin Malachowski 
wrote:

> "make"ing a byre slice every time you call Equal is not likely as
> efficient; surely it will put pressure on the garbage collector, assuming
> it's not just called a few times.
>
> Writing something in less lines is not strictly better. I'd probably just
> make package level variable and reuse it among multiple calls to that
> function.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9cfa25b8-4a18-47ca-9f37-5d5ae5b71849%40googlegroups.com
> .
>

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

Re: [go-nuts] Re: An old problem: lack of priority select cases

[Marcin Romaszewicz]

What he's trying to say is that it is pointless to order select cases in
this example, because it is impossible to guarantee ordering in an
asynchronous system.

You have two asynchronous data streams, ctx.Done() and "v", in that example
above.

Generally, those select cases will happen one by one, as those asynchronous
channels deliver data. If "v" is ready first, shortly before ctx.Done(),
then v will be selected first, followed by ctx.Done(). It doesn't matter
that ctx.Done() wants to be higher priority, "v" arrived first, before
ctx.Done() was posted, so it's handled first. If ctx.Done() happens first,
the reverse happens. The only interesting case is when both "v" and
ctx.Done() are ready at the same time, which will be unlikely in practice.

If ctx.Done() and "v" happen together, so that both cases of that select
statement are available simultaneously, then sure, you can order them, but
this will happen very infrequently, and you still MUST handle the case
where "v" happens first, very close to ctx.Done(). So, if you MUST handle
this case, you don't really need to bother with statement priority, since
if your code is written well, this ordering won't matter. ctx.Done() might
happen while you're in the middle of handling "v", for example.

The desire to have priority to select statements presumes that you have
several cases happen at the same time, which isn't how this will generally
work. If you want to order things in a select, you have to change how it
behaves, and order events within a particular time window. Say you write a
poller which samples the event queue every second. If you do this, then
sure, you can order things however you want, but the cost you pay is that
second of buffering latency.


On Fri, Oct 4, 2019 at 1:19 PM T L  wrote:

>
>
> On Friday, October 4, 2019 at 4:09:09 PM UTC-4, Robert Engels wrote:
>>
>> Because ctx.Done() and v being ready for read are independent events. You
>> can not impose ordering on them unless there is an outer mutex that both
>> events are subject to.
>>
>> As an aside, this is why I think the best 'concurrent software'
>> developers are those that have been exposed to at least some hardware
>> design. Many programmers think in terms of 1 and 0 and everything being
>> ordered. This is certainly not the case in hardware, nor concurrent
>> software. (For example, in computer hardware, the clock/sync line is what
>> is used as the outer controlling event, but still things like propagation
>> times, etc. make even this simple statement not fully correct).
>>
>>
> Still not understanding what you new saying. ;D
>
> Again, select case priority enables use to deduce two select cases
> to one select case in coding in many scenarios.
> This often leads to cleaner code, avoid can avoid the harm caused
> by missing a try-receive select case.
>
>
>
>> -Original Message-
>> From: T L
>> Sent: Oct 4, 2019 2:44 PM
>> To: golang-nuts
>> Subject: Re: [go-nuts] Re: An old problem: lack of priority select cases
>>
>>
>>
>> On Friday, October 4, 2019 at 3:32:31 PM UTC-4, Robert Engels wrote:
>>>
>>> You still are not understanding  proper concurrent design. Priority
>>> select cases do not matter in the case of asynchronous external events.
>>>
>>
>> It at least avoids code verbosity and improves code quantity..
>>
>> BTW, I don't understand what you said. Could you elaborate more?
>>
>>
>>> On Oct 4, 2019, at 1:46 PM, T L  wrote:
>>>
>>> 
>>> I just found an example in the "context" package docs:
>>>
>>> //  // Stream generates values with DoSomething and sends them to out
>>> //  // until DoSomething returns an error or ctx.Done is closed.
>>> //  func Stream(ctx context.Context, out chan<- Value) error {
>>> //  for {
>>> //  v, err := DoSomething(ctx)
>>> //  if err != nil {
>>> //  return err
>>> //  }
>>> //  select {
>>> //  case <-ctx.Done():
>>> //  return ctx.Err()
>>> //  case out <- v:
>>> //  }
>>> //  }
>>> //  }
>>>
>>> It looks the send "out <- v" still has a possibility to be executed,
>>> even if "ctx.Done()" is closed.
>>> But if Go supports select case priority, then this will never happen.
>>>
>>>
>>>
>>> On Wednesday, August 28, 2019 at 12:06:33 PM UTC-4, T L wrote:

 The old thread:
 https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o

 Go channels are flexible, but in practice, I often encountered some
 situations in which channel are hard to use.
 Given an example:

 import "math/rand"

 type Producer struct {
 data   chan int
 closed chan struct{}
 }

 func NewProducer() *Producer {
 p :=  {
 data:   make(chan int),
 closed: make(chan struct{}),
 }

 go p.run()

 return p
 }

 func (p *Produce) 

Re: [go-nuts] ent: an entity framework for Go

[Marcin Romaszewicz]

That looks very nice, congrats! I like that it's simple and doesn't try to
solve every problem, just simple relationships, so you can solve most of
your simple DB schema needs (and most DB usage is quite simple in most
services).

Do you have any plans to add a Postgres driver?

-- Marcin

On Thu, Oct 3, 2019 at 8:11 AM Noam Schachter  wrote:

> Hi gophers,
>
> My team at Facebook Connectivity has just open-sourced a new ORM for Go
> and would love your feedback about it.
> GitHub repo at: https://github.com/facebookincubator/ent
> Story behind it in our blog post:
> https://entgo.io/blog/2019/10/03/introducing-ent/
>
> Thanks!
> Noam
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/16a50745-1744-4fe5-be93-aca2b96fcebc%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] go 1.13 won't compile

[Marcin Romaszewicz]

Could you post the output of "go env" run on linux mint? Maybe there's a
clue in there.


On Mon, Sep 30, 2019 at 9:14 AM Robert Solomon  wrote:

> Then my question becomes, what's different about linuxmint 19.2 to require
> me to set GO111MODULE=no
>
> On Mon, Sep 30, 2019, 11:06 AM Everton Marques 
> wrote:
>
>> Your code from playground compiled fine for me on Debian Linux.
>> Tested with Go 1.13 and 1.13.1.
>>
>> Just had to include the missing func:
>>
>> func GetUserGroupStr(f os.FileInfo) (string, string) {
>> return "foo", "bar"
>> }
>>
>>
>>
>> Em segunda-feira, 30 de setembro de 2019 11:34:52 UTC-3, Robert Solomon
>> escreveu:
>>>
>>> Your experience matches mine when compiled on windows 10.
>>>
>>> But linuxmint experience is as I described.   Another responder asked me
>>> if it works when I set GO111MODULE=no.
>>>
>>> It does work when I do that.   I find it interesting that the linux
>>> behavior seems to be different
>>>
>>> On Mon, Sep 30, 2019, 9:17 AM Michael Ellis  wrote:
>>>
>>>> FWIW, I copied your code from Go Playground into ~/go/src/dsrt/dsrt.go
>>>> on my OS X machine.  I replaced an undefined function at line 375 (see
>>>> below) with direct assignments for usernameStr and groupNameStr. It
>>>> compiled (with go build) and ran without reporting an error under go 1.13.
>>>>
>>>> // usernameStr, groupnameStr := GetUserGroupStr(f) // util function in
>>>> platform specific code, only for linux and windows.  Not needed anymore.
>>>> Probably won't compile for foreign computer.
>>>> // GetUserGroupStr() is undefined, so hardcode
>>>> a couple of nonsense strings to test compilation.
>>>> usernameStr := "foo"
>>>> groupnameStr := "bar"
>>>>
>>>>
>>>>
>>>> On Saturday, September 28, 2019 at 2:55:51 PM UTC-4, rob wrote:
>>>>>
>>>>> I guess I was not clear enough.  My apologies.  dsrt is my own code.
>>>>> I remember an earlier posting on this list recommended 'go install' 
>>>>> instead
>>>>> of 'go build'
>>>>>
>>>>> ~/go/src/dsrt/dsrt.go, util_linux.go, util_windows.go
>>>>>
>>>>> And I have written other small programs in go that I use for myself. I
>>>>> put it in https://play.golang.org/p/U7FgzpqCh-B
>>>>>
>>>>> It compiles and runs fine on go 1.12.x under linux, and fine on go
>>>>> 1.13 under windows 10.  I have not yet installed go1.13.1 on my windows 10
>>>>> box.
>>>>>
>>>>> I remember a promise that anything that compiles under go 1.0.0 will
>>>>> not be broken.  Not being able to compile using go 1.13 that works fine
>>>>> using go 1.12.x, broke my code.
>>>>>
>>>>> I'm not a professional programmer.  I don't know what else to include
>>>>> here to demonstrate my problem.
>>>>>
>>>>> Thanks for your response.
>>>>>
>>>>> --rob solomon
>>>>>
>>>>>
>>>>>
>>>>> On 9/28/19 11:42 AM, Marcin Romaszewicz wrote:
>>>>>
>>>>> What was the last version of Go which worked for you?
>>>>>
>>>>> "dsrt" isn't a valid module path in the new module resolution code.
>>>>> Does it work if you disable modules - "GO111MODULE=off go install dsrt
>>>>> "?
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Sep 22, 2019 at 9:56 AM rob  wrote:
>>>>>
>>>>>> Hi.  I think I'm having an issue compiling my code w/ go 1.13.  I
>>>>>> have
>>>>>> not had any issues up until now.  I have my code in the default
>>>>>> locations off of ~/go/src w/ a directory for each little bit of code
>>>>>> I
>>>>>> wrote.
>>>>>>
>>>>>> Running under linuxmint 19.2 amd64, I installed the go binary by
>>>>>> first
>>>>>> nuking /usr/local/go, and then
>>>>>>
>>>>>>  sudo tar -C /usr/local -xf go1.13.linux-amd64.tar.gz.
>>>>>>
>>>>>> When I run go version, I get go version go1.13 linux/amd64
>>>>>>
>>&

Re: [go-nuts] Golang library for - ORM & Schema Migration

[Marcin Romaszewicz]

I've used naked SQL, and ORMs (Django in Python, Hibernate and EBean in
Java, GORM in Go) for years, and I've noticed the following:

1) It's really easy to write very inefficient queries in an ORM. If you
have a very simple 1:1 mapping between tables and objects, it's fast,
efficient, easy to use, and by all means, use the ORM. However, once you
start doing tricker things, like references to other objects (aka, foreign
row constraints on other tables), or array type fields, things get really
tricky.

2) A database abstraction layer is nice, because while SQL is standard,
every dang database extends SQL in its own way that's usually not
compatible with others. For example, Postgres supports array columns. MySQL
does not. These two are both very popular. If you have an object which
you're storing in a table, your approach in each DB will be drastically
different. In Postgres, you just write the array into a column. In MySQL,
you have to decompose to First Normal Form, meaning you create a table for
the array column, and have some sort of array/table -> PK mapping. Or, you
give up on any kind of easy array searching, and just marshal your array to
JSON or whatever, and throw it in a CLOB.

3) An ORM ties your hands to using SQL in whatever approach it presents, so
you frequently do naked SQL outside of the ORM, particularly if you want to
use something to speed up a query which is very difficult for an ORM to
express, such as Window Functions in Postgres.

Given that no two SQL engines speak the same dialect, and ORMs don't
understand intent, you're basically always debugging. If your object model
is simple, an ORM saves work, if it's complex, I'd argue it's more work. If
you have to support multiple DB's, eg, Postgres for production. SQLite for
unit tests, you need a query builder since their syntax is incompatible, or
stick to a compatible subset. SQL is a mess, ORM or no ORM, and in any
language. Just use what works for you, and reevaluate if it starts to cause
problems.

I've been responsible for internet facing services backed by databases for
quite a few years now, could rant about this for a long time. My current
system, and the best one yet, having learned from past mistakes, uses
something like Liquibase for schema management (I wrote it in Go, I'll be
open sourcing it at some point, once it's battle hardened), and naked SQL
queries, with some simple wrappers to hide nullable columns, since the
zerovalue in go is simpler to work with than optionals.

-- Marcin



On Sat, Sep 28, 2019 at 6:12 PM Robert Engels  wrote:

> ORM is object relational mapping. Go is only pseudo object oriented. I
> will say again that complex object graphs and persistence is very hard
> without an ORM or a LOT of custom code.
>
> Since Go does not have runtime compilation a true (or easy anyway) ORM in
> Go requires code generation.
>
> On Sep 28, 2019, at 9:32 AM, Rodolfo  wrote:
>
> "First, nobody thinks that knowing ORM's query language absolves one from
> knowing SQL."
>
> Speak for yourself.
>
> If you a hard spring boot user you can get into this problem.
>
> Example:
>
> findAll = select * from entity
>
> This is have nothing with SQL.
>
> findAllBySomeProperty = select * from entity where property = ?
>
> This is have nothing with SQL.
>
> Please, do not be rude, be honest.
>
> Em sáb, 28 de set de 2019 00:49,  escreveu:
>
>> First, nobody thinks that knowing ORM's query language absolves one from
>> knowing SQL.
>>
>> But the main issue is that Go SQL interface SUCKS. It's verbose, hard to
>> use and is difficult to integrate with additional tooling (try adding
>> generic tracing support, I dare you!). So often your SQL code is hidden in
>> reams of wrapper code that sets arguments and reads the results.
>>
>> So even simple ORMs that allow mapping of result sets to objects help to
>> reduce boilerplate clutter. More advanced ORMs also offer simple type safe
>> queries: https://github.com/go-reform/reform
>>
>> It's still nowhere close to LINQ for C# or http://www.querydsl.com/ for
>> Java, but it's getting there.
>>
>> On Friday, September 27, 2019 at 3:34:59 AM UTC-7, Dimas Prawira wrote:
>>>
>>> Many Gophers don't like ORM as :
>>> 1. ORM introduce an additional layer of abstraction that doesn't
>>> accomplish anything.
>>> 2. SQL syntax is more or less the same for every database.
>>> 3. If you learn an ORM in Java, you will only ever able to use that ORM
>>> knowledge in Java. If you learn SQL, you can use that SQL with almost
>>> _exactly the same_ with any other database, and in any programming language.
>>> 4. ORMs don't save you any time. The number of "lines" of code for an
>>> ORM will be more or less the same as the equivalent logic done in SQL.
>>>
>>> But if still need to use ORM for any reasons, then you can try GORM
>>> https://gorm.io/
>>>
>>> cheers
>>>
>>> On Fri, Sep 27, 2019 at 4:20 AM b ram  wrote:
>>>
 Hi,

 Can you pls suggest libs for  ORM & Schema Migration.

 Thanks.

Re: [go-nuts] go 1.13 won't compile

[Marcin Romaszewicz]

What was the last version of Go which worked for you?

"dsrt" isn't a valid module path in the new module resolution code. Does it
work if you disable modules - "GO111MODULE=off go install dsrt"?



On Sun, Sep 22, 2019 at 9:56 AM rob  wrote:

> Hi.  I think I'm having an issue compiling my code w/ go 1.13.  I have
> not had any issues up until now.  I have my code in the default
> locations off of ~/go/src w/ a directory for each little bit of code I
> wrote.
>
> Running under linuxmint 19.2 amd64, I installed the go binary by first
> nuking /usr/local/go, and then
>
>  sudo tar -C /usr/local -xf go1.13.linux-amd64.tar.gz.
>
> When I run go version, I get go version go1.13 linux/amd64
>
> Now when I run
>
>  go install dsrt
>
> I'm getting an error message:
>
>  can't load package: package dsrt: mallformed module path "dsrt" :
> missing dot in first path element.
>
> I do not have, need or use a go.mod.  In fact, I don't really understand
> them.  And I don't yet understand what vendoring means.
>
> As an aside, I also compile on a win10 amd64 computer.  I installed
> windows binary in the usual way on that computer, compiled my code using
> go install, and I've not had any issues there.  I only have an issue
> here on linuxmint and go 1.13.
>
> What's up?
>
> --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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/3e9c5dad-2fda-9574-d8f9-8cedfb7986e5%40fastmail.com
> .
>

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

Re: [go-nuts] nil map assignment panics. can we do better?

[Marcin Romaszewicz]

Could we have an operation like append() for slices?

How about:

m := insert(m, "key", "value").

It returns m unchanged if it's allocated, otherwise, it allocates. We're
already familiar with this kind of function.

-- Marcin

On Mon, Sep 23, 2019 at 10:58 PM abuchanan via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Ah, thanks Ian, that's exactly the kind of requirement I was looking for.
>
> (also, you said "without" but you probably meant "while")
>
> Perhaps this is a job for "go vet". And/or, looks like staticcheck.io has
> a check I can try: https://staticcheck.io/docs/checks#SA5000
>
>
>
>
>
> On Monday, September 23, 2019 at 9:45:37 PM UTC-7, Ian Lance Taylor wrote:
>>
>> On Mon, Sep 23, 2019 at 2:40 PM abuchanan via golang-nuts
>>  wrote:
>> >
>> > Is there anything written down on why assignment to a nil map causes a
>> panic? I'm curious if there were carefully considered tradeoffs while
>> making this decision.
>> >
>> > Assignment to nil maps has caused most of the unexpected panics I've
>> seen. Many times these happen in production and cause an incident. Every
>> time it happens I think, "we've got to do something about this."
>> >
>> > I'm not sure what the best solution is yet, but there must be something
>> better than the status quo. Would it be possible to have assignments
>> automatically initialize a nil map?
>>
>> I agree that this is awkward.  But we've never been able to think of a
>> way to make an assignment to a nil map initialize the map without also
>> preserving the very useful property that the zero value of any Go type
>> can be represented by a sequence of zero bytes.
>>
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/d9cc8fb3-7d73-48c0-8c60-9d9b1022054c%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Need a Modules for Dummy's Guide. Please help

[Marcin Romaszewicz]

I've beat my head into the module wall a bit as well, and while I don't
understand some of the design decisions, I've done my best to answer your
questions inline.

On Mon, Sep 23, 2019 at 1:42 PM Stuart Davies  wrote:

> Hi.
>
>
>
> I have been using GO for about a year and I love the language and ideas
> behind the language.
>
>
>
> I am also a Java developer for many years, I switched from Delphi to Java
> 1, the new and exciting language from Sun (a bit like GO is now from
> Google).
>
>
>
> In Java we have Maven and Gradle (sorry Ant) to make dependency hell more
> manageable so I understand the need for modules in Go. I have just
> installed GO 1.13 and thought I would convert an existing 'pet' project to
> use modules. It did NOT go well!
>
>
>
> What I need is a dummies guide to GO module so I can build good, reliable,
> standards compliant GO applications.
>
>
>
> It needs to explain the new terminology in the context of a module, For
> example 'vendor'. Not just a one liner, I NEED to understand!
>
>
>
> I know how to use Google but the quality of the articles I have read on
> this subject is minimal and just brushes the surface.
>
>
>- If I have a reasonably large and complex (pet) project with
>local packages in it. I like to split my project in to small units with
>'namespaces' to keep it manageable. These are NOT reusable components until
>I decide they qualify and publish on Github. Why MUST I import them as if
>they are from github and then 'replace' them, and if I don’t 'MUST' then
>you have failed to explain this feature to me!
>
>
Go now has two distinct ways of finding dependencies. Module mode (export
GO111MODULE=on) and the non-module mode (export GO111MODULE=off). Each mode
resolves dependencies differently.

In Module mode, all imports are assumed to be paths to git version control
systems, such as github, and that's how they're always interpreted, that
was a design choice. If you have a local directory with source code that's
not on a git server with a matching name, that's when you use the 'replace'
directive to point it at the local directory, otherwise, Go will try to
contact that server.

Github doesn't have to be in the name, for example, you could make a
/tmp/stuart/mymodule "namespace", import it as "fake.host/stuart/mymodule",
and you'd have to specify a "replace fake.host/stuart/mymodule =>
/tmp/stuart/mymodule" directive.

With modules turned off, things make a little bit more sense. Imports are
just strings, so "import foo/bar/baz" would try to import
$GOPATH/src/foo/bar/baz, and AFAIK, there aren't any restrictions on naming
these things.


>
>- My local packages are part of my application. They are, I agree
>still 'dependencies' but they are not 'DEPENDENCIES' that I need (or even
>want) to import from a repository. They are part of my project.
>
>
The easiest way to deal with this is to refactor your dependencies to be
subdirectories within your main project/module. If they're subdirectories,
and share one global go.mod file, you're not dependent on github or
anything, and this module can have any name. If you ever intend to publish
it for public consumption, though, you'd need to give it a github name.


>
>- What if I do not want to host my project on a GIT repo (Shock
>horror!).
>
>
Use non-module mode, where it's up to you to manage the contents of
$GOPATH/src, or put everything in the same module, since the name doesn't
matter when you're operating within a module's directory tree.


>
>- Why do all imports start with github.com. Is that a requirement,
>what is the rational for this.
>
>
They must start with a hostname resolvable to a git server, that's all. For
example, gopkg.in shows up a lot as well. I have my own internal gerrit
server, and I use that hostname. This behavior is documented here:
https://golang.org/cmd/go/#hdr-Remote_import_paths

It appears that several version control systems are special cased.


>
>- How does a 'import' resolve its 'reference'.
>
>
In module mode, it contacts the server at your import path, with a query
saying that it's Go asking the question, and it expects a code location
back as an answer, it's documented here in that link above. If you "import
foo.com/bar", Go issues the query "https://foo.com/bar?go-get=1;, and
expects some VCS meta-info back as a response. That tells Go that we're
talking to Git or Mercurial or whatever, as well as the actual path to the
repository.

>
>- Should I add the go.mod and go.sum files to my repository or
>should the developer who cloned my project have to do a go mod init
>(bummer!).
>
> Can someone please explain, properly!
>

Your go.mod and go.sum should go into your repository. Together, they
unambiguously specify _your_ set of dependencies. It's up to you to manage
them in a way which makes your library function properly, and when others
clone it, they can be assured that they're getting the 

Re: [go-nuts] sqlserver error "TLS Handshake failed: x509: certificate signed by unknown authority"

[Marcin Romaszewicz]

You're missing the CA Root certificates for whatever linux distribution is
running your application. For example, I use Alpine linux as my Docker base
image for my Go services, and I must install the certificates like this via
the Dockerfile:

RUN apk update && apk add ca-certificates

Find the correct way to do that in your Docker base image.

-- Marcin

On Tue, Sep 10, 2019 at 12:23 PM Peggy Scott  wrote:

> I am using a dockerized Golang image to connect to my Azure SQL server
> database. When I try to ping it, I am running into "TLS Handshake failed:
> x509: certificate signed by unknown authority". I am able to run my app
> from my box without dockerization without any issues. I am also able to
> able to ping my Azure Postgres server with sslmode=require without issues
> using the same Golang image. I am using
> https://github.com/denisenkom/go-mssqldb package. My connection code is:
>
> db, err := sql.Open("sqlserver", 
> "server=myserver.database.windows.net;user
> id=myuserid;"+
>  password=mypassword;port=1433;database=mydbname;encrypt=true;
> TrustServerCertificate=false;"+
>  connection+timeout=30;hostNameInCertificate=*.database.windows.net;")
>
> if err != nil {
> globals.Log.WithError(err).WithFields(logrus.Fields{
> "drivername":   "sqlserver",
> "connectionstring": "secret",
> "error":err.Error()}).Panic("Unable to connect to
> db")
>
> What am I missing?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/0a0591d0-2b5a-4d21-8e95-012ba26b3900%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] How to do a forward compatibility support for go 1.13?

[Marcin Romaszewicz]

This may not be the exact answer you're looking for, but there's a package
which handles this even better than Go's builtin error package:

https://github.com/pkg/errors

Dave Cheney's package is better designed, IMO, and the explicit
errors.Wrap() call is more clear than inferring it from your format string.

-- Marcin


On Fri, Sep 6, 2019 at 7:50 AM changkun  wrote:

> I have upgraded my code to Go 1.13 with newly introduced errors APIs.
>
> However, I am not able to upgrade the production environment Go version
> which is Go 1.11, which means I have to run Go 1.13 code on a Go 1.11
> environment.
>
> What are the way to make my builds both happy on local and production
> environment with a single code base?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/0a915d38-39f4-4083-b730-75320a4eecc6%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] ticker not firing often enough in minimal mac app with run loop

[Marcin Romaszewicz]

I'm not quite sure how to avoid this, but I'm pretty sure that I know the
cause. Read up on Grand Central Dispatch and Centralized Task Scheduling (
https://developer.apple.com/library/archive/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/DiscretionaryTasks.html).
It's been a while since I've written OS X code, but I used to do it quite
heavily (I'm one of the authors of the mac version of Google Earth).

OS X tries very hard to keep the CPU's in their lowest power state, the the
scheduler has all sorts of heuristics for when an application needs to be
woken up. By default, it tries very hard to keep the applications scheduled
as little as possible, and you're supposed to provide hints to the system
about the urgency of the work you're doing.

Now, here's where I'm rusty, but I believe that at very low nice levels,
you can bypass this behavior. Try this:

sudo nice -1 /path/to/your/application

If your timers start working correctly, that's probably the reason.

Generally, when you interact with Cocoa system libraries, there's all sorts
of interaction with GCD and CTS to keep your app running in an
efficiency/performance sweet spot, but when you call out to another
runtime, like Go's, you bypass all those hooks.


On Wed, Sep 4, 2019 at 1:20 AM Tor Langballe  wrote:

> I'm running a mac cocoa event loop, and calling a go ticker:
>
> void StartApp() {
> [NSAutoreleasePool new];
> [NSApplication sharedApplication];
> [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
> [NSApp run];
> }
>
> func test() {
>  last := time.Now()
>  ticker := time.NewTicker(time.Second)
>  for range ticker.C {
>  t := time.Now()
>  diff := t.Sub(last)
>  if diff > time.Second*2 {
>  fmt.Println("Tick slow:", diff)
>  }
>  last = t
>   }
> }
>
>
> func main() {
>  go test()
>  C.StartApp()
> }
>
> currenly just running the go program from the terminal, though I got
> similar results packaging it into an app.
>
> I soon get very long periods between ticker fires:
>
> Tick slow: 3.501350114s
> Tick slow: 5.551485377s
>
> This seems to only happen with
>
> [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
>
> NSApplicationActivationPolicyProhibited and
> NSApplicationActivationPolicyAccessory don't cause this.
>
> I assume it's the event loop in [NSApp run] that is causing this, but
> don't know how to start making a mac appliction with goroutines and tickers
> that don't get blocked.
>
> Does anybody know how to avoid this and why it is happening?
>
> tor
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/62325cef-7441-4a7c-abf9-ff58454ff5f4%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Re: An old problem: lack of priority select cases

[Marcin Romaszewicz]

Think of a channel as existing for the lifetime of a particular data
stream, and not have it be associated with either producer or consumer.
Here's an example:

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

The channel here is closed after all producers have exited, and all
consumers continue to run until the channel is drained of data.

The producers are managed by something somewhere in your code - and that is
the scope at which it makes sense to create channel ownership. I've used a
waitgroup to ensure that the channel is closed after all producers exit,
but you can use whatever barrier construct you want.

Even if you must have a channel per producer, you can safely close the
producer side, without notifying the downstream about this. The example
early in the thread uses multiple channels, with one channel being used to
signal that the producers should exit. Channels aren't really the right
model for this, you want a thread safe flag of some sort. For example:

var exitFlag uint64
func producer(chan data int, wg *sync.WaitGroup) {
defer wg.Done()
for {
shouldExit := atomic.LoadUint64()
if shouldExit == 1 {
 return
}
chan <- rand.Intn(100)
}
}

Here's 10 producers and 3 consumers sharing a channel and closing it safely
upon receiving an exit flag:
https://play.golang.org/p/RiKi1PGVSvF

-- Marcin

On Wed, Aug 28, 2019 at 11:29 AM Leo Lara  wrote:

> I do not think priority select is *necessary*, it could be a nice addition
> if the performance does not change.
>
> On Wednesday, August 28, 2019 at 8:27:36 PM UTC+2, Leo Lara wrote:
>>
>> Hi Robert,
>>
>> From the article: """To bound more the problem, in my case, you control
>> the writers but not the readers"""
>>
>> So what I was trying to do was to be able to close, with mutiple writers,
>> while being transparent for the readers. The readers only need to read as
>> usual form the channel.
>>
>> For example, if you want to write a library where the user just reads
>> from a channel, this is an approach I found where the user of the lirbary
>> deos nto have to do anything special. Of course, there might be another
>> solution, but if you need to modify the reader we are talking about a
>> different problem.
>>
>> Cheers!!
>>
>> On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote:
>>>
>>> A better solution is to wrap the writes using a RWLock, grab the read
>>> lock for writing, and the Write lock for closing. Pretty simple.
>>>
>>> Just encapsulate it all in a MultiWriterChannel struct - generics would
>>> help here :)
>>>
>>> -Original Message-
>>> From: Leo Lara
>>> Sent: Aug 28, 2019 11:24 AM
>>> To: golang-nuts
>>> Subject: [go-nuts] Re: An old problem: lack of priority select cases
>>>
>>> This is connected with my article:
>>> https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2
>>>
>>> I think there I show it is possible to workaround that limitation using
>>> standard Go tools. Of course, the code would be simple with priority
>>> select, but also perhaps select would become less efficient.
>>>
>>> On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L wrote:

 The old thread:
 https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o

 Go channels are flexible, but in practice, I often encountered some
 situations in which channel are hard to use.
 Given an example:

 import "math/rand"

 type Producer struct {
 data   chan int
 closed chan struct{}
 }

 func NewProducer() *Producer {
 p :=  {
 data:   make(chan int),
 closed: make(chan struct{}),
 }

 go p.run()

 return p
 }

 func (p *Produce) Stream() chan int {
 return p.data
 }

 func (p *Producer) run() {
 for {
 // If non-blocking cases are selected by their appearance order,
 // then the following slect block is a perfect use.
 select {
 case(0) <-p.closed: return
 case p.data <- rand.Int():
 }
 }
 }

 func (p *Produce) Clsoe() {
 close(p.closed)
 close(p.data)
 }

 func main() {
 p := NewProducer()
 for n := p.Stream() {
 // use n ...
 }
 }


 If the first case in the select block in the above example has a higher
 priority than the second one,
 then coding will be much happier for the use cases like the above one.

 In short, the above use case requires:
 * for receivers, data streaming end is notified by the close of a
 channel.
 * for senders, data will never be sent to closed channel.

 But, as Go 1 doesn't support priority select cases, it is much tedious
 to implement the code
 satisfying the above listed requirements. The final implementation is
 often very ugly and inefficient.

Re: [go-nuts] Re: Running tests per package with Go module

[Marcin Romaszewicz]

It could fail if you're under $GOPATH and GO111MODULE=auto, since inside
the GOPATH, auto=off

-- Marcin


On Tue, Aug 20, 2019 at 12:43 PM Jacques Supcik  wrote:

> Hello Chris,
>
> I made a small project with the same structure as yours to reproduce the
> problem : https://github.com/supcik/rtppwgm
>
> But in my project, everything works as expected :
>
> » go test -count=1 ./...
> ok  demo/pkg1   0.006s
> ok  demo/pkg2   0.006s
>
> » go test -count=1 ./pkg1/...
> ok  demo/pkg1   0.006s
>
> » go test -count=1 ./pkg2/...
> ok  demo/pkg2   0.005s
>
> Can you make a similar project that exposes your issue ?
>
> Cheers,
>
> -- Jacques
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/22e3a0fc-ed57-4b53-9ad5-faefab58c800%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] panic: interface conversion: interface is nil, not encoding.BinaryUnmarshaler

[Marcin Romaszewicz]

Here you go:
https://play.golang.org/p/_cPmaSxRatC

You want to unmarshal into , not into 

This means:
var duck2 A

not:
var duck2 Duck

On Wed, Aug 14, 2019 at 8:46 AM Jochen Voss  wrote:

> Hello,
>
> I'm trying to read gob-encoded data into a variable of interface type.  In
> simple cases, this works for me, but when I use a custom encoding
> via MarshalBinary() and UnmarshalBinary() methods, my code keeps crashing,
> with the error message
>
> panic: interface conversion: interface is nil, not
> encoding.BinaryUnmarshaler
>
> Example:
>
> - The code at https://play.golang.org/p/y8nWNhObUwb, letting gob do the
> en-/decoding works.
>
> - The very similar code at https://play.golang.org/p/-zS7QjEJg9x, which
> uses MarshalBinary() and UnmarshalBinary() crashes with the panic shown
> above.
>
> What am I doing wrong?
>
> [I asked the same question at
> https://stackoverflow.com/questions/57485698/, with no answers so far]
>
> Many thanks,
> Jochen
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b19c51bc-524c-4292-915b-fc00e9289052%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Module can't find itself

[Marcin Romaszewicz]

Thanks, and duh :) I was so busy trying to figure out why it wasn't
building that I neglected to check the basics.

-- Marcin


On Wed, Jul 24, 2019 at 9:31 PM Burak Serdar  wrote:

> On Wed, Jul 24, 2019 at 10:11 PM Marcin Romaszewicz 
> wrote:
> >
> > Hi All,
> >
> > I've got a module problem which I don't quite understand. All my code is
> here:
> > https://github.com/deepmap/oapi-codegen
> >
> > When I run "go build" from the top of the repo, I get:
> > $ go build
> > can't load package: package github.com/deepmap/oapi-codegen: unknown
> import path "github.com/deepmap/oapi-codegen": cannot find module
> providing package github.com/deepmap/oapi-codegen
>
> You're trying to build oapi-codegen package, which has no go files to
> build.
>
> Try go build 
>
> >
> > However, this works:
> > $ go build ./...
> >
> > Why can't my module find itself?
> >
> > I am using Go 1.12.7 on OS X. GO111MODULE=auto, and I am not in my
> $GOPATH. The
> > go.mod contains:
> > module github.com/deepmap/oapi-codegen
> >
> > require (...  ...)
> >
> > The same issue happens with go generate, go test, etc, but that makes
> sense as it all builds on top of the build command.
> >
> > Thanks for any tips,
> > -- Marcin
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LsHRrbULJDcT8kP8fnmP%3Dc8G0Oa1PXwLZ3a%2BPzN%2BWa8wg%40mail.gmail.com
> .
>

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

[go-nuts] Module can't find itself

[Marcin Romaszewicz]

Hi All,

I've got a module problem which I don't quite understand. All my code is
here:
https://github.com/deepmap/oapi-codegen

When I run "go build" from the top of the repo, I get:
$ go build
can't load package: package github.com/deepmap/oapi-codegen: unknown import
path "github.com/deepmap/oapi-codegen": cannot find module providing
package github.com/deepmap/oapi-codegen

However, this works:
$ go build ./...

Why can't my module find itself?

I am using Go 1.12.7 on OS X. GO111MODULE=auto, and I am not in my $GOPATH.
The
go.mod contains:
module github.com/deepmap/oapi-codegen

require (...  ...)

The same issue happens with go generate, go test, etc, but that makes sense
as it all builds on top of the build command.

Thanks for any tips,
-- Marcin

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

Re: [go-nuts] Re: prevent alteration of binaries once distributed in the wild?

[Marcin Romaszewicz]

Don't be too afraid of governments tampering with your program, I mean this
in the best possible way, but you are nobody important enough :)
Governments issue subpoenas, arrest warrants, and issue court orders -
that's much quicker and more effective than hacking. In the security space,
we also refer to "rubber hose cryptanalysis" being very effective. What is
it? You beat someone with a rubber hose until they give you the passwords.

The best you can do is give your users who care about the integrity of your
program a way to validate it. Post the SHA256 checksum of each binary
release, which would make it trivial for users to check if their executable
is modified. Naturally, this won't catch post-load modifications.

You can go a tiny step farther and obfuscate the checksum into your
executable with some form of white box crypto. White box crypto makes is
difficult, but not impossible, to extract a secret embedded in an
application. It's really not possible to check integrity effectively
without an external server. Even with an external server, your executable
could be sabotaged.

I wouldn't bother obfuscating, just strip your executable with the -s -w
ldflags to the linker. It is very difficult for most people to glean any
information from stripped programs.

None of this, of course, will stop a motivated attacker.

On Tue, Jul 23, 2019 at 3:09 PM clement auger 
wrote:

> thanks to everyone for sharing its thoughts about this question.
>
> it confirms what i read elsewhere.
>
> this app is to install on the end user computer,
> and there is no central authority required to use its
> service.Unlike the game Michael Jones is working on,
> where somehow the user must to connect some server.
>
> The only reason i have to introduce a central authority,
> or a network of peer validation (a way i have thought about to prevent a
> simple MITM),
> is for licensing concerns.
>
> Giving the control of the data to the end user is part of the value added
> of the product,
> so hosting it on a managed remote platform is not an option.
>
> I was hoping some sort of cross platform one-for-all solution.
> Ideally, quick to setup (...).
> Having to rely on package managers to install it is something i have to
> research.
>
> A quick search reveals projects to implement automatic patching.
> I did not think to search about this before today.
> It does not look like fully automated yet, but they definitely follow the
> path.
>
> Alternatively, an obfuscation tool exists here
> https://github.com/unixpickle/gobfuscate
> I ll give it a try but if anyone ever has tested it
> i would very much appreciate a feedback.
>
> Is it still true that -w might break things when using the reflection
> package ?
> https://stackoverflow.com/a/20928030
>
> On a broader and less personal perspective i also asked because i m
> freaking out of all those governments
> wanting to install backdoor everywhere and feel completely defenseless to
> what they will implement soon.
> Because they will do.
> But this is not a programming topic so i will not expand.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a513dbb4-d4d2-4169-b49c-5743e5ee8337%40googlegroups.com
> 
> .
>

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