Can't you move the go.mod one level up, into the root?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this
I havemf eun tour code bit the lower case "eye" jumps out as something to look
at... "case iD".
Hope that helps. A debugger to walk through should help!
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and
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, lziqia...@gmail.com wrote:
>
Ray, only the discussion is exponential.
On Mon, Jun 8, 2020 at 4:23 PM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> On Tue, Jun 9, 2020 at 12:48 AM Kurtis Rader wrote:
>
>> You're talking past each other. Robert is talking about limiting the
>> length of the regex,
On Tue, Jun 9, 2020 at 12:48 AM Kurtis Rader wrote:
> You're talking past each other. Robert is talking about limiting the
> length of the regex, not the string(s) evaluated by the regex.
>
So am I. Note that e.g. a Code Search based on PCRE would break, even if
you limit *both* (or rather, any
I am scanning database tables into a structure explicitly (with
) that works just fine (working path below).
But my tables have different columns, so I am working to generalize the
API. There are two methods that build and reverse a []interface{} to be
supplied to scan. I have listed them
You're talking past each other. Robert is talking about limiting the length
of the regex, not the string(s) evaluated by the regex. It should be
possible to compile any regex of a reasonable length in a matter of
microseconds. Regardless of whether the application of the regex to a given
input is
Dnia 2020-06-08, o godz. 16:22:24
Robert Engels napisał(a):
> it is trivial to limit the input size to something a user could input.
With exponential complexity simple regex /(x+x+)+y/ blows up at input of 20 to
30 x-es.
See: https://www.regular-expressions.info/catastrophic.html
[Cut long
They don't have to be *arbitrarily* long. They actually can be quite short.
2^n is large, even for relatively small n.
Again, I refer to the graphs in the blog post above. We are talking about
input length of less than 100 characters to get CPU churn of *minutes*.
That's not a huge limit for a
On Sun, Jun 7, 2020 at 12:04 PM Diego Augusto Molina
wrote:
>
> Very often I use the stringer command to generate lists of enumerated values,
> which is great btw.
> But one thing that I see myself also writing after this is a Parse method or
> function to validate strings that are received.
>
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, lziqia...@gmail.com wrote:
> > Why is there no bzip2
You can’t say it arbitrary regex inputted by a user then claim they can be
arbitrarily long - these are incompatible. For any reasonable user input the
compile time is negligible, and it is trivial to limit the input size to
something a user could input.
> On Jun 8, 2020, at 2:27 PM, Axel
Note that in general C strings are not restricted to 2³¹ bytes on 64-bit
systems.
(Larger strings are unusual, but fairly trivial to construct.)
So I would recommend avoiding hard-coded array types of any size.
You say that C.GoBytes truncates at zero. However, that does not reproduce
for me.
On Mon, Jun 8, 2020 at 9:59 AM Yegor Roganov wrote:
>
> My team is developing a cloud-based data processing application, and a large
> bulk of the application's job is doing network calls to other services.
> Go's goroutines and channel-based communication are an excellent fit, but in
> order
And that exact logic is what wouldn't work, if compilation or matching
would be exponential, for example.
Being able to say "as long as the inputs don't get astronomically long, the
running time of the algorithm will be reasonable" is *exactly* the
conclusion that a small complexity class gives
On Mon, Jun 8, 2020 at 10:44 AM Viktor Kojouharov wrote:
>
> The full code can be seen in this diff:
>
> https://github.com/urandom/go/commit/d10ccdd907dac690bfcb31df1115ce1508775458
>
> The just of it is, I've added an extra field to a struct (the chan) of type
> unsafe.Pointer. The value is
If the input regex string is bounded by a typical user input box - the
compilation time will be negligible when compared to the runtimes.
> On Jun 8, 2020, at 11:07 AM, Axel Wagner
> wrote:
>
>
> Oh, true, I overlooked that detail. But FTR, they clarify their question
> subsequently and
See: https://github.com/golang/go/issues/4828
On Mon, Jun 8, 2020, at 05:09, lziqia...@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"
Why is there no bzip2 compression algorithm, what is the reason? Do you
need to add it?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Hello,
My team is developing a cloud-based data processing application, and a
large bulk of the application's job is doing network calls to other
services.
Go's goroutines and channel-based communication are an excellent fit, but
in order for the application to be able to properly shut down,
Hello,
given repository structured as
+ $ tree .
.
├── foo
└── go
├── go.mod
└── main.go
1 directory, 3 files
I'm trying to setup go-import meta tag for it, however it just does not
seem to work. Meta tag looks like this:
It is correctly resolved to the repository, the repository
Hello people,
since now I've used the standard "flags" library for parsing the arguments.
What I really miss in it are two things though:
- long and short syntaxes (only "long" one is supported)
- help printer (which can be done externally in any case)
I'm now developing another software and I
Oh, true, I overlooked that detail. But FTR, they clarify their question
subsequently and specifically ask whether compilation is linear in
expression size. No Must* in that clarification.
On Mon, Jun 8, 2020 at 6:05 PM Thomas Bushnell, BSG
wrote:
> On Mon, Jun 8, 2020 at 12:02 PM Axel Wagner
On Mon, Jun 8, 2020 at 3:38 PM Robert Engels wrote:
> I will claim it also doesn’t matter because you need external bounding
> anyway. Take a simple recursive directory listing. It is linear time
> bounded.
>
Depends on what we're talking about as the "input" here. It is certainly
not linearly
On Mon, Jun 8, 2020 at 12:02 PM Axel Wagner
wrote:
> On Mon, Jun 8, 2020 at 5:41 PM Thomas Bushnell, BSG
> wrote:
>
>> The OP was about MustCompile, so I think it's clear they are not using
>> patterns passed in by external requests.
>>
>
> I don't think that's clear at all. How do you assume
On Mon, Jun 8, 2020 at 5:41 PM Thomas Bushnell, BSG
wrote:
> The OP was about MustCompile, so I think it's clear they are not using
> patterns passed in by external requests.
>
I don't think that's clear at all. How do you assume patterns from external
sources can be matched, if not by
The OP was about MustCompile, so I think it's clear they are not using
patterns passed in by external requests.
On Mon, Jun 8, 2020 at 9:39 AM Robert Engels wrote:
> I will claim it also doesn’t matter because you need external bounding
> anyway. Take a simple recursive directory listing. It is
I will claim it also doesn’t matter because you need external bounding anyway.
Take a simple recursive directory listing. It is linear time bounded. Perform
it on the top level on a sufficiently large directory and it might run for days
consuming TBs of memory - easily becoming a DOS attack
On Mon, Jun 8, 2020 at 3:19 PM Robert Engels wrote:
> I don’t see anything in the blog post referring to compilation time - only
> runtime.
>
Sure. It's more a general point about you saying algorithmic complexity
doesn't matter.
> That being said I couldn’t review the graphs on my phone.
>
>
I don’t see anything in the blog post referring to compilation time - only
runtime. That being said I couldn’t review the graphs on my phone.
Even still, to prevent DOS you can bound the compilation time as easily as the
runtime. If the lib doesn’t support it a simple fork to add an emit with
>No offense :)
I'm really glad for your message!
I decided to write the install method in two cases.
I remembered the old use of "go get" as a way to get a module.
Thank you for messaging me.
2020年6月8日月曜日 21時29分59秒 UTC+9 Tamás Gulácsi:
>
>
>
> 2020. június 8., hétfő 14:09:50 UTC+2 időpontban
On Mon, Jun 8, 2020 at 2:53 PM Robert Engels wrote:
> Attempting to prevent DOS attacks through algorithm efficiency never works
>
Uhm, no, it totally does. Code Search is a real-world example of it working
at least once.
> you have to have resource throttling.
>
Well, yes. But reigning in
Attempting to prevent DOS attacks through algorithm efficiency never works -
you have to have resource throttling.
I’m guessing the IO cost of pulling the text in this case has a better chance
of creating a DOS than the regex compile.
> On Jun 8, 2020, at 7:40 AM, 'Axel Wagner' via
Hi Amnon,
if you read the blog posts I linked above, you'll find examples of where we
care very much. RE2 was developed for enabling regular expression search in
a large source code corpus. In that scenario, the attacker controls both
the regular expression and (to a degree) the text to be
2020. június 8., hétfő 14:09:50 UTC+2 időpontban 加藤泰隆 a következőt írta:
>
> Thank you for your message.
>
> I was mistaken. Sorry.
> I was use "go mod" incorrectly.
> I fixed it as soon as possible.
>
> 2020年6月8日月曜日 20時47分33秒 UTC+9 Tamás Gulácsi:
>>
>> 2020. június 6., szombat 6:20:46 UTC+2
Thank you for your message.
I was mistaken. Sorry.
I was use "go mod" incorrectly.
I fixed it as soon as possible.
2020年6月8日月曜日 20時47分33秒 UTC+9 Tamás Gulácsi:
>
> 2020. június 6., szombat 6:20:46 UTC+2 időpontban 加藤泰隆 a következőt írta:
>>
>> Hi. i'm engeneer in japan. I write any programs as a
2020. június 6., szombat 6:20:46 UTC+2 időpontban 加藤泰隆 a következőt írta:
>
> Hi. i'm engeneer in japan. I write any programs as a hobby each days.
> Today, I introduce new diff tool made me.
>
> features are..
> - compare different on multi tab
> - difference text is colored
> - can search
Sorry, I did not write about license, and now added!
It's MIT license.
Please feel free to use it within the scope of the license.
Sorry, I did not write about license, and now added!
It's MIT license.
Please feel free to use it within the scope of the license.
2020年6月6日土曜日 13時20分46秒 UTC+9 加藤泰隆:
On 2020-06-08 01:49, Matt Harden wrote:
> I suspect your (possibly wrapped) error will be of type
> x509.UnknownAuthorityError, so you should be able to check for it with
> errors.As:
>
> var uaerr x509.UnknownAuthorityError
> if errors.As(err, ) {
> // handle as an unknown authority error
> }
Should we care?
Regular expressions are generally small.
So the asymptotic complexity is not particularly important.
But regular expressions are often used to search large amounts of input.
regexp gives us fast, guaranteed linear search times.
But we pay for this with slower compilation times.
40 matches
Mail list logo
