Re: [go-nuts] Cgo: using syscall.Select
On Wed, May 16, 2018 at 8:07 PM, Juliusz Chroboczek wrote:
>
> I'm interfacing with a C library that expects to do its own I/O, but
> wants to be called after a file descriptor is ready for read. My code
> currently looks roughly like this:
>
> var fdset syscall.FdSet
> var bits = unsafe.Sizeof(fdset.Bits[0]) * 8
> fdset.Bits[uintptr(fd)/bits] |= (1 << (fd % bits))
> var ctv C.struct_timeval
> C.gettimeout(&ctv)
> tv := syscall.Timeval{int64(ctv.tv_sec), int64(ctv.tv_usec)}
> n, err := syscall.Select(int(fd + 1), &fdset, nil, nil, &tv)
> if n < 0 {
> return err
> }
> rc, err := C.dostuff(fd)
> if(rc < 0) {
> return err
> }
>
> I'm bothered by two things:
>
> - the way I access the syscall.FdSet feels like an unportable hack;
> - I'd much rather hook into Go's scheduler then burn a thread on
> sleeping in select.
>
> Is the above the correct way to interface with the C library, or is
> there a better way?
If you do this in Go, you should use golang.org/x/sys/unix package
rather than the syscall package. But since you have to call C anyhow,
I would suggest just doing it in C.
There isn't any way to hook into Go's scheduler for this. Go's
scheduler provides no mechanism for waiting for data without reading
the data.
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.
[go-nuts] Encoding
Hello Guys, I have to convert a Json to a UTF_16LE and byte array for sign a rsa key, someone have idea that how I can do it? Thanks regards. -- 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: Reliable dns client library
miekg/dns is the best dns library by far and is actively maintained. If you see strange results I suggest submitting a bug report. -- kjk https://www.programming-books.io/essential/go/ On Wednesday, May 16, 2018 at 2:16:11 PM UTC-7, sbez...@cisco.com wrote: > > Hello, > > > > Appreciate if somebody could recommend reliable dns client library > supporting AXFR type of requests. > > I was using miekg/dns and I see some strange results. > > > > Thank you > > Serguei > -- 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 license and fitness for purpose
I hope so. I provide a package (github.com/kortschak/zalgo) that I cannot promise will not summon demons. It was written intentionally as a joke. I disclaim all liability should use of the package bring about meetings with demonic presences. On Wed, 2018-05-16 at 07:25 -0700, matthewju...@gmail.com wrote: > I think practical jokes should be allowed under the GPL, BSD, and > similar > licenses. -- 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] Cgo: using syscall.Select
I'm interfacing with a C library that expects to do its own I/O, but
wants to be called after a file descriptor is ready for read. My code
currently looks roughly like this:
var fdset syscall.FdSet
var bits = unsafe.Sizeof(fdset.Bits[0]) * 8
fdset.Bits[uintptr(fd)/bits] |= (1 << (fd % bits))
var ctv C.struct_timeval
C.gettimeout(&ctv)
tv := syscall.Timeval{int64(ctv.tv_sec), int64(ctv.tv_usec)}
n, err := syscall.Select(int(fd + 1), &fdset, nil, nil, &tv)
if n < 0 {
return err
}
rc, err := C.dostuff(fd)
if(rc < 0) {
return err
}
I'm bothered by two things:
- the way I access the syscall.FdSet feels like an unportable hack;
- I'd much rather hook into Go's scheduler then burn a thread on
sleeping in select.
Is the above the correct way to interface with the C library, or is
there a better way?
--
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] Godoc index generator fails in gob encoder due to size
I understand the limit in the gob encoder and where it's coming from. What I don't understand is that godoc uses it for local storage when such a limit can be hit very easily. Unless I'm mistaken godoc could use pretty much anything for local storage. It doesn't have to be compatible with anything. Would it make sense for me to build a patch (and PR) to change this to something less limited (but pure go for portability)? I'd rather not deviate from the official go distribution indefinitely. Best Regards, Carsten On Thursday, May 17, 2018 at 5:34:56 AM UTC+9, Rob 'Commander' Pike wrote: > > The encoder has a 1GB upper limit on message size. You're right that it > might not be documented. Or adjustable, which perhaps it should be, but > then you need to make sure both ends have the same setting. It's all rather > clumsy, writing big blobs on a network. See > https://github.com/golang/go/issues/14140. > > -rob > > > On Wed, May 16, 2018 at 5:36 PM, Carsten Orthbandt > wrote: > >> On my system the command >> >> godoc -v -index -index_files=/var/tmp/godoc_index.db -write_index >> >> runs for quite a while, then finishes with a warning message about the >> gob encoder: >> >> 2018/05/16 14:54:23 initialize file systems >> 2018/05/16 14:54:23 updating index... >> 2018/05/16 15:11:46 index updated (1042.388139246s, 519738767 bytes of >> source, 38378 files, 15129025 lines, 343889 unique words, 20260689 spots) >> 2018/05/16 15:11:46 before GC: bytes = 11159155064 footprint = 13770511160 >> 2018/05/16 15:11:47 after GC: bytes = 6213594416 footprint = 13770511160 >> 2018/05/16 15:11:47 writing index file /var/tmp/godoc_index.db >> 2018/05/16 15:11:57 gob: encoder: message too big >> >> It _does_ write /var/tmp/godoc_index.db but apparently it's pretty much >> empty (1.1kB in size). >> >> I can't find anything in the Github issues on this. Is it a known problem >> and I'm stupid? Should I file a bug? >> >> (I want to run godoc as a local service and avoid having the indexer run >> from scratch on every boot) >> >> Best Regards, >> Carsten >> >> >> carsten@xaos ~ $ go env >> GOARCH="amd64" >> GOBIN="" >> GOCACHE="/home/carsten/.cache/go-build" >> GOEXE="" >> GOHOSTARCH="amd64" >> GOHOSTOS="linux" >> GOOS="linux" >> GOPATH="/home/carsten/go" >> GORACE="" >> GOROOT="/usr/local/go" >> GOTMPDIR="" >> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" >> GCCGO="gccgo" >> CC="gcc" >> CXX="g++" >> CGO_ENABLED="1" >> CGO_CFLAGS="-g -O2" >> CGO_CPPFLAGS="" >> CGO_CXXFLAGS="-g -O2" >> CGO_FFLAGS="-g -O2" >> CGO_LDFLAGS="-g -O2" >> PKG_CONFIG="pkg-config" >> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 >> -fdebug-prefix-map=/tmp/go-build043246410=/tmp/go-build >> -gno-record-gcc-switches" >> >> -- >> 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...@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.
[go-nuts] Reliable dns client library
Hello, Appreciate if somebody could recommend reliable dns client library supporting AXFR type of requests. I was using miekg/dns and I see some strange results. Thank you Serguei -- 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] Godoc index generator fails in gob encoder due to size
The encoder has a 1GB upper limit on message size. You're right that it might not be documented. Or adjustable, which perhaps it should be, but then you need to make sure both ends have the same setting. It's all rather clumsy, writing big blobs on a network. See https://github.com/golang/go/issues/14140. -rob On Wed, May 16, 2018 at 5:36 PM, Carsten Orthbandt < carsten.orthba...@gmail.com> wrote: > On my system the command > > godoc -v -index -index_files=/var/tmp/godoc_index.db -write_index > > runs for quite a while, then finishes with a warning message about the gob > encoder: > > 2018/05/16 14:54:23 initialize file systems > 2018/05/16 14:54:23 updating index... > 2018/05/16 15:11:46 index updated (1042.388139246s, 519738767 bytes of > source, 38378 files, 15129025 lines, 343889 unique words, 20260689 spots) > 2018/05/16 15:11:46 before GC: bytes = 11159155064 footprint = 13770511160 > 2018/05/16 15:11:47 after GC: bytes = 6213594416 footprint = 13770511160 > 2018/05/16 15:11:47 writing index file /var/tmp/godoc_index.db > 2018/05/16 15:11:57 gob: encoder: message too big > > It _does_ write /var/tmp/godoc_index.db but apparently it's pretty much > empty (1.1kB in size). > > I can't find anything in the Github issues on this. Is it a known problem > and I'm stupid? Should I file a bug? > > (I want to run godoc as a local service and avoid having the indexer run > from scratch on every boot) > > Best Regards, > Carsten > > > carsten@xaos ~ $ go env > GOARCH="amd64" > GOBIN="" > GOCACHE="/home/carsten/.cache/go-build" > GOEXE="" > GOHOSTARCH="amd64" > GOHOSTOS="linux" > GOOS="linux" > GOPATH="/home/carsten/go" > GORACE="" > GOROOT="/usr/local/go" > GOTMPDIR="" > GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" > GCCGO="gccgo" > CC="gcc" > CXX="g++" > CGO_ENABLED="1" > CGO_CFLAGS="-g -O2" > CGO_CPPFLAGS="" > CGO_CXXFLAGS="-g -O2" > CGO_FFLAGS="-g -O2" > CGO_LDFLAGS="-g -O2" > PKG_CONFIG="pkg-config" > GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 > -fdebug-prefix-map=/tmp/go-build043246410=/tmp/go-build > -gno-record-gcc-switches" > > -- > 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.
[go-nuts] Re: Checking IP against CIDR ranges
Thanks guys, Patricia Tree did the trick -- 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: New tutorial:Code a simple P2P blockchain in Go!
Thanks for the feedback Ryan! On Monday, April 23, 2018 at 2:22:47 AM UTC-4, Ryan Yogan wrote: > > Absolutely fantastic! The series of articles were fun to work through, > and, for once the subject matter of block-chains just clicked for me! > > On Saturday, April 14, 2018 at 7:53:09 PM UTC-7, no...@mycoralhealth.com > wrote: >> >> >> https://medium.com/@mycoralhealth/code-a-simple-p2p-blockchain-in-go-46662601f417 >> >> Hi Everyone, >> We will show you how to run a simple blockchain in a truly decentralized, >> Peer-to-Peer fashion. >> >> Let us know what you think! >> >> >> >> -- 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: [ANN] Dependencies for dummies
You answered it, thanks. Matt On Wednesday, May 16, 2018 at 4:14:35 AM UTC-5, Gerardo Oscar JT wrote: > > Hello Matt, > > Having dependencies inside the project is the easiest way to make > reproducible builds (without having infrastructure for mirrors) and makes > your organization more independent from third parties. Moreover, tools > based on dependencies rules (like maven, npm, etc) could make your project > ending up with unexpected versions. How many libraries are in a regular > project, 10 maybe 20? managing versions by one by one and testing the side > effects of upgrading a library is affordable. Also, having all the code in > the same place makes the project reproducible for several years even if the > original repositories/vcs are not longer available or vcs has been > compromised with malicious code. > > Also, golla works with any git repos because destination folder is > indicated explicitly. > > Each tool has its pros and cons, this one fits what I expect from software > configuration. > > I hope having answered your question :) > > Chrs, > Fulldump > > > > > > El martes, 15 de mayo de 2018, 15:56:23 (UTC+2), matthe...@gmail.com > escribió: >> >> Hello, >> >> I haven’t seen this pattern: >> >> src/vendor/github.com/fulldump/goconfig >> >> I’ve put vendored dependencies in the project: >> >> src/github.com/my/project/vendor/github.com/fulldump/goconfig >> >> Why are you doing it this way? >> >> Have you tried vgo? https://github.com/golang/vgo >> >> Matt >> >> On Sunday, May 13, 2018 at 3:12:59 PM UTC-5, Gerardo Oscar JT wrote: >>> >>> Hi gophers! >>> >>> Golang do not have a canonical way to download dependencies. Glide is >>> the last one I have been using and it is like a drunk elephant in my laptop. >>> >>> This weekend I have managed to summon the force to work on a silly >>> script that read a list of git repos, and do the clones, one by one. >>> >>> For the moment it supports: >>> >>>- Clone a specific git repo inside a specific directory (removing >>>the .git folder) >>>- Pin a specific tag/branch/commit >>>- Select a specific file or directory inside a repo to avoid cloning >>>all the repo >>>- Comments prefixed with # are suported >>> >>> The project is called *golla*, here is the repo: >>> https://github.com/fulldump/golla >>> >>> All dependencies should be specified in a file called golla like this: >>> >>> # This is a golla file! >>> # First, we will clone a repo to a dir: >>> git@ github.com:fulldump/goconfig.git* ->* src/vendor/ >>> github.com/fulldump/goconfig >>> >>> # Here we will clone a specific version: >>> git@ github.com:fulldump/golax.git*#**v0.6.1* -> src/vendor/ >>> github.com/fulldump/golax >>> >>> # Only a file is cloned here (for example, golla script itself): >>> git@ github.com:fulldump/golla.git*>golla.go* -> golla.go >>> >>> >>> I hope this script could be helpful for anyone else. >>> >>> Happy to learn from your feedback, >>> Fulldump >>> >>> >>> -- 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: Validation checks in Go
I may have misunderstood the question. I follow the idea of panic when the
program is in an invalid state.
If Divide can receive any input then this is probably a better API:
func Divide(a, b float64) (float64, error) {
where you would return an ErrDivideByZero made with errors.New as a global
exported var instead of panicking.
But if Divide can only receive valid input then that assert seems
appropriate to me.
Matt
On Monday, May 14, 2018 at 7:38:32 PM UTC-5, Tristan Muntsinger wrote:
>
> Is it reasonable to use a function like "Assert" below to do validation
> checking in Go? If not, why not?
>
> func Assert(t bool, msg string) {
> if !t {
> debug.SetTraceback("all")
> debug.PrintStack()
> log.Fatal("Assertion failed: " + msg)
> }
> }
>
> func Divide(a float64, b float64) float64 {
> Assert(b != 0, "divide by 0")
> return a / b
> }
>
> func main() {
> fmt.Println(Divide(10, 5))
> }
>
> Thanks,
> -Tristan
>
>
--
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: Go license and fitness for purpose
> > It is not necessary to state up front that you are not willful and > malicious, or careless or negligent. Society expects that from you anyway. I think practical jokes should be allowed under the GPL, BSD, and similar licenses. If you really have legal concerns you should talk to a lawyer. Asking for > anonymous opinion on a forum isn't legal advice. This should certainly not > be the place to discuss legal matters such as the scope of a license. I > don't think anybody who answered you is actually a lawyer. If you come upon > something which you can't understand its license then don't use it. I agree. I’m not a lawyer. I can’t recommend any open source license for life critical applications, which is an opinion I’ll bring to any future employer. On my own I’ve just been making art with Go and hope that the MIT license protects me from misuse liability in the general purpose libraries I’ve pulled from the art projects and put on GitHub. I did get a fancy meal from them as we discussed the dangers of becoming > obligated because of not reading the fine print. I hope “oppressive” tends to mean “reasonable compromise”. Matt On Tuesday, May 15, 2018 at 9:18:05 PM UTC-5, David Skinner wrote: > > Regarding this statement. > >> THE AUTHORS OF THIS SOFTWARE DID NOT INTENTIONALLY MAKE MISTAKES OR >> INCLUDE PRACTICAL JOKES > > > If you place software out in the wild, and you have a LICENSE with no > warranty and indemnification and terms of service and imprint > >- You are not protected from frivolous law suits. >- You are not protected if your actions were willful and malicious, or >careless or negligent. >- You are not protected if you try to represent yourself pro se >- You are not protected if you are too broke to fight it in court. > > If you do go to court and your attorney is computer savvy, he may > demonstrate to the judge that there was a legal binding agreement that the > damaged party had to have been aware of when visiting the web site or > repository where the software was obtained. Most judges will seize upon > such proof to dismiss a case or rule in your favor. Especially if your > attorney testifies (inappropriate) that the agreement was one he drafted, > or reviewed for fitness. > > It is not necessary to state up front that you are not willful and > malicious, or careless or negligent. Society expects that from you anyway. > > This is not to be considered legal advice, it is just a personal > observation. > > For specific legal advice you should consult with your families attorney > in your jurisdiction. > > I once wrote a small program for a company on spec, it was too small for a > formal contract. What I did for my own protection was to prepare a shrink > wrap license that required them to scroll down and click OK before > installing. When I went back a couple of weeks later to see if they like > the utility program, they were very happy, until a gave them a hard copy of > the license agreement. I had included a clause that if they used the > program for more than one week they were obligated to provide me additional > compensation in the form of lunch at my favorite restaurant. They thought > it was a funny joke. I did get a fancy meal from them as we discussed the > dangers of becoming obligated because of not reading the fine print. > > You should be aware that if you do something as simple as putting your > resume on the Internet and getting a programming assignment from Germany, > you could be in for a stiff fine if you have not complied with their local > regulations regarding imprint. If you have any contact with the EU and you > fail to comply with their privacy laws then as a US citizen you may be > considered in violation of treaty, big fine. The US is not the only place > where the legal system can get oppressive. > -- 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] Godoc index generator fails in gob encoder due to size
On my system the command godoc -v -index -index_files=/var/tmp/godoc_index.db -write_index runs for quite a while, then finishes with a warning message about the gob encoder: 2018/05/16 14:54:23 initialize file systems 2018/05/16 14:54:23 updating index... 2018/05/16 15:11:46 index updated (1042.388139246s, 519738767 bytes of source, 38378 files, 15129025 lines, 343889 unique words, 20260689 spots) 2018/05/16 15:11:46 before GC: bytes = 11159155064 footprint = 13770511160 2018/05/16 15:11:47 after GC: bytes = 6213594416 footprint = 13770511160 2018/05/16 15:11:47 writing index file /var/tmp/godoc_index.db 2018/05/16 15:11:57 gob: encoder: message too big It _does_ write /var/tmp/godoc_index.db but apparently it's pretty much empty (1.1kB in size). I can't find anything in the Github issues on this. Is it a known problem and I'm stupid? Should I file a bug? (I want to run godoc as a local service and avoid having the indexer run from scratch on every boot) Best Regards, Carsten carsten@xaos ~ $ go env GOARCH="amd64" GOBIN="" GOCACHE="/home/carsten/.cache/go-build" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/home/carsten/go" GORACE="" GOROOT="/usr/local/go" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GCCGO="gccgo" CC="gcc" CXX="g++" CGO_ENABLED="1" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build043246410=/tmp/go-build -gno-record-gcc-switches" -- 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: [ANN] Dependencies for dummies
Hello Matt, Having dependencies inside the project is the easiest way to make reproducible builds (without having infrastructure for mirrors) and makes your organization more independent from third parties. Moreover, tools based on dependencies rules (like maven, npm, etc) could make your project ending up with unexpected versions. How many libraries are in a regular project, 10 maybe 20? managing versions by one by one and testing the side effects of upgrading a library is affordable. Also, having all the code in the same place makes the project reproducible for several years even if the original repositories/vcs are not longer available or vcs has been compromised with malicious code. Also, golla works with any git repos because destination folder is indicated explicitly. Each tool has its pros and cons, this one fits what I expect from software configuration. I hope having answered your question :) Chrs, Fulldump El martes, 15 de mayo de 2018, 15:56:23 (UTC+2), matthe...@gmail.com escribió: > > Hello, > > I haven’t seen this pattern: > > src/vendor/github.com/fulldump/goconfig > > I’ve put vendored dependencies in the project: > > src/github.com/my/project/vendor/github.com/fulldump/goconfig > > Why are you doing it this way? > > Have you tried vgo? https://github.com/golang/vgo > > Matt > > On Sunday, May 13, 2018 at 3:12:59 PM UTC-5, Gerardo Oscar JT wrote: >> >> Hi gophers! >> >> Golang do not have a canonical way to download dependencies. Glide is the >> last one I have been using and it is like a drunk elephant in my laptop. >> >> This weekend I have managed to summon the force to work on a silly script >> that read a list of git repos, and do the clones, one by one. >> >> For the moment it supports: >> >>- Clone a specific git repo inside a specific directory (removing the >>.git folder) >>- Pin a specific tag/branch/commit >>- Select a specific file or directory inside a repo to avoid cloning >>all the repo >>- Comments prefixed with # are suported >> >> The project is called *golla*, here is the repo: >> https://github.com/fulldump/golla >> >> All dependencies should be specified in a file called golla like this: >> >> # This is a golla file! >> # First, we will clone a repo to a dir: >> git@ github.com:fulldump/goconfig.git* ->* src/vendor/ >> github.com/fulldump/goconfig >> >> # Here we will clone a specific version: >> git@ github.com:fulldump/golax.git*#**v0.6.1* -> src/vendor/ >> github.com/fulldump/golax >> >> # Only a file is cloned here (for example, golla script itself): >> git@ github.com:fulldump/golla.git*>golla.go* -> golla.go >> >> >> I hope this script could be helpful for anyone else. >> >> Happy to learn from your feedback, >> Fulldump >> >> >> -- 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: Checking IP against CIDR ranges
See https://github.com/Kentik/patricia/ On Wednesday, 16 May 2018 03:38:26 UTC+3, XXX ZZZ wrote: > > Hello, > > I'm trying to check an IP against a list of several CIDR ranges, so far > the most obvious way to do it seems to parse both the IP and the cidr > ranges (ParseCIDR) and then do a net.contain() however, if we have more > than 1 CIDR we have to loop checking one by one which imho is incredible > unefficient + slow if the cidr range is big. > > Is there any more efficient way of achieving this? I have thought on > making a map[string]string with all the IPs (within the CIDR) but the > amount of required memory for big lists goes up to a few GB. > > 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.
