[go-nuts] Workspace and dependencies
Hello everyone ! I'm new to golang and I have some questions about the workspace and the dependencies management. I've read that GOPATH is the location of my workspace, where all of my go code belongs (personal project and dependencies of all of these projects). If I want to push one of my project on github, will I push only my project source code or will I also push the dependencies ? If I must push only my code, how another developer who wants to clone my repo can find the list of my dependencies and use the rights versions ? Can I have two projects using two different version of the same project ? (It seems to be impossible if all of my project and dependencies are in the same folder). Thanks for you answers ! -- 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: Unsafe string/slice conversions
Interesting, I actually ran into some odd behavior with this function that
I'm not sure how to explain. Consider the following test:
import (
"reflect"
"testing"
"unsafe"
)
func sliceToStringUnsafe(v []byte) string {
var s string
sh := (*reflect.StringHeader)(unsafe.Pointer())
sh.Data = uintptr(unsafe.Pointer([0]))
sh.Len = len(v)
return s
}
func foo() string {
v := []byte{"foobarbaz"}
s := sliceToStringUnsafe(v)
return s
}
func TestFoo(t *testing.T) string {
foo := foo()
require.Equal(t, "foobarbaz", foo)
}
If I run this test with `go test` it passes. However, if I run the test
with `go test -covermode atomic` it fails and foo contains random data.
Perhaps the `covermode atomic` affects how the compiler performs escape
analysis?
On Saturday, March 25, 2017 at 12:43:38 PM UTC-4, Keith Randall wrote:
>
> That is a worry, but escape analysis can handle this case. It understands
> flow of pointers through unsafe.Pointer and uintptr. As a consequence, in
> this example it forces the array to be allocated on the heap.
>
> The runtime has on occasion a need to hide values from escape analysis.
> It has to do some weird math on the uintptr to hide the escape. It uses:
>
> // noescape hides a pointer from escape analysis. noescape is
> // the identity function but escape analysis doesn't think the
> // output depends on the input. noescape is inlined and currently
> // compiles down to zero instructions.
> // USE CAREFULLY!
> //go:nosplit
> func noescape(p unsafe.Pointer) unsafe.Pointer {
> x := uintptr(p)
> return unsafe.Pointer(x ^ 0)
> }
>
>
> On Friday, March 24, 2017 at 11:58:31 AM UTC-7, Jerome Froelich wrote:
>>
>> It just occurred to me that there may actually be a problem with the
>> conversion functions in the example. Specifically, since the Go
>> compiler can allocate byte slices on the heap if they do not escape, the
>> following function may be invalid:
>>
>> func foo() string {
>> v := []uint64{1,2,3}
>> s := sliceToStringUnsafe(v)
>> return s
>> }
>>
>> Admittedly, this is a contrived example but I think it can illustrate the
>> issue. As noted on this previous thread
>> the
>> compiler will allocate slices on the heap if it can prove they do not
>> escape. Consequently, in the function above, the data for v can be
>> allocated on the stack. In such a case, since sliceToStringUnsafe only
>> adjusts pointers, the string it returns will point to this stack-allocated
>> data. However, once foo returns, this data is no longer valid and can be
>> overwritten by subsequent functions that are pushed on the stack.
>>
>> On Thursday, March 23, 2017 at 9:05:48 PM UTC-4, Caleb Spare wrote:
>>>
>>> Filed: https://github.com/golang/go/issues/19687
>>>
>>> On Thu, Mar 23, 2017 at 4:41 PM, 'Keith Randall' via golang-nuts
>>> wrote:
>>> >
>>> >
>>> > On Thursday, March 23, 2017 at 4:24:40 PM UTC-7, Caleb Spare wrote:
>>> >>
>>> >> That's very good to know. Thanks, Ian.
>>> >>
>>> >> Unfortunately if I use this KeepAlive-based fix, p escapes and so the
>>> >> function now allocates. I guess I'll stick with the original version
>>> >> from my first email.
>>> >>
>>> >> Does this indicate a shortcoming of either compiler support for
>>> >> KeepAlive or escape analysis in general?
>>> >>
>>> >
>>> > KeepAlive shouldn't be making things escape. If that is happening you
>>> > should file a bug for it.
>>> > The definition is:
>>> >
>>> > //go:noinline
>>> > func KeepAlive(interface{}) {}
>>> >
>>> > which should be pretty easy to analyze :)
>>> >
>>> >> Caleb
>>> >>
>>> >> On Thu, Mar 23, 2017 at 10:26 AM, Ian Lance Taylor
>>>
>>> >> wrote:
>>> >> > On Thu, Mar 23, 2017 at 9:16 AM, Caleb Spare
>>> wrote:
>>> >> >>
>>> >> >> Brief follow-up: does the seeming validity of the code rely at all
>>> on
>>> >> >> the fact that the indicated line is written as a single line? What
>>> if,
>>> >> >> instead, a *StringHeader var were extracted?
>>> >> >>
>>> >> >> func stringToSliceUnsafe(s string) []uint64 {
>>> >> >> var v []uint64
>>> >> >> h := (*reflect.StringHeader)(unsafe.Pointer()) // <--
>>> >> >> sh := (*reflect.SliceHeader)(unsafe.Pointer())
>>> >> >> sh.Data = h.Data
>>> >> >> sh.Len = h.Len >> 3
>>> >> >> sh.Cap = h.Len >> 3
>>> >> >> return v
>>> >> >> }
>>> >> >>
>>> >> >> (Play link: https://play.golang.org/p/BmGtYTsGNY)
>>> >> >>
>>> >> >> Does h keep s alive? A strict reading of rule 6 doesn't seem to
>>> say
>>> >> >> that keeping a *StringHeader or *SliceHeader around keeps the
>>> >> >> underlying string/slice alive (but it's sort of implied by the
>>> rule 6
>>> >> >> example code, which doesn't refer to s after converting it to a
>>> >> >> *StringHeader).
>>> >> >
>>> >> >
[go-nuts] template Funcs with ParseFile and Execute
Try changing the call to New to name the template the same as the first parameter to ParseFiles t, _ := template.New(templates.BASE).Funcs(funcMap).ParseFiles(templates.BASE, templates.NOTIFICATIONS, templates.TICKER, templateName) There is something odd about how ParseFiles works if the name in New doesn't match. -- 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: Algorithm Club
On Sunday, 26 March 2017 05:15:10 UTC+3, Bakul Shah wrote:
>
> The simplest design I can think of (that does what you seem to
> want) is to add parameterized packages. Here's a
> stereotypical example:
>
>
> package stack(T)// parameterized on stack element type
> import "fmt"
> type Type struct { rep []T
> func New() *Type { {} }
> func (stk *Type)Push(t T) { stk.rep = append(stk.rep, t) }
> func (stk *Type)Pop()(T, error) {
> var t T
> ln := len(stk.rep)
> if ln = 0 { return t, fmt.Errorf("Empty stack") }
> t = stk.rep[ln-1]
> stk.rep = st.rep[:ln-2]
> return t, nil
> }
>
> package foo
>
> import intstack "stack"(int)// stack of ints
> import intstackstack "stack"(intstack.Type)// stack of stack of
> ints
>
> var istk intstack.Type
> var istkstk intstackstack.Type
> ...
> istk.Push(5)
> x, err := istk.Pop()
> istkstk.Push(istk)
> =
>
> Note that
> - This adds only two syntax rules.
> 1. In the package header, its name can be followed by a
> parenthesized list of names.
> 2. A package import must provide a complete list of types,
> which are concrete or its own parameter types. And such
> instantiated package must be given a local name.
> - *All* we are doing is saving some typing.
> - Given this, this feature can be expanded out via a preprocessor.
> - Given this, no new semantics need be defined!
> - Only one instance of a given type of package need be
> generated and compiled.
> - The intstackstack example is to show composability.
> - This actually makes interface types more useful than now.
>
> The last point is worth elaborating on. Currently the "io"
> package defines a bunch of interface types such as Reader,
> Writer and so on. These interface types allow you to use
> objects of a variety of other types so as as they implement
> relevant functions. But "io" interface types are primarily for
> byte slices. If "io" was defined as a parameterized package,
> one can have similar choices for other slice types. Currently
> to provide similar set of useful interface types for other
> slice types you would have to replicate a whole bunch of
> packages.
>
> Avoiding duplication of code should not be taken lightly.
> Copies can diverge, bug fixes or peroformance improvements may
> not be made consistently across all copies, newer copies may
> not have as much testing, and as different copies may have
> different bugs (and written by different people) each has to
> be independently and thoroughly reviewed etc.
>
> Go may not impress lanuage designers but it is a practical
> language. IMHO the above has a similar feel for "generics" --
> it is simple, very easy to teach, it is not turing complete or
> anything fancy but takes care of most of the common use cases.
>
> I had looked at previous formal proposals but none seemed
> as simple as this.
>
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#heading=h.wko1dvdznk4y
Bakul
>
> On Sat, 25 Mar 2017 20:57:51 EDT David Collier-Brown > wrote:
> > Hmmn, we may be thinking different things... I *think* I'm looking for a
> > way to say "an X of Y", and see composition as a possible approach.
> > I just don't know if it will be a, the, or not the answer (;-))
> >
> > --dave
> >
> >
> > On 24/03/17 11:21 PM, Michael Jones wrote:
> > > I think I was saying that what I seem to want personally is the
> "simple,
> > > weak, slight" thing that you likely see as failure.
> > >
> > > The opposite end of that--where everything is a list and can be
> composed
> > > without special regard (lisp) or everything is an object that can
> > > receive any message (smalltalk) are comfortable for me, but just not
> > > what I find myself wanting very often.
> > >
> > > My own view is not important in the sense that a broad survey would
> be,
> > > but since it seems much less than what people seem to dream of, I
> wanted
> > > to share that maybe people could be happy with less than they seek.
> > >
> > > Or maybe that ultimate typeless generality is what others really need
> > > somehow. I would not know.
> > >
> > > On Fri, Mar 24, 2017 at 6:13 PM David Collier-Brown
> > > > wrote:
> > >
> > > We still don't understand genrality: the current generics are
> > > unimpressive. The proposals for Go are typically "let's do
> something
> > > that has failed already, in hopes that trying it agin will have a
> > > different result". That, alas, is one of the definitions of
> insanity.
> > >
> > > Due caution is advised!
>
--
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
