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

[Jason E. Aten]

So as not to omit the obvious... you could overwrite the password with 
"***" when you are done loading the key.

-- 
You received this message because you are subscribed to the Google 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/57713179-2f51-476e-a62c-87a9e919c683%40googlegroups.com.

[go-nuts] Re: About text-based user interface for Windows and Linux

[Jason E. Aten]

All the terminal emulators I've seen on Windows are garbage. I've only 
tried the free ones though. You could go through a
list like this 
https://www.slant.co/topics/1552/~best-terminal-emulators-for-windows 
systematically 
and try them all. Who knows,
maybe one of the paid-for ones will work. 

Whether Quick-Edit mode is on or off in the cmd.exe windows can make a 
difference for things like mouse clicks (
https://github.com/gdamore/tcell/issues/182 ),

 But really, write a web page instead.

-- 
You received this message because you are subscribed to the Google 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/2f030bca-92fb-4e3c-ab75-26353dc0c249%40googlegroups.com.

[go-nuts] Re: json decode is very slow

[Jason E. Aten]

you could try ffjson https://github.com/pquerna/ffjson

On Tuesday, April 28, 2020 at 12:49:08 PM UTC-4, Sarath Prabath Redlapalli 
Jaya wrote:
>
> req := {}
> json.NewDecoder(r.Body).Decode(req)
>
>
> We've instrument the above code block and reading request body bytes is 
> taking very long i.e., upto 5 secs sometimes reaching upto 20 seconds at 
> the throughput of ~4-5K RPM
>
> The Request Body Size Metrics are as follows
>
> Average: 73190 Bytes
> 90th percentile: 170862 Bytes
> 99th percentile: 467638 Bytes
>
> Tried ioutil.ReadAll too. But, the read time is same. We're not sure why 
> it's so very slow on production with HIGH BANDWIDTH Network line.
>
> Also, there are 5% of errors in this API with following errors while 
> decoding json data
>
>1. unexpected EOF
>2. Error in decoding request: read tcp 127.0.0.1:8080->127.0.0.1:48896: 
>i/o timeout
>
> We're using Kubernetes with Istio 1.0.5 on GCP. These errors are probably 
> from Envoy Sidecar, but since the Envoy acts as a reverse proxy, not sure 
> why we can get EOF or Timeout Errors since end user connection terminates 
> at proxy itself.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3cf4cb1d-cf8d-4eef-89f7-ba9f9fbb300e%40googlegroups.com.

Re: [go-nuts] Re: marshal multiple json documents which may have different format versions into the latest struct version

[Tom Payne]

Possibly also useful if you're dealing with JSON documents with different 
structures:
  https://github.com/twpayne/go-jsonstruct
This will generate the most specific Go struct possible that covers all the 
example documents that you give it. In your example it will generate:

package main

type T struct {
Cities   []string `json:"Cities,omitempty"`
Version  string   `json:"Version"`
Villages []string `json:"Villages,omitempty"`
}

which is the union of all versions.

If you already know exactly what structures you will receive, then Manilo's 
approach of first decoding into a struct only the Version field is better 
though, especially when combined with Go's runtime type switches.

Regards,
Tom

On Wednesday, April 29, 2020 at 9:31:00 AM UTC+1, Chris Burkert wrote:
>
> That sounds like a good plan. I'm going to try that. Thank you Manlio!
>
> Am Di., 28. Apr. 2020 um 15:11 Uhr schrieb Manlio Perillo <
> manlio...@gmail.com >:
>
>> On Tuesday, April 28, 2020 at 10:52:56 AM UTC+2, Chris Burkert wrote:
>>>
>>> Dear all,
>>>
>>> my application users shall be able to provide multiple json documents 
>>> (files and urls) which I'd like to marshall into one structure. 
>>> Additionally these json documents may have different versions. I know how 
>>> to marshal a document into a version specific struct if I know the format 
>>> version before (for simplicity of this example I don't handle errors): 
>>> https://play.golang.org/p/ixVI5CzPqFP
>>>
>>> What I would like (in the example the village field was renamed to 
>>> cities ) is a struct of type ModelV2 with all four values merged in Cities.
>>>
>>> Is there a best practice for a backwards compatible behavior which:
>>>
>>>- identifies the json format version of each document
>>>- skips that document if it is higher than the supported format 
>>>version in my application
>>>- merges supported format versions into ONE struct
>>>
>>> Of course I have to implement the semantics on my own but how can I 
>>> approach the topic?
>>>
>>>
>> You can first unmarshal a struct containing only the Version field.  As 
>> an example:
>> https://play.golang.org/p/1oDzdWlTCfC 
>> 
>>
>>
>> Manlio 
>>
>>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/274e489d-afdb-4ec9-a5b3-26440364c489%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/d035d66f-082b-41a5-9c31-f65ffe766515%40googlegroups.com.

[go-nuts] Re: Is there a library for validating gmail's Variants

[Andrey Tcherepanov]

I don't think it is a good idea to even try to figure it out. There are 
domains that using GSuite, or redirect to gmail as their mail service. They 
will use the same rules, but different host name.

On Thursday, April 30, 2020 at 11:05:43 AM UTC-6, Walter Peng wrote:
>
> Hello community, 
>
> We are running a small website which allow users registration with their 
> email. 
>
> Many users use gmail's variants to sign up the site, as we know, 
> foo...@gmail.com  is equivalent to below similar: 
>
> foo...@googlemail.com  
> foo...@googlemail.com  
> foo...@gmail.com  
> foo...@gmail.com  
> foo...@gmail.com  
> ... 
>
> Is there a library existing to validate all those variants to make sure 
> they are exactly the same account? 
>
> 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/a3f855ef-8898-4245-ba79-86dde593bf8c%40googlegroups.com.

Re: [go-nuts] Re: FIPS Crypto Algorithm Certification

[Ian Lance Taylor]

On Fri, May 1, 2020 at 2:50 PM albert.leung%centrify.com via
golang-nuts  wrote:
>
> This reply was 6 years ago.  Just curious if the golang team changes the 
> position on this or not?

See https://go.googlesource.com/go/+/dev.boringcrypto/README.boringcrypto.md .

Ian



> On Wednesday, April 9, 2014 at 1:43:52 PM UTC-7, agl wrote:
>>
>> On Monday, April 7, 2014 6:53:56 AM UTC-7, John Waycott wrote:
>>>
>>> I am wondering if there's been any discussion among the Go team about 
>>> getting FIPS algorithm certifications for some of the crypto in Go? 
>>> Specifically the PRNG, AES and SHA.
>>>
>>> I ask this because we'd like to eventually use Go for some of our crypto. 
>>> NIAP certification is easier of the crypto source has FIPS algorithm certs.
>>
>>
>> There are no plans for FIPS certification. The cost (in terms of money, time 
>> and pain of making future changes) is overwhelming.
>>
>>
>> Cheers
>>
>> AGL
>
> --
> You received this message because you are subscribed to the Google 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/06e98507-2d20-4942-b317-c671118b684e%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/CAOyqgcWP2A36aF0EqjrN7tqAMB841d0Jd9Ez%3DBLErsaF4JNeWA%40mail.gmail.com.

[go-nuts] Re: FIPS Crypto Algorithm Certification

[albert.leung%centrify.com via golang-nuts]

This reply was 6 years ago.  Just curious if the golang team changes the 
position on this or not?

Thanks
Albert

On Wednesday, April 9, 2014 at 1:43:52 PM UTC-7, agl wrote:
>
> On Monday, April 7, 2014 6:53:56 AM UTC-7, John Waycott wrote:
>>
>> I am wondering if there's been any discussion among the Go team about 
>> getting FIPS algorithm certifications for some of the crypto in Go? 
>> Specifically the PRNG, AES and SHA.
>>
>> I ask this because we'd like to eventually use Go for some of our crypto. 
>> NIAP certification is easier of the crypto source has FIPS algorithm certs.
>>
>
> There are no plans for FIPS certification. The cost (in terms of money, 
> time and pain of making future changes) is overwhelming.
>
>
> Cheers
>
> AGL
>

-- 
You received this message because you are subscribed to the Google 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/06e98507-2d20-4942-b317-c671118b684e%40googlegroups.com.

Re: [go-nuts] Re: net.ParseIP unable to parse some types of ipv6 addresses

[andrey mirtchovski]

thanks. that ought to do it.

On Fri, May 1, 2020 at 11:16 AM Brian Candler  wrote:
>
> parseIP returns a net.IP which is just a slice of bytes without the zone.
>
> However, type net.IPAddr includes the zone.  Looks like net.ResolveIPAddr 
> will do the job:
>
> https://play.golang.org/p/7p1XXIrVGI0
>
> --
> You received this message because you are subscribed to the Google 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/0168d004-5c54-4430-8c09-1a8a8d7ea736%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/CAK4xykXFVkrDe1w3T_24kyC9-Zd4DheJo6rpP7osemeRWSk%3Dcw%40mail.gmail.com.

[go-nuts] Re: net.ParseIP unable to parse some types of ipv6 addresses

[Brian Candler]

parseIP returns a net.IP which is just a slice of bytes without the zone.

However, type net.IPAddr  includes the 
zone.  Looks like net.ResolveIPAddr will do the job:

https://play.golang.org/p/7p1XXIrVGI0

-- 
You received this message because you are subscribed to the Google 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/0168d004-5c54-4430-8c09-1a8a8d7ea736%40googlegroups.com.

[go-nuts] net.ParseIP unable to parse some types of ipv6 addresses

[andrey mirtchovski]

IPv6 addresses including a zone identifier [rfc4007] are not parsed
correctly by net.ParseIP. is there any point in creating an issue or
is this intentional and we're supposed to strip the zone identifier?

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

-- 
You received this message because you are subscribed to the Google 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/CAK4xykWcNUG8jRyiEDo6UD%2BYJd7nENBqgd7se_ji1FAgxefNnw%40mail.gmail.com.

Re: [go-nuts] Build fails when following build instructions

['Than McIntosh' via golang-nuts]

Sorry, I wasn't clear on that last email.

What I'm asking is if you could rerun the compilation by hand, e.g.

$ cat > /tmp/CheckSymbolExists.c << EOF
#include 

int main(int argc, char** argv)
{
  (void)argv;
#ifndef mmap
  return ((int*)())[argc];
#else
  (void)argc;
  return 0;
#endif
}
EOF
$ /usr/bin/cc -fPIC -Werror=date-time -Wall -Wextra -Wno-unused-parameter
-Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long
-Wimplicit-fallthrough -Wno-comment -fdiagnostics-color -ffunction-sections
-fdata-sections -fuse-ld=gold -fsplit-stack  -fuse-ld=gold
-Wl,-allow-shlib-undefined /tmp/CheckSymbolExists.c -c -o
/tmp/CheckSymbolExists.o
$ /usr/bin/cc -v -fPIC -fuse-ld=gold -fsplit-stack  -fuse-ld=gold
-Wl,-allow-shlib-undefined -Wl,--debug,all  /tmp/CheckSymbolExists.o -o
/tmp/a.out  -lm
$

I am hoping that might give me a little more info.

Thanks, Than


On Fri, May 1, 2020 at 9:41 AM Martins Eglitis 
wrote:

> Sure, I have attached the CMakeOutput.log and CMakeError.log
> On 2020-05-01 16:19, Than McIntosh wrote:
>
>
> A little more detail on the error in question. This is a very obscure
> error, so please bear with me.
>
> >>/usr/bin/ld.gold: error:
> CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o: failed to match
> split-stack sequence at section 4 offset 0
>
> What's happening here is that the linker (ld.gold) is linking together two
> object files, let's call them "a.o" and "b.o".
>
> The linker detects that one of the objects (let's say "a.o") has a marker
> indicating that it was compiled with the "-fsplit-stack" option. The second
> object file "b.o" has no such marker (e.g. it apparently wasn't compiled
> with -fsplit-stack).
>
> In addition, the linker sees (from object file relocations) that a
> function (let's call it AFunc) in a.o is making a call to BFunc in b.o. In
> such instances the gold linker has a feature that will perform a
> fixup/rewrite on the calling function to make sure that when the call takes
> place, the stack is large enough (so that -split-stack will have the right
> effect).
>
> To apply this fixup, the linker is looking for a specific prolog
> instruction sequence-- when it doesn't find that sequence, it issues the
> error.
>
> In the previous LLVM bug I cited, the problem was with the C compiler --
> it was marking the object as split-stack, but not consistently emitting the
> prolog sequence that the linker looks for.
>
> Your compiler is an up-to-date version of GCC, however, so it's hard for
> me to believe that the compiler is at fault.
>
> [This is a lot of technical detail, sorry about that].
>
> Do you think you could rerun the compile by hand and send me some of the
> output (e.g. regenerate the file "CheckSymbolExists.c" as it appeared in
> the cmake output log?
>
> Thanks, Than
>
> On Thu, Apr 30, 2020 at 4:39 PM Martins Eglitis 
> wrote:
>
>> Sorry, I should have mentioned that I am running a docker container based
>> on the latest Ubuntu, and Ubuntu 18.04 as the host.
>>
>> On April 30, 2020 11:37:15 PM GMT+03:00, Martins Eglitis <
>> mart...@sitilge.id.lv> wrote:
>>>
>>> Yes,
>>>
>>> cc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
>>>
>>>
>>> On April 30, 2020 11:29:07 PM GMT+03:00, Than McIntosh 
>>> wrote:

 >>/usr/bin/ld.gold: error: CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o:
 failed to match split-stack sequence at section 4 offset 0

 OK, now I think we're getting somewhere, this looks suspicious.  For
 reference, could you please send me the output of "/usr/bin/cc --version"?

 Thanks, Than




 On Thu, Apr 30, 2020 at 4:26 PM Martins Eglitis 
 wrote:

> Hi,
>
> There was something related in "CMakeError.log":
>
> Determining if the mmap exist failed with the following output:
> Change Dir: /home/gopher/workarea/build-debug/CMakeFiles/CMakeTmp
>
> Run Build Command(s):/usr/bin/ninja cmTC_81c99 && [1/2] Building C object 
> CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o
> CheckSymbolExists.c: In function 'main':
> CheckSymbolExists.c:8:11: warning: ISO C forbids conversion of function 
> pointer to object pointer type [-Wpedantic]
> 8 |   return ((int*)())[argc];
>   |   ^
> [2/2] Linking C executable cmTC_81c99
> FAILED: cmTC_81c99
> : && /usr/bin/cc -fPIC -Werror=date-time -Wall -Wextra 
> -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers 
> -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-comment 
> -fdiagnostics-color -ffunction-sections -fdata-sections -fuse-ld=gold 
> -fsplit-stack  -fuse-ld=gold -Wl,-allow-shlib-undefined 
> CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o  -o cmTC_81c99  -lm && :
> /usr/bin/ld.gold: error: CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o: 
> failed to match split-stack sequence at section 4 offset 0
> collect2: error: ld returned 1 exit status
> ninja: build stopped: subcommand failed.
>

Re: [go-nuts] Build fails when following build instructions

['Than McIntosh' via golang-nuts]

A little more detail on the error in question. This is a very obscure
error, so please bear with me.

>>/usr/bin/ld.gold: error: CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o:
failed to match split-stack sequence at section 4 offset 0

What's happening here is that the linker (ld.gold) is linking together two
object files, let's call them "a.o" and "b.o".

The linker detects that one of the objects (let's say "a.o") has a marker
indicating that it was compiled with the "-fsplit-stack" option. The second
object file "b.o" has no such marker (e.g. it apparently wasn't compiled
with -fsplit-stack).

In addition, the linker sees (from object file relocations) that a function
(let's call it AFunc) in a.o is making a call to BFunc in b.o. In such
instances the gold linker has a feature that will perform a fixup/rewrite
on the calling function to make sure that when the call takes place, the
stack is large enough (so that -split-stack will have the right effect).

To apply this fixup, the linker is looking for a specific prolog
instruction sequence-- when it doesn't find that sequence, it issues the
error.

In the previous LLVM bug I cited, the problem was with the C compiler -- it
was marking the object as split-stack, but not consistently emitting the
prolog sequence that the linker looks for.

Your compiler is an up-to-date version of GCC, however, so it's hard for me
to believe that the compiler is at fault.

[This is a lot of technical detail, sorry about that].

Do you think you could rerun the compile by hand and send me some of the
output (e.g. regenerate the file "CheckSymbolExists.c" as it appeared in
the cmake output log?

Thanks, Than

On Thu, Apr 30, 2020 at 4:39 PM Martins Eglitis 
wrote:

> Sorry, I should have mentioned that I am running a docker container based
> on the latest Ubuntu, and Ubuntu 18.04 as the host.
>
> On April 30, 2020 11:37:15 PM GMT+03:00, Martins Eglitis <
> mart...@sitilge.id.lv> wrote:
>>
>> Yes,
>>
>> cc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
>>
>>
>> On April 30, 2020 11:29:07 PM GMT+03:00, Than McIntosh 
>> wrote:
>>>
>>> >>/usr/bin/ld.gold: error: CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o:
>>> failed to match split-stack sequence at section 4 offset 0
>>>
>>> OK, now I think we're getting somewhere, this looks suspicious.  For
>>> reference, could you please send me the output of "/usr/bin/cc --version"?
>>>
>>> Thanks, Than
>>>
>>>
>>>
>>>
>>> On Thu, Apr 30, 2020 at 4:26 PM Martins Eglitis 
>>> wrote:
>>>
 Hi,

 There was something related in "CMakeError.log":

 Determining if the mmap exist failed with the following output:
 Change Dir: /home/gopher/workarea/build-debug/CMakeFiles/CMakeTmp

 Run Build Command(s):/usr/bin/ninja cmTC_81c99 && [1/2] Building C object 
 CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o
 CheckSymbolExists.c: In function 'main':
 CheckSymbolExists.c:8:11: warning: ISO C forbids conversion of function 
 pointer to object pointer type [-Wpedantic]
 8 |   return ((int*)())[argc];
   |   ^
 [2/2] Linking C executable cmTC_81c99
 FAILED: cmTC_81c99
 : && /usr/bin/cc -fPIC -Werror=date-time -Wall -Wextra 
 -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers 
 -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-comment 
 -fdiagnostics-color -ffunction-sections -fdata-sections -fuse-ld=gold 
 -fsplit-stack  -fuse-ld=gold -Wl,-allow-shlib-undefined 
 CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o  -o cmTC_81c99  -lm && :
 /usr/bin/ld.gold: error: CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o: 
 failed to match split-stack sequence at section 4 offset 0
 collect2: error: ld returned 1 exit status
 ninja: build stopped: subcommand failed.


 File 
 /home/gopher/workarea/build-debug/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
 /* */
 #include 

 int main(int argc, char** argv)
 {
   (void)argv;
 #ifndef mmap
   return ((int*)())[argc];
 #else
   (void)argc;
   return 0;
 #endif
 }

 On 2020-04-30 20:32, Than McIntosh wrote:

 Thanks for the email.

 Sorry for the delay in responding, this is a very busy time right now
 for our team (release freeze is happening at the end of this week).

 Just in general, the gollvm build procedure uses "cmake", and as part
 of this process cmake is running various tests to make sure that the C
 compiler you're using works properly, and to detect whether the system you
 are building on has the right header files, libraries, etc.

 Of particular concern is the cmake check for "mmap"-- the mmap()
 routine is definitely available on Ubuntu, so it's puzzling that cmake
 thinks it isn't available.

 One thing you might do: after the build fails, try looking at the
 debris in the CMakeFiles dir:

 $ ls CMakeFiles
 3.13.4 

[go-nuts] Re: URL parsing with special characters.

[Vivek]

Thanks everyone.

I am using "github.com/jlaffaye/ftp" library which returned unescaped file 
names when doing directory listing. I constructed the full url by doing 

filePath = "ftp://user:pass@192.168.0.1/path/; + "file%ver3.txt 
"
 
and later tried to parse the url with url.Parse function somewhere else in 
the code which failed.

I am now calling url.Escape on the file names before appending. 

Regards,
Vivek



On Thursday, 30 April 2020 22:35:45 UTC+5:30, Vivek wrote:
>
> I am trying to parse  a url similar to "ftp://
> user:pass@192.168.0.1/path/file%ver3.txt 
> "
>  
> using `net/url` Parse function but I am getting a error
>
> `parse "ftp://user:pass@192.168.0.1/path/file%ver3.txt": invalid URL 
> escape "%ve"`
>
> https://play.golang.org/p/HE6zlDeIbyq 
> 
>
> The same path parses fine with python(urllib.parse.urlparse and C# URI). 
>
> I appreciate any help on this.
>
> Regards,
> Vivek
>

-- 
You received this message because you are subscribed to the Google 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/a55c65be-fce0-43d7-95ea-2d33cb7746dc%40googlegroups.com.

Re: [go-nuts] Re: URL parsing with special characters.

[Brian Candler]

On Thursday, 30 April 2020 23:04:01 UTC+1, Ian Lance Taylor wrote:
>
> On Thu, Apr 30, 2020 at 11:09 AM Brian Candler  > wrote: 
> > 
> > In a URL, the percent sign should appear as %25  (% marks the start of a 
> hex-encoded character) 
> > https://play.golang.org/p/gMC1tdpJER4 
> > 
> > The URL as shown is invalid. 
>
> I *think* you are saying that the u.Path field should use %25 rather 
> than plain %.



No: I'm just saying the library is working correctly, by rejecting the 
invalid input that the OP gave.

If the input URL is correct to file%25ver3, then the parsed u.Path contains 
file%ver3 as expected.

-- 
You received this message because you are subscribed to the Google 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/453fe1df-34b0-4156-8d9c-5eaa62f485aa%40googlegroups.com.

Re: [go-nuts] Question about strings.EqualFold vs Python's casefold

[Miki Tebeka]

Thanks!

On Friday, May 1, 2020 at 8:21:48 AM UTC+3, Ian Lance Taylor wrote:
>
> On Thu, Apr 30, 2020 at 9:42 PM Miki Tebeka  > wrote: 
> > 
> > I'm trying to find an example where strings.EqualFold returns true but 
> comparison of strings.ToLower fails. 
> > I've found this example (in Python): 
> > 
> > s1 = "der Fluß" 
> > s2 = "der Fluss" 
> > 
> > print('lower', s1.lower() == s2.lower()) 
> > print('fold ', s1.casefold() == s2.casefold()) 
> > 
> > Which prints False for lower and True for casefold. 
> > 
> > When I try the same in Go 
> > package main 
> > 
> > import ( 
> > "fmt" 
> > "strings" 
> > ) 
> > 
> > func main() { 
> > 
> > s1 := "der Fluß" 
> > s2 := "der Fluss" 
> > 
> > fmt.Println("lower", strings.ToLower(s1) == strings.ToLower(s2)) 
> > fmt.Println("fold ", strings.EqualFold(s1, s2)) 
> > } 
> > 
> > I get false for both ToLower and EqualFold. 
> > 
> > Shouldn't Unicode folding be the same across languages? 
> > Also, does anyone have an example I can show in Go where ToLower does 
> not compare and EqualFold does? 
>
> strings.EqualFold uses Unicode case folding, not case mapping.  Case 
> folding is only one-to-one character transformations.  Converting "ss" 
> to "ß" is case mapping, and as such is not used by strings.EqualFold. 
> For that, you want the x/text/search package, as in 
>
> package main 
>
> import ( 
> "fmt" 
>
> "golang.org/x/text/language" 
> "golang.org/x/text/search" 
> ) 
>
> func main() { 
> m := search.New(language.German, search.Loose) 
> s1 := "der Fluß" 
> s2 := "der Fluss" 
> fmt.Println(m.EqualString(s1, s2)) 
> } 
>
> That should print true. 
>
> An example where strings.EqualFold does not return the same result as 
> strings.ToLower(s1) == strings.ToLower(s2) is 
>
> s1 := "σς" 
> s2 := "ΣΣ" 
>
> strings.EqualFold will return true but comparing the ToLower of the 
> strings will return false.  This is because there are two lower case 
> forms of Σ (depending on position in the word), but strings.ToLower 
> can of course only return one. 
>
> 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/3e9f1ac7-fb91-44ce-9f7c-68a1f746eba1%40googlegroups.com.