weekly.2011-12-01

242 views
Skip to first unread message

Andrew Gerrand

unread,
Dec 1, 2011, 12:51:22 AM12/1/11
to golang-nuts
We've just tagged a new Go weekly, weekly.2011-12-01. As usual, you
can update by running:
hg pull
hg update weekly

This weekly snapshot includes changes to the time, os, and text/template
packages. The changes to the time and os packages are significant and related.
Code that uses package time, package text/template, or package os's FileInfo
type will require changes.

In package time, there is now one type - time.Time - to represent times.
Note that time.Time should be used as a value, in contrast to old code
which typically used a *time.Time, a pointer to a large struct. (Drop the *.)
Any function that previously accepted a *time.Time, an int64
number of seconds since 1970, or an int64 number of nanoseconds
since 1970 should now accept a time.Time. Especially as a replacement
for the int64s, the type is good documentation about the meaning of
its value.

Whether you were previously calling time.Seconds, time.Nanoseconds,
time.LocalTime, or time.UTC, the replacement is the new function
time.Now.

If you previously wrote code like:

t0 := time.Nanoseconds()
myFunction()
t1 := time.Nanoseconds()
delta := t1 - t0
fmt.Printf("That took %.2f seconds\n", float64(t1-t0)/1e9)

you can now write:

t0 := time.Now()
myFunction()
t1 := time.Now()
delta := t1.Sub(t0)
fmt.Printf("That took %s\n", delta)

In this snippet, the variable delta is of the new type time.Duration, the
replacement for the many int64 parameters that were nanosecond
counts (but not since 1970).

Gofix can do the above conversions and some others, but it does not
rewrite explicit int64 types as time.Time. It is very likely that you will
need to edit your program to change these types after running gofix.
As always, be sure to read the changes that gofix makes using your
version control system's diff feature.

See http://weekly.golang.org/pkg/time/ for details.

In package os, the FileInfo struct is replaced by a FileInfo interface,
admitting implementations by code beyond the operating system.
Code that refers to *os.FileInfo (a pointer to the old struct) should
instead refer to os.FileInfo (the new interface).
The interface has just a few methods:

type FileInfo interface {
Name() string // base name of the file
Size() int64 // length in bytes
Mode() FileMode // file mode bits
ModTime() time.Time // modification time
IsDir() bool // abbreviation for Mode().IsDir()
}

If you need access to the underlying stat_t provided by the operating
system kernel, you can access it by assuming that the FileInfo you are
holding is actually an *os.FileStat, and that it's Sys field is actually a
*syscall.Stat_t, as in:

dev := fi.(*os.FileStat).Sys.(*syscall.Stat_t).Dev

Of course, this is not necessarily portable across different operating
systems.

Gofix will take care of rewriting *os.FileInfo to os.FileInfo for you,
and it will also rewrite expressions like fi.Name into calls like fi.Name().

See http://weekly.golang.org/pkg/os/#FileInfo for details.

The template package has been changed to export a new, simpler API.
The Set type is gone. Instead, templates are automatically associated by
being parsed together; nested definitions implicitly create associations.
Only associated templates can invoke one another.
This approach dramatically reduces the breadth of the construction API.
The html/template package has been updated also.
There's a gofix for the simplest and most common uses of the old API.
Code that doesn't mention the Set type is likely to work after running gofix;
code that uses Set will need to be updated by hand.
The template definition language itself is unchanged.

See http://weekly.golang.org/pkg/text/template/ for details.

Other changes:
* cgo: add support for callbacks from dynamic libraries.
* codereview: gofmt check for non-src/ files (thanks David Crawshaw).
* crypto/openpgp/packet: fix private key checksum.
* crypto/tls: add openbsd root certificate location,
don't rely on map iteration order.
* crypto/x509, crypto/tls: support PKCS#8 private keys.
* dashboard: start of reimplementation in Go for App Engine.
* encoding/xml: fix copy bug.
* exp/gui: move exp/gui and exp/gui/x11 to http://code.google.com/p/x-go-binding
* exp/ssh: various improvements (thanks Dave Cheney and Gustav Paul).
* filepath/path: fix Rel buffer sizing (thanks Gustavo Niemeyer).
* gc: fix Nconv bug (thanks Rémy Oudompheng) and other fixes.
* go/printer, gofmt: performance improvements.
* gofix: test and fix missorted renames.
* goinstall: add -fix flag to run gofix on packages on build failure,
better error reporting,
don't hit network unless a checkout or update is required,
support Google Code sub-repositories.
* html: parser improvements (thanks Andrew Balholm).
* http: fix sniffing bug causing short writes.
* json: speed up encoding, caching reflect calls.
* ld: align ELF data sections.
* math/big: fix destination leak into result value (thanks Roger Peppe),
use recursive subdivision for significant speedup.
* math: faster Cbrt and Sincos (thanks Charles L. Dorian).
* misc/osx: scripts to make OS X package and disk image (thanks Scott Lawrence).
* os: fail if Open("") is called on windows (thanks Alex Brainman).
* runtime: make sure stack is 16-byte aligned on syscall (thanks Alex Brainman).
* spec, gc: allow direct conversion between string and named []byte, []rune.
* sql: add Tx.Stmt to use an existing prepared stmt in a transaction,
more driver docs & tests; no functional changes.
* strings: add ContainsAny and ContainsRune (thanks Scott Lawrence).
* syscall: add SUSv3 RLIMIT/RUSAGE constants (thanks Sébastien Paolacci),
fix openbsd sysctl hostname/domainname workaround,
implement Syscall15 (thanks Alex Brainman).
* time: fix Timer stop.

Apologies if we missed anyone in the list above. We appreciate all your help.

To see a full list of changes between this and the previous weekly,
after updating, run:
hg log -r weekly.2011-11-18:2011-12-01

Enjoy.

Andrew

Anh Hai Trinh

unread,
Dec 1, 2011, 3:52:14 AM12/1/11
to Andrew Gerrand, golang-nuts
> Each Time has associated with it a Location, consulted when computing the presentation form of the time, such as in the Format, Hour, and Year methods. The methods Local, UTC, and In return a Time with a specific location. Changing the location in this way changes only the presentation; it does not change the instant in time being denoted and therefore does not affect the computations described in earlier paragraphs.

So what is the default Location associated with a Time, e.g. when
calling time.Now() ?


Also, why have three methods to do the job of one?

func (t Time) In(loc *Location) Time

In returns t with the location information set to loc.

func (t Time) Local() Time

Local returns t with the location set to local time.

func (t Time) UTC() Time

UTC returns t with the location set to UTC.


How about removing t.Local() and t.UTC(), and just use t.In(time.UTC)
or t.In(time.Local) which is explicit and only a few more chars to
type? I find that these methods don't "read" well.


--
@chickamade

kortschak

unread,
Dec 1, 2011, 4:00:31 AM12/1/11
to golang-nuts
The relevant gofix fixes don't appear to be present in this weekly.
What should they be called?

On Dec 1, 3:51 pm, Andrew Gerrand <a...@golang.org> wrote:
> Gofix can do the above conversions and some others, but it does not
> rewrite explicit int64 types as time.Time. It is very likely that you will
> need to edit your program to change these types after running gofix.
> As always, be sure to read the changes that gofix makes using your
> version control system's diff feature.
>

Vincent Vanackere

unread,
Dec 1, 2011, 4:05:10 AM12/1/11
to kortschak, golang-nuts
On Thu, Dec 1, 2011 at 10:00, kortschak <dan.ko...@adelaide.edu.au> wrote:
The relevant gofix fixes don't appear to be present in this weekly.
What should they be called?

It looks like the relevant gofix CL wasn't applied in time ;-)
You can get it here :

http://codereview.appspot.com/download/issue5450050_1005.diff

kortschak

unread,
Dec 1, 2011, 4:11:03 AM12/1/11
to golang-nuts
Almost finished doing it manually. Oh well. Learning experience from
two perspectives.

On Dec 1, 7:05 pm, Vincent Vanackere <vincent.vanack...@gmail.com>
wrote:

Andrew Gerrand

unread,
Dec 1, 2011, 5:08:39 AM12/1/11
to golan...@googlegroups.com
On Thursday, December 1, 2011 8:00:31 PM UTC+11, kortschak wrote:
The relevant gofix fixes don't appear to be present in this weekly.
What should they be called?
 
My apologies. Looks like I tagged this snapshot prematurely. I had thought the gofix was already submitted.

I'll issue another snapshot tomorrow. Users of the time package are advised to hold off on updating to this snapshot unless they want to update their code manually.

Sorry for the confusion.

Andrew

Mark Summerfield

unread,
Dec 1, 2011, 6:04:34 AM12/1/11
to Andrew Gerrand, golang-nuts
Hi,

On Thu, 1 Dec 2011 16:51:22 +1100
Andrew Gerrand <a...@golang.org> wrote:
> We've just tagged a new Go weekly, weekly.2011-12-01. As usual, you
> can update by running:
> hg pull
> hg update weekly

[snip]

(1) I notice that time.Time.Second()'s range is [0, 59]; shouldn't it be
[0, 60] to account for leap seconds?

(2) I really like the Example links: is there any documentation for how
they get there?

(3) Go seemed to build okay (I'm about to test my book's examples), but
one of the standard tests failed:

test net/mail
TEST FAIL net/mail
make[1]: Entering directory `/home/mark/opt/go/src/pkg/net/mail'
gotest -test.short -test.timeout=120
rm -f _test/net/mail.a
6g -p net/mail -o _gotest_.6 message.go message_test.go
rm -f _test/net/mail.a
gopack grc _test/net/mail.a _gotest_.6
--- FAIL: mail.TestDateParsing-4 (0.01 seconds)
message_test.go:109: Parse of "21 Nov 97 09:55:06 GMT": got Fri Nov 21 09:55:06 +0000 GMT 1997, want Fri Nov 21 09:55:06 +0000 GMT 1997
FAIL
gotest: "./6.out -test.short=true -test.timeout=120" failed: exit status 1
make[1]: *** [testshort] Error 2
make[1]: Leaving directory `/home/mark/opt/go/src/pkg/net/mail'
make: *** [net/mail.testshort] Error 1

--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Advanced Qt Programming" - ISBN 0321635906
http://www.qtrac.eu/aqpbook.html

Mark Summerfield

unread,
Dec 1, 2011, 6:57:09 AM12/1/11
to Andrew Gerrand, golang-nuts
Hi,

On Thu, 1 Dec 2011 16:51:22 +1100
Andrew Gerrand <a...@golang.org> wrote:

> We've just tagged a new Go weekly, weekly.2011-12-01. As usual, you
> can update by running:
> hg pull
> hg update weekly

[snip]


> In package os, the FileInfo struct is replaced by a FileInfo
> interface, admitting implementations by code beyond the operating
> system. Code that refers to *os.FileInfo (a pointer to the old
> struct) should instead refer to os.FileInfo (the new interface).
> The interface has just a few methods:
>
> type FileInfo interface {
> Name() string // base name of the file
> Size() int64 // length in bytes
> Mode() FileMode // file mode bits
> ModTime() time.Time // modification time
> IsDir() bool // abbreviation for Mode().IsDir()
> }

I've just noticed that the IsRegular() method seems to have gone which
seems a pity.

--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy

"Programming in Go" - ISBN 0321774639
http://www.qtrac.eu/gobook.html

四月份平民

unread,
Dec 1, 2011, 8:42:30 AM12/1/11
to a...@golang.org, golang-nuts

can we get a a r61 before go1?

> Date: Thu, 1 Dec 2011 11:57:09 +0000
> From: li...@qtrac.plus.com
> To: a...@golang.org
> CC: golan...@googlegroups.com
> Subject: Re: [go-nuts] weekly.2011-12-01

Volker Dobler

unread,
Dec 1, 2011, 8:53:30 AM12/1/11
to golang-nuts

On Dec 1, 12:04 pm, Mark Summerfield <l...@qtrac.plus.com> wrote:
> (1) I notice that time.Time.Second()'s range is [0, 59]; shouldn't it be
>     [0, 60] to account for leap seconds?

No, leap seconds are a bad idea: It is much better
if your clock reading (that's what Seconds() returns)
is not jerky as the underlying time itself isn't
jerky (at least not on these timescales representable
in Go :-)

> (2) I really like the Example links: is there any documentation for how
>     they get there?

See: http://tip.goneat.org/cmd/gotest/

Archos

unread,
Dec 1, 2011, 9:14:57 AM12/1/11
to golang-nuts

On Dec 1, 11:57 am, Mark Summerfield <l...@qtrac.plus.com> wrote:
>
> Andrew Gerrand <a...@golang.org> wrote:
> > We've just tagged a new Go weekly, weekly.2011-12-01. As usual, you
> > can update by running:
> >  hg pull
> >  hg update weekly
> [snip]
> > In package os, the FileInfo struct is replaced by a FileInfo
> > interface, admitting implementations by code beyond the operating
> > system. Code that refers to *os.FileInfo (a pointer to the old
> > struct) should instead refer to os.FileInfo (the new interface).
> > The interface has just a few methods:
>
> >        type FileInfo interface {
> >                Name() string       // base name of the file
> >                Size() int64        // length in bytes
> >                Mode() FileMode     // file mode bits
> >                ModTime() time.Time // modification time
> >                IsDir() bool        // abbreviation for Mode().IsDir()
> >        }
>
> I've just noticed that the IsRegular() method seems to have gone which
> seems a pity.
>
+1 to add IsRegular() method

Gustavo Niemeyer

unread,
Dec 1, 2011, 10:02:06 AM12/1/11
to Archos, golang-nuts
> +1 to add IsRegular() method

I faced that today too, but I have a slightly different idea for how
to solve it. Let me build a CL and see if it's well taken.

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.

Gustavo Niemeyer

unread,
Dec 1, 2011, 2:40:11 PM12/1/11
to Archos, golang-nuts
>> +1 to add IsRegular() method
>
> I faced that today too, but I have a slightly different idea for how
> to solve it. Let me build a CL and see if it's well taken.

http://code.google.com/p/go/source/detail?r=d175d9a4e830

Russ Cox

unread,
Dec 1, 2011, 4:41:09 PM12/1/11
to Mark Summerfield, Andrew Gerrand, golang-nuts
On Thu, Dec 1, 2011 at 06:04, Mark Summerfield <li...@qtrac.plus.com> wrote:
> (1) I notice that time.Time.Second()'s range is [0, 59]; shouldn't it be
>    [0, 60] to account for leap seconds?

No. Time pretends that leap seconds don't exist,
which is the best way to handle them. See also
http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

> (2) I really like the Example links: is there any documentation for how
>    they get there?

I'm not sure there is, but they are generated from the Example*
functions in the time directory.

> (3) Go seemed to build okay (I'm about to test my book's examples), but
>    one of the standard tests failed:
>
> test net/mail
> TEST FAIL net/mail
> make[1]: Entering directory `/home/mark/opt/go/src/pkg/net/mail'
> gotest -test.short -test.timeout=120
> rm -f _test/net/mail.a
> 6g   -p net/mail -o _gotest_.6 message.go  message_test.go
> rm -f _test/net/mail.a
> gopack grc _test/net/mail.a _gotest_.6
> --- FAIL: mail.TestDateParsing-4 (0.01 seconds)
>        message_test.go:109: Parse of "21 Nov 97 09:55:06 GMT": got Fri Nov 21 09:55:06 +0000 GMT 1997, want Fri Nov 21 09:55:06 +0000 GMT 1997
> FAIL

This is very odd. Do you have your $TZ set to "GMT" perhaps?

Russ

Andrew Gerrand

unread,
Dec 1, 2011, 5:39:27 PM12/1/11
to golan...@googlegroups.com, a...@golang.org
On Friday, December 2, 2011 12:42:30 AM UTC+11, uta wrote:
can we get a a r61 before go1?

The next release will be the Go 1 release candidate.

Andrew

Mark Summerfield

unread,
Dec 2, 2011, 2:14:20 AM12/2/11
to r...@golang.org, Andrew Gerrand, golang-nuts
On Thu, 1 Dec 2011 16:41:09 -0500
Russ Cox <r...@golang.org> wrote:
> On Thu, Dec 1, 2011 at 06:04, Mark Summerfield <li...@qtrac.plus.com>
> wrote:
> > (1) I notice that time.Time.Second()'s range is [0, 59]; shouldn't
> > it be [0, 60] to account for leap seconds?
>
> No. Time pretends that leap seconds don't exist,
> which is the best way to handle them. See also
> http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

I was slightly tongue in cheek about that anyway:-)

> > (2) I really like the Example links: is there any documentation for
> > how they get there?
>
> I'm not sure there is, but they are generated from the Example*
> functions in the time directory.

Someone else on the list pointed to the gotest docs which mentions
func ExampleXXX() {}
functions.

> > (3) Go seemed to build okay (I'm about to test my book's examples),
> > but one of the standard tests failed:
> >
> > test net/mail
> > TEST FAIL net/mail
> > make[1]: Entering directory `/home/mark/opt/go/src/pkg/net/mail'
> > gotest -test.short -test.timeout=120
> > rm -f _test/net/mail.a
> > 6g   -p net/mail -o _gotest_.6 message.go  message_test.go
> > rm -f _test/net/mail.a
> > gopack grc _test/net/mail.a _gotest_.6
> > --- FAIL: mail.TestDateParsing-4 (0.01 seconds)
> >        message_test.go:109: Parse of "21 Nov 97 09:55:06 GMT": got
> > Fri Nov 21 09:55:06 +0000 GMT 1997, want Fri Nov 21 09:55:06 +0000
> > GMT 1997 FAIL
>
> This is very odd. Do you have your $TZ set to "GMT" perhaps?

$ $GOROOT
bash: /home/mark/opt/go: is a directory
$ $TZ
$ date
Fri Dec 2 07:13:12 GMT 2011

So yes, I'm in GMT (but with an en_US.utf8 locale).

I'm on Debian 6 64-bit.

--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy

Reply all
Reply to author
Forward
0 new messages