Re: [go-nuts] Why can't a regexp.Regexp be const

On Monday, February 13, 2023 at 7:08:35 PM UTC-5 David Finkel wrote: So, why can't the regexp be a constant? Only primitive types are allowed to be constant in go Oh, this is what I missed. For cases like this, I tend to create an unexported package variable

[go-nuts] liteide x38.2 released

Hi all, liteide x38.2 released! * update gotools&gocode to fix generic code lookup and code completion * refactoring the Go class view and outline to support generic views * update Delve debug plug-in, add disassembly view, and repair windows process exit * LiteIDE Source code https://github.

Re: [go-nuts] Why can't a regexp.Regexp be const

On Mon, Feb 13, 2023 at 6:48 PM Pat Farrell wrote: > This won't compile > > var ExtRegex = > regexp.MustCompile("(M|m)(p|P)(3|4))|((F|f)(L|l)(A|a)(C|c))$") > > with a > ./prog.go:10:18: > regexp.MustCompile("((M|m)(p|P)(3|4))|((F|f)(L|l)(A|a)(C|c))$") (value of > type *regexp.Regexp) is not const

Re: [go-nuts] Why can't a regexp.Regexp be const

This compiles just fine, but the regexp compilation fails: https://go.dev/play/p/QvC8CIITUU6 On Mon, Feb 13, 2023 at 4:49 PM Pat Farrell wrote: > This won't compile > > var ExtRegex = > regexp.MustCompile("(M|m)(p|P)(3|4))|((F|f)(L|l)(A|a)(C|c))$") > > with a > ./prog.go:10:18: > regexp.MustCom

[go-nuts] Why can't a regexp.Regexp be const

This won't compile var ExtRegex = regexp.MustCompile("(M|m)(p|P)(3|4))|((F|f)(L|l)(A|a)(C|c))$") with a ./prog.go:10:18: regexp.MustCompile("((M|m)(p|P)(3|4))|((F|f)(L|l)(A|a)(C|c))$") (value of type *regexp.Regexp) is not constant while const pat = "((M|m)(p|P)(3|4))|((F|f)(L|l)(A|a)(C|c))$

Re: [go-nuts] Re: Upgradable RLock

ConcurrentHashMap works that way in Java. Multiple write locks on portions of the table and CAS/atomic reading. > On Feb 13, 2023, at 1:45 PM, 'drc...@google.com' via golang-nuts > wrote: > > Could you use an applicative data structure? (e.g., a balanced binary tree > where you allocate a n

Re: [go-nuts] Suffix Array access

On Mon, Feb 13, 2023 at 6:52 AM Piotr Wyderski wrote: > > The "index/suffixarray" does a great job of providing users with a decent > implementation of the SAIS algorithm. But why does the package hide the ints > suffix array from its users and forces them to use the Lookup method? In my > appl

[go-nuts] Re: Automatically releasing memory resources allocated in cgo?

Hi jake could you give me an example how you achieve that. Because I did the same approach but still faults. However runtime.GC() works properly. But im not into using it. ``` bytes := C.GoBytes(unsafe.Pointer(reqProp.data), C.int(reqProp.size)) copiedDataSize := copy(reqPropDataGo, bytes) C.fr

Re: [go-nuts] Re: Upgradable RLock

Could you use an applicative data structure? (e.g., a balanced binary tree where you allocate a new spine for each insertion/deletion) That has log N overhead to read, log N storage allocated per write, but I think if you CAS the writes, the reads can proceed with a lightweight barrier. On Sun

Re: [go-nuts] Parsing time with timezones seem to fail

On Mon, Feb 13, 2023 at 7:55 AM 'Thomas Casteleyn' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Hi Sam, > > While I do acknowledge there might be some timezones that are ambiguous, > it certainly is not the case for CET and MST. IMHO those should be able to > be correctly parsed by tim

Re: [go-nuts] recover from a unexpected fault address

Hi everyone I also had the same problem and I am wrapping a DLL using CGO. What I found out is that when I do the operations (print-out for instance) inside the function that I wrapped there is no error. However when I pass the value inside wrapped function to my main logic it works for some amo

Re: [go-nuts] Parsing time with timezones seem to fail

Hi Sam, While I do acknowledge there might be some timezones that are ambiguous, it certainly is not the case for CET and MST. IMHO those should be able to be correctly parsed by time.Parse and time.ParseInLocation. If provided an ambiguous timezone to time.Parse, that should maybe return an er

Re: [go-nuts] Parsing time with timezones seem to fail

> On Feb 13, 2023, at 9:55 AM, Sven Rebhan wrote: > > I do not yet see where timezone abbreviations are ambiguous... Do you mean > there are multiple timezones with the same abbrev? This is certainly not the > case for MST... > What is the point in taking the timezone into account only if tha

Re: [go-nuts] Parsing time with timezones seem to fail

Hey Jason E. Aten, while I fully agree that using abbreviations is suboptimal, we have to deal with them in projects like influxdata/telegraf: The plugin-driven server agent for collecting & reporting metrics. (github.com) as users potentially query all

Re: [go-nuts] Parsing time with timezones seem to fail

On Friday, February 10, 2023 at 7:45:37 PM UTC+1 Ian Lance Taylor wrote: But it's not the case that the timezone abbreviation is never taken into account. As the comment says, the timezone abbreviation is taken into account if it is defined for the current location. For example, if the current l

[go-nuts] Suffix Array access

Hello, The "index/suffixarray" does a great job of providing users with a decent implementation of the SAIS algorithm. But why does the package hide the *ints *suffix array from its users and forces them to use the Lookup method? In my application, I build a suffix array to get, well, the suffi