Re: [go-nuts] Does reducing capacity of a slice return memory?

[Michael Jones]

Yes! That always works at the application level. Write an “inspector” that
examines things, duplicating and copying the live parts.

I do that in several of my long running math apps, where my pool of
big.Ints end up with 50-100 thousand digit allocations in a big because of
one giant multiply...I examine them as I recycle and manage this. Makes a
big difference.

But doing it when you know the situation is easy. It’s having the compiler
“just know” that is so challenging. (Unless you box everything like
Java...and that’s an expensive path)

On Fri, Jul 19, 2019 at 12:43 PM Andrey Tcherepanov <
xnow4fippy...@sneakemail.com> wrote:

> My suggestion was not to make "the kitchen" work harder by marking parts
> of the hamburger to be good for the consumption, no. My suggestion was to
> recycle bitten hamburger out and put just the bitten piece aside in a doggy
> bag, sorry.
>
> A.
>
> On Friday, July 19, 2019 at 1:08:51 PM UTC-6, Michael Jones wrote:
>>
>> There is a difference in the meanings of terms in this discussion, maybe
>> that’s confusing to some. (That is, Ian went right to the heart of the
>> matter but maybe a simpler fact needs to be made plain to others.)
>>
>> When you think of the memory used by a slice and of maybe using less of
>> it and “returning” the rest, like putting uneaten food away for tomorrow,
>> you’re making several big demands.
>>
>> You demand severabity, that half a TV set is a reasonable thing to
>> discuss, like half a pie. In fact that backing array was created by the
>> allocator as “256 bytes you can use, with other info you don’t know about
>> somewhere.” To chop off half and “give it back” is not part of the
>> contract. The contract is: use it until you’re done with it. (The whole TV,
>> because of wires and glass bits).
>>
>> One alternative is to make 256 allocations of the small parts, then
>> allocate an array as pointers to each little part. Then you can reshape the
>> array and free the extra parts. This freedom pays a tax in many ways, and
>> always pays it in the normal case.
>>
>> But in the efficient single group allocation style (Go, C, C++, ...) the
>> desire to return part of a monolithic allocation is a major burden. Ian
>> went right to the elements of that burden. But since the follow ups still
>> wanted the burden I thought maybe a reminder of why it is hard would help.
>>
>> On Fri, Jul 19, 2019 at 7:36 AM Ian Lance Taylor 
>> wrote:
>>
>>> I'm not sure what to say.  If someone wants to write up and work on a
>>> detailed implementation proposal, that is fine.  Go for it.  As I said
>>> earlier, I think it would be hard.  I'll add that I don't think that
>>> the difficulty would pay off in terms of the amount of real code that
>>> it would help.  There is a lot of other hard work that could be done
>>> in the compiler that would, I think, help many more programs.
>>>
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVvDz1kRzpoKNtw5MDH%2BrFpsW6fLSqrT%3DS83JGhM_Y-%2BA%40mail.gmail.com
>>> .
>>>
>> --
>>
>> *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-nuts/d371646c-1f7c-4df1-8077-14e40c25ae04%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/d371646c-1f7c-4df1-8077-14e40c25ae04%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQy%3DRtfLzFqUnnzng-dba2mm0kx0o7hc2pTUDT_RTb1UpA%40mail.gmail.com.

Re: [go-nuts] Re: About the Google logo on the new Go website

[Michael Jones]

You sure seem eager to post negative things from your gmail account. Do you
troll only, or is there anything of substance?

If there is something about the Go language or computer programming that
you wish to share it would be welcome: perhaps open source software you’ve
written and want developers to know about, questions for the experts here,
or maybe job positions you have for developers in your company. This is the
place for such matters.

On Fri, Jul 19, 2019 at 8:21 AM Space A.  wrote:

> Unless there are financial reports published for passed years, my personal
> opinion is that accurate term could be "use of official position or office
> for personal gain". Quite common thing to such a big companies, tbh.
> Oh, and don't forget "If you are independent artist tried to make
> something for community - your problem, sincerely yours, Google"
>
>
> On Friday, July 19, 2019 at 8:35:53 AM UTC+3, andrey mirtchovski wrote:
>>
>> what you're doing has a term: character assassination.
>>
>> please take it elsewhere. there are plenty of forums to air your
>> grievances.
>>
>> On Thu, Jul 18, 2019 at 11:31 PM Space A.  wrote:
>> >
>> > Another funny thing and I'm glad that you mentioned, is that "Woman Who
>> Go" and other known "non-google" initiatives, as you said, were founded or
>> co-founded by "developer advocate" Ashley McNamara. I don't know what kind
>> of contract or collaboration, or relations she had with Google or Google
>> employees, but she was quite "official" I would say, on all these
>> conferences. Now, she works for Microsoft. She also created and promoted
>> own printshop with Go-related merch with help of official Go community
>> channels: conferences, social networks, slack, etc. So, the interesting
>> thing is that in the post in Go blog it was claimed that 100% of money from
>> new "official" store will go to so-called non-profit org "GoBridge":
>> https://github.com/gobridge/about-us
>> > which is also seems to be founded or co-founded by her, along with
>> other existing Google and (perhaps some of the) ex-Google employees:
>> https://github.com/gobridge/about-us#leadership-team
>> > Ashley McNamara name there on the first place.
>> >
>> > You can Google a lot with her name and "GoBridge", "Woman Who Go" and
>> other keywords. For example here is her Patreon where she collects
>> donations for Go-related artworks, and also mentions that "Woman Who Go"
>> and "GoBridge" are being merged:
>> https://www.patreon.com/posts/women-who-go-24864094
>> >
>> > So all money will still go to that same project but now with promotion
>> made on very top level, in official Go Programming Language blog. Even if
>> that org is true and registered "non-profit" org, I suspect it still pays
>> salaries and give contracts to sub-contractors. I tried to find any
>> financial reports and proofs or evidence of real actions taken, but all I
>> found is some very general stuff. At least it very suspicious. I don't
>> believe that Google can't fund such a non-profit initiative without
>> affecting true artists.
>> >
>> > And apparently, very unlikely, that you paid a cent to any independent
>> artist over that years.
>> >
>> >
>> >
>> > On Friday, July 19, 2019 at 6:13:26 AM UTC+3, andrey mirtchovski wrote:
>> >>
>> >> really? throughout the years (and I've been here since the beginning)
>> >> i have spent infinitely more on non-google "go" merch than on google
>> >> go merch: stickers, t-shirts, campaigns supporting women who code,
>> >> etc, etc.
>> >>
>> >> come on. get off your high horse.
>> >
>> > --
>> > 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/39fb6e76-6acb-4470-b249-bcb202580d45%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/c7e6bcea-659a-4d3e-8753-07757b797b62%40googlegroups.com
> 
> .
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQypkG%2BtHPiJFgZYmGHjiEAhgOtTPGuPHi8Nntt1TFi9wQ%40mail.gmail.com.

Re: [go-nuts] Does reducing capacity of a slice return memory?

[Michael Jones]

There is a difference in the meanings of terms in this discussion, maybe
that’s confusing to some. (That is, Ian went right to the heart of the
matter but maybe a simpler fact needs to be made plain to others.)

When you think of the memory used by a slice and of maybe using less of it
and “returning” the rest, like putting uneaten food away for tomorrow,
you’re making several big demands.

You demand severabity, that half a TV set is a reasonable thing to discuss,
like half a pie. In fact that backing array was created by the allocator as
“256 bytes you can use, with other info you don’t know about somewhere.” To
chop off half and “give it back” is not part of the contract. The contract
is: use it until you’re done with it. (The whole TV, because of wires and
glass bits).

One alternative is to make 256 allocations of the small parts, then
allocate an array as pointers to each little part. Then you can reshape the
array and free the extra parts. This freedom pays a tax in many ways, and
always pays it in the normal case.

But in the efficient single group allocation style (Go, C, C++, ...) the
desire to return part of a monolithic allocation is a major burden. Ian
went right to the elements of that burden. But since the follow ups still
wanted the burden I thought maybe a reminder of why it is hard would help.

On Fri, Jul 19, 2019 at 7:36 AM Ian Lance Taylor  wrote:

> I'm not sure what to say.  If someone wants to write up and work on a
> detailed implementation proposal, that is fine.  Go for it.  As I said
> earlier, I think it would be hard.  I'll add that I don't think that
> the difficulty would pay off in terms of the amount of real code that
> it would help.  There is a lot of other hard work that could be done
> in the compiler that would, I think, help many more programs.
>
> 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/CAOyqgcVvDz1kRzpoKNtw5MDH%2BrFpsW6fLSqrT%3DS83JGhM_Y-%2BA%40mail.gmail.com
> .
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQxJOkrYvT7yjmEFGr%2BT_xFiairSgYmUp%3Drx2EZTqVPLWw%40mail.gmail.com.

Re: [go-nuts] Need help to learn go lang

[Michael Jones]

Veeresh,

Welcome to the world of programming. It is a beautiful world and has been
my joy for fifty years. It is magical to have a robot friend to multiply
your abilities by millions of times.

Learning about programming at the very start is a small group of tasks:
learning a few details like “where do I type” and “how do I start it” and
understanding the nature of the magic; unlike the Sourcer’s Apprentice in
Fantasia you can’t just point, the robot is faithful but not so smart. You
may be surprised at the need to give very simple commands.

Many people learn best by example. The Golang Tour that Brian mentioned has
this virtue. Not only can you see what’s happening, but you can type
changes right there to try it your way. Give that a quick look.

I’ve taught students/classes but long ago. I do not know what’s the best
“new person learning to program a computer” guide out there now, or if any
of those use Go as their environment. I learned alone in the 4th grade (age
ten) using grim tools for a child (keypunch, FORTRAN, big computer centers)
— so whatever you do will be better!

It is not hard, is fun, and offers many rewards.

Good luck,
Michael

On Fri, Jul 19, 2019 at 7:02 AM Brian Hatfield  wrote:

> Veeresh,
>
> Out of the links I provided, The Little Go Book is the closest to a "new
> programmer" book, but I don't think it really meets that need. Hopefully
> others on this list are aware of a good resource for "new to programming
> and want to try Go" and can link you to one!
>
> Good luck,
> Brian
>
> On Fri, Jul 19, 2019 at 9:50 AM Veeresh Reddy 
> wrote:
>
>> Thanks much . To be honest I have not wrote any code so far but I wanted
>> to start of with Go Lang . Pleade suggest me some accordingly .
>>
>> On Fri, 19 Jul 2019, 7:15 pm Brian Hatfield, 
>> wrote:
>>
>>> Hi Veereshreddy!
>>>
>>> Welcome to Go!
>>>
>>> Here's a collection of links that I put together for some of my
>>> teammates who are new to Go:
>>>
>>> Basics / Introduction to Go
>>>
>>> GoByExample  is a great resource if you've
>>> got experience with 2+ programming languages already. It quickly showcases
>>> langauge syntax and features, but is relatively spartan in its presentation.
>>>
>>> The Little Go Book  is
>>> a more thorough book-style approach to Go for folks with less diverse
>>> programming language experience, or for folks who find GoByExample to be
>>> too spartan.
>>>
>>> The Golang Tour  is the official
>>> interactive introduction to Go. It leverages the Go playground, which lets
>>> you run Go right in your web browser.
>>>
>>> Intermediate
>>> Go
>>>
>>> These links deal with the practicalities of writing Go, and
>>> encourage/discourage various implementation patterns observed in real world
>>> use.
>>>
>>> Effective Go  is officially
>>> provided documentation that gives tips for writing clear, idiomatic Go
>>> code. "Effective Go" is generally regarded in the Go community as
>>> particularly helpful.
>>>
>>> Go Code Review Comments
>>>  is a laundry
>>> list of common mistakes, not a comprehensive style guide. It's great for
>>> beginners and advanced programmers as it explains the rationale behind its
>>> guidance.
>>>
>>> Practical Go: Real World Advice
>>>  
>>> presents
>>> an excellent overview of the practice of software engineering in Go. Some
>>> overlap with Effective Go and Code Review Comments, but with more
>>> explanation and memorable quotes to describe patterns.
>>>
>>> On Fri, Jul 19, 2019 at 9:39 AM  wrote:
>>>
 would anyone help me out how to learn go lang more practically , may be
 some resources . I want to understand go lang more practically , with some
 great examples.

 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/4cb7eae4-b6d2-4454-9d4a-2fe7790cf685%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/CANGiwgbWEsMZaU66zn-eN2%3Dcm8sOp_tGwRd6-pC%3Di9DJiahcOg%4

Re: [go-nuts] Do Any Editors Support Customisable Code collapsing?

[Michael Jones]

Ha!

https://github.com/rstuven/vscode-iferrblocks

On Thu, Jul 18, 2019 at 10:32 AM Jim Robinson 
wrote:

> Is it named try? :P
>
> On Wednesday, July 17, 2019 at 8:37:53 PM UTC-7, Michael Jones wrote:
>>
>> There is a special “collapse if err !=  nil blocks plugin for VS code.
>>
>> On Wed, Jul 17, 2019 at 5:37 PM  wrote:
>>
>>> Context:
>>> 1. Golang can be very verbose, for example checking if err != nil after
>>> a function call takes 3 lines:
>>> if err != nil {
>>>return nil, fmt.Errorf("some context: %v", err)
>>> }
>>>
>>>
>>> 2. Editors like VSCode can already collapse blocks of statements, where
>>> the above would be displayed as:
>>> if err != nil {...
>>>
>>>
>>> My question:
>>> Are there any editors that support some kind of customisable collapsing
>>> behaviour? Where the above code could be collapsed to something like:
>>> ...check...fmt.Errorf("some context: %v", err)...
>>>
>>> Has anyone tried to implement this kind of behaviour? Is it difficult to
>>> achieve?
>>>
>>>
>>>
>>> --
>>> 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/e15556dd-b957-4d79-9ca4-8b6ed8eb6e6c%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/e15556dd-b957-4d79-9ca4-8b6ed8eb6e6c%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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-nuts/920a48e6-431d-40b2-8081-d0b207cb1840%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/920a48e6-431d-40b2-8081-d0b207cb1840%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQzhOPd5%2BpFMZYdwvhHuq4OudugZWnJE%2B0_1W5NgtSKt9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] mutexes, etc

[Michael Jones]

Go has an unusual (clever!) property that anything whose address “escapes”
from your routine will magically be allocated on the heap _no matter if it
looks like heap or local allocation. Conversely, even explicit heap
allocations that don’t escape will/may be local (will up to 10 MiB).

Is data local or not. If yes, then it is safe and is as if a single thread
program no matter how many CPUs or goroutines. This is a go glory. But if
anything else can see it...then caution and precaution are necessary.

On Wed, Jul 17, 2019 at 5:52 PM joe mcguckin 
wrote:

> When do you need to use mutexes? Which begs the question: When can
> multiple coroutines trample on  memory or a variable?
> Doesn't each instance of a go routine get it's own stack (so, it's own
> local copy of local vars). It would seem that the only
> entities that it's possible to access from multiple goroutines are things
> allocated from the heap, as you mould have identical pointer
> values in multiple go threads - yes?
>
> Like they say, Inquiring minds want to know...
>
> Thanks,
>
> Joe
>
> --
> 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/a1fdcdb2-3276-4b67-88be-5414c12ccac5%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQwS3MdJF0GF_g84iaVgPD4neAXP2M7D60aAPM7f9OhnUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Do Any Editors Support Customisable Code collapsing?

[Michael Jones]

There is a special “collapse if err !=  nil blocks plugin for VS code.

On Wed, Jul 17, 2019 at 5:37 PM  wrote:

> Context:
> 1. Golang can be very verbose, for example checking if err != nil after a
> function call takes 3 lines:
> if err != nil {
>return nil, fmt.Errorf("some context: %v", err)
> }
>
>
> 2. Editors like VSCode can already collapse blocks of statements, where
> the above would be displayed as:
> if err != nil {...
>
>
> My question:
> Are there any editors that support some kind of customisable collapsing
> behaviour? Where the above code could be collapsed to something like:
> ...check...fmt.Errorf("some context: %v", err)...
>
> Has anyone tried to implement this kind of behaviour? Is it difficult to
> achieve?
>
>
>
> --
> 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/e15556dd-b957-4d79-9ca4-8b6ed8eb6e6c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQxUZdTTfZSPsvC3EgBSXhEC9-ivUY_5CK5OHPTMd03Avg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: About the Google logo on the new Go website

[Michael Jones]

I'm a reader here, so @all includes me. In regards to Oracle, I was
delighted when they released VirtualBox under GPL and remain delighted that
they pay Oracle employees to enhance it and share their work. When they
write (https://www.virtualbox.org)...

*"VirtualBox is being actively developed with frequent releases and has an
ever growing list of features, supported guest operating systems and
platforms it runs on. VirtualBox is a community effort backed by a
dedicated company: everyone is encouraged to contribute while Oracle
ensures the product always meets professional quality criteria."*


...I find that a logical explanation and a mutually beneficial outcome. The
name 'Oracle' on that page does not discomfort me, nor does it upset me
that the remarkable and free VS-Code admits to Microsoft's parentage--I
thank them for that. I feel the same way about Google staffing Go with my
computer science heroes (Ken Thompson et al!), building a wonderful
language, application-level operating system, rigorous spec, two compilers,
and open sourcing every bit of it. I am grateful, respectful, and
absolutely stunned at your vitriol in response to gifts that none of us
earned. It feels base and unseemly to me. Maybe you could reconsider your
posture.

Michael Jones
Ever grateful for manna from heaven

On Tue, Jul 16, 2019 at 9:05 PM Anca Emanuel  wrote:

> @all, what do you think of Oracle ?
> That is not an company, that is an monster.
>
> On Monday, July 15, 2019 at 6:40:19 PM UTC+3, Michal Strba wrote:
>>
>> As you all know, the new, redesigned Go website has a Google logo in the
>> bottom right corner.
>> Someone opened an issue about this, worrying that with the logo, nobody
>> will see Go as a community project:
>> https://github.com/golang/go/issues/33021
>>
>> The issue was promptly closed and locked by a Go team member, which I
>> must admit, is kind of an unfair move.
>> If you read this thread on r/programming, it seems like the worries are
>> quite justified:
>> https://www.reddit.com/r/programming/comments/ccidly/golang_issue_ticket_remove_the_google_logo/
>>
>> I personally am fine with the logo.
>>
>> What do you think? For example, Rust has no Mozilla logo on its page
>> despite being largely funded by 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/708a60a4-0ad2-41f6-a997-8fa6c5f83e53%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/708a60a4-0ad2-41f6-a997-8fa6c5f83e53%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQxy2aSEQGQuUyQNUwDfc4rNYR1_YYYmw7tP2Mih8EuAzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go for Data Science

[Michael Jones]

Leo,

R is implemented in C and FORTRAN plus R on top of that. SAS is in C (and
some Go here and there) plus the SAS language in top of that. Mathematica
is implemented in C/C++ with the "Wolfram Language" on top of that. PARI/GP
is implemented in C plus some GP-language code. Macsyma, Maple, Octave,
Python,... follow this pattern too:

3 [glue-like meta-tools that combine various "full stack" tools]: Sage
  :
2 [interactive exploration environment with scripting]: many and various,
including R, SAS, MMA, GP, Macsyma, Axciom, Maple, Python, ...
  :
1 [performant heavy duty computation in compiled language]: C/C++
  :
0 [ultra-performant kernels in C/Assembler/..]: GMP, LAPACK, BLAS, ATLAS,
...

You say Data Science is an application domain where Level 2 features make
sense, where they facilitate understanding by providing an interactive
environment. The evidence supports you, though understand that none of your
examples (or in my expanded set) actually do much at that level: this is
where the "convolve a with b" is specified, but the actual doing is lower,
in Level 0 and 1, where Go-like compiled software in C, C++, or FORTRAN
does the heavy lifting. (I make this point only to clarify what some people
seem not to understand in blogs where they write "my Python giant matrix
solver is just as fast as C/C++/Go, I don't see why C/C++/Go is not faster"
or "I don't see advantage in compiled languages.")

If Go has a place in interactive, interpretive data science it seems to me
that it would be as the substrate language (Levels 0 and 1). Go certainly
has a place in statistics, applied mathematics, and other realms related to
data science if you want to include apps that do work and act on
results--control systems, analysis tools, etc. But to create an interactive
"play" space I'd (again, just me) be inclined to follow the PARI/GP model
with a Go kind of PARI and a domain-friendly GP.

The high-level GP (Mathematica, Maple, GP, SAS, ...) in the existing
systems often seems to me to be weak, not designed as a first-class
programming language but more like an endless accretion of script enabling
fixes and patches. I feel this especially in the way local variables are
defined which often feels brutish and awkward, but that extends to many
subtleties. It is natural that it tends this way--developers were focused
on the core and just needed "a way" to bind it all together. The successful
projects span decades and unanticipated new application domains so have
accumulated the most duct tape.

Another goodness of this two-level scheme is that the top language can be
"faulty" in ways that are comfortable. For example, think how many scalar
variables you see in C/C++/FORTRAN/Go: "i:= 3" is the bulk of variables.
But in R, there are (at least when I last looked) no scalar variables(!),
but you can get by with vectors of length 1. This would not do, generally,
but for R, it may be perfect. The two-level strata design of which PARI/GP
is one of the best implementations, makes this kind of field-of-use
tailoring work fine in practice. That's important, it is matching the
language's exposed concepts to the problem domain.

I don't see any of this as a weakness or strength of Go, or as something to
address in the case of a REPL, because it's not Go that you'd want a REPL
for, instead something that knows about data, or Diophantine equations, or
moon rocks, or whatever the domain may be and its natural forms of notation.

Michael

On Tue, Jul 16, 2019 at 10:18 AM Slonik Az  wrote:

> Hi Gophers!
> I was thinking to start a Go project in the area of Data Science that
> would allow for convenient and easy concurrent data processing but at the
> end decided against it mainly because of two reasons:
>
> (1) Almost all data science projects start with a data exploratory
> analysis of some sort. Unfortunately, Go does not have REPL. Go Playground
> is not a substitute, for it does not preserve state. On every iteration
> Playground recompiles and relaunches the entire program, reads all the data
> anew, performs all the calculations. Not good for an interactive "rapid
> fire".
> REPL in a static AOT compiled language is hard, yet Swift somehow managed
> to implement it.
>
> (2) Even if somebody implements incremental Go compiler and provides a
> proper REPL, people will be longing for data analysis "at your fingertips",
> missing rich pandas-like API, overloaded operators (python style) and
> dynamical scoping (like in R). Minimalistic design of Go is unlikely to
> accommodate all of these "convenience" constructs and for a good reason.
>
> I think Go has a place in highly performant concurrent data pipelines and
> transformations but I am less optimistic it would ever play in the field
> dominated currently by Python and R and possibly by Julia in the future. I
> am curious of what am I missing in this line of thinking?
>
> Thanks,
> --Leo
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nut

Re: [go-nuts] How to store the address of C struct on Go side in an array (cgo)

[Michael Jones]

It is really impossible to help you debug what is to the thousands of
readers here an invisible unseen program. You have a logic error. You don't
know where it is (of course, you are busy trying to find it) but we can't
know either as we don't see the code. General advice, as always, is to
"trap" the bug in the smallest stand-alone code that you can. That will
focus your search.

You just shared this:

Following is one of the methods called before this method :

func (obj SyslogParser) InitializeEngine() {
patterndb := C.CString(obj.Patterndb)
defer C.free(unsafe.Pointer(patterndb))
modulepath := C.CString(obj.Modulepath)
defer C.free(unsafe.Pointer(modulepath))
C.initialize_engine(patterndb, modulepath)
}

Not deallocating the memory for the struct can be  the issue for  'fatal
error: bin/main': double free or corruption (fasttop)' ?

Is this right? Is it correct to call C.initialize_engine(a,b) then
immediately call C.free(a) and C.free(b)? It might be fine if your
initialize engine clones/duplicates/or otherwise uses a & b just once. But
if not, then of course A & B will both instantly become death traps for
your C code during runtime of the engine, for any allocations that are
where A & B were located, and potentially when your "engine" is deallocated
later on.

Just one example of might be fine, might be disaster, no way for us to
tell. It seems that you have a logic problem in the program, not a C-to-Go
or Go-to-C interfacing problem. You're going to need to study your code
(unseen by us) yourself to see what that is. I think so anyway. Maybe Ian
is so smart that he can debug this for you by ESP. ;-)

Michael

On Fri, Jul 12, 2019 at 8:15 AM Nitish Saboo 
wrote:

> Hi Ian,
>
> > syslogparser.go
> > =
> >
> > func (obj SyslogParser) LoadPatternDB(opts Syslog, workerId int) {
>log.Info("Loading pattern db with path:", opts.Patterndb)
> > patterndbpath := C.CString(opts.Patterndb) .  <<< . STEP 1
> > defer C.free(unsafe.Pointer(patterndbpath)) .   STEP 2
> > InitStruct := (*C.Accumulatedparams)(C.calloc(1,
> C.sizeof_struct_Accumulatedparams))
> > InitStruct.callback = (C.key_value_cb)(C.callback)
> > InitStruct.data = C.int(workerId)
> > C.load_pattern_db(patterndbpath,
> (*C.Accumulatedparams)(unsafe.Pointer(InitStruct)), C.int(workerId))
> > }
> >
> > Since I am running this program in multiple go routines, when we do
> above STEP 1 :
> >
> > 1)Will the C memory allocate different addresses for  'patterndbpath' in
> both the routines ...Am I right ?
>
> Yes.
>
> > 2)You said 'It may be calling free twice on the same pointer', but I am
> assigning a different pointer in STEP 1 everytime for each routine...Am I
> right ?
>
> Yes, you will see a different pointer each time you call C.calloc, and
> in the code that I see that pointer is only freed once, but I have no
> idea what the rest of your code is doing.
>
> I am calling free only once  and that is for 'patterndbpath' in this
> particular method.In the entire codebase I am NOT calling free for
> InitStruct (Memory allocated for the struct)
> I am pointing out this particular method 'LoadPatternDB' of Go code base
> because I had put a 'Info' log in this method at the starting and that got
> printed before the corruption error came up.
> And my testing  failed at the third iteration:
>
> 1)WorkerID0 completed the  work
> 2)WorkerID1 completed the work
> 3)WorkerID1 failed in this particular method with 'fatal error:
> bin/main': double free or corruption (fasttop)'
>
> Following is one of the methods called before this method :
>
> func (obj SyslogParser) InitializeEngine() {
> patterndb := C.CString(obj.Patterndb)
> defer C.free(unsafe.Pointer(patterndb))
> modulepath := C.CString(obj.Modulepath)
> defer C.free(unsafe.Pointer(modulepath))
> C.initialize_engine(patterndb, modulepath)
> }
>
> Not deallocating the memory for the struct can be  the issue for  'fatal
> error: bin/main': double free or corruption (fasttop)' ?
>
> > 3)Is it possible that one Go routine has already freed up the address
> that the other Go routine is trying to free  and that is causing this
> 'fatal error: bin/main': double free or corruption (fasttop)'
>
> Yes, that is possible.  It won't happen with the code I see above but
> I have no idea what the rest of your code is doing.
>
> How can it not happen with this code ?I did not understand this point.
> Can you please clarify this point ?
>
> > Is this because of the race condition between two routines that this
> error is seen ?
>
> It is possible.
>
> > 4)If you show us a small, complete, self-contained example, that does
> not call any other code, then we may be able to see the problem.
> > >> As you have mentioned problem is happening when we call 'C.free'.Do
> you mean by not calling internal syslog-ng methods and just calling a
> normal C program with multiple go routines ?
> > Please correct me here if I am wrong
>
> I mean any small, self-contained example where we can se

Re: [go-nuts] Re: [ANN] VictoriaMetrics - fast open source time series database written in Go

[Michael Jones]

rpusZ.tar::blob_000158.go.zst
2019/07/11 10:05:34.775064 603118 →  4136079 bytes ( 6.858×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000163.go.zst
2019/07/11 10:05:34.792702 340353 →  4424067 bytes (12.998×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000164.go.zst
2019/07/11 10:05:34.796162 618352 →  4002249 bytes ( 6.472×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000154.go.zst
2019/07/11 10:05:34.820524 289494 →  4036048 bytes (13.942×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000146.go.zst
2019/07/11 10:05:34.820605 309016 →  5260095 bytes (17.022×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000152.go.zst
2019/07/11 10:05:34.865440 131045 →  4280066 bytes (32.661×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000165.go.zst
2019/07/11 10:05:34.870480 406615 →  4000797 bytes ( 9.839×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000162.go.zst
2019/07/11 10:05:34.918977 252124 →  4012267 bytes (15.914×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000153.go.zst
2019/07/11 10:05:34.927295 456129 →  4042538 bytes ( 8.863×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000161.go.zst
2019/07/11 10:05:34.942748 717740 →  4319130 bytes ( 6.018×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000170.go.zst
2019/07/11 10:05:35.011325 731744 →  4013175 bytes ( 5.484×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000171.go.zst
2019/07/11 10:05:35.040012 565284 →  4163041 bytes ( 7.365×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000169.go.zst
2019/07/11 10:05:35.062413 289918 →  401 bytes (13.797×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000159.go.zst
2019/07/11 10:05:35.066697 703842 →  401 bytes ( 5.683×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000160.go.zst
2019/07/11 10:05:35.075955 190967 →  4197565 bytes (21.981×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000168.go.zst
2019/07/11 10:05:35.085458 290878 →  4010780 bytes (13.789×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000172.go.zst
2019/07/11 10:05:35.170622  97265 →  4243884 bytes (43.632×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000166.go.zst
2019/07/11 10:05:35.184665 171285 →  4069187 bytes (23.757×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000167.go.zst
2019/07/11 10:05:35.224262 534458 →  2880005 bytes ( 5.389×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000175.go.zst
2019/07/11 10:05:35.312594 619070 →  4002126 bytes ( 6.465×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000174.go.zst
2019/07/11 10:05:35.313823 518866 →  4350379 bytes ( 8.384×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_000173.go.zst
2019/07/11 10:05:35.408361 scan ends
2019/07/11 10:05:35.408391 performance
2019/07/11 10:05:35.408400   grep  16 matches
2019/07/11 10:05:35.408408   work  752 311 514 bytes, 170 302 873 tokens,
22 927 078 lines, 176 files
2019/07/11 10:05:35.408417   time  3.975375 sec elapsed, 25.803189 sec user
+ 0.985283 system
2019/07/11 10:05:35.408424   rate  189 242 887 bytes/sec, 42 839 444
tokens/sec, 5 767 273 lines/sec, 44 files/sec
2019/07/11 10:05:35.408431   cpus  7 workers (parallel speedup = 6.74x)
celeste:gg mtj$

There is no doubt that Zstd is a brilliance, nor that Klaus' library is
excellent.

On Thu, Jul 11, 2019 at 9:55 AM Aliaksandr Valialkin 
wrote:

>
>
> On Thu, Jul 11, 2019 at 7:29 PM Michael Jones 
> wrote:
>
>> I use Klaus' library to decompress ~GiB files that have been compressed
>> by zstd command line (c/c++ code) at level 19. Works great.
>>
>
> Thanks for sharing this information!
>
>
>> On Thu, Jul 11, 2019 at 9:10 AM Klaus Post  wrote:
>>
>>> On Thursday, 11 July 2019 17:37:09 UTC+2, Aliaksandr Valialkin wrote:
>>>>
>>>>
>>>>
>>>> This is really great idea! Will try implementing it.
>>>>
>>>> Does github.com/klauspost/compress support all the levels for data
>>>> decompression? VictoriaMetrics varies compression level depending on the
>>>> data type. It would be great if github.com/klauspost/compress could
>>>> decompress data compressed by the upstream zstd on higher compression
>>>> levels.
>>>>
>>>
>>> Decompression will work for all input. It is implementing the full spec.
>>>
>>
> Great! I filed feature request for implementing pure Go builds for
> VictoriaMetrics -
> https://github.com/VictoriaMetrics/VictoriaMetrics/issues/94 .
>
>
>>
>>> Compression has "Fastest" and "Default" 

Re: [go-nuts] Re: [ANN] VictoriaMetrics - fast open source time series database written in Go

[Michael Jones]

I use Klaus' library to decompress ~GiB files that have been compressed by
zstd command line (c/c++ code) at level 19. Works great.

On Thu, Jul 11, 2019 at 9:10 AM Klaus Post  wrote:

> On Thursday, 11 July 2019 17:37:09 UTC+2, Aliaksandr Valialkin wrote:
>>
>>
>>
>> This is really great idea! Will try implementing it.
>>
>> Does github.com/klauspost/compress support all the levels for data
>> decompression? VictoriaMetrics varies compression level depending on the
>> data type. It would be great if github.com/klauspost/compress could
>> decompress data compressed by the upstream zstd on higher compression
>> levels.
>>
>
> Decompression will work for all input. It is implementing the full spec.
>
> Compression has "Fastest" and "Default" implemented, roughly matching
> level 1 and 3 in zstd in speed and performance. I plan on adding something
> around level 7-9 (as Better) and level 19 (as Best). But for it to be
> useful I have mainly focused on the fastest modes. I also am planning more
> concurrency in compression and decompression for streams - blocks will
> probably remain as single goroutines. For now I am taking a small break and
> having a bit of fun revisiting deflate and experimenting with Snappy.
>
> If there is anything I can do to help feel free to ping me.
>
>
> /Klaus
>
>
>>
>> --
>> Best Regards,
>>
>> Aliaksandr
>>
> --
> 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/b12c7562-b3a6-426b-bb1c-a62fcfc41714%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQwocTkYXf7bn39mxpkhuF%2Bynogb8BC6YwzXa9%3Dj89%3DvQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Avoiding resource leaks with racing channels

[Michael Jones]

unbuffered means nothing is sent until is is simultaneously received, so
there is no limbo or race or uncertainty. one sender "wins" the select and
the others remain blocked waiting.

On Wed, Jul 10, 2019 at 6:24 AM Dan Eloff  wrote:

> Maybe I'm wrong here in my understanding of unbuffered channels, but I
> don't think so:
>
> Matt says earlier: "Only a buffered channel can "hold" anything. If the
> channel is unbuffered, then you are guaranteed that another goroutine has
> at least received the item you sent when the send statement returns."
>
> I think at least in the simple case of `channel <- fd` this cannot be
> true, since that operation can only fail by panicking, and I beleive it
> will only panic if the channel is nil or closed. Now if you used a
> non-blocking send with a select, that would be a different story.
>
> So if you send over that channel it blocks
> the receiver wakes and runs the select
> but sees both channels ready
> picks the timeout channel at random
>
> Now one of two things must happen, either the sender blocks forever
> because nobody read the sent value, or the value gets lost to space and
> both receiver and sender continue on their merry ways.
>
> Am I wrong?
>
> -Dan
>
> --
> 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/CADz32d%3DOm96%2B7iZet%3DDL0AaNxYVYWO6Q%3DOgvzoYiWKdZpSipHg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQzqDs9XnDm-WHuUw7pr7j%2BB%3Df8PsozhoKsgXDQ7o%3DwjuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] new godoc layout

[Michael Jones]

color change, from aqua to teal, was jarring to me.

On Tue, Jul 9, 2019 at 2:14 PM mh cbon  wrote:

> ... is awesome. so much better to read. much much more enjoyable.
>
>
> 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/eb8979f6-41bf-4ef2-b7aa-2c5da68aac50%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQx4RtzKNLt4cW_dJJYb5VtxrfH5MdLp4JMuuL5DQfx%2Bzg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: net/http and the GC

[Michael Jones]

Very fortunate!

On Mon, Jul 8, 2019 at 1:20 PM B Carr  wrote:

>
>
> On Monday, July 8, 2019 at 1:01:26 PM UTC-6, Burak Serdar wrote:
>>
>>
>> > I'll need to study this a bit more. Can you give me a pointer?
>>
>> I don't know really, other than the obvious ones like:
>>
>> http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/
>> https://golang.org/doc/  -> there's sections on concurrency patterns,
>> http servers, etc.
>>
>
> Thanks for that.
>
>
>>
>> The most difficult and crucial thing with go is to change the way you
>> think about concurrency. For years I wrote programs in Java, and when
>> I started working with go, I looked for thread pools and thread local
>> variables. Learning to live without them was refreshing.
>>
>
> Since I'm coming to Go with zero background in concurrency there is
> nothing contaminating me. Fortunately...
>
> --
> 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/f658e6c9-7b73-4f25-a7db-4c5a95df79bd%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQzMFrmYmsd4TtYkLUk7KRsN3dLFSOodvV5WHNE9z1TfwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: ioutil.ReadDir sort order

[Michael Jones]

Indeed, you have two choices: create file names with fixed width numbers:

Printf “file%08dv%02d.dat”, f,v

Or do a string/number parse of the names before sorting and separate the
numbers, you can insert spaces/zeroes and then string sort, or you can
parse the numbers and compare them numerically.

Sample code is in the Unix sort -n option and more specifically the multi
key feature -k

On Sat, Jul 6, 2019 at 3:47 AM Dan Kortschak  wrote:

> It's sorted lexically by the unicode code points. Why would str1 come
> after str2? '1' < '9'.
>
> On Fri, 2019-07-05 at 21:23 -0700, shubham.pendharkar via golang-nuts
> wrote:
> > It sorts by name, but there is a big problem with golang string
> > comparison.
> > If you consider these two strings:
> > str1 : "hello.20190305-102.txt"
> > str2 : "hello.20190305-99.txt"
> >
> > Then we should say that str1 > str2.
> > But go returns str1 < str2
> >
> > On Wednesday, August 19, 2015 at 3:10:41 PM UTC+5:30, Arie van
> > Wingerden
> > wrote:
> > >
> > > The docs say: ReadDir reads the directory named by dirname and
> > > returns a
> > > list of sorted directory entries.
> > > *It does not say sorted by what. *
> > > Maybe a doc update would be nice.
> > > TIA
> > >
> > >
> >
> > --
> > This message contains confidential information and is intended only
> > for the
> > individual to whom it is addressed. If you are not the intended
> > recipient,
> > you should not disseminate, distribute or copy this e-mail. Please
> > notify
> > the sender immediately by e-mail if you have received this e-mail by
> > mistake and permanently delete this e-mail from your system. E-mail
> > transmission cannot be guaranteed to be secure or error-free as
> > information
> > could be intercepted, corrupted, lost, destroyed, late or incomplete,
> > or
> > could contain viruses. The sender therefore does not accept liability
> > for
> > any errors or omissions in the contents of this message, which arise
> > as a
> > result of e-mail transmission. If verification is required, please
> > request
> > a hard-copy version from the sender. Druva, www.druva.com
> > 
> >
> > --
> >
> >
> > This message contains confidential information and is intended only
> > for
> > the individual to whom it is addressed. If you are not the intended
> > recipient, you should not disseminate, distribute or copy this e-
> > mail.
> > Please notify the sender immediately by e-mail if you have received
> > this
> > e-mail by mistake and permanently delete this e-mail from your
> > system.
> > E-mail transmission cannot be guaranteed to be secure or error-free
> > as
> > information could be intercepted, corrupted, lost, destroyed, late
> > or
> > incomplete, or could contain viruses. The sender therefore does not
> > accept
> > liability for any errors or omissions in the contents of this
> > message,
> > which arise as a result of e-mail transmission. If verification is
> > required, please request a hard-copy version from the sender. Druva,
> > www.druva.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/b5cb1e05924f6614eaca3eb280acd0aae44b631c.camel%40kortschak.io
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQw%2BYFd3s6EhMHTRu7sQaP1%3DBeRv_qEZARNZrYd%2BXtH7sQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Does this code safe?

[Michael Jones]

The race detector detects races, like smoke detectors detect smoke and
water detectors detect water. Are you asking if the race detector is
broken? If its judgement is just a guess? Not a guess. A scientific
observation. Your code is not safe.

On Fri, Jul 5, 2019 at 7:53 AM Cholerae Hu  wrote:

> package main
>
> import (
> "sync/atomic"
> "sync"
> )
>
> func main() {
> var n int32
> var m sync.Mutex
> var wg sync.WaitGroup
> wg.Add(2)
> go func() {
> for {
> atomic.LoadInt32(&n)
> }
> wg.Done()
> }()
> go func() {
> for {
> m.Lock()
> n = 1
> m.Unlock()
> }
> wg.Done()
> }()
> wg.Wait()
> }
>
> Does it safe to use atomic read an int and write an int non-atomically but
> in lock concurrently? Race detector will report it data race.
>
> --
> 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/825f9031-74b9-41b6-87af-dccfa7d98d04%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQzXrK2RnBpcpR7eQpAGPV4tNZZF0xNsuLjGMPSS2xHR9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Announcing gg ("gigi") your new friend

[Michael Jones]

Interesting. I will look. the issue is the level of the smartness. gg is
basic (tokens) and below a full parse (syntax). The higher you go, the
different the search questions can be.

If you downloaded, please update and rebuild. I had mail about a
performance problem and found an error of configuration. It is better now.

Michael

On Thu, Jul 4, 2019 at 5:59 PM Andy Balholm  wrote:

> I recently ran across https://github.com/mvdan/gogrep. It does some of
> that.
>
> Andy
>
> On Jul 4, 2019, at 5:30 PM, Bakul Shah  wrote:
>
> Very nice!
>
> A natural great extension[1] would be language aware grep/sed/awk:
> - return an *enclosing* parse construct after matching something
> - match on a construct with some pieces wildcarded
> - replace one structure with another (but based on the match)
>
> Possible uses:
> - when you change an API of a package, fix up its users
> - rename variables
> - replace Go1 constructs with simpler/more efficient Go2 ones.
> - write generic code and replace with type specific code
> - program construction (ala Beta language's fragment system)
> - literate programming (tangle/weave)
> - optimize code
> - program analysis
> - structured diff/merge
>
> The tough part would be coming up with a simple but flexible
> structured regular expression language. [Initially I had thought
> this is what Rob was writing about in his "Structured Regular
> Expressions" paper! So the idea is very old.]
>
> [1] No good deed goes unpunished :-)
>
>
> On Jul 4, 2019, at 9:10 AM, Michael Jones  wrote:
>
> Recently I shared my Survey <https://github.com/MichaelTJones/survey>
> program, saying that it was a sidestep from what I was working on but
> interesting and hopefully useful to others. Here is the real thing, named
> gg, that Survey was a test for. GG combines lexical analysis and Go-native
> pattern matching to extend grep(1) for Go developers
>
> GG is smart; the search is restricted, seeking matches only in chosen
> token classes.  A search in number literals can match values in addition to
> patterns: "v 255" matches the numeric value 255 in source code as
> 0b_, 0377, 0o377, 255, 0xff, etc.  Go's linear-time regular
> expression engine is Unicode-aware and supports many extensions: numbers in
> identifiers are found with "gg i [0-9]" or "gg i [\d]", find comments with
> math symbols using "gg c \p{Sm}", and Greek in strings via "gg s \p{Greek}".
>
> GG is fast, uses all cores, understands filesystem hierarchies, archives,
> and compression schemes, and is general like grep while focused in a new
> way: find within package names, identifiers, types, strings, comments, and
> more.
>
> Source code:
> https://github.com/MichaelTJones/gg
>
> Man page (all is explained here):
> https://github.com/MichaelTJones/gg/blob/master/gg.pdf
>
> Examples:
>
> Search the Go 1.13 source code for strings containing Megalosaurus, but
> not comments:
>
> $ gg -r s Megalosaurus ~/go
> /Users/mtj/go/src/cmd/link/link_test.go:`text:"London. Michaelmas term
> lately over, and the Lord Chancellor sitting in Lincoln’s Inn Hall.
> Implacable November weather. As much mud in the streets as if the waters
> had but newly retired from the face of the earth, and it would not be
> wonderful to meet a Megalosaurus, forty feet long or so, waddling like an
> elephantine lizard up Holborn Hill. ...
>
>
> Search the Go 1.13 source code for identifiers with greek letters (but not
> strings or comments):
>
> $ gg -r i '\p{Greek}' ~/go
> /Users/mtj/go/src/encoding/json/encode_test.go: A0, À, Aβ int
> /Users/mtj/go/src/math/cmplx/polar.go:func Polar(x complex128) (r, θ
> float64) {
> /Users/mtj/go/src/math/cmplx/rect.go:func Rect(r, θ float64) complex128 {
> /Users/mtj/go/src/math/cmplx/rect.go: s, c := math.Sincos(θ)
> /Users/mtj/go/src/math/rand/rand_test.go: var χ2 float64
> :
>
>
> Best to all,
> Michael
>
> --
>
> *Michael T. jonesmichael.jo...@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-nuts/CALoEmQz-KdFaWjS%2Bfyd-QQS4LEgYmnofiZNmugnoQ7sNaG0HEA%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CALoEmQz-KdFaWjS%2Bfyd-QQS4LEgYmnofiZNmugnoQ7sNaG0HEA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> You received this

Re: [go-nuts] Re: Announcing gg ("gigi") your new friend

[Michael Jones]

Niko, good question. You have your answer already but i’ll add installation
advice in the readme or an install guide. Should be trivial anywhere Go is,
“go get path && go install gg”

On Thu, Jul 4, 2019 at 10:23 AM 'Niko Schwarz' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> What's your recommended strategy for installing it on linux? I guess it'll
> take a few years before distributions have easy-to-install packages just
> listed in their indices.
>
> On Thursday, July 4, 2019 at 6:11:47 PM UTC+2, Michael Jones wrote:
>>
>> Recently I shared my Survey <https://github.com/MichaelTJones/survey>
>> program, saying that it was a sidestep from what I was working on but
>> interesting and hopefully useful to others. Here is the real thing, named
>> gg, that Survey was a test for. GG combines lexical analysis and Go-native
>> pattern matching to extend grep(1) for Go developers
>>
>> GG is smart; the search is restricted, seeking matches only in chosen
>> token classes.  A search in number literals can match values in addition to
>> patterns: "v 255" matches the numeric value 255 in source code as
>> 0b_, 0377, 0o377, 255, 0xff, etc.  Go's linear-time regular
>> expression engine is Unicode-aware and supports many extensions: numbers in
>> identifiers are found with "gg i [0-9]" or "gg i [\d]", find comments with
>> math symbols using "gg c \p{Sm}", and Greek in strings via "gg s \p{Greek}".
>>
>> GG is fast, uses all cores, understands filesystem hierarchies, archives,
>> and compression schemes, and is general like grep while focused in a new
>> way: find within package names, identifiers, types, strings, comments, and
>> more.
>>
>> Source code:
>> https://github.com/MichaelTJones/gg
>>
>> Man page (all is explained here):
>> https://github.com/MichaelTJones/gg/blob/master/gg.pdf
>>
>> Examples:
>>
>> Search the Go 1.13 source code for strings containing Megalosaurus, but
>> not comments:
>>
>> $ gg -r s Megalosaurus ~/go
>> /Users/mtj/go/src/cmd/link/link_test.go:`text:"London. Michaelmas term
>> lately over, and the Lord Chancellor sitting in Lincoln’s Inn Hall.
>> Implacable November weather. As much mud in the streets as if the waters
>> had but newly retired from the face of the earth, and it would not be
>> wonderful to meet a Megalosaurus, forty feet long or so, waddling like an
>> elephantine lizard up Holborn Hill. ...
>>
>>
>> Search the Go 1.13 source code for identifiers with greek letters (but
>> not strings or comments):
>>
>> $ gg -r i '\p{Greek}' ~/go
>> /Users/mtj/go/src/encoding/json/encode_test.go: A0, À, Aβ int
>> /Users/mtj/go/src/math/cmplx/polar.go:func Polar(x complex128) (r, θ
>> float64) {
>> /Users/mtj/go/src/math/cmplx/rect.go:func Rect(r, θ float64) complex128 {
>> /Users/mtj/go/src/math/cmplx/rect.go: s, c := math.Sincos(θ)
>> /Users/mtj/go/src/math/rand/rand_test.go: var χ2 float64
>> :
>>
>>
>> Best to all,
>> Michael
>>
>> --
>>
>> *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-nuts/078487a3-cbda-4479-b414-da5aed21f86f%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/078487a3-cbda-4479-b414-da5aed21f86f%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQzK9Qjk68F4Vh7KKaNQ5ttaW0bDM93BFc8H4c8_ZOwEdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Announcing gg ("gigi") your new friend

[Michael Jones]

Recently I shared my Survey 
program, saying that it was a sidestep from what I was working on but
interesting and hopefully useful to others. Here is the real thing, named
gg, that Survey was a test for. GG combines lexical analysis and Go-native
pattern matching to extend grep(1) for Go developers

GG is smart; the search is restricted, seeking matches only in chosen token
classes.  A search in number literals can match values in addition to
patterns: "v 255" matches the numeric value 255 in source code as
0b_, 0377, 0o377, 255, 0xff, etc.  Go's linear-time regular
expression engine is Unicode-aware and supports many extensions: numbers in
identifiers are found with "gg i [0-9]" or "gg i [\d]", find comments with
math symbols using "gg c \p{Sm}", and Greek in strings via "gg s \p{Greek}".

GG is fast, uses all cores, understands filesystem hierarchies, archives,
and compression schemes, and is general like grep while focused in a new
way: find within package names, identifiers, types, strings, comments, and
more.

Source code:
https://github.com/MichaelTJones/gg

Man page (all is explained here):
https://github.com/MichaelTJones/gg/blob/master/gg.pdf

Examples:

Search the Go 1.13 source code for strings containing Megalosaurus, but not
comments:

$ gg -r s Megalosaurus ~/go
/Users/mtj/go/src/cmd/link/link_test.go:`text:"London. Michaelmas term
lately over, and the Lord Chancellor sitting in Lincoln’s Inn Hall.
Implacable November weather. As much mud in the streets as if the waters
had but newly retired from the face of the earth, and it would not be
wonderful to meet a Megalosaurus, forty feet long or so, waddling like an
elephantine lizard up Holborn Hill. ...


Search the Go 1.13 source code for identifiers with greek letters (but not
strings or comments):

$ gg -r i '\p{Greek}' ~/go
/Users/mtj/go/src/encoding/json/encode_test.go: A0, À, Aβ int
/Users/mtj/go/src/math/cmplx/polar.go:func Polar(x complex128) (r, θ
float64) {
/Users/mtj/go/src/math/cmplx/rect.go:func Rect(r, θ float64) complex128 {
/Users/mtj/go/src/math/cmplx/rect.go: s, c := math.Sincos(θ)
/Users/mtj/go/src/math/rand/rand_test.go: var χ2 float64
:


Best to all,
Michael

-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQz-KdFaWjS%2Bfyd-QQS4LEgYmnofiZNmugnoQ7sNaG0HEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: `on err` alternative to `try()` has traction...?

[Michael Jones]

Any form of restraining gofmt has my vote. One that I despise is ruining:

switch v {
case ‘a’: doA = true
case ‘b’: doB = true
:
case ‘z’: doZ = true
}

Just had this two days ago. So sad to see it balloon up

On Wed, Jul 3, 2019 at 11:36 AM Aston Motes  wrote:

> This proposal is not very much different from a one-liner
>
> if err != nil {  }
>
> It's just 10 more characters. Granted, gofmt won't leave the one-liner
> formatted that way, but it's not much more typing and comes with the
> benefit of not needing a new keyword.
>
> One variation on this proposal that is a little weird is that if could in
> the case of checking for an error omit the requirement that its argument be
> a boolean, giving
>
> if err {  }
>
> Which is only 3 characters longer than on and again avoids a new keyword.
> I believe changing the behavior of if this way should be backwards
> compatible.
>
> On Wed, Jul 3, 2019 at 6:26 AM Michael Ellis 
> wrote:
>
>> I like this. A lot.
>>
>> It's clean and explicit.  The reader only needs to understand that 'on'
>> is a test for a nil value (vs 'if' which tests for boolean true).
>>
>>
>>
>> On Tuesday, July 2, 2019 at 3:57:24 PM UTC-4, Liam wrote:
>>>
>>> This proposal has attracted modest attention from the Go team...
>>> https://github.com/golang/go/issues/32611
>>>
>>> It suggests:
>>>
>>> err := f()
>>> on err, 
>>>
>>> on err, return err// any type can be tested for non-zero
>>> on err, return fmt.Errorf(...)
>>>
>>> on err, fmt.Println(err)  // doesn't stop the function
>>> on err, continue  // retry in a loop
>>>
>>> on err, goto label// labeled handler invocation
>>> on err, hname // named handler invocation
>>>
>>>
>>>
>>> And offers these possible extensions:
>>>
>>> on err, os.IsNotExist(err):  
>>> on err, err == io.EOF:   
>>> on err, err.(*os.PathError): // doesn't panic if not a match
>>>
>>> on err, : 
>>> on err:   // this pair provides if/else in 2 lines
>>>
>>> on err := f(),  // for assignment with single lvalue
>>>
>>>
>>>
>>> Other punctuation is possible, e.g. on (err) 
>>>
>>> Now if we could just convince the Go gods to prototype this along with
>>> try() in 1.14 :-)
>>>
>> --
>> 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/decc63a5-9e65-4e96-929f-76d44cf19e14%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/CANfvvbVy1iP8Un8zudCwZhkTg5dQfGCrBkN-0VmFbbK-FgD8dA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQy5E5%2BK%2BKAcCvVZFJDWptNdfkAz1NrSUVa4oM%3DuQxTgOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] OOM occurring with a small heap

[Michael Jones]

(I don't suspect GC either, it was a rule it out suggestion)

On Mon, Jul 1, 2019 at 10:20 PM robert engels  wrote:

> One other thing to think about - 500 qps is a lot for a single server if
> things start blocking and you have a low memory cap. Imagine the scenario
> where the DynamoDB “locks up / heavy delays due to IO contention /
> something”, depending on how your server is written/configured it may still
> keep accepting inbound connections, each potentially causing a thread to be
> created (if they are doing blocking IO). If there is not a low cap on the
> number of inbound connections you could quickly run out of memory. You
> might want to see if there is a configuration option on grpc-gateway to
> limit the maximum number of simultaneous inbound connections, set that to a
> low number, and see if it still runs out of memory.
>
> This scenario is unlikely if you didn’t see the TCPConn instances in the
> heap dump.
>
> On Jul 1, 2019, at 11:28 PM, Mighty Guava  wrote:
>
> Oh now that you mention it, I'm using grpc-gateway with the stdlib http
> server. Though all it really does is convert json <=> protobuf and is
> pretty mature so it's unlikely to be the culprit.
>
> Running with race detector is a good idea! I'll try that tomorrow.
>
> Thanks,
> Yunchi Luo
> On Jul 2, 2019, 12:25 AM -0400, robert engels ,
> wrote:
>
> Are you using anything like fast-http, or such? Have you tried running the
> server with the race-detector enabled? I could see a race condition causing
> a rare failure that causes the code to go into a ‘spinning loop’ preventing
> GC to work properly. It’s a guess but I would try that to rule out the
> possibility.
>
> On Jul 1, 2019, at 11:06 PM, Mighty Guava  wrote:
>
> I don't think GC is being blocked. GC ran multiple times during the time
> the service was exploding in memory.
>
> I'm not using mmap in the service. It's just a straightforward CRUD
> webserver backed by DynamoDB. The only thing non-standard I can think of is
> that it connects to its backing database over HTTP/1.1 (using AWS Go SDK)
> instead of a custom database protocol. It's serving a fair amount of
> requests (500 qps per replica), so I initially assumed it was
> under-provisioned to handle latency spikes. But I tripled the memory and
> it's still OOMing on occasion, even though RSS is 9% of allocated memory
> just seconds before.
>
> Yunchi
> On Jul 2, 2019, 12:00 AM -0400, Robert Engels ,
> wrote:
>
> Does your process use mmap? Maybe you are leaking there, as this counts
> against process memory size.
>
> On Jul 1, 2019, at 9:11 PM, Mighty Guava  wrote:
>
> I don't understand. What would adding runtime.Goscheduled() do here? I
> don't have any explicit loops in this service.
> On Jul 1, 2019, 9:11 PM -0400, Michael Jones ,
> wrote:
>
> Does adding runtime.GoSched() calls make any difference?
>
> On Mon, Jul 1, 2019 at 5:37 PM 'Yunchi Luo' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> Following that logic, a leak of TCP connections should manifest as a file
> descriptor leak. We have the process_open_fds metric from Prometheus, that
> is the number of open file descriptors as found in /proc//fd. The
> number of descriptors overtime correlates well with the amount of traffic,
> pretty cyclic. There doesn't appear to be a leak.
>
> We don't do our own memory management and the binary is compiled with
> CGO_ENABLED=0.
>
> I still think the issue I'm seeing should be GC (or heap) related, given
> the explosion in mark & sweep time, HeapSys, HeapIdle, and HeapReleased
> just before the process dies. But I'm lacking ideas on how to track down
> the cause of the increase.
>
> On Mon, Jul 1, 2019 at 5:39 PM Robert Engels 
> wrote:
>
> I think don't think you are going to find it in the 'heap', rather it
> would be in native memory.
>
> I would use the monitor the /proc/[pid] for the process, and pay attention
> to the 'fd','net' and 'statm' - if my theory is correct you will see growth
> here long before the process is killed. Since you are running under k8s and
> cgroups, you will need to do this along side the Go process (unless you
> have root access to the server).
>
> I 'think' depending on kernel version, that kernel memory used goes
> against the process for OOM purposes, so this is a likely candidate if
> pprof is showing nothing.
>
> Do you by chance do any of your own memory management (via malloc/CGO)? If
> so, this is not going to show in pprof either.
>
> -Original Message-
> From: 'Yunchi Luo' via golang-nuts

Re: [go-nuts] OOM occurring with a small heap

[Michael Jones]

One theory you advanced is of a desperate garbage collector. If you prevent
it from running all along, then maybe that could be possible. Pursuing that
line of reasoning I though you could ensure it’s chances with gosched() in
your code.

On Mon, Jul 1, 2019 at 7:17 PM Mighty Guava  wrote:

> I don't understand. What would adding runtime.Goscheduled() do here? I
> don't have any explicit loops in this service.
> On Jul 1, 2019, 9:11 PM -0400, Michael Jones ,
> wrote:
>
> Does adding runtime.GoSched() calls make any difference?
>
> On Mon, Jul 1, 2019 at 5:37 PM 'Yunchi Luo' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> Following that logic, a leak of TCP connections should manifest as a file
> descriptor leak. We have the process_open_fds metric from Prometheus, that
> is the number of open file descriptors as found in /proc//fd. The
> number of descriptors overtime correlates well with the amount of traffic,
> pretty cyclic. There doesn't appear to be a leak.
>
> We don't do our own memory management and the binary is compiled with
> CGO_ENABLED=0.
>
> I still think the issue I'm seeing should be GC (or heap) related, given
> the explosion in mark & sweep time, HeapSys, HeapIdle, and HeapReleased
> just before the process dies. But I'm lacking ideas on how to track down
> the cause of the increase.
>
> On Mon, Jul 1, 2019 at 5:39 PM Robert Engels 
> wrote:
>
> I think don't think you are going to find it in the 'heap', rather it
> would be in native memory.
>
> I would use the monitor the /proc/[pid] for the process, and pay attention
> to the 'fd','net' and 'statm' - if my theory is correct you will see growth
> here long before the process is killed. Since you are running under k8s and
> cgroups, you will need to do this along side the Go process (unless you
> have root access to the server).
>
> I 'think' depending on kernel version, that kernel memory used goes
> against the process for OOM purposes, so this is a likely candidate if
> pprof is showing nothing.
>
> Do you by chance do any of your own memory management (via malloc/CGO)? If
> so, this is not going to show in pprof either.
>
> -Original Message-
> From: 'Yunchi Luo' via golang-nuts
> Sent: Jul 1, 2019 4:26 PM
> To: Robert Engels
> Cc: golang-nuts@googlegroups.com, Alec Thomas
> Subject: Re: [go-nuts] OOM occurring with a small heap
>
> I actually have a heap profile (pasted at the bottom) from about 1 second
> before the service died (the goroutine that is logging "[Memory]" triggers
> heap profiles once RSS > 100MB). I don't see TCP connections there. Maybe
> it's too few to be sampled. How would I verify your theory? That the
> service dies within 2 seconds after several hours makes it very hard to
> debug.
>
> The top thing in the heap profile is from the reflect package. I initially
> found that suspect, but it turns out this comes from a use of
> httptrace.ClientTrace I had for counting new connections to DynamoDB.
>
>  tracer := &httptrace.ClientTrace{
>ConnectStart: func(_, _ string) {
>  newConns.Inc()
>},
> }
>
> `newConns` is just a prometheus counter. The `tracer` object itself is
> created once and re-used with every client request context. On request,
> `httptrace.WithClientTrace(ctx, tracer)` uses reflection to compose the
> trace functions under-the-hood and uses reflection to invoke it, hence the
> reflect.funcLayout and reflect.Value.call. Objects in `reflect` account for
> about 50% of heap in terms of size, and does seem to grow as the service is
> running out of memory, but that's only 12MB so I thought it was a red
> herring.
>
> Heap profile:
> Type: inuse_space
> Time: Jun 30, 2019 at 4:46am (EDT)
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) inuse_objects
> (pprof) top
> Showing nodes accounting for 414485, 100% of 414485 total
> Showing top 10 nodes out of 81
>   flat  flat%   sum%cum   cum%
> 344074 83.01% 83.01% 344074 83.01%  reflect.funcLayout.func1
>  32768  7.91% 90.92% 376842 90.92%  reflect.callReflect
>  16384  3.95% 94.87%  16384  3.95%
> github.com/json-iterator/go.processTags
>  10923  2.64% 97.51%  10923  2.64%  context.WithValue
>   8192  1.98% 99.48%   8192  1.98%  crypto/hmac.New
>   1260   0.3% 99.79%   1260   0.3%
> github.com/aws/aws-sdk-go/aws/signer/v4.(*signingCtx).buildCanonicalHeaders
>820   0.2%   100%820   0.2%
> github.com/stripe/veneur/tdigest.NewMerging
> 64 0.015%   100% 

Re: [go-nuts] OOM occurring with a small heap

[Michael Jones]

Does adding runtime.GoSched() calls make any difference?

On Mon, Jul 1, 2019 at 5:37 PM 'Yunchi Luo' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Following that logic, a leak of TCP connections should manifest as a file
> descriptor leak. We have the process_open_fds metric from Prometheus, that
> is the number of open file descriptors as found in /proc//fd. The
> number of descriptors overtime correlates well with the amount of traffic,
> pretty cyclic. There doesn't appear to be a leak.
>
> We don't do our own memory management and the binary is compiled with
> CGO_ENABLED=0.
>
> I still think the issue I'm seeing should be GC (or heap) related, given
> the explosion in mark & sweep time, HeapSys, HeapIdle, and HeapReleased
> just before the process dies. But I'm lacking ideas on how to track down
> the cause of the increase.
>
> On Mon, Jul 1, 2019 at 5:39 PM Robert Engels 
> wrote:
>
>> I think don't think you are going to find it in the 'heap', rather it
>> would be in native memory.
>>
>> I would use the monitor the /proc/[pid] for the process, and pay
>> attention to the 'fd','net' and 'statm' - if my theory is correct you will
>> see growth here long before the process is killed. Since you are running
>> under k8s and cgroups, you will need to do this along side the Go process
>> (unless you have root access to the server).
>>
>> I 'think' depending on kernel version, that kernel memory used goes
>> against the process for OOM purposes, so this is a likely candidate if
>> pprof is showing nothing.
>>
>> Do you by chance do any of your own memory management (via malloc/CGO)?
>> If so, this is not going to show in pprof either.
>>
>> -Original Message-
>> From: 'Yunchi Luo' via golang-nuts
>> Sent: Jul 1, 2019 4:26 PM
>> To: Robert Engels
>> Cc: golang-nuts@googlegroups.com, Alec Thomas
>> Subject: Re: [go-nuts] OOM occurring with a small heap
>>
>> I actually have a heap profile (pasted at the bottom) from about 1 second
>> before the service died (the goroutine that is logging "[Memory]" triggers
>> heap profiles once RSS > 100MB). I don't see TCP connections there. Maybe
>> it's too few to be sampled. How would I verify your theory? That the
>> service dies within 2 seconds after several hours makes it very hard to
>> debug.
>>
>> The top thing in the heap profile is from the reflect package. I
>> initially found that suspect, but it turns out this comes from a use of
>> httptrace.ClientTrace I had for counting new connections to DynamoDB.
>>
>>  tracer := &httptrace.ClientTrace{
>>ConnectStart: func(_, _ string) {
>>  newConns.Inc()
>>},
>> }
>>
>> `newConns` is just a prometheus counter. The `tracer` object itself is
>> created once and re-used with every client request context. On request,
>> `httptrace.WithClientTrace(ctx, tracer)` uses reflection to compose the
>> trace functions under-the-hood and uses reflection to invoke it, hence the
>> reflect.funcLayout and reflect.Value.call. Objects in `reflect` account for
>> about 50% of heap in terms of size, and does seem to grow as the service is
>> running out of memory, but that's only 12MB so I thought it was a red
>> herring.
>>
>> Heap profile:
>> Type: inuse_space
>> Time: Jun 30, 2019 at 4:46am (EDT)
>> Entering interactive mode (type "help" for commands, "o" for options)
>> (pprof) inuse_objects
>> (pprof) top
>> Showing nodes accounting for 414485, 100% of 414485 total
>> Showing top 10 nodes out of 81
>>   flat  flat%   sum%cum   cum%
>> 344074 83.01% 83.01% 344074 83.01%  reflect.funcLayout.func1
>>  32768  7.91% 90.92% 376842 90.92%  reflect.callReflect
>>  16384  3.95% 94.87%  16384  3.95%
>> github.com/json-iterator/go.processTags
>>  10923  2.64% 97.51%  10923  2.64%  context.WithValue
>>   8192  1.98% 99.48%   8192  1.98%  crypto/hmac.New
>>   1260   0.3% 99.79%   1260   0.3%
>> github.com/aws/aws-sdk-go/aws/signer/v4.(*signingCtx).buildCanonicalHeaders
>>820   0.2%   100%820   0.2%
>> github.com/stripe/veneur/tdigest.NewMerging
>> 64 0.015%   100% 64 0.015%  reflect.addReflectOff
>>  0 0%   100%820   0.2%
>> git.sqcorp.co/cash/digester/lib/pkg/histogram.(*SlidingWindowDigest).Observe
>>  0 0%   100%820   0.2%
>> git.sqcorp.co/cash/digester/lib/pkg/histogram.(*SlidingWindowDigest).openDigests
>> (pprof) cum
>> (pprof) top
>> Showing nodes accounting for 376842, 90.92% of 414485 total
>> Showing top 10 nodes out of 81
>>   flat  flat%   sum%cum   cum%
>>  0 0% 0% 376842 90.92%
>>  net/http/httptrace.(*ClientTrace).compose.func1
>>  0 0% 0% 376842 90.92%  reflect.Value.Call
>>  0 0% 0% 376842 90.92%  reflect.Value.call
>>  32768  7.91%  7.91% 376842 90.92%  reflect.callReflect
>>  0 0%  7.91% 376842 90.92%  reflect.makeFuncStub
>> 344074 83.01% 90.92% 344074 83.01%  r

[go-nuts] Counter-counter-counter proposals

[Michael Jones]

With so many strongly worded emotional emails flying it might be helpful to
remember that language design is about other people and other use cases
than your own. The truly good answer meets the needs of many and harms few,
anticipates that no answer is final, and is flexible. Here is a nice way to
think about it:

Taste and Aesthetics, A Conversation with Ken Arnold, Part II
by Bill Venners, September 16, 2002
https://www.artima.com/intv/taste.html


Responsibility for others means focusing on issues beyond your own. As CTO
of Google Maps, Earth, and Local Search, I had to think about what was good
for 1.5 billion unique monthly users, not what was good to me as a map guy.
The Go designers are in the same situation. When we offer advice to them,
we might best think that way too.

-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQze-1ZuY5NTijiTmrpzbnbRzUT_kKD88s0XBzNHzqHjdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Michael Jones]

It seems to me that the try() mechanism could easily be undone by gofmt.
That is, if it does not work out it could be changed with low pain. This is
a virtue. Maybe the lesson is lost on some, but Go 1.0 was incompatible
with primordial Go and the Go team provided GoFix to mutate code. That was
beautiful to me. Any new idea that seems promising but could be undone
automatically if necessary is not risky.

On Sun, Jun 30, 2019 at 6:19 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> On Sat, Jun 29, 2019 at 9:30 PM Henrik Johansson 
> wrote:
>
>>
>> I have a feeling that there is a quite large "silent majority" that
>> pretty much agrees with me.
>>
>>
> Go is a language with the following properties, among other things:
>
> * Massive concurrency through a high amount of gorutines
> * Identity of channels, but not goroutines (goroutines don't have a Pid by
> construction, channels do have identity)
> * Shared memory space among the goroutines
>
> Such a language has a subtle property as an implication: cleanup of a
> failure must happen in the goroutine which made it. That is, error handling
> must be localized. As a result, error handling is mostly a game of treating
> it as data-flow in the program, where errors are values.
>
> There is a common case in such data flow. If an error occurs, we want to
> just return that error. This is where the try-construct will definitely
> improve the ergonomics of the programming. Go is a fairly small language.
> Certainly smaller than e.g., Javascript or Typescript. So I don't think we
> are adding that much cognitive load on people with a specialized
> construction. Of course YMMV... Haskell or OCaml programmers would just
> define a monad and call it a day, heh.
>
>
>
>
> --
> 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/CAGrdgiVU42ep%2BzJFUHc8FiZ_yQWrw2YOTCJEjMbLkyiFeC_C%3DA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQx3fY2CdaNGn41bOB50ESqxQ551HKTmeYM48o8gNscm9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] YAEHI (Yet another error-handling idea)

[Michael Jones]

My personal thought, though it may seem strange, is that the best argument
for it lies in the single word sentence at the bottom of your email. You
write "Thoughts?" -- and that is very expressive in English in just the way
that you mean above in your examples. I don't know enough other languages
to really know if the parallels are universal, but it's pretty clear to me
what it means why "file?.close()" and "os.Open(filename)?" are "punctuated"
as they are -- where the question is. I feel like you're asking this
compiler, "is there anything about this value that you need to tell me?" I
like that.

The long (crazy long!) discussion of error handling has among its many
branches an analysis from the Go team about '?' and this kind of postfix
interrogation. I'm watching it all with a bit of wonder, but I wanted to
speak up and say how your human-language phrasing matches your idea of
computer-language phrasing. That seems a powerful kind of naturalness to
take advantage of in this issue and future ones.

On Sat, Jun 29, 2019 at 2:56 PM Andrey Tcherepanov <
xnow4fippy...@sneakemail.com> wrote:

> Hello mighty fighters of errors!
>
> Here comes my half-thought idea of another way to express error handling:
>
> *Add a postfix '?' that checks value for **emptiness (nil, 0, "") **AND
> an error for nil. *
>
> (Denis have shred it to pieces already in
> https://github.com/golang/go/issues/32852. Thank you Denis.)
>
> I am not good with expressing my inner talk, so there are couple examples
>
> original , Go 1 function
>
> func stat(filename string) (os.FileInfo, error) {
>
> var info os.FileInfo
> {
> var a1 *os.File
> if a1, err := os.Open(filename); err != nil || a1 == nil {
> return _, err
> }
> var a2 os.FileInfo
> if a2, err := a1.Stat(); err != nil || a2 == nil {
> return _, err
> }
> info = a2
> }
> return info, nil
> }
>
>
> And with "?", trying to avoid original try() proposal handle leak
>
> // would return _, err, but since there is no err in signature, will return 
> default value in case of error
> // uses ? on func call that returns (value, error)
> func stat2(filename string) (os.FileInfo) {
>  file := os.Open(filename)?
>  defer file.Close()
>  return file.Stat()?
> }
> // would return error too, uses ? as "not nil" on a variable too
> func stat3(filename string) (_ os.FileInfo, err error) {
>  var file *os.File
>  defer file?.Close()
>  file := os.Open(filename)?
>  return file.Stat()
> }
>
>
> Thoughts?
>
> --
> 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/b7520ffe-ec38-4157-8f95-92844dcb0d0f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQzmBveHCvSDtdZY8Et1xgvuL0N-xwcNXJ5PfUeXa6CVFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Go language survey tool

[Michael Jones]

Announcing *Survey*, a general purpose utility that may be of interest to
those curious about how how the Go language is used at a token level. When
I posted a survey of the Go 1.13 source tree and of the Go Corpus a week
ago, several people wrote and asked that I share. The program at that time
was just part of my test suite for a lexer so it was far from ready to
share; it's now ready and available:

https://github.com/MichaelTJones/survey

When you get that it will also get (or you will need to get)

https://github.com/MichaelTJones/lex

which is much like scanner but knows about Go operators and is careful to
note details of what it parses (not "number" but "number/of the legacy
octal form"). I'm still working on that but it suffices for the needs of
survey.

Hope it is helpful to you.

-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQyHjc3tG0deRNAUmWpAGL4pyq1D5RocdUjd2E4JMToFQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The Seven Finest Go Books (to popularize and 'socialize' Go).

[Michael Jones]

Agree about Lisp (and in same way, Forth and J etc.). About the book I
recommended, it is a missionary book; one of the Bell Labs diaspora on the
topic of why people like UNIX so much, what's not so obvious about
programming (that it is really about people more than machines), and a
point of view by Rob on things like simplicity, testing, and other "above
the language level" topics. I don't want to give it all away, but if the
people who were in anyway associated with this book had formed a "gang" and
written a language to implement the ideas...

On Fri, Jun 21, 2019 at 7:01 AM Akram Ahmad  wrote:

> While I've heard great things about Pike and Kernighan’s *The Practice of
> Programming*, that is one book I have not got around to picking up;
> clearly, you think highly of it, so I'm going to check it out, thanks for
> the pointer! Does it address some of the same areas as, say, *The
> Pragmatic Programmer: From Journeyman to Master* by Andy Hunt and Dave
> Thomas and/or *The Art Of UNIX Programming: The Cathedral and the Bazaar*
> by Eric Raymond?
>
> Speaking of the amazing programmer that Eric Raymond is, he has made an
> observation of which I'm reminded by your thoughtful comment. Thus, and as
> I had mentioned many moons ago in my Clojure write-up
> <https://programming-digressions.com/2015/08/best-clojure-books.html>, he
> has pointedly noted that "*Lisp is worth learning for the profound
> enlightenment experience you will have when you finally get it; that
> experience will make you a better programmer for the rest of your days,
> even if you never actually use Lisp itself a lot.*"
>
>  ~Akram
>
> On Thursday, June 20, 2019 at 6:12:51 PM UTC-5, Michael Jones wrote:
>>
>> There is a marvelous book that is about Go in a magical way...it explains
>> and teaches Go’s personality and attitude...from before Go was born. Read
>> Rob Pike and Brian Kernighan’s “The Practice of Programming.” After reading
>> it carefully you will understand Go in a deeper way than would otherwise be
>> possible. If you have a detective-like personally, study the author’s
>> credits for who advised them. You’ll think it was the “most frequent poster
>> ranking” for this mailing list... even though this all happened beforehand.
>>
>> You’ll also become a better programmer. Truly.
>>
>> On Thu, Jun 20, 2019 at 9:55 AM Aman Alam  wrote:
>>
>>> Hi Rog,
>>>
>>> Are there any plans to make this book available for Kindle, or in PDF,
>>> please?
>>>
>>> Regards,
>>> Aman
>>>
>>> On Friday, February 22, 2019 at 4:29:29 AM UTC-5, rog wrote:
>>>>
>>>> You might want to take a look at Manning's "Get Programming With Go"
>>>> too; it's aimed mostly at more inexperienced programmers.
>>>>
>>>> https://www.amazon.com/Get-Programming-Go-Nathan-Youngman/dp/1617293091
>>>>
>>>> (disclosure: I'm one of the authors :])
>>>>
>>>>
>>>> On Thu, 21 Feb 2019 at 23:02, Akram Ahmad  wrote:
>>>>
>>>>>
>>>>>- The amazing language that golang surely is, and how refreshingly
>>>>>(and elegantly) simple a language golang is—take this from someone 
>>>>> coming
>>>>>from extensive experience in Java and Scala, two language which
>>>>>well-deservedly have a lot going for them—I think we need to do
>>>>>*more* to popularize (and 'socialize') the promise of golang to
>>>>>the larger community of programmers.
>>>>>- To that end, I put together and recently posted a (fairly)
>>>>>detailed blog post: *Best Go Programming Books (2019)
>>>>>
>>>>> <https://programming-digressions.com/2019/02/17/best-go-programming-books-2019/>*
>>>>>.
>>>>>- Earlier posts (at least on golang) include the following two: *The
>>>>>Go Programming Language
>>>>>
>>>>> <https://programming-digressions.com/2018/04/09/the-go-programming-language/>*
>>>>>and *Further Adventures In Go Land
>>>>>
>>>>> <https://programming-digressions.com/2018/08/26/further-adventures-in-go-land/>*
>>>>>.
>>>>>
>>>>> Go golang!
>>>>>
>>>>> Warm Regards to fellow gophers, hibernating or otherwise :)
>>>>>
>>>>>  ~Akram <https://github.com/akramtexas>
>>>>>
>>&g

Re: [go-nuts] The Seven Finest Go Books (to popularize and 'socialize' Go).

[Michael Jones]

There is a marvelous book that is about Go in a magical way...it explains
and teaches Go’s personality and attitude...from before Go was born. Read
Rob Pike and Brian Kernighan’s “The Practice of Programming.” After reading
it carefully you will understand Go in a deeper way than would otherwise be
possible. If you have a detective-like personally, study the author’s
credits for who advised them. You’ll think it was the “most frequent poster
ranking” for this mailing list... even though this all happened beforehand.

You’ll also become a better programmer. Truly.

On Thu, Jun 20, 2019 at 9:55 AM Aman Alam  wrote:

> Hi Rog,
>
> Are there any plans to make this book available for Kindle, or in PDF,
> please?
>
> Regards,
> Aman
>
> On Friday, February 22, 2019 at 4:29:29 AM UTC-5, rog wrote:
>>
>> You might want to take a look at Manning's "Get Programming With Go" too;
>> it's aimed mostly at more inexperienced programmers.
>>
>> https://www.amazon.com/Get-Programming-Go-Nathan-Youngman/dp/1617293091
>>
>> (disclosure: I'm one of the authors :])
>>
>>
>> On Thu, 21 Feb 2019 at 23:02, Akram Ahmad  wrote:
>>
>>>
>>>- The amazing language that golang surely is, and how refreshingly
>>>(and elegantly) simple a language golang is—take this from someone coming
>>>from extensive experience in Java and Scala, two language which
>>>well-deservedly have a lot going for them—I think we need to do
>>>*more* to popularize (and 'socialize') the promise of golang to the
>>>larger community of programmers.
>>>- To that end, I put together and recently posted a (fairly)
>>>detailed blog post: *Best Go Programming Books (2019)
>>>
>>> *
>>>.
>>>- Earlier posts (at least on golang) include the following two: *The
>>>Go Programming Language
>>>
>>> *
>>>and *Further Adventures In Go Land
>>>
>>> *
>>>.
>>>
>>> Go golang!
>>>
>>> Warm Regards to fellow gophers, hibernating or otherwise :)
>>>
>>>  ~Akram 
>>>
>>> --
>>> 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.
>>> 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/b8afaf18-d05d-4b5d-8ca7-306a41f76555%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQyDBe5JSjXV4U%3DUYpKSG_NEm0sKb%3DdBaiU3OH%3D609BOZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is there a goroutine scope global veriable ?

[Michael Jones]

For the OP:

A thought to share on the general topic: Go is pioneering a sufficiently
different model of concurrent computation that it may not make much sense
to ask for or seek equivalencies with classic thread/process models.

This says nothing against the standard model, nor against the “missing”
services; it is a note to encourage design in Go along with coding in Go,
instead of design in C/C++/Java/POSIX/... and a best-effort realization in
Go.

By way of analogy, I’ve long been involved in boat design and construction.
We always use a pair Furuno or Simrad RADAR antennas, one of long range and
one short, to optimize object detection/clutter rejection and as a
redundancy safety factor. However, when sailing on a HobeeCat, i’ve never
looked for nor missed the Radar or any other instruments of navigation. A
HobieCat is just such a different idea of sailing that *all* the normal
mechanisms have no place.  There is no “where do I stow the anchor” or
“where do I control the RAM signal lights.” There are whole chapters of the
USCG instructions (ColRegs) where the thing discussed is not on a HobeeCat.
That does not make such boats inadequate; it makes them fun.

If you can stop thinking of concurrency in Go as a small group of
exquisitely instrumented machines and instead imagine a swarm of ants,
you’ll find new and interesting ways to solve problems. They often work
even better, and are also more fun.

On Wed, Jun 19, 2019 at 9:37 AM Robert Engels  wrote:

> Side-managed thread/execution context has been around since the concept of
> a thread. It is highly useful, and is more robust and secure than a Context
> object passed among methods.
>
> If Go had any concept of a "secure runtime" it would be essential, but it
> doesn't, so you make do with what you have.
>
>
> -Original Message-
> From: jake6...@gmail.com
> Sent: Jun 19, 2019 11:08 AM
> To: golang-nuts
> Subject: [go-nuts] Re: is there a goroutine scope global veriable ?
>
> This has been discussed many times before. Searching "local storage" on
> this group brings up many discussions, including:
>
> https://groups.google.com/d/topic/golang-nuts/Nt0hVV_nqHE/discussion
> https://groups.google.com/d/topic/golang-nuts/_Vv7Bzn8yH4/discussion
> https://groups.google.com/d/topic/golang-nuts/zuWWBHKn6iw/discussion
>
> My take is that GLS could be genuinely useful in a few cases, but would
> undoubtedly lead to abuse in most cases. In the vast majority of
> situations, what you really want to track, or log, is the specific work
> being done, not actually which goroutine it happens to be running on. For
> example, tracking a specific request, etc. My advice is to pass around a
> context, or some other identifying information about the specific work
> being done. At first this will seem tedious and annoying, but you will
> likely get used to it.
>
>
> On Tuesday, June 18, 2019 at 10:59:09 PM UTC-4, hui zhang wrote:
>>
>> is there a goroutine scope global veriable ?
>> like  fork a variable from main ?
>>
> --
> 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/53512dd1-8c24-460d-9bf5-646ea1e95d0f%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/1187971360.3926.1560962237733%40wamui-berry.atl.sa.earthlink.net
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQy_p7hs%3DxrWGFx65r7xb63wGi_dg6aL6PRFfG7%2BwFP7-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Michael Jones]

Volker, the answer to the balance question. My formatting is that "«balance
(2:1) [0:0] {1:0}»" gives the number of left and right parenthesis, lefdt
and right brackets, and left and right braces in using
":":

2019/06/16 17:57:59.844755 files that failed the Go lexical scan:
2019/06/16 17:57:59.844763   bad /Users/mtj/go/test/fixedbugs/bug435.go
«balance (2:1) [0:0] {1:0}»
2019/06/16 17:57:59.844770   bad /Users/mtj/go/test/fixedbugs/issue13248.go
«balance (2:1) [0:0] {1:1}»
2019/06/16 17:57:59.844777   bad /Users/mtj/go/test/fixedbugs/issue13274.go
«balance (1:1) [0:0] {1:0}»
2019/06/16 17:57:59.844784   bad /Users/mtj/go/test/fixedbugs/issue13319.go
«balance (6:4) [0:0] {2:2}»
2019/06/16 17:57:59.844791   bad /Users/mtj/go/test/fixedbugs/issue15611.go
«balance (1:0) [0:0] {0:0}»
2019/06/16 17:57:59.844798   bad /Users/mtj/go/test/fixedbugs/issue17328.go
«balance (1:2) [0:0] {2:2}»
2019/06/16 17:57:59.844805   bad /Users/mtj/go/test/fixedbugs/issue18092.go
«balance (1:1) [0:0] {3:2}»
2019/06/16 17:57:59.844813   bad /Users/mtj/go/test/fixedbugs/issue19667.go
«balance (2:1) [0:0] {1:1}»
2019/06/16 17:57:59.844820   bad /Users/mtj/go/test/fixedbugs/issue20789.go
«balance (1:1) [2:0] {1:0}»
2019/06/16 17:57:59.844827   bad /Users/mtj/go/test/fixedbugs/issue22164.go
«balance (8:6) [1:1] {5:4}»
2019/06/16 17:57:59.844834   bad /Users/mtj/go/test/fixedbugs/issue22581.go
«balance (7:10) [0:3] {7:7}»
2019/06/16 17:57:59.844842   bad /Users/mtj/go/test/syntax/semi1.go
«balance (1:1) [0:0] {2:0}»
2019/06/16 17:57:59.844850   bad /Users/mtj/go/test/syntax/semi2.go
«balance (1:1) [0:0] {2:0}»
2019/06/16 17:57:59.844857   bad /Users/mtj/go/test/syntax/semi3.go
«balance (1:1) [0:0] {2:0}»
2019/06/16 17:57:59.844864   bad /Users/mtj/go/test/syntax/semi4.go
«balance (1:1) [0:0] {2:0}»
2019/06/16 17:57:59.844871   bad /Users/mtj/go/test/syntax/semi5.go
«balance (1:1) [0:0] {1:0}»
2019/06/16 17:57:59.844879   bad /Users/mtj/go/test/syntax/vareq.go
«balance (1:1) [1:1] {2:1}»

On Thu, Jun 13, 2019 at 12:00 AM Michael Jones 
wrote:

> 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% | :=
>>>

Re: [go-nuts] Newbie question on slice bound checking

[Michael Jones]

It has been, yes, and unless it changed in the last few weeks, it still is.

I use to to measure cost as an awareness metric, but seldom run that way.
Go is safe until you do that, then it becomes unsafe. Too risky for serious
use.

On Sun, Jun 16, 2019 at 4:53 AM Ugorji Nwoke  wrote:

> I know this is an old thread, but is -B still supported?
>
>
> On Monday, August 27, 2012 at 2:09:19 AM UTC-4, minux wrote:
>>
>>
>> On Monday, August 27, 2012, bluehorn wrote:
>>>
>>> Is "-gcflags -B" still supported in go1.0.2?  I suppose it was gone
>>> already.
>>>
>> It is still there.
>>
> --
> 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/397c0824-b5b5-412d-974e-b53f56d29a82%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQzeLSEOUFo9wYC52gFGyfv1rfmtUZm1PPHw-MMx1XtT_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[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

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

[Michael Jones]

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

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 golang-nuts+unsubscr...@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
>> <https://groups.google.com/d/msgid/golang-nuts/1a0e2b4b-9276-4418-929c-51888cf2c93a%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQw%2BWmrgRWofpcRdAWxzyPg0qYbLNSn5Vt-c1JYJ75dJdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Michael Jones]

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 golang-nuts+unsubscr...@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
> <https://groups.google.com/d/msgid/golang-nuts/1a0e2b4b-9276-4418-929c-51888cf2c93a%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CALoEmQw3S8TpL9nnqT7yxwRJ%3DOBb3mj4YP_iGJEfUtJqQNx14A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[Michael Jones]

Roger, here's the same thing, but for Russ's corpus v0.01:

https://gist.github.com/MichaelTJones/609589e05017da4be52bc2810e9df4e8

I've been comparing the two side by side and it's fascinating.

Bakul, more good arguments. I have another motivation in the "?" world that
I've not argued because it is personal/not general, but a decade ago I had
two detached retinas, surgeries, and imperfect recovery. Part of my vision
that I lost is just below the center...maybe -15 degrees to -40 degrees.
The brain knows when I want to see things things there and moves the eyes
around to gather that part of the visual field. This "hunting" is tiring of
the muscles and causes issues. left-to-right density is easy for me,
vertical is very bad. Your:

x := b? 2 : 1

is instantaneous, a sight read; while the:

var x int
if b {
  x = 2
} else {
  x = 1
}

and

x := 1
if b {
  x = 2
}

...feel like climbing Everest. It is hard to explain the difficulty.
Fortunately it is not a widespread problem. Certainly not Go's problem, but
I'd pay double for a "wide" mode where gofmt tolerated "var x int; if b { x
= 2 } else { x = 1 }". In fact, now that i've just seen this, I am going to
make a local version and hook it to vs code. Why did I not think of this
before! Wow.

On Wed, Jun 12, 2019 at 9:24 AM Bakul Shah  wrote:

> On Jun 12, 2019, at 8:24 AM, Michael Jones 
> wrote:
> >
> > Bakul, these are good points.
> >
> > On the second, I used to always write (C/C++):
> >
> > If (things are good) {
> > happy case
> > } else {
> > sad case
> > }
> >
> > so the nesting was that the all-good was the first code block even when
> multiply nested and the exceptions came later. A blunt kind of literate
> programming that wants to talk about the 99% case first and the weird
> things later. In Go I've converted to talk about problems all the way to
> the bitter end and then when you run out of problems, do the job. Now that
> you point it out, "else" falls by the wayside in this situation because it
> is else when you did not return already. Each Go-style if-err-die "clause"
> is consuming an else. Thank you. I had not thought of it so clearly.
>
> It's just a different style. Here you are chopping off "sad cases" until
> you are left with the big fat happy case! And by returning ASAP for the
> sad cases, you reduce indentation quite a bit, which helps readability.
>
> >
> > The first is a good point too. The debate about the ternary operator
> might be better viewed as a completion of short variable declaration. Block
> scope means is not possible to write...
> >
> > if b {
> > x := 1
> > } else {
> > x := 2
> > }
> > :
> > use X
> >
> > ...so the benefits of short variable declaration are lost to a choice
> between redundancy as you show:
> >
> > x := 1
> > if b {
> > x = 2
> > }
> >
> > which hides the intent -- the if b is the intent and that's not evident
> from x := 1. The intent is "x := either 1 or 2 depending" and that is well
> expressible only when the := is in the outer scope and the "1 or 2" are
> expressions from an inner one being transported across the lexical boundary
> by an operator -- the "depending" operator whatever its name or form might
> be.
>
> You can almost speed-read straight line code but as soon as you
> encounter if or switch (or other control flow changing part) you
> have to stop and regroup. This is why (for me)
>
> x := b? 2 : 1
>
> is far easier to read than either
>
> var x int
> if b {
>   x = 2
> } else {
>   x = 1
> }
>
> or worse,
>
> x := 1
> if b {
>   x = 2
> }
>
>
> > x := {1,2}[b]
>
> This requires evaluating both alternatives. This may not
> even be possible:
>
> x := p == nil? 10 : p.val
>
> or may had extra side-effects:
>
> x := {f1(), f2()}[b]
>
> This can also a problem with
>
> x := f1()
> if b { x = f2() }
>
>
>
>

-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQw10H-t1GdVG_PDxiPVtaUGJ3uvsBUXyt6adMiPOAAnow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[Michael Jones]

Bakul, these are good points.

On the second, I used to always write (C/C++):

If (things are good) {
happy case
} else {
sad case
}


so the nesting was that the all-good was the first code block even when
multiply nested and the exceptions came later. A blunt kind of literate
programming that wants to talk about the 99% case first and the weird
things later. In Go I've converted to talk about problems all the way to
the bitter end and then when you run out of problems, do the job. Now that
you point it out, "else" falls by the wayside in this situation because it
is else when you did not return already. Each Go-style if-err-die "clause"
is consuming an else. Thank you. I had not thought of it so clearly.

The first is a good point too. The debate about the ternary operator might
be better viewed as a *completion* of short variable declaration. Block
scope means is not possible to write...

if b {
x := 1
} else {
x := 2
}
:
use X

...so the benefits of short variable declaration are lost to a choice
between redundancy as you show:

x := 1
if b {
x = 2
}

which hides the intent -- the if b is the intent and that's not evident
from x := 1. The intent is "x := either 1 or 2 depending" and that is well
expressible only when the := is in the outer scope and the "1 or 2" are
expressions from an inner one being transported across the lexical boundary
by an operator -- the "depending" operator whatever its name or form might
be.

The pro-? forces might better petition under the "make short assignments
complete" banner.

x := if b {1} else {2}
x := switch b {case true: 1; case false: 2}
x := b ? 1 : 2

or, my dream scenario, which is just a dream because of too many moving
parts to sell all at once:

allow bool to int/uint casting with obvious meaning T=>1, F=>0
allow "implicit" types in literal definitions like this:

x := {1,2}[int(b)]

...or even if one could dare hope for automatic coercion of the harmless
bool...

x := {1,2}[b]

as in

workers := {runtime.NumCPU(),1}[*ParallelMode]

...oh to dream.



On Wed, Jun 12, 2019 at 7:56 AM Bakul Shah  wrote:

> On Jun 12, 2019, at 7:36 AM, Michael Jones 
> wrote:
> >
> > 128640 If statements, and just 8034 else, a 16:1 ratio. I'd like to
> understand this better,
>
> There are two patterns that encourage this:
>
> x := v1
> if someCond { x = v2 }
>
> And
>
> if someCond { return ... }
>
> The second pattern acts sort of as a filter. Which is useful (fewer
> choices left).
>
> The first pattern is due to a lack of C’s ?: construct. [In light of that
> it is amusing to see try as a “function” being proposed that even does a
> conditional return!]
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQw5xCLMFj2k9exBBuvr0SBL2zifZoUER0tmiViyGWJt0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[Michael Jones]

Yes, quite a bit there of note:

More hex numbers than decimal. That was a surprise.

The "0o" prefixed octal number literals just went in in the last two days.
I think a gofix rewrite might be in order--it is more explicit and less
vulnerable to mistake than the legacy 0377 style--despite a whole career of
the other from the PDP-8 onward.

128640 If statements, and just 8034 else, a 16:1 ratio. I'd like to
understand this better, but my test is just a lexer and not a parser so I
don't have much context to draw conclusions about this specifically.
However it seems such a huge ratio that switch must be carrying the load.
There are 5024 switch statements and 24903 cases, so that's "4 virtual
elses" per switch in some broad sense.

Type is well used. 2x as much as struct, so even if half are "type X struct
{...}" the other half are not.

The import frequency is not interpretable beyond "every package imports
something" because of the inner list in imports as typically written and
that's available to a parser but not at the lexical level. I could hack it
to look at lines between the parens after import, but that's beyond the
"test the lexer" goal.

The default to switch ratio is high, and there is at most one per, so this
means 60% of switch statements have a default, or by extension, express
if-then-else if-else-if-else logic with a final clauseless else.

Few fallthrough statements and that's natural. There were few cases outside
Duff's Device where C/C++ code is allowed to fall through by default.
[Having just written a lexer, I can share that would I think be much better
than the switch's fallthrough would be a way to say, "now that I'm in this
case, I've changed my mind and want to PROCEED with the case testing
starting with the next case." That would be swell and there is no way to do
it.)

Byte by that name is quite popular compared to its other identity, uint8.
[Opinion: never have been comfortable about this one. There are no living
machines with non 8-bit bytes, so the generality of "byte is the natural
size for a byte" is a stretch here, as would be 1 for the size of a bit.]

Using true is almost 3x false. I wonder if that is natural or if the
default value of zero/false is behind it.

Lots of panics and not many recovers.

Operators are interesting. nearly 2.5x the != than ==. Perhaps "err != nil"
is the story. A lot more < than >, which is curious...presumably from for
loops, but can't tell at the token level. Way more left shifts than right.
Not true in my own code, so interesting. Some disjunctive/conjunctive
dissonance: 3x the && as ||. 7 x the ++ as --. I guess people like to count
up, even when counting down has the advantage of the expensive load being
done once and the test being against zero. 5x += than -=, surprising.
Pretty low incidence of &^ and &^=, not true in my code at all, so I
suppose the BIC "Bit Clear" of PDP-11 is not a meme. That's surprising to
me: a|=b, sets the b bits in a, a&^b, clears the b bits in a. They are a
team, yet | is  50x the usage of &^. Maybe because C did not have it and
C++ copied and Java copied and people have not understood? These should be
peers. /= is not popular, and %= even less so. I use them both but I may be
the only one (there is some code like this in Big from way back.)

External references shows that the Go team writes lots of tests, and that
unsafe is wildly popular.

The most popular character constant is '0' 3x '9' so it's not all ('0' <=
ch && ch <= '9') ... there are some extra '0's in there.

On Wed, Jun 12, 2019 at 6:49 AM Ian Lance Taylor  wrote:

> On Wed, Jun 12, 2019 at 6:08 AM 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
>
> Pretty interesting.  Thanks.
>
> I no

[go-nuts] Go Language Survey

[Michael Jones]

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. jonesmichael.jo...@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-nuts/CALoEmQzK3v4V%2BRYWZorfX0Nst%2BOXwzP9e51mCDm2ri-4jfzXyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Allow methods on primitives

[Michael Jones]

The Go2 proposal process is open minded. Suggest that every well-considered
suggestion be made. Personally, I’m no fan of idiomatic as an argument, it
seems more of a consequence—like bare earth paths worn through grassy
parks—when the paved sidewalks are in the wrong place, the idiomatic path
goes off-road. When there are guardrails preventing that, the idiomatic
path is wrong, just the closest allowed fit. Go2 is the time to ignore the
rails.

I miss discriminated unions too. (Fancy new name, “sum types”). People like
enumerations. There are many odd to Go things that if added, would quickly
become second nature: letting += and * etc apply to arrays and slices would
be natural, smoothly integrate the myriad ugly named vector operations, and
make such code 2x, 4x, 8x faster. It would be a shame to hold back
suggesting it because “operators on non-primitive types are disallowed.”

Be bold. I’m saying this because in reading this thread I think my comment
about hard-won lessons may have come across wrong. It is not that Go is
perfect and should not be changed, more (to me) like Go’s omissions tend to
me much more strategic than people recognize, so the way to add the benefit
that’s missing is not usually to add the feature with that benefit from
other languages. That should motivate new ways, not shut down changes. But
those new ways require free thinking.

On Sun, Jun 9, 2019 at 1:00 PM Steven Blenkinsop 
wrote:

> If one library defines string.Render() for html, and another defines
>> another string.Render() for, say, a graphics library, which Render will be
>> called when I call "str".Render()?
>
>
> Method call syntax is the least of the worries. Presumably, that could be
> based on which packages are imported in the calling context, and you'd get
> an error if it's ambiguous. The larger problem is when you get interfaces
> involved. Two Content variables storing the same value of type string could
> have different implementations of Render depending on where the interface
> value was created. And if a variable v of type Content is used in a way
> equivalent to interface{}(v).(Content), you could end up changing the
> implementation of Render or failing the assertion altogether. So, the
> problem with allowing an arbitrary package to define methods on primitive
> types isn't with method call syntax, it's with using such methods to
> satisfy an interface like Content.
>
> One workaround would be to allow you to use package-qualified method
> names, so
>
> package foo
>
> type Content interface {
> package.Render()
> }
>
> func (s string) package.Render() { ... }
>
> At minimum, package-qualified methods defined in other packages couldn't
> be used to satisfy Content. Normal Render methods defined in other
> packages (for types which have to be defined in those packages) could be
> allowed to satisfy the interface, and/or other packages could be allowed to
> define methods like
>
> func (t T) foo.Render() { ... }
>
> for their own types to satisfy the interface.
>
> There hasn't been much interest in pursuing anything like this for Go,
> however. Something like the sum types mentioned by Bakul might be a better
> match for existing Go idioms, since it could be a swap-in replacement for
> interface{} in existing functions that use a type switch with an
> interface fallback, allowing them to better specify which types they
> support. Of course, there's also been opposition to adding sum types, since
> many see interfaces as "good enough" to cover the use cases of sum types.
>
> On Fri, Jun 7, 2019 at 3:00 PM Burak Serdar  wrote:
>
>> On Fri, Jun 7, 2019 at 12:40 PM Michael Ellis 
>> wrote:
>> >
>> > Count me among those who love the language just the way it is and
>> regard the prospect Go 2.0 with dread and loathing born of the Python 3
>> experience.
>> >
>> > That being said, there's one itty-bitty change I'd like to advocate:
>> Allow methods on primitives.
>> >
>> > I think I understand why allowing new methods on external packages is a
>> bad idea because it introduces a form of the fragile superclass problem.
>> But surely there's nothing fragile about strings, ints and floats.
>> >
>> > Being unable to define a method on a string is *not* a showstopper
>> since one can always do "type Foo string" or use type-assertions. It's just
>> that it's inelegant in the case of a function that takes a recursive struct
>> as an argument if the leaves of the tree are strings.  For example
>> >
>> > type HTMLTree struct {
>> > tag string
>> > attributes string
>> > content * Content //
>> > }
>> >
>> > type Content interface {
>> >Render()
>> > }
>> >
>> > // NOT ALLOWED
>> > func (s  string) Render() {
>> > }
>> >
>> > So I have to do something like
>> >
>> > type SC string
>> > func (s SC) Render() {
>> > }
>> >
>> > but that means instead of being able to write
>> >
>> > Div("", P("id=1", "When in the course of ..."))
>> >
>> > one must use the wrapper type on every content string.
>> >
>> 

Re: [go-nuts] Allow methods on primitives

[Michael Jones]

To emphasize the wisdom:

With an implicit conversion like you mentioned, the F(x) invocation at
the bottom expects B.SomeFunc() will be called but in fact,
A.SomeFunc() will be called. That's why this is an error. You can
still do F(A(x)), which explicitly makes a copy of x as an A.


This is not just a "Go style" issue, this is the result of distilling
lessons of millions of C++ developer's billions of hours of debugging and
large program / large team / long timeline development experience. Things
that are missing from Go, or restricted in Go, or even "adversarial" in Go
are there mostly because of hard-won experience. Many subtle design virtues
are what's missing as much as what's present.

On Sat, Jun 8, 2019 at 8:53 PM Burak Serdar  wrote:

> On Sat, Jun 8, 2019 at 3:22 PM Michael Ellis 
> wrote:
> >
> >
> > On Friday, June 7, 2019 at 3:01:04 PM UTC-4, Burak Serdar wrote:
> >>
> >>
> >> If one library defines string.Render() for html, and another defines
> >> another string.Render() for, say, a graphics library, which Render
> >> will be called when I call "str".Render()?
> >>
> > Thanks for the explanation. That makes sense.  Thinking it over, I'm
> wondering what would be required for the compiler to recognize synonyms of
> the form 'type Foo Bar' and allow passing a Foo for an argument of type
> Bar.  The compiler knows the expected type of each function argument so it
> seems as if checking to see if a passed argument is a simple synonym for
> the expected type and doing a coercion doesn't seem like a big task.  Note
> that this is different than asking for, say, numeric conversion from int to
> float64 because those types are not synonyms.  I actually like the fact
> that Go forces you to explicitly convert numeric types.
>
> If you have:
>
> type A int
> type B A
>
> then A and B are not synonyms, they are different types. Because of
> Go's  type system:
>
> func (a A) SomeFunc() {}
> func (b B) SomeFunc() {}
>
>
> func F(value A) {
>   value.SomeFunc()
> }
>
> x:=B{}
> F(x)
>
> With an implicit conversion like you mentioned, the F(x) invocation at
> the bottom expects B.SomeFunc() will be called but in fact,
> A.SomeFunc() will be called. That's why this is an error. You can
> still do F(A(x)), which explicitly makes a copy of x as an A.
>
> This is one of the reasons why it is so easy to read and write Go
> code. Most of the time you can comprehend the code with only local
> knowledge.
>
>
> >
> >
> > --
> > 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/aa26152a-fc5c-4048-9d30-446960df0ea9%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/CAMV2RqrLJOqhqsrBv4gK7FunSA4SLPNDr2y0xSB5dvyMs4q-Pg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQyO-SK38pLaH4u4qAWbKs5uU%3DaXE%3DH34Ab-tR-WvU2A7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: How to control go routine numbers in function call

[Michael Jones]

Here’s a helper...

https://github.com/korovkin/limiter/blob/master/README.md

You can do it using several other mechanisms as well.

On Fri, Jun 7, 2019 at 6:31 PM Joseph Wang  wrote:

> I mean at same time only 4 go routines run and then creat another 4 etc.
>
> On Fri, Jun 7, 2019 at 6:27 PM Joseph Wang  wrote:
>
>> Hi everyone
>>
>> I have a simple question about go routines.
>>
>> So I have a function like this
>>
>> Func1() {
>>
>>   for n := range array {
>> go fun2()
>>   }
>> }
>>
>> So as I can not make sure array has a fix size, then I cannot control go
>> routines number. Does any one have some elegant ways that I can limit this
>> function1 create fix number go routines?
>>
>> Best
>>
>> Joseph
>>
> --
> 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/CABp8xEnDcrNHhFO-DPrOOmXAy%2B%3DA04QVcgA%2B5E2DABn-B6dCpQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQywoNLe74s3s8qGBiACW4YJD-fq-maZZGutNUvjFH88GQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] There are post-quantum public key cryptograph in Go ? or binds to Go? Thanks.

[Michael Jones]

Your question is maybe a decade premature. Post-quantum cryptography, as
in, “now that quantum encryption is here and understood, we have tools to
build public key mechanisms provably safe for 50+ years in this
post-quantum environment,” is mostly a sentence from the future.

I have patents pending in related areas, have investments in a working
satellite-based quantum entanglement key distribution and security service,
and have had conversations with S&T leaders in a certain three letter
agency — but even so, it still feels like baby steps into a vast and not
yet understood frontier. Relatedly but different, I keep a database of
numbers factored publicly by quantum computers and keep tabs on the
subject...as of today, even the biggest of these are numbers Fermat could
have done by hand.

So, it will be interesting to see what kind of answers you get to your
question. If anyone has a solid, “yes I know just what to do” then bravo!
the world will beat a path to their door. (Beat here is in the metaphorical
sense of “blaze a trail through the jungle to reach you” as well as the
ominous “beat the answer out of you in the name of national security”
sense.)

On Fri, Jun 7, 2019 at 4:35 PM Daniel Norte Moraes 
wrote:

>HI!
>
>There are post-quantum public key cryptograph in Go ? or binds to Go?
>
>My need is just keys creation, encryption and decryption.
>
>
>Many Thanks in Advance!
>
>
> --
> 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/40279401-f23c-4960-a46a-95a0c6732049%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQw2iRK8%2BjKMstM%3DvU7CGA27LMt11tYu_pa%2BPohSc2VK%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Acquiring database new connections slow using pgx and pq

[Michael Jones]

Are you saying that it takes 7 seconds to make a connection?

On Thu, Jun 6, 2019 at 5:26 PM  wrote:

> I noticed that when executing concurrent db queries against my Postgres
> db, the response time gets slower linearly with the number of goroutines
> (at the order of O(N)). The first connection only took 172ms, but the
> subsequent ones are way over 1,000 ms and increase over time.  The more
> concurrent queries are running, the slower the response. Initially, I
> thought the issue might be related to the database server. So I setup a
> similar app in .NET to reproduce the issue but could not. Then I thought
> maybe the db driver, pq, is to blame, so I switched to pgx but the same
> issue happened. Then I though maybe it's the go runtime on Windows, so I
> ran the same app on Linux, and the same problem occurred. As a final
> attempt, I disabled TLS but the problem persisted.
>
> After some profiling, I discovered that opening a new database connection
> is the culprit. Looking at the Network blocking profile (See attached
> windows.svg), most of the delay seems to be in related to the connection.
> This does not seem to be related to a specific library. Any ideas to why
> opening a connection in go would be slow ?
>
>
> *go tool pprof /tmp/io-windows.profile*
>
> Showing top 40 nodes out of 50
>   flat  flat%   sum%cum   cum%
>317.55s 98.77% 98.77%317.55s 98.77%  internal/poll.(*FD).Read
>  3.94s  1.23%   100%  3.94s  1.23%  internal/poll.(*FD).WaitWrite
>  0 0%   100%  8.13s  2.53%  crypto/tls.(*Conn).Handshake
>  0 0%   100%305.46s 95.01%  crypto/tls.(*Conn).Read
>  0 0%   100%  8.13s  2.53%  crypto/tls.(*Conn).Write
>  0 0%   100%  8.13s  2.53%
> crypto/tls.(*Conn).clientHandshake
>  0 0%   100%  4.12s  1.28%
> crypto/tls.(*Conn).readHandshake
>  0 0%   100%313.58s 97.54%  crypto/tls.(*Conn).readRecord
>  0 0%   100%313.58s 97.54%
> crypto/tls.(*block).readFromUntil
>  0 0%   100%  8.13s  2.53%
> crypto/tls.(*clientHandshakeState).handshake
>  0 0%   100%  4.01s  1.25%
> crypto/tls.(*clientHandshakeState).readFinished
>  0 0%   100% 16.20s  5.04%
> github.com/jackc/pgx.(*Conn).Query
>  0 0%   100% 16.20s  5.04%
> github.com/jackc/pgx.(*Conn).QueryEx
>  0 0%   100%312.11s 97.08%
> github.com/jackc/pgx.(*Conn).connect
>  0 0%   100% 25.93s  8.06%
> github.com/jackc/pgx.(*Conn).initConnInfo
>  0 0%   100%  8.06s  2.51%
> github.com/jackc/pgx.(*Conn).initConnInfoDomains
>  0 0%   100%  8.05s  2.50%
> github.com/jackc/pgx.(*Conn).initConnInfoEnumArray
>  0 0%   100% 16.20s  5.04%
> github.com/jackc/pgx.(*Conn).prepareEx
>  0 0%   100%305.46s 95.01%
> github.com/jackc/pgx.(*Conn).rxMsg
>  0 0%   100%  3.97s  1.23%
> github.com/jackc/pgx.(*Conn).startTLS
>  0 0%   100%312.11s 97.08%
> github.com/jackc/pgx.(*ConnPool).Acquire
>  0 0%   100%316.20s 98.35%
> github.com/jackc/pgx.(*ConnPool).Query
>  0 0%   100%316.20s 98.35%
> github.com/jackc/pgx.(*ConnPool).QueryRow
>  0 0%   100%312.11s 97.08%
> github.com/jackc/pgx.(*ConnPool).acquire
>  0 0%   100%312.11s 97.08%
> github.com/jackc/pgx.(*ConnPool).createConnectionUnlocked
>  0 0%   100%  5.29s  1.65%
> github.com/jackc/pgx.(*Row).Scan
>  0 0%   100% 19.11s  5.94%
> github.com/jackc/pgx.(*Rows).Next
>  0 0%   100%312.11s 97.08%  github.com/jackc/pgx.Connect
>  0 0%   100%  5.75s  1.79%
> github.com/jackc/pgx.connInfoFromRows
>  0 0%   100%312.11s 97.08%  github.com/jackc/pgx.connect
>  0 0%   100% 25.93s  8.06%
> github.com/jackc/pgx.initPostgresql
>  0 0%   100%305.46s 95.01%
> github.com/jackc/pgx/chunkreader.(*ChunkReader).Next
>  0 0%   100%305.46s 95.01%
> github.com/jackc/pgx/chunkreader.(*ChunkReader).appendAtLeast
>  0 0%   100%305.46s 95.01%
> github.com/jackc/pgx/pgproto3.(*Frontend).Receive
>  0 0%   100%309.42s 96.25%  io.ReadAtLeast
>  0 0%   100%  3.97s  1.23%  io.ReadFull
>  0 0%   100%321.49s   100%  main.main.func1
>  0 0%   100%  3.94s  1.23%  net.(*Dialer).Dial
>  0 0%   100%  3.94s  1.23%  net.(*Dialer).Dial-fm
>  0 0%   100%  3.94s  1.23%  net.(*Dialer).DialContext
>
> Output of the app
> StartedDurationInMilliseconds: 172
> DurationInMilliseconds: 1724
> DurationInMilliseconds: 1884
> DurationInMilliseconds: 1919
> DurationInMilliseconds: 1975
> DurationInMilliseconds: 2025
> DurationInMilliseconds: 2086
> DurationInMilliseconds: 2156
> DurationInMilliseconds: 2484
> DurationInMilliseconds: 2486
> DurationInMill

Re: [go-nuts] Pattern Syntax in Golang

[Michael Jones]

Nadim, from what you have written I sense that you appreciate (or will
enjoy learning about) the style of programming that emerged with SNOBOL
some time ago. The notion of programming not just by saying "do this, then
this, then..." but at a higher and more conceptual level of *matching*
*situations* using rules and progressing to conclusion by repetition and
potentially *backtracking*. The general area of parsing, rewrite systems,
rule-based programming, and automata is large and not understood by
programmers to the degree that it deserves. (Exceptions being anyone who
has worked on SSA-style optimizing compilers or symbolic math software such
as Maple, Macsyma, Reduce, etc.)

The key ideas around string matching, such as notions of success and
failure, backtracking, greedy matches, following sets (and other new at the
time notions: garbage collection, type inference) were in the Bell Labs
language SNOBOL (and related, SNOCONE as well as Ralph Griswold's
subsequent icon). I suggest that you read about this work. People have been
inspired to add "SNOBOL pattern matching" to various other languages
including Ada and Python. Maybe the result of your interest could be
something of this nature for Go.

There is a similar respect/lust felt by a different set of people for the
PARSE statement of REXX. Some tools are so powerful that they change user's
ideas of possible and impossible. I believe that the general area of
parsing/matching/understanding/translating holds unfulfilled promise of
this kind.

Michael

On Wed, Jun 5, 2019 at 9:02 AM Nadim Kobeissi  wrote:

> Hello, and thank you for your response.
>
> I never intended to suggest that adding pattern matching would allow Go
> computational capabilities that it did not previously have. I agree that
> switch can be wielded to achieve the same logic in a syntax and structures
> that roughly resembles my suggestion. Let me attempt to explain my actual
> reasoning behind this proposal.
>
> Imagine that I am building a lexer, a parser or a compiler. If I am to
> follow your syntax, I would need to repeat a variant of this line from your
> example quite a few times: day, date := getDayAndDate()
>
> That indicates the necessity of declaring and allocates variables -- the
> memory pollution is secondary to the namespace and code elegance pollution
> there -- quite often throughout my code as it goes through the AST or
> whatever else structure I could be considering. In pattern matching the
> `day` and `date` variables *are not declared unless used for purposes other
> than pattern matching*: if I needed them, I'd write: `x, y:`, otherwise I'd
> write `"tuesday", 5:`.
>
> In addition to the above I would then very likely need to have nested ifs
> within nested ifs -- and dealing with each potential pattern that I'm
> trying to match would necessitate so much cruft that the resulting code
> would be very ugly. Indeed it's my view that Golang is currently not a
> suitable language for expressing any program that involves the treatment of
> an AST due to these syntactic limitations, i.e. the lack of real pattern
> matching.
>
> It's true that in the examples we're discussing, this pollution is
> minimal, but that's because they're simple examples. In the context of more
> complex parsing or transpiling, using switch as it currently is causes the
> code to become quite cumbersome, repetitive and nested. It's really a huge
> problem when dealing with actual languages and I can say that from
> experience.
>
> I agree that the `if` guard in my third original example is superfluous,
> so let's put it aside. I would still like to argue for the `match` keyword
> because I think that aside from the infinitely more elegant method and
> syntax for pattern matching, the benefits of wildcards (expressed with `_`)
> and also of struct type deconstruction (as seen in my third original
> example). I believe that `_`s are already ubiquitous around Golang and are
> used amply for very similar purposes as the ones they'd be used for here.
>
> This indeed could be a new direction for Go to consider, I don't claim to
> know. I don't mean to step on anyone's toes here or to dictate what the
> language should look like. I just sincerely think that `match` would make
> Golang a better language, not by allowing it to strictly *do things* it
> couldn't do before, but to do *a class of things elegantly* whereas it
> couldn't do them elegantly before.
>
> Nadim
> Sent from my computer
>
>
> On Wed, Jun 5, 2019 at 4:07 PM Ian Lance Taylor  wrote:
>
>> On Tue, Jun 4, 2019 at 10:22 PM Nadim Kobeissi 
>> wrote:
>> >
>> > Two more examples to show off some more cool ways match could be
>> useful. Here, I just demonstrate how we can have logic inside matches
>> thanks to anonymous functions:
>> >
>> > result = match getDayAndDate() {
>> > "tuesday", _: "wow looks like it's tuesday",
>> > _, 5: (func() string {
>> > if isItWednesday() == true {
>> > return "well, at least i

Re: [go-nuts] How can I debug high garbage collection rate cause high CPU usage issue in golang

[Michael Jones]

Perhaps this is obvious, but suddenly heavy garbage *collection* operations
suggest heavy garbage *creation* operations; that new code or structure is
allocating and discarding more than the old. You've gone from single to
multiple caches, so my thoughts go to: is data cached redundantly? (is the
n-cache version n-times as much GC or memory), are cached elements
migrating without memory reuse?, is the n-way concurrency implied causing
simultaneous caching as a temporal artifact? These seem like the right
kinds of questions to consider. Robert Engels already shared the
fundamental insight that GC cost is a reflection of your application's
"spending habits" and not generally something to control in the collector
itself.

On Tue, Jun 4, 2019 at 5:55 AM Joseph Wang  wrote:

> Hello everyone
>
> I just have a question about my golang code debugging. It's not specific
> code question. But I never met this issue before.
>
> The problem is like this. I replaced our back-end system's cache from
> single node cache to groupcache that is a kind mem cache. Then I met high
> memory usage issue at beginning. I use pprof and online resource then I set
> up GC rate(10%) to reduce memory usage down to normal. But then this will
> cause high CPU usage, because heavy GC operations. I use pprof to get the
> hot spot is runtime.ScanObject() this function, which is out of scope of my
> code base.
>
> So I don't know if anyone can give me some suggestions about how to fix
> this kind issue. I know the issue should come from my code base. But I
> don't know how to find out the issue and fix it ASAP.
>
> Best,
>
> Joseph
>
> --
> 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/5c977af4-074e-4eaf-85c2-2a284595b572%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQzCpxB-f7Xds-SatQApYTXAem76JvstN3YT%3DYZdejgHyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C binding generator for MacOS

[Michael Jones]

This is impressive. Thank you.

On Fri, May 31, 2019 at 9:33 AM Greg Pomerantz  wrote:

> Also I don't think an API is going to assume or require ARC -- as far as I
> understand it, ARC is just a compiler shortcut that adds retain and release
> calls so the programmer doesn't have to, it is not any sort of runtime
> memory management or garbage collection system. As long as Clang has a
> -fno-objc-arc flag, there should be no problem turning ARC off.
>
> On Friday, May 31, 2019 at 11:51:01 AM UTC-4, Robert Engels wrote:
>>
>> Isn't a lack of ARC support a critical limitation, as ARC is required
>> going forward, and many of the newer API's assume ARC behind the scenes?
>>
>> -Original Message-
>> From: Greg Pomerantz
>> Sent: May 30, 2019 8:25 AM
>> To: golang-nuts
>> Subject: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C
>> binding generator for MacOS
>>
>> I have been working on a binding generator that can read MacOS header
>> files and provide bindings for Objective-C interfaces and library
>> functions. NSWrap can also automatically generate classes implementing one
>> or more named protocols or subclassing a specified class.
>>
>> The automatically generated Go types implement method inheritance, and
>> overloaded method names are disambiguated. Variadic functions and methods
>> are supported and pointers to pointers are converted into slices. You can
>> create selectors (to assign actions to NSControl objects, for example) and
>> access Objective-C memory management methods (other than Automatic
>> Reference Counting), including AutoreleasePools.
>>
>> An example Cocoa application is provided in 24 lines of Go code. A
>> text-mode Bluetooth Low Energy heart rate monitor in pure Go is 127 lines.
>> The official git repository is linked below. This is the first release, so
>> expect plenty of rough edges.
>>
>> https://git.wow.st/gmp/nswrap
>>
>> --
>> 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/15be0140-b994-4692-9062-4792be74a8f9%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/5ff1a68f-c379-4ea7-9177-1a4e15f899a9%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQzf-SEiA6-NxsxjXkQE-ws%3DJgnXADh0FNLSwcsLt59-pQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[Michael Jones]

Daniela, that seems an excellent solution.

On Fri, May 24, 2019 at 12:12 PM Daniela Petruzalek <
daniela.petruza...@gmail.com> wrote:

> If I had to process messages from both high and low priority channels I
> would serialise then with a min heap and create a consumer process for the
> min heap. The min heap seems to be the canonical way of solving the
> priority queues anyway, so I think it makes sense here.
>
> Basically: goroutine 1 reads both channels and insert them into the
> min-heap. goroutine 2 reads from min heap and do the processing.
>
>
> Daniela Petruzalek
> Software Engineer
> github.com/danicat
> twitter.com/danicat83
>
>
> Em qui, 14 de fev de 2019 às 15:34,  escreveu:
>
>> select {
>> case highVal := <- high:
>> case lowVal := <- low:
>> if len(high) > 0 {
>> for len(high) > 0 {
>> highVal := <- high
>> }
>> }
>> // process lowVal
>> }
>>
>>
>>
>> On Tuesday, July 24, 2012 at 5:16:16 AM UTC+8, Erwin Driessens wrote:
>>>
>>> Hello,
>>>
>>> i wonder how to implement channel priorities nicely. Say there are two
>>> channels, one with a higher priority than the other, and a goroutine
>>> waiting for incoming data on these channels. I have read that select picks
>>> a random case when multiple channels are ready. I thought of nesting
>>> selects: putting the lower priority select in the default case of the
>>> higher priority select, and have the default case of the inner (low
>>> priority) select do nothing. This leads to a kind of busy wait loop. I
>>> could call a short sleep, but that still isn't very clean. Is there a
>>> better way?
>>>
>>> Why aren't the select cases evaluated in order?
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CA%2B%3Diygt2bxH1E8fkD5JpPV1vKrz2ns%2BD5KpbhZ_SSm2vK%3Dds3w%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQwZ0mL-UptRZya17ak%2B4nPYz47tBNsOWNcZDtCWPAsTeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[Michael Jones]

I see an easy* way to implement channel priorities in Go2 if that is
desired.

two steps:

step 2: At lines 124 and 153-157 of src/runtime/select.go, an *order of
channel testing* index table is created, then permuted.
It is later visited in order. All that needs doing is to make the index
table larger by repeating channel indices based on relative priority.
example:

channels a,b,c of equal priority:
pollorder = permute[a,b,c]

channels a,b,c of priority a=5,b=2,c=1:

pollorder = permute[a,a,a,a,a b,b, c]


step 1:Somehow convey priorities from developer's Go source to select.go.
Open issue, many choices, matter of taste. One idea is explicit parameter
in select, another is to allow cases to repeat and count them, or
equivalently, allow the "comma list of channels" with repeats.

 select {
case msg1 := <-c1:
fmt.Println("received", msg1)
case msg1 := <-c1:
fmt.Println("received", msg1)
case msg2 := <-c2:
fmt.Println("received", msg2)
 }


 select {
case msg1 := <-c1, <-c1:
fmt.Println("received", msg1)
case msg2 := <-c2:
fmt.Println("received", msg2)
 }


Each of these means c1 is 2x and c2 is 1x out of a total of 3, for c1 is 2x
the priority of c2 and is selected 2/3 of the time on average when both
channels have data. Since a deranged developer might copy/paste the "<-c1"
a hundred times, and "<-c2" fifty, the compiler should preferably optimize:

g = gcd(list of priorities)

[list of priorities]/=g // defend against needless scales in priorities,
ivy-like syntax

Michael

*easy to conjecture.

On Fri, May 24, 2019 at 9:18 AM Bruno Albuquerque  wrote:

>
>
> On Fri, May 24, 2019 at 8:40 AM roger peppe  wrote:
>
>> On Fri, 24 May 2019 at 16:25, Bruno Albuquerque  wrote:
>>
>>> On Fri, May 24, 2019 at 1:50 AM roger peppe  wrote:
>>>
 On Thu, 23 May 2019 at 19:28, Bruno Albuquerque  wrote:

> This was my attempt at a channel with priorities:
>
>
> https://git.bug-br.org.br/bga/channels/src/master/priority/channel_adapter.go
>
> Based on the assumption that priorities only make sense if items are
> queued. If they are pulled out from a channel as fast as they are added to
> it, then there is no need for priorization.
>

 I'm not entirely sure that's the right assumption. The original request
 is about having priority
 between different channels. If there's a value available on both
 channels, you only ever want to
 process the high priority one. With your code, however, if you've got
 two goroutines sending and the
 output channel is always ready to receive, the priority is decided by
 goroutine scheduling, and
 the low priority channel can win inappropriately:
 https://play.golang.org/p/YBD_w5vVqjt

>>>
>>> My code actually uses a single channel and deals with relative
>>> priorities between items added to the channel. The original problem can be
>>> morphed to this by using only 2 priorities. I honestly do not think that
>>> worrying about 2 values being sent by 2 different go routines at nearly the
>>> same time is something one needs to worry about. This is similar to having
>>> 2 entries sent to individual channels at nearly the same time but with
>>> enough skew that the low priority one arrives before the higher priority
>>> one does (so it will be processed first unless there is a forced delay
>>> added (as seem on the other approach).
>>>
>>
>> One example scenario when you might want to have priority receiving on
>> two different channels (which was after all the question that started this
>> thread), is when you're receiving messages from a high-volume buffered
>> channel, and a low volume synchronous channel (for example, a channel
>> returned from context.Done). If you get a value from the Done channel, you
>> want to quit as soon as possible. If you just use a regular select, you can
>> end up processing an unbounded number of messages before you decide to quit.
>>
>
> And you could easily do that with a select on the channel I return and the
> done channel. Also this is a very specific scenario you propose. For
> specific scenarios one can almost always find specific non-generic
> solutions that are better than a generic one. My solution tries to address
> the general case of dealing with prioritizing items in a channel.
>
>
>> There is one big advantage with my solution: You can actually model any
>>> reasonable number of priorities you might need without any code changes
>>> whatsoever. It can handle 2 priorities as well as it can handle 100.
>>>
>>
>> If I may say so, there's one significant disadvantage of your solution:
>> it doesn't solve the original problem :)
>>
>
> You you take the original question literally, you are obvious right. But
> it the original question can be relaxed to "I want to handle items with
> different priorities" which, as I mentioned, the original problem can be
> reduced t

Re: [go-nuts] Aggressive Golang Garbage Collection Issues When Using cgo?

[Michael Jones]

and when you change that "pass a pointer" to "have a shim c-side function
return a uint32 that you just assign on the Go side," what happens?

On Fri, May 24, 2019 at 8:52 AM Steven Estes  wrote:

> Thankyou Ian,
>
> I did try a few runs with GODEBUG set to "cgocheck=2" and just the
> "normal" errors (bad Go heap ptr, and sweep increased allocation) occurred.
> I'm assuming I would have seen a different kind of panic if it had detected
> something.
>
> Like I mentioned in the last post, we are very careful not to pass Go
> memory to with one exception where we pass a pointer to a Go uint32 that we
> expect to be filled in by the call. My understanding is this is permitted
> (cgo does not complain though it is very quick to complain if I try to pass
> the address of a string or byte array or structure).
>
> --
> 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/3e71a176-ef6f-4fad-b282-0318d47fda4f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQyW9o%2BqECobt356qt_AYnRAGdsE9KrDpzHUa73FoX%3DVSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Interesting public commentary on Go...

[Michael Jones]

It is very good to have registered the marks to prevent abuse. Once owned,
the owner then has the ability to share as freely as desired, but in a
structured way (a la open source licenses) while holding questionable uses
at bay.

In my work this kind of control has demonstrated its importance. In the
creation of OpenGL ist SGI t was essential to have it mean something
specific API and conformance wise; in inventing Google Earth and growing it
and Google Maps to a billion unique monthly users it was important to
control the brands, including Keyhole's KML which I gave to the OGC; now as
a senior exec at Niantic, it seems more important than ever that Pokémon Go
is a carefully controlled name and mark--every knock-off product seems to
want to use our kind of "Go" as a marketing leverage (including "AR GO"
from Google, a Niantic investor, sigh).

May be a surprise to the Go team, but not to Kent Walker...
[image: Mark Image]
*Word Mark* *GO*
*Goods and Services* IC 009. US 021 023 026 036 038. G & S: Computer
programs and downloadable computer programs that implement a computer
programming language for use in developing, building and managing other
software. FIRST USE: 20091110. FIRST USE IN COMMERCE: 20091110
*Standard Characters Claimed*
*Mark Drawing Code* (4) STANDARD CHARACTER MARK
*Serial Number* 88100955
*Filing Date* August 31, 2018
*Current Basis* 1A
*Original Filing Basis* 1A
*Owner* (APPLICANT) Google LLC LIMITED LIABILITY COMPANY DELAWARE 1600
Amphitheatre Parkway Mountain View CALIFORNIA 94043
*Type of Mark* TRADEMARK
*Register* PRINCIPAL
*Live/Dead Indicator* LIVE


[image: Mark Image]
*Word Mark* *GO*
*Goods and Services* IC 009. US 021 023 026 036 038. G & S: Computer
programs and downloadable computer programs that implement a computer
programming language for use in developing, building and managing other
software
*Mark Drawing Code* (3) DESIGN PLUS WORDS, LETTERS, AND/OR NUMBERS
*Design Search Code* 26.17.01 - Bands, straight ; Bars, straight ; Lines,
straight ; Straight line(s), band(s) or bar(s)
26.17.06 - Bands, diagonal ; Bars, diagonal ; Diagonal line(s), band(s) or
bar(s) ; Lines, diagonal
*Serial Number* 88100957
*Filing Date* August 31, 2018
*Current Basis* 1B
*Original Filing Basis* 1B
*Owner* (APPLICANT) Google LLC LIMITED LIABILITY COMPANY DELAWARE 1600
Amphitheatre Parkway Mountain View CALIFORNIA 94043
*Description of Mark* Color is not claimed as a feature of the mark. The
mark consists of the stylized word GO with three small lines to the left of
the word.
*Type of Mark* TRADEMARK
*Register* PRINCIPAL

*Live/Dead Indicator*

-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQzynsAnt5Lf4T4DHzeC_TU5NKSkLv0bDR%3DWogSZbLGUBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] constatnt conversion question

[Michael Jones]

Oh, Sorry. Have been away from email today. (Focused 100% in VS-code on a
cool feature for Go)

My statement was meant to convey an insight into a subtle aspect of Go's
constants and high-precision expression evaluation--that the "type" of
untyped constants/values, in the conversion rules sense, is derived in the
instant of the conversion and is not an inherent trait of the value as is
quite generally the case in other languages and situations. Also I think,
the spec document is a little deceptive here, or at least, it needs to be
read creatively to understand what all the possibilities are.

In this case, the original question by Djadala was about a const "6.6" not
being able to be coerced to integer form in either of two ways of
trying ("x = int(y)" and "x int = y"). Both you and Jan explained why this
is so and where/how it is defined in the specification. That was
authoritative.

However, the original question was worded in such a way that I could not
discern if he was asking "please share the official reason why this seems
impossible" or if instead he/she meant, "can I do this? I've tried two
ways, and it seems impossible." I'm very supportive of the "how can I make
it work?" sentiment and I doubted that the OP would figure it out since the
two responses seemed so absolute, so I weighed in.

Here's the subtle point. *That 6.6 constant "y" is NOT a floating-point
value.*  it's value just happens to "be as if floating" at the moment.
However, "y*10" evaluates to 66, and that is a "just plain 66" not "10
times the floating point 6.6, therefore an inherent floating point value of
66.0" The upshot is that Djadala cannot get "y" into an int, but can easily
get "10*y" into one, and having done so, can make that integer 66 into the
integer 6 via truncating integer division as I showed in the linked Go
Playground example: https://play.golang.org/p/7gcb9Yv7c9e

Since the "6.6" has one decimal place making y *be as if floating point,*
multiplication by an integer multiple of 10 is enough to clear the decimals
and let it *be as if integer* in arbitrary expressions. If it was "6.67" (2
places) or "6.678" (three places), then the least power of ten to clear the
"as if floating" problem Djadala faced would be "10**k, k >= number of
decimals" as was indicated in my comment in the linked Playground example.

Sadly, this is not a general-purpose, remedy because the magic expression
evaluation logic insists that values fit into the target size; were it not
this way, we might imagine multiplying by 10**k, k>=19, capturing the
integerness of the expression in that instant, and then dividing by the
same factor. Alas, we'll be stopped right there because the expression,
while *as if an integer,* is simultaneously, *as if too big to fit into
one. *Since 64-bit ints are big and the OP was wrestling with only one
decimal place in a small sized number, it worked with fifteen or more
digits of precision to spare. However, if "y" were (1e16 + 0.6) then there
would not be much wiggle room to clear the decimals this way.

If these kinds of topics are interesting to you, there are discussions
about related matters and possible changes for Go 2 in various proposal
threads.

On Mon, May 20, 2019 at 11:50 PM  wrote:

> Could you please clarify which statement your example is meant to
> confirm or refute?
>
>
>
> On 5/20/19, Michael Jones  wrote:
> > ahem...
> > https://play.golang.org/p/7gcb9Yv7c9e
> >
> > On Mon, May 20, 2019 at 2:45 AM  wrote:
> >
> >> https://golang.org/ref/spec#Constants
> >>
> >> "A constant may be given a type explicitly by a constant declaration
> >> or conversion, or implicitly when used in a variable declaration or an
> >> assignment or as an operand in an expression. It is an error if the
> >> constant value cannot be represented as a value of the respective
> >> type."
> >>
> >>
> >>
> >> On 5/20/19, djad...@gmail.com  wrote:
> >> > Hi,
> >> > does this should work ?
> >> >
> >> > package main
> >> >
> >> > import (
> >> > "fmt"
> >> > )
> >> >
> >> > func main() {
> >> > const (
> >> > c = 2
> >> > z = 3.3
> >> > y = c * z
> >> > x = int(y) // or x int = y
> >> > )
> >> >
> >> > fmt.Println(x)
> >> > }
> >> >
> >> >
> >> > it does not compile with error:
> >> > constant 6.6 truncated t

Re: [go-nuts] constatnt conversion question

[Michael Jones]

ahem...
https://play.golang.org/p/7gcb9Yv7c9e

On Mon, May 20, 2019 at 2:45 AM  wrote:

> https://golang.org/ref/spec#Constants
>
> "A constant may be given a type explicitly by a constant declaration
> or conversion, or implicitly when used in a variable declaration or an
> assignment or as an operand in an expression. It is an error if the
> constant value cannot be represented as a value of the respective
> type."
>
>
>
> On 5/20/19, djad...@gmail.com  wrote:
> > Hi,
> > does this should work ?
> >
> > package main
> >
> > import (
> > "fmt"
> > )
> >
> > func main() {
> > const (
> > c = 2
> > z = 3.3
> > y = c * z
> > x = int(y) // or x int = y
> > )
> >
> > fmt.Println(x)
> > }
> >
> >
> > it does not compile with error:
> > constant 6.6 truncated to integer
> >
> > https://play.golang.org/p/f-Q6XSvvcrM
> >
> > --
> > 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/736e8b03-d38f-4ec4-adc8-fcb77e0cda7b%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/CA%2Bctqrp24YWs4cQVE2NxTEqzn0VxgRLTH3aAbXhjPKV21pDeqA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQxB0Gu%3D4TnWWns8yr-LoZ2uhj-%2Bg-%2B4FLLki6vQ6gkTxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: the Dominance of English in Programming Languages

[Michael Jones]

'carcer' is the word. jail/gaol are just johnny-come-lately.

On Sat, May 18, 2019 at 9:43 AM David Riley  wrote:

> On May 18, 2019, at 05:59, ma...@madra.net wrote:
>
> On Saturday, 18 May 2019 00:44:33 UTC+1, Rob 'Commander' Pike wrote:
>>
>> jail is a clear improvement over the ludicrous gaol...
>>
>
> I hadn't actually realised that GAOL vs JAIL was a British vs. US English
> distinction. I thought 'Gaol' was just an archaic spelling of 'Jail', as
> I've only ever come across it in C19th and earlier literature. Even over
> this side of the pond, 'Jail' is used pretty exclusively. Although we
> mostly call it 'Prison' :-)
>
>
> This is OT for the list, but: I think it’s more the latter (an archaism
> rather than a regional distinction; jail is basically universal here
> because we started later).
>
> We do, however, tend to distinguish somewhat between “jail” and “prison”;
> the short version is that jail is temporary holding while awaiting trial,
> while prison is more permanent punitive containment post-sentencing. I’m
> not sure if that distinction exists as much overseas, and in colloquial US
> English, saying that someone is “in jail” is often used for both situations
> (I, myself, enjoy our more colorful slang such as “in the pokey” or “up the
> river”).
>
>
> - 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/A89B99F0-1753-4D8F-81FE-9A6C26A2FDC9%40gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQyzwnGK9zR_KM6w%2Bs5HtHCwM3f6jkXVkZcCsYSbDnG46w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: the Dominance of English in Programming Languages

[Michael Jones]

In addition to being a daily Go programmer, I'm also a corporate executive
in the US and a venture investment partner in the UK. This has me
constantly surrounded by "proper" English and has made me very aware of the
linguistic habits of my American upbringing. It seems that I've become an
amalgam of the two, I say that "I was in hospital" for example, but name
variables 'color' -- the result earning awkward glances on both sides of
the Atlantic. My ear now prefers English English, in part from my love of
the character of English people.

On Fri, May 17, 2019 at 2:07 PM stíobhart matulevicz 
wrote:

>
> I know that a lot of what we think of as "American English"  words are
> actually archaic forms of early 'English English'. Words like "gotten"
> instead of "got", for example. But there's also a lot of blame or credit
> (depending on your point of view) for the differences to be laid at the
> door of a certain Mr. Noah Webster:
>
>
> https://blog.oxforddictionaries.com/amp/2018/05/07/noah-webster-american-identity-simplified-spelling-movement/
>
> I was kind of half-joking in my original post.  But, as someone who
> considers himself highly literate,  I do actually find it does grate a
> bit,  having to (from my point of view) deliberately spell words wrong,
> when I'm coding.
>
> I get my revenge in the code comments though,  where I resolutely stick to
> "colour", "centre", "programme", etc.
>
> I wonder if I'm am isolated case,  or whether any other native English
> speakers are slightly irked by having to code in "bad spelling" too?
>
>
> On 17 May 2019 21:26:29 Michael Jones  wrote:
>
>> I know that you joke here, but I had an interesting dinner conversation
>> in London last year with erudite, scholarly friends who shared with me that
>> recent research supports a different view of the "barbaric Americanised
>> false English" that is the prevailing sentiment you share.
>>
>> According to the scholars they mentioned, "American English" is indeed a
>> true, pure, "real" English; just one from a time-capsule, an English from
>> 1776 that did not advance significantly since American independence. This
>> view suggests that were a BBC presenter and an American to travel back to
>> meet with King George, it would be the American who sounded "right" and not
>> the other way around.
>>
>> This time-capsule argument is not an argument against modern evolved
>> English, but it is an interesting notion of a living language in the
>> homeland might become a historical artifact through cargo culting in the
>> breakaway colony. Insightful as to human psychology and something to
>> remember amongst the lessons of wisdom.
>>
>> Michael
>> (a barbaric American-English 1776 throwback ;-)
>>
>> On Fri, May 17, 2019 at 9:41 AM  wrote:
>>
>>> Spare a thought for those of us who actually speak and write 'proper'
>>> English and not that American version used in all programming languages.
>>>
>>> We get to write in our own language but have to remember to spell half
>>> the words wrong!
>>>
>>>>
>>>
>>> --
>>> 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/1e22042e-9ac0-404f-be30-eaa495ae11dd%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/1e22042e-9ac0-404f-be30-eaa495ae11dd%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>>
>> *Michael T. jonesmichael.jo...@gmail.com *
>>
>
>

-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQwT4dY6tpHr5yp%3DnyQL4arLLRm7QjjUe_9rcV9jKGKC%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: the Dominance of English in Programming Languages

[Michael Jones]

I know that you joke here, but I had an interesting dinner conversation in
London last year with erudite, scholarly friends who shared with me that
recent research supports a different view of the "barbaric Americanised
false English" that is the prevailing sentiment you share.

According to the scholars they mentioned, "American English" is indeed a
true, pure, "real" English; just one from a time-capsule, an English from
1776 that did not advance significantly since American independence. This
view suggests that were a BBC presenter and an American to travel back to
meet with King George, it would be the American who sounded "right" and not
the other way around.

This time-capsule argument is not an argument against modern evolved
English, but it is an interesting notion of a living language in the
homeland might become a historical artifact through cargo culting in the
breakaway colony. Insightful as to human psychology and something to
remember amongst the lessons of wisdom.

Michael
(a barbaric American-English 1776 throwback ;-)

On Fri, May 17, 2019 at 9:41 AM  wrote:

> Spare a thought for those of us who actually speak and write 'proper'
> English and not that American version used in all programming languages.
>
> We get to write in our own language but have to remember to spell half the
> words wrong!
>
>>
>
> --
> 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/1e22042e-9ac0-404f-be30-eaa495ae11dd%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQxZ9FukdODzXUfas4%2BqyC3csGW4voN4fZ4QVX37EYAcgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go documentation - how to determine what implements an interface?

[Michael Jones]

The magical Go phrase is "implicitly implements." What you want is to make
that explicit in the documentation.

On Thu, May 16, 2019 at 1:16 AM 'White Hexagon' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Thanks. Tools are fine, but a new developer has to know about them.  So I
> think it would still be super useful if golang.org documentation had this
> information already generated.  In bytes.Reader I should be able to see
> 'Implements ReadSeeker etc', and in ReadSeeker I should be able to see
> 'Implemented by bytes.Reader etc'.
>
> Cheers
> Peter
>
> On Thursday, 16 May 2019 09:50:04 UTC+2, Agniva De Sarker wrote:
>>
>> You can see the documentation by enabling type analysis in godoc. See
>> https://golang.org/lib/godoc/analysis/help.html. Also see
>> https://github.com/golang/go/issues/20131
>>
>> --
> 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/5b1b85a8-8072-4da3-9ca5-b9d29a28e331%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQz-PT4vYq1phJ7x_9UpcseLqY-u9Qmn7kBYf-0hmtAc%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go if else syntax .. suggested replacement

[Michael Jones]

On Mon, May 13, 2019 at 7:46 AM  wrote:

> Given the extent of responses to the original question by the Go community
> (pro and con), hopefully those responsible for Go syntax will re-visit the
> issue and decide whether Go statement "if test then {.. } else { .. }"
> prevents any possible abuse or confusion  that would occur if it were
> replaced with   ?test { ..} : { .. }
>

It is inconceivable that "if test then {.. } else { .. }" will be replaced
with "?test { ..} : { .. }" just as it is to consider changing red
octagonal stop signs to blue ovals. A massive, omnipresent change (such as
stop signs, power outlet plugs, which side of the road to drive on,
programming paradigms now natural to tens of millions of people, etc.)
needs an enormous motivation to be undertaken voluntarily--major problems
that must urgently be solved in the new way. Nothing in the email here
suggests anything more than personal preference and that is far too weak
for such a change even if the Go gods all liked it. This is a stewardship
issue.

(speaking as a non-god, but speaking truth)

-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQyLfKSJWMz9w_UiNK5qt%3Dhm_J_vbt8T6ZWg3Pviv9EgEw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How to run a go method on multiple cores ?

[Michael Jones]

Can you share a little more of your motivation for saying: “I want two
instances of syslog-ng engine running on two different processors.”

Do you mean (minimum) that you want two independent instances, or (maximum)
that you want to prove that there are two instances, two physical
processors, and that at no time does processor “a” execute code on behalf
of instance “b” and likewise for processor “b” and instance “a”, (or
something else completely).

This “proof” idea seems very unusual but also seems to be what you want.
Maybe it is not. That’s why it might be good to share more of your thinking
and not just the conclusion.

The natural thing in most every situation with modern CPUs, OSs, and non
hard real-time applications, is just having enough total CPU resources for
the mix of work and enough independence (concurrency opportunity) in the
application so that the load can be magically balanced.

If this is not enough for you then you must have special circumstances.

On Wed, May 8, 2019 at 2:47 AM Nitish Saboo 
wrote:

> Hi Marvin,
>
> Thanks for your response.
>
> "Do you mean "log/syslog" from the standard library?  What does
> initialize do?"
>
> >>I have installed syslog-ng parser on my Linux box and I am planning you
> use syslog-ng parser and wanted to initialise it's engine for parsing the
> data.
>
> so initialise() method in my Go code calls  C code that is wrapper around
> syslog-ng C header files.So ,I am making use of cgo
>
> *Following is my Go code:*
>
> func (obj Syslogparser) initialise{
>
> X := C.CString(obj.X)
> defer C.free(unsafe.Pointer(X))
> Y := C.CString(obj.Y)
> defer C.free(unsafe.Pointer(Y))
> C.initialize_engine(X, Y,
> (C.key_value_cb)(unsafe.Pointer(C.callOnMeGo_cgo)));
> }
>
> *And following is my C method 'initialize_engine':*
>
> int initialize_engine(const gchar* X, const gchar* Y, key_value_cb cb) //
> cb is callback function
> {
> // does some operation for initialising the engine of syslog-ng parser
>   return 0;
> }
>
> 1)I want two instances of syslog-ng engine running on two different
> processors.How can I achieve this?
>
> 2)I made the following change :
>
> func main {
> var obj1 Syslogparser  = initalize() // This initialises syslog-ng engine.call
> to a C library via cgo
> var obj2 Syslogparser// Not a package-level variable
> obj1.ParseMessage(program,msg)// this will parse the data and get the
> result
> if result["Z"] == "unknown"{ // On the basis of this result I want to
> initialise a new engine
> go func() {
>  opts := Syslog{}
> obj2 = initalize() //call to a C library via cgo
> obj2.ReloadPatternDB(opts)  //call to a C library via cgo
> obj2.ParseMessage(program, msg) //call to a C library via cgo
> }()
> }
> }
>
> Will this initialise two different syslog-ng engines for me ?
>
> 3)I understand goroutines are not OS threads and they just run on OS
> threads.Can we extract the process id of the running syslog-ng engines
> within the go routine where it spawned the syslog-ng engine ?
>
> Thanks
>
>
> On Wed, May 8, 2019 at 3:01 AM Marvin Renich  wrote:
>
>> * Nitish Saboo  [190507 14:07]:
>> > Thanks Michel for your detailed response.
>> > I am initialising the syslog engine.
>>
>> Do you mean "log/syslog" from the standard library?  What does
>> initialize do?
>>
>> > var obj1 parser  = initalize()
>> > var obj2 parser
>> > go func() {
>> > obj2 = initalize()
>> > }()
>>
>> You have initialized obj1, then you create a go routine that initializes
>> obj2.  Assuming the initialization step takes a relatively short amount
>> of time and terminates, and does not itself create another go routine,
>> obj2 is not "on another go routine" (or thread or CPU or anything else).
>> It is simply another variable whose value was assigned by a different go
>> routine, but that go routine terminated immediately after obj2 was given
>> its value.
>>
>> Note that obj2 is a variable, not a running function; it is not
>> associated with a specific go routine, at least not in the sense that
>> you appear to be thinking.  If obj2 is declared at the package level,
>> than any function in the package can reference it regardless of the go
>> routine in which that function is running.
>>
>> > if obj1 engine fails:
>> > go func() {
>> > obj2.ReloadPattern(opts)
>> > }()
>> >
>> > My question is, will obj2.ReloadPattern reload the pattern on the second
>> > syslog-engine , how can I verify that?Because I am not maintaining the
>> > engine info. I am just having the parser object.
>> > Will parser object obj2 go and reload the respective syslog engine that
>> was
>> > initialised by it? I guess yes, but still need clarification on this .
>>
>> A new go routine will be created (possibly unnecessarily, but you don't
>> give enough information), and the ReloadPattern method of obj2 will be
>> invoked in that go routine.  When ReloadPattern terminates, the go
>> routine will also terminate.  obj2 is still a package-level variable (or
>> associated with whate

Re: [go-nuts] Re: How to run a go method on multiple cores ?

[Michael Jones]

Perhaps you will find this blog post (and the related ones before and
after) and the videos linked at the bottom to be faster.

https://blog.golang.org/pipelines


On Tue, May 7, 2019 at 6:22 AM  wrote:

> Can anyone recommend a good on-line doc for goroutines ? The best one I've
> found so far uses a very SLOW approach to present essential info
> https://gobyexample.com/goroutines
>
>
> On Monday, May 6, 2019 at 7:11:00 AM UTC-4, Nitish Saboo wrote:
>>
>> Hi,
>>
>> I want a go method to run on multiple cores.The go method is returning an
>> object. Can we achieve this using goroutine ?
>> How can I achieve this ?
>>
>> 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/52ca0b92-e335-4681-adbd-886cb69daede%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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-nuts/CALoEmQwOvVypP-ZDC11%2BCo64ZuJdb-MVfuyJisYDB1XRY3KZgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Random panic in production with Sprintf

[Michael Jones]

Is any of this string data touched/from C via CGO?

On Thu, May 2, 2019 at 3:09 PM Anthony Martin  wrote:

> Ian Lance Taylor  once said:
> > I don't *think* the format string is changing.  I think the 0 is from
> > the string being printed, not the format string.  They both happen to
> > be length 5.
>
> Misled by the pair of fives. Mea culpa.
>
>   Anthony
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go if else syntax .. suggested replacement

[Michael Jones]

Agree completely. Despite my reasoned comfort with Go’s rationale I miss
quite a few “but I want to express this algorithm beautifully for the ages”
features. I don’t miss the ternary syntax but miss the natural way to say
“it is an assignment, first, but subject to logic, second.” Same as I miss
do...until/while, because the trivial workaround obscures the logic and I
feel I’ve cheated the reader. Likewise, I lay out structs so the variable
width parts (strings say) will be last so that the initializer will look as
non-bad as possible after gofmt. I understand the trade off, but wish the
literate style and beauty of mathematical typography had a better friend in
go.

On Sat, Apr 27, 2019 at 10:19 AM  wrote:

> Ada originally followed BCPL and Pascal in distinguishing between commands
> (statements) and expressions, compared say to Algol68 which was an
> expression language.
> BCPL had VALOF/RESULTIS to link the two realms. It also had a conditional
> expression (A -> B, C) with the same meaning as B's and C's later (A? B: C)
> [which is probably better syntax].
> Neither Pascal nor Ada had conditional expressions, for different reasons.
>
> Ada has since added both "if" and "case" as conditional expression forms
> (including "elseif"). There's a discussion in the 2012 Rationale:
> http://www.ada-auth.org/standards/12rat/html/Rat12-3-2.html A big reason
> for introducing them was to support writing preconditions and
> postconditions.
> there are quantifying expressions as well (ie, "for all", "for some").
> Originally, they were
> special pragmas in the SPARK subset but were finally promoted to be part
> of the language.
>
> Following the discussion above, I'd note though that one difference
> between (say)
>
> if a > b {
>m = a
> } else {
>m = b
> }
>
>and
>  m := b
>  if a > b {
>m = a
>  }
> is that the former emphasises that the two cases (assignments) are
> mutually exclusive (m is either a or it is b), as opposed to (m is b unless
> it then becomes a),
> not very interesting here but there can be more complex cases.
>
> In converting a C# program to Go I've had a few instances where converting
> to if/else was clumsier or even more obscure, often it seems in
> constructors converted to struct literals,
> but in practice it's a minor point. As someone observed, sometimes little
> helper functions restore the flow and improve clarity (count!=0?
> total/count: 0) => avg(total, count)
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go if else syntax .. suggested replacement

[Michael Jones]

The last time there was a big thread about this, I explained how GCC added
“value of brace block is value of last expression” to allow great power,
and a fellow poster explained how this came into being with Algol-68.

There is long history in these ideas, and much value, but Go specifically
chose not to be an expression language. The limits of this are clear in the
++ statement vs c’s ++ operator. Huge, delicious power in the latter, tepid
bit of economy in the former. It was a loss. The offsetting gain was
believed to be in avoiding the four decades of confusion about ++ order of
evaluation in function arguments and other situations.

It’s natural to miss power long held. The Go experiment is about team
efficiency in a far simpler language. It feels a great success to me
despite the frustration of feeling muzzled.

On Fri, Apr 26, 2019 at 6:18 AM Mike Schinkel  wrote:

> I was assuming the compiler did not eliminate it. If it does then my point
> is moot.
>
> -Mike
>
> Sent from my iPad
>
> > On Apr 26, 2019, at 9:13 AM, Ian Lance Taylor  wrote:
> >
> >> On Thu, Apr 25, 2019 at 10:57 PM Mike Schinkel 
> wrote:
> >>
> >> Marcus Low wrote:
> >>>
> >>> datalen := removedKeyken // removedKeyken must have been int32 in your
> example.
> >>> if value != nil {
> >>>   datalen = len(value)
> >>> }
> >>
> >>
> >> The issue with this is it makes two assignments when value != nil
> instead of just one.
> >
> > In what sense is that an issue?  If you are concerned about
> > performance, note that the compiler can eliminate the initial
> > assignment in the value == nil case if it is costly.
> >
> > 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.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go if else syntax .. suggested replacement

[Michael Jones]

switch test {
case true:
  //..code block for test=true
case false:
  //..code block for test=false
}

On Wed, Apr 24, 2019 at 4:42 PM Dan Kortschak  wrote:

> How would you preclude it?
>
> On Wed, 2019-04-24 at 16:28 -0700, lgod...@gmail.com wrote:
> > I am NOT in favor of allowing nested ternary operations
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to get file's current offset

[Michael Jones]

It does if you’re Rob. 🥁

On Fri, Apr 19, 2019 at 5:49 PM andrey mirtchovski 
wrote:

>
>
> On Fri, Apr 19, 2019, 4:48 PM Rob Pike  wrote:
>
>> I just use 1 so I don't have to look up what it's called these days, but
>> I'm seriously old school.
>>
>
> Does that pass code review or do people give you the benefit of doubt?
>
>> --

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to get file's current offset

[Michael Jones]

I’ve been doing that since 6th Edition, 1976/77

On Thu, Apr 18, 2019 at 8:00 AM andrey mirtchovski 
wrote:

> > offset, err := f.Seek(0, io.SeekCurrent)
>
> my code has been written so long ago i didn't even notice os.SEEK_CUR
> is deprecated :)
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Current Thinking on Explicit Memory Freeing?

[Michael Jones]

There are two issues here:

1. *"I'm done with this and I want to free it now."* It seems helpful as a
programmer to say such things. I wanted that once. The problem with it is
that the runtime can't trust you if you say it. At best it can put the
address on a list to be examined, but only a GC pass will be able to prove
that the region is unreferenced.

2. *"It is still referenced but I'm done with it forever."* This is good in
spirit: it is a kind of program-level pointer liveness analysis as is done
in register allocation. It could be proven by the compiler that at line N+1
of code...some things from lines 0..N will no longer be referenced. This
could be done automatically by inserting "set never to be referenced
pointers to nil" code during compilation after each provable last reference.

On Tue, Apr 16, 2019 at 10:22 PM Ian Lance Taylor  wrote:

> On Tue, Apr 16, 2019 at 9:53 PM  wrote:
> >
> > In a compiler, say during the lexing and parsing phases, memory might be
> allocated
> > that won't be needed after those phases are complete. The memory is
> still referenced,
> > so the GC won't free it, but conceptually it actually could be freed. In
> other words,
> > the fact that memory is referenced isn't the final word on whether it
> could be freed.
>
> If the memory is still referenced, it can still be used, so it won't
> be freed.  If the memory will not longer be used, then don't reference
> it.
>
>
> > You're saying to modify all the pointers that point to this memory. I'm
> guessing
> > that this could be a lot of work, Plus, let's say this memory is
> organized as
> > a linked list. Would it be sufficient to just modify the pointer that
> points to the
> > head of the list, or would I have to go through the list from tail to
> head, modifying
> > the pointers in each list element?
>
> As Robert said, just stop referencing the head.  The only references
> that count are the ones from global and local variables.  If it can't
> be reached by following pointers from a variable, then it is no longer
> referenced.
>
>
> > And to answer Robert Engels question - no, I'm not concerned with the
> > GC's performance because the memory I'm thinking about won't be seen
> > by the GC since it's still referenced. And yes, I'm wondering whether
> there's
> > a way to create a region-like entity so that all the memory that was
> allocated
> > in the region could be freed in one swell foop.
>
> My earlier answer still stands: such a region is unlikely to make a
> significant difference in a GC system.
>
> 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.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] floating point question

[Michael Jones]

These "floating-point is weird" discussions tend to be unfair to the
virtues of floating point. ;-)

The numbers in computers are NOT the numbers of mathematics. They do not
have the same properties, promises, and definitions. So instead of shaking
our fists at the computer when we're reminded of the difference, why not
accept the difference and use what is provided?

Acceptance #1: Floating point values are actually binary integers.

While the "floating" aspect means scaling a range of integers over a wide
range via a separate exponent, the mantissa part (the fraction) is still a
binary integer interpreted as the numerator of a rational number, the
denominator being 2^n where n varies of course between 32-bit and 64-bit
floating point, with n=52 for the "double precision" 64-bit case. The n
here determines the number of values that are expressible perfectly as
scaled integers (2^52 of them).

In particular, when expressing a floating point value the compiler and
computer must find the closest power-of-two fraction to your number:
1.0/2.0 => 2^51 / 2^52, for example and this is an ideal representation.
Unfortunately, a value like 1.0/3.0 (or 1.21 == 121/100 in the original
question) is impossible to represent a n/d, d=2^k for any k. That is
because 2^k is not divisible by 3 and neither is 2^k divisible by 121.

We accept this about time. "I'll see you in a 7th of an hour" is a
reasonable notion, but it is not expressible in seconds. It is more than 8
seconds, but less than 9 seconds.(t=8.5714285714... seconds) Now if we
agree to pretend that this floating point value is the time we mean, it
will all work out, unless someone peeks under the hood at the details by
asking "why is 7-1/t not equal to zero but instead 3.469446952E-18?" ;-)

When they do, it's ok. It just means that we're all observing the measure
of the distance between the desired value and the nearest fraction with
2^52 as the denominator. it is all ok. Just remember they're not the
numbers of algebra.


On Tue, Apr 16, 2019 at 6:40 AM David Riley  wrote:

> On Apr 16, 2019, at 2:29 AM, Miki Tebeka  wrote:
> >>
> >> On Monday, April 15, 2019 at 7:59:28 PM UTC+3, David Riley wrote:
> >> On Apr 15, 2019, at 12:47 PM, Miki Tebeka  wrote:
> >> >
> >> > On Monday, April 15, 2019 at 2:12:18 PM UTC+3, Jan Mercl wrote:
> >> >
> >> > 1.1*1.1 and 1.21 are untyped constants and have much higher precision
> at which they are not equal.
> >> > Does that mean that the Go compiler is using floats with more
> precision than the runtime?
> >>
> >> Yes, but it's also worth remembering that in general, in computing,
> it's not a great idea to compare floats for absolute equality except for
> specific constants (e.g. +/- zero, +/- infinity, NaN).
> >>
> >> Is there an in-built intrinsic in Go for comparing floats within an
> epsilon, or does that have to be done manually?
> >
> > I came across this when teaching about floats not being exact, was
> surprised to see the "true" :)
>
> Yup! My personal perspective is that it's best to treat floating point
> numbers as "noisy", because you lose or add little bits to them with most
> operations in ways that are hard to control (this is one of the reasons
> IEEE floating point numbers have tightly-defined characteristics, because
> then at least the flaws are well-defined and you don't get e.g. diverging
> results in physics simulations on different machines because they round
> differently).
>
> Treat a floating point number as a noisy signal, always compare within
> ranges (often enough, even when comparing against zero, especially
> considering that there is also a *negative* zero in floats) and you won't
> go wrong.  Well, not *very* wrong.  Better yet, avoid use of floating point
> arithmetic where at all possible (but here I'm showing my personal biases).
>
>
> - 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.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to use an instance across functions in a package w/o global vars

[Michael Jones]

This is really about you, your taste in design, and your sensibilities for
information hiding.

If you have a global symbol, be it a function name or data item, then
that's what it is, a global. Globals, r/w data especially, invite subtle
sharing complications, can cause complexity in attempts at modular
replacement or in various testing scenarios.

Global data works nicely for set once, read mostly scenarios such as the
flags package. Even so, it is not so flexible as a contained item with
explicit accessors. One approach above is to treat that "var w
*window.Window" as private in un-exported scope and then provide a
global-visible GetWindow() function that could be called from main or other
places. While this is almost literally the same, it is much nicer when you
want to change things during testing or in ports where special
circumstances are needed. The go compiler's inlining is now good enough
that the object style getter setter approach is as fast as global data.

(I know there is no big news here but people search these threads and may
find value in comprehensive answers)


On Fri, Apr 12, 2019 at 10:44 AM alex via golang-nuts <
golang-nuts@googlegroups.com> wrote:

>
>
> On Thursday, April 11, 2019 at 6:20:33 AM UTC-4, Dumitru Ungureanu wrote:
>>
>> It helps a lot! Thanks.
>>
>> I now have two things to moan about.
>>
>> If I was to pass c around, I would added it to the params list. If I had
>> more others, I'd built a struct. But now, if somehow I lose track of who's
>> passing what and where, hard times debugging ahead. Having them declared at
>> package level, it seems to cut short the list of things to add, do and
>> track.
>>
> Grouping parameters in a struct (or any kind of aggregate data structure)
> should actually make it easier to reason about them, e.g. you are now
> reasoning about "configuration" instead of individual configuration
> options, making "zoom-in" distinctions only where necessary at the point of
> use.
>
> Passing data around, whether as function arguments or closed-over
> variables, increases data locality, reducing the mental scope that you need
> to keep active when working on a given piece of code. Having everything you
> care about right in front of your eyes makes it easier to keep track of
> what's what, compared to having to remember where and why was that
> identifier defined. Of course, that is assuming functions are kept
> reasonably short.
>
>>
>>
>
>> If I was to use a init func to initialize w and c, how do I pass them to
>> main? Or any initialization, really?
>>
>>
>> I have yet to see a good reason to use init funcs in a main package. Not
> saying there can never be, just that I haven't encountered any situation
> where the contents of init could not be just added to the beginning of the
> main func, without any change in behaviour. At least in your example, you
> could do just that and not need to pass anything into main.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Modifying the Runtime Scheduler

[Michael Jones]

I have no experience with this code...but a lot of debugging experience.

Since you think you know the general problem and have both hands inside the
patient already, why not (for now) modify the GC scanner to always look at
your batch’s pointer list and explicitly avoid messing with them.

Then you should be (a) able to validate your sense of the problem, (b) run
with GC on, and (c) do diagnostic stack traces precisely from the “yes it
is in the span of protected batch-related addresses” line and thereby see
the call stack that presently leads to harm.

Just a thought, maybe not a good one.

On Mon, Apr 8, 2019 at 11:50 AM Tharen Abela  wrote:

> I am keeping an `allb` slice, and with that I did see it occasionally
> succeed.
>
> I am using the binarytree
> 
> test, since it is an issue regarding the GC.
> In fact running it with GOGC=off, or also keep a slice with pointers in
> the program, does consistently succeed, as well.
>
> What I do know is when I allocate a batch, I keep a raw pointer in the
> slice, and is never popped or removed from there at any point.
> P's will keep their own batch using a uintptr, and the others are stored
> in either a global batch queue, or a queue of empty batches, the same as
> gQueue but for the batch type *b*uintptr: all of which are irrelevant to
> the GC.
>
> Now I modified the batch allocation to show me the pointer of `allb` and
> the new batch allocated:
> // Allocate a new batch
> //go:nosplit
> //go:yeswritebarrierrec
> func allocb() *b {
> // Break the cycle by doing acquirem/releasem around new(b).
> // The acquirem/releasem increments m.locks during new(b),
> // which keeps the garbage collector from being invoked.
> mp := acquirem()
>
> var bp *b
>
> bp = new(b)
> allb = append(allb, bp)
> print("allb: ", allb, ", bp:", bp, "\n")
>
> releasem(mp)
> return bp
> }
>
> With GOGC=off I get that 6 batches have been created
> GOGC=off GODEBUG=gccheckmark=1 gobatch run ./binarytree.go
> allb: [1/1]0xc10010, bp:0xc160f0
> allb: [2/2]0xc12010, bp:0xc16100
> allb: [3/4]0xc0e020, bp:0xc16110
> allb: [4/4]0xc0e020, bp:0xc16120
> allb: [5/8]0xc62000, bp:0xc6
> allb: [6/8]0xc62000, bp:0xc60010
>
> When it does succeed with the GC on, it consistently takes 13 batches,
> which I find rather odd.
> GODEBUG=gccheckmark=1 gobatch run ./binarytree.go
> allb: [1/1]0xc10010, bp:0xc160f0
> allb: [2/2]0xc12010, bp:0xc16100
> allb: [3/4]0xc0e020, bp:0xc16110
> allb: [4/4]0xc0e020, bp:0xc16120
> allb: [5/8]0xc62000, bp:0xc6
> allb: [6/8]0xc62000, bp:0xc60010
> allb: [7/8]0xc62000, bp:0xc16150
> allb: [8/8]0xc62000, bp:0xc0004b8000
> allb: [9/16]0xc00051, bp:0xc00044a040
> allb: [10/16]0xc00051, bp:0xc000514000
> allb: [11/16]0xc00051, bp:0xc00054
> allb: [12/16]0xc00051, bp:0xc0004b8010
> allb: [13/16]0xc00051, bp:0xc0004b8020
>
> Now when it crashes it returns the following: (full stack trace on
> pastebin) 
> GODEBUG=gccheckmark=1 gobatch run ./binarytree.go
> allb: [1/1]0xc10010, bp:0xc160f0
> allb: [2/2]0xc12010, bp:0xc16100
> allb: [3/4]0xc0e020, bp:0xc16110
> allb: [4/4]0xc0e020, bp:0xc16120
> allb: [5/8]0xc6a000, bp:0xc68000
> allb: [6/8]0xc6a000, bp:0xc68010
> allb: [7/8]0xc6a000, bp:0xc16170
> allb: [8/8]0xc6a000, bp:0xc0004b4000
> allb: [9/16]0xc0004ea000, bp:0xc0004b4010
> allb: [10/16]0xc0004ea000, bp:0xc0004ee000
> allb: [11/16]0xc0004ea000, bp:0xc000448040
> runtime: marking free object 0xc000448040 found at *(0xc0004ea000+0x50)
> base=0xc0004ea000 s.base()=0xc0004ea000 s.limit=0xc0004ec000 s.spanclass=
> 18 s.elemsize=128 s.state=mSpanInUse
>  *(base+0) = 0xc160f0
>  *(base+8) = 0xc16100
>  *(base+16) = 0xc16110
>  *(base+24) = 0xc16120
>  *(base+32) = 0xc68000
>  *(base+40) = 0xc68010
>  *(base+48) = 0xc16170
>  *(base+56) = 0xc0004b4000
>  *(base+64) = 0xc0004b4010
>  *(base+72) = 0xc0004ee000
>  *(base+80) = 0xc000448040 <==
>  *(base+88) = 0x0
>  *(base+96) = 0x0
>  *(base+104) = 0x0
>  *(base+112) = 0x0
>  *(base+120) = 0x0
> obj=0xc000448040 s.base()=0xc000448000 s.limit=0xc00044a000 s.spanclass=5
> s.elemsize=16 s.state=mSpanInUse
>  *(obj+0) = 0x0
>  *(obj+8) = 0xc0004ee000
> fatal error: marking free object
>
> At this point i'm assuming the error has been done, and the trace is just
> when it was realized to be wrong.
>
> What I do notice is that its not always at the same level when the error
> is noticed:
> for the full stack trace, it was when the depth was 3, ...
> goroutine 1 [runnable]:runtime.newobject(0x464820, 0x2)
> /go.batch/src/runtime/malloc.go:1067 +0x51 fp=0xc84b20 sp=
> 0xc84b18 pc=0x40a701
> main.bottomUpTree(0xff

Re: [go-nuts] Re: [ANN] Gomail v2: sending emails faster

[Michael Jones]

If those black boxes represent Go language code, please share it here by
pasting it into the Go Language Playground and then sharing a link in email
here.

It is impossible to understand these rectangles on my phone.

On Sat, Apr 6, 2019 at 11:10 PM  wrote:

> hi, i use this code, I can't make it work help
>
> Could you tell me how to properly use your library on this code, and set
> an example for a custom dealer, so that I can access the smtp through a
> proxy (sock4, sock4a, or sock5)? is it possible? please a couple of lines
> of code for an example
>
> func main() {
>
>
>ch := make(chan *gomail.Message, 10)
>
>// Use the channel in your program to send emails.
>m := gomail.NewMessage()
>m.SetHeader("From", "ifabion.bai...@mail.bcu.ac.uk")
>m.SetHeader("To", "t...@mail.com")
>
>//m.SetAddressHeader("Cc", "d...@example.com", "Dan")
>m.SetHeader("Subject", "Hello!")
>m.SetBody("text/html", "Hello Bob and Cora!")
>//m.Attach("/home/Alex/lolcat.jpg")
>
>ch <- m
>
>go func() {
>   d := gomail.NewDialer("smtp-mail.outlook.com", 587, 
> "ifabion.bai...@mail.bcu.ac.uk", "pwd")
>
>   var s gomail.SendCloser
>
>   var err error
>   open := false
>   for {
>  select {
>  case m, ok := <-ch:
> if !ok {
>return
> }
> if !open {
>if s, err = d.Dial(); err != nil {
>   panic(err)
>}
>open = true
> }
> if err := gomail.Send(s, m); err != nil {
>log.Print(err)
> }
>  // Close the connection to the SMTP server if no email was sent in
>  // the last 30 seconds.
>  case <-time.After(30 * time.Second):
> if open {
>if err := s.Close(); err != nil {
>   panic(err)
>}
>open = false
> }
>  }
>   }
>}()
>
> }
>
>
>
>
>// Close the channel to stop the mail daemon.
>close(ch)
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What happens when you call another method within a method set at the end of a method

[Michael Jones]

The opportunity to optimize yb tail-call elimination comes up in my coding
from time to time. It is generally trivial to do but sometimes less so, and
this example by Ian Denhardt is one I'd never considered and one that would
make doing the rewrite yourself impossible.


Generally though it is very simple. The basic recipe is this:

func name(arg1, arg2, argN) (result) {
code // first line of body
:
x = name(a,b,c) // optional recursive body call of function
:
if (j = y) {
return
}
result = name(d, e, f) // tail-call of function
return
}

becomes

func name(arg1, arg2, argN) (result) {
*for { // added forever loop head before first line*
code // first line of body
:
x = name(a,b,c) // optional recursive body call of function
if (j = y) {
   * break // return changes to break*
}
 *   // result = name(d, e, f) // tail-call of function*
*arg1, arg2, argN = d, e, f // tail-call becomes simple argument
assignment*
*} // added forever loop close after last line*
return
}


On Sat, Apr 6, 2019 at 10:23 AM Ian Denhardt  wrote:

> Quoting Robert Engels (2019-04-06 08:00:02)
>
> >But yes, similar to how all recursive functions can be rewritten using
> >loops, which are more efficient, that is essentially what tail call
> >optimization does - just that the process it automatic.
>
> Not all recursive functions -- just tail calls. If you do stuff after
> the call then you need to save state, which is what the call stack is
> for.
>
> You *could* use an explicit stack instead of using the call stack, but
> whether this is more or less efficient is highly dependent on your
> language implementation and the stack data structure you're using; I see
> no reason to believe it would necessarily be more efficient in general.
>
> ---
>
> Adding tail calls also has a few gotchas depending on how it interacts
> with other parts of the language. For example, in the case of:
>
>
> ```
> func foo () {
> ...
> defer x.Close()
> ...
> return bar()
> }
> ```
>
> The call to `bar()` is *NOT* a tail call, because `x.Close()` must be
> called before the function actually returns. So this means they interact
> in non-obvious ways with other parts of the language. One of the things
> I like about Go is that most of the features interact in ways that are
> easy to predict.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: proposal: Go 2: add untyped() type conversion for integer constants #31076

[Michael Jones]

I updated https://github.com/golang/go/issues/31076 to reflect the comments
here.
Thank you both.

On Fri, Mar 29, 2019 at 9:57 AM Ian Lance Taylor  wrote:

> On Thu, Mar 28, 2019 at 11:17 PM Jan Mercl <0xj...@gmail.com> wrote:
> >
> > The Compatibility section of the proposal says: "I think that this would
> break no existing code, as a user function invocation untyped(EXPR) is not
> at present allowed in constant specifications."
> >
> > It's true that user function cannot be called in a constant expression.
> But conversion to a user defined type is legal:
> https://play.golang.org/p/AXSFzMR677c
> >
> > IOW, the proposal is not backwards compatible.
>
> If we treat untyped as an ordinary predeclared identifier, then I
> think the proposal remains backward compatible.  The new predeclared
> untyped is not available in packages that defined the name untyped in
> package scope.  And there is no other way write untyped(EXPR).
>
> Ian
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: proposal: Go 2: add untyped() type conversion for integer constants #31076

[Michael Jones]

Very helpful. Thank you. I will edit my proposal based on this.

On Thu, Mar 28, 2019 at 11:17 PM Jan Mercl <0xj...@gmail.com> wrote:

> The Compatibility section of the proposal says: "I think that this would
> break no existing code, as a user function invocation untyped(EXPR) is not
> at present allowed in constant specifications."
>
> It's true that user function cannot be called in a constant expression.
> But conversion to a user defined type is legal:
> https://play.golang.org/p/AXSFzMR677c
>
> IOW, the proposal is not backwards compatible.
>
> PS: Sorry for replying here. Still no other way available w/o a Github
> account.
>
> --
>
> -j
>
-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Very long API call

[Michael Jones]

"*"

On Wed, Mar 27, 2019 at 1:06 PM Michael Jones 
wrote:

> You left off the "=" key. Must be "160 * 60 =" if you want the
> calculator to display the result. (Or "160 enter 60 +" if using an HP
> RPN calculator.)
>
> On Wed, Mar 27, 2019 at 12:35 PM Kurtis Rader 
> wrote:
>
>> On Wed, Mar 27, 2019 at 12:30 PM Alex Dvoretskiy 
>> wrote:
>>
>>> I ran into a huge API call. 160 * 60. Can it be normal? Or something
>>> should be changed here for sure?
>>>
>>
>> Which API call? What arguments were passed to it? What are the units for
>> those numbers? I don't like to be snarky but your question is completely
>> devoid of any useful information.
>>
>> --
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> *Michael T. jonesmichael.jo...@gmail.com *
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Very long API call

[Michael Jones]

You left off the "=" key. Must be "160 * 60 =" if you want the
calculator to display the result. (Or "160 enter 60 +" if using an HP
RPN calculator.)

On Wed, Mar 27, 2019 at 12:35 PM Kurtis Rader  wrote:

> On Wed, Mar 27, 2019 at 12:30 PM Alex Dvoretskiy 
> wrote:
>
>> I ran into a huge API call. 160 * 60. Can it be normal? Or something
>> should be changed here for sure?
>>
>
> Which API call? What arguments were passed to it? What are the units for
> those numbers? I don't like to be snarky but your question is completely
> devoid of any useful information.
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Question regarding gob

[Michael Jones]

There is certainly no reason why pointer semantic meaning cannot be
supported in encode/decode tools for Go. It does not seem hard to do, but
there was a choice not to do it. I shared my understanding of the reason,
but that's not a suggestion of difficulty or impossibility.

The most natural implementation uses a map in both the encoder and decoder.
The least memory way uses the existing pointer values as the instance ID. A
refinement uses 2x map memory but is more compressible in the wire format.

encoder:
  if next item is a pointer{
is pointer NOT in the map of previously sent pointers?
  recursively encode/transmit *pointer and use uintptr(pointer) as its
ID.
send "next thing is a pointer to a T; value is whatever you
(reconstructor) generated for ID uintptr(pointer)"
}

decoder:
  opposite of this, where the map has IDs sent and pointers to locally
allocated objects.

That is all it takes. More suave is to have the map not just be a
map[uintptr]struct{} but of map[uintptr]uint64, where the ID is a serial
number counting up. This would be invisible to the decoder, but real
addresses sent as IDs will be big numbers in a 64-bit address space and
take more bits to encode than one byte 0..255, two byte 256..65535, ...

On Tue, Mar 26, 2019 at 3:44 PM Robert Engels  wrote:

> Yes, when using pointers and cycles you need to either use ids in the
> encoding or break the cycle by dropping the cyclic fields (for example, a
> simple ‘parent’ field causes an infinite cycle so drop it and make it
> implicit)
>
> On Mar 26, 2019, at 2:27 PM, Thomas Bushnell, BSG 
> wrote:
>
> I mean, everything except the things that are not pointers.
>
> On Tue, Mar 26, 2019 at 2:45 PM Robert Engels 
> wrote:
>
>> This is not really true. In Java everything is a pointer (reference) and
>> has no problem with the semantics of passing a reference, it is built into
>> the serialization. They may be in fact passed as a pointer (local rpc) or
>> passed as a copy of the object graph, or something in between (custom).
>>
>> There is no reason Go can not achieve use the same paradigm.
>>
>> On Mar 26, 2019, at 11:48 AM, Michael Jones 
>> wrote:
>>
>> To be clear here as educators, it is important to point out that
>> exporting / persisting / sending a pointer is an awkward concept.
>>
>> The normal meanings of sending data beyond an executing program have no
>> direct use for the pointer’s literal value; “the thing at location 12345 in
>> the memory of a program that ran last year” is not much help.
>>
>> On the other hand, one might imagine pointers being like file names and
>> then recreate both content and references during reading. The export format
>> could persist all the typed, pointed to values in tables, and then for each
>> pointer variable exported send instead advice like “put the address of the
>> 456th element of the table for type C things in this pointer slot.”
>>
>> A persistent format supporting this way of recreating the semantics of
>> pointers is very much like an archive format (Zip) with support for
>> symbolic links. It is not particularly hard to implement, but it is a
>> “heavyweight” approach. My sense is that the common desire in export tools
>> is high speed and byte efficiency so it is natural that Gob and other
>> mechanisms adopt the “pointers don’t make sense for export” argument.
>>
>> Michael
>>
>> On Tue, Mar 26, 2019 at 6:01 AM roger peppe  wrote:
>>
>>>
>>>
>>> On Mon, 25 Mar 2019 at 14:45, Glen Huang  wrote:
>>>
>>>> Thanks for the reply, Sameer.
>>>>
>>>> Being able to directly send go types is a really big plus for me, I
>>>> wonder if I really want to use gob, are there any recommended rpc choices?
>>>>
>>>
>>> Note that gob has at least one significant limitation when encoding Go
>>> types - it doesn't know about pointers - in general it encodes a pointer by
>>> omitting a field. So if you want to send a slice of a pointer type where
>>> some elements can be nil, you're out of luck:
>>> https://play.golang.org/p/ThVUT_M0hjR
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>>
>> *Michael T. jonesmichael.jo...@gmail.com *
>>
>> --
>> You received this message because you are subscribe

Re: [go-nuts] Question regarding gob

[Michael Jones]

To be clear here as educators, it is important to point out that exporting
/ persisting / sending a pointer is an awkward concept.

The normal meanings of sending data beyond an executing program have no
direct use for the pointer’s literal value; “the thing at location 12345 in
the memory of a program that ran last year” is not much help.

On the other hand, one might imagine pointers being like file names and
then recreate both content and references during reading. The export format
could persist all the typed, pointed to values in tables, and then for each
pointer variable exported send instead advice like “put the address of the
456th element of the table for type C things in this pointer slot.”

A persistent format supporting this way of recreating the semantics of
pointers is very much like an archive format (Zip) with support for
symbolic links. It is not particularly hard to implement, but it is a
“heavyweight” approach. My sense is that the common desire in export tools
is high speed and byte efficiency so it is natural that Gob and other
mechanisms adopt the “pointers don’t make sense for export” argument.

Michael

On Tue, Mar 26, 2019 at 6:01 AM roger peppe  wrote:

>
>
> On Mon, 25 Mar 2019 at 14:45, Glen Huang  wrote:
>
>> Thanks for the reply, Sameer.
>>
>> Being able to directly send go types is a really big plus for me, I
>> wonder if I really want to use gob, are there any recommended rpc choices?
>>
>
> Note that gob has at least one significant limitation when encoding Go
> types - it doesn't know about pointers - in general it encodes a pointer by
> omitting a field. So if you want to send a slice of a pointer type where
> some elements can be nil, you're out of luck:
> https://play.golang.org/p/ThVUT_M0hjR
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why the XOR between*(*[]uintptr)(unsafe.Pointer(&dst)) is fast then []byte

[Michael Jones]

Good point

On Tue, Mar 19, 2019 at 6:15 AM roger peppe  wrote:

> On Tue, 19 Mar 2019 at 07:32, Michael Jones 
> wrote:
>
>> Ok, at my computer now so time for a longer answer.
>>
>> What you want is this:
>> https://play.golang.org/p/QirBtj523Wu
>>
>
> I think that's wrong too, as the byte slices might not be word aligned, so
> on some architectures, that code will panic due to unaligned access. To do
> it right, you'd need to do the word arithmetic only on the aligned parts of
> the slice (and only if all the slices are equally aligned), and use
> bytewise arithmetic on the unaligned
> start and end bytes.
>
> The original also used loop unrolling which could speed things up quite a
> bit, but adds complexity. Using uintptr rather than uint64 is likewise
> probably faster on non-64-bit architectures.
>
-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why the XOR between*(*[]uintptr)(unsafe.Pointer(&dst)) is fast then []byte

[Michael Jones]

Ok, at my computer now so time for a longer answer.

What you want is this:
https://play.golang.org/p/QirBtj523Wu

Now, what's wrong with the code you sent? Quite a few things actually.
Maybe you should start with the code shared above and then work through
what it is doing, then compare that with the original alternatives.

Michael

On Mon, Mar 18, 2019 at 9:58 PM Michael Jones 
wrote:

> n%8 is not what you want.
>
> n - n%8 is what you want, best expressed as n &^0x7
>
> On Mon, Mar 18, 2019 at 7:36 PM zhou yu  wrote:
>
>> *Why the XOR between*(*[]uintptr)(unsafe.Pointer(&dst)) is fast then
>> []byte?*
>>
>> I find a fast xor lib https://github.com/templexxx/xor, and write the
>> benchmark below,
>>
>> the result show that BenchmarkFastXORWords is 5x faster than BenchmarkS
>> afeXORBytes on my computer
>>
>>  I can't figure out why? Anyone can help me. THX
>>
>> package main
>>
>> import (
>>"math/rand"
>>"testing"
>>"unsafe"
>> )
>>
>> const wordSize = int(unsafe.Sizeof(uintptr(0)))
>>
>> var e = make([]byte, 160)
>> var f = make([]byte, 160)
>> var g = make([]byte, 160)
>>
>> func init() {
>>for i := 0; i < 160; i++ {
>>rand.Seed(22)
>>e[i] = byte(rand.Intn(256))
>>f[i] = byte(rand.Intn(256))
>>}
>> }
>>
>> func BenchmarkSafeXORBytes(b *testing.B) {
>>for i := 0; i < b.N; i++ {
>>safeXORBytes(g, e, f)
>>}
>> }
>>
>> func BenchmarkFastXORWords(b *testing.B) {
>>for i := 0; i < b.N; i++ {
>>fastXORWords(g, e, f)
>>}
>> }
>>
>> func safeXORBytes(dst, a, b []byte) {
>>n := len(a)
>>ex := n % 8
>>for i := 0; i < ex; i++ {
>>dst[i] = a[i] ^ b[i]
>>}
>>
>> for i := ex; i < n; i += 8 {
>>_dst := dst[i : i+8]
>>_a := a[i : i+8]
>>_b := b[i : i+8]
>>_dst[0] = _a[0] ^ _b[0]
>>_dst[1] = _a[1] ^ _b[1]
>>_dst[2] = _a[2] ^ _b[2]
>>_dst[3] = _a[3] ^ _b[3]
>>
>> _dst[4] = _a[4] ^ _b[4]
>>_dst[5] = _a[5] ^ _b[5]
>>_dst[6] = _a[6] ^ _b[6]
>>_dst[7] = _a[7] ^ _b[7]
>>}
>> }
>>
>> func fastXORWords(dst, a, b []byte) {
>>dw := *(*[]uintptr)(unsafe.Pointer(&dst))
>>aw := *(*[]uintptr)(unsafe.Pointer(&a))
>>bw := *(*[]uintptr)(unsafe.Pointer(&b))
>>n := len(b) / wordSize
>>ex := n % 8
>>for i := 0; i < ex; i++ {
>>dw[i] = aw[i] ^ bw[i]
>>}
>>
>> for i := ex; i < n; i += 8 {
>>_dw := dw[i : i+8]
>>_aw := aw[i : i+8]
>>_bw := bw[i : i+8]
>>_dw[0] = _aw[0] ^ _bw[0]
>>_dw[1] = _aw[1] ^ _bw[1]
>>_dw[2] = _aw[2] ^ _bw[2]
>>_dw[3] = _aw[3] ^ _bw[3]
>>_dw[4] = _aw[4] ^ _bw[4]
>>_dw[5] = _aw[5] ^ _bw[5]
>>_dw[6] = _aw[6] ^ _bw[6]
>>_dw[7] = _aw[7] ^ _bw[7]
>>}
>> }
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> *Michael T. jonesmichael.jo...@gmail.com *
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why the XOR between*(*[]uintptr)(unsafe.Pointer(&dst)) is fast then []byte

[Michael Jones]

n%8 is not what you want.

n - n%8 is what you want, best expressed as n &^0x7

On Mon, Mar 18, 2019 at 7:36 PM zhou yu  wrote:

> *Why the XOR between*(*[]uintptr)(unsafe.Pointer(&dst)) is fast then
> []byte?*
>
> I find a fast xor lib https://github.com/templexxx/xor, and write the
> benchmark below,
>
> the result show that BenchmarkFastXORWords is 5x faster than BenchmarkS
> afeXORBytes on my computer
>
>  I can't figure out why? Anyone can help me. THX
>
> package main
>
> import (
>"math/rand"
>"testing"
>"unsafe"
> )
>
> const wordSize = int(unsafe.Sizeof(uintptr(0)))
>
> var e = make([]byte, 160)
> var f = make([]byte, 160)
> var g = make([]byte, 160)
>
> func init() {
>for i := 0; i < 160; i++ {
>rand.Seed(22)
>e[i] = byte(rand.Intn(256))
>f[i] = byte(rand.Intn(256))
>}
> }
>
> func BenchmarkSafeXORBytes(b *testing.B) {
>for i := 0; i < b.N; i++ {
>safeXORBytes(g, e, f)
>}
> }
>
> func BenchmarkFastXORWords(b *testing.B) {
>for i := 0; i < b.N; i++ {
>fastXORWords(g, e, f)
>}
> }
>
> func safeXORBytes(dst, a, b []byte) {
>n := len(a)
>ex := n % 8
>for i := 0; i < ex; i++ {
>dst[i] = a[i] ^ b[i]
>}
>
> for i := ex; i < n; i += 8 {
>_dst := dst[i : i+8]
>_a := a[i : i+8]
>_b := b[i : i+8]
>_dst[0] = _a[0] ^ _b[0]
>_dst[1] = _a[1] ^ _b[1]
>_dst[2] = _a[2] ^ _b[2]
>_dst[3] = _a[3] ^ _b[3]
>
> _dst[4] = _a[4] ^ _b[4]
>_dst[5] = _a[5] ^ _b[5]
>_dst[6] = _a[6] ^ _b[6]
>_dst[7] = _a[7] ^ _b[7]
>}
> }
>
> func fastXORWords(dst, a, b []byte) {
>dw := *(*[]uintptr)(unsafe.Pointer(&dst))
>aw := *(*[]uintptr)(unsafe.Pointer(&a))
>bw := *(*[]uintptr)(unsafe.Pointer(&b))
>n := len(b) / wordSize
>ex := n % 8
>for i := 0; i < ex; i++ {
>dw[i] = aw[i] ^ bw[i]
>}
>
> for i := ex; i < n; i += 8 {
>_dw := dw[i : i+8]
>_aw := aw[i : i+8]
>_bw := bw[i : i+8]
>_dw[0] = _aw[0] ^ _bw[0]
>_dw[1] = _aw[1] ^ _bw[1]
>_dw[2] = _aw[2] ^ _bw[2]
>_dw[3] = _aw[3] ^ _bw[3]
>_dw[4] = _aw[4] ^ _bw[4]
>_dw[5] = _aw[5] ^ _bw[5]
>_dw[6] = _aw[6] ^ _bw[6]
>_dw[7] = _aw[7] ^ _bw[7]
>}
> }
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] protobuf and golang

[Michael Jones]

Yes, the way to think of the topic here is: first, write your own code to
decode the legacy format, then arrange the data in a struct of your design,
and *then* persist the struct or slice of structs using an encode/decode
mechanism of choice, such as gob, protobuf, json, etc.

Step one here is your present task. It is as easy or hard as the old format
makes it. This is made a little easier in Go by the standard library tools
for byte order decoding, hex decoding, etc.

Step two is trivial to implement but is a design decision worth investing
some thought.

Step three, where you were starting, will be effortless after #1 and 2.

On Mon, Mar 18, 2019 at 11:10 AM Kurtis Rader  wrote:

> On Mon, Mar 18, 2019 at 10:00 AM R Srinivasan  wrote:
>
>> i am investigating the use of go+protobuf for reading binary files of a
>> legacy design.
>>
>
>> my intial attempts to define the data structures have hit a roadblock -
>> support for data types such as uint16, int16, uint8, int8. Is this an
>> inherent protobuf limitation or am i overlooking something.
>>
>
> The protobuf subsystem cannot be used to read/write arbitrary binary
> formats. Binary protobufs use a very efficient, compact, encoding that is
> architecture neutral. For example, int fields are encoded the same way
> regardless of whether your CPU is little or big endian.
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go 1.12.1 and Go 1.11.6 are released

[Michael Jones]

I don't have direct feedback on this, but I do have an observation based on
my own faster-sort code, which is that timing seems about the same, and
scaling seems different than this report.

The sorty_test.go file starts with "const N = 1 << 28" so we're talking
about sorting a 268,435,456-element array of ints. In that code, they are
uint32s and float32s, in mine, 64-bit ints. I should be slower, but
adjusting my benchmarks for this array size I see:

go standard library sort.Ints()
54669865378 ns/op
54.6 sec

my quicksort
21398838106 ns/op
21.3 sec (2.55x stdlib)

my parallel quicksort
5428725888 ns/op
5.4 sec (10.0x stdlib, 3.94x serial version on my 4 cpu macbook pro)

These are 64-bit values and 32-bit should is just slightly faster
5318033205 ns/op
5.3 sec

I don't see a slowdown here Go version to version. Of course 10x slower in
the standard library vs tuned parallel is unfortunate.

Michael

On Sun, Mar 17, 2019 at 4:35 PM Ian Lance Taylor  wrote:

> On Sun, Mar 17, 2019 at 1:46 PM Serhat Şevki Dinçer 
> wrote:
> >
> > I see a regression on speed with sorty tests (go test -short -gcflags
> '-B -s' -ldflags '-s -w') on my Intel Core i5-4210M laptop (also sortutil
> became faster, zermelo float became much slower):
>
> Please open an issue with full details.  Thanks.
>
> 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.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Order of evaluation need more definition in spec

[Michael Jones]

Upon reflection I see that this is as you say. Not only expressed hazards,
but even such mysterious cases as file system modification yb external
scripts invoked by one argument and visible to another.

On Sat, Mar 16, 2019 at 10:03 PM T L  wrote:

>
>
> On Friday, March 15, 2019 at 2:25:44 PM UTC-4, zs...@pinterest.com wrote:
>>
>> Thanks for response, I'm new here still need do more research on existing
>> topics.
>>
>> I understand compiler can do more optimization with less order
>> restriction, and I agree it's best to not coding in that way. The problem
>> is how to prevent people doing that since it's very similar to the usual
>> return multiple values style. Is it possible to add the check in golint,
>> such as when any comma separated expression (including return, assignment,
>> func parameters etc) contains variable who is also referenced in a func
>> closure (or get pointer in a func parameter) in the same expression, shows
>> a warning say the execution order is unspecified may cause bug?
>>
>
> It is possible for a linter to find some simple such cases. But it is hard
> to find some complicated cases.
> I ever wrote such a linter (not published). It only works for some simple
> cases.
> For my inexperience in using g0.* packages, the linter run very slow even
> for the simple cases.
> And I found that it is almost impossible to some complicated cases in
> theory.
>
>>
>>
>>
>> On Thursday, March 14, 2019 at 8:04:12 PM UTC-7, Ian Lance Taylor wrote:
>>
>>> On Thu, Mar 14, 2019 at 2:49 PM zshi via golang-nuts
>>>  wrote:
>>> >
>>> > I'm a little bit confused with result from below code:
>>> >
>>> > func change(v *int) bool {
>>> > *v = 3
>>> > return true
>>> > }
>>> >
>>> > func value(v int) int {
>>> > return v
>>> > }
>>> >
>>> > func main() {
>>> > b := 1
>>> > fmt.Println(b + 1, value(b + 1), change(&b))
>>> > }
>>> >
>>> > Output:
>>> >
>>> > 4 2 true
>>> >
>>> >
>>> > I expected 2 2 true. Then I checked spec, it said:
>>> > "all function calls, method calls, and communication operations
>>> are evaluated in lexical left-to-right order."
>>> > and:
>>> > "However, the order of those events compared to the evaluation and
>>> indexing of x and the evaluation of y is not specified."
>>> > So from that we can say both 4 2 and 2 2 are correct based on spec,
>>> although the implementation choose putting expression evaluated after all
>>> the function calls.
>>> >
>>> > I think it's better written into spec rather than say not specified.
>>> Why? because I already see some production code with below pattern:
>>> > .
>>> > return b, change(&b)
>>> > }
>>> > (the real production code use a function closure which directly modify
>>> b without pointer, but I think the order issue is same)
>>> >
>>> > I don't know if this pattern is used a lot in other place since I'm
>>> still new to golang, but people writing go style probably like this way.
>>> Since it depends on a not specified behavior which has risk to change in
>>> future and very hard to debug, I think it's better written into spec which
>>> make sure it won't change in future.
>>> >
>>> > Any thoughts?
>>>
>>> This kind of discussion has been had several times, e.g.,
>>> https://golang.org/issue/23735.  In general I don't think there has
>>> been a strong sentiment for precisely specifying evaluation order down
>>> to the level of exactly when the value of a variable is evaluated.
>>> The advantage of doing so is that code such as you describe becomes
>>> precisely specified.  The disadvantage is that the compiler has much
>>> less scope for optimization.
>>>
>>> In general, code such as you describe is confusing and hard to read.
>>> It's impossible to recommend that people write code that way.  And if
>>> we make that unclear code precisely specified, then the compiler will
>>> be forced to generate slower code even for clear code.
>>>
>>> So well there is an argument for fully specifying the code as you
>>> suggest, there is also an argument for leaving it unspecified.
>>>
>>> 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.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] modules and GoSublime

[Michael Jones]

Have not been able to rescue sublime text from module confusion. It is sad
on startup with:

| GoSublime error: MarGo build failed
|> This is possibly a bug or miss-configuration of your
environment.
|> For more help, please file an issue with the following
build output
|> at: https://github.com/DisposaBoy/GoSublime/issues/new
|> or alternatively, you may send an email to:
gosubl...@dby.me
|>
|>
|> cmd: `['~/go/bin/go', 'build', '-tags', '', '-v', '-o',
'gosublime.margo_r18.07.22-1_devel..7765576e09.exe', 'gosublime/cmd/margo']`
|> stdout: `
|>
|> `
|> stderr: `
|> can't load package: package gosublime/cmd/margo: unknown
import path "gosublime/cmd/margo": cannot find module providing package
gosublime/cmd/margo
|> `
|> exception: `None`
|   install state: busy
| sublime.version: 3200
| sublime.channel: stable
|   about.ann: a18.07.31-1
|   about.version: r18.07.22-1
| version: r18.07.22-1
|platform: osx-x64
|~bin: ~/Library/Application Support/Sublime Text
3/Packages/User/GoSublime/osx-x64/bin
|   margo.exe: ~bin/gosublime.margo_r18.07.22-1_devel..7765576e09.exe
(missing)
|  go.exe: ~/go/bin/go (ok)
|  go.version: devel..7765576e09
|  GOROOT: ~/go
|  GOPATH: ~/Documents/gocode
|   GOBIN: (not set)
|   set.shell: []
|   env.shell: /bin/bash
|   shell.cmd: ['/bin/bash', '-l', '-c', '${CMD}']
|sh.bootstrap:
|> using shell env GOPATH=~/Documents/gocode
|> using shell env GOROOT=~/go
|> using shell env
PATH=/opt/local/bin:/opt/local/sbin:~/go/bin:~/Documents/gocode/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/usr/local/go/bin:~/go/bin:~/Documents/gocode/bin:/opt/local/bin:/opt/local/sbin:~/bin:/usr/local/opt/go/bin
|> go version: `devel..7765576e09` (raw version string
`devel +7765576e09 Fri Mar 15 23:27:36 2019 +`)
|> shell bootstrap took 0.178s
|>

...and I've yet to find a form of go.mod that mollifies the compiler. I've
tried placing the mod file in ~/Library/Application Support/Sublime Text
3/Packages/GoSublime/src/gosublime/cmd/margo and various places near there.
I've tried various ways of saying "the files are over here." But no success
yet,

I hope this smoothes out -- for code not related to whatever the virtue
will be.

-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Order of evaluation need more definition in spec

[Michael Jones]

Great idea!

On Fri, Mar 15, 2019 at 11:25 AM zshi via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Thanks for response, I'm new here still need do more research on existing
> topics.
>
> I understand compiler can do more optimization with less order
> restriction, and I agree it's best to not coding in that way. The problem
> is how to prevent people doing that since it's very similar to the usual
> return multiple values style. Is it possible to add the check in golint,
> such as when any comma separated expression (including return, assignment,
> func parameters etc) contains variable who is also referenced in a func
> closure (or get pointer in a func parameter) in the same expression, shows
> a warning say the execution order is unspecified may cause bug?
>
>
> On Thursday, March 14, 2019 at 8:04:12 PM UTC-7, Ian Lance Taylor wrote:
>
>> On Thu, Mar 14, 2019 at 2:49 PM zshi via golang-nuts
>>  wrote:
>> >
>> > I'm a little bit confused with result from below code:
>> >
>> > func change(v *int) bool {
>> > *v = 3
>> > return true
>> > }
>> >
>> > func value(v int) int {
>> > return v
>> > }
>> >
>> > func main() {
>> > b := 1
>> > fmt.Println(b + 1, value(b + 1), change(&b))
>> > }
>> >
>> > Output:
>> >
>> > 4 2 true
>> >
>> >
>> > I expected 2 2 true. Then I checked spec, it said:
>> > "all function calls, method calls, and communication operations are
>> evaluated in lexical left-to-right order."
>> > and:
>> > "However, the order of those events compared to the evaluation and
>> indexing of x and the evaluation of y is not specified."
>> > So from that we can say both 4 2 and 2 2 are correct based on spec,
>> although the implementation choose putting expression evaluated after all
>> the function calls.
>> >
>> > I think it's better written into spec rather than say not specified.
>> Why? because I already see some production code with below pattern:
>> > .
>> > return b, change(&b)
>> > }
>> > (the real production code use a function closure which directly modify
>> b without pointer, but I think the order issue is same)
>> >
>> > I don't know if this pattern is used a lot in other place since I'm
>> still new to golang, but people writing go style probably like this way.
>> Since it depends on a not specified behavior which has risk to change in
>> future and very hard to debug, I think it's better written into spec which
>> make sure it won't change in future.
>> >
>> > Any thoughts?
>>
>> This kind of discussion has been had several times, e.g.,
>> https://golang.org/issue/23735.  In general I don't think there has
>> been a strong sentiment for precisely specifying evaluation order down
>> to the level of exactly when the value of a variable is evaluated.
>> The advantage of doing so is that code such as you describe becomes
>> precisely specified.  The disadvantage is that the compiler has much
>> less scope for optimization.
>>
>> In general, code such as you describe is confusing and hard to read.
>> It's impossible to recommend that people write code that way.  And if
>> we make that unclear code precisely specified, then the compiler will
>> be forced to generate slower code even for clear code.
>>
>> So well there is an argument for fully specifying the code as you
>> suggest, there is also an argument for leaving it unspecified.
>>
>> 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.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Pointer declaration syntax

[Michael Jones]

If you consider lv and rv in BCPL, and see how that becomes * and & in B
and stays that way in C/C++/... it may be more clear.

The C declaration syntax was revolutionary for being inside out. “int *p”
really means “p is the type of variable where *p means an int.” Your
argument seems right, in the outside in order of most every non-C language,
we are saying “var p X” where X should mean “address of an int” and that
is, as you say, “& int”

The installed base of programmers expects it the other way, though. 🙂

On Sun, Mar 10, 2019 at 9:18 AM 박민우  wrote:

> Thank you for the explanation!
>
> and sorry for the typo,
> I meant to say something like,
> someInteger := 0
> q := &someInteger
> or
> q := &SomeStructure{}
> as an example of & symbol as "pointer to".
>
> Anyway, I would say C's declaration syntax
> int *p
> makes more sense because *p , "where p points to", is int.
> However, it also makes sense to use the same asterisk for pointer
> declaration.
> Thank you for mentioning creation of other types too,
> It really helped me get over it ! :)
> I believe I just need some getting used to !
>
>
>
> 2019년 3월 10일 일요일 오후 11시 46분 13초 UTC+9, Ian Lance Taylor 님의 말:
>
>> On Sun, Mar 10, 2019 at 7:41 AM 박민우  wrote:
>> >
>> > I am new to Go and I have read Go;s-declaration-syntax documentation.
>> >
>> > It states that:
>> >
>> > p: pointer to int
>> >
>> > Would be written as:
>> > p *int
>> >
>> > However, other than declaration syntax, "&" is the symbol for "the
>> pointer to" like,
>> > q := &int
>> > The above code would be the same as:
>> > var q *int
>> > q = new(int)
>> > So, I would suggest,
>> > var q &int
>> > to be more consistent, but Go's syntax wouldn't permit this.
>> >
>> > Is there a reason behind this decision?
>> > I will get used to the syntax after a while, but in need of some
>> reasonable explanation.
>>
>> The reason boils down to: this is how it is done in C.  A pointer type
>> is written as *int.  A pointer variable q is dereferenced as *q.  That
>> is also what C looks like.
>>
>> Note that in Go there is no particular correspondence between the way
>> that a type is written and the way that a value of that type is
>> created. A map or chan type is created using the builtin function
>> make, or using a composite literal.  An int type is created by
>> declaration, or implicitly.  A slice type can be created by using a
>> slice expression on an array value.  The consistency you suggest just
>> doesn't exist for 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.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Performance comparison of Go, C++, and Java for biological sequencing tool

[Michael Jones]

I'm sorry Isaac, I meant multi-language benchmarking generally, nothing
about the specific case you mention so i was slightly tangential to your
original post.

On Thu, Mar 7, 2019 at 9:41 AM 'Isaac Gouy' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Wednesday, March 6, 2019 at 7:22:41 PM UTC-8, Michael Jones wrote:
>>
>> There is another problem about these microbenchmarks as well--they often
>> are ports of an originating C-version.
>>
>
> Which microbenchmarks?
>
> You quoted a reply to a question about "Performance comparison of Go, C++,
> and Java for biological sequencing tool".
>
> For those who haven't looked, that is about an evaluation (done by the
> authors of the elPrep tool) to select a new implementation language for the
> particular case of elPrep.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Performance comparison of Go, C++, and Java for biological sequencing tool

[Michael Jones]

There is another problem about these microbenchmarks as well--they often
are ports of an originating C-version.

I just implemented the Rabbit stream cipher and after reading the papers I
reviewed several versions online in Java and two in Go, as well as the now
open-source C version. It seems that they all started with the C version
and did a "c-to-Java" or "c-to-go-ization" of it. The results are not
strong for the language. My code took me a day and runs at 830 MB/s vs 620
MB/s peak for any of these. Now this is not a microbenchmark exactly and I
may have more experience than some, but it still shows that language-X
would seem to do a job at 620 that it could do at 830 with cleaner code.
That kind of difference is probably more than the difference between the
upper half of the performance reports.

The base code has the C-ism "... + (a wrote:

> On Wednesday, March 6, 2019 at 4:03:52 PM UTC-8, Bakul Shah wrote:
>>
>> Thanks for an interesting read!
>>
>> Curious to know if you guys have any estimates on the number of lines,
>> development time and number of bugs for each language implementation? I
>> realize this is subjective but this comparison may be quite meaningful
>> given that the authors had an existing reference implementation of a sort
>> done in CL. It is not often one sees real world examples of multiple
>> implementations done by a small team with the same goals.
>>
>
>
> One of the authors Pascal Costanza showed-up on programming reddit to
> remedy some misconceptions.
>
> You could ask him in-that-discussion
> 
> or email him directly.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] efficient random float32 number generator?

[Michael Jones]

My instinct (for "please invent for me the fastest possible low fidelity
floating point prng algorithm") is to look at RC4 for inspiration,
permuting the order of a large table of float32s and constantly modifying
them as well. This could be pared down to three index accesses, a floating
add/subtract, and a 32-bit swap.

On Mon, Feb 25, 2019 at 3:16 PM Rob Pike  wrote:

> If you don't need precision, just generate ints and scale them.
>
> -rob
>
>
> On Tue, Feb 26, 2019 at 9:39 AM DrGo  wrote:
>
>> Thanks Ian,
>> The std lib float32 is slow for my purpose. In my benchmarking it is
>> actually slower than the float64. But I don’t even need float16 precision.
>> I am working on implementing othe alias method for sampling from a fixed
>> freq dist with possibly thousands of arbitrary values. So the rng doesn’t
>> need to be precise or high quality because of rounding eg a rn of .67895
>> might end up selecting the same arbitrary value as .67091 or even .65!!
>> https://en.m.wikipedia.org/wiki/Alias_method
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] efficient random float32 number generator?

[Michael Jones]

My PCG library's 32-bit generator generates a 32-bit pseudo-random integer
in 2.23 ns.
https://github.com/MichaelTJones/pcg

Just wrote this 32-bit float extension and that delivers a float32 in 2.75
ns. (363 million/good values/sec, period of 2**64 = 4 billion). The extra
time is for the multiply:

func (p *PCG32) Float32() float32 {
const bits = 23
const denom = 1.0 / float32(1<>(32-bits)) * denom
}

The same thing, but with the 2**128 period generator is 6.91 ns/op per
float32

If you want faster than that then you'll need to look at other ways, likely
non-multiply ways.

IMPORTANT...

Also, be reminded that generating "random real values in [0..1)" is not the
same thing as "random floating point values in [0..1)".
it is subtle, and it seems you may want the former, but a random sampling
of float32's in that range would be different, using the exponent to scale
the 8 million possible mantissa fractions to various tiny ranges. There are
4 billion values total. so som big subsetting is happening.

On Mon, Feb 25, 2019 at 2:05 PM Ian Lance Taylor  wrote:

> On Mon, Feb 25, 2019 at 2:01 PM DrGo  wrote:
> >
> > what is the fastest possible algorithm to generate a float32
> pseudo-random number in [0.0,1.0)?
> > need to generate billions of numbers. Statistical performance and
> security (and even space) are not a priority.
> > any Go implementations you know of?
>
> Take a look at https://godoc.org/golang.org/x/exp/rand .
>
> 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.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Michael Jones]

That they do not work is an important issue as has been explained here
repeatedly.

On Fri, Feb 22, 2019 at 7:59 PM Victor Giordano 
wrote:

> Those idioms should be documented somewhere!
>
> I would use waiting groups for the rest of the job, i don't know.. have to
> think a little more.. you got the number of background task to wait for,
> right?
>
>
> El jueves, 21 de febrero de 2019, 10:47:07 (UTC-3), Jan Mercl escribió:
>>
>> On Thu, Feb 21, 2019 at 2:38 PM Serhat Şevki Dinçer 
>> wrote:
>>
>>
> Idiom 1
>
>
>> > waitempty(ch)
>> > blocks caller until ch buffer is empty
>>
>> Not exactly the same, but a similar mechanism exists:
>>
>> select {
>> case x := <-ch:
>> ...
>> default:
>> ... ch is empty
>> }
>>
>> > waitfull(ch)
>> > blocks caller until ch buffer is full
>>
>>
> Idiom 2
>
>> Dtto
>>
>> select {
>> case ch <- x:
>> ...
>> default:
>> ... ch is full
>> }
>>
>>
>> > What do you think?
>>
>> That the above is enough of gears to implement what you're after.
>>
>> --
>>
>> -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.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channel Feature Suggestion

[Michael Jones]

Serhat, imagine your feature in the context of a buffered channel that
holds 10 elements, and a writer go routine that wants to send 1000 elements
through that channel.

It is natural to imagine a downstream go routine reading and working on the
first element, and the writer filling the empty slot with #11 then being
blocked waiting to write #12.

But it is possible that the writer writes only #1, the reader reads it, the
channel is empty, and only later is #2 added to the channel, maybe when the
downstream go routine tries to read #2 and blocks, which might force the
runtime to continue the reader routine.

In this second case an outside observer would think "that channel is always
empty." It is unclear what meaning any instantaneous observation can have.

On Thu, Feb 21, 2019 at 12:20 PM Jan Mercl <0xj...@gmail.com> wrote:

> But then calling it or not has the exact same semantics. So what's it even
> good for?
>
> On Thu, Feb 21, 2019, 21:17 Serhat Şevki Dinçer 
> wrote:
>
>> btw waitempty(ch) does not return any value, and it does not (have to)
>> guarantee that ch stays empty when it returns..
>>
>>
>> On Thursday, February 21, 2019 at 11:10:45 PM UTC+3, Serhat Şevki Dinçer
>> wrote:
>>>
>>> Burak, I think you dont get the potential of the suggesred directives.
>>>
>>> You can be interested in waitepty(ch) for example when:
>>> - you have direct control of who is pushing and pulling on it, and you
>>> know what an empty buffer means
>>> buffer could be "things to do or process", and you have a very
>>> easy-to-setup observer to alert some routine that:
>>> - you are out of job, or
>>> - you have too many to process
>>>
>>> Also what you suggest as raciness is irrelevant:
>>>
>>> for {
>>>   x := <- ch {
>>> // here, do you have a guarantee that you can put x back to the
>>> channel ??
>>>   }
>>> }
>>>
>>> On Thursday, February 21, 2019 at 10:57:43 PM UTC+3, Burak Serdar wrote:

 You can implement waitempty(ch) without a race condition. However, any
 scenario in which you use waitempty(ch) would have a race condition,
 because the moment it returns there is no guarantee on the state of
 the channel. So in a piece of code like this:

 waitempty(ch)
 post


 the only guarantee you have is that when 'post' is running, ch was
 empty at least once since waitempty was called.

 This code:

 for {
   if waitempty(ch) {
 ...
   }
 }

 is racy, because when you go into the if block, you have no idea how
 many times ch was empty.

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


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] inverse of time.Duration?

[Michael Jones]

start := time.Now()
:
// work to be timed
:
elapsed := time.Now().Sub(start).Seconds()
hertz := 1.0/elapsed

On Fri, Feb 15, 2019 at 11:49 AM Hemant Singh  wrote:

> This is an example of time.Duration I have: 5.671msec
>
> I need to convert the duration to rate = 1.0/5.671 msec.
>
> However, time.Duration and float in 1.0 do not mix.  How do I get the rate?
>
> thanks,
>
> Hemant
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] reserved variable names

[Michael Jones]

looking back:
https://stackoverflow.com/questions/2627511/why-do-c-compilers-prepend-underscores-to-external-names

On Thu, Feb 14, 2019 at 8:54 AM Manlio Perillo 
wrote:

> As far as I know, Go currently does not have a list of "reserved" variable
> names, however some tools that generate code do use special names to avoid
> potential conflicts.
> As an example, stringer add a "_" prefix to each variable.
>
> I don't remember where, but I have seen variable names with a "_" suffix.
>
> Is there a common convention?
>
>
> Thanks
> Manlio Perillo
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] A Measure of Hash Function Collisions

[Michael Jones]

good observations.

here is a help for you... your program modified to do any size computation
in any size of memory
(so you need not look for that special machine)

https://play.golang.org/p/m03mnIP4F0E

On Wed, Feb 13, 2019 at 10:11 PM Serhat Sevki Dincer 
wrote:

> 14 Şub 2019 Per 01:58 tarihinde Michael Jones 
> şunu yazdı:
>
>> Serhat,
>>
>> Some more ideas for you to consider: the expected number of collisions
>> for an ideal random hash, the option of "folding in" the high bits of the
>> hash rather than truncating, and finer control of operation.
>>
>> https://play.golang.org/p/92ERC4PJKAL
>>
>
> Hi Michael,
> Here with your variant:
>
> x = uint64(1<<64-59) ^ uint64(len(s))
>
> for i := len(s) - 1; i >= 0; i-- {
> x ^= uint64(s[i])
> x *= 11400714819323198549
> }
>
> // fold high bits
>
> you have a direct collision with input length's lowest byte (which is
> practically the length) and input's first byte. This is better for
> initialization:
>
> x = uint64(len(s))
> x *= 11400714819323198549
>
> at the cost of an extra multiplication.
>
> Folding high bits does not change collision characteristic, right?
> Also when the last operation is a multiplication, you don't seem to need
> it, if at all it is useful.
>
>>

-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] A Measure of Hash Function Collisions

[Michael Jones]

Serhat,

Some more ideas for you to consider: the expected number of collisions for
an ideal random hash, the option of "folding in" the high bits of the hash
rather than truncating, and finer control of operation.

https://play.golang.org/p/92ERC4PJKAL

On Wed, Feb 13, 2019 at 12:20 PM Serhat Şevki Dinçer 
wrote:

> On Tuesday, February 12, 2019 at 9:51:17 PM UTC+3, Michael Jones wrote:
>>
>> Serhat, some ideas for you...
>> https://play.golang.org/p/7QPy5wa-9eO
>>
>
> Interestingly I found out input iteration order does matter :) 15,33 shift
> version yields an amazing number of collisions (7_910_886_368 collisions
> over 7_918_845_952 inputs) when fed with a spesific 6-byte sequence
> (attached).
> rotate-27 version interestingly gave no collisions for this case. prime
> version also had no collisions. prime version with ^= and -= instead of +=
> also gave no collision.
>
> I want to identify a collision on the prime version (any variant ^= -= +=)
> with small inputs, say sum of lengths <= 12. Does anyone have any idea how
> to identify such inputs?
> So far prime version seems to be the most promising (in terms of high
> minimum sum of collding inputs)..
>
> Thanks..
>
> Note: Thanks Damian, it looks like an advanced test suite for cryto
> hashes, though text input tests seems limited.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] A Measure of Hash Function Collisions

[Michael Jones]

Serhat, some ideas for you...
https://play.golang.org/p/7QPy5wa-9eO

On Tue, Feb 12, 2019 at 9:23 AM Damian Gryski  wrote:

> For more information on hash function goodness tests, check out
> https://github.com/demerphq/smhasher
>
> Damian
>
> On Tuesday, February 12, 2019 at 5:23:39 AM UTC-8, Serhat Şevki Dinçer
> wrote:
>>
>> On Saturday, February 9, 2019 at 5:23:14 PM UTC+3, Serhat Şevki Dinçer
>> wrote:
>>>
>>> On Fri, Feb 8, 2019 at 7:42 PM Michael Jones wrote:
>>> > clustering:
>>> >
>>> https://www.cs.cornell.edu/courses/cs3110/2014fa/lectures/13/lec13.html
>>> >
>>> > careful hash functions often treat short inputs specially.
>>> >
>>> > iterated shift-xor alone is weak in expanding the "changed bits(s)"
>>> signal, at least by comparison to a) large prime multiply, b) good s-boxes,
>>> c) introduction of keyed material.
>>> Hm, thanks. I would like to try a particular version of this prime
>>> multiplication idea wih utf8 strings.
>>> I wrote for loops to find collisions (attached). It takes 3 seconds
>>> and finds no collision for strings with length < 4.
>>> The next step (including length=4, commented in the code) will take
>>> 13+ min and 32+ gb ram, so I appreciate if anyone with sufficient RAM
>>> could try that and report the result ;P
>>> Thanks..
>>>
>>
>> I got access to a server with 64 gb ram. On it, using a Go map did not
>> work, so I used a list and sorted it for identifying collisions.
>> It turned out both prime and shift versions (attached) of the simple hash
>> turned out to be really good for small inputs. No collisions for
>> 7_918_845_952 inputs.
>> This required 59 GiB of ram. For a 64-bit cryptographic hash output, the
>> probability of a collision for that many inputs is about %82.
>>
>> What I am curious about next is
>> - How further can this test be taken ? When are the first collisions for
>> these simple hashes with the given code ?
>> - What are their "minimum sum of colliding inputs lengths" ?
>> - Is there a (smooth) trade-off between being cryptographic /
>> good-bit-mixing *and* being nice on small inputs / high minimum sum of
>> colliding inputs lengths ? Assume that we dont treat small inputs
>> differently, and there is one general algorithm for all inputs..
>> - Can a cryptographic hash function have high minimum sum of colliding
>> inputs lengths, or be nice on small inputs ?
>>
>> 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.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Alternative of defer?

[Michael Jones]

ok, accepting that people use libraries with lurking panics, here's my
tweak of Sam Whitted's answer:

*package main*

*func example() {*
* // robust in face of unruly/panic-possible Operation1*
* lockedOperation1 := func() error {*
* lock1.Lock()*
* defer lock1.Unlock()*
* return performOperation1()*
* }*
* if err := lockedOperation1(); err != nil {*
* return err*
* }*
* performExpensiveOperation2()*
*}*


This is stylistically clear about meaning and motivation, short, and
simple. could be idiomatic.
Of course, if Operation 1 always needs to be locked then put the lock there!

On Sat, Feb 9, 2019 at 5:02 PM robert engels  wrote:

> I was referring to this comment (below) made by a different commentor,
> which was related to the lock not being released if it panics - and that
> only matters if the application doesn’t terminate.
>
> Recovering from panics is a common and IMO perfectly acceptable
> practice... For example in a web server where you do not want a panic that
> occurs while handling a request to affect other request, especially ones
> that are in flight.
>
>
>
>
> On Feb 9, 2019, at 6:48 PM, Michael Jones  wrote:
>
> The original question--the one I answered--was about a small block of user
> code and asked nothing about http or unexpected panics.
>
> The spirit of panic/recover, and with defer, includes in its use "local"
> panic, a kind of successor to setjump/longjump, that unwinds the stack,
> calls defers, and is caught and managed near some local top. As in the blog
> post I excerpted:
>
> https://blog.golang.org/defer-panic-and-recover
>
> On Sat, Feb 9, 2019 at 2:22 PM robert engels 
> wrote:
>
>> I agree, but in that case the ‘panic’ is as you say recognized (and in
>> this particular case used to unwind from a potentially very deep call), but
>> is then still returned as an error.
>>
>> The previous commentor referred to catching “panics" in a top-level http
>> request processor and continuing to service requests - which is far
>> different in my opinion.
>>
>> > On Feb 9, 2019, at 4:08 PM, Ian Lance Taylor  wrote:
>> >
>> > On Fri, Feb 8, 2019 at 7:48 PM Robert Engels 
>> wrote:
>> >>
>> >> The way Go is designed a panic must terminate the application.
>> Anything else is so indeterminate to be unusable.
>> >
>> > I think one can reasonably argue that an unrecognized panic should
>> > terminate the application.
>> >
>> > But there is nothing wrong with recovering and continuing from a
>> > recognized panic.  For example, the call to recover in
>> > encoding/json.encodeState.marshal is fine
>> > (https://golang.org/src/encoding/json/encode.go#L295).
>> >
>> > 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.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>
> --
>
> *Michael T. jonesmichael.jo...@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.
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.