Re: [go-nuts] Preserving special characters when reading Go POST request body
On Mon, Jul 1, 2024 at 12:04 PM Hugh Myrie wrote: > > I am trying to preserve special characters (group separators and field > separators) when reading the request body from a POST request. > > When I do a dumpRequest I am able to see the special characters (Hex Format, > for example: \x1c or \x03). I am sending the data from the client as > text/plain. > > I have tried sending the data as JSON and using the decoder in Go. I have > also tried using Base64 and decoding in go accordingly. I have tried > json.unmarshal to decode the incoming JSON data. However, in every instance > the special characters are removed. > > I need the special characters to be preserved so I can send the data for > further processing. I need the special characters not the hexadecimal > representation. > > I am able to see the actual data being sent to the Go server. I also tried > encoding the data from the client side. > > Your help would be greatly appreciated. Can you provide a reasonably small, but complete, example that demonstrates the problem? 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/CAOyqgcVT0Yr%2ByZKbMJw0Q%3DKXP%3Desu45y%2BERidgWRXxu3vcJOMQ%40mail.gmail.com.
[go-nuts] Re: Advancing the container/set design?
+1 on this.
At the moment, every module that needs a set implementation ends up
creating its own, either using map[T]struct{} or map[T]bool. Having a set
implementation in the standard library would significantly increase
operability between modules, even if the implementation is trivial.
On Monday, July 1, 2024 at 7:43:19 PM UTC+2 Frederik Zipp wrote:
> Some time ago, Ian started a discussion about a potential proposal for a
> container/set package: https://github.com/golang/go/discussions/47331
>
> The main point of uncertainty was iterating over elements. Now that
> iteration is solved in Go 1.23, is it perhaps time to advance this design
> and turn it into a proposal for the 1.24 release cycle?
>
--
You received this message because you are subscribed to the Google 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/7730dc45-fc43-4ac5-a9b3-2c8ec7647dddn%40googlegroups.com.
[go-nuts] Preserving special characters when reading Go POST request body
I am trying to preserve special characters (group separators and field separators) when reading the request body from a POST request. When I do a dumpRequest I am able to see the special characters (Hex Format, for example: \x1c or \x03). I am sending the data from the client as text/plain. I have tried sending the data as JSON and using the decoder in Go. I have also tried using Base64 and decoding in go accordingly. I have tried json.unmarshal to decode the incoming JSON data. However, in every instance the special characters are removed. I need the special characters to be preserved so I can send the data for further processing. I need the special characters not the hexadecimal representation. I am able to see the actual data being sent to the Go server. I also tried encoding the data from the client side. Your help would be greatly appreciated. -- You received this message because you are subscribed to the Google 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/6866b137-3606-45b1-9feb-67cf00d4a71en%40googlegroups.com.
[go-nuts] Advancing the container/set design?
Some time ago, Ian started a discussion about a potential proposal for a container/set package: https://github.com/golang/go/discussions/47331 The main point of uncertainty was iterating over elements. Now that iteration is solved in Go 1.23, is it perhaps time to advance this design and turn it into a proposal for the 1.24 release cycle? -- You received this message because you are subscribed to the Google 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/e52b942f-2642-483a-b451-14a25f422ea3n%40googlegroups.com.
Re: [go-nuts] is stop the world and restart the world overhead expensive?
On Mon, Jul 1, 2024 at 5:45 AM 杨杰 wrote: > > i implement an goroutine profile which use frame pointer to get traceback. > > it need stop and restart the world with 100hz. > > is this operation expensive? Yes. Since the concern is profiling, I'll note that it will also significantly affect the program's behavior, so a profile that is constantly stopping and starting the world may not be a good reflection of the performance of the program when that is not happening. 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/CAOyqgcViro_A%3DH4ZMt6V-0%3Dh4Q3vsZS_4DENm8jyfu6yjsy2Zw%40mail.gmail.com.
[go-nuts] Should the phrasing about method sets in Go FAQ be slightly clarified?
https://go.dev/doc/faq#different_method_sets I am referring to this paragraph that in my opinion answers one of the trickiest questions for new Go developers. *Even in cases where the compiler could take the address of a value to pass to the method, if the method modifies the value the changes will be lost in the caller. As an example, if the Write method of bytes.Buffer used a value receiver rather than a pointer, this code:var buf bytes.Bufferio.Copy(buf, os.Stdin)would copy standard input into a copy of buf, not into buf itself. This is almost never the desired behavior.* Even though I understand the explanation, I think that it's a bit unclear. If the Write method used a value receiver, then the whole example doesn't make sense and the part "E*ven in cases where the compiler could take the address of a value" *doesn't apply at all because the code works as is, and the compiler doesn't really have to take any addresses. My bet is that the document meant "if the code above worked..." What do you think? -- You received this message because you are subscribed to the Google 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/31623bcd-8902-450b-8498-147ac00e5e06n%40googlegroups.com.
[go-nuts] is stop the world and restart the world overhead expensive?
i implement an goroutine profile which use frame pointer to get traceback. it need stop and restart the world with 100hz. is this operation expensive? see https://github.com/felixge/fgprof/issues/31 -- You received this message because you are subscribed to the Google 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/bb24961c-38a5-4e81-b262-089b9f8786cdn%40googlegroups.com.
