[go-nuts] idea behind error interface and github.com/pkg/errors

[Dave Cheney]

A minor clarification. An error is any value that implements this interface 

type error interface {
Error() string
}

Functions like errors.New and fmt.Errorf return an error implementation who's 
base type (kind) is a string, but this is an implementation detail, there are 
plenty of other error implementations, like os.PathError to pick just one, 
which are a struct type containing additional details. 

Why the type of errors.New is a string probably extends back to the days before 
go 1 when we had this type

package os

type Error string

(From memory)

Dave

-- 
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] idea behind error interface and github.com/pkg/errors

[Jan Mercl]

Nothing prevents you from including the call stack in the error message.
Especially if you prefer the way how Java error messages look.

I don't.

On Fri, Sep 23, 2016, 08:24 Yulrizka  wrote:

> Hello
>
> I was watching Dave Cheney's presentation in gopher conf and was
> fascinated.
>
> (btw he also wrote a blog post here
> http://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully
> )
>
> In some case, I can relate. For example when I'm working on quite large
> codebase, Sometimes I found errors like
>
> "failed X: io.EOF" and the caller was about 5 level deep. That doesn't
> help and sometimes it require me to trace the code.
>
> Sometimes we also wrap the error message to give more context such as:
>
> " Failed updating x: Failed processing feed: XML lint error: failed
> getting XML: timed out"
>
> But still, sometimes this require me to trace the full stack to find out
> where it was generated.
>
> Which got me to think, what was the design philosophy behind the error
> interface?
> why is there only a string and no call stack?
> How do you usually structure code so that the error message is then
> meaningful?
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

-j

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

[go-nuts] idea behind error interface and github.com/pkg/errors

[Yulrizka]

Hello

I was watching Dave Cheney's presentation in gopher conf and was fascinated.

(btw he also wrote a blog post here 
http://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully)

In some case, I can relate. For example when I'm working on quite large 
codebase, Sometimes I found errors like

"failed X: io.EOF" and the caller was about 5 level deep. That doesn't help 
and sometimes it require me to trace the code.

Sometimes we also wrap the error message to give more context such as:

" Failed updating x: Failed processing feed: XML lint error: failed getting 
XML: timed out"

But still, sometimes this require me to trace the full stack to find out 
where it was generated.

Which got me to think, what was the design philosophy behind the error 
interface? 
why is there only a string and no call stack?
How do you usually structure code so that the error message is then 
meaningful? 
 
Thanks

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

[go-nuts] Re: Trying to understand GOPATH

[Volker Dobler]

There are two parts in your question:

Am Freitag, 23. September 2016 06:13:30 UTC+2 schrieb leon.j...@gmail.com:
>
> [...]
> Do I have to manually symlink /usr/local/go/bin/go to my PATH because the 
> GOPATH docs lead me to believe that GOPATH to need to be set to the 
> directory where my go code is located. 
>

1. Normally you append /usr/local/go/bin to your PATH variable so that you 
can
execute the go command by typing "go" in your terminal instead of having
to type "/usr/local/go/bin/go". This is for your convenience and completely 
unrelated to your Go source code. (Note that no symlinking is done anywhere
and this really not related to anything GOPATH is set to or not set to.)
  

2.

Example of my code directories:
>
> git
> ├── bitbucket
> │   └── demo1
> ├── github
> │   ├── notes
> │   ├── scripts
> │   └── snippets
> ├── github-work
> │   ├── ruby-app1
> │   ├── ruby-app2
> │   └── ruby-app3
> └── gitlab
> ├── javascript-app1
> ├── python-app1
> └── (go-app1)
>
> I'd like to be able to keep this structure the same, but I don't see how 
> this is possible with GOPATH pointing to a single directory. 
>
> What if I want to organize my code by version control location and not by 
> language?
>

The documentation on GOPATH i pretty clear: You do not have any choices,
you must organise your code in one particular way.
GOPATH may point to several distinct directories (GOPATH is a list like 
PATH is),
but this still does not permit your desired code layout as each entry in 
GOPATH
must stick to the convention.

If you really want to keep this layout you can always use the Go compiler 
directly,
typically driven through a Makefile. As you are new to Go this will be a 
_major_
pain for you (it is a major pain for experienced Gophers), maybe even 
undoable.

There is no reason to not put you Go code in a GOPATH and go tool compatible
structure.

V.

-- 
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] How to pass arbitrary typed (int, string, etc) slices to a golang function?

[Dave Cheney]

There are two ways, one is to use reflection, the other would be to use unsafe 
to convert the slice value into another structure then extract the length 
field. 

Assuming that you could write a Len function as you specified, what would you 
do next? What problem are you trying to solve?

-- 
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] How to pass arbitrary typed (int, string, etc) slices to a golang function?

[Lax Clarke]

How would someone create a function like len ?

func Len(s []interface{})   would not work because compiler complains of 
type mismatch if you call it with an integer slice (for example)

Thanks

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

[go-nuts] Trying to understand GOPATH

[leon . johnson]

I'm new to golang, and I'm trying to understand the role of GOPATH. The OS 
X package from https://golang.org/dl/ installs to `/usr/local/go/bin/go`. 

Do I have to manually symlink /usr/local/go/bin/go to my PATH because the 
GOPATH docs lead me to believe that GOPATH to need to be set to the 
directory where my go code is located. 

Example of my code directories:

git
├── bitbucket
│   └── demo1
├── github
│   ├── notes
│   ├── scripts
│   └── snippets
├── github-work
│   ├── ruby-app1
│   ├── ruby-app2
│   └── ruby-app3
└── gitlab
├── javascript-app1
├── python-app1
└── (go-app1)

I'd like to be able to keep this structure the same, but I don't see how 
this is possible with GOPATH pointing to a single directory. 

What if I want to organize my code by version control location and not by 
language?

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

[paraiso . marc]

My advice, unless you need to do some low level stuff with the NDK in C or 
C++ use Java, that's the only viable way to develop for Android.

With Phonegap (html,javascript) you will never take advantage of Android 
SDK widgets and won't be able to write background activities ,and you won't 
really learn Android development. 

Gomobile is not production ready in my opinion, and there is no GUI aside 
from developing your own with OpenGL. 

Java cannot be avoided here.

Le mercredi 21 septembre 2016 16:33:17 UTC+2, Peter Kleiweg a écrit :
>
> I want to start developing for Android, and would like your advice on 
> that: Where to start.
>
> My background is Linux. I have a lot of programming experience. Mainly C 
> and Perl, followed by C and Python, and for the last five years it's mainly 
> Go. I did some Java programming for a few weeks, decades ago, and I didn't 
> like it.
>
> I played around briefly with DroidScript http://droidscript.org/ a while 
> ago, but never used it for anything useful.
>
> My first goal is to get to know Android as a developer, learn its 
> concepts, architecture, possibilities. What I am going to do with it is 
> something I don't know yet, but I don't want to limit myself by using the 
> wrong development platform. So, Android Studio would be the obvious choice. 
> But: Java.
>
> How about Go Mobile? Is that useful as a starting point, or should I try 
> to get to know the system first using Android Studio? What are the 
> capabilities of Go Mobile? Can it do all the stuff a native app can do, 
> system calls, events, graphics, sound, sensors, communications, all that 
> stuff? Can I use all the Java libraries for Android that I assume must be 
> available out there?
>
> Or should I use another platform all together? There seem to be so many. A 
> quick search got me Adobe PhoneGap, Apache Cordova, DroidScript, 
> NativeScript, AppDeck...
>
> (If things can run on iPhone too... I don't care.)
>
> I would like to hear your advice on what you think is the best platform. 
> But what's important too is: does it have good tutorials, that explain 
> concepts and architecture, as well as how to do practical stuff.
>

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

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

[go-nuts] Re: Several issues on macOS Sierra

[martin]

Dave you were right, just had to rebuild the binary.

On Thursday, September 22, 2016 at 4:48:44 PM UTC-4, Dave Cheney wrote:
>
> Sierra broke programs compiled with previous versions of Go. You've 
> probably got an old version of go-bindata in your path, delete that, and 
> run go install -v github.com/jteeuwen/go-bindata/go-bindata
>
> If this line does not return at least one line of output, there is a 
> problem in with your Go installation.
>
> On Friday, 23 September 2016 01:26:30 UTC+10, mar...@repustate.com wrote:
>>
>> 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.

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.

[go-nuts] Re: Several issues on macOS Sierra

[Dave Cheney]

Sierra broke programs compiled with previous versions of Go. You've 
probably got an old version of go-bindata in your path, delete that, and 
run go install -v github.com/jteeuwen/go-bindata/go-bindata

If this line does not return at least one line of output, there is a 
problem in with your Go installation.

On Friday, 23 September 2016 01:26:30 UTC+10, mar...@repustate.com wrote:
>
> 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.

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.

Re: [go-nuts] TCP Client can't dial to server on localhost: network is unreachable.

[Brad Fitzpatrick]

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 <
golang-nuts@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+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: 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: truncate float32 to lesser precision (22 bit mantissa)

[jnc7919]

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

On Wednesday, September 21, 2016 at 10:16:33 PM UTC+1, xiio...@gmail.com 
wrote:
>
> Thanks for those links - I started using a something similar to what is 
> described as Smit's algorithm (Slab method) in the Amy Williams paper. My 
> code us subtly different to that usually given because I check the "back 
> face" intersection first -for an early terminate ; this basically involves 
> swapping x_plane_min and x_plane_max early if v.X<0 .. then looking 
> explicitly for the back plane intersection points first..  as well as being 
> slightly more verbose it seems to have the side effect of avoiding the 
> divide by -0 problem described in the paper. (misses ray parallel to plane, 
> catches adjoining edges) I think my version is sub-optimal but not a 
> priority right now.
>
> I've noticed that the divides in all the "slab" methods could be 
> multiplied out - this which inverts the boundary condition if the divisor 
> was negative, but can be caught using 
>
> if (multiplied_x < undivided_boundary_value) ==(divisor>0)
>
>
> instead of the vanilla.
>
> if (x < boundary_value) 
>
>
> not only does this avoid any division (hurray!), but also reduces the 
> cumulative float errors - the number of operations on both sides of the 
> condition of is roughly equal, rather than being unbalanced with most on 
> one side in the un-premultuplied version.. It's a little more complicated, 
> but divides are, afaik, still slow even on modern hardware, which is 
> something I suspect may be a bottleneck within the function.. I need to 
> bench this.. It may mitigate but doesn't solve the float precision problem.
>
> The second link is a nice optimisation for simd too. Optimisation for this 
> function isn't a big priority for me because I'm primarily using it it get 
> the intersection point for a bounding volume for a "3d texture" (or 
> 'non-sparse voxel array' in other words) - my main routine steps through 
> the voxel grid front to back using a different algorithm.
>
> PBRT looks good - wasn't aware of it - found the pre-publication chapter 
> section 3.9.2 "CONSERVATIVE RAY–BOUNDS INTERSECTIONS" - though I didn't 
> proof read it it looks like it covers using calculated expected errors 
> (deltas) well.
>

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

Re: [go-nuts] WebP encoder

[Aarti Parikh]

Is webp encoding in pure go something that may happen in a future release?


On Thursday, December 1, 2011 at 4:54:09 PM UTC-8, Nigel Tao wrote:
>
> On 2 December 2011 01:51, canop > wrote:
> > Is there somewhere a (complete or partial) implementation of a
> > (lossless) encoder and decoder that could be compatible with weekly
> > (or forkable) ?
>
> http://code.google.com/p/vp8-go/ has a WebP decoder, but only for the
> lossy form. I don't think the bitstream for lossless WebP has been
> finalized.
>
> Doing an encoder is also is on my TODO list, but I haven't had much
> spare time lately.
>
>

-- 
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(&duplicate) 
> >> 
> >> 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{}
> 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 := &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 := &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.