Re: [go-nuts] fs.Glob, fs.DirWalk, etc. does the pattern support complex regex

[James]

It makes the pattern a bit ugly, but you can definitely do it with
path.Match https://go.dev/play/p/zi6nh8Vj9LF

On Fri, 4 Nov 2022 at 09:20, pat2...@gmail.com  wrote:

> This has to be a FAQ, but my google foo for searching it is not clear
> The docs say: " The syntax of patterns is the same as in path.Match."
>
> The pattern seems to implement only fairly simple search expressions.
>
> I'd like to search for "./*.MP4", but of course to be platform independant
> I have to search for both upper and lower case "mp4" and "MP4"
> and maybe even allow "Mp4".
>
> This is trivial in most regex, including go's regex
>
> Can I do this with Glob or DirWalk? Or do I need to just
> get the file names and manually apply the regex?
>
> --
> 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/2d6cfad4-6a32-458a-89d1-f5546c80df90n%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/CAFuMYUx%2B0t9i1ZtEmR6ncr_JTU20RHpqr9-tSOmFB828RoHGbw%40mail.gmail.com.

[go-nuts] Re: about upstream?

[TheDiveO]

I've seen both usages depending on the writers' perspectives. For that 
reason I avoid the terms upstream and downstream in this context (services) 
like the plague and always ask people for clarification without using these 
two words. It's always fun to see this then sparking totally surprised 
reaction in others taking part in those conversations.

The OP is perfectly right to ask this usinthe term "up/downstream" in the 
context of services, as I've seen and heard this often times for REST-based 
APIs, both from native as well as non-native speakers.

On Wednesday, November 2, 2022 at 10:15:51 AM UTC+1 cuiw...@gmail.com wrote:

> there are two micro service writen in go, let's call them A and B. A will 
> call B. In this scene we will call B is the upstream of A. or A is the 
> upstream of B? which one is correct way?

-- 
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/80af4dc5-3c18-4f2a-a52b-026a93d0dac8n%40googlegroups.com.

[go-nuts] fs.Glob, fs.DirWalk, etc. does the pattern support complex regex

[pat2...@gmail.com]

This has to be a FAQ, but my google foo for searching it is not clear
The docs say: " The syntax of patterns is the same as in path.Match."

The pattern seems to implement only fairly simple search expressions.

I'd like to search for "./*.MP4", but of course to be platform independant
I have to search for both upper and lower case "mp4" and "MP4" 
and maybe even allow "Mp4".

This is trivial in most regex, including go's regex

Can I do this with Glob or DirWalk? Or do I need to just
get the file names and manually apply the regex?

-- 
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/2d6cfad4-6a32-458a-89d1-f5546c80df90n%40googlegroups.com.

Re: [go-nuts] There is a passage in book that is difficult to understand, can anyone help explain it?

[Robert Engels]

In past reviews it seems to me that non reentrant locks simply lead to course 
locks. Reentrent allow for proper function decomposition. Without them you see 
a lot of methods in Go like “doXWithLock” - and function decomposition is done 
via duplicative private methods. 

> On Nov 2, 2022, at 10:15 AM, Eli Lindsey  wrote:
> 
> 
> 
>> A’ would then be susceptible to the original “reasoning difficulties” 
>> without any locking. I think it shows that any complex function, especially 
>> those with recursion, have the same difficulties. 
>> 
>> Due to sequential consistency, A’ must be correct, since a non-reentrant 
>> lock forces a single thread of execution - making A’ and A equivalent. 
> 
> A holding the lock for the length of A’ communicates that A’ is inside the 
> critical section and must be careful to preserve invariants. A’ internally 
> locking a reentrant lock is ambiguous with respect to invariant expectations.
> 
> The practical implications are as important as the theoretical. There’s 
> inherent complexity in both - non reentrant locks tends to surface complexity 
> and make the behaviors/assumptions more obvious. 
> 
> Very, very occasionally reentrant locks are worth the ambiguity they 
> introduce, but primarily in callback heavy code (which Go doesn’t encourage 
> as much as other languages/APIs).
> 
> -eli
> 
 On Nov 2, 2022, at 7:49 AM, Eli Lindsey  wrote:
 
>>> Reentrant locks make any given critical section harder to understand 
>>> because you must also understand the calling pattern that led there to know 
>>> which invariants have been upheld and which may have been violated due to a 
>>> still-in-progress critical section higher up the call chain.
>>> 
>>> For example, Average.Value() in the example is making the assumption that 
>>> sum and count have been appropriately updated in lockstep. But if the lock 
>>> is reentrant, this may not be true. Average is small enough that it’s 
>>> trivial to check if this is a problem (ie. that Value is not called from 
>>> Add while sum/count mismatch); more complex code is not, especially when it 
>>> encounters future maintainers.
>>> 
>>> -eli
>>> 
 On Nov 2, 2022, at 7:43 AM, Robert Engels  wrote:
 
 I am curious though for an example that shows how a reentrant lock could 
 violate this?
 
>> On Nov 2, 2022, at 2:38 AM, peterGo  wrote:
>> 
> 
> Guanyun,
> 
> I tried to think of a simple example.
> 
> type Average struct {
> sum   float64
> count int64
> mxsync.Mutex
> }
> 
> https://go.dev/play/p/4SLCLuqG246
> 
> 1. An invariant represents a condition that does not change while the 
> process progresses - Niklaus Wirth.
> 
> 2. The additional invariant--Average = sum / count--is specific to the 
> data structure that the mutex mx guards.
> 
> 3. The shared variables sum and count are part of an invariant.
> 
> 4. The Add method temporarily violates the invariant by updating sum but 
> restores the invariant by updating count.
> 
> Peter
> 
>> On Wednesday, November 2, 2022 at 12:49:41 AM UTC-4 name@gmail.com 
>> wrote:
>> Hello,
>> 
>> This is a passage in book :
>> 
>> There is a good reason Go’s mutexes are not re-entrant.
>> 
>> The purpose of a mutex is to ensure that certain invariants of the 
>> shared variables are
>> maintained at critical points during program execution.
>> 
>> One of the invariants is "no goroutine is accessing the shared 
>> variables", but there may be additional invariants specific to the data 
>> structures that the mutex guards.
>> 
>> When a goroutine acquires a mutex lock, it may assume that the 
>> invariants hold. While it holds the lock, it may update the shared 
>> variables so that the invariants are temporarily violated.
>> 
>> However, when it releases the lock, it must guarantee that order has 
>> been restored
>> and the invariants hold once again.
>> 
>> Although a re-entrant mutex would ensure that no other goroutines are 
>> accessing the shared variables, it cannot protect the additional 
>> invariants of those variables.
>>  
>> 
>> 
>> This passage is difficult for me to understand:
>> 1. How to understand invariants "invariants"?
>> 2. What kind of scenarios does “additional invariants” refer to?
>> 3. What is the relationship between "shared variables" and "invariants"?
>> 4. What does "...guarantee that order has been restored..." mean?
>> 
>> Thanks,
>> Guanyun
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> 

Re: [go-nuts] godoc and generic code

[Hotei]

Thanks for the very helpful replies. < go doc -all pkg > should meets my 
needs for printed documentation.  I guess I will have to weigh the 
convenience of navigating which the godoc html version provides vs the 
inconvenience of "instantiating" the methods required by the types [T] I 
use in this project.  The pkgsite option doesn't seem workable in my case 
for the reasons eloquently described by one of the posters to issue 49212.  
At any rate, problem solved and thanks again to the golang-nuts group for 
the assistance!

On Thursday, November 3, 2022 at 9:32:09 AM UTC-4 Sebastien Binet wrote:

> On Thu Nov 3, 2022 at 14:02 CET, Jan Mercl wrote:
> > On Thu, Nov 3, 2022 at 12:49 PM Hotei  wrote:
> >
> > > I added some generic code to a project and godoc doesn't seem to like 
> that and stops working when it sees the generics. It's a 4 year old version 
> of godoc so that's perhaps not a surprise. What is a surprise is that godoc 
> isn't shipped with go any longer. Is there a version that handles generics 
> and if so where can I find it? A quick search of github came up empty but I 
> know things have been moved around so some hints would be much appreciated.
> >
> > I'm not in favor of the fact, but It's been deprecated a year ago:
> > https://github.com/golang/go/issues/49212
>
> one can use godocs.io for a maintained "godoc-like" binary:
>
> - https://godocs.io/go-hep.org/x/hep/sliceop
> - https://sr.ht/~sircmpwn/godocs.io/
>
> (otherwise, 'go doc' does support "generics")
>
> hth,
> -s
>

-- 
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/d5612970-6ad5-4e47-a45e-1e61f9cb648an%40googlegroups.com.

Re: [go-nuts] How does the go compiler treat initialized string variables?

[Konstantin Khomoutov]

On Tue, Nov 01, 2022 at 11:18:48AM -0700, Frank Jüdes wrote:

> I have to write a program that should verify the content of 
> configuration-servers. It will need a lot of pre-initialized data to verify 
> the actual content of a server, so it has to initialize many strings. What 
> i know from other C-style languages is, that code like 
> 
> var MyString *string = 'Hello World!'; 
> 
> Will result in having two identical copies of the string »Hello World!« in 
> the memory: The first one within the program-code itself and a second copy 
> somewhere in the heap-memory.
[...]
> Will there be two copies of the string »Hello World!" in the memory or just 
> one? As said, mMy code will contain a gazillion of pre-defined string 
> variables and having each string allocate two copies of itself in memory 
> would be bad for small systems. 

In addition to what others have said, please note that you can use for
analysis the usual tooling such as `objdump` and `nm` to peek at the generated
executable image file, as well as Go's native `go tool objdump` and
`go build -gcflags=-S` - with the latter producing the assembly 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/20221103154101.clxygi7iqsvcfegt%40carbon.

[go-nuts] go[runtime.rt0_go]: why should 104 be subtracted from g0 stack 64k?

[liiux...@gmail.com]

asm_amd64.s 


Please explain why 104 should be subtracted from g0 stack?
```go

TEXT runtime·rt0_go(SB),NOSPLIT|TOPFRAME,$0

   // copy arguments forward on an even stack

   MOVQDI, AX// argc

   MOVQSI, BX// argv

   SUBQ$(5*8), SP// 3args 2auto

   ANDQ$~15, SP

   MOVQAX, 24(SP)

   MOVQBX, 32(SP)



   // create istack out of the given (operating system) stack.

   // _cgo_init may update stackguard.

   MOVQ$runtime·g0(SB), DI

   LEAQ(-64*1024+104)(SP), BX

   MOVQBX, g_stackguard0(DI)

   MOVQBX, g_stackguard1(DI)

   MOVQBX, (g_stack+stack_lo)(DI)

   MOVQSP, (g_stack+stack_hi)(DI)
```

but asm_arm64.s is 64kb:
asm_arm64.s 


```go

   // create istack out of the given (operating system) stack.

   // _cgo_init may update stackguard.

   MOVD$runtime·g0(SB), g

   MOVDRSP, R7

   MOVD$(-64*1024)(R7), R0

   MOVDR0, g_stackguard0(g)

   MOVDR0, g_stackguard1(g)

   MOVDR0, (g_stack+stack_lo)(g)

   MOVDR7, (g_stack+stack_hi)(g)
```

-- 
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/6be1ed1e-d6f5-4942-9d4a-746ea27687a1n%40googlegroups.com.

Re: [go-nuts] Understanding some gotchas with linking slices together via indexing

[Konstantin Khomoutov]

On Tue, Nov 01, 2022 at 09:38:20PM -0700, Brian, son of Bob wrote:

> Can anyone explain these gotchas (demo )?  
> I've tried reading articles on this [one , 
[...]
> but they don't go into enough detail.


Because that's an intro ;-)

Try reading the next one in the series: https://go.dev/blog/slices

-- 
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/20221103144412.7rmrpggsk5gmneir%40carbon.

Re: [go-nuts] godoc and generic code

['Sebastien Binet' via golang-nuts]

On Thu Nov 3, 2022 at 14:02 CET, Jan Mercl wrote:
> On Thu, Nov 3, 2022 at 12:49 PM Hotei  wrote:
>
> > I added some generic code to a project and godoc doesn't seem to like that 
> > and stops working when it sees the generics.  It's a 4 year old version of 
> > godoc so that's perhaps not a surprise.  What is a surprise is that godoc 
> > isn't shipped with go any longer.  Is there a version that handles generics 
> > and if so where can I find it?  A quick search of github came up empty but 
> > I know things have been moved around so some hints would be much 
> > appreciated.
>
> I'm not in favor of the fact, but It's been deprecated a year ago:
> https://github.com/golang/go/issues/49212

one can use godocs.io for a maintained "godoc-like" binary:

- https://godocs.io/go-hep.org/x/hep/sliceop
- https://sr.ht/~sircmpwn/godocs.io/

(otherwise, 'go doc' does support "generics")

hth,
-s

-- 
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/CO2P4Z1G01II.LR5IDHBBGWME%40clrinfopc42.

Re: [go-nuts] godoc and generic code

[Jan Mercl]

On Thu, Nov 3, 2022 at 12:49 PM Hotei  wrote:

> I added some generic code to a project and godoc doesn't seem to like that 
> and stops working when it sees the generics.  It's a 4 year old version of 
> godoc so that's perhaps not a surprise.  What is a surprise is that godoc 
> isn't shipped with go any longer.  Is there a version that handles generics 
> and if so where can I find it?  A quick search of github came up empty but I 
> know things have been moved around so some hints would be much appreciated.

I'm not in favor of the fact, but It's been deprecated a year ago:
https://github.com/golang/go/issues/49212

-j

-- 
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-WA7DgrswXk_QrCBYX24au--MTEKbraQFALt-_YHwmC0A%40mail.gmail.com.

[go-nuts] godoc and generic code

[Hotei]

I added some generic code to a project and godoc doesn't seem to like that 
and stops working when it sees the generics.  It's a 4 year old version of 
godoc so that's perhaps not a surprise.  What is a surprise is that godoc 
isn't shipped with go any longer.  Is there a version that handles generics 
and if so where can I find it?  A quick search of github came up empty but 
I know things have been moved around so some hints would be much 
appreciated.

-- 
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/46a9941d-32e8-4ce1-a9d5-1c5b369668e4n%40googlegroups.com.

Re: [go-nuts] Occasional hard lockup w/ 100% CPU usage in go applications

[Konstantin Khomoutov]

On Mon, Oct 31, 2022 at 09:32:21AM -0700, Steven Sokol wrote:

> I tried sending SIGABRT, but the process did not respond - continued 
> running in the runaway state. I can kill it with SIGKILL but that doesn't 
> generate a core. Can you suggest a specific kill command that will? Thanks!

Sending SIGKILL is worthless because this signal is never delivered to the
target process: it's actually a request to the kernel to forcibly bring the
process down without any extra fuss.

To make the process drop the core, you should first make sure that this is
allowed for the process - usually by running

  ulimit -c unlimited

in the shell which starts the process (well, exactly how to make sure this
ulimit parameter is set for your process heavily depends on how it starts up)
and then sending a process any of the signals with "drop the core" default
disposition - see the signal(7) manual page - and not handled by the process
itself using the os/signal package).
On Linux, SIGQUIT is typically the signal you want.
And on a terminal (including virtual terminals such as Linux's virtual
consoles, XTerm, GNOME Terminal, screen, tmux etc) sending of this signal is
bound to Ctrl-\ by default. So, if you can run this program in the foreground
mode - that is, from a shell session attached to a terminal, you can do

  ulimit -c unlimited
  /path/to/the/process
  # idenfity lockup
  # press Ctrl-\ to have the process sent the SIGQUIT

-- 
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/20221103091256.7dbi4nbcn3yxcprr%40carbon.

Re: [go-nuts] about upstream?

[Konstantin Khomoutov]

On Wed, Nov 02, 2022 at 02:15:51AM -0700, xie cui wrote:

> there are two micro service writen in go, let's call them A and B. A will 
> call B. In this scene we will call B is the upstream of A. or A is the 
> upstream of B? which one is correct way?

I'm not a native speaker but I would say that using the term "upstream" is not
really fit for this particular case unless A really _streams_ data from B -
that is, opens a long-lived connection with the amount of data to be
transferred not known before making a request, and with the request usually
lasting until B goes offline or A loses interest in receiving the data.
A very good example of streaming is transferring some sort of "events" (for
instance, "realtime" data from a stock exchange, messages in a chat system
etc).

Otherwise, if A makes short-lived requests to B, I would just call B
"a server" and A - "a client". The both parties may be programmed in a way
that B also requests some data from A, and in this case they switch roles;
this is fine.

-- 
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/20221103090609.tpyftbjxyztoqv63%40carbon.