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

[Russtopia]

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%
free of C could be a reality. Wouldn't that be amazing?


On Mon, 8 Oct 2018 at 16:17, andrey mirtchovski 
wrote:

> 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
> system, poll, etc.) to execute significant applications. Biscuit makes
> liberal use of Go's HLL features (closures, channels, maps,
> interfaces, garbage collected heap allocation), which subjectively
> made programming easier. The most challenging puzzle was handling the
> possibility of running out of kernel heap memory; Biscuit benefited
> from the analyzability of Go source to address this challenge.
>
> --
> 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.

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

[Ian Lance Taylor]

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 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] UDPConn.ReadFromUDP blocked in syscall when underlying socket option is set

[Jun Hu]

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 set socket option to use ESPinUDP encap: "syscall.SetsockoptInt(conn_fd, 
syscall.IPPROTO_UDP, 100, 2)" , with the socket option set, each go routine 
is blocked in syscall, thus consuming a lots of system threads:

101 @ 0x47b915 0x47b163 0x47841f 0x49039f 0x4f735b 0x516dba 0x514bad 0x6fd1bf 
0x45c741
#   0x47b914syscall.Syscall6+0x4
/usr/local/go/src/syscall/asm_linux_amd64.s:44
#   0x47b162syscall.recvfrom+0xa2   
/usr/local/go/src/syscall/zsyscall_linux_amd64.go:1648
#   0x47841esyscall.Recvfrom+0xae   
/usr/local/go/src/syscall/syscall_unix.go:262
#   0x49039einternal/poll.(*FD).ReadFrom+0xfe   
/usr/local/go/src/internal/poll/fd_unix.go:215
#   0x4f735anet.(*netFD).readFrom+0x5a  
/usr/local/go/src/net/fd_unix.go:208
#   0x516db9net.(*UDPConn).readFrom+0x69
/usr/local/go/src/net/udpsock_posix.go:47
#   0x514bacnet.(*UDPConn).ReadFromUDP+0x6c 
/usr/local/go/src/net/udpsock.go:109
#   0x6fd1bemain.listensocket+0x3ae 
/root/gowork/src/test/test.go:55


if I don't set the socket option, then number of thread is far less, and go 
routine no longer use syscall:

101 @ 0x42f3cb 0x42a709 0x429db6 0x48f1aa 0x48f2bd 0x490408 0x4f735b 0x516dba 
0x514bad 0x6fd0b7 0x45c741
#   0x429db5internal/poll.runtime_pollWait+0x65 
/usr/local/go/src/runtime/netpoll.go:173
#   0x48f1a9internal/poll.(*pollDesc).wait+0x99 
/usr/local/go/src/internal/poll/fd_poll_runtime.go:85
#   0x48f2bcinternal/poll.(*pollDesc).waitRead+0x3c 
/usr/local/go/src/internal/poll/fd_poll_runtime.go:90
#   0x490407internal/poll.(*FD).ReadFrom+0x167  
/usr/local/go/src/internal/poll/fd_unix.go:219
#   0x4f735anet.(*netFD).readFrom+0x5a  
/usr/local/go/src/net/fd_unix.go:208
#   0x516db9net.(*UDPConn).readFrom+0x69
/usr/local/go/src/net/udpsock_posix.go:47
#   0x514bacnet.(*UDPConn).ReadFromUDP+0x6c 
/usr/local/go/src/net/udpsock.go:109
#   0x6fd0b6main.listensocket+0x2a6 
/root/gowork/src/test/test.go:55


so is there way to use socket option without consume so many system threads?



-- 
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] Error Handling Best Practice (error wrapping)

[Robert Engels]

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 features the original designers left out intentionally, rather than 
deciding that Go is not suitable for this application and use something else.

People get overly invested in tools. Yes, your learning time and job prospects 
make this investment bilateral. Still, if you stop doing engineering and 
instead just use the tool you’ve backed you’re bound to fail. 

Sent from my iPhone

> On Oct 8, 2018, at 11:10 PM, Robert Engels  wrote:
> 
> 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 more structure and “process” which can be a negative in some 
> environments. Thus the trade offs I referenced.  
> 
> You can have simple or you can have robust. You can’t have both, but which is 
> needed is determined by the problem at hand. 
> 
> Sent from my iPhone
> 
>> On Oct 8, 2018, at 10:46 PM, Dan Kortschak  
>> wrote:
>> 
>> 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
>> people, by stealth changing one language to another because the
>> destination is the Obviously Correct™ language to use. This struck a
>> chord with my with your claims about things that are obviously missing
>> from Go that are present in Java and how we as a community in Go should
>> just stop fooling around and start doing it the Right Way™.
>> 
>> ISTM that in your comment "Yes, lobby to have Go2 include exceptions
>> and then you don’t need to worry about any of this... :)" you are
>> indeed suggesting that the actually is a silver bullet, and that Java
>> has it and that Go doesn't. It may be the case that I have
>> misinterpreted what you wrote (the smiley supports this), but the
>> fairly consistent abrasiveness of you posts regarding deficits in Go
>> that Java has already solved suggests to me on balance that I haven't.
>> If I have, I apologise.
>> 
>> I have nothing further to add to this thread.
>> 
>> Dan
>> 
>>> On Mon, 2018-10-08 at 21:12 -0500, Robert Engels wrote:
>>> 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 8:23 PM, Dan Kortschak >>> du.au> wrote:
 
 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 issues please. Thanks for your understanding.
> 
> -- 
> 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.

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

[Robert Engels]

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 more structure and “process” which can be a negative in some environments. 
Thus the trade offs I referenced.  

You can have simple or you can have robust. You can’t have both, but which is 
needed is determined by the problem at hand. 

Sent from my iPhone

> On Oct 8, 2018, at 10:46 PM, Dan Kortschak  
> wrote:
> 
> 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
> people, by stealth changing one language to another because the
> destination is the Obviously Correct™ language to use. This struck a
> chord with my with your claims about things that are obviously missing
> from Go that are present in Java and how we as a community in Go should
> just stop fooling around and start doing it the Right Way™.
> 
> ISTM that in your comment "Yes, lobby to have Go2 include exceptions
> and then you don’t need to worry about any of this... :)" you are
> indeed suggesting that the actually is a silver bullet, and that Java
> has it and that Go doesn't. It may be the case that I have
> misinterpreted what you wrote (the smiley supports this), but the
> fairly consistent abrasiveness of you posts regarding deficits in Go
> that Java has already solved suggests to me on balance that I haven't.
> If I have, I apologise.
> 
> I have nothing further to add to this thread.
> 
> Dan
> 
>> On Mon, 2018-10-08 at 21:12 -0500, Robert Engels wrote:
>> 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 8:23 PM, Dan Kortschak >> du.au> wrote:
>>> 
>>> 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 issues please. Thanks for your understanding.

-- 
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] Error Handling Best Practice (error wrapping)

[Dan Kortschak]

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
people, by stealth changing one language to another because the
destination is the Obviously Correct™ language to use. This struck a
chord with my with your claims about things that are obviously missing
from Go that are present in Java and how we as a community in Go should
just stop fooling around and start doing it the Right Way™.

ISTM that in your comment "Yes, lobby to have Go2 include exceptions
and then you don’t need to worry about any of this... :)" you are
indeed suggesting that the actually is a silver bullet, and that Java
has it and that Go doesn't. It may be the case that I have
misinterpreted what you wrote (the smiley supports this), but the
fairly consistent abrasiveness of you posts regarding deficits in Go
that Java has already solved suggests to me on balance that I haven't.
If I have, I apologise.

I have nothing further to add to this thread.

Dan

On Mon, 2018-10-08 at 21:12 -0500, Robert Engels wrote:
> 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 8:23 PM, Dan Kortschak  > du.au> wrote:
> > 
> > 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 issues please. Thanks for your understanding.

-- 
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] Error Handling Best Practice (error wrapping)

[Robert Engels]

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 8:23 PM, Dan Kortschak  
> wrote:
> 
> 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 issues please. Thanks for your understanding.

-- 
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: Announcing a Fyne GUI toolkit

[ct via golang-nuts]

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 building new 
> applications, as I wanted to use something powerful but fast to learn. I 
> also wanted a really simple to use GUI toolkit that worked cross platform - 
> this was a little more difficult to satisfy!
>
> The aim was to create an API that was:
>
>- Simple to learn
>- Great looking with theme options
>- Truly cross platform with identical look across platforms
>- Solved all of the complicated GUI challenges (threading, scaling etc)
>
> And so the Fyne project was created https://github.com/fyne-io/fyne !
> The design language is basically material design and the rendering is 
> currently EFL with support for Windows, macOS and Linux.
> It's entirely vector based (though you can draw a Raster space if you 
> need) and scales beautifully.
>
> For a taste of what that looks like here you go :)
>
> [image: widgets-dark.png]
>
> It's now well into development and ready for people to get involved. There 
> is a long way to go but it feels like a solid base.
> Instructions for getting started, if you need them, are at 
> https://github.com/fyne-io/bootstrap/blob/master/README.md .
> If you want to know more we're also in the #fyne channel on the gopher 
> Slack server.
>
> Thanks in advance for your thoughts :)
> Andrew
>

-- 
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] Error Handling Best Practice (error wrapping)

[Dan Kortschak]

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 issues please. Thanks for your understanding.

-- 
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] Error Handling Best Practice (error wrapping)

[robert engels]

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  
> wrote:
> 
> 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 spelling had some room for improvement and has accepted a 5-
>> year phase-in plan that would become known as "Euro-English". 
>> 
>> In the first year, "s" will replace the soft "c". Sertainly, this
>> will make the sivil servants jump with joy. The hard "c" will be
>> dropped in favour of "k". This should klear up konfusion, and
>> keyboards kan have one less letter.
>> 
>> There will be growing publik enthusiasm in the sekond year when the
>> troublesome "ph" will be replaced with "f". This will make words like
>> fotograf 20% shorter. 
>> 
>> In the 3rd year, publik akseptanse of the new spelling kan be
>> expekted to reach the stage where more komplikated changes are
>> possible. 
>> 
>> Governments will enkourage the removal of double letters which have
>> always ben a deterent to akurate speling. 
>> 
>> Also, al wil agre that the horibl mes of the silent "e" in the
>> languag is disgrasful and it should go away. 
>> 
>> By the 4th yer peopl wil be reseptiv to steps such as replasing "th"
>> with "z" and "w" with "v". 
>> 
>> During ze fifz yer, ze unesesary "o" kan be dropd from vords
>> kontaining "ou" and after ziz fifz yer, ve vil hav a reil sensi bl
>> riten styl. 
>> 
>> Zer vil be no mor trubl or difikultis and evrivun vil find it ezi TU
>> understand ech oza. Ze drem of a united urop vil finali kum tru. 
>> 
>> Und efter ze fifz yer, ve vil al be speking German like zey vunted in
>> ze forst plas. 
> 
> Replace "German" with "Java".
> 
> On Mon, 2018-10-08 at 08:04 -0500, Robert Engels wrote:
>> Yes, lobby to have Go2 include exceptions and then you don’t need to
>> worry about any of this... :)
> 
> -- 
> 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] The benefits and costs of writing a POSIX kernel in a high-level language

[andrey mirtchovski]

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
system, poll, etc.) to execute significant applications. Biscuit makes
liberal use of Go's HLL features (closures, channels, maps,
interfaces, garbage collected heap allocation), which subjectively
made programming easier. The most challenging puzzle was handling the
possibility of running out of kernel heap memory; Biscuit benefited
from the analyzability of Go source to address this challenge.

-- 
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 resolve go lang dependencies from enterprise repository

[pprasanthi via golang-nuts]

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-local/github.com/davecgh/go-spew/@v/v1.1.1.mod


How should I resolve them when I run my tests?

When I set GOPROXY =“value” and tried,

go get github.com/Masterminds/semver

go get github.com/Masterminds/semver: unexpected status 
(http://stg-repo.org.com/artifactory/github.com/%21masterminds/semver/@v/list): 
404 Not Found

How can I go get the pkg from enterprise proxy and execute my tests?

As a temporary hack I am doing:


Then following

cd **$** {TESTDIR}/src

curl -O http://stg-repo.org.com/artifactory/ **$** {pkg}

FIELDS=( **$** (echo **$** {pkg} | awk **'{split($0, arr, /[\/:]*/); for (x in 
arr) { print arr[x] }}'** ))

INDEX=( **$** (echo **$** {FIELDS[@]/@v//} | cut -d/ -f1 | wc -w | tr -d **' 
'** ))

PREV_INDEX=$INDEX-1

POST_INDEX=$INDEX+1

FILE= **$** {FIELDS[ **$** {POST_INDEX}]}

unzip **$** {FILE}

FILE= **$** (echo **$** {FILE} | sed -e s/^ **$** {go_local}// -e s/ **$** 
{zip}//)

SOURCE= **$** (find **$** {TESTDIR}/src -name **$** {FIELDS[ **$** 
{PREV_INDEX}]}@ **$** {FILE})

DIR= **$** (dirname $SOURCE)

mv $SOURCE **$** {DIR}/ **$** {FIELDS[ **$** {PREV_INDEX}]}

rm -rf **$** {FILE}.zip

Please let me know the correct way of doing it.

-- 
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] [Go2] rename "Error" to "Fail" in Go2

[Wojciech S. Czarnecki]

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

-- 
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] Error Handling Best Practice (error wrapping)

[Wojciech S. Czarnecki]

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 time to lobby java ppl about removing 'do' and 'while' and some 
other twenty three keywords
to let Gophers feel better at java?

I solemnly promise a post advocating for try/catch construct in Go the day 
after you will succeed with convincing java's population to a vocabulary size 
of Go's.

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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] Re: splitting package question

[Vasiliy Tolstov]

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. :)
>
> The official linker does try to remove many unused functions.
> Unused functions really need more time to compile.
>
> On Saturday, October 6, 2018 at 10:08:43 AM UTC-4, Vasiliy Tolstov wrote:
>>
>> Hi!
>> I have some data that can be formatted with json, text and binary form.
>> Does i need to split this on three parts (json, text, binary) to avoid
>> compile time and run time overhead (and disk size of resulted binary)
>> if user want to use only one format (for example binary). Or go
>> compiler remove unused functions and not include them in resulted
>> binary? (if i don't use json Marshal/Unmarshal full json package not
>> included in my binary)
>> Thanks!
>>
>> --
>> Vasiliy Tolstov,
>> e-mail: v.to...@selfip.ru
>
> --
> 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.



-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

-- 
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] Where are the dependencies saved when we use go mod

[pprasanthi via golang-nuts]

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 wrote:
>
> > 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 process I had few 
> questions that needs clarification. 
> > 
> > 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 { 
> > envVariable := os.Getenv(key) 
> > if envVariable == “” { 
> > return fallback 
> > } 
> > return envVariable 
> > } 
> > 
> > func TestHello(t *testing.T) { 
> > val := GetEnv(“check”, “ok”) 
> > assert.Equal(t, “ok”, val, “val is not equal to ok”) 
> > } 
> > 
> > func TestHello1(t *testing.T) { 
> > val := GetEnv(“check”, “ok”) 
> > assert.Equal(t, “ok”, val, “val is not equal to ok”) 
> > } 
> > 
> > export GO111MODULE=on 
> > 
> > go test ./… 
> > This created go.mod and go.sum files in cd /tmp/gomodtry/ location 
> > When I executed go test ./… -v again , it executed the tests 
> successfully. 
> > 
> > QUESTION: 
> > 
> > Where is the dependent github.com/stretchr/testify/assert downloaded - 
> I dont see it downloaded any where. 
> > Before go mod concept when we set GOPATH and then go get dependency, it 
> used to download physically. 
> > Can you please explain how the test is resolving dependency without the 
> physical presence of dependent library. 
> > 
> > In previous version, when we go get dependencies, some times we used to 
> get 500 error because the host where dependency exists will be down 
> temporarily. 
> > Do we still face this kind of issues with go mod concepts? How is it 
> handled? [we did not like vendoring of dependencies, so we end up doing go 
> get for every test run, which made of tests runs unstable when the host 
> went 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...@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] Where are the dependencies saved when we use go mod

[Wagner Riffel]

> 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 process I had few 
> questions that needs clarification.
>
> 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 {
> envVariable := os.Getenv(key)
> if envVariable == “” {
> return fallback
> }
> return envVariable
> }
>
> func TestHello(t *testing.T) {
> val := GetEnv(“check”, “ok”)
> assert.Equal(t, “ok”, val, “val is not equal to ok”)
> }
>
> func TestHello1(t *testing.T) {
> val := GetEnv(“check”, “ok”)
> assert.Equal(t, “ok”, val, “val is not equal to ok”)
> }
>
> export GO111MODULE=on
>
> go test ./…
> This created go.mod and go.sum files in cd /tmp/gomodtry/ location
> When I executed go test ./… -v again , it executed the tests successfully.
>
> QUESTION:
>
> Where is the dependent github.com/stretchr/testify/assert downloaded - I dont 
> see it downloaded any where.
> Before go mod concept when we set GOPATH and then go get dependency, it used 
> to download physically.
> Can you please explain how the test is resolving dependency without the 
> physical presence of dependent library.
>
> In previous version, when we go get dependencies, some times we used to get 
> 500 error because the host where dependency exists will be down temporarily.
> Do we still face this kind of issues with go mod concepts? How is it handled? 
> [we did not like vendoring of dependencies, so we end up doing go get for 
> every test run, which made of tests runs unstable when the host went 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.

-- 
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] Error Handling Best Practice (error wrapping)

[Dan Kortschak]

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 spelling had some room for improvement and has accepted a 5-
> year phase-in plan that would become known as "Euro-English". 
> 
> In the first year, "s" will replace the soft "c". Sertainly, this
> will make the sivil servants jump with joy. The hard "c" will be
> dropped in favour of "k". This should klear up konfusion, and
> keyboards kan have one less letter.
> 
> There will be growing publik enthusiasm in the sekond year when the
> troublesome "ph" will be replaced with "f". This will make words like
> fotograf 20% shorter. 
> 
> In the 3rd year, publik akseptanse of the new spelling kan be
> expekted to reach the stage where more komplikated changes are
> possible. 
> 
> Governments will enkourage the removal of double letters which have
> always ben a deterent to akurate speling. 
> 
> Also, al wil agre that the horibl mes of the silent "e" in the
> languag is disgrasful and it should go away. 
> 
> By the 4th yer peopl wil be reseptiv to steps such as replasing "th"
> with "z" and "w" with "v". 
> 
> During ze fifz yer, ze unesesary "o" kan be dropd from vords
> kontaining "ou" and after ziz fifz yer, ve vil hav a reil sensi bl
> riten styl. 
> 
> Zer vil be no mor trubl or difikultis and evrivun vil find it ezi TU
> understand ech oza. Ze drem of a united urop vil finali kum tru. 
> 
> Und efter ze fifz yer, ve vil al be speking German like zey vunted in
> ze forst plas. 

Replace "German" with "Java".

On Mon, 2018-10-08 at 08:04 -0500, Robert Engels wrote:
> Yes, lobby to have Go2 include exceptions and then you don’t need to
> worry about any of this... :)

-- 
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] Where are the dependencies saved when we use go mod

[pprasanthi via golang-nuts]

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 {
envVariable := os.Getenv(key)
if envVariable == “” {
return fallback
}
return envVariable
}

func TestHello(t *testing.T) {
val := GetEnv(“check”, “ok”)
assert.Equal(t, “ok”, val, “val is not equal to ok”)
}

func TestHello1(t *testing.T) {
val := GetEnv(“check”, “ok”)
assert.Equal(t, “ok”, val, “val is not equal to ok”)
}

   1. 
   
   export GO111MODULE=on
   2. 
   
   go test ./…
   This created go.mod and go.sum files in cd /tmp/gomodtry/ location
   When I executed go test ./… -v again , it executed the tests 
   successfully.
   
QUESTION:

Where is the dependent github.com/stretchr/testify/assert downloaded - I dont 
see it downloaded any where. 
Before go mod concept when we set GOPATH and then go get dependency, it used to 
download physically. 
Can you please explain how the test is resolving dependency without the 
physical presence of dependent library.

In previous version, when we go get dependencies, some times we used to get 500 
error because the host where dependency exists will be down temporarily. 
Do we still face this kind of issues with go mod concepts? How is it handled? 
[we did not like vendoring of dependencies, so we end up doing go get for every 
test run, which made of tests runs unstable when the host went 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] Get dependency from enterprise repository

[pprasanthi via golang-nuts]

 

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-local/github.com/davecgh/go-spew/@v/v1.1.1.mod


How should I resolve them when I run my tests?

When I set GOPROXY =“value” and tried,

go get github.com/Masterminds/semver

go get github.com/Masterminds/semver: unexpected status 
(http://stg-repo.com/artifactory/github.com/%21masterminds/semver/@v/list): 404 
Not Found

How can I go get the pkg from enterprise proxy and execute my tests?

As a temporary hack I am doing:


Then following

cd **$** {TESTDIR}/src

curl -O http://stg-repo.com/artifactory/ **$** {pkg}

FIELDS=( **$** (echo **$** {pkg} | awk **'{split($0, arr, /[\/:]*/); for (x in 
arr) { print arr[x] }}'** ))

INDEX=( **$** (echo **$** {FIELDS[@]/@v//} | cut -d/ -f1 | wc -w | tr -d **' 
'** ))

PREV_INDEX=$INDEX-1

POST_INDEX=$INDEX+1

FILE= **$** {FIELDS[ **$** {POST_INDEX}]}

unzip **$** {FILE}

FILE= **$** (echo **$** {FILE} | sed -e s/^ **$** {go_local}// -e s/ **$** 
{zip}//)

SOURCE= **$** (find **$** {TESTDIR}/src -name **$** {FIELDS[ **$** 
{PREV_INDEX}]}@ **$** {FILE})

DIR= **$** (dirname $SOURCE)

mv $SOURCE **$** {DIR}/ **$** {FIELDS[ **$** {PREV_INDEX}]}

rm -rf **$** {FILE}.zip

Please let me know the correct way of doing it.

-- 
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] Strange behavior of range over composite literal.

[Raffaele Sena]

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 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.
>
> For future notice, when asking about a strange behavior, it's always
> extremely helpful to say what the strange behavior is.  There are many
> reasons why we might not see the same behavior.
>
> In this case, search for "parsing ambiguity" in
> https://golang.org/ref/spec#Composite_literals .
>
> Ian
>

-- 
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] Strange behavior of range over composite literal.

[Ian Lance Taylor]

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.

For future notice, when asking about a strange behavior, it's always
extremely helpful to say what the strange behavior is.  There are many
reasons why we might not see the same behavior.

In this case, search for "parsing ambiguity" in
https://golang.org/ref/spec#Composite_literals .

Ian

-- 
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] Strange behavior of range over composite literal.

[Jan Mercl]

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 brace of the block
of an "if", "for", or "switch" statement, and the composite literal is not
enclosed in parentheses, square brackets, or curly braces. In this rare
case, the opening brace of the literal is erroneously parsed as the one
introducing the block of statements. To resolve the ambiguity, the
composite literal must appear within parentheses.

if x == (T{a,b,c}[i]) { … }
if (x == T{a,b,c}[i]) { … }


-- 

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

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

[Bakul Shah]

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 in the paper and without channels (such as
> > in Occam) the flavor is very different.
>
> FWIW Occam does have channels; they're just not first class values.
>
> Perhaps you're thinking of Erlang, which I think was inspired more
> directly by the paper?

Erlang is not based on CSP. The main difference being async
message passing as opposed to message rendezvous.

Joe Armstrong (coinventor of Erlang) says this in his PhD thesis:

  1986 - I start work on the language that was to become Erlang,
  though at the time the language had no name. The language started
  as an experiment to add concurrent processes to Prolog
  ...
  at the time the best method for programming POTS appeared to
  be a variant of Prolog augmented with parallel processes.

  1987 ... This version of Erlang was embedded in Prolog using
  Prolog infix operators and did not yet have its own syntax.

There is not even a mention of CSP in this thesis or early
Erlang papers.

http://erlang.org/download/armstrong_thesis_2003.pdf
https://www.erlang.org/course/history

As for go, it is inspired by CSP but it omits a central
restriction of CSP: processes may not communicate by updating
global variables. Go also allows sharing lexical environment
when a nested function is started as a goroutine.  Worse, the
language provides no help in guarding against unprotected
concurrent access. [Race detection is external and not even
available on all supported platforms] 

A CSP like subset Go would make for an interesting experiment
(though I don't know if this is possible). Second, it would be
good to figure out how to detect unprotected concurrent access
at compile time (where possible).

-- 
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] Strange behavior of range over composite literal.

[Raffaele Sena]

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 is expecting
[] followed by {} in order to recognize the composite literal, and misses
the case when the literal type is a user type (i.e. type List []int). Bug
or feature ? :)

-- Raffaele

package main


import "fmt"


type Int int

type List []int


func main() {

// this works

source := List{1, 2, 3, 4, 5}

for _, x := range source {

fmt.Println(x)

}


// this works

for _, x := range []int{1, 2, 3, 4, 5} {

fmt.Println(x)

}


// this works

for _, x := range []Int{1, 2, 3, 4, 5} {

fmt.Println(x)

}


// this doesn't

for _, x := range List{1, 2, 3, 4, 5} {

fmt.Println(x)

}

}

-- 
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] Error Handling Best Practice (error wrapping)

[Liam]

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" for Go2 error 
handling. If it's missing any concepts that try/catch provides, could you 
raise them?
https://gist.github.com/networkimprov/961c9caa2631ad3b95413f7d44a2c98a

That page is linked from the feedback wiki I posted previously.

On Monday, October 8, 2018 at 10:37:43 AM UTC-7, Robert Engels wrote:
>
> 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 different name and syntax - so I 
> say - why not just implement them to begin with. Passing errors up stream 
> (which is often the only reasonable thing to do in a complex system) is 
> error prone without stack traces (for logging), and types (for handling).
>
> The only difference between Go and Java here would be that Go’s are 
> interface based, where as in Java it uses a type hierarchy based off 
> Throwable.
>
> You can write poor Go error code now, there would be nothing stopping 
> someone from writing poor error code using exceptions, except at least with 
> exceptions it is obvious (by the catch and throw clauses) which errors the 
> code is handling and how… (if at all in bad code). With the current Go 
> error handling and the ability to use ‘_’ coupled with no API that controls 
> what errors can be seen/emitted (other than reading the specific API method 
> documentation, and even here you have to get lucky, including with the 
> stdlib methods) -  complex error situations in Go are much harder to handle.
>
> Simple situations are easy in Go right now, but the ‘error mechanism’ is 
> more flow control than error handling in many cases.
>
>
> On Oct 8, 2018, at 12:07 PM, Chris Hopkins  > wrote:
>
> {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 rough and ready "don't worry about the 
> details until I absolutely have to" philosophy.
> That's not to say they would be wrong for go, I just got the impression 
> exceptions - like interrupts - did not play well with concurrency and large 
> projects in general (Except in a "stop the world, I've subbed my toe" kind 
> of way).
>
> I can see for many classes of problems they could work very well and 
> certainly be convenient, but are they not kind of a "Forget about any 
> issues I might have, someone else will fix it" philosophy?
>
> {Hardware Engineer hat on}
> I can't help but think that Exceptions in the hardware sense are a costly 
> thing, in terms of latency, context switch and the higher level handler 
> trying to clean up the state afterwards. In a multi-processor system this 
> gets MUCH worse. They are errors in the strictest sense that should be rare.
> Perhaps this viewpoint is shading my outlook, of the different concept of 
> exceptions here.
> {Hat off}
>
> But I think that's what this is, not a question of utility, but of 
> philosophy, what type of language do people want go to be? Which scales to 
> large systems better? What is easier to understand when someone else has 
> written it? 
> I guess my fear of a catch type mechanism is coming along to find an 
> exception firing in someone else's code and all I see is "Out of Cheese 
> error", where that's an error that's used at every place in the code 
> anything goes wrong (I joke, but how many times have I seen code that just 
> goes log.Fatal("Error")). I could then come along and re-write every one of 
> those places to use different errors, but I would hope most people would 
> say that that behaviour was bad practice, to be fixed. I believe exceptions 
> would encourage, not discourage that behaviour.
>
> Sorry, my short post ended up quite long too!
>
> Regards
>
> Chris
> On Monday, 8 October 2018 16:46:28 UTC+1, Robert Engels wrote:
>>
>> 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, with the 
>> current const based error instances - just add an interface Exception that 
>> all throw X need to implement in order to use, and catch on interfaces, not 
>> structs. 
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 

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

[Liam]

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:
>
> 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 intellects. 
> That's way less scary than the generics proposals that worry me so much.
>
> Thanks again
>
> On Monday, 8 October 2018 15:33:07 UTC+1, Ian Lance Taylor wrote:
>>
>> On Mon, Oct 8, 2018 at 3:38 AM, Chris Hopkins  
>> wrote: 
>> > Hi, 
>> > Could I please check what current error handling best practice is? 
>> ...
>> > Any suggestions gratefully received. 
>>
>> Have you seen the error handling thoughts at 
>> https://go.googlesource.com/proposal/+/master/design/go2draft.md ? 
>> The thoughts about "errors as values" seems relevant here. 
>>
>> Ian 
>>
>

-- 
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 mod download -json` does not product valid json?

['kalekold' via golang-nuts]

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 details on how to handle such a stream of JSON objects: 
>
> https://github.com/golang/go/issues/27655#issuecomment-420993215 
>
>
> Paul 
>

-- 
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] [ANN] Golem: A general purpose, interpreted scripting language

[Mike Jarmy]

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

* github repo: https://github.com/mjarmy/golem-lang
* documentation: https://mjarmy.github.io/golem-lang/

Golem is in beta.  Feedback, suggestions, criticism, bug reports, etc. are 
welcome.

-- 
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] Error Handling Best Practice (error wrapping)

[robert engels]

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 different name and syntax - so I say - why 
not just implement them to begin with. Passing errors up stream (which is often 
the only reasonable thing to do in a complex system) is error prone without 
stack traces (for logging), and types (for handling).

The only difference between Go and Java here would be that Go’s are interface 
based, where as in Java it uses a type hierarchy based off Throwable.

You can write poor Go error code now, there would be nothing stopping someone 
from writing poor error code using exceptions, except at least with exceptions 
it is obvious (by the catch and throw clauses) which errors the code is 
handling and how… (if at all in bad code). With the current Go error handling 
and the ability to use ‘_’ coupled with no API that controls what errors can be 
seen/emitted (other than reading the specific API method documentation, and 
even here you have to get lucky, including with the stdlib methods) -  complex 
error situations in Go are much harder to handle.

Simple situations are easy in Go right now, but the ‘error mechanism’ is more 
flow control than error handling in many cases.


> On Oct 8, 2018, at 12:07 PM, Chris Hopkins  wrote:
> 
> {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 rough and ready "don't worry about the details 
> until I absolutely have to" philosophy.
> That's not to say they would be wrong for go, I just got the impression 
> exceptions - like interrupts - did not play well with concurrency and large 
> projects in general (Except in a "stop the world, I've subbed my toe" kind of 
> way).
> 
> I can see for many classes of problems they could work very well and 
> certainly be convenient, but are they not kind of a "Forget about any issues 
> I might have, someone else will fix it" philosophy?
> 
> {Hardware Engineer hat on}
> I can't help but think that Exceptions in the hardware sense are a costly 
> thing, in terms of latency, context switch and the higher level handler 
> trying to clean up the state afterwards. In a multi-processor system this 
> gets MUCH worse. They are errors in the strictest sense that should be rare.
> Perhaps this viewpoint is shading my outlook, of the different concept of 
> exceptions here.
> {Hat off}
> 
> But I think that's what this is, not a question of utility, but of 
> philosophy, what type of language do people want go to be? Which scales to 
> large systems better? What is easier to understand when someone else has 
> written it? 
> I guess my fear of a catch type mechanism is coming along to find an 
> exception firing in someone else's code and all I see is "Out of Cheese 
> error", where that's an error that's used at every place in the code anything 
> goes wrong (I joke, but how many times have I seen code that just goes 
> log.Fatal("Error")). I could then come along and re-write every one of those 
> places to use different errors, but I would hope most people would say that 
> that behaviour was bad practice, to be fixed. I believe exceptions would 
> encourage, not discourage that behaviour.
> 
> Sorry, my short post ended up quite long too!
> 
> Regards
> 
> Chris
> On Monday, 8 October 2018 16:46:28 UTC+1, Robert Engels wrote:
> 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, with the current 
> const based error instances - just add an interface Exception that all throw 
> X need to implement in order to use, and catch on interfaces, not structs. 
> 
> On Oct 8, 2018, at 9:54 AM, Chris Hopkins > wrote:
> 
>> 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 intellects. That's 
>> way less scary than the generics proposals that worry me so much.
>> 
>> Thanks again
>> 
>> On Monday, 8 October 2018 15:33:07 UTC+1, Ian Lance Taylor wrote:
>> 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 

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

[Chris Hopkins]

{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 rough and ready "don't worry about the details 
until I absolutely have to" philosophy.
That's not to say they would be wrong for go, I just got the impression 
exceptions - like interrupts - did not play well with concurrency and large 
projects in general (Except in a "stop the world, I've subbed my toe" kind 
of way).

I can see for many classes of problems they could work very well and 
certainly be convenient, but are they not kind of a "Forget about any 
issues I might have, someone else will fix it" philosophy?

{Hardware Engineer hat on}
I can't help but think that Exceptions in the hardware sense are a costly 
thing, in terms of latency, context switch and the higher level handler 
trying to clean up the state afterwards. In a multi-processor system this 
gets MUCH worse. They are errors in the strictest sense that should be rare.
Perhaps this viewpoint is shading my outlook, of the different concept of 
exceptions here.
{Hat off}

But I think that's what this is, not a question of utility, but of 
philosophy, what type of language do people want go to be? Which scales to 
large systems better? What is easier to understand when someone else has 
written it? 
I guess my fear of a catch type mechanism is coming along to find an 
exception firing in someone else's code and all I see is "Out of Cheese 
error", where that's an error that's used at every place in the code 
anything goes wrong (I joke, but how many times have I seen code that just 
goes log.Fatal("Error")). I could then come along and re-write every one of 
those places to use different errors, but I would hope most people would 
say that that behaviour was bad practice, to be fixed. I believe exceptions 
would encourage, not discourage that behaviour.

Sorry, my short post ended up quite long too!

Regards

Chris
On Monday, 8 October 2018 16:46:28 UTC+1, Robert Engels wrote:
>
> 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, with the 
> current const based error instances - just add an interface Exception that 
> all throw X need to implement in order to use, and catch on interfaces, not 
> structs. 
>
> On Oct 8, 2018, at 9:54 AM, Chris Hopkins  > wrote:
>
> 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 intellects. 
> That's way less scary than the generics proposals that worry me so much.
>
> Thanks again
>
> On Monday, 8 October 2018 15:33:07 UTC+1, Ian Lance Taylor wrote:
>>
>> 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 is not an often used package - it's not available in 
>> > playground for example. It's really useful for diagnostics to see a 
>> stack of 
>> > what is causing an error, however in my latest application where I'm 
>> trying 
>> > to be really rigorous with my error handling I've hit - for want of a 
>> better 
>> > word - an imperfection. Could I check if there's a better way to do 
>> these 
>> > things: 
>> > So here's what I'm doing: 
>> > When I have an error I need to report I create it like this: 
>> > var ErrInvalidVariable = errors.New("Invalid Variable") 
>> > Which means that you can have code that nicely reads: 
>> > if err == ErrInvalidVariable { /* handle this error */} 
>> > It's how the os package reports errors (along with helper functions), 
>> so I 
>> > assume this is the correct way. 
>> > 
>> > 
>> > For better debug I can use errors.Wrap to annotate this error through 
>> the 
>> > error stack and get useful diagnostic printouts such as 
>> > Line Processing passed "if $BOB==3": Token Passed $BOB : Invalid 
>> Variable. 
>> > 
>> > So far so good. This starts to fail though if I'm trying to determine 
>> lets 
>> > say a fileio error that came from the config file reader, vs the script 
>> file 
>> > reader. At the moment I can say 
>> > _, err := os.Open(...) 
>> > if err != nil { 
>> >   return errors.Wrap(err, "Config File read error") 
>> > } 
>> > But without searching through the error text I can't tell 

Re: [go-nuts] go:nosplit

[Scott Cotton]

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 will work in the future.  Let's focus on real
> problems.  The lack of cooperative preemption is giving us real
> problems in real Go programs today.  That is why we are trying to fix
> it.  If the fix causes problems for audio code, then we'll try to fix
> that.  But let's not get ahead of ourselves; let's first see if there
> is a problem.
>
> Ian
>

There is documentation about the "reality" of the problem is on the issue
tracker.
If there is disagreement about that I would find it more productive to
address why in light of the arguments
and documentation present on the issue tracker, rather than simply to
assume that it is
not real here (and well after the fact).  In any event, I take my
experience, research, and interactions with
others as sufficient to assess they are real.

I also find that all assessments directly to the contrary or responses
which ignore the problem to come from people with far less experience in
the matter (at least as far as I know) than  those other sources I have
consulted and probably also myself.

That said, I too took your stance about a year ago, said to myself, let's
wait and see if it's a real problem. It is quite reasonable and really the
only practical entry point into tackling the problem anyway.

But asserting a priori that well established guidelines from the field are
not to be treated as "real"
without backing up that position is in my opinion a risk with long term
consequences.


-- 
Scott Cotton
http://www.iri-labs.com

-- 
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] Error Handling Best Practice (error wrapping)

[Robert Engels]

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, with the current const 
based error instances - just add an interface Exception that all throw X need 
to implement in order to use, and catch on interfaces, not structs. 

> On Oct 8, 2018, at 9:54 AM, Chris Hopkins  wrote:
> 
> 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 intellects. That's way less 
> scary than the generics proposals that worry me so much.
> 
> Thanks again
> 
>> On Monday, 8 October 2018 15:33:07 UTC+1, Ian Lance Taylor wrote:
>> 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 is not an often used package - it's not available in 
>> > playground for example. It's really useful for diagnostics to see a stack 
>> > of 
>> > what is causing an error, however in my latest application where I'm 
>> > trying 
>> > to be really rigorous with my error handling I've hit - for want of a 
>> > better 
>> > word - an imperfection. Could I check if there's a better way to do these 
>> > things: 
>> > So here's what I'm doing: 
>> > When I have an error I need to report I create it like this: 
>> > var ErrInvalidVariable = errors.New("Invalid Variable") 
>> > Which means that you can have code that nicely reads: 
>> > if err == ErrInvalidVariable { /* handle this error */} 
>> > It's how the os package reports errors (along with helper functions), so I 
>> > assume this is the correct way. 
>> > 
>> > 
>> > For better debug I can use errors.Wrap to annotate this error through the 
>> > error stack and get useful diagnostic printouts such as 
>> > Line Processing passed "if $BOB==3": Token Passed $BOB : Invalid Variable. 
>> > 
>> > So far so good. This starts to fail though if I'm trying to determine lets 
>> > say a fileio error that came from the config file reader, vs the script 
>> > file 
>> > reader. At the moment I can say 
>> > _, err := os.Open(...) 
>> > if err != nil { 
>> >   return errors.Wrap(err, "Config File read error") 
>> > } 
>> > But without searching through the error text I can't tell who caused that. 
>> > Now I could declare a specific type for this, add a Cause handler onto 
>> > that, 
>> > but it starts to get clunky to do that for every error condition. Also it 
>> > doesn't scale to more than 2 levels because it stops at the first cause 
>> > found. I can obviously work around this, but I'm thinking I'm doing this 
>> > wrong, a defining feature of go is the error handling - surely there's a 
>> > better way to do it than this!. 
>> > 
>> > Am I doing something unusual here and wanting to determine where in the 
>> > hierarchy of the stack a problem might have come from? How else do people 
>> > handle errors in situations like this, where you can't fully handle them 
>> > locally, so you want to return the error, but then when you get to the 
>> > higher levels you can handle them, as long as you have information about 
>> > the 
>> > error. The annoying thing is, everything is there in the string of the 
>> > error 
>> > message and I could strings.Contains my way through the error string to 
>> > work 
>> > this out, but that feels a really stupid way to do this. 
>> > I also come across this in my test cases, I want to inject error to make 
>> > sure I am spotting errors correctly and checking that I am getting the 
>> > correct error from the correct place is really quite clunky at the moment, 
>> > if I could test that an error checker in location X was triggered by it 
>> > being passed an error that would save me a lot of code. 
>> > 
>> > Any suggestions gratefully received. 
>> 
>> Have you seen the error handling thoughts at 
>> https://go.googlesource.com/proposal/+/master/design/go2draft.md ? 
>> The thoughts about "errors as values" seems relevant here. 
>> 
>> Ian 
> 
> -- 
> 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 

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

[Michael Jones]

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  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 flavor is very different.
>>
>> FWIW Occam does have channels; they're just not first class values.
>>
>> Perhaps you're thinking of Erlang, which I think was inspired more
>> directly by the paper?
>>
> --

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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: Announcing a Fyne GUI toolkit

[sounthar]

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.
Perhaps you should add the directory containing `eina.pc'
to the PKG_CONFIG_PATH environment variable
No package 'eina' found


what path should be exported to PKG_CONFIG_PATH?

Thank u



On Friday, September 14, 2018 at 10:47:00 PM UTC+5:30, Andrew Williams 
wrote:
>
> Hi,
>
> Some time ago I realised that Go was a great language for building new 
> applications, as I wanted to use something powerful but fast to learn. I 
> also wanted a really simple to use GUI toolkit that worked cross platform - 
> this was a little more difficult to satisfy!
>
> The aim was to create an API that was:
>
>- Simple to learn
>- Great looking with theme options
>- Truly cross platform with identical look across platforms
>- Solved all of the complicated GUI challenges (threading, scaling etc)
>
> And so the Fyne project was created https://github.com/fyne-io/fyne !
> The design language is basically material design and the rendering is 
> currently EFL with support for Windows, macOS and Linux.
> It's entirely vector based (though you can draw a Raster space if you 
> need) and scales beautifully.
>
> For a taste of what that looks like here you go :)
>
> [image: widgets-dark.png]
>
> It's now well into development and ready for people to get involved. There 
> is a long way to go but it feels like a solid base.
> Instructions for getting started, if you need them, are at 
> https://github.com/fyne-io/bootstrap/blob/master/README.md .
> If you want to know more we're also in the #fyne channel on the gopher 
> Slack server.
>
> Thanks in advance for your thoughts :)
> Andrew
>

-- 
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] Error Handling Best Practice (error wrapping)

[Chris Hopkins]

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 intellects. 
That's way less scary than the generics proposals that worry me so much.

Thanks again

On Monday, 8 October 2018 15:33:07 UTC+1, Ian Lance Taylor wrote:
>
> 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 is not an often used package - it's not available in 
> > playground for example. It's really useful for diagnostics to see a 
> stack of 
> > what is causing an error, however in my latest application where I'm 
> trying 
> > to be really rigorous with my error handling I've hit - for want of a 
> better 
> > word - an imperfection. Could I check if there's a better way to do 
> these 
> > things: 
> > So here's what I'm doing: 
> > When I have an error I need to report I create it like this: 
> > var ErrInvalidVariable = errors.New("Invalid Variable") 
> > Which means that you can have code that nicely reads: 
> > if err == ErrInvalidVariable { /* handle this error */} 
> > It's how the os package reports errors (along with helper functions), so 
> I 
> > assume this is the correct way. 
> > 
> > 
> > For better debug I can use errors.Wrap to annotate this error through 
> the 
> > error stack and get useful diagnostic printouts such as 
> > Line Processing passed "if $BOB==3": Token Passed $BOB : Invalid 
> Variable. 
> > 
> > So far so good. This starts to fail though if I'm trying to determine 
> lets 
> > say a fileio error that came from the config file reader, vs the script 
> file 
> > reader. At the moment I can say 
> > _, err := os.Open(...) 
> > if err != nil { 
> >   return errors.Wrap(err, "Config File read error") 
> > } 
> > But without searching through the error text I can't tell who caused 
> that. 
> > Now I could declare a specific type for this, add a Cause handler onto 
> that, 
> > but it starts to get clunky to do that for every error condition. Also 
> it 
> > doesn't scale to more than 2 levels because it stops at the first cause 
> > found. I can obviously work around this, but I'm thinking I'm doing this 
> > wrong, a defining feature of go is the error handling - surely there's a 
> > better way to do it than this!. 
> > 
> > Am I doing something unusual here and wanting to determine where in the 
> > hierarchy of the stack a problem might have come from? How else do 
> people 
> > handle errors in situations like this, where you can't fully handle them 
> > locally, so you want to return the error, but then when you get to the 
> > higher levels you can handle them, as long as you have information about 
> the 
> > error. The annoying thing is, everything is there in the string of the 
> error 
> > message and I could strings.Contains my way through the error string to 
> work 
> > this out, but that feels a really stupid way to do this. 
> > I also come across this in my test cases, I want to inject error to make 
> > sure I am spotting errors correctly and checking that I am getting the 
> > correct error from the correct place is really quite clunky at the 
> moment, 
> > if I could test that an error checker in location X was triggered by it 
> > being passed an error that would save me a lot of code. 
> > 
> > Any suggestions gratefully received. 
>
> Have you seen the error handling thoughts at 
> https://go.googlesource.com/proposal/+/master/design/go2draft.md ? 
> The thoughts about "errors as values" seems relevant here. 
>
> Ian 
>

-- 
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] Error Handling Best Practice (error wrapping)

[Ian Lance Taylor]

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 is not an often used package - it's not available in
> playground for example. It's really useful for diagnostics to see a stack of
> what is causing an error, however in my latest application where I'm trying
> to be really rigorous with my error handling I've hit - for want of a better
> word - an imperfection. Could I check if there's a better way to do these
> things:
> So here's what I'm doing:
> When I have an error I need to report I create it like this:
> var ErrInvalidVariable = errors.New("Invalid Variable")
> Which means that you can have code that nicely reads:
> if err == ErrInvalidVariable { /* handle this error */}
> It's how the os package reports errors (along with helper functions), so I
> assume this is the correct way.
>
>
> For better debug I can use errors.Wrap to annotate this error through the
> error stack and get useful diagnostic printouts such as
> Line Processing passed "if $BOB==3": Token Passed $BOB : Invalid Variable.
>
> So far so good. This starts to fail though if I'm trying to determine lets
> say a fileio error that came from the config file reader, vs the script file
> reader. At the moment I can say
> _, err := os.Open(...)
> if err != nil {
>   return errors.Wrap(err, "Config File read error")
> }
> But without searching through the error text I can't tell who caused that.
> Now I could declare a specific type for this, add a Cause handler onto that,
> but it starts to get clunky to do that for every error condition. Also it
> doesn't scale to more than 2 levels because it stops at the first cause
> found. I can obviously work around this, but I'm thinking I'm doing this
> wrong, a defining feature of go is the error handling - surely there's a
> better way to do it than this!.
>
> Am I doing something unusual here and wanting to determine where in the
> hierarchy of the stack a problem might have come from? How else do people
> handle errors in situations like this, where you can't fully handle them
> locally, so you want to return the error, but then when you get to the
> higher levels you can handle them, as long as you have information about the
> error. The annoying thing is, everything is there in the string of the error
> message and I could strings.Contains my way through the error string to work
> this out, but that feels a really stupid way to do this.
> I also come across this in my test cases, I want to inject error to make
> sure I am spotting errors correctly and checking that I am getting the
> correct error from the correct place is really quite clunky at the moment,
> if I could test that an error checker in location X was triggered by it
> being passed an error that would save me a lot of code.
>
> Any suggestions gratefully received.

Have you seen the error handling thoughts at
https://go.googlesource.com/proposal/+/master/design/go2draft.md ?
The thoughts about "errors as values" seems relevant here.

Ian

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

[Ian Lance Taylor]

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 Cotton  wrote:
>> >
>> >
>> >>
>> >> In fact
>> >> we definitely do want to add other preemption checks that occur at
>> >> points other than function entry (issues #10958, #24543).  And if
>> >> there is another preemption check, there are no promises that
>> >> go:nosplit will disable that check.
>> >
>> >
>> > From what I understand,  this would
>> > 1. enable more faire/balanced scheduling
>> > 2. reduce worst case gc latency
>> > 3. eliminate problems when programmers unintentionally spin with
>> > cooperative/stack based
>> > pre-emption.
>> > 4. slow things down a bit when fair/balanced scheduling and gc latency
>> > and
>> > 3) are not an issue
>> > 5. make it impossible to prevent pre-emption in cases that need it or
>> > rely
>> > on cooperative/stack based pre-emption
>> > 6. potentially re-order some sequences of system calls,   so that Go
>> > programmer sequences of system calls G1, G2, ...
>> > may have Go runtime system calls inserted in between where they weren't
>> > previously.
>> >
>> > I don't think anyone wants 4,5 and 6 is frightening.
>> >
>> > Maybe I don't know what I'm doing, so perhaps others can give opinions?
>> >
>> > Or should this discussion be on the issue tracker or golang-dev?
>>
>> See the discussion at issue #24543.  With that scheme 4 should not be
>> an issue.  5 and 6 could be problems in principle, but note that there
>> is no guaranteed way to do that today either.
>
>
> Thanks.  Continuing the discussion here since there re no responses there
> for some time.
>
> There are many different ways to interpret "guaranteed" above.  The two that
> come to mind
> are
>
> a) A single given go release implementation, such as go1.11 actually may
> randomly pre-empt outside
> of cooperative/stack based premption.  My understanding is no, you do not
> mean this.  And that
> cooperative/stack based pre-emption has been an established norm for a long
> time even if it falls outside the formal language specification.   I call it
> a language "semantic" because to me it's not really the same level of
> abstraction as say whether the compiler does loop unrolling.  It has
> qualitative program I/O implications.
>
> b) If, by "guaranteed" you mean that the language does not formally specify
> it, then I take it on faith that you know the specification better than I,
> so ok.  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 sequences of sys-calls longer than length one is in
> fact not guaranteed to work either.  While I appreciate being conservative
> about the language spec and compatibility, I find this conundrum quite
> impractical.

I think that you are correct: given a sequence of system calls, the Go
language does not guarantee that there will be no intervening system
call.  That is true today and it will be true in the future.  For
example, today, the Go language makes no specific guarantees about
when memory will be allocated, and therefore makes no specific
guarantees about when the mmap system call will be called (on Unix
systems).

But the concern about a sequence of system calls that admits no
intervening system call seems rather abstract to me.  When does that
issue ever arise?  That's not your real concern.  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 will work in the future.  Let's focus on real
problems.  The lack of cooperative preemption is giving us real
problems in real Go programs today.  That is why we are trying to fix
it.  If the fix causes problems for audio code, then we'll try to fix
that.  But let's not get ahead of ourselves; let's first see if there
is a problem.

Ian

-- 
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/types: Why does type check fail with custom importer?

[watassbass]

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 cases, but type check fails when it passes 
a function as an argument. The following is an example:
https://gist.github.com/wata727/345e0be0b8e345f1307bcf38362795a9

When you execute the above code, the following error occurs:

% go run main.go
panic: main.go:10:21: cannot use walker (value of type func(path string, 
info os.FileInfo, err error) error) as path/filepath.WalkFunc value in 
argument to filepath.Walk


goroutine 1 [running]:
main.main()
/Users/watanabekazuma/workspace/golang/src/github.com/wata727/
ssa_example/repro/main.go:27 +0x2d2
exit status 2

However, this `project/main.go` can be executed normally. That is, no type 
error has occurred.

% cd project
% go run main
go run main.go
.main.go

By the way, using `importer.Default()` as importer does not cause this 
error. Why does type check fail with custom importer?


go env

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/watanabekazuma/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/watanabekazuma/workspace/golang"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
-fmessage-length=0 
-fdebug-prefix-map=/var/folders/ds/c5vrpyx94xv7xxzvrf9_qyx0gn/T/go-build429329010=/tmp/go-build
 
-gno-record-gcc-switches -fno-common"

golang.org/x/tools: commit f60d9635b16a5a57b06eaa119614ba4df421966a

-- 
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] Error Handling Best Practice (error wrapping)

[Robert Engels]

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 like the 
> ability to create a stack of errors that trace to what is going on. However 
> it seems this is not an often used package - it's not available in playground 
> for example. It's really useful for diagnostics to see a stack of what is 
> causing an error, however in my latest application where I'm trying to be 
> really rigorous with my error handling I've hit - for want of a better word - 
> an imperfection. Could I check if there's a better way to do these things:
> So here's what I'm doing:
> When I have an error I need to report I create it like this:
> var ErrInvalidVariable = errors.New("Invalid Variable")
> Which means that you can have code that nicely reads: 
> if err == ErrInvalidVariable { /* handle this error */}
> It's how the os package reports errors (along with helper functions), so I 
> assume this is the correct way.
> 
> 
> For better debug I can use errors.Wrap to annotate this error through the 
> error stack and get useful diagnostic printouts such as
> Line Processing passed "if $BOB==3": Token Passed $BOB : Invalid Variable.
> 
> So far so good. This starts to fail though if I'm trying to determine lets 
> say a fileio error that came from the config file reader, vs the script file 
> reader. At the moment I can say
> _, err := os.Open(...)
> if err != nil {
>   return errors.Wrap(err, "Config File read error")
> }
> But without searching through the error text I can't tell who caused that.
> Now I could declare a specific type for this, add a Cause handler onto that, 
> but it starts to get clunky to do that for every error condition. Also it 
> doesn't scale to more than 2 levels because it stops at the first cause 
> found. I can obviously work around this, but I'm thinking I'm doing this 
> wrong, a defining feature of go is the error handling - surely there's a 
> better way to do it than this!.
> 
> Am I doing something unusual here and wanting to determine where in the 
> hierarchy of the stack a problem might have come from? How else do people 
> handle errors in situations like this, where you can't fully handle them 
> locally, so you want to return the error, but then when you get to the higher 
> levels you can handle them, as long as you have information about the error. 
> The annoying thing is, everything is there in the string of the error message 
> and I could strings.Contains my way through the error string to work this 
> out, but that feels a really stupid way to do this.
> I also come across this in my test cases, I want to inject error to make sure 
> I am spotting errors correctly and checking that I am getting the correct 
> error from the correct place is really quite clunky at the moment, if I could 
> test that an error checker in location X was triggered by it being passed an 
> error that would save me a lot of code.
> 
> Any suggestions gratefully received.
> 
> Regards
> 
> Chris
> -- 
> 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.

Re: [go-nuts] go:nosplit

[Scott Cotton]

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 calls of length two.  The syscall package 
supports your sys calls.  You follow the OS guidelines.  Then, the way 
things are today, you are STILL not guaranteed that it will work because 
the runtime might be implemented in a way that uses sys calls which 
interfere with what you are doing.  And the runtime doesn't specify what 
sys calls it might or might not use.  

So it is not really a question of whether you are using the syscall package 
correctly or its organisation w.r.t. operating systems.

Scott



On Monday, 8 October 2018 13:54:26 UTC+2, Jan Mercl wrote:
>
> 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 sequences of sys-calls longer than length one is in 
> fact not guaranteed to work either. 
>
> https://golang.org/doc/go1compat#operating_systems
>
> -- 
>
> -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.

Re: [go-nuts] go:nosplit

[Jan Mercl]

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 sequences of sys-calls longer than length one is in fact not
guaranteed to work either.

https://golang.org/doc/go1compat#operating_systems

-- 

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

Re: [go-nuts] go:nosplit

[Scott Cotton]

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 
> >> we definitely do want to add other preemption checks that occur at 
> >> points other than function entry (issues #10958, #24543).  And if 
> >> there is another preemption check, there are no promises that 
> >> go:nosplit will disable that check. 
> > 
> > 
> > From what I understand,  this would 
> > 1. enable more faire/balanced scheduling 
> > 2. reduce worst case gc latency 
> > 3. eliminate problems when programmers unintentionally spin with 
> > cooperative/stack based 
> > pre-emption. 
> > 4. slow things down a bit when fair/balanced scheduling and gc latency 
> and 
> > 3) are not an issue 
> > 5. make it impossible to prevent pre-emption in cases that need it or 
> rely 
> > on cooperative/stack based pre-emption 
> > 6. potentially re-order some sequences of system calls,   so that Go 
> > programmer sequences of system calls G1, G2, ... 
> > may have Go runtime system calls inserted in between where they weren't 
> > previously. 
> > 
> > I don't think anyone wants 4,5 and 6 is frightening. 
> > 
> > Maybe I don't know what I'm doing, so perhaps others can give opinions? 
> > 
> > Or should this discussion be on the issue tracker or golang-dev? 
>
> See the discussion at issue #24543.  With that scheme 4 should not be 
> an issue.  5 and 6 could be problems in principle, but note that there 
> is no guaranteed way to do that today either. 
>

Thanks.  Continuing the discussion here since there re no responses there 
for some time.

There are many different ways to interpret "guaranteed" above.  The two 
that come to mind
are

a) A single given go release implementation, such as go1.11 actually may 
randomly pre-empt outside
of cooperative/stack based premption.  My understanding is no, you do not 
mean this.  And that 
cooperative/stack based pre-emption has been an established norm for a long 
time even if it falls outside the formal language specification.   I call 
it a language "semantic" because to me it's not really the same level of 
abstraction as say whether the compiler does loop unrolling.  It has 
qualitative program I/O implications.

b) If, by "guaranteed" you mean that the language does not formally specify 
it, then I take it on faith that you know the specification better than I, 
so ok.  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 sequences of sys-calls longer than length one is in 
fact not guaranteed to work either.  While I appreciate being conservative 
about the language spec and compatibility, I find this conundrum quite 
impractical.

Scott
 

 

>
> Ian 
>

-- 
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] Traverse directory without infinite loops while following symlinks

[Rob Pike]

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 although not
> > contradictory. Channels were not in the paper and without channels (such
> as
> > in Occam) the flavor is very different.
>
> FWIW Occam does have channels; they're just not first class values.
>
> Perhaps you're thinking of Erlang, which I think was inspired more
> directly by the paper?
>

-- 
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] Traverse directory without infinite loops while following symlinks

[roger peppe]

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 flavor is very different.

FWIW Occam does have channels; they're just not first class values.

Perhaps you're thinking of Erlang, which I think was inspired more
directly by the paper?

-- 
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] Why is the method net.PacketConn.ReadFrom named as that? Isn't ReadInto more natural?

[T L]

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 explanation. I didn't notice that this method returns an 
address.
The fact that it returns an address makes its name not look unreasonable.

-- 
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: cgo long double

[bruceesmith]

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.

Regards
Bruce


On Monday, 8 October 2018 13:26:16 UTC+11, Bruce Smith wrote:
>
> The header file smi.h from libsmi (https://github.com/mikeowens/libsmi) 
> declares a typedef using "long double"
>
> typedef long double SmiFloat128;
>
> In Go versions prior to 1.11, programs using smi.h compiled without error. 
> In Go 1.11, cgo calls out "long double" as "unexpected". Here is that 
> changed behaviour:
>
> bruce@calochilus:/tmp$ go version
> go version go1.11 linux/amd64
> bruce@calochilus:/tmp$ go build longdouble.go 
> # command-line-arguments
> -: unexpected: 16-byte float type - long double
> bruce@calochilus:/tmp$ go1.10/bin/go version
> go version go1.10.3 linux/amd64
> bruce@calochilus:/tmp$ go1.10/bin/go build longdouble.go 
> bruce@calochilus:/tmp$ cat longdouble.go 
> package main
>
> /*
> #cgo LDFLAGS: -lsmi
> #include 
> #include 
> */
> import "C"
>
> import (
> "fmt"
> )
>
> type SmiType struct {
> smiType *C.struct_SmiType
> }
>
> func main() {
> fmt.Println("Hello")
> }
> bruce@calochilus:/tmp$
>
> So this raises two questions for me:
>
> a) is it a bug that the error message does not include a line number (the 
> code in cmd/cgo/gcc.go tries to print a line number)
> b) what is a 'best practice' approach to handling such an incompatible 
> C-type?
>
> Regards
> Bruce
>
>

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