Re: [go-nuts] Persistent memory support for Go

[Robert Engels]

And no need to be sorry. You didn’t do anything wrong at all. 

> On Apr 3, 2019, at 6:32 PM, 'Mohit Verma' via golang-nuts 
>  wrote:
> 
> Hi Robert,
>  
> Sorry for the confusion. Our changes are to make byte-addressable persistent 
> memory support available to Go community. You can find more information about 
> this technology here:
> 1. http://pmem.io/
> 2. 
> https://www.intel.com/content/www/us/en/architecture-and-technology/optane-dc-persistent-memory.html
>  
> >>> I think the project needs to be distributed as a patch to the Go codebase 
> >>> - too much to review/maintain for security controls. 
> We eventually plan to distribute our changes as patches to Go codebase, but 
> before we do that we wanted to gather feedback here 
>  
> >>> Also, I’ve used pmem for a very long time (I have a bg in retail point of 
> >>> sale systems where it is very common) and we always had a driver/library 
> >>> on top of the physical device to multiplex across consumers, and we used 
> >>> it from Java, and never needed specialized JVM to use it efficiently. 
> >>> Again, just curious, maybe the use cases have changed.
> The recent technological changes have put this technology close to the access 
> speeds of DRAM,  while retaining the persistence property. Quoting from the 
> blog post in Jerrin’s original e-mail:
> “Ad hoc libraries often provide a difficult programming interface. As memory 
> management for RAM has increasingly become a part of programming languages, 
> we believe managing persistent memory should be addressed in the same manner. 
> And so, our programming model includes changes to Go itself ”.
>  
> There has been a lot of work around this technology in the past few years, 
> including efforts to change C and Java, and adhoc libraries for C/C++, Java 
> and Python. These changes are our efforts to make persistent memory 
> accessible to Go developers.
>  
> Thanks!
> Mohit
>  
> From: Robert Engels 
> Date: Wednesday, April 3, 2019 at 4:00 PM
> To: Jerrin Shaji George 
> Cc: "golang-nuts@googlegroups.com" , Mohit 
> Verma , Pratap Subrahmanyam , Rajesh 
> Venkatasubramanian 
> Subject: Re: [go-nuts] Persistent memory support for Go
>  
> Also, I’ve used pmem for a very long time (I have a bg in retail point of 
> sale systems where it is very common) and we always had a driver/library on 
> top of the physical device to multiplex across consumers, and we used it from 
> Java, and never needed specialized JVM to use it efficiently. Again, just 
> curious, maybe the use cases have changed. 
> 
> On Apr 3, 2019, at 5:47 PM, Robert Engels  wrote:
> 
> I think the project needs to be distributed as a patch to the Go codebase - 
> too much to review/maintain for security controls. 
>  
> Also, I’m curious about the Api. In reviewing the example, it looks no 
> different than any ORM - just flatter -and these don’t need a customized 
> runtime. 
>  
> What would be the advantage of using the Api directly rather than using Redis 
> (with the support there)?
>  
> No criticism, just not obvious to me. Maybe a link describing the persistent 
> memory capabilities in detail?
> 
> On Apr 3, 2019, at 5:31 PM, 'Jerrin Shaji George' via golang-nuts 
>  wrote:
> 
> Hi,
>  
> I am part of a small team at VMware working on projects related to persistent
> memory (others in CC). We have recently been working on adding persistent 
> memory
> support to the Go programming language, and I wanted to spread the word about
> couple of these projects.
>  
> 1) Go-pmem-transaction
> The go-pmem-transaction project introduces a new programming model for
> developing applications in Go for persistent memory. It consists of two 
> packages
> - pmem and transaction.
>  
> The pmem package provides methods to initialize persistent memory and an
> interface to set and retrieve objects in persistent memory. The transaction
> package provides undo and redo transaction logging APIs to support
> crash-consistent updates to persistent memory data.
>  
> Project page - https://github.com/vmware/go-pmem-transaction
>  
> 2) Go-pmem
> The Go-pmem project adds native persistent memory support to Go.
> Some of the features of the persistent memory support added to Go are:
> * Support for persistent memory allocations
> * Garbage collector now collects objects from persistent heap 
> and volatile
> heap
> * Runtime automatically swizzles pointers if the memory 
> mapping address
> changes on an application restart
> * The persistent memory heap is dynamically sized and 
> supports automatic
> heap growth depending on memory demand
>  
> Project page - https://github.com/jerrinsg/go-pmem
>  
> The project pages contains links to further documentation. We welcome the
> community to try out these projects and send any feedback our way!
>  
> Also see the blog post at 
> 

Re: [go-nuts] Persistent memory support for Go

['Mohit Verma' via golang-nuts]

Hi Robert,



Sorry for the confusion. Our changes are to make byte-addressable persistent 
memory support available to Go community. You can find more information about 
this technology here:

1. http://pmem.io/

2. 
https://www.intel.com/content/www/us/en/architecture-and-technology/optane-dc-persistent-memory.html


>>> I think the project needs to be distributed as a patch to the Go codebase - 
>>> too much to review/maintain for security controls.

We eventually plan to distribute our changes as patches to Go codebase, but 
before we do that we wanted to gather feedback here 



>>> Also, I’ve used pmem for a very long time (I have a bg in retail point of 
>>> sale systems where it is very common) and we always had a driver/library on 
>>> top of the physical device to multiplex across consumers, and we used it 
>>> from Java, and never needed specialized JVM to use it efficiently. Again, 
>>> just curious, maybe the use cases have changed.

The recent technological changes have put this technology close to the access 
speeds of DRAM,  while retaining the persistence property. Quoting from the 
blog 
post in Jerrin’s original e-mail:

“Ad hoc libraries often provide a difficult programming interface. As memory 
management for RAM has increasingly become a part of programming languages, we 
believe managing persistent memory should be addressed in the same manner. And 
so, our programming model includes changes to Go itself ”.


There has been a lot of work around this technology in the past few years, 
including efforts to change 
C
 and Java, and adhoc libraries for 
C/C++, Java and 
Python. These changes are our efforts to make 
persistent memory accessible to Go developers.

Thanks!
Mohit

From: Robert Engels 
Date: Wednesday, April 3, 2019 at 4:00 PM
To: Jerrin Shaji George 
Cc: "golang-nuts@googlegroups.com" , Mohit Verma 
, Pratap Subrahmanyam , Rajesh 
Venkatasubramanian 
Subject: Re: [go-nuts] Persistent memory support for Go

Also, I’ve used pmem for a very long time (I have a bg in retail point of sale 
systems where it is very common) and we always had a driver/library on top of 
the physical device to multiplex across consumers, and we used it from Java, 
and never needed specialized JVM to use it efficiently. Again, just curious, 
maybe the use cases have changed.

On Apr 3, 2019, at 5:47 PM, Robert Engels 
mailto:reng...@ix.netcom.com>> wrote:
I think the project needs to be distributed as a patch to the Go codebase - too 
much to review/maintain for security controls.

Also, I’m curious about the Api. In reviewing the example, it looks no 
different than any ORM - just flatter -and these don’t need a customized 
runtime.

What would be the advantage of using the Api directly rather than using Redis 
(with the support there)?

No criticism, just not obvious to me. Maybe a link describing the persistent 
memory capabilities in detail?

On Apr 3, 2019, at 5:31 PM, 'Jerrin Shaji George' via golang-nuts 
mailto:golang-nuts@googlegroups.com>> wrote:
Hi,

I am part of a small team at VMware working on projects related to persistent
memory (others in CC). We have recently been working on adding persistent memory
support to the Go programming language, and I wanted to spread the word about
couple of these projects.

1) Go-pmem-transaction
The go-pmem-transaction project introduces a new programming model for
developing applications in Go for persistent memory. It consists of two packages
- pmem and transaction.

The pmem package provides methods to initialize persistent memory and an
interface to set and retrieve objects in persistent memory. The transaction
package provides undo and redo transaction logging APIs to support
crash-consistent updates to persistent memory data.

Project page - 
https://github.com/vmware/go-pmem-transaction

2) Go-pmem
The Go-pmem project adds native persistent memory support to Go.
Some of the features of the persistent memory support added to Go are:
* Support for persistent memory allocations
* Garbage collector now collects objects from persistent heap 
and volatile
heap
* Runtime automatically swizzles pointers if the memory mapping 
address
changes on an application restart
* The persistent memory heap is dynamically sized and supports 
automatic

Re: [go-nuts] Persistent memory support for Go

[Robert Engels]

Thanks for the info!

> On Apr 3, 2019, at 6:32 PM, Mohit Verma  wrote:
> 
> Hi Robert,
>  
> Sorry for the confusion. Our changes are to make byte-addressable persistent 
> memory support available to Go community. You can find more information about 
> this technology here:
> 1. http://pmem.io/
> 2. 
> https://www.intel.com/content/www/us/en/architecture-and-technology/optane-dc-persistent-memory.html
>  
> >>> I think the project needs to be distributed as a patch to the Go codebase 
> >>> - too much to review/maintain for security controls. 
> We eventually plan to distribute our changes as patches to Go codebase, but 
> before we do that we wanted to gather feedback here 
>  
> >>> Also, I’ve used pmem for a very long time (I have a bg in retail point of 
> >>> sale systems where it is very common) and we always had a driver/library 
> >>> on top of the physical device to multiplex across consumers, and we used 
> >>> it from Java, and never needed specialized JVM to use it efficiently. 
> >>> Again, just curious, maybe the use cases have changed.
> The recent technological changes have put this technology close to the access 
> speeds of DRAM,  while retaining the persistence property. Quoting from the 
> blog post in Jerrin’s original e-mail:
> “Ad hoc libraries often provide a difficult programming interface. As memory 
> management for RAM has increasingly become a part of programming languages, 
> we believe managing persistent memory should be addressed in the same manner. 
> And so, our programming model includes changes to Go itself ”.
>  
> There has been a lot of work around this technology in the past few years, 
> including efforts to change C and Java, and adhoc libraries for C/C++, Java 
> and Python. These changes are our efforts to make persistent memory 
> accessible to Go developers.
>  
> Thanks!
> Mohit
>  
> From: Robert Engels 
> Date: Wednesday, April 3, 2019 at 4:00 PM
> To: Jerrin Shaji George 
> Cc: "golang-nuts@googlegroups.com" , Mohit 
> Verma , Pratap Subrahmanyam , Rajesh 
> Venkatasubramanian 
> Subject: Re: [go-nuts] Persistent memory support for Go
>  
> Also, I’ve used pmem for a very long time (I have a bg in retail point of 
> sale systems where it is very common) and we always had a driver/library on 
> top of the physical device to multiplex across consumers, and we used it from 
> Java, and never needed specialized JVM to use it efficiently. Again, just 
> curious, maybe the use cases have changed. 
> 
> On Apr 3, 2019, at 5:47 PM, Robert Engels  wrote:
> 
> I think the project needs to be distributed as a patch to the Go codebase - 
> too much to review/maintain for security controls. 
>  
> Also, I’m curious about the Api. In reviewing the example, it looks no 
> different than any ORM - just flatter -and these don’t need a customized 
> runtime. 
>  
> What would be the advantage of using the Api directly rather than using Redis 
> (with the support there)?
>  
> No criticism, just not obvious to me. Maybe a link describing the persistent 
> memory capabilities in detail?
> 
> On Apr 3, 2019, at 5:31 PM, 'Jerrin Shaji George' via golang-nuts 
>  wrote:
> 
> Hi,
>  
> I am part of a small team at VMware working on projects related to persistent
> memory (others in CC). We have recently been working on adding persistent 
> memory
> support to the Go programming language, and I wanted to spread the word about
> couple of these projects.
>  
> 1) Go-pmem-transaction
> The go-pmem-transaction project introduces a new programming model for
> developing applications in Go for persistent memory. It consists of two 
> packages
> - pmem and transaction.
>  
> The pmem package provides methods to initialize persistent memory and an
> interface to set and retrieve objects in persistent memory. The transaction
> package provides undo and redo transaction logging APIs to support
> crash-consistent updates to persistent memory data.
>  
> Project page - https://github.com/vmware/go-pmem-transaction
>  
> 2) Go-pmem
> The Go-pmem project adds native persistent memory support to Go.
> Some of the features of the persistent memory support added to Go are:
> * Support for persistent memory allocations
> * Garbage collector now collects objects from persistent heap 
> and volatile
> heap
> * Runtime automatically swizzles pointers if the memory 
> mapping address
> changes on an application restart
> * The persistent memory heap is dynamically sized and 
> supports automatic
> heap growth depending on memory demand
>  
> Project page - https://github.com/jerrinsg/go-pmem
>  
> The project pages contains links to further documentation. We welcome the
> community to try out these projects and send any feedback our way!
>  
> Also see the blog post at 
> https://blogs.vmware.com/opensource/2019/04/03/persistent-memory-with-go/
>  
> Thanks,
> Jerrin
> -- 
> You received 

Re: [go-nuts] go in cloud server

[David Riley]

On Apr 3, 2019, at 11:34 AM, Shyaka Rene  wrote:
> 
> 
> Hello.
> I'm new to go, i'm looking for a programming language to replace java. I have 
> simple questions
>   • is it a good idea to deploy go in cloud server if go is compiled to 
> machine binaries, what can happen if the cloud provider changes the physical 
> server to different processor architecture.

This is a concern for Java, too, in that you have to have a JVM to run on. Go 
builds easily for most common cloud architectures these days (amd64, ppc64le, 
arm/aarch64, s390) and less easily for a few others (e.g. sparc).  Do 
multi-architecture builds to protect yourself.

If you're building for modern cloud infrastructure, you may be using Docker; 
Docker supports multi-architecture images, so if you do your build system 
correctly, you should be able to build image bundles that support a bunch of 
different architectures reasonably easily.

It's maybe somewhat less easy than distributing a Java binary across multiple 
architectures, but ultimately it's probably easier than maintaining something 
that needs to run well across different Unixes and beyond (OpenVMS, IBM i to 
name a few).

That said, most cloud providers aren't in the business of suddenly changing 
their entire processor architecture to something incompatible, unless they're 
Oracle.

>   • does go have embedded relational database management system similar 
> to h2 in java. google gives me key/value pair embedded database
>any help is appreciated. thank you

Go has lots of interfaces to lots of databases, from key/value (memcached, 
Redis, bdb) to relational (an flexible SQL interface with drivers for most 
popular RDBs including sqlite) to popular non-SQL databases (Couchbase, Mongo, 
etc).  Others on the list have also pointed out a few other embedded ones 
available for Go of which I wasn't aware, so that's very exciting.


- Dave

-- 
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] Persistent memory support for Go

[Robert Engels]

Also, I’ve used pmem for a very long time (I have a bg in retail point of sale 
systems where it is very common) and we always had a driver/library on top of 
the physical device to multiplex across consumers, and we used it from Java, 
and never needed specialized JVM to use it efficiently. Again, just curious, 
maybe the use cases have changed. 

> On Apr 3, 2019, at 5:47 PM, Robert Engels  wrote:
> 
> I think the project needs to be distributed as a patch to the Go codebase - 
> too much to review/maintain for security controls. 
> 
> Also, I’m curious about the Api. In reviewing the example, it looks no 
> different than any ORM - just flatter -and these don’t need a customized 
> runtime. 
> 
> What would be the advantage of using the Api directly rather than using Redis 
> (with the support there)?
> 
> No criticism, just not obvious to me. Maybe a link describing the persistent 
> memory capabilities in detail?
> 
>> On Apr 3, 2019, at 5:31 PM, 'Jerrin Shaji George' via golang-nuts 
>>  wrote:
>> 
>> Hi,
>>  
>> I am part of a small team at VMware working on projects related to persistent
>> memory (others in CC). We have recently been working on adding persistent 
>> memory
>> support to the Go programming language, and I wanted to spread the word about
>> couple of these projects.
>>  
>> 1) Go-pmem-transaction
>> The go-pmem-transaction project introduces a new programming model for 
>> developing applications in Go for persistent memory. It consists of two 
>> packages
>> - pmem and transaction.
>>  
>> The pmem package provides methods to initialize persistent memory and an
>> interface to set and retrieve objects in persistent memory. The transaction
>> package provides undo and redo transaction logging APIs to support
>> crash-consistent updates to persistent memory data.
>>  
>> Project page - https://github.com/vmware/go-pmem-transaction
>>  
>> 2) Go-pmem
>> The Go-pmem project adds native persistent memory support to Go.
>> Some of the features of the persistent memory support added to Go are:
>> * Support for persistent memory allocations
>> * Garbage collector now collects objects from persistent 
>> heap and volatile
>> heap
>> * Runtime automatically swizzles pointers if the memory 
>> mapping address
>> changes on an application restart
>> * The persistent memory heap is dynamically sized and 
>> supports automatic
>> heap growth depending on memory demand
>>  
>> Project page - https://github.com/jerrinsg/go-pmem
>>  
>> The project pages contains links to further documentation. We welcome the
>> community to try out these projects and send any feedback our way!
>>  
>> Also see the blog post at 
>> https://blogs.vmware.com/opensource/2019/04/03/persistent-memory-with-go/
>>  
>> Thanks,
>> Jerrin
>> -- 
>> 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.

-- 
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] Persistent memory support for Go

[Robert Engels]

Never mind on the “what is pmem” as I found the VMware docs. 

I am curious though why you need specialized runtime support rather than mmap 
on a block device? I am assuming that the api is slightly easier to use from a 
standard Go perspective but given the variable performance characteristics of 
pmem I don’t see why it shouldn’t be treated like any other external resource. 

> On Apr 3, 2019, at 5:47 PM, Robert Engels  wrote:
> 
> I think the project needs to be distributed as a patch to the Go codebase - 
> too much to review/maintain for security controls. 
> 
> Also, I’m curious about the Api. In reviewing the example, it looks no 
> different than any ORM - just flatter -and these don’t need a customized 
> runtime. 
> 
> What would be the advantage of using the Api directly rather than using Redis 
> (with the support there)?
> 
> No criticism, just not obvious to me. Maybe a link describing the persistent 
> memory capabilities in detail?
> 
>> On Apr 3, 2019, at 5:31 PM, 'Jerrin Shaji George' via golang-nuts 
>>  wrote:
>> 
>> Hi,
>>  
>> I am part of a small team at VMware working on projects related to persistent
>> memory (others in CC). We have recently been working on adding persistent 
>> memory
>> support to the Go programming language, and I wanted to spread the word about
>> couple of these projects.
>>  
>> 1) Go-pmem-transaction
>> The go-pmem-transaction project introduces a new programming model for 
>> developing applications in Go for persistent memory. It consists of two 
>> packages
>> - pmem and transaction.
>>  
>> The pmem package provides methods to initialize persistent memory and an
>> interface to set and retrieve objects in persistent memory. The transaction
>> package provides undo and redo transaction logging APIs to support
>> crash-consistent updates to persistent memory data.
>>  
>> Project page - https://github.com/vmware/go-pmem-transaction
>>  
>> 2) Go-pmem
>> The Go-pmem project adds native persistent memory support to Go.
>> Some of the features of the persistent memory support added to Go are:
>> * Support for persistent memory allocations
>> * Garbage collector now collects objects from persistent 
>> heap and volatile
>> heap
>> * Runtime automatically swizzles pointers if the memory 
>> mapping address
>> changes on an application restart
>> * The persistent memory heap is dynamically sized and 
>> supports automatic
>> heap growth depending on memory demand
>>  
>> Project page - https://github.com/jerrinsg/go-pmem
>>  
>> The project pages contains links to further documentation. We welcome the
>> community to try out these projects and send any feedback our way!
>>  
>> Also see the blog post at 
>> https://blogs.vmware.com/opensource/2019/04/03/persistent-memory-with-go/
>>  
>> Thanks,
>> Jerrin
>> -- 
>> 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.

-- 
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] Persistent memory support for Go

[Robert Engels]

I think the project needs to be distributed as a patch to the Go codebase - too 
much to review/maintain for security controls. 

Also, I’m curious about the Api. In reviewing the example, it looks no 
different than any ORM - just flatter -and these don’t need a customized 
runtime. 

What would be the advantage of using the Api directly rather than using Redis 
(with the support there)?

No criticism, just not obvious to me. Maybe a link describing the persistent 
memory capabilities in detail?

> On Apr 3, 2019, at 5:31 PM, 'Jerrin Shaji George' via golang-nuts 
>  wrote:
> 
> Hi,
>  
> I am part of a small team at VMware working on projects related to persistent
> memory (others in CC). We have recently been working on adding persistent 
> memory
> support to the Go programming language, and I wanted to spread the word about
> couple of these projects.
>  
> 1) Go-pmem-transaction
> The go-pmem-transaction project introduces a new programming model for
> developing applications in Go for persistent memory. It consists of two 
> packages
> - pmem and transaction.
>  
> The pmem package provides methods to initialize persistent memory and an
> interface to set and retrieve objects in persistent memory. The transaction
> package provides undo and redo transaction logging APIs to support
> crash-consistent updates to persistent memory data.
>  
> Project page - https://github.com/vmware/go-pmem-transaction
>  
> 2) Go-pmem
> The Go-pmem project adds native persistent memory support to Go.
> Some of the features of the persistent memory support added to Go are:
> * Support for persistent memory allocations
> * Garbage collector now collects objects from persistent heap 
> and volatile
> heap
> * Runtime automatically swizzles pointers if the memory 
> mapping address
> changes on an application restart
> * The persistent memory heap is dynamically sized and 
> supports automatic
> heap growth depending on memory demand
>  
> Project page - https://github.com/jerrinsg/go-pmem
>  
> The project pages contains links to further documentation. We welcome the
> community to try out these projects and send any feedback our way!
>  
> Also see the blog post at 
> https://blogs.vmware.com/opensource/2019/04/03/persistent-memory-with-go/
>  
> Thanks,
> Jerrin
> -- 
> 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.

Re: [go-nuts] how golang creates binary

[Ian Lance Taylor]

On Wed, Apr 3, 2019 at 12:27 PM  wrote:
>
> Hi,
> Any one explain the background process of go build or how go build creates 
> shared objects and include into go binary.
> Here sharing my experience with c shared files.
> Earlier I worked with there we creating some shared objects of my projects 
> and collected manually and using.
>
> Here is the scenario I observed with go binary.
> I ran this command in Linux ldd   and got dependency shared objects 
> (.so) of Linux.
>
> If possible please explain how go binary communicate/use  linux shared 
> objects(.so)

On many systems, a Go program that uses cgo, or that uses the net or
os/user packages, will be linked against system shared libraries.
These are used for cgo support, or for GODEBUG=netdns=cgo (see
https://golang.org/pkg/net) or calls to getpwuid and friends.  A Go
program uses a shared library exactly the same way that a C program
does.

I hope that helps.  If you want a more specific answer I encourage you
to ask a more specific question.

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] Persistent memory support for Go

['Jerrin Shaji George' via golang-nuts]

Hi,

I am part of a small team at VMware working on projects related to persistent
memory (others in CC). We have recently been working on adding persistent memory
support to the Go programming language, and I wanted to spread the word about
couple of these projects.

1) Go-pmem-transaction
The go-pmem-transaction project introduces a new programming model for
developing applications in Go for persistent memory. It consists of two packages
- pmem and transaction.

The pmem package provides methods to initialize persistent memory and an
interface to set and retrieve objects in persistent memory. The transaction
package provides undo and redo transaction logging APIs to support
crash-consistent updates to persistent memory data.

Project page - https://github.com/vmware/go-pmem-transaction

2) Go-pmem
The Go-pmem project adds native persistent memory support to Go.
Some of the features of the persistent memory support added to Go are:
* Support for persistent memory allocations
* Garbage collector now collects objects from persistent heap 
and volatile
heap
* Runtime automatically swizzles pointers if the memory mapping 
address
changes on an application restart
* The persistent memory heap is dynamically sized and supports 
automatic
heap growth depending on memory demand

Project page - https://github.com/jerrinsg/go-pmem

The project pages contains links to further documentation. We welcome the
community to try out these projects and send any feedback our way!

Also see the blog post at 
https://blogs.vmware.com/opensource/2019/04/03/persistent-memory-with-go/

Thanks,
Jerrin

-- 
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] Using Closures to Generate Code On the Fly

[Louki Sumirniy]

I have been doing a lot of work involving essentially declarative 
(nominally) complex data types involving several layers of encapsulation.

I had seen here and there examples of this 'Fluent' method-based pipeline 
chaining, with methods passing through receivers to invoke multiple 
distinct functions in the type. Here is a gist about it with an example:

https://git.parallelcoin.io/loki/gists/src/commit/d6cabfd0933d0cda731217c371e0295db331ebb1/tailrecursion-generic.md

It occurred to me that if one used this to construct complex graphs of 
processing, that the CPU's branch predictor would probably be on fire for 
that time, since even though these binary blobs are being possibly 
arbitrarily constructed based on random inputs, they will have a 
substantial amount off scope in common, so...

It might then be possible to further amplify this effect by allowing the 
runtime to lay the code ahead of the execution a bit like Magneto pulling 
those metal blocks up as he walks forwards.

I don't know how verbose it is, just at first blush, I am generally not 
fond of closure syntax in Go, but it seems to me like this dynamic 
construction pattern would be very good for speeding up complex processing 
with significant variance in sequence.

For example, playing back a journal into a database - a scouting thread 
could pre-process some of the key but simple and salient data about the 
segments of the journal, and construct ahead of time cache locality 
optimised code and data segmentation that will run with 100% confidence 
based on the structure and composition of the data.

At the moment I am just using it to chain validators together, but, for 
example, generating a graph from a blockchain ledger, in order to perform 
validation, can have a front-running pass that first generates the 
join/split paths of tokens intersecting with accounts. This graph forms the 
map of how to process the data, and for parallelisation, such a graph would 
allow the replay processing to be split automatically to make optimal use 
of cores, caches and memory bus. It could even farm the work out acrosss 
the network and all of the cluster nodes process their mostly isolated 
segment, then share their database tables directly and voila.

Such processing is naturally easier to construct using recursion, and with 
composition of closures in this way, it should also be quite efficient. 
Although at with current go 1.10+ syntax it is a little clumsy, each part 
is small and this helps a lot.

When I am making big changes to code, I have this sensation like I am 
walking on unstable ground, because sometimes I can get a way into 
something and discover I passed the correct route some way back and I 
didn't commit before it and now I have to start all over again.

Small pieces less than a screenful at a time are very manageable. Just 
gotta get a handle on that vertigo :)

-- 
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] Why does "go mod" ignore tags in this case?

[Tom Payne]

Thanks Roger.

To close this topic, you were right: I'd missed that there is a special
release process for v2 of a module and above, and also go's mod cache was
out-of-sync as I'd been moving tags around. "go mod verify" is your friend.

On Thu, 21 Feb 2019 at 09:05, roger peppe  wrote:

> I suspect it's because it's version 2. Major version v2 and above needs to
> have the version in the import path.
> So the correct import path for your package would be:
>
>github.com/twpayne/go-xdg/v2
>
> It might be nice if the go tool complained about this at some stage of the
> process; I suspect that's the role of the (currently non-existent) "go
> release" tool.
>
>   cheers,
> rog.
>
> On Wed, 20 Feb 2019 at 23:54,  wrote:
>
>> tl;dr "go mod" writes a timestamp/commit hash to go.mod when a perfectly
>> good tag exists. I don't understand why go.mod doesn't use the tag.
>>
>>
>> Given this library
>>
>>   https://github.com/twpayne/go-xdg
>>
>> with a "v2.0.0" tag:
>>
>>   https://github.com/twpayne/go-xdg/releases/tag/v2.0.0
>>
>> if I create a trivial program that uses it, like
>>
>>   https://gist.github.com/twpayne/09e9135d3f62471ebd7c83359b081e80
>>
>> when I run the go command (e.g. go build), I end up with a go.mod file
>> that contains
>>
>>   require github.com/twpayne/go-xdg v0.0.0-20190214203150-05c8dc503590
>>
>> whereas I would expect go.mod to contain
>>
>>   require github.com/twpayne/go-xdg v2.0.0
>>
>> Even I run the explicit command:
>>
>>   $ go get github.com/twpayne/go-xdg@v2.0.0
>>
>> go.mod still ends up containing the v0.0.0/timestamp/commit hash instead
>> of v2.0.0.
>>
>>
>> Why does go.mod contain v0.0.0/timestamp/commitHash instead of "v2.0.0"?
>>
>>
>> Possibly relevant information:
>> - I initially made a mistake tagging "v2.0.0", so the tag has moved since
>> the go command first saw it. However, I also tried creating a new "v3.0.0"
>> tag, but also saw the v0.0.0/timestamp/commit hash instead of the expected
>> "v3.0.0".
>> - I have GO111MODULE=on.
>>
>> Thanks for any insight :)
>>
>> Tom
>>
>> --
>> 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] how golang creates binary

[durgasomeswararao532]

Hi,
Any one explain the background process of go build or how go build creates 
shared objects and include into go binary. 
Here sharing my experience with c shared files.
Earlier I worked with there we creating some shared objects of my projects 
and collected manually and using.

Here is the scenario I observed with go binary.
I ran this command in Linux ldd   and got dependency shared 
objects (.so) of Linux.

If possible please explain how go binary communicate/use  linux shared 
objects(.so)

-- 
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] source for scheduler and gc?

[Robert Engels]

Sorry, that made no sense, since the original message was not sent to the group. Here is the link:see https://github.com/golang/go/issues/11100-Original Message-
From: Robert Engels 
Sent: Apr 3, 2019 12:36 PM
To: "Jason E. Aten" 
Cc: golang-nuts 
Subject: Re: [go-nuts] source for scheduler and gc?

The issue I linked to goes pretty in-depth on the reasons. On Apr 3, 2019, at 12:30 PM, Jason E. Aten  wrote:Thanks Ian.On Wednesday, April 3, 2019 at 6:57:32 PM UTC+2, Ian Lance Taylor wrote:On Wed, Apr 3, 2019 at 8:34 AM Jason E. Aten  wrote:
>
> Where does the source for the runtime scheduler and garbage collector live these days?

The central locations are runtime/proc.go and runtime/mgc.go.


> Wherefore, I need to locate all runtime background threads and add in a means to shut them down upon request.

That's not currently supported, but it may be possible to modify the
scheduler to do it.  There is no simple way.

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.




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

Re: [go-nuts] How to link different static libararies on different platforms?

[T L]

On Wednesday, April 3, 2019 at 1:00:24 PM UTC-4, Ian Lance Taylor wrote:
>
> On Wed, Apr 3, 2019 at 8:30 AM T L > 
> wrote: 
> > 
> > Assume I have a .go soruce file like: 
> > 
> > /* 
> > #cgo LDFLAGS: -L${SRCDIR}/lib/static/linux/amd64 -lmylib 
> > ... // more flags 
> > */ 
> > import "C" 
> > 
> > ... // many cross-platform Go code lines 
> > 
> > 
> > Now, It compiles ok on Linux AMD64 platform. 
> > 
> > There are several library files under different subfolders of 
> "${SRCDIR}/lib/static". 
> > For example, the Linux-amd64 version is put in the "/linux/amd64" 
> subfolers. 
> > How to let the cgo directives to adaptively select the corresponding 
> static library file on different platforms? 
>
> Use a build tag in your #cgo directive: 
>
> #cgo linux LDFLAGS: 
>
> See the examples at https://golang.org/cmd/cgo. 
>
> Ian 
>

Thanks for the info, 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.

Re: [go-nuts] source for scheduler and gc?

[Robert Engels]

The issue I linked to goes pretty in-depth on the reasons. 

> On Apr 3, 2019, at 12:30 PM, Jason E. Aten  wrote:
> 
> Thanks Ian.
> 
>> On Wednesday, April 3, 2019 at 6:57:32 PM UTC+2, Ian Lance Taylor wrote:
>> On Wed, Apr 3, 2019 at 8:34 AM Jason E. Aten  wrote: 
>> > 
>> > Where does the source for the runtime scheduler and garbage collector live 
>> > these days? 
>> 
>> The central locations are runtime/proc.go and runtime/mgc.go. 
>> 
>> 
>> > Wherefore, I need to locate all runtime background threads and add in a 
>> > means to shut them down upon request. 
>> 
>> That's not currently supported, but it may be possible to modify the 
>> scheduler to do it.  There is no simple way. 
>> 
>> 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.

-- 
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] source for scheduler and gc?

[Jason E. Aten]

Thanks Ian.

On Wednesday, April 3, 2019 at 6:57:32 PM UTC+2, Ian Lance Taylor wrote:
>
> On Wed, Apr 3, 2019 at 8:34 AM Jason E. Aten  > wrote: 
> > 
> > Where does the source for the runtime scheduler and garbage collector 
> live these days? 
>
> The central locations are runtime/proc.go and runtime/mgc.go. 
>
>
> > Wherefore, I need to locate all runtime background threads and add in a 
> means to shut them down upon request. 
>
> That's not currently supported, but it may be possible to modify the 
> scheduler to do it.  There is no simple way. 
>
> 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] go in cloud server

[Tamás Gulácsi]

Beside sqlite3, https://godoc.org/modernc.org/ql is a pure go embedded rdbms.
Tere are several key-value stores though: syndtr/go-leveldb, coreos/bbolt.

-- 
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 in cloud server

[Manlio Perillo]

On Wednesday, April 3, 2019 at 6:44:36 PM UTC+2, Shyaka Rene wrote:
>
>
> Hello.
> I'm new to go, i'm looking for a programming language to replace java. I 
> have simple questions
>
>1. is it a good idea to deploy go in cloud server if go is compiled to 
>machine binaries, what can happen if the cloud provider changes the 
>physical server to different processor architecture.
>
>
You should change cloud provider...
 

>
>1. 
>2. does go have embedded relational database management system similar 
>to h2 in java. google gives me key/value pair embedded database
>
>
The Go standard library has an SQL database interface:
https://golang.org/pkg/database/sql/

The only relational database implemented in Go I know is CockroachDB.
But see https://awesome-go.com/#database for more informations.


Manlio 

-- 
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] go in cloud server

[Marko Ristin-Kaufmann]

Hi Shyaka,

>
>1. is it a good idea to deploy go in cloud server if go is compiled to
>machine binaries, what can happen if the cloud provider changes the
>physical server to different processor architecture.
>
> I don't think this could ever be a problem. You normally choose the
architecture of your instances as a user.

2. does go have embedded relational database management system similar to
h2 in java. google gives me key/value pair embedded database

>any help is appreciated. thank you
>

https://github.com/mattn/go-sqlite3 ?

-- 
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] How to link different static libararies on different platforms?

[Ian Lance Taylor]

On Wed, Apr 3, 2019 at 8:30 AM T L  wrote:
>
> Assume I have a .go soruce file like:
>
> /*
> #cgo LDFLAGS: -L${SRCDIR}/lib/static/linux/amd64 -lmylib
> ... // more flags
> */
> import "C"
>
> ... // many cross-platform Go code lines
>
>
> Now, It compiles ok on Linux AMD64 platform.
>
> There are several library files under different subfolders of 
> "${SRCDIR}/lib/static".
> For example, the Linux-amd64 version is put in the "/linux/amd64" subfolers.
> How to let the cgo directives to adaptively select the corresponding static 
> library file on different platforms?

Use a build tag in your #cgo directive:

#cgo linux LDFLAGS:

See the examples at https://golang.org/cmd/cgo.

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.

Re: [go-nuts] source for scheduler and gc?

[Ian Lance Taylor]

On Wed, Apr 3, 2019 at 8:34 AM Jason E. Aten  wrote:
>
> Where does the source for the runtime scheduler and garbage collector live 
> these days?

The central locations are runtime/proc.go and runtime/mgc.go.


> Wherefore, I need to locate all runtime background threads and add in a means 
> to shut them down upon request.

That's not currently supported, but it may be possible to modify the
scheduler to do it.  There is no simple way.

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] go in cloud server

[Shyaka Rene]

Hello.
I'm new to go, i'm looking for a programming language to replace java. I 
have simple questions

   1. is it a good idea to deploy go in cloud server if go is compiled to 
   machine binaries, what can happen if the cloud provider changes the 
   physical server to different processor architecture.
   2. does go have embedded relational database management system similar 
   to h2 in java. google gives me key/value pair embedded database
   
   any help is appreciated. thank you

-- 
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] Gio: portable immediate mode GUI programs in Go for iOS/tvOS, Android, macOS, Linux, Windows

[Daniel Theophanes]

I'm running Deepin, debian based. Looking into the forums, the devs aren't 
interested in Wayland at the moment. [1] Though they are switching over the 
WM over to QT and kwin, so maybe in the future that will be an option.

I was only trying to run weston to try out gio. Thanks for the feedback, 
good to know.

1. 
https://bbs.deepin.org/forum.php?mod=viewthread=133029=1#pid279019

On Wednesday, April 3, 2019 at 7:51:59 AM UTC-7, ma...@eliasnaur.com wrote:
>
>
>
> On Monday, April 1, 2019 at 7:18:49 AM UTC+2, Daniel Theophanes wrote:
>>
>> I don't typically run wayland anywhere, but I was interested in this 
>> project and installed wayland and weston from my package manager. However, 
>> it seems my package manager's version of weston (v4.0.0) is too old(?) 
>> because I get the Go error: "wayland: no xdg_wm_base available". Probably 
>> from [here](
>> https://git.sr.ht/~eliasnaur/gio/tree/master/ui/app/os_wayland.go#L1051).
>>
>> Do you have any tips?  Tried googling various terms, but nothing seemed 
>> relevant.
>>
>>
> I'm sorry I missed your question. The precursor "unstable" version of the 
> "xdg_wm_base" is "zxdg_shell_v6", which is supported by weston but not by 
> gio. However, weston is only a reference compositor and is not intended for 
> serious use. On my Fedora 29, the Gnome shell supports xdg_wm_base, but its 
> version of weston (5.0.0) does not.
>
> What distribution and version are you running? If your distribution 
> supports Wayland in general, you should be able to choose Wayland from the 
> login chooser.
>
>  - elias
>

-- 
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] source for scheduler and gc?

[Michel Levieux]

I don't know what you're trying to achieve but I think:

a. that it's not possible to have a program keep a consistent state while
enabling such behaviour
b. that there's a better way to do what you want to do

Maybe explaining (even vaguely) what your purpose is could help?

Le mer. 3 avr. 2019 à 17:34, Jason E. Aten  a écrit :

> Where does the source for the runtime scheduler and garbage collector live
> these days?
>
> Wherefore, I need to locate all runtime background threads and add in a
> means to shut them down upon request.
>
>
> --
> 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.

Re: [go-nuts] How to apply middleware

[Burak Serdar]

On Wed, Apr 3, 2019 at 8:35 AM  wrote:

> type Route struct {
> Namestring
> Method  string
> Pattern string
> HandlerFunc http.HandlerFunc
> }
>
> type Routes []Route
>
> func NewRouter() *mux.Router {
> router := mux.NewRouter().StrictSlash(true)
> for _, route := range routes {
> var handler http.Handler
> handler = route.HandlerFunc
> handler = Logger(handler, route.Name)
>
> router.
> Methods(route.Method).
> Path(route.Pattern).
> Name(route.Name).
> Handler(handler)
> }
>
> return router
> }
>
> func Index(w http.ResponseWriter, r *http.Request) {
> fmt.Fprintf(w, "Hello World!")
> }
>
> var routes = Routes{
> {
> "Index",
> "GET",
> "/",
> Index,
> },
>
> {
> "protecteduri",
> strings.ToUpper("Get"),
> "/protected",
> protecteduri,
> },
> }
>
> My question is how do i apply the "validateToken" function (middleware) to 
> the routes in the router.go?
> The function is to validate the access token in the request message before 
> calling the handler functions.
>
Have you looked at the gorilla/mux documentation about middlewares?
There are examples there: https://godoc.org/github.com/gorilla/mux

You need to change the validateToken func:

func getTokenMW(srv *server.Server) func(http.Handler) http.Handler {
   return func(next http.Handler) http.Handler {
  return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
  }
   }
}

Then:
router.Use(getTokenMW(server))

Or, you can define a struct, put the server pointer in it, and use a
member function of that struct as the middleware.

-- 
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] source for scheduler and gc?

[Jason E. Aten]

Where does the source for the runtime scheduler and garbage collector live 
these days?  

Wherefore, I need to locate all runtime background threads and add in a 
means to shut them down upon request.


-- 
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] How to link different static libararies on different platforms?

[T L]

Assume I have a .go soruce file like:

/*
#cgo LDFLAGS: -L${SRCDIR}/lib/static/linux/amd64 -lmylib
... // more flags
*/
import "C"

... // many cross-platform Go code lines


Now, It compiles ok on Linux AMD64 platform.

There are several library files under different subfolders of 
"${SRCDIR}/lib/static".
For example, the Linux-amd64 version is put in the "/linux/amd64" subfolers.
How to let the cgo directives to adaptively select the corresponding static 
library file on different platforms?

-- 
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] Gio: portable immediate mode GUI programs in Go for iOS/tvOS, Android, macOS, Linux, Windows

[mail]

On Monday, April 1, 2019 at 7:18:49 AM UTC+2, Daniel Theophanes wrote:
>
> I don't typically run wayland anywhere, but I was interested in this 
> project and installed wayland and weston from my package manager. However, 
> it seems my package manager's version of weston (v4.0.0) is too old(?) 
> because I get the Go error: "wayland: no xdg_wm_base available". Probably 
> from [here](
> https://git.sr.ht/~eliasnaur/gio/tree/master/ui/app/os_wayland.go#L1051).
>
> Do you have any tips?  Tried googling various terms, but nothing seemed 
> relevant.
>
>
I'm sorry I missed your question. The precursor "unstable" version of the 
"xdg_wm_base" is "zxdg_shell_v6", which is supported by weston but not by 
gio. However, weston is only a reference compositor and is not intended for 
serious use. On my Fedora 29, the Gnome shell supports xdg_wm_base, but its 
version of weston (5.0.0) does not.

What distribution and version are you running? If your distribution 
supports Wayland in general, you should be able to choose Wayland from the 
login chooser.

 - elias

-- 
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] How to apply middleware

[afriyie . abraham]

Hi,

I have this main function in a main.go file inside the main directory
func main() {
log.Printf("Server started")

router := sw.NewRouter()
manager := manage.NewDefaultManager()
manager.SetAuthorizeCodeTokenCfg(manage.DefaultAuthorizeCodeTokenCfg)

manager.MustTokenStorage(store.NewMemoryTokenStore())

clientStore := store.NewClientStore()
manager.MapClientStorage(clientStore)

srv := server.NewDefaultServer(manager)
srv.SetAllowGetAccessRequest(true)
srv.SetClientInfoHandler(server.ClientFormHandler)
manager.SetRefreshTokenCfg(manage.DefaultRefreshTokenCfg)

srv.SetInternalErrorHandler(func(err error) (re *errors.Response) {
log.Println("Internal Error:", err.Error())
return
})

srv.SetResponseErrorHandler(func(re *errors.Response) {
log.Println("Response Error:", re.Error.Error())
})

router.HandleFunc("/oauth2/token", func(w http.ResponseWriter, r 
*http.Request) {
srv.HandleTokenRequest(w, r)
})

router.HandleFunc("/credentials", func(w http.ResponseWriter, r 
*http.Request) {
clientId := uuid.New().String()[:8]
clientSecret := uuid.New().String()[:8]
err := clientStore.Set(clientId, {
ID: clientId,
Secret: clientSecret,
Domain: "http://localhost:9094;,
})
if err != nil {
fmt.Println(err.Error())
}

w.Header().Set("Content-Type", "application/json")
json.NewEncoder(w).Encode(map[string]string{"CLIENT_ID": clientId, 
"CLIENT_SECRET": clientSecret})
})

log.Fatal(http.ListenAndServe(":8000", router))
}


The functions below are in different files in the sub directory of the main 
as

*maindir
*subdir


//Funtion in handler.go in subdir

func protecteduri(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("Hello, I'm protected"))
}

//This function in middleware.go in subdir

func validateToken(f http.HandlerFunc, srv *server.Server) http.HandlerFunc 
{
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
_, err := srv.ValidationBearerToken(r)
if err != nil {
http.Error(w, err.Error(), http.StatusBadRequest)
return
}

f.ServeHTTP(w, r)
})
}

And my routes are in the router.go in the subdir as

type Route struct {
Namestring
Method  string
Pattern string
HandlerFunc http.HandlerFunc
}

type Routes []Route

func NewRouter() *mux.Router {
router := mux.NewRouter().StrictSlash(true)
for _, route := range routes {
var handler http.Handler
handler = route.HandlerFunc
handler = Logger(handler, route.Name)

router.
Methods(route.Method).
Path(route.Pattern).
Name(route.Name).
Handler(handler)
}

return router
}

func Index(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello World!")
}

var routes = Routes{
{
"Index",
"GET",
"/",
Index,
},

{
"protecteduri",
strings.ToUpper("Get"),
"/protected",
protecteduri,
},
}

My question is how do i apply the "validateToken" function (middleware) to 
the routes in the router.go?
The function is to validate the access token in the request message before 
calling the handler functions.









-- 
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] A value copy will occur when executing for range xxx？

[Ian Lance Taylor]

On Wed, Apr 3, 2019 at 6:32 AM  wrote:
>
> thanks! v must be a value copy，Is this determined by the compiler?

It's determined by the language definition.

Ian


> 在 2019年4月3日星期三 UTC+8下午7:57:26，Marvin Renich写道：
>>
>> * mount...@gmail.com  [190403 05:10]:
>> > package main
>> >
>> > func main() {
>> > b := []int{1}
>> >
>> > bb := make([]*int, 0, 1)
>> > for k, v := range b {
>>
>> The above range clause will assign to k the index of the current
>> element, and it will assign to v a copy (as if v = b[k]) of the element
>> at that index.
>>
>> Go does not have references of the kind that C++ or Java has, so v
>> cannot be a reference, in that sense, to b[k]; it must be a value copy.
>>
>> If what you really want is to be able to refer to the location of the
>> element in the slice (really its backing array), omit the v in the range
>> clause and just use [k]:
>>
>> for k := range b {
>>   _ = [k] // do what you want
>> }
>>
>> > _ =   //8 line
>> > _ = [k] //9 line
>> > // bb = append(bb, )
>> > bb = append(bb, [k])
>> > }
>> >
>> > // for _, v := range bb {
>> > // fmt.Println(*v)
>> > // }
>> > }
>>
>> ...Marvin
>>
> --
> 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.

Re: [go-nuts] Build problems with modules in Docker

[David Riley]

A few things. Responses inline.

> On Apr 3, 2019, at 7:05 AM, Marcus Franke  wrote:
> 
> Hello,
> 
> I have a small project here at work, that does not compile using modules 
> inside the golang docker image.
> 
> The software resides inside a rather monorepo like repository inside the 
> organizations private repository at github. So far, a great place for the 
> modules, as I can develop the software outside my GOPATH and building it on 
> my machine works great.
> 
> My code resides inside this private repository inside an arbitrary path, 
> which is not fully part of the name I initiated the module with. Which does 
> not impose a problem when building on my laptop.
> 
> My go.mod file looks like this:
> ```
> module github.com/org/repo/asm
> 
> go 1.12
> 
> require (
> github.com/aws/aws-sdk-go v1.19.5
> github.com/kr/pretty v0.1.0
> github.com/stretchr/testify v1.3.0 // indirect
> golang.org/x/net v0.0.0-20190327091125-710a502c58a2 // indirect
> gopkg.in/yaml.v2 v2.2.2
> )
> ```

This generally looks OK.

> 
> I have a Makefile does some simple tasks for building, it creates a tarball 
> of my code directory and starts a docker build -t  job.

Why make a tarball? You'll get a lot more mileage out of just copying the files 
from the Docker context, which Docker is already tarring up to pass around 
anyway.  You'll get fewer surprises that way.

In our Dockerfiles, we generally have the following as preamble (we also add 
some non-root permissioning, which is more complex than you really need right 
now):

# Provide arguments for the module name (required) and the
# optional module proxy for hermetic builds
ARG MOD_NAME=modname
ARG GOPROXY
ENV GOPROXY ${GOPROXY}

# Set a variable for our working directory (make sure it matches
# the module name)
ENV D $HOME/build/$MOD_NAME
RUN mkdir -p $D
WORKDIR $D

# Copy go.sum/go.mod and warm up the module cache (so that this
# rather long step can be cached if go.mod/go.sum don't change)
COPY go.* $D/
CMD go mod download

# Now copy the rest.
COPY . $D

# Run the build script, which in the end generally calls
# "go install ./cmd/$app1 ./cmd/$app2 ...etc"
RUN ./scripts/build.sh install-all -v

> 
> My simplified Dockerfile:
> ```
> FROM golang:1.12
> ENV GO111MODULE=on
> CMD mkdir asm
> WORKDIR /go/asm
> ADD code.tar .
> CMD tar xvf code.tar

Careful with ADD, it automatically untars things when they're compressed 
(though yes, this is not currently compressed).  Again, though, there's usually 
not much reason to do that; you should probably just do a COPY of the files 
from your context instead.

> RUN cd cmd/asm

This doesn't doo what you think it does; it does not change the working 
directory.  For that, you want the WORKDIR directive. However...

> RUN go build -o asm

Instead of trying to change directories, you might want to just say go build 
./cmd/asm. You'll do yourself a lot of favors if you do your builds from the 
base of your repo

> ```
> 
> When I execute the build, I get the following error output:
> ```
> Step 10/10 : RUN go build -o asm
>  ---> Running in 243e73e7ed25
> go: finding github.com/stretchr/testify v1.3.0
> go: finding github.com/kr/pretty v0.1.0
> go: finding github.com/aws/aws-sdk-go v1.19.5
> go: finding gopkg.in/yaml.v2 v2.2.2
> go: finding golang.org/x/net v0.0.0-20190327091125-710a502c58a2
> go: finding github.com/kr/text v0.1.0
> go: finding github.com/davecgh/go-spew v1.1.0
> go: finding github.com/pmezard/go-difflib v1.0.0
> go: finding github.com/stretchr/objx v0.1.0
> go: finding gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405
> go: finding golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2
> go: finding golang.org/x/text v0.3.0
> go: finding github.com/kr/pty v1.1.1
> go: finding golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a
> go: finding github.com/jmespath/go-jmespath v0.0.0-20180206201540-c2b33e8439af
> can't load package: package github.com/org/repo/asm: unknown import path 
> "github.com/org/repo/asm": cannot find module providing package 
> github.com/org/repo/asm
> The command '/bin/sh -c go build -o asm' returned a non-zero code: 1
> ```
> 
> Why does the go tool try to kind of resolve the import path of my project 
> itself? I thought this would be defined by the module directive in my go.mod 
> file, at the source root of my project directory?

It is, the Go tool generally uses that to specify where the package "lives" if 
it's working properly. This looks to me almost like it's not seeing go.mod 
correctly.

> 
> My repository contains two internal packages below a pkg/ directory and these 
> are being imported just fine with "github.com/org/repo/asm/pkg/foo" and 
> "github.com/org/repo/asm/pkg/bar" in my code. On my laptop the compiler can, 
> as written above, compile the project just fine. Here it seems it does not 
> fumble with finding that particular and rather virtual module name.
> 
> Am I doing something wrong or did I just misunderstand the 

Re: [go-nuts] A value copy will occur when executing for range xxx？

[mountainfpf]

 thanks! v must be a value copy，Is this determined by the compiler? 

在 2019年4月3日星期三 UTC+8下午7:57:26，Marvin Renich写道：
>
> * mount...@gmail.com  > 
> [190403 05:10]: 
> > package main 
> > 
> > func main() { 
> > b := []int{1} 
> > 
> > bb := make([]*int, 0, 1) 
> > for k, v := range b { 
>
> The above range clause will assign to k the index of the current 
> element, and it will assign to v a copy (as if v = b[k]) of the element 
> at that index. 
>
> Go does not have references of the kind that C++ or Java has, so v 
> cannot be a reference, in that sense, to b[k]; it must be a value copy. 
>
> If what you really want is to be able to refer to the location of the 
> element in the slice (really its backing array), omit the v in the range 
> clause and just use [k]: 
>
> for k := range b { 
>   _ = [k] // do what you want 
> } 
>
> > _ =   //8 line 
> > _ = [k] //9 line 
> > // bb = append(bb, ) 
> > bb = append(bb, [k]) 
> > } 
> > 
> > // for _, v := range bb { 
> > // fmt.Println(*v) 
> > // } 
> > } 
>
> ...Marvin 
>
>

-- 
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: SPIFFE certificate verification (SVID) failure

[Dheeraj Gedam]

Hi Bradley,

Thanks for the response.
I could get things going with go-spiffe library [
https://github.com/spiffe/go-spiffe].
This library is essentially providing a custom verification method
(tls.Config.VerifyPeerCertificate) which takes care of matching SVID.
This one suited my need.

Regards,
Dheeraj




On Tue, Apr 2, 2019 at 11:18 PM  wrote:

> Have you reached out to the SPIFFE and SPIRE folks?
>
> https://github.com/spiffe/spiffe
> https://github.com/spiffe/spire
>
> SPIRE, a reference implementation, is written in go.  They may be familiar
> with the issue.
>
> On Monday, April 1, 2019 at 11:51:20 AM UTC-5, Dheeraj Gedam wrote:
>>
>> Hi,
>>
>> I am writing a gRPC client for a third party gRPC Server. Certificates
>> issued to both Server and Client are SPIFFE based. These certificates don't
>> have Common Name, and has SPIFFE id in URI SAN field.
>> However, there is an issue while validating the server certificate which
>> leads to Handshake failure.
>>
>> *go version go1.12.1 linux/amd64*
>>
>>
>> CA had issued certificates for both client and server. My client code
>> performs below steps:
>>
>> 1. Populate tls.Config structure
>>tlsConf.Certificates = []tls.Certificate{clientcertificate}
>>tlsConf.RootCAs = caCertificatePool
>>tlsConf.InsecureSkipVerify = false
>>
>> 2. creds = credentials.NewTLS()
>>
>> 3. conn, err := ({}).DialContext(ctx, "tcp", "servername")
>>conn, _, err = creds.ClientHandshake(ctx, "servername", conn)
>>
>> ClientHandshake returns the err "*x509: certificate is not valid for any
>> names, but wanted to match *"
>>
>> This error comes from *https://golang.org/src/crypto/x509/verify.go
>> * file func (h
>> HostnameError) Error() string].
>> After little debugging, it looks like below sequence of events are
>> happening.
>> i) hostname is populated from addr (i.e. servername in this case) in
>> DialWithDialer [https://golang.org/pkg/crypto/tls/#DialWithDialer]. This
>> same hostname is populated as config.ServerName.
>> ii) config.ServerName is later used to populate DNSName in VerifyOptions.
>> iii) Since DNSName is non-empty, VerifyHostname() is called which returns
>> error!
>>
>> In short, when it is SPIFFE ceritificate, the hostname match should be
>> avoided and only URI SAN should be matched.
>> There is an option of InsecureSkipVerify which altogether skips hostname
>> and certificate verification.
>> I would like to know if there is an option of just skipping hostname
>> match, and continue with rest of the certificate verification (required for
>> mTLS).
>>
>> Thanks,
>> Dheeraj
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/SX-MajM2ZUM/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Build problems with modules in Docker

[Tamás Gulácsi]

RUN cd cmd/asm
RUN go build -o asm

Is not what you wanted.

Try 

RUN cd cmd/asm && go build -o asm

(or "RUN go build -o cmd/asm/asm ./cmd/asm")




2019. április 3., szerda 13:05:44 UTC+2 időpontban Marcus Franke a 
következőt írta:
>
> Hello,
>
> I have a small project here at work, that does not compile using modules 
> inside the golang docker image.
>
> The software resides inside a rather monorepo like repository inside the 
> organizations private repository at github. So far, a great place for the 
> modules, as I can develop the software outside my GOPATH and building it on 
> my machine works great.
>
> My code resides inside this private repository inside an arbitrary path, 
> which is not fully part of the name I initiated the module with. Which does 
> not impose a problem when building on my laptop.
>
> My go.mod file looks like this:
> ```
> module github.com/org/repo/asm
>
> go 1.12
>
> require (
> github.com/aws/aws-sdk-go v1.19.5
> github.com/kr/pretty v0.1.0
> github.com/stretchr/testify v1.3.0 // indirect
> golang.org/x/net v0.0.0-20190327091125-710a502c58a2 // indirect
> gopkg.in/yaml.v2 v2.2.2
> )
> ```
>
> I have a Makefile does some simple tasks for building, it creates a 
> tarball of my code directory and starts a docker build -t  job.
>
> My simplified Dockerfile:
> ```
> FROM golang:1.12
> ENV GO111MODULE=on
> CMD mkdir asm
> WORKDIR /go/asm
> ADD code.tar .
> CMD tar xvf code.tar
> RUN cd cmd/asm
> RUN go build -o asm
> ```
>
> When I execute the build, I get the following error output:
> ```
> Step 10/10 : RUN go build -o asm
>  ---> Running in 243e73e7ed25
> go: finding github.com/stretchr/testify v1.3.0
> go: finding github.com/kr/pretty v0.1.0
> go: finding github.com/aws/aws-sdk-go v1.19.5
> go: finding gopkg.in/yaml.v2 v2.2.2
> go: finding golang.org/x/net v0.0.0-20190327091125-710a502c58a2
> go: finding github.com/kr/text v0.1.0
> go: finding github.com/davecgh/go-spew v1.1.0
> go: finding github.com/pmezard/go-difflib v1.0.0
> go: finding github.com/stretchr/objx v0.1.0
> go: finding gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405
> go: finding golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2
> go: finding golang.org/x/text v0.3.0
> go: finding github.com/kr/pty v1.1.1
> go: finding golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a
> go: finding github.com/jmespath/go-jmespath 
> v0.0.0-20180206201540-c2b33e8439af
> can't load package: package github.com/org/repo/asm: unknown import path "
> github.com/org/repo/asm": cannot find module providing package 
> github.com/org/repo/asm
> The command '/bin/sh -c go build -o asm' returned a non-zero code: 1
> ```
>
> Why does the go tool try to kind of resolve the import path of my project 
> itself? I thought this would be defined by the module directive in my 
> go.mod file, at the source root of my project directory?
>
> My repository contains two internal packages below a pkg/ directory and 
> these are being imported just fine with "github.com/org/repo/asm/pkg/foo" 
> and "github.com/org/repo/asm/pkg/bar" in my code. On my laptop the 
> compiler can, as written above, compile the project just fine. Here it 
> seems it does not fumble with finding that particular and rather virtual 
> module name.
>
> Am I doing something wrong or did I just misunderstand the way modules 
> work?
>
>
> Kind and puzzled regards,
> Marcus
>
> -- 
> pedo mellon a minno
>

-- 
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] modules usage help

[T L]

On Tuesday, April 2, 2019 at 5:31:51 AM UTC-4, T L wrote:
>
> This is glide.lock file at 
> github.com/projectcalico/libcalico...@v3.7.0-0.dev+incompatible 
> 
> ,
>
>
> and this is the go.mod file after running go build:
>
> module a.b.c/ddd
>
> require (
> contrib.go.opencensus.io/exporter/ocagent v0.4.10 // indirect
> github.com/Azure/go-autorest v11.7.0+incompatible // indirect
> github.com/coreos/bbolt v1.3.2 // indirect
> github.com/coreos/etcd v3.3.12+incompatible // indirect
> github.com/coreos/go-semver v0.2.0 // indirect
> github.com/coreos/go-systemd v0.0.0-20190321100706-95778dfbb74e // 
> indirect
> github.com/coreos/pkg v0.0.0-20180928190104-399ea9e2e55f // indirect
> github.com/dgrijalva/jwt-go v3.2.0+incompatible // indirect
> github.com/go-playground/locales v0.12.1 // indirect
> github.com/go-playground/universal-translator v0.16.0 // indirect
> github.com/gogo/protobuf v1.2.1 // indirect
> github.com/golang/groupcache v0.0.0-20190129154638-5b532d6fd5ef // 
> indirect
> github.com/golang/mock v1.2.0 // indirect
> github.com/google/btree v1.0.0 // indirect
> github.com/google/gofuzz v0.0.0-20170612174753-24818f796faf // 
> indirect
> github.com/google/uuid v1.1.1 // indirect
> github.com/googleapis/gnostic v0.2.0 // indirect
> github.com/gophercloud/gophercloud v0.0.0-20190330013820-4d3066f119fa 
> // indirect
> github.com/gorilla/websocket v1.4.0 // indirect
> github.com/gregjones/httpcache v0.0.0-20190212212710-3befbb6ad0cc // 
> indirect
> github.com/grpc-ecosystem/go-grpc-middleware v1.0.0 // indirect
> github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0 // indirect
> github.com/grpc-ecosystem/grpc-gateway v1.8.5 // indirect
> github.com/hashicorp/golang-lru v0.5.1 // indirect
> github.com/imdario/mergo v0.3.7 // indirect
> github.com/jonboulle/clockwork v0.1.0 // indirect
> github.com/json-iterator/go v1.1.6 // indirect
> github.com/kelseyhightower/envconfig v1.3.0 // indirect
> github.com/leodido/go-urn v1.1.0 // indirect
> github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // 
> indirect
> github.com/modern-go/reflect2 v1.0.1 // indirect
> github.com/peterbourgon/diskv v2.0.1+incompatible // indirect
> github.com/projectcalico/go-json v0.0.0-20161128004156-6219dc7339ba 
> // indirect
> github.com/projectcalico/go-yaml v0.0.0-20161201183616-955bc3e451ef 
> // indirect
> github.com/projectcalico/go-yaml-wrapper 
> v0.0.0-20161127220527-598e54215bee // indirect
> github.com/projectcalico/libcalico-go v3.7.0-0.dev+incompatible
> github.com/satori/go.uuid v1.2.0 // indirect
> github.com/sirupsen/logrus v1.4.0 // indirect
> github.com/soheilhy/cmux v0.1.4 // indirect
> github.com/spf13/pflag v1.0.3 // indirect
> github.com/tmc/grpc-websocket-proxy 
> v0.0.0-20190109142713-0ad062ec5ee5 // indirect
> github.com/ugorji/go/codec v0.0.0-20190320090025-2dc34c0b8780 // 
> indirect
> github.com/xiang90/probing v0.0.0-20190116061207-43a291ad63a2 // 
> indirect
> go.etcd.io/bbolt v1.3.2 // indirect
> go.opencensus.io v0.20.0 // indirect
> go.uber.org/atomic v1.3.2 // indirect
> go.uber.org/multierr v1.1.0 // indirect
> go.uber.org/zap v1.9.1 // indirect
> golang.org/x/net v0.0.0-20190328230028-74de082e2cca // indirect
> golang.org/x/oauth2 v0.0.0-20190319182350-c85d3e98c914 // indirect
> golang.org/x/time v0.0.0-20190308202827-9d24e82272b4 // indirect
> gopkg.in/go-playground/assert.v1 v1.2.1 // indirect
> gopkg.in/go-playground/validator.v9 v9.28.0 // indirect
> gopkg.in/inf.v0 v0.9.1 // indirect
> k8s.io/api v0.0.0-20190327184913-92d2ee7fc726 // indirect
> k8s.io/apimachinery v0.0.0-20190402064448-91ffda0f6be2 // indirect
> k8s.io/client-go v10.0.0+incompatible // indirect
> k8s.io/klog v0.2.0 // indirect
> sigs.k8s.io/yaml v1.1.0 // indirect
> )
>
> go 1.12
>
> Who can help me on how to specify the version numbers in go.mod file to 
> let the program compile ok?
>
> On Tuesday, April 2, 2019 at 12:36:27 AM UTC-4, T L wrote:
>>
>>
>>
>> On Tuesday, April 2, 2019 at 12:33:41 AM UTC-4, T L wrote:
>>>
>>>
>>>
>>> On Monday, April 1, 2019 at 9:01:28 AM UTC-4, Jakob Borg wrote:

 On 1 Apr 2019, at 11:22, T L  wrote:


 How to use this package in vgo mode?


 go mod init a.b.c/ddd
 go get github.com/projectcalico/libcalico-go@master

 The problem is that their latest non-prerelease tag is v1.7.3, which is 
 several years old and doesn’t contain the package you want to import.

 //jb

>>>
>>>
>>> There are still some problems:
>>>
>>> $ cat main.go
>>> package main
>>>
>>> import _ "github.com/projectcalico/libcalico-go/lib/apiconfig"
>>> import _ "github.com/projectcalico/libcalico-go/lib/clientv3"
>>>
>>> func main() 

Re: [go-nuts] A value copy will occur when executing for range xxx？

[Marvin Renich]

* mountain...@gmail.com  [190403 05:10]:
> package main
> 
> func main() {
> b := []int{1}
> 
> bb := make([]*int, 0, 1)
> for k, v := range b {

The above range clause will assign to k the index of the current
element, and it will assign to v a copy (as if v = b[k]) of the element
at that index.

Go does not have references of the kind that C++ or Java has, so v
cannot be a reference, in that sense, to b[k]; it must be a value copy.

If what you really want is to be able to refer to the location of the
element in the slice (really its backing array), omit the v in the range
clause and just use [k]:

for k := range b {
  _ = [k] // do what you want
}

> _ =   //8 line
> _ = [k] //9 line
> // bb = append(bb, )
> bb = append(bb, [k])
> }
> 
> // for _, v := range bb {
> // fmt.Println(*v)
> // }
> }

...Marvin

-- 
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] Build problems with modules in Docker

[Marcus Franke]

Hello,

I have a small project here at work, that does not compile using modules
inside the golang docker image.

The software resides inside a rather monorepo like repository inside the
organizations private repository at github. So far, a great place for the
modules, as I can develop the software outside my GOPATH and building it on
my machine works great.

My code resides inside this private repository inside an arbitrary path,
which is not fully part of the name I initiated the module with. Which does
not impose a problem when building on my laptop.

My go.mod file looks like this:
```
module github.com/org/repo/asm

go 1.12

require (
github.com/aws/aws-sdk-go v1.19.5
github.com/kr/pretty v0.1.0
github.com/stretchr/testify v1.3.0 // indirect
golang.org/x/net v0.0.0-20190327091125-710a502c58a2 // indirect
gopkg.in/yaml.v2 v2.2.2
)
```

I have a Makefile does some simple tasks for building, it creates a tarball
of my code directory and starts a docker build -t  job.

My simplified Dockerfile:
```
FROM golang:1.12
ENV GO111MODULE=on
CMD mkdir asm
WORKDIR /go/asm
ADD code.tar .
CMD tar xvf code.tar
RUN cd cmd/asm
RUN go build -o asm
```

When I execute the build, I get the following error output:
```
Step 10/10 : RUN go build -o asm
 ---> Running in 243e73e7ed25
go: finding github.com/stretchr/testify v1.3.0
go: finding github.com/kr/pretty v0.1.0
go: finding github.com/aws/aws-sdk-go v1.19.5
go: finding gopkg.in/yaml.v2 v2.2.2
go: finding golang.org/x/net v0.0.0-20190327091125-710a502c58a2
go: finding github.com/kr/text v0.1.0
go: finding github.com/davecgh/go-spew v1.1.0
go: finding github.com/pmezard/go-difflib v1.0.0
go: finding github.com/stretchr/objx v0.1.0
go: finding gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405
go: finding golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2
go: finding golang.org/x/text v0.3.0
go: finding github.com/kr/pty v1.1.1
go: finding golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a
go: finding github.com/jmespath/go-jmespath
v0.0.0-20180206201540-c2b33e8439af
can't load package: package github.com/org/repo/asm: unknown import path "
github.com/org/repo/asm": cannot find module providing package
github.com/org/repo/asm
The command '/bin/sh -c go build -o asm' returned a non-zero code: 1
```

Why does the go tool try to kind of resolve the import path of my project
itself? I thought this would be defined by the module directive in my
go.mod file, at the source root of my project directory?

My repository contains two internal packages below a pkg/ directory and
these are being imported just fine with "github.com/org/repo/asm/pkg/foo"
and "github.com/org/repo/asm/pkg/bar" in my code. On my laptop the compiler
can, as written above, compile the project just fine. Here it seems it does
not fumble with finding that particular and rather virtual module name.

Am I doing something wrong or did I just misunderstand the way modules work?


Kind and puzzled regards,
Marcus

-- 
pedo mellon a minno

-- 
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 rewrite code and apply middleware gorilla mux routes

[afriyie . abraham]

On Wednesday, April 3, 2019 at 11:28:55 AM UTC+3, afriyie...@gmail.com 
wrote:
>
> Hi
>
> I have this working main function code and would like to rewrite it such 
> that the middleware "validateToken" would be applied
> to all my gorilla mux routes.
> Please attached is the file containg the working code.
>
> What i would like to do is to use the handler function   
>
> http.HandleFunc("/protected", validateToken(func(w http.ResponseWriter, r 
> *http.Request) {
> w.Write([]byte("Hello, I'm protected" 
> outside the main function as
> func protecteduri(w http.ResponseWriter, r *http.Request) {
> w.Write([]byte("Hello, I'm protected"))
> }
>
> and apply the middleware function "validateToken" to all my gorilla mux 
> routes so that the token used to request can be validated. The routes 
> type Route struct {
> Namestring
> Method  string
> Pattern string
> HandlerFunc http.HandlerFunc
> }
>
> type Routes []Route
>
> func NewRouter() *mux.Router {
> router := mux.NewRouter().StrictSlash(true)
> for _, route := range routes {
> var handler http.Handler
> handler = route.HandlerFunc
> handler = Logger(handler, route.Name)
>
> router.
> Methods(route.Method).
> Path(route.Pattern).
> Name(route.Name).
> Handler(handler)
> }
>
> return router
> }
>
> func Index(w http.ResponseWriter, r *http.Request) {
> fmt.Fprintf(w, "Hello World!")
> }
>
> var routes = Routes{
> {
> "Index",
> "GET",
> "/",
> Index,
> },
>
> {
> "protecteduri",
> strings.ToUpper("Get"),
> "/protected",
> protecteduri,
> },
>
> {
> "AccessTokenRequest",
> strings.ToUpper("Post"),
> "/oauth2/token",
> AccessTokenRequest,
> },
> }
>
>  Can anyone help?
>
>
>

-- 
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 rewrite code and apply middleware gorilla mux routes

[afriyie . abraham]

On Wednesday, April 3, 2019 at 11:28:55 AM UTC+3, afriyie...@gmail.com 
wrote:
>
> Hi
>
> I have this working main function code and would like to rewrite it such 
> that the middleware "validateToken" would be applied
> to all my gorilla mux routes.
> Please attached is the file containg the working code.
>
> What i would like to do is to use the handler function   
>
> http.HandleFunc("/protected", validateToken(func(w http.ResponseWriter, r 
> *http.Request) {
> w.Write([]byte("Hello, I'm protected" 
> outside the main function as
> func protecteduri(w http.ResponseWriter, r *http.Request) {
> w.Write([]byte("Hello, I'm protected"))
> }
>
> and apply the middleware function "validateToken" to all my gorilla mux 
> routes so that the token used to request can be validated. The routes 
> type Route struct {
> Namestring
> Method  string
> Pattern string
> HandlerFunc http.HandlerFunc
> }
>
> type Routes []Route
>
> func NewRouter() *mux.Router {
> router := mux.NewRouter().StrictSlash(true)
> for _, route := range routes {
> var handler http.Handler
> handler = route.HandlerFunc
> handler = Logger(handler, route.Name)
>
> router.
> Methods(route.Method).
> Path(route.Pattern).
> Name(route.Name).
> Handler(handler)
> }
>
> return router
> }
>
> func Index(w http.ResponseWriter, r *http.Request) {
> fmt.Fprintf(w, "Hello World!")
> }
>
> var routes = Routes{
> {
> "Index",
> "GET",
> "/",
> Index,
> },
>
> {
> "protecteduri",
> strings.ToUpper("Get"),
> "/protected",
> protecteduri,
> },
>
> {
> "AccessTokenRequest",
> strings.ToUpper("Post"),
> "/oauth2/token",
> AccessTokenRequest,
> },
> }
>
>  Can anyone help?
>
Sorry please attacted is the file 

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


main.go
Description: Binary data

[go-nuts] A value copy will occur when executing for range xxx？

[mountainfpf]

package main

func main() {
b := []int{1}

bb := make([]*int, 0, 1)
for k, v := range b {
_ =   //8 line
_ = [k] //9 line
// bb = append(bb, )
bb = append(bb, [k])
}

// for _, v := range bb {
// fmt.Println(*v)
// }
}

1、When i use `go too compile -N -l -S main.go |grep "main.go:8" ` print asm 
on line 8, it print nothing.
2、When i use `go too compile -N -l -S main.go |grep "main.go:9" ` print asm 
on line 8, it print some asm code:

0x0136 00310 
(/data/app/go/src/gosrc/demo/base_learn/slice/range/main.go:9) MOVQ
"".b+168(SP), CX
0x013e 00318 
(/data/app/go/src/gosrc/demo/base_learn/slice/range/main.go:9) CMPQ
"".k+72(SP), CX
0x0143 00323 
(/data/app/go/src/gosrc/demo/base_learn/slice/range/main.go:9) JCS
 330
0x0145 00325 
(/data/app/go/src/gosrc/demo/base_learn/slice/range/main.go:9) JMP
 583
0x0247 00583 
(/data/app/go/src/gosrc/demo/base_learn/slice/range/main.go:9) CALL
runtime.panicindex(SB)
0x024c 00588 
(/data/app/go/src/gosrc/demo/base_learn/slice/range/main.go:9) UNDEF
0x024e 00590 
(/data/app/go/src/gosrc/demo/base_learn/slice/range/main.go:9) NOP

so it because a copy of the array/slice variable ?

-- 
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] How to rewrite code and apply middleware gorilla mux routes

[afriyie . abraham]

Hi

I have this working main function code and would like to rewrite it such 
that the middleware "validateToken" would be applied
to all my gorilla mux routes.
Please attached is the file containg the working code.

What i would like to do is to use the handler function   

http.HandleFunc("/protected", validateToken(func(w http.ResponseWriter, r 
*http.Request) {
w.Write([]byte("Hello, I'm protected" 
outside the main function as
func protecteduri(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("Hello, I'm protected"))
}

and apply the middleware function "validateToken" to all my gorilla mux 
routes so that the token used to request can be validated. The routes 
type Route struct {
Namestring
Method  string
Pattern string
HandlerFunc http.HandlerFunc
}

type Routes []Route

func NewRouter() *mux.Router {
router := mux.NewRouter().StrictSlash(true)
for _, route := range routes {
var handler http.Handler
handler = route.HandlerFunc
handler = Logger(handler, route.Name)

router.
Methods(route.Method).
Path(route.Pattern).
Name(route.Name).
Handler(handler)
}

return router
}

func Index(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello World!")
}

var routes = Routes{
{
"Index",
"GET",
"/",
Index,
},

{
"protecteduri",
strings.ToUpper("Get"),
"/protected",
protecteduri,
},

{
"AccessTokenRequest",
strings.ToUpper("Post"),
"/oauth2/token",
AccessTokenRequest,
},
}

 Can anyone help?


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