[go-nuts] OOP AND GOLANG

2019-06-13 Thread Ali Hassan
https://koohinoorgo.blogspot.com/2019/06/object-oriented-paradigm-and-golang.html

-- 
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/388dd786-de8a-42aa-82d2-82cef2ed9b02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: cannot find package "text/template"

2019-06-13 Thread Wagner Riffel
Hi Tenney, clearly something went wrong with /src directory, you
reported your compiler to be go1.12, so it'd be a better idea to
download the go tree from go1.12 release branch instead of tip,
https://github.com/golang/go/tree/release-branch.go1.12

-- 
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/CAFEfeLwUfQXZX4wxEFPZO39w5XKhMYkveDYUNxx1teB_0G%2BhBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: cannot find package "text/template"

2019-06-13 Thread ThisEndUp
Not sure what caused the problem to pop up from one day to the next, but I 
repaired it by downloading *go-master.zip* from github 
 and extracting the directory *text* into 
*$GOROOT/src* . It now works both as a module and within* $GOPATH/src*.

On Thursday, June 13, 2019 at 1:05:15 AM UTC-4, ThisEndUp wrote:
>
> All of a sudden, when trying to build programs that used to work, as 
> recently as a couple of days ago, I'm getting
>
> main.go:6:2: cannot find package "text/template" in any of:
>  C:\Go\src\text\template (from $GOROOT)
>  D:\\Go\src\text\template (from $GOPATH)
>
>
> I was trying this in a module, but when the error popped up, I copied the 
> program into a directory in $GOPATH/src and got the same result.
>
> go version reports "go1.12 windows/amd64". I'm using a 64-bit Windows 10 
> Home machine.
>
> Is anyone else experiencing this? Is it temporary? Is there a work-around?
>
> 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/657accfe-64a8-4f70-906b-47e12ab24f73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: weak references

2019-06-13 Thread Robert Engels
But if nothing else has a reference to the anonymous listener that was added it will be immediately collected - and since it is created at the invocation point usually - it's a problem.here is the pseudo code:s = Server() // Server uses weak listener references...s.addListener(new Listener())the listener will be immediately collected...so try thiss = Server()new ChildService(s)withctor ChildService(Service s):   s.addListener(new BaseListener(){// some overridden method})The listener will also be immediately removedThe only way to prevent it is to use:ctor ChildService(Service s):   BaseListener sl = new BaseListener(){ with overridden method}; // sl must be named instance var   s.addListener(sl);That was the point I was trying to make - you can't use anonymous listener classes easily - which are often the bulk in many event driven designs.But YES, having weak references at some top-level makes things much easier, but the "explicit nature" of Go, means knowing the life-cycle and manually removing the observers. For simple callbacks this is usually not necessary.See https://softwareengineering.stackexchange.com/questions/238753/should-event-listeners-be-held-in-weak-references-Original Message-
From: Ricardo Alves 
Sent: Jun 13, 2019 2:46 PM
To: "tgptial...@gmail.com" , golang-nuts , Robert Engels 
Subject: Re: [go-nuts] Re: weak references









Thank you for your response again. In the case where anonymous classes are used, the anonymous class would add it self as listeners as you said, but what happens is that the service where the listener will be added will have a weak reference to the this listener.
 This means that the listener can be collected anytime without calling the RemoveListener. I worked with projects which all the arquitechture was event based, and sometimes even small things like a field of a class are listening to something to keep it's value
 updated. Sometimes you end up with lots of listeners. Regarding this last case, imagine you have a class A that inside has a class B. Object B is listening to something but it will not be collected until object A is collected. So, Object B never really knows
 when he needs to stop listening. In this case I will have to come up with methods to communicate between the two objects or instead I will have to turn object A as a listener to act as a gateway to object B. This is not productive at all in these cases, that's
 why I like to have WeakReferences.





Obter o Outlook para Android



From: Robert Engels 
Sent: Thursday, June 13, 2019 8:35:15 PM
To: Ricardo Alves; tgptial...@gmail.com; golang-nuts
Subject: Re: [go-nuts] Re: weak references
 



But using weak references for listeners is fraught with problems. The most common being that listeners are often anonymous inner classes (in something like Java) or at the point instantiated
 (closure), so if a direct reference is not held, the listener is would be immediately removed. Holding the reference to the inner instance is cumbersome - often requiring the developer to create an instance variable and assign to that. 


But you still need to manage the lifecycle of the object that was listening... so why not remove the listener then.



I don't think a finalizer helps in this case - since the service will have a hard reference to the listener, it will never be finalized... or GC'd, unless the removeListener is called anyway.


That being said, if the service is no longer referenced, all listeners will be GC'd - there will be no memory leak.


For example, Java Swing doesn't use weak listeners, but it does have weak references in some cases to the Window (i.e. Service), which contains references to all of the components (which are the listeners). When the Window goes out of scope, everything
 will be destroyed (cleaned up by GC).





-Original Message- 
From: Ricardo Alves 
Sent: Jun 13, 2019 2:12 PM 
To: "tgptial...@gmail.com" , golang-nuts , Robert Engels 
Subject: Re: [go-nuts] Re: weak references 




Yes, I understand. But if I have a productive language that doesn't need me to call it better. In C/C++ it's also easy, whoever calls new should call delete, but trust me, I've had my troubles finding memory leaks in other people's code. With a large enterprise
 application made in Go and working with other people and observer pattern, sooner or later I will have the same trouble finding memory this "memory leak".





Obter o Outlook para Android



From: Robert Engels 
Sent: Thursday, June 13, 2019 8:08:41 PM
To: tgptial...@gmail.com; golang-nuts
Subject: Re: [go-nuts] Re: weak references
 


That doesn't sound right. Whatever calls 'addListener', should be calling 'removeListener' - nothing needs to be detected.


-Original Message- 
From: tgptial...@gmail.com 
Sent: Jun 13, 2019 11:36 AM 
To: golang-nuts 
Subject: Re: [go-nuts] Re: weak references 

Yes, that is the "workaround". I mean, the lack of WeakReference makes Go (when implementing this pattern) at the same le

Re: [go-nuts] Re: weak references

2019-06-13 Thread Ricardo Alves
Thank you for your response again. In the case where anonymous classes are 
used, the anonymous class would add it self as listeners as you said, but what 
happens is that the service where the listener will be added will have a weak 
reference to the this listener. This means that the listener can be collected 
anytime without calling the RemoveListener. I worked with projects which all 
the arquitechture was event based, and sometimes even small things like a field 
of a class are listening to something to keep it's value updated. Sometimes you 
end up with lots of listeners. Regarding this last case, imagine you have a 
class A that inside has a class B. Object B is listening to something but it 
will not be collected until object A is collected. So, Object B never really 
knows when he needs to stop listening. In this case I will have to come up with 
methods to communicate between the two objects or instead I will have to turn 
object A as a listener to act as a gateway to object B. This is not productive 
at all in these cases, that's why I like to have WeakReferences.

Obter o Outlook para Android


From: Robert Engels 
Sent: Thursday, June 13, 2019 8:35:15 PM
To: Ricardo Alves; tgptial...@gmail.com; golang-nuts
Subject: Re: [go-nuts] Re: weak references

But using weak references for listeners is fraught with problems. The most 
common being that listeners are often anonymous inner classes (in something 
like Java) or at the point instantiated (closure), so if a direct reference is 
not held, the listener is would be immediately removed. Holding the reference 
to the inner instance is cumbersome - often requiring the developer to create 
an instance variable and assign to that.

But you still need to manage the lifecycle of the object that was listening... 
so why not remove the listener then.

I don't think a finalizer helps in this case - since the service will have a 
hard reference to the listener, it will never be finalized... or GC'd, unless 
the removeListener is called anyway.

That being said, if the service is no longer referenced, all listeners will be 
GC'd - there will be no memory leak.

For example, Java Swing doesn't use weak listeners, but it does have weak 
references in some cases to the Window (i.e. Service), which contains 
references to all of the components (which are the listeners). When the Window 
goes out of scope, everything will be destroyed (cleaned up by GC).


-Original Message-
From: Ricardo Alves
Sent: Jun 13, 2019 2:12 PM
To: "tgptial...@gmail.com" , golang-nuts , Robert Engels
Subject: Re: [go-nuts] Re: weak references

Yes, I understand. But if I have a productive language that doesn't need me to 
call it better. In C/C++ it's also easy, whoever calls new should call delete, 
but trust me, I've had my troubles finding memory leaks in other people's code. 
With a large enterprise application made in Go and working with other people 
and observer pattern, sooner or later I will have the same trouble finding 
memory this "memory leak".

Obter o Outlook para Android


From: Robert Engels 
Sent: Thursday, June 13, 2019 8:08:41 PM
To: tgptial...@gmail.com; golang-nuts
Subject: Re: [go-nuts] Re: weak references

That doesn't sound right. Whatever calls 'addListener', should be calling 
'removeListener' - nothing needs to be detected.

-Original Message-
From: tgptial...@gmail.com
Sent: Jun 13, 2019 11:36 AM
To: golang-nuts
Subject: Re: [go-nuts] Re: weak references

Yes, that is the "workaround". I mean, the lack of WeakReference makes Go (when 
implementing this pattern) at the same level as C/C++, since I have to know 
when I need to "delete" the resource in order to unsubscribe the event. I will 
have a look at SetFinalizer though, I haven't heard of it but I literally 
started programming Go yesterday x'D

quinta-feira, 13 de Junho de 2019 às 17:29:37 UTC+1, Robert Engels escreveu:
Isn't the "Go Way" for something like this to have the listeners explicitly 
unregister themselves ?

It does make certain event listener patterns more difficult, but I don't think 
it requires WeakRefs to implement.


-Original Message-
From: tgpti...@gmail.com
Sent: Jun 13, 2019 5:39 AM
To: golang-nuts
Subject: Re: [go-nuts] Re: weak references

I find WeakReferences when implementing observer pattern: A service generate 
events and signal listeners that the event was triggered. This usually requires 
the service to have a list to all of the listeners. Now, without weak refernece 
it means that any temporary listener will not be garbage collected and thus we 
will have memory grow without limits, since the listeners will not be collected 
as they are referenced by the service. When it comes to this, WeakReferences 
are mandatory and unfortunately Go doesn't support them :'(

terça-feira, 5 de Março de 2013 às 23:13:05 UTC, Steve McCoy escreveu:


On Tues

Re: [go-nuts] Re: weak references

2019-06-13 Thread Ricardo Alves
Yes, I understand. But if I have a productive language that doesn't need me to 
call it better. In C/C++ it's also easy, whoever calls new should call delete, 
but trust me, I've had my troubles finding memory leaks in other people's code. 
With a large enterprise application made in Go and working with other people 
and observer pattern, sooner or later I will have the same trouble finding 
memory this "memory leak".

Obter o Outlook para Android


From: Robert Engels 
Sent: Thursday, June 13, 2019 8:08:41 PM
To: tgptial...@gmail.com; golang-nuts
Subject: Re: [go-nuts] Re: weak references

That doesn't sound right. Whatever calls 'addListener', should be calling 
'removeListener' - nothing needs to be detected.

-Original Message-
From: tgptial...@gmail.com
Sent: Jun 13, 2019 11:36 AM
To: golang-nuts
Subject: Re: [go-nuts] Re: weak references

Yes, that is the "workaround". I mean, the lack of WeakReference makes Go (when 
implementing this pattern) at the same level as C/C++, since I have to know 
when I need to "delete" the resource in order to unsubscribe the event. I will 
have a look at SetFinalizer though, I haven't heard of it but I literally 
started programming Go yesterday x'D

quinta-feira, 13 de Junho de 2019 às 17:29:37 UTC+1, Robert Engels escreveu:
Isn't the "Go Way" for something like this to have the listeners explicitly 
unregister themselves ?

It does make certain event listener patterns more difficult, but I don't think 
it requires WeakRefs to implement.


-Original Message-
From: tgpti...@gmail.com
Sent: Jun 13, 2019 5:39 AM
To: golang-nuts
Subject: Re: [go-nuts] Re: weak references

I find WeakReferences when implementing observer pattern: A service generate 
events and signal listeners that the event was triggered. This usually requires 
the service to have a list to all of the listeners. Now, without weak refernece 
it means that any temporary listener will not be garbage collected and thus we 
will have memory grow without limits, since the listeners will not be collected 
as they are referenced by the service. When it comes to this, WeakReferences 
are mandatory and unfortunately Go doesn't support them :'(

terça-feira, 5 de Março de 2013 às 23:13:05 UTC, Steve McCoy escreveu:


On Tuesday, March 5, 2013 5:43:35 PM UTC-5, Jan Mercl wrote:
On Tue, Mar 5, 2013 at 11:24 PM, Dustin Sallings  wrote:
>   Strong reference:  "hands off, gc"
>   Weak reference:"0 this if no strong reference exists"
>   Soft refernce: "0 this if no strong reference exists and we're low
>   on RAM"

This is magic, even though feasible by the runtime. Go excels in
explicitness, even though that may mean more user coding. My feeling
is that those two approaches don't mix well, to put it mildly.

-j

It's not magic; it's not as though people won't know they have an instance of a 
weak reference on their hands.

Anyhow, I don't care if Go ever gets them, but there are other fun things that 
can be done with weak references that don't have anything to do with caches. I 
wrote a Java tool+package that keeps track of every object created while the 
program runs and asserts some preconditions whenever an object is accessed. Of 
course, memory would be extremely wasted if I kept them all in a map with 
strong references for the keys, so I instead used a WeakHashMap, allowing the 
garbage collector to clean things up in a typical fashion. Using explicit 
reference counting would've been painful for that.

--
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 golan...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/19d2f189-4dc6-406b-bd1e-45c1deeef054%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.




--
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/5f6c64a4-f45b-4547-9e14-6039b97f26cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



-- 
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 

Re: [go-nuts] Re: weak references

2019-06-13 Thread Robert Engels
But using weak references for listeners is fraught with problems. The most common being that listeners are often anonymous inner classes (in something like Java) or at the point instantiated (closure), so if a direct reference is not held, the listener is would be immediately removed. Holding the reference to the inner instance is cumbersome - often requiring the developer to create an instance variable and assign to that. But you still need to manage the lifecycle of the object that was listening... so why not remove the listener then.I don't think a finalizer helps in this case - since the service will have a hard reference to the listener, it will never be finalized... or GC'd, unless the removeListener is called anyway.That being said, if the service is no longer referenced, all listeners will be GC'd - there will be no memory leak.For example, Java Swing doesn't use weak listeners, but it does have weak references in some cases to the Window (i.e. Service), which contains references to all of the components (which are the listeners). When the Window goes out of scope, everything will be destroyed (cleaned up by GC).-Original Message-
From: Ricardo Alves 
Sent: Jun 13, 2019 2:12 PM
To: "tgptial...@gmail.com" , golang-nuts , Robert Engels 
Subject: Re: [go-nuts] Re: weak references









Yes, I understand. But if I have a productive language that doesn't need me to call it better. In C/C++ it's also easy, whoever calls new should call delete, but trust me, I've had my troubles finding memory leaks in other people's code. With a large enterprise
 application made in Go and working with other people and observer pattern, sooner or later I will have the same trouble finding memory this "memory leak".





Obter o Outlook para Android



From: Robert Engels 
Sent: Thursday, June 13, 2019 8:08:41 PM
To: tgptial...@gmail.com; golang-nuts
Subject: Re: [go-nuts] Re: weak references
 


That doesn't sound right. Whatever calls 'addListener', should be calling 'removeListener' - nothing needs to be detected.


-Original Message- 
From: tgptial...@gmail.com 
Sent: Jun 13, 2019 11:36 AM 
To: golang-nuts 
Subject: Re: [go-nuts] Re: weak references 

Yes, that is the "workaround". I mean, the lack of WeakReference makes Go (when implementing this pattern) at the same level as C/C++, since I have to know when I need to "delete" the resource in order to unsubscribe the event. I will have a
 look at SetFinalizer though, I haven't heard of it but I literally started programming Go yesterday x'D

quinta-feira, 13 de Junho de 2019 às 17:29:37 UTC+1, Robert Engels escreveu:


Isn't the "Go Way" for something like this to have the listeners explicitly unregister themselves ?


It does make certain event listener patterns more difficult, but I don't think it requires WeakRefs to implement.




-Original Message- 
From: tgpti...@gmail.com 
Sent: Jun 13, 2019 5:39 AM 
To: golang-nuts 
Subject: Re: [go-nuts] Re: weak references 

I find WeakReferences when implementing observer pattern: A service generate events and signal listeners that the event was triggered. This usually requires the service to have a list to all of the listeners. Now, without weak refernece it means
 that any temporary listener will not be garbage collected and thus we will have memory grow without limits, since the listeners will not be collected as they are referenced by the service. When it comes to this, WeakReferences are mandatory and unfortunately
 Go doesn't support them :'(

terça-feira, 5 de Março de 2013 às 23:13:05 UTC, Steve McCoy escreveu:



On Tuesday, March 5, 2013 5:43:35 PM UTC-5, Jan Mercl wrote:

On Tue, Mar 5, 2013 at 11:24 PM, Dustin Sallings  wrote:

>   Strong reference:  "hands off, gc" 
>   Weak reference:    "0 this if no strong reference exists" 
>   Soft refernce:     "0 this if no strong reference exists and we're low 
>                       on RAM" 

This is magic, even though feasible by the runtime. Go excels in 
explicitness, even though that may mean more user coding. My feeling 
is that those two approaches don't mix well, to put it mildly. 

-j 



It's not magic; it's not as though people won't know they have an instance of a weak reference on their hands.


Anyhow, I don't care if Go ever gets them, but there are other fun things that can be done with weak references that don't have anything to do with caches. I wrote a Java tool+package that keeps track of every object created while the program runs and
 asserts some preconditions whenever an object is accessed. Of course, memory would be extremely wasted if I kept them all in a map with strong references for the keys, so I instead used a WeakHashMap, allowing the garbage collector to clean things up in a
 typical fashion. Using explicit reference counting would've been painful for that.



-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this grou

Re: [go-nuts] Re: weak references

2019-06-13 Thread Robert Engels
That doesn't sound right. Whatever calls 'addListener', should be calling 'removeListener' - nothing needs to be detected.-Original Message-
From: tgptial...@gmail.com
Sent: Jun 13, 2019 11:36 AM
To: golang-nuts 
Subject: Re: [go-nuts] Re: weak references

Yes, that is the "workaround". I mean, the lack of WeakReference makes Go (when implementing this pattern) at the same level as C/C++, since I have to know when I need to "delete" the resource in order to unsubscribe the event. I will have a look at SetFinalizer though, I haven't heard of it but I literally started programming Go yesterday x'Dquinta-feira, 13 de Junho de 2019 às 17:29:37 UTC+1, Robert Engels escreveu:Isn't the "Go Way" for something like this to have the listeners explicitly unregister themselves ?It does make certain event listener patterns more difficult, but I don't think it requires WeakRefs to implement.-Original Message-
From: tgpti...@gmail.com
Sent: Jun 13, 2019 5:39 AM
To: golang-nuts 
Subject: Re: [go-nuts] Re: weak references

I find WeakReferences when implementing observer pattern: A service generate events and signal listeners that the event was triggered. This usually requires the service to have a list to all of the listeners. Now, without weak refernece it means that any temporary listener will not be garbage collected and thus we will have memory grow without limits, since the listeners will not be collected as they are referenced by the service. When it comes to this, WeakReferences are mandatory and unfortunately Go doesn't support them :'(terça-feira, 5 de Março de 2013 às 23:13:05 UTC, Steve McCoy escreveu:On Tuesday, March 5, 2013 5:43:35 PM UTC-5, Jan Mercl wrote:On Tue, Mar 5, 2013 at 11:24 PM, Dustin Sallings  wrote:
>   Strong reference:  "hands off, gc"
>   Weak reference:    "0 this if no strong reference exists"
>   Soft refernce:     "0 this if no strong reference exists and we're low
>                       on RAM"

This is magic, even though feasible by the runtime. Go excels in
explicitness, even though that may mean more user coding. My feeling
is that those two approaches don't mix well, to put it mildly.

-j
It's not magic; it's not as though people won't know they have an instance of a weak reference on their hands.Anyhow, I don't care if Go ever gets them, but there are other fun things that can be done with weak references that don't have anything to do with caches. I wrote a Java tool+package that keeps track of every object created while the program runs and asserts some preconditions whenever an object is accessed. Of course, memory would be extremely wasted if I kept them all in a map with strong references for the keys, so I instead used a WeakHashMap, allowing the garbage collector to clean things up in a typical fashion. Using explicit reference counting would've been painful for that.



-- 
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 golan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/19d2f189-4dc6-406b-bd1e-45c1deeef054%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.





-- 
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/5f6c64a4-f45b-4547-9e14-6039b97f26cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.




-- 
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/1937315646.8946.1560452921742%40wamui-hyena.atl.sa.earthlink.net.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: weak references

2019-06-13 Thread tgptialves
Yes, that is the "workaround". I mean, the lack of WeakReference makes Go 
(when implementing this pattern) at the same level as C/C++, since I have 
to know when I need to "delete" the resource in order to unsubscribe the 
event. I will have a look at SetFinalizer though, I haven't heard of it but 
I literally started programming Go yesterday x'D

quinta-feira, 13 de Junho de 2019 às 17:29:37 UTC+1, Robert Engels escreveu:
>
> Isn't the "Go Way" for something like this to have the listeners 
> explicitly unregister themselves ?
>
> It does make certain event listener patterns more difficult, but I don't 
> think it requires WeakRefs to implement.
>
>
> -Original Message- 
> From: tgpti...@gmail.com  
> Sent: Jun 13, 2019 5:39 AM 
> To: golang-nuts 
> Subject: Re: [go-nuts] Re: weak references 
>
> I find WeakReferences when implementing observer pattern: A service 
> generate events and signal listeners that the event was triggered. This 
> usually requires the service to have a list to all of the listeners. Now, 
> without weak refernece it means that any temporary listener will not be 
> garbage collected and thus we will have memory grow without limits, since 
> the listeners will not be collected as they are referenced by the service. 
> When it comes to this, WeakReferences are mandatory and unfortunately Go 
> doesn't support them :'(
>
> terça-feira, 5 de Março de 2013 às 23:13:05 UTC, Steve McCoy escreveu:
>>
>>
>>
>> On Tuesday, March 5, 2013 5:43:35 PM UTC-5, Jan Mercl wrote:
>>>
>>> On Tue, Mar 5, 2013 at 11:24 PM, Dustin Sallings  
>>> wrote: 
>>> >   Strong reference:  "hands off, gc" 
>>> >   Weak reference:"0 this if no strong reference exists" 
>>> >   Soft refernce: "0 this if no strong reference exists and we're 
>>> low 
>>> >   on RAM" 
>>>
>>> This is magic, even though feasible by the runtime. Go excels in 
>>> explicitness, even though that may mean more user coding. My feeling 
>>> is that those two approaches don't mix well, to put it mildly. 
>>>
>>> -j 
>>>
>>
>> It's not magic; it's not as though people won't know they have an 
>> instance of a weak reference on their hands.
>>
>> Anyhow, I don't care if Go ever gets them, but there are other fun things 
>> that can be done with weak references that don't have anything to do with 
>> caches. I wrote a Java tool+package that keeps track of every object 
>> created while the program runs and asserts some preconditions whenever an 
>> object is accessed. Of course, memory would be extremely wasted if I kept 
>> them all in a map with strong references for the keys, so I instead used a 
>> WeakHashMap, allowing the garbage collector to clean things up in a typical 
>> fashion. Using explicit reference counting would've been painful for that.
>>
> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/19d2f189-4dc6-406b-bd1e-45c1deeef054%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
>

-- 
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/5f6c64a4-f45b-4547-9e14-6039b97f26cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: weak references

2019-06-13 Thread Robert Engels
Isn't the "Go Way" for something like this to have the listeners explicitly unregister themselves ?It does make certain event listener patterns more difficult, but I don't think it requires WeakRefs to implement.-Original Message-
From: tgptial...@gmail.com
Sent: Jun 13, 2019 5:39 AM
To: golang-nuts 
Subject: Re: [go-nuts] Re: weak references

I find WeakReferences when implementing observer pattern: A service generate events and signal listeners that the event was triggered. This usually requires the service to have a list to all of the listeners. Now, without weak refernece it means that any temporary listener will not be garbage collected and thus we will have memory grow without limits, since the listeners will not be collected as they are referenced by the service. When it comes to this, WeakReferences are mandatory and unfortunately Go doesn't support them :'(terça-feira, 5 de Março de 2013 às 23:13:05 UTC, Steve McCoy escreveu:On Tuesday, March 5, 2013 5:43:35 PM UTC-5, Jan Mercl wrote:On Tue, Mar 5, 2013 at 11:24 PM, Dustin Sallings  wrote:
>   Strong reference:  "hands off, gc"
>   Weak reference:    "0 this if no strong reference exists"
>   Soft refernce:     "0 this if no strong reference exists and we're low
>                       on RAM"

This is magic, even though feasible by the runtime. Go excels in
explicitness, even though that may mean more user coding. My feeling
is that those two approaches don't mix well, to put it mildly.

-j
It's not magic; it's not as though people won't know they have an instance of a weak reference on their hands.Anyhow, I don't care if Go ever gets them, but there are other fun things that can be done with weak references that don't have anything to do with caches. I wrote a Java tool+package that keeps track of every object created while the program runs and asserts some preconditions whenever an object is accessed. Of course, memory would be extremely wasted if I kept them all in a map with strong references for the keys, so I instead used a WeakHashMap, allowing the garbage collector to clean things up in a typical fashion. Using explicit reference counting would've been painful for that.



-- 
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/19d2f189-4dc6-406b-bd1e-45c1deeef054%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.




-- 
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/1937383182.5582.1560443343706%40wamui-hyena.atl.sa.earthlink.net.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: weak references

2019-06-13 Thread Ian Lance Taylor
On Thu, Jun 13, 2019 at 8:52 AM  wrote:
>
> I find WeakReferences when implementing observer pattern: A service generate 
> events and signal listeners that the event was triggered. This usually 
> requires the service to have a list to all of the listeners. Now, without 
> weak refernece it means that any temporary listener will not be garbage 
> collected and thus we will have memory grow without limits, since the 
> listeners will not be collected as they are referenced by the service. When 
> it comes to this, WeakReferences are mandatory and unfortunately Go doesn't 
> support them :'(

Go has finalizers (https://golang.org/pkg/runtime/#SetFinalizer).  A
finalizer on a handle object can be used to implement what you
describe.

Ian


> terça-feira, 5 de Março de 2013 às 23:13:05 UTC, Steve McCoy escreveu:
>>
>>
>>
>> On Tuesday, March 5, 2013 5:43:35 PM UTC-5, Jan Mercl wrote:
>>>
>>> On Tue, Mar 5, 2013 at 11:24 PM, Dustin Sallings  wrote:
>>> >   Strong reference:  "hands off, gc"
>>> >   Weak reference:"0 this if no strong reference exists"
>>> >   Soft refernce: "0 this if no strong reference exists and we're low
>>> >   on RAM"
>>>
>>> This is magic, even though feasible by the runtime. Go excels in
>>> explicitness, even though that may mean more user coding. My feeling
>>> is that those two approaches don't mix well, to put it mildly.
>>>
>>> -j
>>
>>
>> It's not magic; it's not as though people won't know they have an instance 
>> of a weak reference on their hands.
>>
>> Anyhow, I don't care if Go ever gets them, but there are other fun things 
>> that can be done with weak references that don't have anything to do with 
>> caches. I wrote a Java tool+package that keeps track of every object created 
>> while the program runs and asserts some preconditions whenever an object is 
>> accessed. Of course, memory would be extremely wasted if I kept them all in 
>> a map with strong references for the keys, so I instead used a WeakHashMap, 
>> allowing the garbage collector to clean things up in a typical fashion. 
>> Using explicit reference counting would've been painful for that.
>
> --
> 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/19d2f189-4dc6-406b-bd1e-45c1deeef054%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CAOyqgcV5fmQYTY3MjjRjtKhS5Qxit_jok%2Bp%2Bxs%2BpSTQaEeGThw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: weak references

2019-06-13 Thread tgptialves
I find WeakReferences when implementing observer pattern: A service 
generate events and signal listeners that the event was triggered. This 
usually requires the service to have a list to all of the listeners. Now, 
without weak refernece it means that any temporary listener will not be 
garbage collected and thus we will have memory grow without limits, since 
the listeners will not be collected as they are referenced by the service. 
When it comes to this, WeakReferences are mandatory and unfortunately Go 
doesn't support them :'(

terça-feira, 5 de Março de 2013 às 23:13:05 UTC, Steve McCoy escreveu:
>
>
>
> On Tuesday, March 5, 2013 5:43:35 PM UTC-5, Jan Mercl wrote:
>>
>> On Tue, Mar 5, 2013 at 11:24 PM, Dustin Sallings  
>> wrote: 
>> >   Strong reference:  "hands off, gc" 
>> >   Weak reference:"0 this if no strong reference exists" 
>> >   Soft refernce: "0 this if no strong reference exists and we're 
>> low 
>> >   on RAM" 
>>
>> This is magic, even though feasible by the runtime. Go excels in 
>> explicitness, even though that may mean more user coding. My feeling 
>> is that those two approaches don't mix well, to put it mildly. 
>>
>> -j 
>>
>
> It's not magic; it's not as though people won't know they have an instance 
> of a weak reference on their hands.
>
> Anyhow, I don't care if Go ever gets them, but there are other fun things 
> that can be done with weak references that don't have anything to do with 
> caches. I wrote a Java tool+package that keeps track of every object 
> created while the program runs and asserts some preconditions whenever an 
> object is accessed. Of course, memory would be extremely wasted if I kept 
> them all in a map with strong references for the keys, so I instead used a 
> WeakHashMap, allowing the garbage collector to clean things up in a typical 
> fashion. Using explicit reference counting would've been painful for that.
>

-- 
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/19d2f189-4dc6-406b-bd1e-45c1deeef054%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Go will shine on huge web projects, but how about simple ones?

2019-06-13 Thread Jan Mercl
On Thu, Jun 13, 2019 at 4:47 PM Tong Sun  wrote:

If you want or need to discuss personal feelings, please do it off-list.

Thank you.

-- 
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-WwhgYb4yx0%2B6ayWYVMRzgTiGruYwZ4Ajacwj24eU%2B4pg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Go will shine on huge web projects, but how about simple ones?

2019-06-13 Thread Tong Sun
Hi Damian & all.

I think I need to set the record straight, as most of the technical
discussions has been taken place elsewhere, so I feel that I was treated
unfairly because of that. If you only see one site of the story, then it is
very easy to do that, I get it and understand it however.

So first of all, was I *"like Perl and think it performs good enough or
better for your use"*? No. As I have expressed again and again, I don't
think Go should lag so far behind of Perl. How bad? See for yourself:

[image: image.png]

There has some discrepancies and discussions on Apache Bench's statistics,
but my conclusion was that I trust the measured & reported response time
more than the statistical numbers.

This is the fundamental of the discussion. And as I have expressed again
and again, I want to improve my Go code, because I don't think Go being 8
times longer than (that *"ridiculously simple")* Perl on average, *"its
results are totally unsurprising"* and should be an accepted as an
*unchangeable
fact*.

So if you had thought I should be the one who apologies first, expressed on
or off line, please read on...

On Mon, Jun 10, 2019 at 7:50 PM Axel Wagner wrote:

>
> On Mon, Jun 10, 2019 at 11:28 PM Tong Sun wrote:
>
>> There is a second test well before your this post, which is a direct
>> translation of Perl code, that is now reading and writing directly to
>> a socket. Hanging on to the first test method and not referring to the
>> second test is not a very constructive way of discussion, let alone
>> using words like "ridiculously ...".
>>
>
> The updated test only changes *both* not to implement a web server. My
> point was, that this is not a realistic test case.e
>
>
>> Over 90% of the code are NOT doing regular expression matching.
>> Focusing *only* on regular expression, not >90% of the rest, is not
>> very convincing but miss the elephant in the room, at least seems to
>> me.
>
>
> The amount of SLOC is not important, however, but where time is spent.
> When adding some basic CPU profiling to the Go code, it spent ~10% of its
> time RE-matching, ~10% in various allocation-related activities, ~75%
> blocking in syscalls and the rest in other various network related runtime
> code. That's pretty much what I meant - in terms of actual CPU time used,
> RE-matching (and some allocation) is pretty much all that's happening. Now,
> I don't know how to profile Perl code and I'll admit that the netpoller
> etc. are part of the language and as such matter for the comparison. But
> the more direct the translation becomes, the less these code-paths will
> differ in performance and the more realistic your scenario gets (in terms
> of concurrency used and required), the more I'd expect Go to be favored by
> it.
>
> Please don't get personal and emotional over technical discussions,
>> and please refrain from using terms like "ridiculously simple" or
>> "reading in tea-leafs" in future discussions. It is inappropriately
>> condescending, thus not the correct attitude of communication.  It
>> does not align with the code of conduct of this mlist, and neither of
>> google's, I believe.
>>
>> If you have test results that contradict with mine, please show me
>> yours -- Let's talk the data, and not let the emotion get in the way
>> of technical discussion, and fact the fact, whatever it is.
>
>
There is a reason I'm saying above. Here I quote word for word from Axel
Wagner:

In any case, in this direct translation, I would've actually assumed perl
> to be faster - because literally all we do is a regexp-match and the perl
> RE-engine is famously optimized and the Go RE-engine is famously meh. That
> perl still ends up with significantly higher average response times is…
> honestly, a confirmation that it's not a very fast language.
>


> BTW, I also used a different tool to benchmark (github.com/rakyll/hey).
> AIUI, it uses multiple cores more efficiently. With that tool, the perl
> implementation gets absolutely demolished, with an average response time
> ~40x higher than the Go implementation on my machine.


I tried out his implementation eagerly (after thank him publicly of
course), but my result cannot replicate his findings/claims. So I asked him
a follow up question in the blog. He never replies to my inquiry, and now
is this, the only reply I get, from my simple *technical *question, "As you
can see, the test result from my machine is much different from yours.
Would you blog how you tested and your results please?"

I am not contradicting your data, I'm contradicting your conclusions.
>

And now he changed his tune. I never accused him of *"reading tea-leafs"*
for coming up the ungrounded conclusion as *"average response time ~40x
higher than Go"*, but he started to blame me for *"reading tea-leafs", *
unprovoked:


> *That's why I said "reading tea-leafs"*: You seem to look at the same
> data and come to conclusions that just don't connect for me. For example,
> your original post says that the mean resp

Re: [go-nuts] Re: Project Layout Question

2019-06-13 Thread Randall O'Reilly
In case it helps anyone else with this problem, there is an issue with the 
standard layout, and any project where all the code is in various 
subdirectories but there is no .go code at the top level: godoc.org won’t find 
it!

https://github.com/golang-standards/project-layout/issues/19
https://github.com/golang/gddo/issues/618

a good workaround is to create a doc.go file at the top level, which can be a 
handy place to put overall project docs I guess.

btw, a further advantage of moving all code (except doc.go) out of the top 
level is that it makes your github page look nicer, especially for being able 
to read the README file without having to scroll down too far.  I’ve adopted 
the strategy of just having a “stutter” in repeating the name of the overall 
repository as the main package subdirectory in the repository (e.g., gi/gi) — 
the std go import prefix is the same, but you get the advantage of moving all 
the code out of the top level.

- Randy

> On Jun 13, 2019, at 1:21 AM, Boris Mühmer  wrote:
> 
> Thanks for Your suggestions so far. I will have to do further tests to see 
> what suits our team best.
> 
> 
> Regards,
> Boris
> 
> Am Di., 11. Juni 2019 um 23:47 Uhr schrieb David Riley :
> On Jun 11, 2019, at 13:38, Ronny Bangsund  wrote:
> 
>> 
>> 
>> On Tuesday, June 11, 2019 at 2:47:44 PM UTC+2, Boris Mühmer wrote:
>> Is the project layout total rubbish?
>> 
>> I'm not sure - all I know is that it's different from how I prefer it, and 
>> "pkg" is the one thing I frequently see people dislike ;)
>> If you want to share packages, parent them to the project directory. 
>> Anything you feel is too niche you can hide inside internal/. Binaries in 
>> cmd/ makes it nice and tidy, but you can get away with top-level main 
>> packages if there's only one command and it's really simple (few source 
>> files to clutter it up).
> 
> This layout is, I feel, most useful for large projects which build many 
> binaries and have many packages (which is what we use it for). In that 
> context, it’s great.
> 
>> I might make a server cmd the same name as the project directory, and if 
>> possible, make it have CLI options to control itself (talk via local socket, 
>> gRPC, REST, whatever). Pleasing VS Code is mainly about configuring the 
>> build task(s). I like to have Release and Debug tasks, sometimes with tasks 
>> requiring other tasks (client-server projects, for instance).
> 
> One thing I’ve found it doesn’t work especially nicely with is things that 
> have files hardcoded to be in `pwd` (the common “task” utility is an example 
> of this), because then you get your nice, tidy top level cluttered with dreck 
> from your tools.
> 
> Also, `go test` runs its commands from the directory of the tested package, 
> not the current working directory, but that gripe is better hashed out 
> elsewhere.
> 
>> I haven't looked closely at the current state of modules to say anything 
>> about how it'll change up my standards, but it looks like we're expected to 
>> run module stuff out of the top-level directory. If not, aren't those parts 
>> better off breaking out into their own standalone projects? Running module 
>> setup in sub-directories with potentially different versions of external 
>> dependencies feels dirty.
> 
> It works fine with modules, at least assuming your repo directory is one 
> module! We haven’t tried it with sub-modules, mostly because that feels like 
> madness.
> 
> 
> - Dave
> 
> -- 
> 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/174A6172-8A4B-47F0-9C49-F54A7D1B17A8%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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/CALW2tjrL8bDJvqh3cZGMhK6GNoy7XNJhKFwmhFW9FJqH92KtqQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/E8204FB9-818A-4EDA-8301-90291057334C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Project Layout Question

2019-06-13 Thread Boris Mühmer
Thanks for Your suggestions so far. I will have to do further tests to see
what suits our team best.


Regards,
Boris

Am Di., 11. Juni 2019 um 23:47 Uhr schrieb David Riley :

> On Jun 11, 2019, at 13:38, Ronny Bangsund 
> wrote:
>
>
>
> On Tuesday, June 11, 2019 at 2:47:44 PM UTC+2, Boris Mühmer wrote:
>>
>> Is the project layout total rubbish?
>>
>
> I'm not sure - all I know is that it's different from how I prefer it, and
> "pkg" is the one thing I frequently see people dislike ;)
> If you want to share packages, parent them to the project directory.
> Anything you feel is too niche you can hide inside internal/. Binaries in
> cmd/ makes it nice and tidy, but you can get away with top-level main
> packages if there's only one command and it's really simple (few source
> files to clutter it up).
>
>
> This layout is, I feel, most useful for large projects which build many
> binaries and have many packages (which is what we use it for). In that
> context, it’s great.
>
> I might make a server cmd the same name as the project directory, and if
> possible, make it have CLI options to control itself (talk via local
> socket, gRPC, REST, whatever). Pleasing VS Code is mainly about configuring
> the build task(s). I like to have Release and Debug tasks, sometimes with
> tasks requiring other tasks (client-server projects, for instance).
>
>
> One thing I’ve found it doesn’t work especially nicely with is things that
> have files hardcoded to be in `pwd` (the common “task” utility is an
> example of this), because then you get your nice, tidy top level cluttered
> with dreck from your tools.
>
> Also, `go test` runs its commands from the directory of the tested
> package, not the current working directory, but that gripe is better hashed
> out elsewhere.
>
> I haven't looked closely at the current state of modules to say anything
> about how it'll change up my standards, but it looks like we're expected to
> run module stuff out of the top-level directory. If not, aren't those parts
> better off breaking out into their own standalone projects? Running module
> setup in sub-directories with potentially different versions of external
> dependencies feels dirty.
>
>
> It works fine with modules, at least assuming your repo directory is one
> module! We haven’t tried it with sub-modules, mostly because that feels
> like madness.
>
>
> - Dave
>
> --
> 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/174A6172-8A4B-47F0-9C49-F54A7D1B17A8%40gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CALW2tjrL8bDJvqh3cZGMhK6GNoy7XNJhKFwmhFW9FJqH92KtqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Go Language Survey

2019-06-13 Thread Michael Jones
The "src" subdirectory of go does balance, but building every ".go" file in
./go does lose the balance. I sensed your discomfort so I've changed my
plans a little to take as day to make a flexible command line tool out of
my go-test so that with it's verbose mode you'll know which files have
issues. I am here working on it at this very moment...

// Survey gathers and reports simple statistics about Go code by lexical
analysis
// Author: Michael Jones
//
// Survey files named in the file list of the "-f" argument and then those
listed in command line
// arguments. Files may be ".go" files or directories. If a named file is a
directory then all ".go"
// files in that directory are surveyed without considering subdirectories.
With the "-r" flag,
// named directories are processed recursively, eventually finding and
surveying each ".go" file in
// that hierarchy. The verbose argument requests details of individual file
processing and
// file system traversal, mentioning files with unbalanced "()[]{}." The
markdown argument prepares
// output for pretty display.

On Wed, Jun 12, 2019 at 10:27 PM Volker Dobler 
wrote:

>
> On Wednesday, 12 June 2019 23:48:36 UTC+2, Michael Jones wrote:
>>
>> Volker, did you see a few posts back that I did the run Roger asked
>> about, on RSC’s huge corpus? It is about 10x the size and its parens,
>> braces, and brackets match just fine, all *7476284* of them
>>
>
> If I remember the corpus was curated to be buildable, but on
> the other hand the Go 1.13 codebase in master should be
> buildable always too, anytime. Weird.
>
> V.
>
>
>>
>> On Wed, Jun 12, 2019 at 2:13 PM Michael Jones 
>> wrote:
>>
>>> They matched up until yesterday. When I updated at 2am California time
>>> it changed. It also had no "0o" octal literals up until the latest.
>>>
>>> I'd planned to joke how the race was on to be the first to check in a
>>> new octal literal in my mail, but  a few of those snuck in too.
>>>
>>> Yesterday:
>>> Count | Frequency | Detail
>>> ---:|---:|---
>>>   929548 | 19.7889% | ,
>>>   574886 | 12.2386% | .
>>>
>>> *  544819 | 11.5985% | (544819 | 11.5985% | )  *
>>>
>>> *  352547 | 7.5053% | {352547 | 7.5053% | }  *
>>>   288042 | 6.1321% | =
>>>   253563 | 5.3980% | :
>>>   155297 | 3.3061% | :=
>>>
>>> *138465 | 2.9478% | [138465 | 2.9478% | ]  *
>>>   78567 | 1.6726% | !=
>>>   72007 | 1.5329% | *
>>>
>>> On Wed, Jun 12, 2019 at 1:51 PM Volker Dobler 
>>> wrote:
>>>
 Cool work!

 What I found most astonishing on a first look: Not all
 parentheses ( are closed: 4 ) seem to be missing??
 For { 5 are unclosed while there is one more ] than [ ?

 Are you parsing testfiles with deliberate errors?

 V.

 On Wednesday, 12 June 2019 15:08:44 UTC+2, Michael Jones wrote:
>
> I've been working on a cascade of projects, each needing the next as a
> part, the most recent being rewriting text.Scanner. It was not a goal, but
> the existing scanner does not do what I need (recognize Go operators,
> number types, and more) and my shim code was nearly as big as the standard
> library scanner itself, so I just sat down an rewrote it cleanly.
>
> To test beyond hand-crafted edge cases it seemed good to try it
> against a large body of Go code. I chose the Go 1.13 code base, and 
> because
> the results are interesting on their own beyond my purpose of code 
> testing,
> I thought to share what I've noticed as a Github Gist on the subject of 
> the
> "Go Popularity Contest"—what are the most used types, most referenced
> packages, most and least popular operators, etc. The data are interesting,
> but I'll let it speak for itself. Find it here:
>
> https://gist.github.com/MichaelTJones/ca0fd339401ebbe79b9cbb5044afcfe2
>
> Michael
>
> P.S. Generated by go test. I just cut off the "passed" line and posted
> it. ;-)
>
> --
>
> *Michael T. jonesmichae...@gmail.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 golan...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/golang-nuts/1a0e2b4b-9276-4418-929c-51888cf2c93a%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
>>
>> *Michael T. jonesmichae...@gmail.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-