[go-nuts] Re: Why does Go transform os.Args[] with colons in this way (win32/x64)

2020-06-11 Thread Russtopia 
Ah, bad form posting before I tried it in a plain CMD.EXE context.
The args are not transformed running from the vanilla command environment.
Guess it's a nasty interaction with MSYS.

-Russ


On Thu, 11 Jun 2020 at 20:03, Russtopia  wrote:

> On windows, Go 1.14 running in my case under MSYS64
>
> --
>
>> package main
>> import (
>> "fmt"
>> "os"
>> )
>> func main() {
>> for idx, a := range os.Args {
>> fmt.Printf("arg[%d]: %s\n", idx, a)
>> }
>> }
>
>
> $ go run argtest.go foo foo:bar foo:/bar/baz
> arg[0]: C:\msys64\tmp\go-build182983234\b001\exe\argtest.exe
> arg[1]: foo
> arg[2]: foo:bar
> arg[3]: foo;C:\msys64\bar\baz
>
>
> Note that last arg: seems Go converts 'foo:' to 'foo;C:' and then
> interprets the rest as an absolute unix path to be converted to a DOS-style
> path!
>
> Is there a good rationale why this is done?
> For context, I am writing a utility that I want to specify paths in the
> style of openssh/scp, eg. hostname:path without Go munging them into
> Windows-style paths.
>
>

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

[go-nuts] Why does Go transform os.Args[] with colons in this way (win32/x64)

2020-06-11 Thread Russtopia 
On windows, Go 1.14 running in my case under MSYS64

--

> package main
> import (
> "fmt"
> "os"
> )
> func main() {
> for idx, a := range os.Args {
> fmt.Printf("arg[%d]: %s\n", idx, a)
> }
> }


$ go run argtest.go foo foo:bar foo:/bar/baz
arg[0]: C:\msys64\tmp\go-build182983234\b001\exe\argtest.exe
arg[1]: foo
arg[2]: foo:bar
arg[3]: foo;C:\msys64\bar\baz


Note that last arg: seems Go converts 'foo:' to 'foo;C:' and then
interprets the rest as an absolute unix path to be converted to a DOS-style
path!

Is there a good rationale why this is done?
For context, I am writing a utility that I want to specify paths in the
style of openssh/scp, eg. hostname:path without Go munging them into
Windows-style paths.

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

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

2020-06-11 Thread Andy Balholm 
I’ve filed an issue: https://github.com/golang/go/issues/39542

> On Jun 11, 2020, at 6:08 PM, Ray Pereda  wrote:
> 
> 
> I think that regexp/syntax.patchlist.append refers to line 42 here
> https://golang.org/src/regexp/syntax/compile.go 
> 
> 
> Using a singly linked list with a pointer to the tail pointer would give 
> constant time append
> 
> Ray
> 
> On Thu, Jun 11, 2020 at 5:40 PM Andy Balholm  > wrote:
> Right. That’s why I left the double bar in my example. 
> 
> Basically all the time is spent appending to a linked list in 
> regexp/syntax.patchlist.append. Which makes sense, because appending to a 
> linked list when you only have a head pointer is O(n) in the length of the 
> list. So building the whole list that way is O(n^2).
> 
> Andy
> 
>> On Jun 11, 2020, at 4:47 PM, Kurtis Rader > > wrote:
>> 
>> On Thu, Jun 11, 2020 at 2:57 PM 'Axel Wagner' via golang-nuts 
>> mailto:golang-nuts@googlegroups.com>> wrote:
>> The Graph is clearly not linear. Another way to see this is to print out the 
>> ratio of time taken and i. If the cost is linear, you'd expect that ratio to 
>> be constant. When I run this code https://play.golang.org/p/v1JVQkOXnEH 
>>  on my machine I get...
>> 
>> The poor scalability of the example provided by Andy is due to the empty 
>> alternation. Using "D|" repeated as many times as you desire results in 
>> linear time and a constant number of memory allocations to compile the 
>> sequence. Changing the segment to "D||"  causes two allocations for every 
>> "||" instance. While "D||D" is legal it's also somewhat silly since it 
>> matches anything. Inserting a repetition between the two "|" (e.g., 
>> "D|d*|"), or a fixed length expression that is a different length (e.g., 
>> "D|xy|") results in the same behavior. Putting a fixed length expression 
>> between the two "|" that is the same length as the expression on the other 
>> side results in linear time even if the expression is a char class; e.g., 
>> "D|[xy]|". This doesn't surprise me given the research papers linked to 
>> earlier in this thread. Whether the pathological alternation case can be 
>> optimized to reduce the number of allocations is an open question.
>> 
>> -- 
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>> 
>> -- 
>> You received this message because you are subscribed to the Google 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/CABx2%3DD-ciPs%3DRa9GAO9SqXqFM_AFRV6TR6h3n3g-_DSpnzu%3DBg%40mail.gmail.com
>>  
>> .
> 
> 
> -- 
> 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/8M-qVbRKIWA/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/C52F7F0C-1DCA-44B6-ACE8-2F96066D62CD%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/61DDC42C-71A4-4BA4-A9CF-EEF2FCC9EE25%40gmail.com.

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

2020-06-11 Thread Ray Pereda 
I think that regexp/syntax.patchlist.append refers to line 42 here
https://golang.org/src/regexp/syntax/compile.go

Using a singly linked list with a pointer to the tail pointer would give
constant time append

Ray

On Thu, Jun 11, 2020 at 5:40 PM Andy Balholm  wrote:

> Right. That’s why I left the double bar in my example.
>
> Basically all the time is spent appending to a linked list in
> regexp/syntax.patchlist.append. Which makes sense, because appending to a
> linked list when you only have a head pointer is O(n) in the length of the
> list. So building the whole list that way is O(n^2).
>
> Andy
>
> On Jun 11, 2020, at 4:47 PM, Kurtis Rader  wrote:
>
> On Thu, Jun 11, 2020 at 2:57 PM 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> The Graph is clearly not linear. Another way to see this is to print out
>> the ratio of time taken and i. If the cost is linear, you'd expect that
>> ratio to be constant. When I run this code
>> https://play.golang.org/p/v1JVQkOXnEH on my machine I get...
>>
>
> The poor scalability of the example provided by Andy is due to the empty
> alternation. Using "D|" repeated as many times as you desire results in
> linear time and a constant number of memory allocations to compile
> the sequence. Changing the segment to "D||"  causes two allocations for
> every "||" instance. While "D||D" is legal it's also somewhat silly since
> it matches anything. Inserting a repetition between the two "|" (e.g., "
> D|d*|"), or a fixed length expression that is a different length (e.g., "
> D|xy|") results in the same behavior. Putting a fixed length expression
> between the two "|" that is the same length as the expression on the
> other side results in linear time even if the expression is a char class;
> e.g., "D|[xy]|". This doesn't surprise me given the research papers
> linked to earlier in this thread. Whether the pathological alternation case
> can be optimized to reduce the number of allocations is an open question.
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
> --
> You received this message because you are subscribed to the Google 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/CABx2%3DD-ciPs%3DRa9GAO9SqXqFM_AFRV6TR6h3n3g-_DSpnzu%3DBg%40mail.gmail.com
> 
> .
>
>
> --
> 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/8M-qVbRKIWA/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/C52F7F0C-1DCA-44B6-ACE8-2F96066D62CD%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/CANZUSA%2BVObY_21%3DEc7C4VEaKDrO2fS4eNtSrQuG0u059cc3fsw%40mail.gmail.com.

Re: [go-nuts] Re: GO on multi-processor systems

2020-06-11 Thread joe mcguckin 
Yes, of course they have internet connections, but I don't run 
virtualization software. It's my understanding that most of these 
bugs have to do with information leaking from one process or VM to another 
or with a process trying to escape from it's user process into a higher 
privileged one.  If simply being connected to the internet is risky enough 
that your machine can be compromised, there's more of a problem here than a 
cpu bug.

On Thursday, June 11, 2020 at 1:46:45 AM UTC-7, Kevin Chadwick wrote:
>
> >Actually, I'd like to turn off all the cpu bug fixes (e.g. row hammer). 
> > 
> >It's my understanding that there is a significant performance penalty 
> >and I 
> >don't share my machines 
> >with anyone else, so I'm not concerned with information leaking between 
> > 
>
> It is likely more dangerous, than you realise. So they don't receive any 
> data from the Internet? 
>

-- 
You received this message because you are subscribed to the Google 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/3fb303ba-0512-4928-982b-ef45edebac9fo%40googlegroups.com.

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

2020-06-11 Thread Andy Balholm 
Right. That’s why I left the double bar in my example. 

Basically all the time is spent appending to a linked list in 
regexp/syntax.patchlist.append. Which makes sense, because appending to a 
linked list when you only have a head pointer is O(n) in the length of the 
list. So building the whole list that way is O(n^2).

Andy

> On Jun 11, 2020, at 4:47 PM, Kurtis Rader  wrote:
> 
> On Thu, Jun 11, 2020 at 2:57 PM 'Axel Wagner' via golang-nuts 
> mailto:golang-nuts@googlegroups.com>> wrote:
> The Graph is clearly not linear. Another way to see this is to print out the 
> ratio of time taken and i. If the cost is linear, you'd expect that ratio to 
> be constant. When I run this code https://play.golang.org/p/v1JVQkOXnEH 
>  on my machine I get...
> 
> The poor scalability of the example provided by Andy is due to the empty 
> alternation. Using "D|" repeated as many times as you desire results in 
> linear time and a constant number of memory allocations to compile the 
> sequence. Changing the segment to "D||"  causes two allocations for every 
> "||" instance. While "D||D" is legal it's also somewhat silly since it 
> matches anything. Inserting a repetition between the two "|" (e.g., "D|d*|"), 
> or a fixed length expression that is a different length (e.g., "D|xy|") 
> results in the same behavior. Putting a fixed length expression between the 
> two "|" that is the same length as the expression on the other side results 
> in linear time even if the expression is a char class; e.g., "D|[xy]|". This 
> doesn't surprise me given the research papers linked to earlier in this 
> thread. Whether the pathological alternation case can be optimized to reduce 
> the number of allocations is an open question.
> 
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
> 
> -- 
> You received this message because you are subscribed to the Google 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/CABx2%3DD-ciPs%3DRa9GAO9SqXqFM_AFRV6TR6h3n3g-_DSpnzu%3DBg%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/C52F7F0C-1DCA-44B6-ACE8-2F96066D62CD%40gmail.com.

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

2020-06-11 Thread Kurtis Rader 
On Thu, Jun 11, 2020 at 2:57 PM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> The Graph is clearly not linear. Another way to see this is to print out
> the ratio of time taken and i. If the cost is linear, you'd expect that
> ratio to be constant. When I run this code
> https://play.golang.org/p/v1JVQkOXnEH on my machine I get...
>

The poor scalability of the example provided by Andy is due to the empty
alternation. Using "D|" repeated as many times as you desire results in
linear time and a constant number of memory allocations to compile
the sequence. Changing the segment to "D||"  causes two allocations for
every "||" instance. While "D||D" is legal it's also somewhat silly since
it matches anything. Inserting a repetition between the two "|" (e.g., "
D|d*|"), or a fixed length expression that is a different length (e.g., "
D|xy|") results in the same behavior. Putting a fixed length expression
between the two "|" that is the same length as the expression on the other
side results in linear time even if the expression is a char class; e.g., "
D|[xy]|". This doesn't surprise me given the research papers linked to
earlier in this thread. Whether the pathological alternation case can be
optimized to reduce the number of allocations is an open question.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
You received this message because you are subscribed to the Google 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/CABx2%3DD-ciPs%3DRa9GAO9SqXqFM_AFRV6TR6h3n3g-_DSpnzu%3DBg%40mail.gmail.com.

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

2020-06-11 Thread 'Axel Wagner' via golang-nuts 
The Graph is clearly not linear. Another way to see this is to print out
the ratio of time taken and i. If the cost is linear, you'd expect that
ratio to be constant. When I run this code
https://play.golang.org/p/v1JVQkOXnEH on my machine I get

1000 6.821361ms 6821.361
2000 27.229439ms 13614.7195
3000 65.352307ms 21784.1022
4000 118.262424ms 29565.606
5000 184.231412ms 36846.2824
6000 265.085287ms 44180.8811
7000 341.980378ms 48854.339714285714
8000 468.367349ms 58545.918625
9000 566.985419ms 62998.3798889
1 715.327926ms 71532.7926
11000 863.203647ms 78473.05881818182
12000 1.046590109s 87215.8424167
13000 1.208058338s 92927.56446153847
14000 1.367802614s 97700.18671428571
15000 1.599170348s 106611.3565334
16000 1.856199076s 116012.44225
17000 2.035878934s 119757.58435294118
18000 2.29658726s 127588.182
19000 2.57228423s 135383.3805263158

You can see the ratio increasing by ~7K on each increment (though there's
of course noise). This means the graph is pretty clearly quadratic.

On Thu, Jun 11, 2020 at 11:18 PM Andy Balholm  wrote:

> It’s more than linear. 1 repetitions take 73 times the time of 1000
> repetitions.
>
> Andy
>
> On Jun 11, 2020, at 2:11 PM, Ray Pereda  wrote:
>
> On my laptop, I compiled Andy's code from here:
> https://play.golang.org/p/82UBmyfyqV-
> I imported the output into google sheets and plotted it with a bar chart.
>
> https://docs.google.com/spreadsheets/d/1Pp8FBfHXgdMU54v6STutzDbb7SITGscFd84sUuJQ_gk/edit#gid=0
> The runtime strongly looks linear.
>
> Still, the constant in the O(n) runtime can possibly be improved with
> effort profiling the code and pull requests.
> There many man-months in fine-tuning the regexp engines in other languages
> like Perl, Python, C PCRE libraries, and Java.
> Any recommendations for Go profilers for this work would be appreciated.
>
> Ray
>
>
>
>
> On Thu, Jun 11, 2020 at 1:36 PM Andy Balholm 
> wrote:
>
>> Here is a simpler reproducer: https://play.golang.org/p/82UBmyfyqV-
>>
>> (Running it on the playground isn’t much use because of the playground’s
>> fake time, though.)
>>
>> It just repeats the string “D||” (with two vertical bars) to make the
>> regex. The runtime is roughly quadratic in the number of repetitions.
>>
>> Andy
>>
>> On Jun 11, 2020, at 12:55 PM, Andy Balholm  wrote:
>>
>> Obviously any reasonable input validation or length limit would disallow
>> it.
>>
>> The time requirement is only quadratic, not exponential, so it takes
>> ridiculously long inputs to cause a problem.
>>
>> Andy
>>
>> On Jun 11, 2020, at 12:26 PM, Robert Engels 
>> wrote:
>>
>> Why would you ever allow that regex?
>>
>> On Jun 11, 2020, at 11:01 AM, Andy Balholm  wrote:
>>
>> It’s apparently quadratic in some cases. Yesterday fuzzing on
>> github.com/andybalholm/cascadia found an input that triggered a timeout.
>> The time was being spent compiling a 180-KB regex (which I’m attaching to
>> this message). If I concatenate two copies of this file, the combined regex
>> takes at least four times as long to compile.
>>
>> I plan to investigate further, and see if I can find a way to reproduce
>> the issue that doesn’t look like it was generated by a fuzzer.
>>
>> Andy
>>
>>
>> --
>> You received this message because you are subscribed to the Google 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/885CBC71-3268-4BEA-983E-A67B824AC654%40gmail.com
>> 
>> .
>> 
>>
>>
>> On Jun 9, 2020, at 8:42 AM, 'Thomas Bushnell, BSG' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>> On Tue, Jun 9, 2020 at 11:23 AM Axel Wagner <
>> axel.wagner...@googlemail.com> wrote:
>>
>>> If you actually read OPs second E-Mail, they did and they didn't find it
>>> very clear. With that in mind, your message isn't very nice.
>>> (Also, not to be repetitive or anything: ~80% of the messages in this
>>> thread aren't actually concerned with what the complexity class *is*, but
>>> whether it matters)
>>>
>>
>> The OP stopped participating in this exciting thread a long time ago. I
>> went and read through the code, and it seems pretty clear to me that it's
>> linear.
>>
>> --
>> You received this message because you are subscribed to the Google 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%2BYjuxvQgnTKMM4FF4%3D4pspM-2nBJScNfCNinDv-2cNA09N%3DaQ%40mail.gmail.com
>>

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

2020-06-11 Thread Ray Pereda 
Oops, I screwed up the plot in google sheets.
I was only plotting the regexp length values.
I fixed the plot, and only plotted the y values, runtime.
The x-values are linearly spaced.

There is a curve. It doesn't look linear. I think Andy is right.
I did a quadratic curve fit with https://mycurvefit.com/
y = 7.763291 - 0.002980518*x + 0.08260165*x^2
with an R^2 value 0.9998

Ray


On Thu, Jun 11, 2020 at 2:18 PM Andy Balholm  wrote:

> It’s more than linear. 1 repetitions take 73 times the time of 1000
> repetitions.
>
> Andy
>
> On Jun 11, 2020, at 2:11 PM, Ray Pereda  wrote:
>
> On my laptop, I compiled Andy's code from here:
> https://play.golang.org/p/82UBmyfyqV-
> I imported the output into google sheets and plotted it with a bar chart.
>
> https://docs.google.com/spreadsheets/d/1Pp8FBfHXgdMU54v6STutzDbb7SITGscFd84sUuJQ_gk/edit#gid=0
> The runtime strongly looks linear.
>
> Still, the constant in the O(n) runtime can possibly be improved with
> effort profiling the code and pull requests.
> There many man-months in fine-tuning the regexp engines in other languages
> like Perl, Python, C PCRE libraries, and Java.
> Any recommendations for Go profilers for this work would be appreciated.
>
> Ray
>
>
>
>
> On Thu, Jun 11, 2020 at 1:36 PM Andy Balholm 
> wrote:
>
>> Here is a simpler reproducer: https://play.golang.org/p/82UBmyfyqV-
>>
>> (Running it on the playground isn’t much use because of the playground’s
>> fake time, though.)
>>
>> It just repeats the string “D||” (with two vertical bars) to make the
>> regex. The runtime is roughly quadratic in the number of repetitions.
>>
>> Andy
>>
>> On Jun 11, 2020, at 12:55 PM, Andy Balholm  wrote:
>>
>> Obviously any reasonable input validation or length limit would disallow
>> it.
>>
>> The time requirement is only quadratic, not exponential, so it takes
>> ridiculously long inputs to cause a problem.
>>
>> Andy
>>
>> On Jun 11, 2020, at 12:26 PM, Robert Engels 
>> wrote:
>>
>> Why would you ever allow that regex?
>>
>> On Jun 11, 2020, at 11:01 AM, Andy Balholm  wrote:
>>
>> It’s apparently quadratic in some cases. Yesterday fuzzing on
>> github.com/andybalholm/cascadia found an input that triggered a timeout.
>> The time was being spent compiling a 180-KB regex (which I’m attaching to
>> this message). If I concatenate two copies of this file, the combined regex
>> takes at least four times as long to compile.
>>
>> I plan to investigate further, and see if I can find a way to reproduce
>> the issue that doesn’t look like it was generated by a fuzzer.
>>
>> Andy
>>
>>
>> --
>> You received this message because you are subscribed to the Google 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/885CBC71-3268-4BEA-983E-A67B824AC654%40gmail.com
>> 
>> .
>> 
>>
>>
>> On Jun 9, 2020, at 8:42 AM, 'Thomas Bushnell, BSG' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>> On Tue, Jun 9, 2020 at 11:23 AM Axel Wagner <
>> axel.wagner...@googlemail.com> wrote:
>>
>>> If you actually read OPs second E-Mail, they did and they didn't find it
>>> very clear. With that in mind, your message isn't very nice.
>>> (Also, not to be repetitive or anything: ~80% of the messages in this
>>> thread aren't actually concerned with what the complexity class *is*, but
>>> whether it matters)
>>>
>>
>> The OP stopped participating in this exciting thread a long time ago. I
>> went and read through the code, and it seems pretty clear to me that it's
>> linear.
>>
>> --
>> You received this message because you are subscribed to the Google 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%2BYjuxvQgnTKMM4FF4%3D4pspM-2nBJScNfCNinDv-2cNA09N%3DaQ%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/885CBC71-3268-4BEA-983E-A67B824AC654%40gmail.com
>> 
>> .
>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

2020-06-11 Thread Andy Balholm 
It’s more than linear. 1 repetitions take 73 times the time of 1000 
repetitions. 

Andy

> On Jun 11, 2020, at 2:11 PM, Ray Pereda  wrote:
> 
> On my laptop, I compiled Andy's code from here: 
> https://play.golang.org/p/82UBmyfyqV- 
> I imported the output into google sheets and plotted it with a bar chart.
> https://docs.google.com/spreadsheets/d/1Pp8FBfHXgdMU54v6STutzDbb7SITGscFd84sUuJQ_gk/edit#gid=0
>  
> 
> The runtime strongly looks linear. 
> 
> Still, the constant in the O(n) runtime can possibly be improved with effort 
> profiling the code and pull requests.
> There many man-months in fine-tuning the regexp engines in other languages 
> like Perl, Python, C PCRE libraries, and Java.
> Any recommendations for Go profilers for this work would be appreciated.
> 
> Ray
> 
> 
> 
> 
> On Thu, Jun 11, 2020 at 1:36 PM Andy Balholm  > wrote:
> Here is a simpler reproducer: https://play.golang.org/p/82UBmyfyqV- 
> 
> 
> (Running it on the playground isn’t much use because of the playground’s fake 
> time, though.)
> 
> It just repeats the string “D||” (with two vertical bars) to make the regex. 
> The runtime is roughly quadratic in the number of repetitions.
> 
> Andy
> 
>> On Jun 11, 2020, at 12:55 PM, Andy Balholm > > wrote:
>> 
>> Obviously any reasonable input validation or length limit would disallow it. 
>> 
>> The time requirement is only quadratic, not exponential, so it takes 
>> ridiculously long inputs to cause a problem.
>> 
>> Andy
>> 
>>> On Jun 11, 2020, at 12:26 PM, Robert Engels >> > wrote:
>>> 
>>> Why would you ever allow that regex?
>>> 
 On Jun 11, 2020, at 11:01 AM, Andy Balholm >>> > wrote:
 
 It’s apparently quadratic in some cases. Yesterday fuzzing on 
 github.com/andybalholm/cascadia  
 found an input that triggered a timeout. The time was being spent 
 compiling a 180-KB regex (which I’m attaching to this message). If I 
 concatenate two copies of this file, the combined regex takes at least 
 four times as long to compile.
 
 I plan to investigate further, and see if I can find a way to reproduce 
 the issue that doesn’t look like it was generated by a fuzzer.
 
 Andy
 
 
 -- 
 You received this message because you are subscribed to the Google 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/885CBC71-3268-4BEA-983E-A67B824AC654%40gmail.com
  
 .
 
 
 
> On Jun 9, 2020, at 8:42 AM, 'Thomas Bushnell, BSG' via golang-nuts 
> mailto:golang-nuts@googlegroups.com>> 
> wrote:
> 
> On Tue, Jun 9, 2020 at 11:23 AM Axel Wagner 
> mailto:axel.wagner...@googlemail.com>> 
> wrote:
> If you actually read OPs second E-Mail, they did and they didn't find it 
> very clear. With that in mind, your message isn't very nice.
> (Also, not to be repetitive or anything: ~80% of the messages in this 
> thread aren't actually concerned with what the complexity class *is*, but 
>  whether it matters)
> 
> The OP stopped participating in this exciting thread a long time ago. I 
> went and read through the code, and it seems pretty clear to me that it's 
> linear. 
> 
> -- 
> You received this message because you are subscribed to the Google 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%2BYjuxvQgnTKMM4FF4%3D4pspM-2nBJScNfCNinDv-2cNA09N%3DaQ%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

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

2020-06-11 Thread Ray Pereda 
On my laptop, I compiled Andy's code from here:
https://play.golang.org/p/82UBmyfyqV-
I imported the output into google sheets and plotted it with a bar chart.
https://docs.google.com/spreadsheets/d/1Pp8FBfHXgdMU54v6STutzDbb7SITGscFd84sUuJQ_gk/edit#gid=0
The runtime strongly looks linear.

Still, the constant in the O(n) runtime can possibly be improved with
effort profiling the code and pull requests.
There many man-months in fine-tuning the regexp engines in other languages
like Perl, Python, C PCRE libraries, and Java.
Any recommendations for Go profilers for this work would be appreciated.

Ray




On Thu, Jun 11, 2020 at 1:36 PM Andy Balholm  wrote:

> Here is a simpler reproducer: https://play.golang.org/p/82UBmyfyqV-
>
> (Running it on the playground isn’t much use because of the playground’s
> fake time, though.)
>
> It just repeats the string “D||” (with two vertical bars) to make the
> regex. The runtime is roughly quadratic in the number of repetitions.
>
> Andy
>
> On Jun 11, 2020, at 12:55 PM, Andy Balholm  wrote:
>
> Obviously any reasonable input validation or length limit would disallow
> it.
>
> The time requirement is only quadratic, not exponential, so it takes
> ridiculously long inputs to cause a problem.
>
> Andy
>
> On Jun 11, 2020, at 12:26 PM, Robert Engels  wrote:
>
> Why would you ever allow that regex?
>
> On Jun 11, 2020, at 11:01 AM, Andy Balholm  wrote:
>
> It’s apparently quadratic in some cases. Yesterday fuzzing on
> github.com/andybalholm/cascadia found an input that triggered a timeout.
> The time was being spent compiling a 180-KB regex (which I’m attaching to
> this message). If I concatenate two copies of this file, the combined regex
> takes at least four times as long to compile.
>
> I plan to investigate further, and see if I can find a way to reproduce
> the issue that doesn’t look like it was generated by a fuzzer.
>
> Andy
>
>
> --
> You received this message because you are subscribed to the Google 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/885CBC71-3268-4BEA-983E-A67B824AC654%40gmail.com
> 
> .
> 
>
>
> On Jun 9, 2020, at 8:42 AM, 'Thomas Bushnell, BSG' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> On Tue, Jun 9, 2020 at 11:23 AM Axel Wagner 
> wrote:
>
>> If you actually read OPs second E-Mail, they did and they didn't find it
>> very clear. With that in mind, your message isn't very nice.
>> (Also, not to be repetitive or anything: ~80% of the messages in this
>> thread aren't actually concerned with what the complexity class *is*, but
>> whether it matters)
>>
>
> The OP stopped participating in this exciting thread a long time ago. I
> went and read through the code, and it seems pretty clear to me that it's
> linear.
>
> --
> You received this message because you are subscribed to the Google 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%2BYjuxvQgnTKMM4FF4%3D4pspM-2nBJScNfCNinDv-2cNA09N%3DaQ%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/885CBC71-3268-4BEA-983E-A67B824AC654%40gmail.com
> 
> .
>
>
>
> --
> 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/8M-qVbRKIWA/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/DECADAAC-2F98-463C-9202-132D6D0F93F6%40gmail.com
> 
> .
>


-- 
Ray

-- 
You received this message because you 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] what is the complexity of regexp.MustCompile()?

2020-06-11 Thread Andy Balholm 
Here is a simpler reproducer: https://play.golang.org/p/82UBmyfyqV- 


(Running it on the playground isn’t much use because of the playground’s fake 
time, though.)

It just repeats the string “D||” (with two vertical bars) to make the regex. 
The runtime is roughly quadratic in the number of repetitions.

Andy

> On Jun 11, 2020, at 12:55 PM, Andy Balholm  wrote:
> 
> Obviously any reasonable input validation or length limit would disallow it. 
> 
> The time requirement is only quadratic, not exponential, so it takes 
> ridiculously long inputs to cause a problem.
> 
> Andy
> 
>> On Jun 11, 2020, at 12:26 PM, Robert Engels > > wrote:
>> 
>> Why would you ever allow that regex?
>> 
>>> On Jun 11, 2020, at 11:01 AM, Andy Balholm >> > wrote:
>>> 
>>> It’s apparently quadratic in some cases. Yesterday fuzzing on 
>>> github.com/andybalholm/cascadia  
>>> found an input that triggered a timeout. The time was being spent compiling 
>>> a 180-KB regex (which I’m attaching to this message). If I concatenate two 
>>> copies of this file, the combined regex takes at least four times as long 
>>> to compile.
>>> 
>>> I plan to investigate further, and see if I can find a way to reproduce the 
>>> issue that doesn’t look like it was generated by a fuzzer.
>>> 
>>> Andy
>>> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google 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/885CBC71-3268-4BEA-983E-A67B824AC654%40gmail.com
>>>  
>>> .
>>> 
>>> 
>>> 
 On Jun 9, 2020, at 8:42 AM, 'Thomas Bushnell, BSG' via golang-nuts 
 mailto:golang-nuts@googlegroups.com>> wrote:
 
 On Tue, Jun 9, 2020 at 11:23 AM Axel Wagner >>> > wrote:
 If you actually read OPs second E-Mail, they did and they didn't find it 
 very clear. With that in mind, your message isn't very nice.
 (Also, not to be repetitive or anything: ~80% of the messages in this 
 thread aren't actually concerned with what the complexity class *is*, but  
 whether it matters)
 
 The OP stopped participating in this exciting thread a long time ago. I 
 went and read through the code, and it seems pretty clear to me that it's 
 linear. 
 
 -- 
 You received this message because you are subscribed to the Google 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%2BYjuxvQgnTKMM4FF4%3D4pspM-2nBJScNfCNinDv-2cNA09N%3DaQ%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/885CBC71-3268-4BEA-983E-A67B824AC654%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/DECADAAC-2F98-463C-9202-132D6D0F93F6%40gmail.com.

[go-nuts] Go 1.15 Beta 1 is released

2020-06-11 Thread Alexander Rakoczy 
Hello gophers,

We have just released go1.15beta1, a beta version of Go 1.15.
It is cut from the master branch at the revision tagged go1.15beta1.

Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.

Report any problems using the issue tracker:
https://golang.org/issue/new

If you have Go installed already, the easiest way to try go1.15beta1
is by using the go command:
$ go get golang.org/dl/go1.15beta1
$ go1.15beta1 download

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.15beta1

To find out what has changed in Go 1.15, read the draft release notes:
https://tip.golang.org/doc/go1.15

Cheers,
Alex for the Go Team

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

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

2020-06-11 Thread Andy Balholm 
Obviously any reasonable input validation or length limit would disallow it. 

The time requirement is only quadratic, not exponential, so it takes 
ridiculously long inputs to cause a problem.

Andy

> On Jun 11, 2020, at 12:26 PM, Robert Engels  wrote:
> 
> Why would you ever allow that regex?
> 
>> On Jun 11, 2020, at 11:01 AM, Andy Balholm  wrote:
>> 
>> It’s apparently quadratic in some cases. Yesterday fuzzing on 
>> github.com/andybalholm/cascadia  
>> found an input that triggered a timeout. The time was being spent compiling 
>> a 180-KB regex (which I’m attaching to this message). If I concatenate two 
>> copies of this file, the combined regex takes at least four times as long to 
>> compile.
>> 
>> I plan to investigate further, and see if I can find a way to reproduce the 
>> issue that doesn’t look like it was generated by a fuzzer.
>> 
>> Andy
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google 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/885CBC71-3268-4BEA-983E-A67B824AC654%40gmail.com
>>  
>> .
>> 
>> 
>> 
>>> On Jun 9, 2020, at 8:42 AM, 'Thomas Bushnell, BSG' via golang-nuts 
>>> mailto:golang-nuts@googlegroups.com>> wrote:
>>> 
>>> On Tue, Jun 9, 2020 at 11:23 AM Axel Wagner >> > wrote:
>>> If you actually read OPs second E-Mail, they did and they didn't find it 
>>> very clear. With that in mind, your message isn't very nice.
>>> (Also, not to be repetitive or anything: ~80% of the messages in this 
>>> thread aren't actually concerned with what the complexity class *is*, but  
>>> whether it matters)
>>> 
>>> The OP stopped participating in this exciting thread a long time ago. I 
>>> went and read through the code, and it seems pretty clear to me that it's 
>>> linear. 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google 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%2BYjuxvQgnTKMM4FF4%3D4pspM-2nBJScNfCNinDv-2cNA09N%3DaQ%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/885CBC71-3268-4BEA-983E-A67B824AC654%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/FB6E7B2F-E80E-4DAC-8A35-5029C205F565%40gmail.com.

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

2020-06-11 Thread Robert Engels 
Why would you ever allow that regex?

> On Jun 11, 2020, at 11:01 AM, Andy Balholm  wrote:
> 
> It’s apparently quadratic in some cases. Yesterday fuzzing on 
> github.com/andybalholm/cascadia found an input that triggered a timeout. The 
> time was being spent compiling a 180-KB regex (which I’m attaching to this 
> message). If I concatenate two copies of this file, the combined regex takes 
> at least four times as long to compile.
> 
> I plan to investigate further, and see if I can find a way to reproduce the 
> issue that doesn’t look like it was generated by a fuzzer.
> 
> Andy
> 
> -- 
> You received this message because you are subscribed to the Google 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/885CBC71-3268-4BEA-983E-A67B824AC654%40gmail.com.
> 
> 
> 
>> On Jun 9, 2020, at 8:42 AM, 'Thomas Bushnell, BSG' via golang-nuts 
>>  wrote:
>> 
>>> On Tue, Jun 9, 2020 at 11:23 AM Axel Wagner  
>>> wrote:
>> 
>>> If you actually read OPs second E-Mail, they did and they didn't find it 
>>> very clear. With that in mind, your message isn't very nice.
>>> (Also, not to be repetitive or anything: ~80% of the messages in this 
>>> thread aren't actually concerned with what the complexity class *is*, but  
>>> whether it matters)
>> 
>> The OP stopped participating in this exciting thread a long time ago. I went 
>> and read through the code, and it seems pretty clear to me that it's linear. 
>> 
>> -- 
>> You received this message because you are subscribed to the Google 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%2BYjuxvQgnTKMM4FF4%3D4pspM-2nBJScNfCNinDv-2cNA09N%3DaQ%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/885CBC71-3268-4BEA-983E-A67B824AC654%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/C5F82494-F4DD-4F69-9327-D19C219D%40ix.netcom.com.

[go-nuts] Re: For a .net developer,how long it takes to learn go completely?

2020-06-11 Thread Ronny Bangsund 
I'd say the more C-like languages you know, the easier it is to become 
fluent in Go. If you've already gotten used to switching between the likes 
of C, C++, C#, Java and more, you're likely to have fewer wrong assumptions 
about Go. Getting over the error handling verbosity is the major first 
step, I think :)

On Thursday, June 11, 2020 at 7:33:32 PM UTC+2, derek kenney wrote:
>
> There is a lot to Go. I'm still learning after three years. I will never 
> go back to .NET after moving to Go. Good luck. 
>
I miss things from C# in Go and vice versa. But C# isn't as useful in the 
Linux environments I prefer, and Go works well for both CLI tools and 
server software/glue.

-- 
You received this message because you are subscribed to the Google 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/52524822-b864-444a-b575-95f3f2503f69o%40googlegroups.com.

[go-nuts] Re: For a .net developer,how long it takes to learn go completely?

2020-06-11 Thread derek kenney 
Depends on what you mean by completely. I was writing production Go code 
within 6 months after moving on from .NET. There are fundamental 
programming differences I found in the way you approach solutions. 
There is a lot to Go. I'm still learning after three years. I will never go 
back to .NET after moving to Go. Good luck. 

On Thursday, 11 June 2020 13:25:06 UTC-4, P Walizada wrote:
>
> For a .net developer,how long it takes to learn go completely?
>

-- 
You received this message because you are subscribed to the Google 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/b8587ad8-2b0c-49af-82db-0be685ae8d89o%40googlegroups.com.

Re: [go-nuts] For a .net developer,how long it takes to learn go completely?

2020-06-11 Thread Jan Mercl 
On Thu, Jun 11, 2020 at 7:24 PM P Walizada  wrote:
>
> For a .net developer,how long it takes to learn go completely?

IMO Go can be learned in a day. Getting fluent and comfortable with it
takes longer, but that depends on how much code one writes.

The other question is, how long it takes in some cases to unlearn
habits and expectations from other languages. It seems some people
have bigger trouble with that than actually learning/mastering Go.

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

Re: [go-nuts] bytes.NewBuffer(make([]byte, 0, )) allocates 4096 bytes buffer

2020-06-11 Thread Jan Mercl 
On Thu, Jun 11, 2020 at 6:50 PM Gautam Saha  wrote:
>
> Trying to allocate an in-memory  buff of small size (few bytes) using
> bytes.NewBuffer(make([]byte, 0, ))
> The allocated buffer has size 4096 bytes i.e. > than what I requested for. 
> Why is this so?

Nowhere the docs say one can control the buffer size. Instead, the
passed []byte is documented to be used "as its initial contents", not
"as its initial buffer".

-- 
You received this message because you are subscribed to the Google 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-WByFmqUX8LhY7878hZ1kFQDDdd2%2BF%3DTt2QjL%3Dg4C%3DPmQ%40mail.gmail.com.

[go-nuts] For a .net developer,how long it takes to learn go completely?

2020-06-11 Thread P Walizada 
For a .net developer,how long it takes to learn go completely?

-- 
You received this message because you are subscribed to the Google 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/80756197-3335-42e2-9e1b-a9733ecad765o%40googlegroups.com.

[go-nuts] Re: bytes.NewBuffer(make([]byte, 0, )) allocates 4096 bytes buffer

2020-06-11 Thread Brian Candler 
Can you show how you came to that conclusion?  It seems to work as expected 
for me:
https://play.golang.org/p/wPBC1VBvkde

4096 bytes is typically a page, so maybe something is going on to do with 
allocation on page boundaries, but need to see your 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/6a2c8ae3-ed53-4596-aa83-a2b03ae9ea2ao%40googlegroups.com.

Re: [go-nuts] Compiler error when using an interface type in a list

2020-06-11 Thread burak serdar 
On Thu, Jun 11, 2020 at 10:50 AM John Sturdy  wrote:
>
> I've defined an interface type, and a concrete type that I think implements 
> that interface, but when I use it in a list, I get an error from the compiler 
> that makes it look like it doesn't.
>
> Here's my interface type, in anything/anything.go:
>
> package anything
>
> import (
> "fmt"
> )
>
> type AnyThing interface {
> Textual() string
> Numeric(name string) int
> }
>
> func OneCallee(thing AnyThing) {
> fmt.Printf("textual result is %s and numeric result is %d\n", 
> thing.Textual(), thing.Numeric("default"))
> }
>
> func ListCallee(things []AnyThing) {
> fmt.Printf("textual result is %s and numeric result is %d\n", 
> things[0].Textual(), things[0].Numeric("default"))
> }
>
>
> and here's a concrete type that defines the methods required by the 
> interface, in particularthing/particularthing.go:
>
> package particularthing
>
> type ParticularThing struct {
> Name string
> Number int
> }
>
> func (n ParticularThing) Textual() string {
> return n.Name
> }
>
> func (n ParticularThing) Numeric(name string) int {
> return n.Number
> }
>
> and here's the caller:
>
> package main
>
> import (
> "example.com/user/scratch/anything"
> "example.com/user/scratch/particularthing"
> )
>
> func main() {
> onething := particularthing.ParticularThing{"this", 1}
> anything.OneCallee(onething)
> thinglist := make([]particularthing.ParticularThing, 1)
> anything.ListCallee(thinglist)
> }
>
> When I compile it, I get:
>
> ./caller.go:12:21: cannot use thinglist (type 
> []particularthing.ParticularThing) as type []anything.AnyThing in argument to 
> anything.ListCallee
>
> Could some explain what the problem with this is?

An array of values implementing an interface cannot be used in place
of an array of those interfaces. Go's type system simply compares the
type required with the type provided, and []someInterface is not
[]someType. Note that the structure of the two objects passed to the
function is quite different. The function expects a []someInterface
where each element of the array is a pair containing the pointer to
the value and the type, but you are sending []someType where each
element is a value. So you have to convert:

intfList:=make([]AnyThing,0)
for _,x:=range thingList {
   intfList=append(intfList,x)
}
anything.ListCallee(intfList)

You can argue that the compiler can do this conversion. Such
potentially expensive operations are explicit in Go, which creates
some clutter but overall not a bad thing.



>
> I've attached a tarball of the files to make experimental changes easier.
>
> --
> You received this message because you are subscribed to the Google 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/3abb649b-f134-4535-8832-18c8ca0a54ebo%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/CAMV2Rqo-6xZU%2BUkQBCTeyyjrrXoBFk5jTxHHTDmmF8dKMDRnjw%40mail.gmail.com.

[go-nuts] Implement package level logging

2020-06-11 Thread Chashika Weerathunga 
hi,

logging Frameworks like log4j (for java) we can configure log levels for 
specific packages. My go project I am using *logrus* (
https://github.com/sirupsen/logrus) framework for logging. It doesn't 
support direct package level log enable disable support.   I want to know 
few basic things about the  implement logging in my go project. 

1)  Is there any logging framework which directly support that feature 
(package level log enable disable support) ?

2) If I implement that feature using logrus, is it good to create separate 
loggers (var log = logrus.New() ) for each package,  if I create like this 
where should I initiate the logger instance inside the package. (what the 
entry point of the package ) . I am thinking to implement inside of init() 
function. but it is only for the file. not for whole package... and what 
will be the most suitable way.

3) Your suggestion

I know this is a long question, but if you can give your suggestions, It 
will be really appreciated. 

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/79ebd493-f62e-4095-8dea-dc663d472452o%40googlegroups.com.

[go-nuts] bytes.NewBuffer(make([]byte, 0, )) allocates 4096 bytes buffer

2020-06-11 Thread Gautam Saha 
Trying to allocate an in-memory  buff of small size (few bytes) using 
bytes.NewBuffer(make([]byte, 0, ))
The allocated buffer has size 4096 bytes i.e. > than what I requested for. 
Why is this so?

-- 
You received this message because you are subscribed to the Google 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/8320e1ca-a627-4166-bbc2-ec793f258bffo%40googlegroups.com.

Re: [go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?

2020-06-11 Thread Robert Engels 
The wiki page has some neat details on this 
https://en.m.wikipedia.org/wiki/Mac_68k_emulator

> On Jun 10, 2020, at 9:49 PM, Robert Engels  wrote:
> 
> Yep. My timeline/memory was wrong. It was the 68k to PowerPC. Intel required 
> dual binaries. Thanks for the correction. 
> 
>> On Jun 10, 2020, at 8:26 PM, David Riley  wrote:
>> 
>> Not quite. When they switched to PowerPC, that was the case; the initial 
>> one was a table-driven instruction translator in ROM originally written for 
>> the M88k, which had been the original target before Motorola canned it, but 
>> it was apparently a relatively simple thing to change the translations to 
>> PowerPC instructions (only took a weekend according to legend, but, well, 
>> legends).  It eventually evolved into something much more sophisticated and 
>> performant.
>> 
>> The transition from PowerPC to Intel ended the Classic VM environment that 
>> ran Mac OS 9, which included the old 68k translator in the ROM file.  On a 
>> PowerPC Mac running OS X 10.4 (including G5s, which are 64-bit!), you can 
>> run 68k apps from the dark ages just fine (as long as they didn't use 
>> undocumented interfaces, etc).  I've been doing exactly this recently while 
>> porting a very old Mac game to modern systems.
>> 
>> Anyway, no Classic support on Intel, thus no 68k either (and PowerPC only 
>> for OS X apps).  The PowerPC emulation for Intel (Apple called it "Rosetta") 
>> was a licensed third-party product that used JIT-style compilation, but it 
>> really only worked for userland programs; it didn't support drivers and it 
>> presumably wasn't close enough to the real deal to support the Classic 
>> environment, so they dropped it in all Intel versions of Mac OS (10.5 
>> dropped it for PowerPC as well for reasons I don't quite understand, since 
>> that was the last PowerPC version).
>> 
>> Anyway, given that the PowerPC translation on Intel only lasted through 
>> 10.6, and Apple just dropped 32-bit Intel support in 10.15, I would expect 
>> backwards compatibility support for Intel apps (if they're even planning it) 
>> to drop within 2-3 revisions of macOS after the transition.  Just putting 
>> that out there.
>> 
 On Jun 10, 2020, at 8:47 PM, Robert Engels  wrote:
>>> 
>>> When Macs first switched to Intel the OS included a Motorola 68k emulator 
>>> so that existing Mac binaries would run. 
>> 

-- 
You received this message because you are subscribed to the Google 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/E186B60B-1F4E-4049-BDE9-7A0094E8ED3C%40ix.netcom.com.

Re: [go-nuts] Re: GO on multi-processor systems

2020-06-11 Thread Kevin Chadwick 
>Actually, I'd like to turn off all the cpu bug fixes (e.g. row hammer).
>
>It's my understanding that there is a significant performance penalty
>and I 
>don't share my machines
>with anyone else, so I'm not concerned with information leaking between
>

It is likely more dangerous, than you realise. So they don't receive any data 
from the Internet?

-- 
You received this message because you are subscribed to the Google 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/1486A9D3-7233-4851-A3BB-04B4004368F7%40gmail.com.

Re: [go-nuts] Re: GO on multi-processor systems

2020-06-11 Thread Brian Candler 
On Thursday, 11 June 2020 01:45:53 UTC+1, joe mcguckin wrote:
>
> Actually, I'd like to turn off all the cpu bug fixes (e.g. row hammer). 
> It's my understanding that there is a significant performance penalty and I 
> don't share my machines
> with anyone else, so I'm not concerned with information leaking between 
> processes.
>
>
For Linux, add mitigations=off to the kernel command line. e.g. for Ubuntu 
put this in /etc/default/grub:
GRUB_CMDLINE_LINUX="mitigations=off"
then run "update-grub" and reboot.

For virtualization-heavy workloads (network simulations) I've seen in 
excess of 30% loss in performance from the mitigations.

-- 
You received this message because you are subscribed to the Google 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/574111c4-10b9-4f4a-bd0f-0a16acbc65a5o%40googlegroups.com.

Re: [go-nuts] compress/bzip2：Why is there only a decompression function, no compression function.

2020-06-11 Thread lziqiang1 

My goodness, it is a great honor to get your detailed explanation. It seems 
that this is a fairly complicated algorithm. If I have time and can solve 
this problem, I try to solve it. Thank you.
在 2020年6月11日星期四 UTC+8下午12:37:30，Joe Tsai写道：
>
> > Why has this code called Joe Tsai never been merged?
>
> I am Joe Tsai and the reason why my bzip2 encoder implementation has not 
> been merged is because I have not had time to do it. Though I am a 
> contributor to the standard library, curating and improving it is not my 
> primary responsibility. In contrast, my other responsibilities have 
> continually kept any intention to merge the bzip2 encoder implementation at 
> the bottom of the task list. The most complicated portion of a bzip2 
> encoder is the implementation for a suffix array construction algorithm 
>  (SACA). Such algorithms are 
> fairly complex and require quite an investment by the reviewer to 
> understand. Given that its' been years since I touched the code, I would 
> hardly consider myself well-versed in SACAs at this point in time.
>
> JT
> On Tuesday, June 9, 2020 at 7:07:29 AM UTC-7 Michael Jones wrote:
>
>> Chapter 13 in 'The Go Programming Language" uses bzip as an example of 
>> CGO integration. Book is good, code is here:
>> https://github.com/adonovan/gopl.io/tree/master/ch13/bzip
>>
>> On Mon, Jun 8, 2020 at 7:06 PM 'Dan Kortschak' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> bzip2 compression is not trivial so making sure the review catches any
>>> issues will take time. Finding people with the relevant expertise and
>>> the time to do the review is not necessarily easy.
>>>
>>> Note that you can use the dsnet package.
>>>
>>> On Mon, 2020-06-08 at 18:55 -0700, lziq...@gmail.com wrote:
>>> > 
>>> > It seems that this issue was discussed long ago, but why is it not
>>> > compressed because of the lack of reviewers? Why has this code called
>>> > Joe Tsai never been merged? Does anyone have an official explanation?
>>> > I don't understand too much.
>>> > 在 2020年6月9日星期二 UTC+8上午5:30:34，kortschak写道：
>>> > > Also see https://godoc.org/github.com/dsnet/compress/bzip2 and 
>>> > > https://github.com/dsnet/compress/issues/58 
>>> > > 
>>> > > On Mon, 2020-06-08 at 13:14 -0400, Sam Whited wrote: 
>>> > > > See: https://github.com/golang/go/issues/4828 
>>> > > > 
>>> > > > On Mon, Jun 8, 2020, at 05:09, lziq...@gmail.com wrote: 
>>> > > > > Why is there no bzip2 compression algorithm, what is the
>>> > > reason? Do 
>>> > > > > you 
>>> > > > > need to add it? 
>>> > > > 
>>> > > > —Sam 
>>> > > > 
>>> > > > -- 
>>> > > > You received this message because you 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/4e2007ea-0215-41d3-afdc-1f77330dbdbd%40www.fastmail.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...@googlegroups.com.
>>> > To view this discussion on the web visit 
>>> > 
>>> https://groups.google.com/d/msgid/golang-nuts/d1ee336c-5ba7-4a60-9dc3-48f9d3141704o%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...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/9d35d55b58ac5b5c77e8290a2ad7319144535034.camel%40kortschak.io
>>> .
>>>
>>
>>
>> -- 
>>
>> *Michael T. jonesmichae...@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/2104d69d-4295-4bf9-9e07-443e2497174do%40googlegroups.com.

Re: [go-nuts] multiple-line 'expression' of if-statement not supported?

2020-06-11 Thread xiangdong...@gmail.com 
Thanks a lot, Ian, it works now.

On Thursday, June 11, 2020 at 2:17:23 PM UTC+8, Ian Lance Taylor wrote:
>
> On Wed, Jun 10, 2020 at 11:05 PM xiang...@gmail.com  
> > wrote: 
> > 
> > Wondering if the 'expression' part of an if-statement should be in one 
> line only, given the following case, 'go tool compile' will report a syntax 
> error 
> > 
> > Enter code here... 
> > package p 
> > 
> > func cf1() int { 
> > return 0 
> > } 
> > 
> > func cf2() int { 
> > return 10 
> > } 
> > 
> > func f() { 
> > if cf2() - 1 
> > < cf1() { 
> > println("tested") 
> > } 
> > } 
> > 
> > 
> > ss.go:13:3: syntax error: unexpected <, expecting expression 
> > 
> > Guess there might be syntax specification rules but I failed to find 
> out. 
>
> It's because of automatic semicolon insertion.  You need to put the 
> "<" at the end of the "if" line, not at the start of the next line. 
> See https://golang.org/ref/spec#Semicolons . 
>
> 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/b06a5576-6d9b-4066-9017-b6aeb61a665do%40googlegroups.com.

Re: [go-nuts] multiple-line 'expression' of if-statement not supported?

2020-06-11 Thread Ian Lance Taylor 
On Wed, Jun 10, 2020 at 11:05 PM xiangdong...@gmail.com
 wrote:
>
> Wondering if the 'expression' part of an if-statement should be in one line 
> only, given the following case, 'go tool compile' will report a syntax error
>
> Enter code here...
> package p
>
> func cf1() int {
> return 0
> }
>
> func cf2() int {
> return 10
> }
>
> func f() {
> if cf2() - 1
> < cf1() {
> println("tested")
> }
> }
>
>
> ss.go:13:3: syntax error: unexpected <, expecting expression
>
> Guess there might be syntax specification rules but I failed to find out.

It's because of automatic semicolon insertion.  You need to put the
"<" at the end of the "if" line, not at the start of the next line.
See https://golang.org/ref/spec#Semicolons .

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/CAOyqgcXJkjsa8tDOQYSrPp0PXWF-xvwj-gJFFJQk5LS9DjdxSw%40mail.gmail.com.

[go-nuts] multiple-line 'expression' of if-statement not supported?

2020-06-11 Thread xiangdong...@gmail.com 
Hi all,

Wondering if the 'expression' part of an if-statement should be in one line 
only, given the following case, 'go tool compile' will report a syntax error

Enter code here...
package p

func cf1() int {
return 0
}

func cf2() int {
return 10
}

func f() {
*if cf2() - 1*
*< cf1()* {
println("tested")
}
}


ss.go:13:3: syntax error: unexpected <, expecting expression

Guess there might be syntax specification rules but I failed to find out. 

Thanks a lot.

-- 
You received this message because you are subscribed to the Google 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/6887bd7f-5344-47b6-91ad-2960d2f67b33o%40googlegroups.com.