[go-nuts] Re: cgo long double

Thanks Ian. I have submitted issue 28069 along with the simplest example I could figure out. I found that the behaviour is triggered when a long double is nested in an inner field of a struct; moving the long double to the outer field of the struct lets the go build complete successfully.

Re: [go-nuts] Traverse directory without infinite loops while following symlinks

On 8 October 2018 at 08:53, Rob Pike wrote: > Actually the original is a paper: > https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf > The book came later and is substantially different although not > contradictory. Channels were not in the paper and without channels (such as > in Occam) the

Re: [go-nuts] Traverse directory without infinite loops while following symlinks

No, I was thinking of Occam but being wrong. -rob On Mon, Oct 8, 2018 at 9:52 PM roger peppe wrote: > On 8 October 2018 at 08:53, Rob Pike wrote: > > Actually the original is a paper: > > https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf > > The book came later and is substantially different

Re: [go-nuts] Why is the method net.PacketConn.ReadFrom named as that? Isn't ReadInto more natural?

On Sunday, October 7, 2018 at 11:05:54 PM UTC-4, Ian Lance Taylor wrote: > > The net package's ReadFrom method is named ReadFrom because it is > implemented by the recvfrom system call. Perhaps it was a poor choice > of name in Go, but that is where it comes from. > > Ian > Thanks for the

Re: [go-nuts] go:nosplit

On Mon, Oct 8, 2018 at 1:50 PM Scott Cotton wrote: > However, I wanted to state that if the language doesn't specify this, and the language also doesn't specify what sys-calls are used on what platforms in what circumstances, then one can readily conclude that any Go program that relies on

Re: [go-nuts] go:nosplit

On Monday, 8 October 2018 06:02:13 UTC+2, Ian Lance Taylor wrote: > > On Fri, Oct 5, 2018 at 11:57 PM, Scott Cotton > wrote: > > > > On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor > wrote: > >> > >> On Fri, Oct 5, 2018 at 2:10 PM, Scott Cotton > wrote: > > > > > >> > >> In fact > >>

Re: [go-nuts] Error Handling Best Practice (error wrapping)

Yes, lobby to have Go2 include exceptions and then you don’t need to worry about any of this... :) > On Oct 8, 2018, at 5:38 AM, Chris Hopkins wrote: > > Hi, > Could I please check what current error handling best practice is? > I've gotten quite smitten with github.com/pkg/errors. I really

Re: [go-nuts] go:nosplit

Thanks, This doesn't however really address what I was pointing out. Maybe I was too vague, let me try to clarify. Suppose you are working on an operating system port of something and you use sys calls. You check the syscall package, the OS docs, and you need to execute a sequence of sys

[go-nuts] go/types: Why does type check fail with custom importer?

I'm now developing software to resolve types using go/types package. In order to resolve to go modules dependencies, it uses a custom importer using `golang.org/x/tools/go/packages`. (Ref: https://github.com/mdempsky/gocode/issues/46#issuecomment-417950836) This will work correctly in many

Re: [go-nuts] go:nosplit

On Mon, Oct 8, 2018 at 4:50 AM, Scott Cotton wrote: > > On Monday, 8 October 2018 06:02:13 UTC+2, Ian Lance Taylor wrote: >> >> On Fri, Oct 5, 2018 at 11:57 PM, Scott Cotton wrote: >> > >> > On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor wrote: >> >> >> >> On Fri, Oct 5, 2018 at 2:10 PM, Scott

[go-nuts] Re: Announcing a Fyne GUI toolkit

Hi There, I tried it to test it. But i am getting the below error : # pkg-config --cflags -- eina evas ecore-evas ecore-evas ecore-input ecore ecore-evas eina evas ecore-evas ecore-input ecore evas ecore ecore-evas ecore-input evas Package eina was not found in the pkg-config search path.

Re: [go-nuts] Error Handling Best Practice (error wrapping)

On Mon, Oct 8, 2018 at 3:38 AM, Chris Hopkins wrote: > Hi, > Could I please check what current error handling best practice is? > I've gotten quite smitten with github.com/pkg/errors. I really like the > ability to create a stack of errors that trace to what is going on. However > it seems this

Re: [go-nuts] Error Handling Best Practice (error wrapping)

Thanks. Yes, that's exactly what I want, could I have Go2 now please? ;-) Okay I'll keep doing it the way I'm doing it with a mind to swapping to that when available. I had avoided reading the Go2 proposal stuff simply because I regard language design as a question for people with Marvin-like

Re: [go-nuts] Traverse directory without infinite loops while following symlinks

I was wrong too. Though I’m now puzzled about the UCLA book. It’s in my library. Will look. On Mon, Oct 8, 2018 at 4:06 AM Rob Pike wrote: > No, I was thinking of Occam but being wrong. > > -rob > > > On Mon, Oct 8, 2018 at 9:52 PM roger peppe wrote: > >> On 8 October 2018 at 08:53, Rob Pike

Re: [go-nuts] Error Handling Best Practice (error wrapping)

I read the proposal and the only knock against including a stack trace by default is one google problem cited that was clearly bad error handling to begin with. Why is there always some need to reinvent the wheel. Leave Go error handling as in and add a throws and catch that new code can use,

Re: [go-nuts] Error Handling Best Practice (error wrapping)

Note that the check/handle proposal has largely prompted counter-proposals and critique... https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback So I'd guess that the final product will look rather different :-) On Monday, October 8, 2018 at 7:54:54 AM UTC-7, Chris Hopkins wrote: > >

Re: [go-nuts] Error Handling Best Practice (error wrapping)

The Go designers considered and discarded exceptions for common errors, then added panic/recover for truly exceptional circumstance. There are known problems with try/catch: https://en.wikipedia.org/wiki/Exception_handling#Criticism I've posted a comprehensive list of "possible requirements"

Re: [go-nuts] `go mod download -json` does not product valid json?

Thanks for the reply. I'm decoding successfully now. On Sunday, 7 October 2018 21:19:47 UTC+1, Paul Jolly wrote: > > > It looks like it is a stream of JSON objects? > > > > If so, I suspect this is expected? > > Per the issue you linked, thepudds, absolutely correct. > > This comment gives

Re: [go-nuts] go:nosplit

On Mon, 8 Oct 2018 at 16:30, Ian Lance Taylor wrote: > On Mon, Oct 8, 2018 at 4:50 AM, Scott Cotton wrote: > Your real concern > has to do with running audio code without interruption. That concern, > too, is abstract. We don't know how well it works today and we don't > know how well it

[go-nuts] How to resolve go lang dependencies from enterprise repository

I have built and published the go dependencies to our enterprise artifactory. Is there an efficient way to get the files from artifactory and use them in test runs? My dependencies are in jfrog artifactory. They appear like the following: go-local/github.com/davecgh/go-spew/@v/v1.1.1.zip

[go-nuts] The benefits and costs of writing a POSIX kernel in a high-level language

I do not think this has been shared yet, please accept my apologies if this is a repeat. https://www.usenix.org/conference/osdi18/presentation/cutler The paper contributes Biscuit, a kernel written in Go that implements enough of POSIX (virtual memory, mmap, TCP/IP sockets, a logging file

Re: [go-nuts] Error Handling Best Practice (error wrapping)

That is uncalled for. Dan On Mon, 2018-10-08 at 20:20 -0500, robert engels wrote: > I don’t think denigrating the most obvious advancement in computer > software in the last 20 years helps move things forward. > > But to each his own, just please don’t work on anything with critical > safety

Re: [go-nuts] Error Handling Best Practice (error wrapping)

This is relevant here again. > The European Commission has just announced an agreement whereby > English will be the official language of the European Union rather > than German, which was the other possibility.  > > As part of the negotiations, the British Government conceded that > English

Re: [go-nuts] Error Handling Best Practice (error wrapping)

I was only speaking for James Gosling. Engineering is balancing trade offs, which usually entails choosing the proper tools and processes for the task at hand. There are no silver bullets and taking positions that hinge on them is a fools errand. Sent from my iPhone > On Oct 8, 2018, at

[go-nuts] Re: Announcing a Fyne GUI toolkit

Just wanted to drop in and say that I'm very impressed with the design and quality of the examples I've seen. Great work, and thanks for sharing! On Friday, September 14, 2018 at 5:17:00 PM UTC, Andrew Williams wrote: > > Hi, > > Some time ago I realised that Go was a great language for

Re: [go-nuts] Where are the dependencies saved when we use go mod

> Where is the dependent github.com/stretchr/testify/assert downloaded - I dont > see it downloaded any where. it still download physically, it's under $GOPATH/pkg/mod On Mon, Oct 8, 2018 at 5:55 PM pprasanthi via golang-nuts wrote: > > I followed below steps to run tests in go mod. In this

Re: [go-nuts] Where are the dependencies saved when we use go mod

Got it, Thanks Wagner. I did not set GOPATH since I was using GO111MODULE=on. Since I did not use GOPATH I was having a doubt about its physical presence. But I found in the go root /Users/xxx/go/pkg/mod/cache Thanks Again. On Monday, October 8, 2018 at 2:21:00 PM UTC-7, Wagner Riffel

Re: [go-nuts] Re: splitting package question

As i test go compiler remove unused functions (i'm not try to check compile time, but resulted binary size not changed after i merge all formats in single package). сб, 6 окт. 2018 г. в 19:31, T L : > > You can make some tests to check the final binary sizes, which will not spend > you much time.

Re: [go-nuts] Error Handling Best Practice (error wrapping)

I don’t think denigrating the most obvious advancement in computer software in the last 20 years helps move things forward. But to each his own, just please don’t work on anything with critical safety issues please. Thanks for your understanding. > On Oct 8, 2018, at 4:03 PM, Dan Kortschak >

[go-nuts] Where are the dependencies saved when we use go mod

I followed below steps to run tests in go mod. In this process I had few questions that needs clarification. 1. cd /tmp/gomodtry/tests/src/hello/hello_test.go package tests import ( “github.com/stretchr/testify/assert” “os” “testing” ) func GetEnv(key string, fallback string) string {

[go-nuts] Get dependency from enterprise repository

I have built and published the go dependencies to our enterprise artifactory. Is there an efficient way to get the files from artifactory and use them in test runs? My dependencies are in jfrog artifactory. They appear like the following: go-local/github.com/davecgh/go-spew/@v/v1.1.1.zip

Re: [go-nuts] Error Handling Best Practice (error wrapping)

On Mon, 8 Oct 2018 08:04:46 -0500 Robert Engels wrote: > Yes, lobby to have Go2 include exceptions and then you don’t need to worry > about any of this... :) You only will worry about thousands of things that your predecessors thrown at you just because "the schedule was tight". Is it right

[go-nuts] [Go2] rename "Error" to "Fail" in Go2

While we are at errors, I think that the most consequential error of Go1 spec was Error, the name. Had the expected wrongs were named correctly as Fails I would be happy; and some others would likely be happier too. Just a fleeting thought. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE --

Re: [go-nuts] Error Handling Best Practice (error wrapping)

OK, I'll have to accept that. However, in your reply that I responded to you wrote: > But to each his own, just please don’t work on anything with critical > safety issues please. Thanks for your understanding. This was rude. Further, to explain my original post. It is a joke talking about

Re: [go-nuts] Error Handling Best Practice (error wrapping)

One other thing. I’ll say it again. Go is an amazing piece of technology and it is awesome for many type of applications. I think the “fracturing” that may be occurring is because people are using it in cases it is not well suited and they are running into walls, thus the need to add in

Re: [go-nuts] Error Handling Best Practice (error wrapping)

I’m sorry you feel that way. None of my comments on Go were intended to be abrasive, they were intended to be matter of fact. You are mistaken as well if you think I was proposing exceptions as any sort of silver bullet. They address the exact concerns the OP had. Exceptions also come with

Re: [go-nuts] Error Handling Best Practice (error wrapping)

Let's please all drop this thread. Thanks. Chris, sorry this got derailed. If you want to follow up on something please start a new thread. Thanks. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

[go-nuts] UDPConn.ReadFromUDP blocked in syscall when underlying socket option is set

Hi, I have a program need to create large number of listening UDPConn, basically around 30k, each UDPConn will run in its own go routine waiting incoming packets, so that's 30k go routines, however I hit the wall of 1 system threads limitation; after search around, I found it is because I

Re: [go-nuts] The benefits and costs of writing a POSIX kernel in a high-level language

This is really interesting! I have only viewed the slideshow quickly, and have no idea how applicable it would be, but there are projects for getting Go to run on bare-metal: https://www.youtube.com/watch?v=8T3VxGrrJwc if that could be combined or leveraged to run Biscuit, a POSIX kernel 100%

Re: [go-nuts] Error Handling Best Practice (error wrapping)

I don’t think any of hat is true. Java has exceptions, it is highly concurrent and it is very efficient. I just think that by the time yo get all of the “features” into Go error handling that it needs for both reliability, debugging, etc., you are going to end up with “exceptions” just with a

[go-nuts] [ANN] Golem: A general purpose, interpreted scripting language

This is the initial announcement for Golem. Golem is a general purpose, interpreted scripting language, that brings together ideas from many other languages, including Go, Python, Javascript and Lua. Golem can be used as a command-line application, or it can be easily embedded inside a Go

Re: [go-nuts] Error Handling Best Practice (error wrapping)

{initial long rabley post deleted} If I understand the exception proposals, they are quite un-go-like. That is go as a strongly typed, "no undeclared variables", etc language sits on the side of more effort upfront to produce fewer bugs later trade-off. Try ... catch however is more of the

Re: [go-nuts] Strange behavior of range over composite literal.

Thanks for the answers. I tried to read the specs, but didn't go as far as the parsing ambiguity section :( -- Raffaele On Mon, Oct 8, 2018 at 12:20 PM Ian Lance Taylor wrote: > On Mon, Oct 8, 2018 at 12:10 PM, Raffaele Sena wrote: > > > > I found a strange behavior (well, I would call it a

Re: [go-nuts] Traverse directory without infinite loops while following symlinks

On Mon, 08 Oct 2018 11:51:59 +0100 roger peppe wrote: > On 8 October 2018 at 08:53, Rob Pike wrote: > > Actually the original is a paper: > > https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf > > The book came later and is substantially different although not > > contradictory. Channels were not

[go-nuts] Strange behavior of range over composite literal.

I found a strange behavior (well, I would call it a bug) of for-range over a composite literal where the literal type is a user type (or alias). This is true for both maps and array/slices, but the following example is with a slice. My guess is that at the compiler level the for-range statement

Re: [go-nuts] Strange behavior of range over composite literal.

On Mon, Oct 8, 2018 at 12:10 PM, Raffaele Sena wrote: > > I found a strange behavior (well, I would call it a bug) of for-range over a > composite literal where the literal type is a user type (or alias). This is > true for both maps and array/slices, but the following example is with a > slice.

Re: [go-nuts] Strange behavior of range over composite literal.

On Mon, Oct 8, 2018 at 9:10 PM Raffaele Sena wrote: See https://golang.org/ref/spec#Composite_literals A parsing ambiguity arises when a composite literal using the TypeName form of the LiteralType appears as an operand between the keyword and the opening