[go-nuts] `-pkgdir` option does not work with `go get` command

My go workspace is simple: [000]kdr2@Debian-X230:~/gows$ pwd /home/kdr2/gows [000]kdr2@Debian-X230:~/gows$ tree . └── src └── test └── m.go 2 directories, 1 file And the content of m.go is from https://raw.githubusercontent.com/facebookgo/grace/master/gracedemo/demo.go . All ENV

[go-nuts] Re: Go -> C++ transpiler idea: Miracle child or horrible abomination?

Just thought about maybe this could be used to generate the C header and source files for C binding. Currently we have to write a hybrid language called cgo for FFI. It's not always the best approach. I'd like to have a C header that can be included to implement a 'driver' for the Go runtime

Re: [go-nuts] New Smallcaps Go Fonts; other Go Fonts updated

Good advice for Go as well. Maybe that should be the last line of a panic crash: [image: Inline image 1] On Thu, Mar 30, 2017 at 7:56 PM, Rob Pike wrote: > With the new "Smallcaps" font you can feel nostalgic by pretending you're > working on a TI Silent 700. > > -rob > > >

[go-nuts] Minecraft and Go (with project Malmo)

Hello, Everybody: If you like Minecraft and Go, you may like project Malmo and the GoWrapper I have been working on (https://github.com/cpmech/malmo forked from here ). For example, a minimal

Re: [go-nuts] dep: Roadmap for merging into the toolchain

I think Russ' feedback may imply dep needing to be versioned, as in the project itself publishing releases. Specially considering Peter Bourgon's lastest response, there's no way of users to know if dep is usable yet or not (roadmap is too abstract in that regard), and after that, what features

Re: [go-nuts] Re: [ANN] Go geospatial libraries: geometries, GeoJSON, WKB, KML, PostGIS, GPX, polyline

Hard to do better than KML. :-) On Thu, Mar 30, 2017 at 11:41 AM, Constantine Vassilev wrote: > Hi Tom, > > It worked perfectly. Thank you! > > --Constantine > > On Monday, March 27, 2017 at 11:14:48 AM UTC-7, Tom Payne wrote: >> >> Here's an example: >> >> 8< >>

Re: [go-nuts] time: error prone implementation of Time.Format

Il giorno giovedì 30 marzo 2017 17:28:47 UTC+2, Ian Lance Taylor ha scritto: > > > [...] > >> But it's not clearly incorrect to write > >> > >> "2006-01-02 or Jan 02, 2006" > >> > > > > I'm probably missing something, but "2006-01-02" is a valid time layout > > string. > > I'm presenting

Re: [go-nuts] time: error prone implementation of Time.Format

On Thu, Mar 30, 2017 at 7:49 AM, Manlio Perillo wrote: > Il giorno giovedì 30 marzo 2017 01:21:14 UTC+2, Ian Lance Taylor ha scritto: >> >> On Wed, Mar 29, 2017 at 2:29 PM, Manlio Perillo >> wrote: >> > Il giorno mercoledì 29 marzo 2017 23:18:09

Re: [go-nuts] Re: Go's Deprecation Policy + Android NDK

On Thu, Mar 30, 2017 at 5:14 PM Tomi Häsä wrote: > I have been pondering the minimum supported Android version also. First I > thought of 4.0.3, which I recall is what Android Studio has been > suggesting. On the other hand, Android 4.3 supports widgets "anywhere" on >

[go-nuts] Re: JSON empty slice and/or empty set encoding question/proposal

That does indeed work, but requires a call to "NewFoo" every time i marshal (invoking an allocation and subsequent GC). The application I am building is extremely memory intensive so I would like to be able to avoid that. I am totally willing to put in the work on the standard library

[go-nuts] Re: Go's Deprecation Policy + Android NDK

I have been pondering the minimum supported Android version also. First I thought of 4.0.3, which I recall is what Android Studio has been suggesting. On the other hand, Android 4.3 supports widgets "anywhere" on Android Home Screen and I might use widgets with some of my apps. Any thoughts on

[go-nuts] Re: JSON empty slice and/or empty set encoding question/proposal

Why not provide a "NewFoo() *Foo" function instead? https://play.golang.org/p/GE8cMgwe24 On Monday, March 27, 2017 at 10:42:46 AM UTC-6, traetox wrote: > > Hello all, > > I have swept through the list and gone through the pkg/encoding/json > package and _believe_ I haven't missed anything, but

Re: [go-nuts] golang precise gc

I don't understand what you are trying to say. Note that your code uses unsafe.Pointer in an unsupported way. See https://golang.org/pkg/unsafe/#Pointer . Ian On Thu, Mar 30, 2017 at 7:08 AM, 刘桂祥 wrote: > package main > > import ( > "fmt" > "runtime" > "unsafe" > ) >

Re: [go-nuts] time: error prone implementation of Time.Format

I think he said "02/02/2006", and got two day-numbers instead of a day and a month. --dave On Thursday, March 30, 2017 at 10:49:29 AM UTC-4, Manlio Perillo wrote: > > Il giorno giovedì 30 marzo 2017 01:21:14 UTC+2, Ian Lance Taylor ha > scritto: >> >> On Wed, Mar 29, 2017 at 2:29 PM, Manlio

Re: [go-nuts] time: error prone implementation of Time.Format

Il giorno giovedì 30 marzo 2017 01:21:14 UTC+2, Ian Lance Taylor ha scritto: > > On Wed, Mar 29, 2017 at 2:29 PM, Manlio Perillo > wrote: > > Il giorno mercoledì 29 marzo 2017 23:18:09 UTC+2, Ian Lance Taylor ha > > scritto: > >> > >> On Wed, Mar 29, 2017 at 2:03 PM,

Re: [go-nuts] time: error prone implementation of Time.Format

Certainly this is a bug that can be found with unit test, however catching a bug early is always better, if this is possible. Manlio Il giorno giovedì 30 marzo 2017 13:18:35 UTC+2, rog ha scritto: > > Isn't this the kind of thing we write tests for? > > On 29 Mar 2017 22:03, "Manlio Perillo"

[go-nuts] golang precise gc

package main import ( "fmt" "runtime" "unsafe" ) func main() { var m runtime.MemStats runtime.ReadMemStats() println(m.HeapObjects, m.Mallocs) runtime.GC() runtime.ReadMemStats() println(m.HeapObjects, m.Mallocs) runtime.GC() runtime.ReadMemStats() println(m.HeapObjects, m.Mallocs) p :=

[go-nuts] Re: Go's Deprecation Policy + Android NDK

Go has very few dependencies on its environment, so it should be able to run on quite old phones. I have a 4.1 device still running that I regularly test Go (with Go Mobile) on. I would recommend using the newest Go version for your projects. There are often important fixes in newer Go

Re: [go-nuts] time: error prone implementation of Time.Format

>From your described implementation, I assume you're asking for something like As a programmer, if I ask for a date with month twice, I wish to revieve a warning" If so, it would complain if I asked to print something like "01/01/2017 (1 Jan 2017)" --dave -- You received this message

Re: [go-nuts] time: error prone implementation of Time.Format

>From your described implementation, I assume youre asking for On Wednesday, March 29, 2017 at 5:29:19 PM UTC-4, Manlio Perillo wrote: > > Il giorno mercoledì 29 marzo 2017 23:18:09 UTC+2, Ian Lance Taylor ha > scritto: >> >> On Wed, Mar 29, 2017 at 2:03 PM, Manlio Perillo >>

[go-nuts] Go's Deprecation Policy + Android NDK

I have been thinking of using Go in Android apps with Android NDK. How does the Go deprecation policy affect me in the long run? How old phones can I support? Should I use as old Go version as possible for maximum compatibility? -- You received this message because you are subscribed to the

[go-nuts] Re: how to debug in gomobile? & can gomobile support mac or linux sometime

Em quarta-feira, 29 de março de 2017 22:31:52 UTC-3, hui zhang escreveu: > > As too me gomobile now are more like a game engine (for ui is gl) , like > cocos2dx. > but unlike cocos2dx, it only support mobile, and did not offer a way to > debug in wiki. > > how to debug, if it could not be

Re: [go-nuts] Re: go run package

> > A bin util, which would do something similar to your idea > `goexec bin args...` might be smart enough to sort things out > and call for the right binary in the right path, > it is also able to provide detailed information when something wrong > happen. > It would indeed be unambiguous,

Re: [go-nuts] time: error prone implementation of Time.Format

Isn't this the kind of thing we write tests for? On 29 Mar 2017 22:03, "Manlio Perillo" wrote: > In a program I have a function that formats the time in Italian date > format: dd/mm/, but, due to an oversight, I wrote the layout string as > "02/02/2006", instead of

[go-nuts] Re: How to control the symbol visibility of shared lib built from Go

Yes. 1. "default" visibility will contribute the loading time. 2. also it's possible to relocate the symbol provided by another linked library. but if it's protected or hidden these symbols won't be relocated anymore during loading. On Tuesday, March 21, 2017 at 8:49:26 PM UTC+8, David

[go-nuts] Re: go run package

Another scenario, There is a package x which requires a bin package Y, if the bin package is installed as global, a per package dependency reference breaks, so the bin file needs to exists into a package/vendor/bin which co exists with GOPATH/bin having the path modified to ./vendor/bin does

Re: [go-nuts] go run package

> > I don't like the idea of giving go run any more powers. It is already >> being horribly abused. >> > > I understand the sentiment; it needn't be the run sub-command of course... > it's about adding this behaviour to the go command. > Because I'm lacking imagination, it could be an entirely

Re: [go-nuts] go run package

> > > go run github.com/fruit/banana arg1 arg2 ... > > I don't like the idea of giving go run any more powers. It is already > being horribly abused. > I understand the sentiment; it needn't be the run sub-command of course... it's about adding this behaviour to the go command. > Your users can

Re: [go-nuts] go run package

On Thu, Mar 30, 2017 at 11:28 AM Paul Jolly wrote: > go run github.com/fruit/banana arg1 arg2 ... I don't like the idea of giving go run any more powers. It is already being horribly abused. Your users can perhaps try $ $GOPATH/bin/banana arg1 arg2 if properly

[go-nuts] go run package

I've searched golang-nuts and the Go issue tracker pretty extensively and I can't find any mention of my question or the topic, so would appreciate any links if this has been previously covered and I was simply using the wrong search terms. go install takes a number of packages as arguments:

Re: [go-nuts] Re: directory name versus package name

On Thu, Mar 30, 2017 at 1:41 AM Dorival Pedroso wrote: > I like the idea that the go tool would enforce matching directory and package names. I don't know why it should be enforced, but consider that commands must be in package main. -- -j -- You received this