Re: [go-nuts] Why is it forbidden to add methods to an existing type?

[Sam Hughes]

My workaround like is something like `type String struct{string}. 
It can be reasonably treated as a string for most cases in which as string 
is needed, and it lets you convert back conveniently from any scope in 
which it's reasonable for your program to know the difference.
On Friday, March 18, 2022 at 12:46:34 AM UTC-5 Henry wrote:

> My own preference is to have a small number of methods and put the general 
> functionalities into functions. By putting the general functionalities into 
> functions, you allow code reuse. In object-oriented programming, you 
> normally attach as many functionalities as possible to their corresponding 
> types and achieve code reuse via inheritance. Since Go does not have 
> inheritance, you can achieve a similar effect with standalone functions. 
>
> On Friday, March 18, 2022 at 11:26:51 AM UTC+7 Ian Lance Taylor wrote:
>
>> On Thu, Mar 17, 2022 at 7:17 PM Zhaoxun Yan  wrote:
>> >
>> > I just came across this taboo in golang - new methods cannot be added 
>> to an existing type:
>>
>> Yes. If we didn't have this prohibition, then the set of interfaces
>> satisfied by a type would depend on which package was using the type.
>>
>> See the discussion at https://go.dev/issue/21401.
>>
>> 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/ac1c5c49-2000-42d4-8c2b-7ff6562c5486n%40googlegroups.com.

Re: [go-nuts] Is there any way to produce etcd watch chan be closed

[Sam Hughes]

 As written above, if that's the main thread, it is guaranteed to freeze in 
a deadlock every time. I don't see a goroutine kicked off, so I'm assuming 
you're trying to run that on the main thread, and you will be 100%, always, 
forever stuck on the `case wch := <- ach {` line.

Channel reads are blocking, if there's nothing in the buffer. You might 
have omitted it for brevity, but so I read that as if it's on the main 
thread for the program. You want goroutines to block while awaiting a 
receivable channel, typically. If you're receiving on the main thread, you 
need to add a default case that will not block.. This is a good explanation 
of the issue: https://golangbyexample.com/select-default-case-go/

On Friday, March 25, 2022 at 1:45:48 PM UTC-5 Ian Lance Taylor wrote:

> On Fri, Mar 25, 2022 at 11:41 AM 袁成若  wrote:
> >
> > I met a problem about etcd watch channel. seems that be closed, but i 
> can not reproduce it.
> >
> > like this:
> >
> > ```
> > for {
> > ach := etcdClientV3.Watch(context.Background(), "/test", 
> clientv3.WithPrefix())
> > for {
> > select {
> > case wch := <- ach {
> > fmt.Println("recv chan")
> > }
> > }
> > }
> > }
> > ```
> > the program print recv chan all the time. but I cannot reproduce it , Is 
> there any way to reproduce it
>
> It sounds like you are describing a problem with the
> https://github.com/etcd-io/etcd/ package. I suggest that you ask
> there.
>
> 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/6c0b5e4b-9959-45cb-a476-fca3a3d2d72dn%40googlegroups.com.

[go-nuts] Re: I have just published my iterator library iter_go : migrated for generics

[Sam Hughes]

Hey. I'm a rando internet jerk that just wrote you an issue!

I know I can't quite use your package, but I did point out an easy 
improvement I think you could make, that'd make stacking iterators into 
pipelines a little easier.

On Wednesday, March 23, 2022 at 5:14:10 AM UTC-5 Serge Hulne wrote:

> https://github.com/serge-hulne/go_iter
>
> It allows iterating over streams of arbitrary length (data channels).
>
>
>

-- 
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/6dfcfd65-06b0-442a-a872-dc198c00344an%40googlegroups.com.

Re: [go-nuts] How the bmap structure in runtime/map.go dynamically extended during compilation?

[Maksadbek]

Yes, this is exactly what I was searching for. Thank you!

On Friday, 25 March 2022 at 21:51:27 UTC+3 Ian Lance Taylor wrote:

> On Fri, Mar 25, 2022 at 11:42 AM Maksadbek  wrote:
> >
> > I've been reading the map internals in Go and came across into following 
> structure in source code:
> >
> > https://github.com/golang/go/blob/master/src/runtime/map.go#L150
> >
> > // A bucket for a Go map.
> > type bmap struct {
> > // tophash generally contains the top byte of the hash value
> > // for each key in this bucket. If tophash[0] < minTopHash,
> > // tophash[0] is a bucket evacuation state instead.
> > tophash [bucketCnt]uint8
> > // Followed by bucketCnt keys and then bucketCnt elems.
> > // NOTE: packing all the keys together and then all the elems together 
> makes the
> > // code a bit more complicated than alternating key/elem/key/elem/... 
> but it allows
> > // us to eliminate padding which would be needed for, e.g., 
> map[int64]int8.
> > // Followed by an overflow pointer.
> > }
> >
> > But if you scroll down the file and see the usage of this structure, 
> actually it has the following structure:
> >
> > // NOT REAL
> > type bmap struct {
> > topbits [8]uint8
> > keys [8]keytype
> > values [8]valuetype
> > pad uintptr
> > overflow uintptr
> > }
> >
> > I can't find out the place in the source code where this structure is 
> extended. In order to access those extra fields, authors do some pointer 
> arithmetics:
> >
> > https://github.com/golang/go/blob/master/src/runtime/map.go#L445
> > https://github.com/golang/go/blob/master/src/runtime/map.go#L501
> >
> > But in order to access those memory points, they needs to be allocated. 
> Where does the allocation happen ?
>
> The allocation occurs in calls to newobject in hmap.newoverflow and
> calls to newarray in makeBucketArray. But you are probably asking
> where the t.bucket struct is defined. That happens in the compiler in
> MapBucketType in cmd/compile/internal/reflectdata/reflect.go.
>
> 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/3eede932-1b06-4c10-93c8-220b63bc6924n%40googlegroups.com.

Re: [go-nuts] How the bmap structure in runtime/map.go dynamically extended during compilation?

[Ian Lance Taylor]

On Fri, Mar 25, 2022 at 11:42 AM Maksadbek  wrote:
>
> I've been reading the map internals in Go and came across into following 
> structure in source code:
>
> https://github.com/golang/go/blob/master/src/runtime/map.go#L150
>
> // A bucket for a Go map.
> type bmap struct {
> // tophash generally contains the top byte of the hash value
> // for each key in this bucket. If tophash[0] < minTopHash,
> // tophash[0] is a bucket evacuation state instead.
> tophash [bucketCnt]uint8
> // Followed by bucketCnt keys and then bucketCnt elems.
> // NOTE: packing all the keys together and then all the elems together makes 
> the
> // code a bit more complicated than alternating key/elem/key/elem/... but it 
> allows
> // us to eliminate padding which would be needed for, e.g., map[int64]int8.
> // Followed by an overflow pointer.
> }
>
> But if you scroll down the file and see the usage of this structure, actually 
> it has the following structure:
>
> // NOT REAL
> type bmap struct {
> topbits [8]uint8
> keys [8]keytype
> values [8]valuetype
> pad uintptr
> overflow uintptr
> }
>
> I can't find out the place in the source code where this structure is 
> extended. In order to access those extra fields, authors do some pointer 
> arithmetics:
>
> https://github.com/golang/go/blob/master/src/runtime/map.go#L445
> https://github.com/golang/go/blob/master/src/runtime/map.go#L501
>
> But in order to access those memory points, they needs to be allocated. Where 
> does the allocation happen ?

The allocation occurs in calls to newobject in hmap.newoverflow and
calls to newarray in makeBucketArray.  But you are probably asking
where the t.bucket struct is defined.  That happens in the compiler in
MapBucketType in cmd/compile/internal/reflectdata/reflect.go.

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/CAOyqgcVSZfqQBk0r4rX7aq_VQW9BwQQ-%3D89aSZxOV20myB_JyQ%40mail.gmail.com.

Re: [go-nuts] Is there any way to produce etcd watch chan be closed

[Ian Lance Taylor]

On Fri, Mar 25, 2022 at 11:41 AM 袁成若  wrote:
>
> I met a problem about etcd watch channel. seems that be closed,  but i can 
> not reproduce it.
>
> like this:
>
> ```
> for {
>  ach := etcdClientV3.Watch(context.Background(), "/test", 
> clientv3.WithPrefix())
>  for {
>   select {
>  case wch := <- ach {
>fmt.Println("recv chan")
>  }
>   }
>  }
> }
> ```
> the program print recv chan all the time. but I cannot reproduce  it , Is 
> there any way to reproduce it

It sounds like you are describing a problem with the
https://github.com/etcd-io/etcd/ package.  I suggest that you ask
there.

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/CAOyqgcXeHHdVBmYj7FYL1yHSDW%2BvgyjPnFLR1EBxE6Ag3sSo%3DQ%40mail.gmail.com.

[go-nuts] LotusDB - A fast kv database in Go

[Rose Duan]

I write a new kv storage named LotusDB, an alternative to Badger or bbolt 
in Go.

Github:https://github.com/flower-corp/lotusdb

Key features:

   - 
   
   Combine the advantages of LSM and B+ tree
   - 
   
   Fast read/write performance
   - 
   
   Much lower read and space amplification than typical LSM
   
It is simple, fast, and easy to understand and use.

Feel free to use LotusDB and give us any advice!

-- 
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/cd88fa31-17f6-4e59-95d1-951199705dd4n%40googlegroups.com.

[go-nuts] How the bmap structure in runtime/map.go dynamically extended during compilation?

[Maksadbek]

I've been reading the map internals in Go and came across into following 
structure in source code:

https://github.com/golang/go/blob/master/src/runtime/map.go#L150
// A bucket for a Go map.
type bmap struct {
// tophash generally contains the top byte of the hash value
// for each key in this bucket. If tophash[0] < minTopHash,
// tophash[0] is a bucket evacuation state instead.
tophash [bucketCnt]uint8
// Followed by bucketCnt keys and then bucketCnt elems.
// NOTE: packing all the keys together and then all the elems together 
makes the
// code a bit more complicated than alternating key/elem/key/elem/... but 
it allows
// us to eliminate padding which would be needed for, e.g., map[int64]int8.
// Followed by an overflow pointer.
}

But if you scroll down the file and see the usage of this structure, 
actually it has the following structure:
// NOT REAL
type bmap struct {
topbits [8]uint8
keys [8]keytype
values [8]valuetype
pad uintptr
overflow uintptr
} 

I can't find out the place in the source code where this structure is 
extended. In order to access those extra fields, authors do some pointer 
arithmetics:

   - https://github.com/golang/go/blob/master/src/runtime/map.go#L445
   - https://github.com/golang/go/blob/master/src/runtime/map.go#L501

But in order to access those memory points, they needs to be allocated. 
Where does the allocation happen ?

-- 
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/08373fea-4e2b-4672-bc29-79825a1d3177n%40googlegroups.com.

[go-nuts] Re: New edition of the Go Programming Language comming soon ?

[tmack8080]

Page XV:
"We assume that you have programmed in one or more languages, whether 
compiled like C, C++, and Java, or interpreted like Python, Ruby, and 
JavaScript, so we won't spell out everything as if for a total beginner."

On Monday, March 14, 2022 at 12:11:34 PM UTC-4 r...@rwx.gg wrote:

> As an educator and mentor I've had very negative feedback about that book 
> from dozens, from 12 to 50 years old. I preordered 25 when it came out and 
> regret ever having anyone start Go with it. One brilliant kid (who went on 
> to teach himself Assembly and C) nearly threw it at me. To date, I have 
> been unable to solidly recommend any book for beginners. This lack of 
> *good* beginner instruction remains one of the great flaws of Go in 
> general. I'm asked daily what to buy and have nothing to tell them. I 
> bought "Mastering Go" recently and it contains "generics" as proposed from 
> 2019 (I should have known since Packt published it). I know the authors are 
> capable, good people, but these books just do not hit the mark. It is one 
> of the *only* areas where I can confidently say Rust does a better job. 
> Their documentation team is amazing.
>
> On Sunday, February 13, 2022 at 6:22:47 AM UTC-5 christoph...@gmail.com 
> wrote:
>
>> Hello Go friends, 
>>
>> is there a new edition of the "Go Programming Language" book to be 
>> published soon ? 
>> It is quite old now and there have been a few changes to Go since then. 
>> Go.mod and generics. I was considering buying it, but if a new edition 
>> comes out in a few months, it would be wasted money. 
>>
>

-- 
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/f3e3b316-9fb8-4824-95f6-bb1f80c17e47n%40googlegroups.com.

Re: [go-nuts] Looked at using Go ... nil/SEGV really bothered me .. Go2 Proposal?

['Michael Toy' via golang-nuts]

The discussion is quite informative for me to read, thanks for responding. 
Go uses nil in a way which I don't quite yet grok, and so I had no idea if 
it was even a reasonable thing to wish for. Today I am writing in 
Typescript, and the way null is integrated into the type system now (after 
a while) feels natural and helpful to me.

Sam is correct, there is bug in my Go snippet in the post. For humor value 
only, I would like to point out that the imaginary Go compiler I was 
wishing for would have found that bug!

I think Brian gets to the heart of my question, which is "If I really 
understood Go, would I want something like this". I am hearing, "No, you 
would not"

I think if I were to have a long conversation with Axel about "what is it 
that makes programs robust and maintainable" we'd go round in circles a 
bit, as should happen any time you talk about something complex and 
important. I think I disagree with some statements, but even the 
disagreement is super helpful.

Thanks for the discussion!

-Michael Toy

On Thursday, March 24, 2022 at 12:22:44 AM UTC-10 Brian Candler wrote:

> The OP hasn't said specifically which language or feature they're 
> comparing with, but I wonder if they're asking for a pointer type which is 
> never allowed to be nil, enforced at compile time.  If so, a normal 
> pointer-which-may-be-nil would have to be represented as a Maybe[*T] or 
> union { *T | nil }. To use such a pointer value at runtime you'd have to 
> deconstruct it via a case statement or similar, with separate branches for 
> where the value is nil or not-nil. I am sure there have been proposals 
> along those lines floated here before.
>
> I don't think this would negatively affect code readability, because a 
> function which takes *T as an argument can be sure that the value passed in 
> can never be nil (the compiler would not allow a value of type Maybe[*T] to 
> be passed).  Conversely, a function which accepts Maybe[*T] as an argument 
> is explicitly saying that the value passed may legitimately be nil, and 
> hence it needs to check for this.
>
> I like this idea in principle, but in the context of Go it would mean that 
> *T does not have any valid zero value, so you would not be able to use it 
> in any variable or struct which is not explicitly initialized.  This would 
> definitely not be Go any more.
>
> type T 
> var t T  // ok
>
> var p1 Maybe[*T]  // ok
> var p2 *T =   // ok
> var p3 *T  // fails to compile (no zero value is available)
>
> type A struct {
> a Maybe[*T]
> }
> var q1 A // ok
>
> type B struct {
> b *T
> }
> var q2 B = B{b: } // ok
> var q3 B  // fails to compile (cannot create zero-valued instance of this 
> struct, because it includes a member which cannot have a zero value)
>  
> On Thursday, 24 March 2022 at 09:41:23 UTC axel.wa...@googlemail.com 
> wrote:
>
>> One thing to be clear: It is very different if we are talking about "emit 
>> a warning if a value is known to be nil" and "emit a warning unless a 
>> warning is known not to be nil". The former seems fine to me - it is IMO 
>> fine for this code to cause a vet-failure:
>>
>> var x *int
>> y := *x
>>
>> What I'm opposing is the original idea, for this code to cause a 
>> vet-failure:
>>
>> func (x *int) { *x }
>>
>> Importantly, whether or not a value is `nil` is *always* going to be a 
>> heuristic .
>> If we complain about "known to be nil", every finding will always be a 
>> bug. I don't think it's objectionable to find them statically.
>> If we complain about "not known not to be nil", a significant number of 
>> findings will be non-bugs, leading to changes as OP suggested. So, I'm 
>> assuming that's the situation we are talking about.
>>
>> On Thu, Mar 24, 2022 at 9:40 AM Sam Hughes  wrote:
>>
>>> @axel, it my feel counter-intuitive, but a possible runtime panic 
>>> converted to a compiler error is an increase in how robust the code is.
>>>
>>
>> Of course. But that's not what we are talking about. We are converting 
>> *some* runtime bugs into compiler errors (really, vet checks, we can't fail 
>> to compile because of backwards compatibility).
>> But most of them, where it's not clear from the code that a particular 
>> pointer is going to be nil, will get the treatment suggested by OP. Which 
>> ends up exploding the state-space of possible behaviors of a program, 
>> making it exponentially harder to know what it's doing.
>>
>> That's IMO the less intuitive thing. People tend to think "crashing code 
>> is unreliable". But really, crashing is quite a safe and easy to reason 
>> about behavior. But having to constantly program against any possible bug 
>> leads to unmaintainable, brittle, impossible to reason about code. If every 
>> index-expression, every pointer-dereference and every method call needs to 
>> be wrapped in a conditional, it becomes impossible to really understand 
>> where a failure is coming from and how a program 

[go-nuts] Is there any way to produce etcd watch chan be closed

[袁成若]

I met a problem about etcd watch channel. seems that be closed,  but i can 
not reproduce it.

like this: 

```
for {
 ach := etcdClientV3.Watch(context.Background(), "/test", 
clientv3.WithPrefix())
 for {
  select {
 case wch := <- ach {
   fmt.Println("recv chan")
 }
  }
 }
}
```
the program print recv chan all the time. but I cannot reproduce  it , Is 
there any way to reproduce 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d7c2a224-1124-4c77-8627-d34a08ef3035n%40googlegroups.com.

Re: [go-nuts] all goroutines are asleep - deadlock!

[Tong Sun]

Oh, thanks for the explain and pointing out `go vet` for future problems. 

Thanks!

On Friday, March 25, 2022 at 12:08:39 PM UTC-4 jake...@gmail.com wrote:

> The WaitGroup Documentation  says " A 
> WaitGroup must not be copied after first use.". 
>
> You are passing around and calling choppingActivity by value, so it is 
> being copied after Add() is called, and again each call to choppingAction() 
> and choppingSimulation(). 
>
> If you run "go vet" on your code it will alert you to the problems. 
>
> On Friday, March 25, 2022 at 10:27:02 AM UTC-4 sunto...@gmail.com wrote:
>
>> *Re-using the old thread for a new problem that I'm getting:*
>>
>> fatal error: all goroutines are asleep - deadlock!
>>
>> I rewrote my 
>> https://github.com/suntong/lang/blob/master/lang/Go/src/sys/butchers.go 
>> files from procedure based to OO based, as
>> https://github.com/suntong/lang/tree/master/lang/Go/src/sys/butchersOO
>>
>> The two programs behaves exactly the same, however my new "OO" approach 
>> ended with 
>>
>> fatal error: all goroutines are asleep - deadlock!
>> goroutine 1 [semacquire]:
>>
>> The only reason that I can think of is that,
>>
>> I changed my goroutine calling from function calling of
>> `go choppingProblem(i, knifeLeft, knifeRight)`
>> (
>> https://github.com/suntong/lang/blob/9057e5718e00d396d0fe9a232820bdb79a31df72/lang/Go/src/sys/butchers.go#L79-L82
>> )
>>
>> to method calling of
>> `go chopping.choppingAction(i, knifeLeft, knifeRight, )`
>> (
>> https://github.com/suntong/lang/blob/9057e5718e00d396d0fe9a232820bdb79a31df72/lang/Go/src/sys/butchersOO/main.go#L129-L132
>> )
>>
>> Might that be the reason? 
>> How to fix the problem?
>>
>> Thanks
>>
>>
>>

-- 
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/b3e5deba-8325-481e-9f5d-a115406da728n%40googlegroups.com.

Re: [go-nuts] all goroutines are asleep - deadlock!

[jake...@gmail.com]

The WaitGroup Documentation  says " A 
WaitGroup must not be copied after first use.". 

You are passing around and calling choppingActivity by value, so it is 
being copied after Add() is called, and again each call to choppingAction() 
and choppingSimulation(). 

If you run "go vet" on your code it will alert you to the problems. 

On Friday, March 25, 2022 at 10:27:02 AM UTC-4 sunto...@gmail.com wrote:

> *Re-using the old thread for a new problem that I'm getting:*
>
> fatal error: all goroutines are asleep - deadlock!
>
> I rewrote my 
> https://github.com/suntong/lang/blob/master/lang/Go/src/sys/butchers.go 
> files from procedure based to OO based, as
> https://github.com/suntong/lang/tree/master/lang/Go/src/sys/butchersOO
>
> The two programs behaves exactly the same, however my new "OO" approach 
> ended with 
>
> fatal error: all goroutines are asleep - deadlock!
> goroutine 1 [semacquire]:
>
> The only reason that I can think of is that,
>
> I changed my goroutine calling from function calling of
> `go choppingProblem(i, knifeLeft, knifeRight)`
> (
> https://github.com/suntong/lang/blob/9057e5718e00d396d0fe9a232820bdb79a31df72/lang/Go/src/sys/butchers.go#L79-L82
> )
>
> to method calling of
> `go chopping.choppingAction(i, knifeLeft, knifeRight, )`
> (
> https://github.com/suntong/lang/blob/9057e5718e00d396d0fe9a232820bdb79a31df72/lang/Go/src/sys/butchersOO/main.go#L129-L132
> )
>
> Might that be the reason? 
> How to fix the problem?
>
> Thanks
>
>
>

-- 
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/1e3d22ca-f4c0-4063-9fdf-6d6bdbcf3202n%40googlegroups.com.

Re: [go-nuts] all goroutines are asleep - deadlock!

[Tong Sun]

*Re-using the old thread for a new problem that I'm getting:*

fatal error: all goroutines are asleep - deadlock!

I rewrote my 
https://github.com/suntong/lang/blob/master/lang/Go/src/sys/butchers.go 
files from procedure based to OO based, as
https://github.com/suntong/lang/tree/master/lang/Go/src/sys/butchersOO

The two programs behaves exactly the same, however my new "OO" approach 
ended with 

fatal error: all goroutines are asleep - deadlock!
goroutine 1 [semacquire]:

The only reason that I can think of is that,

I changed my goroutine calling from function calling of
`go choppingProblem(i, knifeLeft, knifeRight)`
(https://github.com/suntong/lang/blob/9057e5718e00d396d0fe9a232820bdb79a31df72/lang/Go/src/sys/butchers.go#L79-L82)

to method calling of
`go chopping.choppingAction(i, knifeLeft, knifeRight, )`
(https://github.com/suntong/lang/blob/9057e5718e00d396d0fe9a232820bdb79a31df72/lang/Go/src/sys/butchersOO/main.go#L129-L132)

Might that be the reason? 
How to fix the problem?

Thanks


-- 
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/beee5c10-9c8d-4c25-b418-ebe77349938fn%40googlegroups.com.

Re: [go-nuts] Mathematical operations - the generics way

[Paul Hankin]

I don't know if it's important to you, but your Max[float64] isn't 
compatible with math.Max in the standard library.
For example, Max[float64](NaN, 1) returns 1 rather than NaN.

On Tuesday, 22 March 2022 at 16:58:40 UTC+1 esi...@gmail.com wrote:

> I found a working version meantime.
>
> // Max returns the bigger value between two numbers.
> func Max[T constraints.Ordered](x, y T) T {
> if x > y {
> return x
> }
> return y
> }
>
> // Abs returns the absolut value of x.
> func Abs[T constraints.Signed | constraints.Float](x T) T {
> if x < 0 {
> return -x
> }
> return x
> }
>
> On Saturday, March 19, 2022 at 12:22:39 PM UTC+2 Gergely Födémesi wrote:
>
>> some details: https://github.com/golang/go/issues/48918 
>>
>> On 3/18/22, Endre Simo  wrote: 
>> > Now that generics are officially supported, I was checking in the Go 
>> source 
>> > 
>> > if there are some generic implementation of utility methods like Abs, 
>> Min, 
>> > Max etc, but I couldn't find it other than this 
>> > proposal https://github.com/golang/go/discussions/48287. 
>> > 
>> > Anyone knows if something related has been adopted and implemented in 
>> Go 
>> > 1.18? 
>> > 
>> > -- 
>> > 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/e930b89a-0ba6-46f5-b3ec-7aeb26d8acf9n%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/5a96dccf-2e52-4172-bd2f-e1bf0e8757b4n%40googlegroups.com.