[go-nuts] Re: Go Community Charity Work?

We have to enforce some kind of central registry for the manufacturers, to avoid that anybody can create a key pair, use our software, and have vald unique verifiable codes, but be a drug counterteiter. -- You received this message because you are subscribed to the Google Groups "golang-nuts"

Re: [go-nuts] Where to stick temporary go files after an AST rewrite?

You can put them anywhere on your GOPATH. So for example, if you're on a unix-y system, $HOME/go is normally your GOPATH, and you want to rewrite the file $HOME/go/src/github.com/my/repo/hello.go, you could store the rewritten file at /tmp/go/src/github.com/my/repo/hello.go, and run the go tool

[go-nuts] Re: Go Community Charity Work?

So the manufacturer provides a number on a label that can be verified to have been written by them that is unique and unguessable for each label printing. We provide a program to generate these labels and a PWA to verify the labels. We’d need to serve the PWA on the Internet, and the label

Re: [go-nuts] Go get -f still checking VCS

AFAIK, go get can't download anything via "basic HTTP/S fetch". It always uses some kind of VCS. So if you don't have a VCS installed, go get won't work for you. You will need to determine all the dependencies yourself and place their source code in your GOPATH. On Wed, Oct 4, 2017 at 1:26 AM

[go-nuts] Re: Go Community Charity Work?

2017. december 26., kedd 21:59:17 UTC+1 időpontban Frank Davidson a következőt írta: > > I was thinking a Progressive Web App (PWA) to avoid writing multiple > Android, Web, iOS apps... I know QR codes are more broadly used but I'm not > sure if they can store the amount of info we would

[go-nuts] Re: Go Community Charity Work?

I was thinking a Progressive Web App (PWA) to avoid writing multiple Android, Web, iOS apps... I know QR codes are more broadly used but I'm not sure if they can store the amount of info we would need? I think you need 384 bits plus the data we need to encode for secure ECDSA? Aztec codes seem

Re: [go-nuts] Possible bug on os.Stat and mode is symlink

On Mon, Dec 25, 2017 at 1:48 AM, Shulhan wrote: > Environment > > OS: Linux xenom-bubu 4.14.8-1-ARCH #1 SMP PREEMPT Wed Dec 20 21:27:44 > UTC 2017 x86_64 GNU/Linux > > Go: go1.10beta1 linux/amd64 > > Steps to reproduce > > $ mkdir testSymlink > $ cd testSymlink > $ touch

[go-nuts] Re: Go Community Charity Work?

On Tuesday, December 26, 2017 at 10:42:34 AM UTC-6, Frank Davidson wrote: > > Might make sense to port https://github.com/zxing to Go? Seems a popular >> library and I think it was created by Google folks >> > Android already provides AZTEC reader:

Re: [go-nuts] Re: dep and versioning : how are conflicts dealt with ?

I'd try to do the same thing, just at the interface level, like the kernel does. Eg, preadv2 as  described at https://lwn.net/Articles/670231/ --dave On 26/12/17 11:42 AM, Fabien wrote: Thank you, lots of food for thought. For the go package-writer, now, I guess the best practice so as not

Re: [go-nuts] Re: dep and versioning : how are conflicts dealt with ?

I'd try to do the same thing, just at the interface level, like the kernel does. Eg, preadv2 as  described at https://lwn.net/Articles/670231/ --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest

[go-nuts] Re: Go Community Charity Work?

My thought is we'd just be a source of UUIDs. The request for a barcode block would be verified with keys, but the barcodes have no cryptography besides us solely holding what is associated with the UUID. The manufacturer would have the ability to track that information too if they chose to

[go-nuts] Re: Go Community Charity Work?

Might make sense to port https://github.com/zxing to Go? Seems a popular library and I think it was created by Google folks. On Tuesday, December 26, 2017 at 11:29:44 AM UTC-5, Frank Davidson wrote: > > I'm not sure we could encrypt codes for them as we would not have their > private key? I

[go-nuts] Re: dep and versioning : how are conflicts dealt with ?

Thank you, lots of food for thought. For the go package-writer, now, I guess the best practice so as not to be part of the problem is to 1- in minor revisions, of course, keep backward-compatibility. 2- in major revisions, either: - make a new project, for instance, if my first project was

[go-nuts] Re: Go Community Charity Work?

I'm not sure we could encrypt codes for them as we would not have their private key? I think we could provide an CLI executable that could make it really easy, though. on virtually any OS (the benefits of Go!)... Also, I agree on the advertising but it's not a deal breaker for me if they did.

[go-nuts] Re: Go Community Charity Work?

For implementation I’m of the opinion that we should own everything besides printing the labels. There is only the one path of data between the consumer and our server+database in a cloud center. We nor the manufacturers should be able to advertise to consumers through this, and consumers

[go-nuts] Re: dep and versioning : how are conflicts dealt with ?

Lots of in-line reply-bits (;-)) On Tuesday, December 26, 2017 at 8:58:47 AM UTC-5, Fabien wrote: > > Thank you, that's a very interesting read. > > TLDR: If I understood everything, NP-complete != DLL hell, but anyway, go > is vulnerable to DLL hell, so we're screwed. > > I'm not sure I

[go-nuts] Re: Go 1.10 Beta 1 is released

Are there any restrictions on arch for go's plugin? I am finding that both 1.9 and 1.10beta1 fail when attempting to open plugin (.so) on arm64 chips/SOCs. same code work fine on amd64. OS is linux of course. panic is coming from: src/runtime/plugin.go:21 - "runtime: no plugin module

[go-nuts] Re: Go Community Charity Work?

Yes, that's the Aztec library I saw for creating the codes. Looking now for a good OS library for reading them... I'm thinking the sequence would go something like this: 1. Manufacturer creates key pair 2. They register their public key with our central server 3. The public key is

Re: [go-nuts] Re: select multiple expressions per case

My concern was about a shared ok. On Mon, Dec 25, 2017 at 1:22 PM, wrote: > Well my almost-use-case was just for signaling without assignment. The > assignment cases are something that would need to be addressed by such a > feature. I like your pattern as a Go 1

[go-nuts] database/sql: what about Conn.StmtContext?

The Tx type has a method StmtContext to return a transaction-specific prepared statement from an existing statement. But the Conn type does not have such a method; what is the reason? The Conn.PrepareContext returns a prepared statement that is executed on the same driver.Conn (see #20647).

[go-nuts] Re: dep and versioning : how are conflicts dealt with ?

Thank you, that's a very interesting read. TLDR: If I understood everything, NP-complete != DLL hell, but anyway, go is vulnerable to DLL hell, so we're screwed. I'm not sure I understand everything, though. Both your article and Russ Cox' you mention seem to confuse NP-completeness and the