Planning the 1.4 release

[Rob Pike]

Go 1.3 is on the exit ramp. We're in the quiet period now, and we hope
to ship the release within a couple of weeks.

The 1.3 release is the second one we've run within this new, regular
schedule[1]. Our ship date slipped a little, for a number of minor
reasons, but not by much. We expect 1.4 to happen, as normal, on
December 1, 2014.

So now it's time to plan what's next. What will be in 1.4?

The biggest component will be entirely under the covers, as the
toolchain and runtime move from C towards Go [2]. It's unlikely all C
code will be gone by 1.4, but much of it will, including - and most
exciting - the compiler. Compiler development in the C version is
likely to be dialed back, to free up more resources for the
transition. (Note that "rsc" appears nicely distributed in
"resources".) Similar conditions apply to the runtime.

Once the 1.3 release is live, we'll be open to new CLs but want to
concentrate on these fundamental changes, even scheduling them so the
code can move gracefully without introducing merge conflicts and other
complexities. If anyone else has other wide-ranging, core work like
this that would make sense for 1.4, please say so now so it can be
scheduled as well.

Over the next few weeks we'll work with you to sketch out the
large-scale priorities for 1.4 and pencil in the sequence of changes
to satisfy them.

Please remember that the open source community is vital to the Go
ecosystem. We can't thank you enough for your contributions.

-rob, for the Go team

[1] http://golang.org/s/releasesched
[2] http://golang.org/s/go13compiler

[Nathan Youngman]

I hope to see os/fsnotify in Go 1.4.

https://code.google.com/p/go-wiki/wiki/DesignDocuments

There is still a fair bit of experimentation needed before we settle on the API. 

We left off with: https://groups.google.com/d/msg/golang-dev/bShm2sqbrTY/IR8eI20Su8EJ

~

As well, I'd like to reopen the "locking down vanity import paths" conversation:

https://groups.google.com/forum/#!msg/golang-dev/RgHGBXROeAw/yCD6bpGq4R8J

Improving search results on GoDoc.org may be able to make use of a "canonical import path" of sorts:
https://github.com/golang/gddo/issues/172

- nathan

[Elias Naur]

I'd like to bring android Dalvik and iOS to the table again, as well as cgo shared libraries (perhaps using https://docs.google.com/document/d/1tU_yNmwu1raKZm9atHJ8THiQizkYTKykdWraIb15TSE/edit?usp=docslist_api as a starting point)

- elias

[Dave Cheney]

I would like to have a discussion about additional build tags for the
various arm variants now that instruction selection is handled at
compile time.

https://groups.google.com/d/topic/golang-dev/1EERkkWgbrM/discussion

The people who also want to do something similar for SSE2/3/4/AVX may
want to chime in.

Cheers

Dave

On Wed, Jun 4, 2014 at 3:24 PM, Elias Naur <elias...@gmail.com> wrote:
> I'd like to bring android Dalvik and iOS to the table again, as well as cgo shared libraries (perhaps using https://docs.google.com/document/d/1tU_yNmwu1raKZm9atHJ8THiQizkYTKykdWraIb15TSE/edit?usp=docslist_api as a starting point)
>
> - elias
>

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

[Aram Hăvărneanu]

My main priority this cycle is writing 7g, the arm64 compiler. I
hope to get it working in time to get it in 1.4. The first target
is plan9/arm64 and the principal target (but done second) is
linux/arm64. This is solitary work, I expect no clash with other
work, so it doesn't require any special scheduling.

There are other things I want to do, for which I might or I might
not have time to do. The first would be plan9/amd64 support. It
took me a single day to get to a semi-working go tool, so I expect
to finish that (mostly because I use the amd64 Plan 9 kernel these
days). plan9/arm is also on the table but rather unlikely for this
cycle.

Another thing I want to do is better DTrace support for Go. This
is not so much work, although I might wait until we have the linker
written in Go.

Another thing I will most certainly do very soon is cgo support for
the solaris/amd64 port (I've actually done it a few months ago and
it's working perfectly, 95% of the time).

I expect most of these things not to clash with other people's work,
even if some of thsese things are large. Or if there's a clash, it
would be minimal.

--
Aram Hăvărneanu

[Yukinari Toyota]

In my personal matter, I want to build generic runtime poller API like [Issue 6222: runtime: poller should be used for file system operations]

 but not for filesystem/AIO, just for file descriptors those support poll to enhance some device driver/device file operation supports.

2014年6月4日水曜日 7時44分53秒 UTC+9 Rob Pike:

[tracey....@gmail.com]

It would be a huge boon to the numerical community to have support for multi-dimensional slices (issue 6282). I think my proposal (linked in the issue) integrates well within the language. It would be useful to have some input on the proposal from the lead developers; so far there as only been one Go contributor that has commented on the proposal (aside from the proposal authors). It is my opinion that this set of changes, along with Dan’s suggested range syntax, constitutes a sufficient set of changes to make Go an excellent language for numeric computing.

I understand that even if the proposal is accepted a full implementation may add too much complexity for 1.4. In that case, a partial implementation (type definition, access, assignment, and slicing) would be of great help as we build a standard library for numeric/scientific computing in Go.

[Mikio Hara]

On Wed, Jun 4, 2014 at 7:44 AM, Rob Pike <r...@golang.org> wrote:

> So now it's time to plan what's next. What will be in 1.4?

I'd like to see netio or similar package that exposes both Poller and
Mutex primitives of the runtime-integrated network poller. A simple
motivation: we'll be able to implement featured network connection
endpoints which satisfy net.Conn interface without churning out the
runtime and net packages if we get some fancy network attachment that
implements some programmable protocol offload engine or net package
unsupported address families.

The replumbing work would not be tough; simply from runtime<-net to
runtime<-netio<-net (https://codereview.appspot.com/99510043/).

[Mikio Hara]

On Wed, Jun 4, 2014 at 1:34 PM, Nathan Youngman <n...@nathany.com> wrote:

> I hope to see os/fsnotify in Go 1.4.
> https://code.google.com/p/go-wiki/wiki/DesignDocuments

Hope so too. After it lands, net package uses os/fsnotify for
capturing local configuration file changes.

[Taru Karttunen]

On 04.06 20:40, Dave Cheney wrote:
> I would like to have a discussion about additional build tags for the
> various arm variants now that instruction selection is handled at
> compile time.
>
> https://groups.google.com/d/topic/golang-dev/1EERkkWgbrM/discussion

I would like to get the armv4 code in, which requires a solution to
this (the code contains a separate patch which implements build flags
armv4/armv5/armv6/armv7).

- Taru Karttunen

[Dave Cheney]

I would prefer not to see that. I've looked into arm4t boards and none
of them would be capable of running a builder so don't qualify as a
port.

[chen...@126.com]

Can map support upper_bound like c++?

在 2014年6月4日星期三UTC+8上午6时44分53秒，Rob Pike写道：

[Lucio De Re]

But by the same criterion, nor does NaCl, right?

[Aram Hăvărneanu]

> But by the same criterion, nor does NaCl, right?

No, NaCl has a builder (actually two), which is active and mostly
passes: http://build.golang.org.

--
Aram Hăvărneanu

[Brad Fitzpatrick]

Mostly? It actually passes. And when it breaks we've fix it. (See recent case)

Builders: they work.

[Aram Hăvărneanu]

> Mostly? It actually passes. And when it breaks we've fix it. (See recent
> case)

Yes, the builder always passes, 90% of the time.

--
Aram Hăvărneanu

[Dmitry Vyukov]

It makes no sense.

[Ian Lance Taylor]

On Thu, Jun 5, 2014 at 2:14 AM, <chen...@126.com> wrote:
>
> Can map support upper_bound like c++?

Not really, maps in Go are not sorted. They are like the C++
std::unordered_map, not the C++ std::map.

Ian

[Lucio De Re]

OK, but the issue was that there is no hardware to run arm<7 and I
presume that the NaCl builder runs as a VM, so I assumed that one
could run arm builders on emulators, like for NaCl?

Maybe a bad assumption?

[Brad Fitzpatrick]

Nacl doesn't require a VM. I mean, it IS one. But runs on any OS on that native arch.

[Aram Hăvărneanu]

> OK, but the issue was that there is no hardware to run arm<7 and I
> presume that the NaCl builder runs as a VM, so I assumed that one
> could run arm builders on emulators, like for NaCl?

There is a lot of armv4 hardware. The alleged problem is that is bad
(not enough memory?). Emulating it would only make it slower and
worse.

--
Aram Hăvărneanu

[Dave Cheney]

We have real arm hardware builders for arm v5, v6 and v7. The build
requires more than 256mb of ram to run to completion, and it was
difficult to find an arm v5 device that could fit those requirements.

In my research the largest armv4t device has a 400mhz cpu and a 64mb
of ram, they simply aren't capable of hosting a builder. Emulation may
be faster in that case if someone is prepared to host and maintain a
qemu builder.

I don't see the cost of supporting armv4t devices as worthwhile. There
are other devices that Go does not support, like the Intel Galileo,
and that's just the way it turned out.

[Dave Cheney]

On a different note I would like to have a discussion about how to
make the cmd/go tool available to platforms that don't/can't use the
gc toolchain.

The goal would be to support passing the contents of cmd/go to gccgo
unmodified and getting a linkable result. Right now that involves some
modification of the cmd/go sources to work with gccgo's 1.2 spec
standard library[1]. In theory this would be solvable with some build
tags.

Thoughts ?

1. http://go-talks.appspot.com/github.com/davecheney/gosyd/gccgo.slide#1

[Ian Lance Taylor]

On Thu, Jun 5, 2014 at 2:06 PM, Dave Cheney <da...@cheney.net> wrote:
>
> I don't see the cost of supporting armv4t devices as worthwhile. There
> are other devices that Go does not support, like the Intel Galileo,
> and that's just the way it turned out.

For oddball processors there is always the gccgo compiler.

Ian

[Ian Lance Taylor]

On Thu, Jun 5, 2014 at 2:30 PM, Dave Cheney <da...@cheney.net> wrote:
>
> On a different note I would like to have a discussion about how to
> make the cmd/go tool available to platforms that don't/can't use the
> gc toolchain.
>
> The goal would be to support passing the contents of cmd/go to gccgo
> unmodified and getting a linkable result. Right now that involves some
> modification of the cmd/go sources to work with gccgo's 1.2 spec
> standard library[1]. In theory this would be solvable with some build
> tags.

I would like to have gccgo build the go tool itself. This is mostly a
matter of getting the configury right. The go tool needs to be built
using a build-x-host Go compiler, but I only have build-x-target Go
compiler. (To be clear in a normal default build of gccgo these are
the same compiler, but GCC and hence gccgo are routinely built both as
and using cross-compilers.) If I can get that done that will address
your problem. But I don't know when I will work on it. But somebody
else could do it--patches welcome!

Also, I am currently in the process of updating gccgo's runtime
library to the 1.3 library.

All that aside, yes, I think that any general modifications needed to
make the go tool build and work with gccgo should be committed.

But I'm not entirely sure whether we want to worry about making the go
tool in the master tree buildable with older versions of gccgo. That
seems like a bit of a struggle. If that is desirable I think we
should make a fork of the go tool hosted elsewhere.

Ian

[Michael Hudson-Doyle]

Aram Hăvărneanu <ara...@mgk.ro> writes:

> My main priority this cycle is writing 7g, the arm64 compiler. I
> hope to get it working in time to get it in 1.4. The first target
> is plan9/arm64 and the principal target (but done second) is
> linux/arm64. This is solitary work, I expect no clash with other
> work, so it doesn't require any special scheduling.

Awesome! Let me know if Linaro can help in any way.

Cheers,
mwh

[Michael Hudson-Doyle]

Dave Cheney <da...@cheney.net> writes:

> On a different note I would like to have a discussion about how to
> make the cmd/go tool available to platforms that don't/can't use the
> gc toolchain.
>
> The goal would be to support passing the contents of cmd/go to gccgo
> unmodified and getting a linkable result. Right now that involves some
> modification of the cmd/go sources to work with gccgo's 1.2 spec
> standard library[1]. In theory this would be solvable with some build
> tags.

There is also that hard coded list of std libary package paths in the
gccgo-go source; I think that could/should be replaced with searching
gccgo's linker path for .gox files (gccgoimporter has code for this). I
think anyway! It's been a while since I thought about this.

Cheers,
mwh

[Taru Karttunen]

On 06.06 07:06, Dave Cheney wrote:
> We have real arm hardware builders for arm v5, v6 and v7. The build
> requires more than 256mb of ram to run to completion, and it was
> difficult to find an arm v5 device that could fit those requirements.
>
> In my research the largest armv4t device has a 400mhz cpu and a 64mb
> of ram, they simply aren't capable of hosting a builder. Emulation may
> be faster in that case if someone is prepared to host and maintain a
> qemu builder.
>
> I don't see the cost of supporting armv4t devices as worthwhile. There
> are other devices that Go does not support, like the Intel Galileo,
> and that's just the way it turned out.

Is this a general direction that it is not worthwhile to support e.g.
embedded systems in future if they are not usable as builders?

Typically when using a low end ARM system with Go the easiest way is
to use a higher-end ARM machine with an explicit GOARM setting and do
judicious testing on the target device.

What specs would you require for a builder (virtual) machine?

Is there a general good practice for maintaining out-of-tree ports?

- Taru Karttunen

[Aram Hăvărneanu]

FWIW I run Go on "small" machines, and I would be happy if I could run
it on even smaller machines. We can test ARMv4 code on newer ARM
machines; that's no guarantee it will run on ARMv4, but we don't use a
Pentium 2 to test GO386=387 either, so it's neither better or worse.

We can also reduce the scope of the tests for that platform, is native
testing is required.

Where there's a will, there's a way.

--
Aram Hăvărneanu

[Gustavo Niemeyer]

On Tue, Jun 3, 2014 at 7:44 PM, Rob Pike <r...@golang.org> wrote:
> The biggest component will be entirely under the covers, as the
> toolchain and runtime move from C towards Go [2]. It's unlikely all C
> code will be gone by 1.4, but much of it will, including - and most
> exciting - the compiler. Compiler development in the C version is
> likely to be dialed back, to free up more resources for the
> transition. (Note that "rsc" appears nicely distributed in
> "resources".) Similar conditions apply to the runtime.

We discussed the idea of having shared libraries of Go code a few
times over the last few months, to enable Linux distributions to
upgrade parts of Go applications across the whole system when there
are security incidents. Over a casual conversation with Russ at
GopherCon, we talked a bit about the potential granularity of that,
possibly having "bundles" of packages together in a single shared
object.

Given the comments above, I'm wondering if there's any chance this
might see some preliminary attention.


gustavo @ http://niemeyer.net

[John Waycott]

Has there been any discussion or interest in other specialized processors? My interest is the Tilera Gx which seems would be a good fit with Go since it is aimed at Go original server/system market space.

[snes...@gmail.com]

Support methods written in assembly.

Support all SIMD x86 instructions in 6a and 8a, if possible also other current non-SIMD instructions.

[Dave Cheney]

On Mon, Jun 9, 2014 at 5:56 AM, <snes...@gmail.com> wrote:

Support methods written in assembly.

Support all SIMD x86 instructions in 6a and 8a, if possible also other current non-SIMD instructions.

This has been requested before. Can you please make sure an issue detailing the instructions that you would like to see added is filed.

[Dmitry Vyukov]

On Wed, Jun 4, 2014 at 2:44 AM, Rob Pike <r...@golang.org> wrote:
> Go 1.3 is on the exit ramp. We're in the quiet period now, and we hope
> to ship the release within a couple of weeks.
>
> The 1.3 release is the second one we've run within this new, regular
> schedule[1]. Our ship date slipped a little, for a number of minor
> reasons, but not by much. We expect 1.4 to happen, as normal, on
> December 1, 2014.
>
> So now it's time to plan what's next. What will be in 1.4?
>

> The biggest component will be entirely under the covers, as the
> toolchain and runtime move from C towards Go [2]. It's unlikely all C
> code will be gone by 1.4, but much of it will, including - and most
> exciting - the compiler. Compiler development in the C version is
> likely to be dialed back, to free up more resources for the
> transition. (Note that "rsc" appears nicely distributed in
> "resources".) Similar conditions apply to the runtime.
>

> Once the 1.3 release is live, we'll be open to new CLs but want to
> concentrate on these fundamental changes, even scheduling them so the
> code can move gracefully without introducing merge conflicts and other
> complexities. If anyone else has other wide-ranging, core work like
> this that would make sense for 1.4, please say so now so it can be
> scheduled as well.
>
> Over the next few weeks we'll work with you to sketch out the
> large-scale priorities for 1.4 and pencil in the sequence of changes
> to satisfy them.
>
> Please remember that the open source community is vital to the Go
> ecosystem. We can't thank you enough for your contributions.

Hi!

My plans are:
- faster/better GC/malloc, mainly based on
https://docs.google.com/document/d/1HCPu3WKyCX3ZRYxmIMKTk0Ik1dePxKW1p02k3uhcft4/edit
but to be discussed (not sure if I will be able to do it all, but it
would be great)

- faster buffered channels
(https://docs.google.com/document/d/1yIAYmbvL3JxOKOjuCyon7JhW4cSv1wy5hC0ApeGMV9s/edit#heading=h.h23m1dwm0wep)
this must synchronize with Keith C->Go chan.goc transformation

- faster unbuffered channels [stretch]

- faster timers [stretch^2]

- better race detector (this should not conflict with other work, as
most changes will be in the race runtime):
- update to tip runtime
- output heap block allocation stack
- detect races between atomic and non-atomic accesses
- describe mutexes hold around racy accesses
- detect deadlocks [stretch]

[Erwin]

On 10 June 2014 03:27, Dave Cheney <da...@cheney.net> wrote:

On Mon, Jun 9, 2014 at 5:56 AM, <snes...@gmail.com> wrote:

Support methods written in assembly.

Support all SIMD x86 instructions in 6a and 8a, if possible also other current non-SIMD instructions.

This has been requested before. Can you please make sure an issue detailing the instructions that you would like to see added is filed.

 

Issue 4978 is about methods in assembly.

I could not find specific issues about the lack of some SSE instructions in 6a and 8a.

[Ed Swierk]

On Thursday, June 5, 2014 2:47:18 PM UTC-7, Ian Lance Taylor wrote:

All that aside, yes, I think that any general modifications needed to
make the go tool build and work with gccgo should be committed.

I'd like to be able to use a single instance of the go tool with both gc and gccgo backends, rather than needing a specially-built go tool just for gccgo. I posted patches a few weeks ago:

https://groups.google.com/forum/#!topic/golang-dev/AGGMtWHpXi0

--Ed

[Ian Lance Taylor]

To contribute patches, please follow the process described at
http://golang.org/doc/contribute.html . Thanks.

Ian