Re: [go-nuts] godoc and generic code

[Hotei]

Thanks for the very helpful replies. < go doc -all pkg > should meets my 
needs for printed documentation.  I guess I will have to weigh the 
convenience of navigating which the godoc html version provides vs the 
inconvenience of "instantiating" the methods required by the types [T] I 
use in this project.  The pkgsite option doesn't seem workable in my case 
for the reasons eloquently described by one of the posters to issue 49212.  
At any rate, problem solved and thanks again to the golang-nuts group for 
the assistance!

On Thursday, November 3, 2022 at 9:32:09 AM UTC-4 Sebastien Binet wrote:

> On Thu Nov 3, 2022 at 14:02 CET, Jan Mercl wrote:
> > On Thu, Nov 3, 2022 at 12:49 PM Hotei  wrote:
> >
> > > I added some generic code to a project and godoc doesn't seem to like 
> that and stops working when it sees the generics. It's a 4 year old version 
> of godoc so that's perhaps not a surprise. What is a surprise is that godoc 
> isn't shipped with go any longer. Is there a version that handles generics 
> and if so where can I find it? A quick search of github came up empty but I 
> know things have been moved around so some hints would be much appreciated.
> >
> > I'm not in favor of the fact, but It's been deprecated a year ago:
> > https://github.com/golang/go/issues/49212
>
> one can use godocs.io for a maintained "godoc-like" binary:
>
> - https://godocs.io/go-hep.org/x/hep/sliceop
> - https://sr.ht/~sircmpwn/godocs.io/
>
> (otherwise, 'go doc' does support "generics")
>
> hth,
> -s
>

-- 
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/d5612970-6ad5-4e47-a45e-1e61f9cb648an%40googlegroups.com.

[go-nuts] godoc and generic code

[Hotei]

I added some generic code to a project and godoc doesn't seem to like that 
and stops working when it sees the generics.  It's a 4 year old version of 
godoc so that's perhaps not a surprise.  What is a surprise is that godoc 
isn't shipped with go any longer.  Is there a version that handles generics 
and if so where can I find it?  A quick search of github came up empty but 
I know things have been moved around so some hints would be much 
appreciated.

-- 
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/46a9941d-32e8-4ce1-a9d5-1c5b369668e4n%40googlegroups.com.

Re: [go-nuts] I'm missing godoc for local packages after converting to modules.

[Hotei]

Thanks to all for assistance with this!
 
Got it working with (perhaps) the most recent version - though once again 
it looks to have moved from the path(s) mentioned above.  Part of my 
problem was not looking specifically for the "Third Party" section since 
before my code had all been lumped in at the top with the standard library 
sections.  That's an improvement I agree.  Also not mentioned specifically 
is there exist both a package and a command by the name godoc.  You need to 
compile them separately - paying attention to the need to "go generate" the 
static section of the package first.  It had been a while since I last had 
to do this so it took awhile to (re)discover the secret sauce ingredients.

While I'm still hoping to eventually see programs added to the godoc 
feature set I'm at least back to where we were before I started the module 
experiment.  So far it looks like a pretty straight forward - though a bit 
labor intensive in my case.

David
On Sunday, March 28, 2021 at 10:30:47 AM UTC-4 seank...@gmail.com wrote:

> Assuming a recent enough version of `godoc`, running it from within a 
> module should include the documentation for the standard library (standard 
> library section), that module, and all its dependencies (third party 
> section)
> Expected output should be similar to:
>
> $ godoc
> using module mode; GOMOD=/home/arccy/testrepo-337/go.mod
>
> It doesn't handle documentation across multiple, unrelated modules, but 
> you could work around it by defining a dummy package & module with imports 
> to the modules you wish to include (use replace to point to the local 
> version) and running `godoc` from the dummy module
>
> On Sunday, March 28, 2021 at 4:01:37 PM UTC+2 Hotei wrote:
>
>> Clarification.  As mentioned earlier, $GOPATH is supposed to go away in 
>> the (possibly near) future so one of my main goals is to get it working 
>> outside the $GOPATH tree.  At present my solution has been to copy my 
>> source tree (about 4 GB) to a "non-module-aware" go ecosystem on a 
>> different machine and browse over my local network to the old godoc version 
>> there.While it works (for the moment) it's not a very efficient or 
>> maintainable solution.  The possibility of easy to maintain documentation 
>> has always been one of go's strengths thanks to gofmt and godoc.  Hate to 
>> lose half that advantage if there's a way around it.
>> David Rook
>>
>> On Sunday, March 28, 2021 at 7:05:01 AM UTC-4 m8il...@gmail.com wrote:
>>
>>> I found you had to cd to each directory with a .mod file and run it 
>>> there. A global option would be nice to know about.
>>>
>>

-- 
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/ca3a64e5-fe14-42b0-bbec-cc60de6e2b9bn%40googlegroups.com.

[go-nuts] Re: How to wait for HTTP server to start?

[Hotei]

jerome - not sure that the code you provided fully answers the OP's 
problem.  I think you'd need to craft an http request and get a response to 
really KNOW that the server is indeed responding.  If you do that as a 
replacement for where you have the "select {}" then I think you've got it.

Note, the http request need not be complicated.  A simple "echo" style 
handler would do the trick.  As soon as you get the echo back then you know 
your server is ready to start handling other types of potentially more 
complex requests.  If the server has a TON of stuff (seconds to minutes of 
initialization)  you can make the echo server wait till all the prelim's 
are done first before sending the echo reply.  After startup you can also 
use the echo as a simple test of whether the server is at least running - 
even if more complicated requests are failing.
 
On Saturday, March 27, 2021 at 1:53:47 PM UTC-4 jerome@gmail.com wrote:

> When I want to ensure that the HTTP server is started (or if I want 
> additional stuff), I do this :
>
> https://play.golang.org/p/mX0OsNWFf-f
>
> Le samedi 27 mars 2021 à 15:13:40 UTC+1, cpu...@gmail.com a écrit :
>
>> The typical Go tutorials pattern for starting a server is something like 
>>
>> log.Fatal(http.ListenAndServe(":8080"))
>>
>> But what if the application needs to do other things after the server is 
>> started? It seems there is virtually no method to wait for the server 
>> actually start listening to requests?
>>
>> I'm probably missing something and would appreciate a hint.
>>
>> Thanks,
>> Andi
>>
>>

-- 
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/ffeaa43b-bde3-4524-ae88-b1e7292108f1n%40googlegroups.com.

Re: [go-nuts] I'm missing godoc for local packages after converting to modules.

[Hotei]

Clarification.  As mentioned earlier, $GOPATH is supposed to go away in the 
(possibly near) future so one of my main goals is to get it working outside 
the $GOPATH tree.  At present my solution has been to copy my source tree 
(about 4 GB) to a "non-module-aware" go ecosystem on a different machine 
and browse over my local network to the old godoc version there.While 
it works (for the moment) it's not a very efficient or maintainable 
solution.  The possibility of easy to maintain documentation has always 
been one of go's strengths thanks to gofmt and godoc.  Hate to lose half 
that advantage if there's a way around it.
David Rook

On Sunday, March 28, 2021 at 7:05:01 AM UTC-4 m8il...@gmail.com wrote:

> I found you had to cd to each directory with a .mod file and run it there. 
> A global option would be nice to know about.
>

-- 
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/4015dad3-f54a-44e1-bb26-6eb8740a0991n%40googlegroups.com.

[go-nuts] I'm missing godoc for local packages after converting to modules.

[Hotei]

Could use a little help figuring out how to attack the following problem:

I normally run godoc locally with $godoc -http=":6060"& and then browse it 
with chrome. 

 Many years ago that method broke for a while as godoc was "reinvented" but 
then it came back pretty much the same as before.  A few weeks ago I 
converted a lot of old code to use modules.  Now that I've converted my 
local packages tree to modules I find that the same godoc code I've been 
using with no problem  before can only find the packages in the official 
source 1.16.* tree.  I don't know if this is a bug or a feature but if 
possible I'd like to find a way so that the old method still works.  Is 
there a work-around?  Sorry if this ground has been covered before. There's 
no error message to reference, just the absence of my source  (and that of 
others from golang.org, github.com etc) in the listing.  It's possible I'm 
not using the latest & greatest godoc but it has moved around a bit the 
last few years so I'm not 100% sure what the canonical version is right 
now.  Any help appreciated.  I also wish godoc handled programs (as opposed 
to just packages) but I can work around that where necessary.  Thanks in 
advance.

David

-- 
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/19a7749e-31cc-4308-93f1-e9e436a75e22n%40googlegroups.com.

Re: [go-nuts] Re: build world question

[Hotei]

Jan,
To clarify a bit, "world" used to be everything under $GOPATH/src.   Since 
gophers can expect at some point to see $GOPATH go away the directory I now 
refer to as "world" is just a local/private version of my github.com/hotei 
repository with about 250 or so subdirs that represent individual 
projects.  I'm about halfway through the conversion process and it's pretty 
much down to a lot of typing now.  Go has gotten a bit more complex lately 
with vendoring and modules but in my opinion it's still the best choice for 
development. One particular strength I can vouch for is that I can look at 
go code I wrote 10 years ago and 99% of the time I understand what I was 
doing at the time.  Can't recall any other language I've used for which I 
can say the same.
David

On Thursday, March 18, 2021 at 12:02:12 PM UTC-4 Jan Mercl wrote:

> On Thu, Mar 18, 2021 at 4:51 PM Brian Candler  wrote:
>
> > OK. I'll just point out that if the repo contains a set of related 
> packages, then normally you'd only put a go.mod at the top level.
>
> I think the OP never mentioned a repository but "world". I infer that
> means all the repositories the OP is dealing with on some machine,
> probably everything under $GOPATH/src.
>

-- 
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/42912903-f717-42dd-9482-497e7828db9dn%40googlegroups.com.

[go-nuts] Re: build world question

[Hotei]

Brian, 
Looks like a case of "pilot error".  After tinkering a bit more it started 
to work.  Each directory has its own go.mod file.  Took a little while to 
figure out what the module wanted to see for versioning but that's seems to 
be sorted now.  Still have  a large number of projects to convert but at 
least the process seems to be working ok.  Thanks for the assistance.  
David
On Wednesday, March 17, 2021 at 3:29:37 PM UTC-4 Brian Candler wrote:

> What error do you see?
>
> Are your subdirectories independent modules in their own right (i.e. they 
> have their own "go.mod"), or just separate packages within the same module 
> (go.mod only exists at the top level)?  Normally the latter is what you 
> want.
>
> On Wednesday, 17 March 2021 at 17:57:55 UTC Hotei wrote:
>
>> Heeding the prodding of the go gurus on this list I just converted a 
>> bunch of old code to modules and was wondering what the "module" equivalent 
>> to "go build ./..." is.  I used to be able to use that command at the top 
>> of my code tree and it would attempt to build everything in the subdirs.  
>> Doesn't seem to work now even though each subdir compiles fine 
>> individually.  Haven't been reading golang-nuts every day so sorry if I 
>> missed a previous topic that solves 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/85c42ff3-9aae-43d2-86db-c0cda0520b08n%40googlegroups.com.

[go-nuts] build world question

[Hotei]

Heeding the prodding of the go gurus on this list I just converted a bunch 
of old code to modules and was wondering what the "module" equivalent to 
"go build ./..." is.  I used to be able to use that command at the top of 
my code tree and it would attempt to build everything in the subdirs.  
Doesn't seem to work now even though each subdir compiles fine 
individually.  Haven't been reading golang-nuts every day so sorry if I 
missed a previous topic that solves 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/bda882d5-9cdc-4b68-8722-920e4790a3d0n%40googlegroups.com.

[go-nuts] Re: os.remove is slow

[Hotei]

Gabriel - Thank you for reminding me that perl is a write-only language.  
It's been a few years since I had to deal with it.  How many files are we 
talking about and on what media?

On Monday, December 4, 2017 at 12:50:54 PM UTC-5, Gabriel Forster wrote:
>
> What takes 18 seconds in a perl command:
> perl -e 'for(<*>){((stat)[9]<(unlink))}'
>
> is taking almost 8 minutes with the following code. Any ideas how I can 
> speed this up?
>
> dir, err := os.Open("/var/spool/directory")
> if err != nil {
> fmt.Fprintf(w, "failed - " + err.Error())
> return
> }
> defer dir.Close()
>
>
> files, err := dir.Readdir(-1)
> if err != nil {
> fmt.Fprintf(w, "failed - " + err.Error())
> return
> }
>
> for _, file := range files {
> if file.Name() == "." || file.Name() == ".." {
> continue
> }
>
> os.Remove("/var/spool/directory/" + file.Name())
> }
>
>
> fmt.Fprintf(w, "success")
>
>
>

-- 
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] Is there a way to check if all pending finalizers have been executed?

[Hotei]

re "meaningfullness" - I think he's saying that a finalizer for a function 
called in a goroutine might not run if main() quits first, intentionally or 
otherwise.  You can of course check for this specific case by making sure 
all your goroutines are cleaned up before exiting main - but in some 
(many?) cases that's overkill. 

 If it's REALLY important to know which finalizer actions completed you 
could log them to disk and analyse the results afterwards to see that all 
the boxes got checked. Not quite what the OP was looking for I know - but 
might help diagnose problems.  

On Saturday, October 15, 2016 at 3:08:46 AM UTC-4, di...@veryhaha.com wrote:
>
>
>
> On Saturday, October 15, 2016 at 8:18:04 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Fri, Oct 14, 2016 at 4:08 PM, 'Peter Lam' via golang-nuts 
>>  wrote: 
>> > Is there someway to wait for all pending finalizers to be run? 
>>
>> Not in general, no.  Conceptually it doesn't make sense since, as you 
>> know, finalizers not guaranteed to run at all.  You could of course 
>> write your finalizers to support this. 
>>
>> Ian 
>>
>
> if finalizers not guaranteed to run at all, then what is its 
> meaningfulness? 
>

-- 
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: Rational number to floating point

[Hotei]

I think you'll need something like x := float(355) / float(113)   - where 
float is either float32 or float64 depending on your preferred trade-off 
for accuracy vs bytes required per number.

On Monday, September 19, 2016 at 12:38:12 PM UTC-4, Mark Longtin wrote:
>
> Hey guys, 
>
> I'm new to Go - through the Ivy app on IOS- so I have a newbie question. 
> What's the easiest way to cast or convert a rational number to its floating 
> point representation?
>
> EG, looking for something like this:
>
>
> *float 355/113*3.14159292035
>
> I could do something inelegant like
>
>
> *floor .5+1e11* 355/113*314159292035
>
> but was hoping there would be a native function for 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Differences in archive/zip between 1.6.3 / 1.7

[Hotei]

Because zip compression programs can use different levels of compression 
there is certainly no expectation that zipping the same file with different 
compression levels will give the the same output.  It MIGHT - but it's not 
to be expected or relied upon.  The only thing that's "guaranteed" is that 
unzipping the zipped file (regardless of compression level) will return you 
to the original file.  If it doesn't then it's obviously a bug.  Confusion 
can happen because not all zip programs allow varying the compression level 
- especially the GUI versions and of course different programs can have 
different defaults.  Look at the man page for zip and the -Z option or go 
to the PKware spec for details.


On Wednesday, August 17, 2016 at 8:40:08 AM UTC-4, Radek Simko wrote:
>
> Hi,
> I read through the 1.7 changelog but didn't spot any change that would 
> explain this behaviour.
>
> Basically given a specific slice of bytes archived via "archive/zip" + 
> written to a file produces different file when doing so w/ Go 1.6.3 and 
> 1.7.0.
>
> See full repro case:
> https://gist.github.com/radeksimko/62aa4b89af6633f7421e45c979523135
> The first example produces different ZIP file, second produces the same 
> one.
>
> Is anyone able to explain to me the difference I observed?
>
> I am aware that reproducible ZIP archives are tricky in general due to 
> timestamp-based metadata,
> but I don't believe these affect me in the attached example.
>
> Thanks,
> -- 
> Radek
>

-- 
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: cmdline--improve Golang std.flag based on Go src v1.7

[Hotei]

I assume you're aware it's valid to have two initializers for the same 
variable.?  I often use -v and -verbose to both modify flagVerbose.

var flagVerbose bool

func init() {
boolVar(,"v" 
boolVar( "verbose" 

}

Other than that I don't see what your package is actually enhancing over 
the current flag package.  Could you please explain what advantage(s) you 
believe you are providing.  You might also want to re-visit the "usage" 
function convention since that's pretty easy to use to accomplish the 
"enough information" part.

On Thursday, August 18, 2016 at 6:11:35 AM UTC-4, Ally Dale wrote:
>
> Hi, everyone,
> I have create a package named cmdline to extend std.flag based on Go 
> src v1.7
> Then, we can make a command usage page more easily and with enough 
> information.
>
> So, I wonder if the Go authors can merge this change into std.flag, to 
> help gophers make a command line page more conveniently?
>
> You can find the project here: http://github.com/vipally/cmdline
>
> This is the main change:
>
> 1. Add LogicName and Required field for every flag, and modify the flag 
> define interface
>
>   2. Add Summary and Details for command line info
>
>   3. Add interface GetUsage() string
>
>   4. Modify the Parse() logic
>
>
> //usage of cmdline as follow
>
> import (
>
> "github.com/vipally/cmdline"
>
> )
>
> func main() {
>
> cmdline.Summary("command copy is used to copy a file to another path.")
>
> cmdline.Details(`Command copy is used to copy a file to another path.
>
> If the destnation file is exist, default ask for if will cover it.
>
> If flag -y used, it will cover the destnation file without ask.
>
> If flag -n used, it will not cover the destnation file without ask.
>
> `)
>
> cmdline.String("s", "src", ".", true, "source file path")
>
> cmdline.String("d", "dst", ".", true, "destnation file path")
>
> cmdline.Bool("c", "cover", false, false, "if cover the destnation file")
>
> cmdline.Bool("y", "yes", false, false, "if auto select yes when ask for 
> cover")
>
> cmdline.Bool("n", "no", false, false, "if auto select no when ask for 
> cover")
>
> cmdline.Parse()
>
>
> //[error] require but lack of flag -s=
>
> //Usage of [copy.exe]:
>
> //  Summary:
>
> //command copy is used to copy a file to another path
>
> //
>
> //  Usage:
>
> //copy.exe [-c=] -d= [-n=] -s= [-y=]
>
> //  -c=
>
> //  if cover the destnation file
>
> //  -d=  required  string (default ".")
>
> //  destination file path
>
> //  -n=if auto select no when ask for cover
>
> //  -s=  required  string (default ".")
>
> //  source file path
>
> //  -y=
>
> //  if auto select yes when ask for cover
>
> //
>
> //  Details:
>
> //Command copy is used to copy a file to another path.
>
> //If the destnation file is exist, default ask for if will cover it.
>
> //If flag -y used, it will cover the destnation file without ask.
>
> //If flag -n used, it will not cover the destnation file without ask.
>
> }
>
>

-- 
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] Reject Unknown clients

[Hotei]

Sam,
I'm guessing but a lot of (non-commercial) folks use an inexpensive 
"wireless router" with NAT as their "firewall".  Besides, the application 
code is trivial.  Probably less than a hundred lines.  Potentially s a good 
teaching moment for using go and how it does http.  On the other hand - if 
this was for a business I'd have to agree with you on using a proper 
firewall.

On Thursday, August 4, 2016 at 1:16:42 PM UTC-4, Sam Whited wrote:
>
> On Thu, Aug 4, 2016 at 9:17 AM, Naveen Shivegowda  > wrote: 
> > Is it possible to make http servers listen only on a few source ip's and 
> > request from any other source should be rejected? 
>
> Out of curiosity, is there a reason you don't want to use a firewall 
> for this? iptables and pf are pretty great. Or, if you're already 
> terminating HTTP elsewhere with a loadbalancer like HAProxy you can do 
> it at that level. Plenty of options that don't require more 
> application code. 
>
> —Sam 
>
>
> -- 
> Sam Whited 
> pub 4096R/54083AE104EA7AD3 
>

-- 
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: Reject Unknown clients

[Hotei]

Certainly possible.  You can put the whitelisted IPS in a map and use that 
to filter the incoming requests.

On Thursday, August 4, 2016 at 10:17:37 AM UTC-4, Naveen Shivegowda wrote:
>
> Is it possible to make http servers listen only on a few source ip's and 
> request from any other source should be rejected?
>

-- 
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: How to check that a Go package has not been modified?

[Hotei]

The fact that collisions are possible does not make them "easy to create" 
especially when you add the compileable requirement.  If you're uneasy 
about md5 you could always use more bits - like SHA1 used by "git" or 
SHA256 (or larger) if you're really paranoid.

On Wednesday, August 3, 2016 at 1:14:53 PM UTC-4, atd...@gmail.com wrote:
>
> Would a md5 hash suffice?
>
> I mean, it is probably easy to create collisions, but the source still 
> needs to compile so...
>
> Or an md5 hash and using go/types to make sure that any object escaping 
> the package boundaries is still present and none other have been added.
>
> Any idea?
>
>
>

-- 
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: Will compiler do optimization here?

[Hotei]

If you create the source as a byte array by converting it ([]byte("abcde") 
then the compiler can NOT optimize it away.  However - I don't think it 
will *use* the capacity information in the source since it's not relevant 
and it's going to copy the data bytes and length in any case. 

If you're worried about speed impacts I'd suggest benchmarking it.  I think 
the second one may be a nanosecond or two slower per copy. If you're 
looking for significant gains from optimizing this I believe you will be 
wasting time looking here.  

In my unsolicited opinion the first version is arguably "better", because 
it's easier to read/understand, not because it's faster.


I am still not clear about your answer, yes or not?
>

-- 
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: Will compiler do optimization here?

[Hotei]

Looking at the asm it appears that there is a conversion func called in the 
second version - right before the copy with memmove.

Based on this I'd say what happens AFTER the conversion is the same in both 
version since the destination is the same and the content is the same.  The 
only optimization I see is  not doing an unnecessary explicit conversion. 
 I'm not sure this helps.  Am I answering the right question?  

On Wednesday, August 3, 2016 at 11:27:36 AM UTC-4, T L wrote:
>
>
> I know a string value can be used as []byte if the first parameter if the 
> builtin copy/append function is a []byte value:
>
>> var bs []byte = make([]byte, 10)
>> copy(bs, "abcde")
>
>
> but if do explicit conversion anyway on the second string value  
>
>> var bs []byte = make([]byte, 10)
>> copy(bs, []byte("abcde"))
>>
> will compiler do optimization here to avoid copying the underline byte 
> array of the string? 
>
>

-- 
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: Will compiler do optimization here?

[Hotei]

Have you tried examining the assembler output?  go build -gcflags="-S" 
program.go if I recall correctly. 


On Wednesday, August 3, 2016 at 11:27:36 AM UTC-4, T L wrote:
>
>
> I know a string value can be used as []byte if the first parameter if the 
> builtin copy/append function is a []byte value:
>
>> var bs []byte = make([]byte, 10)
>> copy(bs, "abcde")
>
>
> but if do explicit conversion anyway on the second string value  
>
>> var bs []byte = make([]byte, 10)
>> copy(bs, []byte("abcde"))
>>
> will compiler do optimization here to avoid copying the underline byte 
> array of the string? 
>
>

-- 
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: Data locality in large slices

[Hotei]

With times under one nanosecond I'm wondering what you're actually 
measuring.  Aggressive optimization could make this an "empty" loop. 
 Synthetic benchmarks like this can be tricky to interpret.


On Wednesday, August 3, 2016 at 7:56:32 AM UTC-4, Ondrej wrote:
>
> I wanted to see if there was a difference when loading values from a 
> large-ish slice (1 elements) - to see if caches, locality and other 
> things had any meaningful impacts. Whilst individual value loading (just a 
> single element) seemed to be equally fast regardless of element position 
> (see bench of First, Second, Last, Penultimate), when combining loading of 
> various values, there seem to be almost a 2.5x difference between loading 
> first four values and loading last four values (first two benchmarks).
> Loading the same values, just in different order, also yields different 
> execution times. But alternating loading (0, n, 1, n-1) seems to be faster 
> than loading first two values and last two values.
>
> (Setting the test slice to be an array instead wipes all differences 
> between benchmarks.)
>
> Can anyone point me to a resource - be it Go specific or on computer 
> science principles - that would explain these large differences?
>
> Thanks!
>
> https://play.golang.org/p/oMqDvXI9YW
>

-- 
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: recommended push notification library for Go

[Hotei]

Depending on your needs (you didn't specify the target mobile devices) you 
can use go's SMTP facilities to send an email to a phone via an SMS 
gateway.  This list might help though I'm not sure how current it is.
 
http://mfitzp.io/list-of-email-to-sms-gateways/

On Thursday, July 28, 2016 at 3:12:33 PM UTC-4, Karthik Rajagopalan wrote:
>
> Hi Folks,
>
> I am looking for a  library which can be integrated with backend server 
> written in Go to handle push notification to mobile devices. Can you folks 
> share your experience on available options for Go?
>
> -Karthik
>

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