Re: [go-nuts] go build -gcflags '-N -l' don't work

[刘桂祥]

go1.7.1

go run -gcflags '-N -l -m' example.go

在 2017年4月14日星期五 UTC+8下午1:18:26，Ian Lance Taylor写道：
>
> On Thu, Apr 13, 2017 at 8:33 PM, 刘桂祥  
> wrote: 
> > // example.go 
> > package main 
> > 
> > 
> > import "runtime" 
> > 
> > 
> > type S struct{} 
> > 
> > 
> > func main() { 
> >  var stats runtime.MemStats 
> > 
> > 
> >  runtime.ReadMemStats() 
> >  println(stats.Mallocs) 
> >  var x S 
> >  runtime.ReadMemStats() 
> >  println(stats.Mallocs) 
> >  _ = *ref(x) 
> >  runtime.ReadMemStats() 
> >  println(stats.Mallocs) 
> > } 
> > 
> > 
> > func ref(z S) *S { 
> >  return  
> > } 
> > 
> > go build -gcflags '-N -l' example.go && ./example 
> > or 
> > go run -gcflags '-N -l' example.go 
> > 
> > results: 
> > ./example.go:21:  escapes to heap 
> > ./example.go:20: moved to heap: z 
> > ./example.go:10: main  does not escape 
> > ./example.go:13: main  does not escape 
> > ./example.go:16: main  does not escape 
> > 61 
> > 61 
> > 61 
>
> That looks like the output from -gcflags="-m -l".  Are you really sure 
> you typed -N?  What version of Go are you using? 
>
> 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] NewTicker leak

[Fabián Inostroza]

Hi,

I'm writing and application where I need to check for some condition and do 
something every 'x' < 'y' seconds. If the condition is not true after 'y' 
seconds I do something. Every time the condition checked every 'x' seconds 
is true I have to reset the 'y' timeout.

I wrote a test application based on code found in 
https://medium.com/@arpith/resetting-a-ticker-in-go-63858a2c17ec
package main

import "time"

// Ticker asdf
type Ticker struct {
period time.Duration
ticker time.Ticker
}

func createTicker(period time.Duration) *Ticker {
return {period, *time.NewTicker(period)}
}

func (t *Ticker) resetTicker() {
t.ticker.Stop()
t.ticker = *time.NewTicker(t.period)
}

type timers struct {
ticker1 Ticker
ticker2 Ticker
donechan bool
}

func (t *timers) work() {
condition := true
count := 0
for {
select {
case <-t.ticker1.ticker.C:
if condition {
if count >= 5 {
count = 0
condition = false
} else {
t.ticker2.resetTicker()
count++
}
}
case <-t.ticker2.ticker.C:
if count >= 2 {
count = 0
condition = true
}
count++
case <-t.done:
return
}
}
}

func createPeriodicTask() *timers {
ticker1 := createTicker(time.Duration(5) * time.Second)
ticker2 := createTicker(time.Duration(1) * time.Minute)
quit := make(chan bool)

timer := timers{*ticker1, *ticker2, quit}
return 
}

func main() {
timersArray := make([]*timers, 1000)

for i := range timersArray {
timer := createPeriodicTask()
timersArray[i] = timer
go timer.work()
}

//m := runtime.MemStats{}
for {
for i := range timersArray {
select {
case <-timersArray[i].done:
break
default:
time.Sleep(time.Duration(2000) * time.Millisecond)
//fmt.Println("Numero de goroutines existentes: ", 
runtime.NumGoroutine())
//runtime.ReadMemStats()
//fmt.Printf("%+v\n", m)
}
}
}
}


If I run this program for many hours the memory usage of the process 
steadily increases.

I changed the Ticker struct definition to use pointers to the 
time.newTicker and the problem is gone but I don't understand what was 
wrong with the first version, could somebody give me a hint?

-- 
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 build -gcflags '-N -l' don't work

[刘桂祥]

// example.go
package main


import "runtime"


type S struct{}


func main() {
 var stats runtime.MemStats


 runtime.ReadMemStats()
 println(stats.Mallocs)
 var x S
 runtime.ReadMemStats()
 println(stats.Mallocs)
 _ = *ref(x)
 runtime.ReadMemStats()
 println(stats.Mallocs)
}


func ref(z S) *S {
 return 
}

go build -gcflags '-N -l' example.go && ./example
or
go run -gcflags '-N -l' example.go

results:
./example.go:21:  escapes to heap
./example.go:20: moved to heap: z
./example.go:10: main  does not escape
./example.go:13: main  does not escape
./example.go:16: main  does not escape
61
61
61


-- 
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 toolchain confusion

[rob solomon]

Hi.  I'm new to Go.  I wrote some code for my own use on Ubuntu 16.04 
amd64, using just vim as my editor.


Then I got experimental and installed vscode 
(code_1.11.1-whatever-amd64.deb) and I let it install all the Go stuff 
it wanted.


I'm getting "cannot find package" messages from I guess golint. These 
are either packages I wrote myself or github.com/nsf/termbox-go.   These 
are found and used when I use go install  from a command line.



And then I compile the same code I develop on Ubuntu, on a win10 box, 
that now also has vscode.  On windows, I noticed that one of the tools 
keeps alphabetizing the imports in the ( ... ) list, and removing a 
needed import line from the list:

  "github.com/nsf/termbox-go"

At this point I have to stay w/ vim, but I wonder why I'm getting these 
errors from packages others highly recommend.


Thx,
Rob






--
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] swig and go

[larry104]

>
>
>
> CXXFLAGS 
>
> See https://golang.org/cmd/cgo . 
>
> Ian 
>

Cool - that works now like a charm - so much simpler than before - no more 
100 line long complicated make file.
Thanks a lot for your 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.

Re: [go-nuts] swig and go

[Ian Lance Taylor]

On Thu, Apr 13, 2017 at 11:40 AM, larry104  wrote:
>>
>>
>> The go tool will run whichever one is first on your PATH.
>>
>> Ian
>
>
> My mistake - there was a typo - Tracing what go build does with the -x
> option shows that swig run correct now (interface file with .swigcxx
> extension). Then it seems cg0 compiles all files in the _obj file with gcc4
> but when it comes to g++4 for my own c++ class it fails. // #cgo
> CFLAGS/LDFLAGS adds preprocessing directives to cgo - is there a
> preprocessing directive for c++4 as well?

CXXFLAGS

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

[go-nuts] Re: Vendoring nested dependencies

[David Collier-Brown]

As Russ Cox, a somewhat famous Gopher, noted, that's an NP-complete 
problem.  You can pay in effort (several different interpretations of 
"flattening"), in compile speed(running a SAT solver) or you can fail (;-))

This won't help you, but the last three times we ran into this, we changed 
the problem definition so we could achieve it. See “DLL Hell”, and avoiding 
an NP-complete problem 

 and 
especially David J Brown's paper, referred to there.

--dave
[I used to work for David J, my "evil twin".  My notably smarter twin, too]

-- 
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: Vendoring nested dependencies

[Ondřej Kupka]

Doesn't flattening and using a service like gopkg.in solve this issue? Then 
you can have both flat structure and multiple versions of the same library 
since different versions of the same library appear as different packages 
since the import path is different.

On Thursday, April 13, 2017 at 9:47:21 PM UTC+2, JB wrote:
>
> Our team has run into some complicated issues regarding vendoring. The 
> simplest way to explain it is with an illustration.
>
> We have three separate repositories; Main, Foo and Bar.
>
> Main vendors Bar
> Main vendors Foo
> Foo vendors Bar
>
> When trying to build this code, compile errors like this arise:
>
> ./main.go:12: cannot use Bar.Method() (type *"Main/vendor/Foo/vendor/Bar".T) 
> as type *"Main/vendor/Bar".T in assignment
>
>
> Flattening the vendor folder structure so that all vendored dependencies 
> (nested or not) all resolve in the same place will solve this, but if there 
> are actually different versions of Foo (Main depends on Bar@v1, Foo 
> depends on Bar@v2) then this becomes problematic once again.
>
> We use govendor as our dependency management tool.
>
> How can we deal with this issue properly?
>

-- 
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] Vendoring nested dependencies

[Michael Banzon]

In short: You can't.

Flattening is the way to go (pun intended) but dependeing on different
versions will brake your build.

On Thu, Apr 13, 2017 at 9:48 PM johnbernardo via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Our team has run into some complicated issues regarding vendoring. The
> simplest way to explain it is with an illustration.
>
> We have three separate repositories; Main, Foo and Bar.
>
> Main vendors Bar
> Main vendors Foo
> Foo vendors Bar
>
> When trying to build this code, compile errors like this arise:
>
> ./main.go:12: cannot use Bar.Method() (type *"Main/vendor/Foo/vendor/Bar".T) 
> as type *"Main/vendor/Bar".T in assignment
>
>
> Flattening the vendor folder structure so that all vendored dependencies
> (nested or not) all resolve in the same place will solve this, but if there
> are actually different versions of Foo (Main depends on Bar@v1, Foo
> depends on Bar@v2) then this becomes problematic once again.
>
> We use govendor as our dependency management tool.
>
> How can we deal with this issue properly?
>
> --
> 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.
>
-- 
Michael Banzon
https://michaelbanzon.com/

-- 
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] Vendoring nested dependencies

[johnbernardo via golang-nuts]

Our team has run into some complicated issues regarding vendoring. The 
simplest way to explain it is with an illustration.

We have three separate repositories; Main, Foo and Bar.

Main vendors Bar
Main vendors Foo
Foo vendors Bar

When trying to build this code, compile errors like this arise:

./main.go:12: cannot use Bar.Method() (type *"Main/vendor/Foo/vendor/Bar".T) as 
type *"Main/vendor/Bar".T in assignment


Flattening the vendor folder structure so that all vendored dependencies 
(nested or not) all resolve in the same place will solve this, but if there 
are actually different versions of Foo (Main depends on Bar@v1, Foo depends 
on Bar@v2) then this becomes problematic once again.

We use govendor as our dependency management tool.

How can we deal with this issue properly?

-- 
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] Gomail v2: sending emails faster

[emilyvyomahallaway . shiva]

Hi Alexandre
I tried sending an email using the server settings from my outlook mailbox 
and got this error - Could you shed some light as to what this could be 
about? 

panic: read tcp 10.18.32.66:59347->10.12.137.20:3268: read: connection 
reset by peer


goroutine 1 [running]:

panic(0x1aaf80, 0xc420014460)

/usr/local/Cellar/go/1.7.4_2/libexec/src/runtime/panic.go:500 +0x1a1

main.main()



On Wednesday, September 2, 2015 at 4:55:26 AM UTC-7, Alexandre Cesaro wrote:
>
> Hi,
>
> I just released the second version of Gomail 
> .
>
> There are quite a few backward-incompatible changes 
>  since 
> Gomail v1 but it brings lots of good stuff:
>
>- A great focus was placed on performances. Gomail v2 is way more 
>efficient than Gomail v1 to send a large number of emails (see the 
>Daemon  
>or Newsletter 
> 
>examples).
>- The API is now clearer and way more flexible.
>- The documentation  improved 
>and many examples were added.
>- All existing issues have been closed.
>- The minimum Go version is now 1.2 instead of 1.3. No external 
>dependencies are used with Go 1.5.
>
> More info on Github: https://github.com/go-gomail/gomail
>

-- 
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] swig and go

[larry104]

>
>
>
> The go tool will run whichever one is first on your PATH. 
>
> Ian 
>

My mistake - there was a typo - Tracing what go build does with the -x 
option shows that swig run correct now (interface file with .swigcxx 
extension). Then it seems cg0 compiles all files in the _obj file with gcc4 
but when it comes to g++4 for my own c++ class it fails. // 
#cgo CFLAGS/LDFLAGS adds preprocessing directives to cgo - is there 
a preprocessing directive for c++4 as well?

-- 
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] Memory use of a value

[Jesper Louis Andersen]

I think the most extreme variant of this sharing is when you build up a
"binary tree" that keeps pointing both left and right pointers to the same
underlying structure. A tree of size K is supposed to have around 2^K nodes
but in reality the memory layout is around K nodes in size. Suppose we
define (brace for some Erlang):

gather(X, 0) -> X;
gather(X, K) -> gather([X,X], K-1).

as a function and then call it with gather(<<"hello">>, 24), we obtain a
tree of size 2^24, yet it doesn't take up too much internal memory due to
sharing. To see how extreme it is, lets define

run() ->
Parent = self(),
spawn_link(
  fun() ->
  Res = gather(<<"hello">>, 24),
  {ok, Sock} = gen_tcp:connect({127,0,0,1}, 2000, [binary,
{packet, 4}]),
  gen_tcp:send(Sock, Res),
  gen_tcp:close(Sock),
  Parent ! {proc_info, erlang:process_info(self(), memory)},
  ok
  end),
receive
{proc_info, Info} ->
Info
after 5000 ->
{error, timeout}
end.

This creates a process, opens a local TCP socket on port 2000 (we'll have a
nc(1) patiently waiting in another shell piped to wc(1)), writes the tree
to the socket, and then closes it before returning. The output produced by
netcat has size around 81 Megabytes. Yet, the memory reported in the above
usage is around 5.7 Kilobytes for my installation. Sharing is caring, I
guess :)

Of course, this only works if your data is truly immutable. Mutating the
structure can yield some vastly different results and YMMV in that case.


On Thu, Apr 13, 2017 at 6:46 PM Ian Lance Taylor  wrote:

> On Thu, Apr 13, 2017 at 9:31 AM,   wrote:
> > https://play.golang.org/p/swRxxCbb65
> >
> > Surely s1 uses more than 8 bytes.
>
> Unfortunately, your question is not well defined.  s1 itself is 8
> bytes.  If you write `s3 := s1` and ask for the size of s3, it too
> will be 8 bytes.  There is also string data in memory, and both s1 and
> s3 will share that string data.  There isn't a clear answer to "how
> much space is taken by this value and everything to which it points."
>
> 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.

[go-nuts] File diff based go test check

[Tong Sun]

My program works on files, read from input and write to output. 

Is there any ready-made and *light *testing packages that allows me 
checking whether the new output is the same as before? 

Thanks


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Memory use of a value

[Ian Lance Taylor]

On Thu, Apr 13, 2017 at 9:31 AM,   wrote:
> https://play.golang.org/p/swRxxCbb65
>
> Surely s1 uses more than 8 bytes.

Unfortunately, your question is not well defined.  s1 itself is 8
bytes.  If you write `s3 := s1` and ask for the size of s3, it too
will be 8 bytes.  There is also string data in memory, and both s1 and
s3 will share that string data.  There isn't a clear answer to "how
much space is taken by this value and everything to which it points."

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] Memory use of a value

[Ian Lance Taylor]

On Thu, Apr 13, 2017 at 9:31 AM,   wrote:
> https://play.golang.org/p/swRxxCbb65
>
> Surely s1 uses more than 8 bytes.

Unfortunately, your question is not well defined.  s1 itself is 8
bytes.  If you write `s3 := s1` and ask for the size of s3, it too
will be 8 bytes.  There is also string data in memory, and both s1 and
s3 will share that string data.  There isn't a clear answer to "how
much space is taken by this value and everything to which it points."

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] Memory use of a value

[Jan Mercl]

On Thu, Apr 13, 2017 at 6:31 PM  wrote:

> https://play.golang.org/p/swRxxCbb65
>
> Surely s1 uses more than 8 bytes.

no

-- 

-j

-- 
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] Memory use of a value

[sdickey]

https://play.golang.org/p/swRxxCbb65

Surely s1 uses more than 8 bytes.

On Thursday, April 13, 2017 at 11:28:39 AM UTC-5, Jan Mercl wrote:
>
> On Thu, Apr 13, 2017 at 6:24 PM AWildTyphlosion <
> sdi...@watchtower-security.com > wrote:
>
> > I'm trying to figure out how much memory a value. Anyone have a clue how 
> to?
>
> unsafe.Sizeof/reflect.Type.Size
>
> -- 
>
> -j
>

-- 
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] Memory use of a value

[Jan Mercl]

On Thu, Apr 13, 2017 at 6:24 PM AWildTyphlosion <
sdic...@watchtower-security.com> wrote:

> I'm trying to figure out how much memory a value. Anyone have a clue how
to?

unsafe.Sizeof/reflect.Type.Size

-- 

-j

-- 
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] Memory use of a value

[AWildTyphlosion]

I'm trying to figure out how much memory a value. Anyone have a clue how to?


-- 
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] suggestions for the best way to consume Restful services

[Konstantin Khomoutov]

On Thu, 13 Apr 2017 05:35:57 -0700 (PDT)
Joe Blue  wrote:

> I have to consume 100's of restful services :)
> 
> So the only way is going to be some sort of parse and codegen
> approach.
> 
> Can anyone suggest any libraries or approaches please ?

go-swagger may be?

It's able to consume ready-made swagger specs, and when you don't have
these specs, you could possibly generate them from the service itself
using some other swagger-related tool. Maybe.

1. https://goswagger.io/

-- 
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] Russian translation of the Tour of Go

[Alexander Guz]

Hey!

I have just finished translating the Tour of Go to Russian language. I 
deployed it to https://go-tour-ru-ru.appspot.com - "go-tour-ru" was not 
available and there was nothing at this URL.

I hope it will be useful.

-- 
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] suggestions for the best way to consume Restful services

[Joe Blue]

I have to consume 100's of restful services :)

So the only way is going to be some sort of parse and codegen approach.

Can anyone suggest any libraries or approaches please ?

-- 
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] dep: Roadmap for merging into the toolchain

[Peter Bourgon]

I should clarify one thing: there are two open issues regarding the
·semantics· of the files: how the default versions are parsed re: the
caret[0], and how OS/arch/build tags are parameterized[1]. Until these
issues are closed, dep may change its interpretation of the files. If
you're interested in helping us get to a place of stability faster,
please volunteer in those tickets :)

[0] https://github.com/golang/dep/issues/225
[1] https://github.com/golang/dep/issues/291

Cheers,
Peter.

On Thu, Apr 13, 2017 at 9:25 AM, Peter Bourgon  wrote:
> And an update: thanks to the excellent work of contributor Carolyn Van
> Slyck, we have the manifest and lock file format changes complete and
> merged[0] to dep. From this point forward the file formats should be
> stable enough to start committing. So, as Russ originally noted:
> please do give it a try!
>
> [0] https://github.com/golang/dep/pull/342
>
> On Tue, Mar 28, 2017 at 10:38 AM, Peter Bourgon  wrote:
>> On Tue, Mar 28, 2017 at 3:14 AM, Russ Cox  wrote:
>>> On Mon, Mar 13, 2017 at 5:09 PM, Russ Cox  wrote:

 By far the most important things to do with dep right now are (1) build
 something people can use and get benefit from today and eliminate blockers
 to adoption and (2) based on experience with that usage, learn what the
 eventual design and go command integration should look like.
>>>
>>> I've been away and am not fully back yet, but I want to reemphasize these
>>> two lines, for everyone on this list and anyone else reading. I've heard a
>>> few people in various forums saying things like "I won't use dep until it's
>>> official".
>>>
>>> Please don't wait. Use it now. Make it possible for dep users to depend on
>>> specific versions of your packages: convert your packages to have manifest
>>> and lock files, and add version tags to your repos. Use dep for your own
>>> projects, to find out how well the approach works. Let us know.
>>
>> Agreed! But one important addendum: please wait until we've merged in
>> the manifest/lock file format changes[0][1] :) I'll post another
>> update to this thread when that's complete, as well as update dep's
>> README to remove the warnings. Thanks!
>>
>> [0] https://github.com/golang/dep/issues/119
>> [1] https://github.com/golang/dep/issues/168
>>
>>
>>> This is all critical. If you wait to try any of this until it's in the go
>>> command, then your feedback basically won't have any impact, because things
>>> will be so much harder to change at that point.
>>>
>>> (The flip side of this is that dep should freeze these basic details so that
>>> users aren't chasing a moving target. They don't need to be perfect. We know
>>> that JSON is not perfect, for example, but it's fine for this trial. The
>>> goal is to learn about the overall experience and semantics offered, not the
>>> file format.)
>>>
>>> Russ
>>>
>>> --
>>> 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] Compute materialised views from base records for a db

[Joe Blue]

Maybe something like this:

https://github.com/chrislusf/gleam/blob/master/README.md

It's generic and powerful.

-- 
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] Compute materialised views from base records for a db

[Joe Blue]

I am writing a grpc code generator.
It generates the normal stuff plus all database crud.

The DBs are only kv ones. Like boltdb and goleveldb. Also Mino fs can be used 
as a kv store.

You model you functions in grpc with a get and set name at the start. This 
allows me to see what is a read and what is a write to the dB.

Now i am ready to implement materialised views.
This allows a change in a base record to trigger an update in a materialised 
view.

So imagine you have 1000 record types. You know from a business perspective 
that you need to have relations between many of the base records. So for a kv 
store you can des eine the materialised view in the grpc using type composition.
This is a nice situation be sure your using type composition at the database 
level too so it's easy to code gen it.

This architecture is really nice for crdt style architectures because a write 
mutation can be designed ribed at the grpc level and the production of the 
materialised views can use that meta data 

My question relates to the best way to do the code to build the materialised 
views.

I figured that something like this is easy to do but i am guessing there are 
many ways of doing this.

-- 
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 golang's tuntime.gogo not restore normal registers

[Aram Hăvărneanu]

Because in Go general purpose registers are caller save.

-- 
Aram Hăvărneanu

-- 
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] why golang's tuntime.gogo not restore normal registers

[代君]

In runtime.gogo function, it's only restore SP LR PC, I couldn't understand 
how it works.

Assume that last goroutinue used R0-R9, and then the next goroutinue 
scheduled in, without restore R0-R9;

and then why dose the next goroutinue can work without errors?

-- 
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] dep: Roadmap for merging into the toolchain

[Peter Bourgon]

And an update: thanks to the excellent work of contributor Carolyn Van
Slyck, we have the manifest and lock file format changes complete and
merged[0] to dep. From this point forward the file formats should be
stable enough to start committing. So, as Russ originally noted:
please do give it a try!

[0] https://github.com/golang/dep/pull/342

On Tue, Mar 28, 2017 at 10:38 AM, Peter Bourgon  wrote:
> On Tue, Mar 28, 2017 at 3:14 AM, Russ Cox  wrote:
>> On Mon, Mar 13, 2017 at 5:09 PM, Russ Cox  wrote:
>>>
>>> By far the most important things to do with dep right now are (1) build
>>> something people can use and get benefit from today and eliminate blockers
>>> to adoption and (2) based on experience with that usage, learn what the
>>> eventual design and go command integration should look like.
>>
>> I've been away and am not fully back yet, but I want to reemphasize these
>> two lines, for everyone on this list and anyone else reading. I've heard a
>> few people in various forums saying things like "I won't use dep until it's
>> official".
>>
>> Please don't wait. Use it now. Make it possible for dep users to depend on
>> specific versions of your packages: convert your packages to have manifest
>> and lock files, and add version tags to your repos. Use dep for your own
>> projects, to find out how well the approach works. Let us know.
>
> Agreed! But one important addendum: please wait until we've merged in
> the manifest/lock file format changes[0][1] :) I'll post another
> update to this thread when that's complete, as well as update dep's
> README to remove the warnings. Thanks!
>
> [0] https://github.com/golang/dep/issues/119
> [1] https://github.com/golang/dep/issues/168
>
>
>> This is all critical. If you wait to try any of this until it's in the go
>> command, then your feedback basically won't have any impact, because things
>> will be so much harder to change at that point.
>>
>> (The flip side of this is that dep should freeze these basic details so that
>> users aren't chasing a moving target. They don't need to be perfect. We know
>> that JSON is not perfect, for example, but it's fine for this trial. The
>> goal is to learn about the overall experience and semantics offered, not the
>> file format.)
>>
>> Russ
>>
>> --
>> 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.