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

[Doug]

You can try my regexp2 engine that's based on the .NET engine: 
https://github.com/dlclark/regexp2

It supports atomic groups, has no dependencies, and doesn't need cgo. 
Unfortunately it doesn't support Possessive Quantifier syntax, but 
supposedly that may be serving as syntactic sugar for atomic groups and 
look-ahead assertions (which it does support).

Thanks,
Doug

On Thursday, April 1, 2021 at 2:54:35 PM UTC-5 bobj...@gmail.com wrote:

> I have a use of regular expressions where I need the "atomic" matching 
> features that I can get for several other languages, such as atomic 
> matching groups and "possessive" quantifiers. I'm willing to forego the 
> blazing performance of Go's standard library dfa matcher for this 
> particular case. I cannot write an equivalent regexp for Go's "regexp", and 
> the additional code I would have to write for equivalent functionality is 
> prohibitive.
>
> I did find such an implementation in the ether, importable as "
> github.com/h2so5/goback/regexp", It kind of works, but fails for my use 
> case.
>
> Is there any reason to believe that downloaded modules such as this are 
> well-tested and reliable?
>
> To pursue this problem,, I wrote small programs that perform the same 
> operation in isolation in some other languages that have regular expression 
> implementations the have the features I want, in particular
>Java, whose java.util.regex module provides the desired features
>Python, which has a module "regex" downloadable from the PyPI (Python 
> program index) that replaces the standard "re" module but has my desired 
> features
>Also Go, using the downloaded module I mentioned
>
> Only the Go version fails. Of course, it's the fault of the downloaded 
> library, not Go itself :)
>
> Anyone know of any other Go nfa implementations with the aforementioned 
> features?
>
> As much as I appreciate the advantages Go's dfa "regexp" module, there are 
> times when a more full-featured nfa implementation is useful. (And, a 
> well-written regexp for nfa can be pretty fast if the aforementioned 
> features are used to prevent excessive backtracking.)
>
> If anyone is interested in looking into the failure I experienced, I'd be 
> happy to send the little programs I wrote to investigate this.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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/42ac52d7-2a7c-4ad7-93ff-4a9be447f463n%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Doug]

The square bracket-based syntax feels much more readable to me, so it's a 
welcome change!

Based on my dev background I'm still partial to angle brackets and had an 
idea for disambiguating function calls. We could put the type information 
as the first data *inside* the parens, so a generic function invocation 
would become:
w( z)

This may not be the right forum to discuss the idea, but figured I'd throw 
it out there.

Thanks,
Doug

On Tuesday, July 14, 2020 at 4:56:01 PM UTC-5, gri wrote:
>
> We have received a variety of feedback on the generics draft design 
> <https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-contracts.md>
>  
> (blog <https://blog.golang.org/generics-next-step>). Thanks to everyone 
> who took the time to read it, play with generics code in the playground 
> <https://go2goplay.golang.org/>, file issues, and send us their thoughts.
>
> Not unexpectedly, many people raised concerns about the syntax, 
> specifically the choice of parentheses for type parameter declarations and 
> generic type and function instantiations.
>
> A typical computer keyboard provides four easily accessible pairs of 
> single-character symmetrical "brackets": parentheses ( and ), square 
> brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses 
> curly braces to delineate code blocks, composite literals, and some 
> composite types, making it virtually impossible to use them for generics 
> without severe syntactic problems. Angle brackets require unbounded parser 
> look-ahead or type information in certain situations (see the end of this 
> e-mail for an example). This leaves us with parentheses and square 
> brackets. Unadorned square brackets cause ambiguities in type declarations 
> of arrays and slices, and to a lesser extent when parsing index 
> expressions. Thus, early on in the design, we settled on parentheses as 
> they seemed to provide a Go-like feel and appeared to have the fewest 
> problems.
>
> As it turned out, to make parentheses work well and for 
> backward-compatibility, we had to introduce the type keyword in type 
> parameter lists. Eventually, we found additional parsing ambiguities in 
> parameter lists, composite literals, and embedded types which required more 
> parentheses to resolve them. Still, we decided to proceed with parentheses 
> in order to focus on the bigger design issues.
>
> The time has come to revisit this early decision. If square brackets alone 
> are used to declare type parameters, the array declaration
>
> type A [N]E
>
> cannot be distinguished from the generic type declaration
>
> type A[N] E
>
> But if we are comfortable with the extra type keyword, the ambiguity 
> disappears:
>
> type A[type N] E
>
> (When we originally dismissed square brackets, the type keyword was not 
> yet on the table.)
>
> Furthermore, the ambiguities that arise with parentheses appear not to 
> arise with square brackets. Here are some examples where extra parentheses 
> are not needed with square brackets:
>
> using () using []
>
> func f((T(int))  func f(T[int])
>
> struct{ (T(int)) }   struct{ T[int] }
>
> interface{ (T(int)) }interface{ T[int] }
>
> [](T(int)){} []T[int]{}
>
> To test this better understanding, and to get a feel for this alternative 
> notation, we will begin to make changes to our prototype implementation 
> such that it accepts either parentheses or square brackets (only one or the 
> other) in a generic Go package. Those changes will first appear as commits 
> to the dev.go2go branch 
> <https://go.googlesource.com/go/+/refs/heads/dev.go2go>, and eventually 
> in the playground <https://go2goplay.golang.org/>.
>
> If square brackets don't lead to unforeseen issues, we have another fully 
> explored notation to choose from, which will allow us to make a more 
> informed decision.
>
> - gri, iant
>
> PS: For ambiguities with angle brackets consider the assignment
>
> a, b = w < x, y > (z)
>
> Without type information, it is impossible to decide whether the 
> right-hand side of the assignment is a pair of expressions
>
> (w < x), (y > (z))
>
> or whether it is a generic function invocation that returns two result 
> values
>
> (w)(z)
>
> In Go, type information is not available at compile time. For instance, in 
> this case, any of the identifiers may be declared in another file that has 
> not even been parsed yet.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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/4725dd75-eef7-4794-ab04-44e9335a9d91o%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Doug Clark]

Thanks for the follow up Eric. Your experience with the concurrency 
primitives lines up with my experience porting projects from various 
languages into Go. The ability to maintain exceptionally low cognitive 
overhead when adding concurrency is pretty amazing.

On an unrelated note, if in the future you find yourself converting more 
projects and need the advanced regexp features you can use this regexp 
implementation: https://github.com/dlclark/regexp2
It's closer to what you're used to with Python (or C#, or Javascript, etc), 
but those advanced features do have a cost that shouldn't be entered into 
lightly.

- Doug


On Friday, February 21, 2020 at 11:08:53 AM UTC-6, Eric Raymond wrote:
>
> This is a belated addition to my notes on the Go translation of 
> reposurgeon. I'll be adding it to the revised version I post to golang-dev.
>
> One extremely positive thing I must say before closing.  Translation from 
> Python, which is a dreadful language to try to do concurrency in due to its 
> global interpreter lock, really brought home to me how unobtrusively 
> brilliant the Go implementation of Communicating Sequential Processes is.  
> The primitives are right and the integration with the rest of the language 
> is wonderfully seamless.  The Go port of reposurgeon got some very large 
> speedups at an incremental-complexity cost that I found to be astonishingly 
> low.  I am impressed both by the power of the CSP part of the design and 
> the extreme simplicity and non-fussiness of the interface it presents.  I 
> hope it will become a model for how concurrency is managed in future 
> languages.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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/0113e65f-c809-476b-a9b4-c0ab4830134f%40googlegroups.com.

[go-nuts] How do I test an func which depends on (pseudo)-random numbers, e.g. rand.Intn()?

[Doug Ireton]

I'm a new Gopher and I'm working through "Learn Go" by Nathan Youngman and 
trying to TDD the exercises to learn how to write testable Go code.

I have a function to return a random spaceline 
 from a string array.

In Go, how do I test functions which depend on random numbers? And, yes, I 
know that "math/rand" isn't truly random.

Is it as simple as setting a seed right before I run my test, e.g. 
rand.Seed(1)? Do I set rand.Seed(1) at the top of the _test.go file, or at 
the beginning of each unit test?

Also, am I seeding math.rand correctly in the Init() function? Will seeding 
it in the Init() function override any seeding I do in my tests?

My only other thought is to create an interface somehow to mock rand.Intn(), 
but this seems like overkill and I don't know enough about interfaces to 
know if this is inadvisable.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] regarding regex package

[Doug Clark]

There’s a pure Go (no cgo needed) regexp engine that supports lookahead and 
lookbehind here: https://github.com/dlclark/regexp2

However, and I say this as someone who maintains that regex library, use this 
type of regex with caution.  I would highly recommend changing your code to use 
the native, RE2-based engine if you can. Runaway regex’s on certain inputs is a 
risk with backtracking and is frequently a bad trade off in production.  

If you need compatibility because you don’t control the patterns being used or 
are porting code with lots of existing patterns (which is why the library 
exists) then regexp2 is nice to have in your back pocket. 

-Doug

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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/d89d0c25-90ab-49a5-9281-f8db334b029c%40googlegroups.com.

[go-nuts] Re: pure-go implementation of sqlite

[doug . manley]

As of right now, all I've been able to find is this (incomplete) read-only 
implementation: https://github.com/alicebob/sqlittle

On Tuesday, July 1, 2014 at 8:27:34 AM UTC-4, Sebastien Binet wrote:
>
> hi there, 
>
> is there (or is somebody working on) a pure-go implementation of sqlite ? 
> or at least a subset of it, to be able to read sqlite files ? 
>
> -s 
>
> PS: I know about the (by now) canonical implementations 
> (mattn/go-sqlite and others) but a completely go-based solution would 
> facilitate deployment and development across devs machines... 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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/c2fc5af2-9c42-46cd-9f13-ee69cd80cbab%40googlegroups.com.

[go-nuts] understanding garbage collection logging

[Doug Whitfield]

Hi folks,

I come from java-land, and am having some trouble figuring out gc logging 
in go. I have been asked to contribute to a memory leak issue in Minio, 
which is written in Go.

I found 
https://www.ardanlabs.com/blog/2019/05/garbage-collection-in-go-part2-gctraces.html
 
but I cannot tell if go is calling gc tracing what java calls logging, or 
if this is something different.

If it is the same, then does it work like in java where the JVM settings 
are separate from the app setting (and thus will work in any application)? 
This is my assumption, but since I was here I figured I would ask.

Basically, I want to see if gc activity is behaving as it should. 
Obviously, I have a lot to learn to be able to make anything out of the gc 
logging I am seeing since I won't be able to use my normal java tooling, 
but I figure before I spend a lot of time looking into this, I should find 
out from the experts if I am even going down the same path.

For the curious, I am suspicious of this: 
https://github.com/minio/minio/issues/19079

I think it should have been re-opened Feb 19. There isn't a merge or 
anything definitive that it should be closed...but that's a minio thing, 
not a go thing. Just some backstory for folks that see it has been "closed"

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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/74f829eb-04a1-45cd-a9a9-5524a4c6f2a1n%40googlegroups.com.