Is there any one interested in compile time and date like the __time__ and
__date__ macros in c

On Aug 8, 2017 7:26 PM, <> wrote:
Topic digest
View all topics

   - A humble request/challenge <#m_395805729739486593_group_thread_0> - 4
   - [ANN] Edit - Acme command language
   <#m_395805729739486593_group_thread_1> - 5 Updates
   - Getting Uid/Gid for a folder <#m_395805729739486593_group_thread_2> - 1
   - [Blog] Context should go away for Go 2
   <#m_395805729739486593_group_thread_3> - 3 Updates
   - How to setup go-swagger for an existing project to generate API docs
   <#m_395805729739486593_group_thread_4> - 1 Update
   - chaining contexts, best practices question
   <#m_395805729739486593_group_thread_5> - 1 Update
   - Go 1.9 Release Candidate 2 is released
   <#m_395805729739486593_group_thread_6> - 2 Updates
   - How to secure variables in memory?
   <#m_395805729739486593_group_thread_7> - 1 Update
   - "find" for Slices like "append" <#m_395805729739486593_group_thread_8>
   - 1 Update
   - Generics are overrated. <#m_395805729739486593_group_thread_9> - 1
   - Offline Go Documentation Tools <#m_395805729739486593_group_thread_10>
   - 2 Updates

A humble request/challenge
Jabari Zakiya <>: Aug 08 01:18PM -0700


I primarly use Ruby for math/science problems/projects because it's so easy
to program in, and it allows me to think about how to solve problems
without worrying about how to code it. I've also played around with Crystal
(aka Ruby on steroids) but it's still young, and doesn't let me (currently)
do what I want, or without a lot of hassles, and I've just recently started
looking at Nim (less than a month at time of writing).

I heard about Go for sometime but never had any time/reason to learn it.
But now maybe I have incentive to do so.

I developed a prime sieve called the *Sieve of Zakiya (SoZ)*, and it's
companion the *Segmented Sieve of Zakiya (SSoZ)*. I wrote a paper, **The
Segmented Sieve of Zakiya (SSoZ)** which describes its mathematical
foundations and algorithm, and provide a working C++ implementation at the
end of the paper (compiled, run, and verified), though I don't consider
myself a C++ programmer, just funcitonal enough in it. It's a relatively
short program.

Here's a link to read and download the paper:

My humble request/challenge is for a/some skilled Golanger(?) to translate
the code into idiomatic Go to demonstrate the best way to code the
algorithm in it. Extra points if someone can do a true parallel version of
the algorithm, which I attempted to do using OpemMP, but what I did didnt'
seem to make the code faster than the serial version (see paper).

I assume coding this the *Go way* would look different than the C++ code,
and be quite different than a direct translation into Go using the same
(probably suboptimal) structure.

Ultimately, I'd like to publish the results of benchmarks in different
languages doing the SSoZ in an updated paper.

If anyone would be willing to take up the challenge I'd be pleased to
answer any questions the best I can.

Thanks in advance.

Pierpaolo Bernardi <>: Aug 09 12:31AM +0200


> Here's a link to read and download the paper:


Downloading the paper requires a scribd account which costs money(*).
Is the paper available for free somewhere else?

(*) Or one can use the free month they offer, but misteriously to get
a free month they require you give them your credit card number.

Jan Mercl <>: Aug 08 10:40PM

On Wed, Aug 9, 2017 at 12:32 AM Pierpaolo Bernardi <>

> Downloading the paper requires a scribd account which costs money(*).
> Is the paper available for free somewhere else?

My 2-minute skimming smells quite crackpot-ish
<> (#25). Or maybe it's a
download-fee scam?

Check also:


Michael Jones <>: Aug 08 03:45PM -0700

I remember a segmented wheel of Aitkin implementation. Maybe you can start
with that.

here are a few:

On Tue, Aug 8, 2017 at 3:31 PM, Pierpaolo Bernardi <>

Michael T. Jones
Back to top <#m_395805729739486593_digest_top>
[ANN] Edit - Acme command language
<> Aug 08 05:54AM -0700

Thanks for suggesting the Reader(q0, q1 int64) io.RuneReader. I
accidentally replied off list.

I wasn't aware of up to four horsemen being involved. The man pages didn't
prepare me for this.
Michael Jones <>: Aug 08 01:34PM -0700

The Four Horsemen of the Apocalypse, surely! It would be tempting fate to
shade them or step on their brand.

Michael T. Jones
roger peppe <>: Aug 08 09:58PM +0100

> The Four Horsemen of the Apocalypse, surely! It would be tempting fate to
> shade them or step on their brand.

Ah, but of which apocalypse?
Rob Pike <>: Aug 09 07:49AM +1000

Grep for conquest.


roger peppe <>: Aug 08 11:45PM +0100

Hang by your pseudopod, write if you find a warm rich planet ripe for

Back to top <#m_395805729739486593_digest_top>
Getting Uid/Gid for a folder
<> Aug 08 02:37PM -0700

WOW this is exactly what I was looking for - Thanks sbez

On Monday, July 31, 2017 at 8:46:44 PM UTC-6, Ian Lance Taylor wrote:
Back to top <#m_395805729739486593_digest_top>
[Blog] Context should go away for Go 2
Daniel Theophanes <>: Aug 08 02:20PM

I'm personally reasonably happy with Context as-is. Bit if you are looking
for a better solution, I completly agree with "as.utf8": the solution won't
be found in TLS/GLS (goroutine local storage) but in some other
contextual/namespace/arena type thing that is larger then a single
goroutine, is still cooperative, and can expose properties that allow
transporting it over the network as Context allows today.

Piero de Salvia <>: Aug 08 08:28AM -0700

I agree with Dave Cheney and Michal Strba that Context should not be used
for storage of any kind and only serve the purpose of cancelation.

In effect, the original purpose of Context, I think, was avoiding cascading
failure in chains of *network* calls, where the result of one call would
be used as argument to the next call. In effect, a kill switch on the whole

A deeper analysis of this feature makes me think that this is not so much
about goroutines (hence not so much about thread local storage) as much as
network failures.

And finally, I think the last thing anybody wants is to pollute the whole
stdlib with Contexts.

To me, given these requirements, context should become embedded in all
network functions, just like a timeout is.

Only difference, when creating a network function (client or server) one
would (optionally) call SetContextName("MyContext") on it (I think the
namespace suggestion from plan 9 is excellent), so a chain of network calls
would belong to the same named context.

So when code owning that chain of network calls would need to cancel (in
effect kill) the chain, it would just call a lib function called Cancel(ctx
string) and the whole chain of calls would be killed: every network
functions must obey a Cancel() call.

As far as extending it to Reader, it does not make sense to me. The reason
why there is a Context today is that failures in chained network calls are
difficult to detect and correct, because of inherent network
characteristics. That is not a general case for a Reader.

On Monday, August 7, 2017 at 3:40:05 PM UTC+2, Michal Strba wrote:
Sam Whited <>: Aug 08 04:34PM -0500

On Mon, Aug 7, 2017, at 11:33, Uli Kunitz wrote:
> I assume here that the proposal is not to change io.Reader but to …

There is no proposal. This was briefly discussed in the contributors
summit, but the underlying issues are not necessarily well understood.
Blog posts like this one help us all understand those issues better.
Apologies if I made it sound like this was something that was going to
happen in the contributors summit post; everything at the summit was
just a discussion which, for the most part, avoided concrete solutions.

Back to top <#m_395805729739486593_digest_top>
How to setup go-swagger for an existing project to generate API docs
Dayana Mallasserry <>: Aug 08 12:04PM -0700

Has anyone set up swagger for an existing golang project ?
Back to top <#m_395805729739486593_digest_top>
chaining contexts, best practices question
Josh Humphries <>: Aug 08 10:48AM -0400

I noticed the Go doc for context.Context includes the following snippet:

Do not store Contexts inside a struct type; instead, pass a Context
> explicitly to each function that needs it.

I think one potential reason for going against this advice is maintaining
context chain relationships in servers. In a server object, it seems
reasonable to provide a context when starting the server (which is valid
for the lifetime the server is serving) and the server to then store that
context in a struct. The reason it would be stored is that it could be used
to create child contexts when handling incoming data from the socket (or
whatever the server does).

The reason I would do this is two-fold:

1. It is convenient and IMO elegant (particularly, but not exclusively,
in test code) to be able to simply cancel a top-level context and have that
respected throughout the chain, resulting in the server stopping and
tearing itself down.
2. It is a natural place for server-scoped contextual data. For example,
we use a log library that allows log writer configuration to be stored in
context. We could configure the log writer once for the server and have it
then correctly applied to every action taken by the server, including
request dispatches.

Does this seem like a reasonable approach, or are there other possibly
better practices for addressing these issues?

Obviously we must do things differently for HTTP and GRPC servers since
those libraries do not expose a way to provide a "parent context" for the
whole server. In those cases, we provide a method for registering HTTP
handlers that will wrap an incoming handler with one that decorates the
request context (for bullet #2 above; and we can use interceptors for
GRPC). For bullet #1, we have to implement our own cancellation propagation
-- like a goroutine that will stop the server(s) when the root context gets

I'm curious how others tackle these kinds of concerns.

*Josh Humphries*
Back to top <#m_395805729739486593_digest_top>
Go 1.9 Release Candidate 2 is released
ifreelance Asia <>: Aug 07 10:38PM -0700

Will there be any *Performance Improvement for RegEx in Golang* - It is one
of the most hyped and relevant issue.

One of the reference :
( Regex-redux ) and more
Ian Lance Taylor <>: Aug 08 07:18AM -0700

On Mon, Aug 7, 2017 at 10:38 PM, ifreelance Asia

> Will there be any Performance Improvement for RegEx in Golang - It is one
> the most hyped and relevant issue.

No particular improvements are expected. Let's take any discussion of
this to a separate thread, not the rc2 announcement thread. Thanks.

Back to top <#m_395805729739486593_digest_top>
How to secure variables in memory?
Awn Umar <>: Aug 08 06:16AM

Seems like this is what you're looking for:

Project page:
Back to top <#m_395805729739486593_digest_top>
"find" for Slices like "append"
roger peppe <>: Aug 08 12:52PM +0100

> if !contains {
> ...

> Seriously? 2017?

I'd usually write that as as separate function:

func isExcluded(ns []byte, m byte) bool {
for _, n := range ns {
if n == m {
return true
return false

For that *particular* case, you could always use
bytes.Index(excluded_numbers, byte(m)) >= 0

Yes, it feels a little tedious sometimes, but if you
add up the number of times you actually have to do this,
it's generally not too much. There's a trade-off going
on here.


Back to top <#m_395805729739486593_digest_top>
Generics are overrated.
Jan Mercl <>: Aug 08 11:43AM

> Currently Java developers would not change to Go.

Never enough of good news.


Back to top <#m_395805729739486593_digest_top>
Offline Go Documentation Tools
me <>: Aug 07 07:29PM -0700

On Monday, July 24, 2017 at 10:46:31 AM UTC-6, Tyler Compton wrote:
> Studio Code with Go today, and will help provide that functionality to
> editors like [Neo]vim in the future.

> 1.

That's interesting!
Is Visual Studio Code a .Net app that takes up lots of memory and CPU?
I find Visual Studio a memory hog/cpu hog at times and do not like editing
in it if I do not have to.
However, the "Code" edition could be trimmed down to be quicker, and
smaller foot print, but only an experienced user would know.

If that does not work, maybe I'll one day take LSP (above) and implement it
into one of my own editors.
me <>: Aug 07 07:33PM -0700

On Monday, July 24, 2017 at 2:52:48 PM UTC-6, Rob 'Commander' Pike wrote:

> The "go doc" (distinct from "godoc") command works fine offline. It fact
> it never goes on line.

> -rob

That's a good tip, I might be even able to use that and pipe it into an
editor Memo/Edit widget for instant help with an F1 shortcut. Some editors
have "tools" that you can pipe the output of a process into a status memo
based on the context (current selected item in editor or cursor). Just
running it at a command line and reading it like a man page is an option,
but, I'll likely want something a bit more than that, such as a pop up
window when I hit F1 or a shortcut.
Back to top <#m_395805729739486593_digest_top>
You received this digest because you're subscribed to updates for this
group. You can change your settings on the group membership page
To unsubscribe from this group and stop receiving emails from it send an
email to

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 
For more options, visit

Reply via email to