Re: [go-nuts] Go beginner asks for code review

[Diego Medina]

Hi,

First, awesome that you started using Go! some thoughts inline:

 

> 1. The sbxs_ prefix is there just because I expect this package to be part 
> of a set of related repositories and I wanted to give them some "unity" 
> through naming. Arguably a bad idea, I am not sure about it.
>

I have seen two ways other Go developers have "solve" this,

1. Create a dedicated organization/github account for this group of repos, 
like

http://www.gorillatoolkit.org/

if you see that link (you probably are familiar with it already but if not)

you have:

gorilla/context
gorilla/mux
gorilla/reverse
gorilla/rpc 
gorilla/schema
gorilla/securecookie
gorilla/sessions 
gorilla/websocket

and people in the community refers to them as " ... have you tried gorilla 
mux? ..." , etc 

2. in your github account you create a repo sbxs, and inside there you add 
a folder go_markydown

if then you have a new component that is related, you create a new folder, 
go_asciidoc inside sbxs

this is somewhat similar to juju iirc

https://github.com/juju/juju


 

>
> 2. I added "go" to the package name because I tend to experiment with 
> different languages from time to time, and therefore I have a reasonable 
> chance to have naming conflicts without it.
>
>
this is a personal preference, you have your reason, sounds good to me :)
 

> 3. I added that extra "markydown" directory just because I read on 
> Effective Go that it is a convention to give the package name the same name 
> as the directory, and I thought that "markydown" was a better package name 
> than "sbxs_go_markydown". Maybe I should just use the long package name and 
> let users rename it when importing if they wish? Or is there  some better 
> way?
>
>
skipping this one.

Thanks!



 

> Thanks again!
>
> LMB
>
>

-- 
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] WebP encoder

[Nigel Tao]

On Fri, Sep 23, 2016 at 4:18 AM, Aarti Parikh  wrote:
> Is webp encoding in pure go something that may happen in a future release?

I'd like to see that, but I have higher priority things to work on.

-- 
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] Go beginner asks for code review

['Chris Manghane' via golang-nuts]

On Thu, Sep 22, 2016 at 3:31 PM, Leandro Motta Barros 
wrote:

> Hi Sam,
>
> Looks like your response got truncated. :-/
>
> Anyway, there is a good deal of nice tips, there. I am updating my code to
> take your feedback into account. Thanks a lot!
>
> There is one point I still wondering about, however:
>
>
> On Thu, Sep 22, 2016 at 1:57 PM, Sam Whited  wrote:
>
>>
>> > github.com/lmbarros/sbxs_go_markydown/markydown
>>
>> The package would normally just live at the repo root in go; unless
>> you're expecting other subpackages to live in this repo. Right now I'd have
>> to:
>>
>> import "github.com/lmbarros/sbxs_go_markydown/markydown"
>>
>> but it might read better if I could just import:
>>
>> import "github.com/lmbarros/go_markydown"
>>
>> (you can also leave the go_ off if this will be the only thing called
>> markydown on your GitHub account)
>>
>>
> Yes, I think the directory structure I used sucks, and I'd like to improve
> it. I'll tell why did so, and would be glad to have some feedback about it:
>
> 1. The sbxs_ prefix is there just because I expect this package to be part
> of a set of related repositories and I wanted to give them some "unity"
> through naming. Arguably a bad idea, I am not sure about it.
>
> 2. I added "go" to the package name because I tend to experiment with
> different languages from time to time, and therefore I have a reasonable
> chance to have naming conflicts without it.
>
> 3. I added that extra "markydown" directory just because I read on
> Effective Go that it is a convention to give the package name the same name
> as the directory, and I thought that "markydown" was a better package name
> than "sbxs_go_markydown". Maybe I should just use the long package name and
> let users rename it when importing if they wish? Or is there  some better
> way?
>
>
To this point, it's probably better not expect users to rename your package
when importing it. Import paths can be gross, but it should not affect the
underlying package name. That is to say, you can keep the long import path
and just name the package "markydown". Given your other considerations, the
convention in Effective Go doesn't fit very well in this situation.


> Thanks again!
>
> LMB
>
> --
> 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] Re: truncate float32 to lesser precision (22 bit mantissa)

[xiiophen]

On Thursday, 22 September 2016 19:43:35 UTC+1, Jamie Clarkson wrote:
>
> Sure, as you say for your use case it might be best for you, and you might 
> need different information from the test anyway.   Usually in a fast ray 
> tracer you'd pre-calculate the inverse of the direction components and 
> store them (since you do LOTS of ray-bbox intersections for each ray while 
> traversing the bounding hierarchies) then the slab test is pure 
> multiplication and adds.  The branchless version then replaces all branch 
> tests with min/max operations.  I'd be interested if your div free version 
> is faster and doesn't need the precalculation/storage costs.
>
> Cheers,
>
> Jamie
>
>
I'm currently fiddling with the "no-division" version - it's not optimised. 
It doesn't actually avoid the division, unless all that is needed is a 
true/false (intersects) return - for a function that also returns the 
scalar along the ray the division is still needed, but it's not in the 
boundary check 

Easier to show : Original code (in my first post)

front_n = (x_front - s.X) / v.X
ripY = s.Y + front_n*v.Y
ripZ = s.Z + front_n*v.Z

if (front_n > 0) && (ymin <= ripY && ripY <= ymax) && (zmin <= ripZ && ripZ 
<= zmax) { ..etc ..


becomes  (completely non-optimized)

 

front_n_d = (x_front - s.X) // non-divided version
positive = (v.X > 0)

 

if (front_n_d > ) == positive &&
((ymin-s.Y)*v.X <= front_n_d*v.Y)==positive &&
(front_n_d*v.Y <= (ymax-s.Y)*v.X)==positive &&
((zmin-s.Z)*v.X <= front_n_d*v.Z)==positive &&
(front_n_d*v.Z <= (zmax-s.Z)*v.X))==positive {
..etc..

 

(terms such as ymin-s.Y are reused many times .. I haven't remove them here 
as it obscures the math.)

 
the obvious alternative is to add an extra if positive .. else .. to 
simplify all those ==positive out of the condition.. *either way I'm not 
expecting it to be faste*r, but the *numerical errors should be much less*, 
since each side has only 1 multiply and 1 add/subtract, whereas the 
original form had all the math on one side of the boundary condition - 
consisting of a subtract followed by a divide ie (x_front - s.X) / v.X (or 
a multiplication by a reciprocal which adds more potential numerical 
error), compounded into an additional multiplication and add ie s.Y + 
front_n*v.Y - so in terms of numerical accuracy the non-multiply version 
should be much better.

however if the condition is true the divide is still required to get the 
scalar if needed :

front_n = front_n_d / v.X


So for multiple rays the pre-store of the reciprocal of v.X, v.Y, v.Z still 
make sense. 

For the usual raytracing bounding boxes a few errors, or slightly oversized 
bounding boxes are fine, but in my case the ray-box intersection is used to 
generate indexes for a 3d voxel array - so errors here can throw an index 
out of range (about 1 in 1 million rays, but still a run time panic for me)


-- 
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] Go beginner asks for code review

[Leandro Motta Barros]

Hi Sam,

Looks like your response got truncated. :-/

Anyway, there is a good deal of nice tips, there. I am updating my code to
take your feedback into account. Thanks a lot!

There is one point I still wondering about, however:


On Thu, Sep 22, 2016 at 1:57 PM, Sam Whited  wrote:

>
> > github.com/lmbarros/sbxs_go_markydown/markydown
>
> The package would normally just live at the repo root in go; unless you're
> expecting other subpackages to live in this repo. Right now I'd have to:
>
> import "github.com/lmbarros/sbxs_go_markydown/markydown"
>
> but it might read better if I could just import:
>
> import "github.com/lmbarros/go_markydown"
>
> (you can also leave the go_ off if this will be the only thing called
> markydown on your GitHub account)
>
>
Yes, I think the directory structure I used sucks, and I'd like to improve
it. I'll tell why did so, and would be glad to have some feedback about it:

1. The sbxs_ prefix is there just because I expect this package to be part
of a set of related repositories and I wanted to give them some "unity"
through naming. Arguably a bad idea, I am not sure about it.

2. I added "go" to the package name because I tend to experiment with
different languages from time to time, and therefore I have a reasonable
chance to have naming conflicts without it.

3. I added that extra "markydown" directory just because I read on
Effective Go that it is a convention to give the package name the same name
as the directory, and I thought that "markydown" was a better package name
than "sbxs_go_markydown". Maybe I should just use the long package name and
let users rename it when importing if they wish? Or is there  some better
way?

Thanks again!

LMB

-- 
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] TCP Client can't dial to server on localhost: network is unreachable.

['Константин Иванов' via golang-nuts]

Curse. I sprinkle ashes upon my head. That was a stupid mistake.

Yeah, 127.0.0.1 works fine. Thank you

четверг, 22 сентября 2016 г., 22:29:15 UTC+3 пользователь bradfitz написал:
>
> Use 127.0.0.1, not 127.0.0.0
>
> The playground's net implementation is a toy and not very accurate.
>
>
> On Thu, Sep 22, 2016 at 10:41 AM, 'Константин Иванов' via golang-nuts <
> golan...@googlegroups.com > wrote:
>
>> Related to net package.
>>
>> Code works fine on playground: https://play.golang.org/p/1fCIZzaUIT
>>
>> But on local machine I've got (every time)
>>
>> 2016/09/22 20:37:30 listening on: 127.0.0.0:44327
>> 2016/09/22 20:37:30 dialing
>> 2016/09/22 20:37:30 dial error: dial tcp 127.0.0.0:44327: connect: 
>> network is unreachable
>>
>> go version
>>
>> go version go1.7.1 linux/amd64
>>
>> What could it mean?
>>
>> -- 
>> 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...@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] Re: TCP Client can't dial to server on localhost: network is unreachable.

['Константин Иванов' via golang-nuts]

uname -a
Linux hpg6 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux

-- 
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: Request for advice: Developing for Android

[Elias Naur]

On Thursday, September 22, 2016 at 6:35:13 PM UTC+2, Peter Kleiweg wrote:
>
>
>
> Op donderdag 22 september 2016 18:28:43 UTC+2 schreef Peter Kleiweg:
>>
>> Op donderdag 22 september 2016 18:08:10 UTC+2 schreef Elias Naur:
>>>
>>>
>>>
>>> On Thursday, September 22, 2016 at 5:34:24 PM UTC+2, Peter Kleiweg wrote:

 I try the examples on  https://github.com/golang/go/wiki/Mobile

 Native applications -> Building and deploying to Android works fine.

 On "SDK applications and generating bindings" I get into problems.

 It says: 

 go get -d golang.org/x/mobile/example/bind/...

 I get:

 warning: "golang.org/x/mobile/example/bind/..." matched no packages
 can't load package: package golang.org/x/mobile/example: no 
 buildable Go source files in /home/peter/go/src/
 golang.org/x/mobile/example


>>> That's odd, and it should definitely work. With Go 1.7.1 and after 
>>> removing my existing $GOPATH/golang.org directory out of the way, 
>>> running
>>>
>>> $ go get -d golang.org/x/mobile/example/bind/. 
>>> ..
>>>
>>> outputs no error and downloads golang.org/x/mobile just fine. Which 
>>> version of Go are you using? Regardless of this issue, I recommend 1.7.1 
>>> because it contains fixes for several issues on mobiles, in particular iOS.
>>>
>>
>> (peter) ~ go version
>> go version go1.7.1 linux/amd64
>> (peter) ~ go env
>> GOARCH="amd64"
>> GOBIN=""
>> GOEXE=""
>> GOHOSTARCH="amd64"
>> GOHOSTOS="linux"
>> GOOS="linux"
>> GOPATH="/home/peter/go"
>> GORACE=""
>> GOROOT="/my/opt/go"
>> GOTOOLDIR="/my/opt/go/pkg/tool/linux_amd64"
>> CC="gcc"
>> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
>> -fdebug-prefix-map=/tmp/go-build429704933=/tmp/go-build 
>> -gno-record-gcc-switches"
>> CXX="g++"
>> CGO_ENABLED="1"
>> (peter) ~ go get -v -u -d golang.org/x/mobile/example/bind/...
>> Fetching https://golang.org/x/mobile/example/bind?go-get=1
>> Parsing meta tags from 
>> https://golang.org/x/mobile/example/bind?go-get=1 (status code 200)
>> get "golang.org/x/mobile/example/bind": found meta tag 
>> main.metaImport{Prefix:"golang.org/x/mobile", VCS:"git", RepoRoot:"
>> https://go.googlesource.com/mobile"} at 
>> https://golang.org/x/mobile/example/bind?go-get=1
>> get "golang.org/x/mobile/example/bind": verifying non-authoritative 
>> meta tag
>> Fetching https://golang.org/x/mobile?go-get=1
>> Parsing meta tags from https://golang.org/x/mobile?go-get=1 (status 
>> code 200)
>> golang.org/x/mobile (download)
>> warning: "golang.org/x/mobile/example/bind/..." matched no packages
>> can't load package: package .: no buildable Go source files in 
>> /home/peter
>>
>
> When I do this first, it works:
>
> rm -fr $GOPATH/src/golang.org/x/mobile
>
>  
>

Does subsequent go gets after rm -fr'ing once, or only if you rm -fr before 
go get every time? If it works from now on, you might have had some old 
crud in the existing directory. If you need rm -fr every time, here's the 
output from similar runs on my machine:
 
$ go version
go version go1.7.1 linux/amd64
$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/elias/dev/go"
GORACE=""
GOROOT="/home/elias/dev/go-release"
GOTOOLDIR="/home/elias/dev/go-release/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build347214193=/tmp/go-build 
-gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
$ go get -v -u -d golang.org/x/mobile/example/bind/...
Fetching https://golang.org/x/mobile/example/bind/hello?go-get=1
Parsing meta tags from 
https://golang.org/x/mobile/example/bind/hello?go-get=1 (status code 200)
get "golang.org/x/mobile/example/bind/hello": found meta tag 
main.metaImport{Prefix:"golang.org/x/mobile", VCS:"git", 
RepoRoot:"https://go.googlesource.com/mobile"} at 
https://golang.org/x/mobile/example/bind/hello?go-get=1
get "golang.org/x/mobile/example/bind/hello": verifying non-authoritative 
meta tag
Fetching https://golang.org/x/mobile?go-get=1
Parsing meta tags from https://golang.org/x/mobile?go-get=1 (status code 
200)
golang.org/x/mobile (download)
$

 - elias

-- 
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] TCP Client can't dial to server on localhost: network is unreachable.

['Константин Иванов' via golang-nuts]

Related to net package.

Code works fine on playground: https://play.golang.org/p/1fCIZzaUIT

But on local machine I've got (every time)

2016/09/22 20:37:30 listening on: 127.0.0.0:44327
2016/09/22 20:37:30 dialing
2016/09/22 20:37:30 dial error: dial tcp 127.0.0.0:44327: connect: network 
is unreachable

go version

go version go1.7.1 linux/amd64

What could it mean?

-- 
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: telling apart errors returned by database/sql

[edmund . troche]

This is what I expected to see and it is dissapointing to see it is not how 
it is implemented even 3 years after your post.



On Tuesday, June 11, 2013 at 7:29:45 PM UTC-5, John Nagle wrote:
>
>There's a standardized set of SQLSTATE codes for SQL 
> systems.  Postgres and IBM DB2 use them directly. 
> That's what the Go SQL interface should be returning 
> on an error. MySQL has different codes, but there's a translation 
> table at 
>
>
> http://dev.mysql.com/doc/refman/5.7/en/connector-j-reference-error-sqlstates.html
>  
>
>  SQLite also has its own set of codes, and those too 
> should be translated. 
>
>  The "error" type returned by SQL packages should have 
> a Sqlstate() function to return the system-independent error 
> code, and perhaps a function to return the system-dependent 
> error code.  Losing that information is unacceptable for 
> any serious database work. 
>
> John Nagle 
>
> On 6/11/2013 12:07 AM, Julien Schmidt wrote: 
> > Giving this another thought, this would be an race condition. 
> > But the chance might be very low that someone other registers another 
> > account with this id in the meantime. I think I would risk to let the 
> > registration fail in such a case. 
> > 
> > On Tuesday, June 11, 2013 9:01:58 AM UTC+2, Julien Schmidt wrote: 
> >> 
> >> In such a case I would make another query to check for an existing 
> account 
> >> with that id before even trying to insert the new account data. 
> >> 
> >> Something like this should work: 
> >> 
> >> var duplicate bool 
> >> err := db.QueryRow("SELECT 1 FROM users WHERE id = ? LIMIT 1", 
> >> id).Scan() 
> >> 
> >> On Sunday, June 9, 2013 9:34:20 AM UTC+2, Jochen Voss wrote: 
> >>> 
> >>> Dear Andy, 
> >>> 
> >>> Many thanks for your answer. 
> >>> 
> >>> On Sunday, 9 June 2013 01:17:06 UTC+2, Andy Balholm wrote: 
>  
>  The errors are specific to the database backend. At least some 
> backends 
>  define their own error type; for example 
>  http://godoc.org/github.com/lib/pq#PGError . So use a type assertion 
> or 
>  type switch on the error; if it is the backend's database error type, 
> check 
>  to see if it is the specific kind of error that you're looking for. 
> >>> 
> >>> 
> >>> This sounds painful!  Are libraries using sql databases then forced to 
> be 
> >>> backend specific (if they do error handling)? 
> >>> 
> >>> What I'm trying to do is to implement an account system, which stores 
> >>> user information in a database.  When somebody tries to add a new 
> account, 
> >>> I need to tell apart duplicate user names from other problems (like 
> the DB 
> >>> server being down, the table not existing, etc.)  It would be great if 
> >>> there was a backend-independent way of doing this. 
> >>> 
> >>> Many thanks, 
> >>> Jochen 
> >>> 
> >>> 
> > 
>
>
>
>

-- 
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] Go beginner asks for code review

[Sam Whited]

On Thu, Sep 22, 2016 at 10:48 AM, Leandro Motta Barros 
wrote:
> I wonder if anyone would be willing to take a look at it, and give some
> advice on how to be more idiomatic or improve it somehow.

Not sure how to do this on GitHub if it's not a PR, I don't appear to be
able to leave line-level comments on the source, so I've inlined it. Sorry
for all the missing context. That being said, here are a few things I
noticed:

> parser := {}
> parser.input = document
> parser.processor = processor
> parser.frag = parser.input
> parser.fragEnd = 0
> parser.textStyle = TextStyleRegular
> parser.linkTarget = ""
> parser.linkTargetLen = 0

This could be much more cleanly written with all the fields in the struct
literal, eg. the idiomatic way to write this would be:

> parser := {
>input: document,
>processor: processor,
>frag: document,
>textStyle: TextStyleRegular,
> }

Also, don't forget that in Go all structs are initialized, so eg.
linkTargetLen and linkTarget which are 0 and the empty string respectively
dont need to be initialized at all since the zero value of an numeric type
is 0 and the zero value for a string is "".

Finally, be careful, doing parser := {} is shadowing the struct
parser which may (or may not) be what you want.

> p.processor.OnStartDocument()

This is of course completely up to you, but it's idiomatic to just call
something like this "StartDocument", the "On" is normally elided.

> github.com/lmbarros/sbxs_go_markydown/markydown

The package would normally just live at the repo root in go; unless you're
expecting other subpackages to live in this repo. Right now I'd have to:

import "github.com/lmbarros/sbxs_go_markydown/markydown"

but it might read better if I could just import:

import "github.com/lmbarros/go_markydown"

(you can also leave the go_ off if this will be the only thing called
markydown on your GitHub account)

if len(p.input) == 0 {
return false
}
// Try parsing each of the "special" paragraph types.
if p.parseHeading() {
return true
}
if p.parseBulletedParagraph() {
return true
}

some people prefer to write long chains of I




-- 
Sam Whited
pub 4096R/54083AE104EA7AD3

-- 
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] Go beginner asks for code review

[Sam Whited]

On Thu, Sep 22, 2016 at 10:48 AM, Leandro Motta Barros
 wrote:
> I hope this is not considered off-topic: I have started learning Go a few
> weeks ago, and have recently finished writing my first sizable piece of Go
> code.

Not at all; welcome to the Go community, and congrats on your first
big project! I'm sure you'll get lots of feedback, and please,
continue to ask questions and avail yourself of this list, it's a
great resource if you're just starting out.

Best,
Sam


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3

-- 
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: Request for advice: Developing for Android

[Peter Kleiweg]

Op donderdag 22 september 2016 18:28:43 UTC+2 schreef Peter Kleiweg:
>
> Op donderdag 22 september 2016 18:08:10 UTC+2 schreef Elias Naur:
>>
>>
>>
>> On Thursday, September 22, 2016 at 5:34:24 PM UTC+2, Peter Kleiweg wrote:
>>>
>>> I try the examples on  https://github.com/golang/go/wiki/Mobile
>>>
>>> Native applications -> Building and deploying to Android works fine.
>>>
>>> On "SDK applications and generating bindings" I get into problems.
>>>
>>> It says: 
>>>
>>> go get -d golang.org/x/mobile/example/bind/...
>>>
>>> I get:
>>>
>>> warning: "golang.org/x/mobile/example/bind/..." matched no packages
>>> can't load package: package golang.org/x/mobile/example: no 
>>> buildable Go source files in /home/peter/go/src/
>>> golang.org/x/mobile/example
>>>
>>>
>> That's odd, and it should definitely work. With Go 1.7.1 and after 
>> removing my existing $GOPATH/golang.org directory out of the way, running
>>
>> $ go get -d golang.org/x/mobile/example/bind/. 
>> ..
>>
>> outputs no error and downloads golang.org/x/mobile just fine. Which 
>> version of Go are you using? Regardless of this issue, I recommend 1.7.1 
>> because it contains fixes for several issues on mobiles, in particular iOS.
>>
>
> (peter) ~ go version
> go version go1.7.1 linux/amd64
> (peter) ~ go env
> GOARCH="amd64"
> GOBIN=""
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOOS="linux"
> GOPATH="/home/peter/go"
> GORACE=""
> GOROOT="/my/opt/go"
> GOTOOLDIR="/my/opt/go/pkg/tool/linux_amd64"
> CC="gcc"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=/tmp/go-build429704933=/tmp/go-build 
> -gno-record-gcc-switches"
> CXX="g++"
> CGO_ENABLED="1"
> (peter) ~ go get -v -u -d golang.org/x/mobile/example/bind/...
> Fetching https://golang.org/x/mobile/example/bind?go-get=1
> Parsing meta tags from 
> https://golang.org/x/mobile/example/bind?go-get=1 (status code 200)
> get "golang.org/x/mobile/example/bind": found meta tag 
> main.metaImport{Prefix:"golang.org/x/mobile", VCS:"git", RepoRoot:"
> https://go.googlesource.com/mobile"} at 
> https://golang.org/x/mobile/example/bind?go-get=1
> get "golang.org/x/mobile/example/bind": verifying non-authoritative 
> meta tag
> Fetching https://golang.org/x/mobile?go-get=1
> Parsing meta tags from https://golang.org/x/mobile?go-get=1 (status 
> code 200)
> golang.org/x/mobile (download)
> warning: "golang.org/x/mobile/example/bind/..." matched no packages
> can't load package: package .: no buildable Go source files in 
> /home/peter
>

When I do this first, it works:

rm -fr $GOPATH/src/golang.org/x/mobile

 

-- 
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: Request for advice: Developing for Android

[Peter Kleiweg]

Op donderdag 22 september 2016 18:08:10 UTC+2 schreef Elias Naur:
>
>
>
> On Thursday, September 22, 2016 at 5:34:24 PM UTC+2, Peter Kleiweg wrote:
>>
>> I try the examples on  https://github.com/golang/go/wiki/Mobile
>>
>> Native applications -> Building and deploying to Android works fine.
>>
>> On "SDK applications and generating bindings" I get into problems.
>>
>> It says: 
>>
>> go get -d golang.org/x/mobile/example/bind/...
>>
>> I get:
>>
>> warning: "golang.org/x/mobile/example/bind/..." matched no packages
>> can't load package: package golang.org/x/mobile/example: no 
>> buildable Go source files in /home/peter/go/src/
>> golang.org/x/mobile/example
>>
>>
> That's odd, and it should definitely work. With Go 1.7.1 and after 
> removing my existing $GOPATH/golang.org directory out of the way, running
>
> $ go get -d golang.org/x/mobile/example/bind/. 
> ..
>
> outputs no error and downloads golang.org/x/mobile just fine. Which 
> version of Go are you using? Regardless of this issue, I recommend 1.7.1 
> because it contains fixes for several issues on mobiles, in particular iOS.
>

(peter) ~ go version
go version go1.7.1 linux/amd64
(peter) ~ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/peter/go"
GORACE=""
GOROOT="/my/opt/go"
GOTOOLDIR="/my/opt/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build429704933=/tmp/go-build 
-gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
(peter) ~ go get -v -u -d golang.org/x/mobile/example/bind/...
Fetching https://golang.org/x/mobile/example/bind?go-get=1
Parsing meta tags from 
https://golang.org/x/mobile/example/bind?go-get=1 (status code 200)
get "golang.org/x/mobile/example/bind": found meta tag 
main.metaImport{Prefix:"golang.org/x/mobile", VCS:"git", 
RepoRoot:"https://go.googlesource.com/mobile"} at 
https://golang.org/x/mobile/example/bind?go-get=1
get "golang.org/x/mobile/example/bind": verifying non-authoritative 
meta tag
Fetching https://golang.org/x/mobile?go-get=1
Parsing meta tags from https://golang.org/x/mobile?go-get=1 (status 
code 200)
golang.org/x/mobile (download)
warning: "golang.org/x/mobile/example/bind/..." matched no packages
can't load package: package .: no buildable Go source files in 
/home/peter

-- 
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: Request for advice: Developing for Android

[Elias Naur]

On Thursday, September 22, 2016 at 5:34:24 PM UTC+2, Peter Kleiweg wrote:
>
> I try the examples on  https://github.com/golang/go/wiki/Mobile
>
> Native applications -> Building and deploying to Android works fine.
>
> On "SDK applications and generating bindings" I get into problems.
>
> It says: 
>
> go get -d golang.org/x/mobile/example/bind/...
>
> I get:
>
> warning: "golang.org/x/mobile/example/bind/..." matched no packages
> can't load package: package golang.org/x/mobile/example: no buildable 
> Go source files in /home/peter/go/src/golang.org/x/mobile/example
>
>
That's odd, and it should definitely work. With Go 1.7.1 and after removing 
my existing $GOPATH/golang.org directory out of the way, running

$ go get -d golang.org/x/mobile/example/bind/. 
..

outputs no error and downloads golang.org/x/mobile just fine. Which version 
of Go are you using? Regardless of this issue, I recommend 1.7.1 because it 
contains fixes for several issues on mobiles, in particular iOS.

 

> But this works:
>
> go get -d github.com/golang/mobile/example/bind/...
>
> But then building in Studio fails.
>
> I edit example/bind/android/hello/build.gradle to set GO and GOPATH, and I 
> change pkg from "golang.org/x/mobile/example/bind/hello" to "
> github.com/golang/mobile/example/bind/hello"
>
> When I do Build -> Make Project, I get:
>
> Executing tasks: [clean, :app:generateDebugSources, 
> :app:mockableAndroidJar, :app:prepareDebugUnitTestDependencies, 
> :app:generateDebugAndroidTestSources, :app:compileDebugSources, 
> :app:compileDebugUnitTestSources, :app:compileDebugAndroidTestSources]
>
> Configuration on demand is an incubating feature.
> Incremental java compilation is an incubating feature.
> :app:clean
> :hello:clean UP-TO-DATE
> :app:preBuild UP-TO-DATE
> :app:preDebugBuild UP-TO-DATE
> :app:checkDebugManifest
> :app:preReleaseBuild UP-TO-DATE
> :hello:gobind
> :app:prepareAndroidHelloUnspecifiedLibrary
> :app:prepareComAndroidSupportAppcompatV72211Library
> :app:prepareComAndroidSupportSupportV42211Library
> :app:prepareDebugDependencies
> :app:compileDebugAidl
> :app:compileDebugRenderscript
> :app:generateDebugBuildConfig
> :app:generateDebugResValues
> :app:generateDebugResources
> :app:mergeDebugResources
> :app:processDebugManifest
> :app:processDebugResources
> :app:generateDebugSources
> :app:mockableAndroidJar UP-TO-DATE
> :app:preDebugUnitTestBuild UP-TO-DATE
> :app:prepareDebugUnitTestDependencies
> :app:preDebugAndroidTestBuild UP-TO-DATE
> :app:prepareDebugAndroidTestDependencies
> :app:compileDebugAndroidTestAidl
> :app:processDebugAndroidTestManifest
> :app:compileDebugAndroidTestRenderscript
> :app:generateDebugAndroidTestBuildConfig
> :app:generateDebugAndroidTestResValues
> :app:generateDebugAndroidTestResources
> :app:mergeDebugAndroidTestResources
> :app:processDebugAndroidTestResources
> :app:generateDebugAndroidTestSources
> :app:incrementalDebugJavaCompilationSafeguard
> :app:compileDebugJavaWithJavac
> :app:compileDebugJavaWithJavac - is not incremental (e.g. outputs have 
> changed, no previous execution, etc.).
> 
> /home/peter/go/src/
> github.com/golang/mobile/example/bind/android/app/src/main/java/org/golang/example/bind/MainActivity.java:27:
>  
> error: cannot find symbol
> String greetings = Hello.Greetings("Android and Gopher");
> ^
>   symbol:   method Greetings(String)
>   location: class Hello
> 1 error
> 
> :app:compileDebugJavaWithJavac FAILED
>
>
>
>

Java methods names were recently changed to lowercase, but the examples 
weren't updated. That's unfortunate, but thank you for reporting. FWIW, 
I've mailed https://go-review.googlesource.com/c/29594/ to fix the two 
examples and to comment out the GO, GOMOBILE and GOPATH settings from the 
build.gradle file. They're more confusing than helpful.

  - elias

-- 
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 beginner asks for code review

[Leandro Motta Barros]

Hello,

I hope this is not considered off-topic: I have started learning Go a few
weeks ago, and have recently finished writing my first sizable piece of Go
code.

I wonder if anyone would be willing to take a look at it, and give some
advice on how to be more idiomatic or improve it somehow. Any feedback is
welcome! :-)

The code is a hand-written parser for a subset of Markdown, and can be
found here: https://github.com/lmbarros/sbxs_go_markydown

Function Parse() on parser.go (
https://github.com/lmbarros/sbxs_go_markydown/blob/master/markydown/parser.go#L7
) is the main entry point for this code.

Thanks a lot!

LMB

-- 
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] Wordbreak and word extraction in Go?

[mpvl]

Hi Ingo,

Thanks for your interest in x/text!  Text segmentation is high on the
priority list for x/text, but not yet implemented. Indeed, x/text/cases
implements a (close) approximation of Annex #29 optimized for title casing,
but it is not the full thing.

For now, if your main interest is word segmentation, your best bet is to
use github.com/blevesearch/segment. This is a decent implementation of
Annex #29 for word breaking. I've been talking with Marty to see if this
can be integrated with x/text even.

But it would help to file an issue with exactly what you need.

Please let me know if you have any other questions.

Best regards,

Marcel


On Wed, Sep 21, 2016 at 5:41 AM, Nigel Tao  wrote:

> On Wed, Sep 21, 2016 at 7:34 AM, 'Ingo Oeser' via golang-nuts
>  wrote:
> > I am pretty sure I am overlooking something in the repository
> https://godoc.org/golang.org/x/text but I cannot find something to split
> text into words according to the next Unicode word splitting algorithm.
> >
> > Has anyone examples or can point me to the right direction? Can anyone
> confirm that this is missing? If missing, I would like to file an issue
> against the text repository for this.
>
> I'd ask mpvl (CC'ed).
>

-- 
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: Request for advice: Developing for Android

[Peter Kleiweg]

I try the examples on  https://github.com/golang/go/wiki/Mobile

Native applications -> Building and deploying to Android works fine.

On "SDK applications and generating bindings" I get into problems.

It says: 

go get -d golang.org/x/mobile/example/bind/...

I get:

warning: "golang.org/x/mobile/example/bind/..." matched no packages
can't load package: package golang.org/x/mobile/example: no buildable 
Go source files in /home/peter/go/src/golang.org/x/mobile/example

But this works:

go get -d github.com/golang/mobile/example/bind/...

But then building in Studio fails.

I edit example/bind/android/hello/build.gradle to set GO and GOPATH, and I 
change pkg from "golang.org/x/mobile/example/bind/hello" to 
"github.com/golang/mobile/example/bind/hello"

When I do Build -> Make Project, I get:

Executing tasks: [clean, :app:generateDebugSources, 
:app:mockableAndroidJar, :app:prepareDebugUnitTestDependencies, 
:app:generateDebugAndroidTestSources, :app:compileDebugSources, 
:app:compileDebugUnitTestSources, :app:compileDebugAndroidTestSources]

Configuration on demand is an incubating feature.
Incremental java compilation is an incubating feature.
:app:clean
:hello:clean UP-TO-DATE
:app:preBuild UP-TO-DATE
:app:preDebugBuild UP-TO-DATE
:app:checkDebugManifest
:app:preReleaseBuild UP-TO-DATE
:hello:gobind
:app:prepareAndroidHelloUnspecifiedLibrary
:app:prepareComAndroidSupportAppcompatV72211Library
:app:prepareComAndroidSupportSupportV42211Library
:app:prepareDebugDependencies
:app:compileDebugAidl
:app:compileDebugRenderscript
:app:generateDebugBuildConfig
:app:generateDebugResValues
:app:generateDebugResources
:app:mergeDebugResources
:app:processDebugManifest
:app:processDebugResources
:app:generateDebugSources
:app:mockableAndroidJar UP-TO-DATE
:app:preDebugUnitTestBuild UP-TO-DATE
:app:prepareDebugUnitTestDependencies
:app:preDebugAndroidTestBuild UP-TO-DATE
:app:prepareDebugAndroidTestDependencies
:app:compileDebugAndroidTestAidl
:app:processDebugAndroidTestManifest
:app:compileDebugAndroidTestRenderscript
:app:generateDebugAndroidTestBuildConfig
:app:generateDebugAndroidTestResValues
:app:generateDebugAndroidTestResources
:app:mergeDebugAndroidTestResources
:app:processDebugAndroidTestResources
:app:generateDebugAndroidTestSources
:app:incrementalDebugJavaCompilationSafeguard
:app:compileDebugJavaWithJavac
:app:compileDebugJavaWithJavac - is not incremental (e.g. outputs have 
changed, no previous execution, etc.).


/home/peter/go/src/github.com/golang/mobile/example/bind/android/app/src/main/java/org/golang/example/bind/MainActivity.java:27:
 
error: cannot find symbol
String greetings = Hello.Greetings("Android and Gopher");
^
  symbol:   method Greetings(String)
  location: class Hello
1 error

:app:compileDebugJavaWithJavac FAILED



-- 
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] TradeRev is hosting free 3-day GoLang Training Session for Toronto Developers

[Stella Karami]

 

TradeRev, a revolutionary vehicle appraisal and auctioning app, is inviting 
you to a FREE 3-day GoLang training session from October 12th to the 14th. 
Interested applicants can apply here 

.

 

As a tech innovator, TradeRev is committed to helping Toronto stay at the 
forefront of innovation by offering a chance for developers in the GTA to 
learn the Go programming language from renowned developer, William Kennedy.

 

*Agenda*

 

This is a three-day class for intermediate-level developers who have some 
experience with other programming languages. The class provides an 
intensive, comprehensive and idiomatic view of the language.

 

Students will learn:

 

·   A strong understanding of the language syntax and implementation.

·   A feel for writing code in an idiomatic style and syntax.

·   Walk away with patterns and techniques for solving common problems

 

If you have any questions or would like further information, please contact 
Luiz at gol...@traderev.com. 

 

Breakfast and lunch will be provided.

 

Remember, the deadline to apply is *Friday September 30th.*

 

Can’t wait to see you there!

-- 
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] Several issues on macOS Sierra

[martin]

Hello,

Since upgrading to macOS Sierra, I've stumbled upon a few issues that were 
not present when using OSX El Capitan.

All issues arise when using this package 
https://github.com/jteeuwen/go-bindata however from my cursory glance 
there's nothing specific about that code that seems troublesome.

Stack traces for the issues I've stumbled on are below - I can't reliably 
reproduce them and I haven't been able to create a minimal test case to 
reproduce it either. Sometimes it works, sometimes it doesn't. However I 
can say that it panics more often than not.

Specs:
Go 1.7.1
MacBook Pro Retina , 16GB RAM, 2.3 GHz Intel Core i7

I've changed my working directory to say "GOROOT" in the pastebins - but 
there's nothing special about that path. Just my home working directory. 
Also the script to invoke go-bindata, generate_models.sh, is bare bones and 
just invoked the binary ./bin/go-bindata/ several times, one after another. 
I can post that, too, but I don't think it'll be very helpful because again 
- this all used to work.

Stack trace 1:
http://pastebin.com/X8Zv7Hy8

Stack trace 2:
This one has the same panic as #1 but also has an issue with entersyscall
http://pastebin.com/MzFuaVCe

I know I'm a bit light on details here but I'm hoping a core Go dev might 
see these stack traces and know what's up.

Please let me know what other info I can produce to help track the issue 
down.

-- 
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] bitcoin golang

[Anonymous]

Bonjour je voudrais savoir si le code directory.io serait modifiable pour 
n'afficher que des adresses commençant par 1LE ?

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