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, <golang-nuts@googlegroups.com> wrote: golang-nuts@googlegroups.com <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/golang-nuts/topics> Google Groups <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> Topic digest View all topics <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/golang-nuts/topics> - A humble request/challenge <#m_395805729739486593_group_thread_0> - 4 Updates - [ANN] Edit - Acme command language <#m_395805729739486593_group_thread_1> - 5 Updates - Getting Uid/Gid for a folder <#m_395805729739486593_group_thread_2> - 1 Update - [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 Update - Offline Go Documentation Tools <#m_395805729739486593_group_thread_10> - 2 Updates A humble request/challenge <http://groups.google.com/group/golang-nuts/t/5b474faec01045f1?utm_source=digest&utm_medium=email> Jabari Zakiya <jzak...@gmail.com>: Aug 08 01:18PM -0700 Hi 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: https://www.scribd.com/doc/228155369/The-Segmented-Sieve-of-Zakiya-SSoZ 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. Jabari Pierpaolo Bernardi <olopie...@gmail.com>: Aug 09 12:31AM +0200 Hello, > Here's a link to read and download the paper: > https://www.scribd.com/doc/228155369/The-Segmented-Sieve-of-Zakiya-SSoZ 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. Cheers! Jan Mercl <0xj...@gmail.com>: Aug 08 10:40PM On Wed, Aug 9, 2017 at 12:32 AM Pierpaolo Bernardi <olopie...@gmail.com> wrote: > 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 <http://math.ucr.edu/home/baez/crackpot.html> (#25). Or maybe it's a download-fee scam? Check also: https://www.google.com/search?q=%22humble+request%22+%22The+ Segmented+Sieve+of+Zakiya%22&oq=%22humble+request%22+% 22The+Segmented+Sieve+of+Zakiya%22 -- -j Michael Jones <michael.jo...@gmail.com>: Aug 08 03:45PM -0700 I remember a segmented wheel of Aitkin implementation. Maybe you can start with that. here are a few: https://golanglibs.com/top?q=sieve On Tue, Aug 8, 2017 at 3:31 PM, Pierpaolo Bernardi <olopie...@gmail.com> wrote: -- Michael T. Jones michael.jo...@gmail.com Back to top <#m_395805729739486593_digest_top> [ANN] Edit - Acme command language <http://groups.google.com/group/golang-nuts/t/4c98777dc106e60f?utm_source=digest&utm_medium=email> as.u...@gmail.com: 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 <michael.jo...@gmail.com>: 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 michael.jo...@gmail.com roger peppe <rogpe...@gmail.com>: 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 <r...@golang.org>: Aug 09 07:49AM +1000 Grep for conquest. -rob roger peppe <rogpe...@gmail.com>: Aug 08 11:45PM +0100 Hang by your pseudopod, write if you find a warm rich planet ripe for conquest. Back to top <#m_395805729739486593_digest_top> Getting Uid/Gid for a folder <http://groups.google.com/group/golang-nuts/t/ab8c69f7d0d735e5?utm_source=digest&utm_medium=email> charlesfo...@gmail.com: 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 <http://groups.google.com/group/golang-nuts/t/7840e55c0556f6f5?utm_source=digest&utm_medium=email> Daniel Theophanes <kardia...@gmail.com>: 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 <dslpi...@gmail.com>: 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 chain. 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 <s...@samwhited.com>: 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. —Sam Back to top <#m_395805729739486593_digest_top> How to setup go-swagger for an existing project to generate API docs <http://groups.google.com/group/golang-nuts/t/38782b94d3636008?utm_source=digest&utm_medium=email> Dayana Mallasserry <dayanam...@gmail.com>: 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 <http://groups.google.com/group/golang-nuts/t/c544f8d334c6cd6?utm_source=digest&utm_medium=email> Josh Humphries <jh...@bluegosling.com>: 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 cancelled. I'm curious how others tackle these kinds of concerns. ---- *Josh Humphries* jh...@bluegosling.com Back to top <#m_395805729739486593_digest_top> Go 1.9 Release Candidate 2 is released <http://groups.google.com/group/golang-nuts/t/639424f5cfded847?utm_source=digest&utm_medium=email> ifreelance Asia <ifreelancea...@gmail.com>: 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 : https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=node ( Regex-redux ) and more Ian Lance Taylor <i...@golang.org>: 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 of > 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. Ian Back to top <#m_395805729739486593_digest_top> How to secure variables in memory? <http://groups.google.com/group/golang-nuts/t/45255bd104235be3?utm_source=digest&utm_medium=email> Awn Umar <a...@cryptolosophy.io>: Aug 08 06:16AM Seems like this is what you're looking for: Project page: https://github.com/awnumar/memguard Explanation: https://cryptolosophy.io/memory-security-go/ Back to top <#m_395805729739486593_digest_top> "find" for Slices like "append" <http://groups.google.com/group/golang-nuts/t/712577fcd4d0f5b0?utm_source=digest&utm_medium=email> roger peppe <rogpe...@gmail.com>: 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 though. 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. cheers, rog. Back to top <#m_395805729739486593_digest_top> Generics are overrated. <http://groups.google.com/group/golang-nuts/t/850899b1dd5945d0?utm_source=digest&utm_medium=email> Jan Mercl <0xj...@gmail.com>: Aug 08 11:43AM > Currently Java developers would not change to Go. Never enough of good news. -- -j Back to top <#m_395805729739486593_digest_top> Offline Go Documentation Tools <http://groups.google.com/group/golang-nuts/t/10e4110010845039?utm_source=digest&utm_medium=email> me <fo...@z505.com>: 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. http://langserver.org/ 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 <fo...@z505.com>: 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 <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/golang-nuts/join> . To unsubscribe from this group and stop receiving emails from it send an email to golang-nuts+unsubscr...@googlegroups.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.
