date:20190809

Sorry, mixed things up in the code with layer1 and layer2... 


var (
Layer1Error= errors.New("some error on layer 1")
Layer2Error= errors.New("some error on layer 2")
)

func main() {
err := callLayer1Function()

// do something with error
}

func callLayer1Function() error {
err := callLayer2Function()

// how to not lose layer2 error but also append a new layer1 error ?
// this does not work, since you fully lose layer1 error
// with pkg/err
return fmt.Errorf("some specific layer 1 error message: %w", Layer1Error)
}

func callLayer2Function() error {
// wrap an error of Layer2 here
return fmt.Errorf("some specific layer2 error message: %w", Layer2Error)
}


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/13d370de-1ea0-48aa-96df-273b5cdb4e53%40googlegroups.com.

[go-nuts] Re: What did you see at GopherCon 2019 (San Diego)?

2019-08-09 Thread Akram Ahmad

You're very welcome, JuciÊ Andrade. Meanwhile, to keep my promise, here's 
an update on what's available in terms of videos of the various talks at 
GopherCon 2019. 

I haven't seen an update, yet, in the GopherCon Slack channel itself. But 
did find some related info elsewhere--It turns out each GopherCon session 
was live-blogged, with links as follows, next to the name of the speaker 
each in the list ([]) below:

GopherCon Talks

*Thursday, July 25*

Russ Cox - On the Road to Go 2 


Elena Morozova - How Uber "Go"es 


Elias Naur - Portable, Immediate Mode GUI Programs for Mobile and Desktop 
in 100% Go  


Rebecca Stambler - Go, pls stop breaking my editor 


Patrick Hawley - Controlling the go runtime 


Johan Brandhorst - Get Going with WebAssembly 


Marwan Sulaiman - Handling Go Errors 


Michael McLoughlin - Better x86 Assembly Generation from Go 


Kaite Hockman - Go Module Proxy: Life of a Query 


Carolyn Van Slyck - Design Command-Line Tools People Love 


Eric Chiang - PKI for Gophers 


Kris Brandow - The Gopher's Manual of Style 


Oliver Stenbom - Contributing to the os Package: How Deep Do You Go? 


*Friday, July 26*

Aaron Schlesinger - The Athens Project - A Proxy Server for Go Modules 


Ian Lance Taylor - Generics in Go 


Jessica Lucci - You Can't Go Your Own Way: The Standardization of Go at 
GitHub 


Ron Evans - Small is Going Big: Go on Microcontrollers 


Chris Hines - Death By Three Thousand Timers: Streaming Video-on-Demand for 
Cable TV 


Daniel Marti - Optimizing Go Code Without a Blindfold 


Gabbi Fisher - Socket to Me: Where do Sockets Live in Go? 


Jonathan Amsterdam - Detecting Incompatible API Changes 

 

Jason Keene - Dynamically Instrumenting Go Programs 


Denis Isaev - Go Linters: Myths and Best Practices 


Mat Ryer - How I Write HTTP Web Services After Eight Years 


Mike Seplowitz - Tracking Inter-process Dependencies Using Static Analysis 


Dave Cheney - Two Go Programs, Three Different Profiling Techniques, in 50 
Minutes 


Johnny Boursiquot - What Got Us Here, Won't Get Us There 



Go Gophers!

 ~Akram

On Thursday, A

[go-nuts] RFC for opt-in streaming support in encoding/json package



*I debated posting here, or straight to GitHub. If that's the better place, 
I can move the thread there. * I have long wanted proper streaming support 
in the `encoding/json` library. Lately I’ve been doing some digging to 
understand the current state of things, and I think I’ve come to grips with 
most of it.

A number of previous issues relate to this topic: 
https://github.com/golang/go/issues/7872, 
https://github.com/golang/go/issues/11046, 
https://github.com/golang/go/issues/12001, 
https://github.com/golang/go/issues/14140

I have read through each of these issues, and believe I have a fair 
understanding of the problems associated with streaming JSON input/output. 
If I'm overlooking something please enlighten me.

In a nutshell: The library implicitly guarantees that marshaling will never 
write an incomplete JSON object due to an error, and that during 
unmarshaling, it will never pass an incomplete JSON message to 
`UnmarshalJSON`.

Work toward this was done about 3 years ago, on this CL: 
https://go-review.googlesource.com/c/go/+/13818/

Workt was eventually abandoned, apparently when the author was unsure how 
to make the new behavior opt-in. I believe this proposal will solve that 
issue.

*The problem to be solved*

Dealing with large JSON structures is inefficient, due to the internal 
buffering done by `encoding/json`. `json.NewEncoder` and `json.NewDecoder` 
appear to offer streaming benefits, but this is mostly an idiomatic 
advantage, not a performance one, as internal buffering still takes place. 
Particular aspects of the broader problem are already addressed on the 
above mentioned links, and benefits of streaming should be easy to imagine, 
so I won't bore people with details unless someone asks. 

*A naïve solution*

I believe a simple solution (simple from the perspective of a consumer of 
the library--the internal changes are not so simple) would be to add two 
interfaces:

type StreamMarshaler interface {

MarshalJSONStream(io.Writer) error

}

type StreamUnmarshaler interface {

UnmarshalJSONStream(io.Reader) error

}

During (un)marshaling, where `encoding/json` looks for `json.Marshaler` and 
`json.Unmarshaler` respectively, it will now look for (and possibly prefer) 
the new interfaces instead. Wrapping either the old or new interfaces to 
work as the other is a trivial matter.

With this change, and the requisite internal changes, it would be possible 
to begin streaming large JSON data to a server immediately, from within a 
`MarshalJSONStream()` implementation, for instance.

The drawback is that it violates the above mentioned promise of complete 
reads and writes, even with errors.

*Opt-in*

To accommodate this requirement, I believe it would be possible to expose 
the streaming functionality _only_ with the `json.Encoder` and 
`json.Decoder` implementations, and only when `EnablePartial*` (name TBD) 
is enabled.  So further, the following two functions would be added to the 
public API:

func (*Encoder) EnablePartialWrites(on bool)

func (*Decoder) EnablePartialReads(on bool)

The default behavior, even when a type implements one of the new `Stream*` 
interfaces, will be to operate on an entire JSON object at once. That is to 
say, the Encoder will internally buffer `MarshalJSONStream`'s output, and 
process any error before continuing, and a decoder will read an entire JSON 
object into a buffer, then pass it to `UnmarshalJSONStream` only if there 
are no errors.

However, when `EnablePartial*` is enabled, the library will bypass this 
internal buffering, allowing for immediate streaming to/from the 
source/destination.

Enabling streaming with the `EnablePartial*` toggle could be enough to 
already experience a benefit for many users, even without the use of the 
additional interfaces above.

Toggling `EnablePartial*` on will, of course, enable streaming for all 
types, not just those which implement the new interface above, so this 
could be considered a separate part of the proposal. In my opinion, this 
alone would be worth implementing, even if the new interface types above 
are done later or never.

*Internals*

CL 13818 can serve as very informative for this part of the discussion. 
I've also done some digging in the `encoding/json` package (as of 1.12) 
recently, for more current context. A large number of internal changes will 
be necessary to allow for this. I started playing around with a few 
internals, and I believe this is doable, but will mean a lot of code churn, 
so will need to be done carefully, in small steps with good code review.

As an exercise, I have successfully rewritten`indent()` to work with 
streams, rather than on byte slices, and began doing the same with 
`compact()`. The `encodeState` type would need to work with a standard 
`io.Writer` rather than specifically a `bytes.Buffer`. This seems to be a 
bigger change, but not technically difficult. I know there are other 
changes needed--I have

[go-nuts] app not compiling

2019-08-09 Thread gato . pardo

Hi:

  can someone explain this message that I've gotten recently after 
installing "go version go1.12.7 linux/amd64" in a new computer and  
compiling an application named xorto:

# xorto
2019/08/09 09:14:58 readSym out of sync
 
The same application compiles and runs well in the same  environement in 
other machines.
I suspect there is some library missing. If it is so how can I find it.

Or, what else can it be ?. What does the message mean ? 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cfe0731e-660a-4292-be55-f831f648cbec%40googlegroups.com.

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

On Fri, Aug 9, 2019 at 8:33 AM Jonathan Hall  wrote:
>
> I debated posting here, or straight to GitHub. If that's the better place, I 
> can move the thread there. I have long wanted proper streaming support in the 
> `encoding/json` library. Lately I’ve been doing some digging to understand 
> the current state of things, and I think I’ve come to grips with most of it.
>
>
> A number of previous issues relate to this topic: 
> https://github.com/golang/go/issues/7872, 
> https://github.com/golang/go/issues/11046, 
> https://github.com/golang/go/issues/12001, 
> https://github.com/golang/go/issues/14140
>
>
> I have read through each of these issues, and believe I have a fair 
> understanding of the problems associated with streaming JSON input/output. If 
> I'm overlooking something please enlighten me.
>
>
> In a nutshell: The library implicitly guarantees that marshaling will never 
> write an incomplete JSON object due to an error, and that during 
> unmarshaling, it will never pass an incomplete JSON message to 
> `UnmarshalJSON`.
>
>
> Work toward this was done about 3 years ago, on this CL: 
> https://go-review.googlesource.com/c/go/+/13818/
>
> Workt was eventually abandoned, apparently when the author was unsure how to 
> make the new behavior opt-in. I believe this proposal will solve that issue.
>
>
> The problem to be solved
>
>
> Dealing with large JSON structures is inefficient, due to the internal 
> buffering done by `encoding/json`. `json.NewEncoder` and `json.NewDecoder` 
> appear to offer streaming benefits, but this is mostly an idiomatic 
> advantage, not a performance one, as internal buffering still takes place. 
> Particular aspects of the broader problem are already addressed on the above 
> mentioned links, and benefits of streaming should be easy to imagine, so I 
> won't bore people with details unless someone asks.
>
> A naïve solution
>
>
> I believe a simple solution (simple from the perspective of a consumer of the 
> library--the internal changes are not so simple) would be to add two 
> interfaces:
>
>
> type StreamMarshaler interface {
>
> MarshalJSONStream(io.Writer) error
>
> }
>
>
> type StreamUnmarshaler interface {
>
> UnmarshalJSONStream(io.Reader) error
>
> }
>
>
> During (un)marshaling, where `encoding/json` looks for `json.Marshaler` and 
> `json.Unmarshaler` respectively, it will now look for (and possibly prefer) 
> the new interfaces instead. Wrapping either the old or new interfaces to work 
> as the other is a trivial matter.
>
>
> With this change, and the requisite internal changes, it would be possible to 
> begin streaming large JSON data to a server immediately, from within a 
> `MarshalJSONStream()` implementation, for instance.
>
>
> The drawback is that it violates the above mentioned promise of complete 
> reads and writes, even with errors.
>
>
> Opt-in
>
>
> To accommodate this requirement, I believe it would be possible to expose the 
> streaming functionality _only_ with the `json.Encoder` and `json.Decoder` 
> implementations, and only when `EnablePartial*` (name TBD) is enabled.  So 
> further, the following two functions would be added to the public API:
>
>
> func (*Encoder) EnablePartialWrites(on bool)
>
>
> func (*Decoder) EnablePartialReads(on bool)
>
>
> The default behavior, even when a type implements one of the new `Stream*` 
> interfaces, will be to operate on an entire JSON object at once. That is to 
> say, the Encoder will internally buffer `MarshalJSONStream`'s output, and 
> process any error before continuing, and a decoder will read an entire JSON 
> object into a buffer, then pass it to `UnmarshalJSONStream` only if there are 
> no errors.
>
>
> However, when `EnablePartial*` is enabled, the library will bypass this 
> internal buffering, allowing for immediate streaming to/from the 
> source/destination.
>
>
> Enabling streaming with the `EnablePartial*` toggle could be enough to 
> already experience a benefit for many users, even without the use of the 
> additional interfaces above.
>
>
> Toggling `EnablePartial*` on will, of course, enable streaming for all types, 
> not just those which implement the new interface above, so this could be 
> considered a separate part of the proposal. In my opinion, this alone would 
> be worth implementing, even if the new interface types above are done later 
> or never.
>
>
> Internals
>
>
> CL 13818 can serve as very informative for this part of the discussion. I've 
> also done some digging in the `encoding/json` package (as of 1.12) recently, 
> for more current context. A large number of internal changes will be 
> necessary to allow for this. I started playing around with a few internals, 
> and I believe this is doable, but will mean a lot of code churn, so will need 
> to be done carefully, in small steps with good code review.
>
>
> As an exercise, I have successfully rewritten`indent()` to work with streams, 
> rather than on byte slice

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

Can you say more? Better in which way?


On Friday, August 9, 2019 at 4:46:19 PM UTC+2, burak serdar wrote:
>
>
> Instead of modifying the existing Encoder/Decoder, wouldn't it be 
> better to do this as a separate encoder/decoder? 
>
>
>
>
> > 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/9b081989-0ffa-40a1-8d6b-f56833e7b749%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cc2b65c1-4abc-4309-b0c8-b311456873ee%40googlegroups.com.

Re: [go-nuts] Re: Upgrade to Go1.12.7 problem [SOLVED]

2019-08-09 Thread Gerald Henriksen

On Mon, 5 Aug 2019 18:58:02 -0700 (PDT), you wrote:

>I discovered that /usr/local/go was still version 1.11 for whatever reason 
>Ubuntu did not update that directory when I installed go via apt/dpkg

This is correct behaviour, see below.

>I therefore downloaded  
>https://dl.google.com/go/go1.12.7.linux-amd64.tar.gz into /tmp, 
>decompressed it, then moved the go/ directory to /usr/local (moving the old 
>version to /usr/local/go-1.11 just in case)

In general it is a bad idea to mix both self-installed and
distribution packaged versions of the same program unless you are
aware of what you are doing and the likely repurcussions.

If you are now using the version of Go that you downloaded and self
installed (as indicated above) then make sure you have used apt/dpkg
to remove the Ubuntu version that you installed in the past.

More generally, distribution packages (whether apt/dpkg/rpm) do not
install into /usr/local and thus installing the Ubuntu version of Go
would not touch anything in /usr/local because, as the name suggests,
/usr/local is meant for stuff the user has installed outside of the
distribution package management system.

So if you want to switch from self installed to the Ubuntu packaged
version of Go, then it is up to you to clean up /usr/local of any
previous non-dpkg installs of Go.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/iv1rkep3ukfd24au2uejfvecq7c0pba5o8%404ax.com.

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall  wrote:
>
> Can you say more? Better in which way?

Better in the way that it wouldn't change existing code. Also, I think
the use cases for existing and proposed json encoders/decoders are
different enough to justify a separate implementation. A wihle ago
with similar concerns you described, I wrote a separate json
encoder/decoder using the existing ones to deal with large json files.
The purpose was to stream json input/output, and direct json
manipulation in memory. I ended up using that only for cases where I
expect large json data, and use the std encoder/decoder for small json
processing like config files, or API calls with known structures.




>
>
> On Friday, August 9, 2019 at 4:46:19 PM UTC+2, burak serdar wrote:
>>
>>
>> Instead of modifying the existing Encoder/Decoder, wouldn't it be
>> better to do this as a separate encoder/decoder?
>>
>>
>>
>>
>> >
>> >
>> > --
>> > 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 golan...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/golang-nuts/9b081989-0ffa-40a1-8d6b-f56833e7b749%40googlegroups.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/cc2b65c1-4abc-4309-b0c8-b311456873ee%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqpN_PufK3icB9DnS6pMSEoUCQZGbo5b0jMJTSM%3Dcp3n-Q%40mail.gmail.com.

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

Thanks for the reply. My responses inline below.

On Friday, August 9, 2019 at 5:14:52 PM UTC+2, burak serdar wrote:
>
> On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall  > wrote: 
> > 
> > Can you say more? Better in which way? 
>
> Better in the way that it wouldn't change existing code.

That doesn't seem like a benefit, in its own right

I understand the desire not to just change code for its own sake, or add 
extra features nobody needs. But people have been asking for these types of 
features for several years.  This doesn't seem like a frivolous code change 
to me.

> Also, I think 
> the use cases for existing and proposed json encoders/decoders are 
> different enough to justify a separate implementation.

I don't think I agree with this.

The proposal deals with a subset of current use cases, but not, strictly 
speaking, a _different set_ of use cases. And the number of commentators on 
the issues linked above, I think lends weight to the idea that the use 
cases this proposal addresses are not insignificant, or fundamentally 
"different".

If I were to fork the standard `encoding/json` library, and add my proposed 
functionality, the code would still be 95% the same. Standard reasons for 
sharing code apply, as far as I can tell.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/df688733-a2e9-4bc8-aa7b-09267827007a%40googlegroups.com.

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

2019-08-09 Thread Robert Engels

In other environments (e.g. Java), the streaming processors are distinct from the instance oriented - usually for good reason as the APIs are very different - the former is usually event based, and the latter returns realized instances as a whole or an error. The streaming processors can often skip ill-formed entities, and/or have them manipulated during decoding.-Original Message-
From: Jonathan Hall 
Sent: Aug 9, 2019 10:38 AM
To: golang-nuts 
Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

Thanks for the reply. My responses inline below.On Friday, August 9, 2019 at 5:14:52 PM UTC+2, burak serdar wrote:On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall  wrote:
>
> Can you say more? Better in which way?

Better in the way that it wouldn't change existing code.That doesn't seem like a benefit, in its own rightI understand the desire not to just change code for its own sake, or add extra features nobody needs. But people have been asking for these types of features for several years.  This doesn't seem like a frivolous code change to me.  Also, I think
the use cases for existing and proposed json encoders/decoders are
different enough to justify a separate implementation.I don't think I agree with this.The proposal deals with a subset of current use cases, but not, strictly speaking, a _different set_ of use cases. And the number of commentators on the issues linked above, I think lends weight to the idea that the use cases this proposal addresses are not insignificant, or fundamentally "different".If I were to fork the standard `encoding/json` library, and add my proposed functionality, the code would still be 95% the same. Standard reasons for sharing code apply, as far as I can tell.

-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/df688733-a2e9-4bc8-aa7b-09267827007a%40googlegroups.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/360977651.3940.1565366003341%40wamui-agami.atl.sa.earthlink.net.

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

An interesting observation.

Although in a sense, we already have the decoding half of that low-level 
streaming API exposed by way of the `json.Decoder` type.

Would you be suggesting that a separate, stream-based API makes sense even 
within the stdlib?

I'm not really sure what that separate API would look like, or do 
differently than my proposal (I'm open to new ideas, though).

Given that the "Go way" of handling streams is with io.Reader/io.Writer (as 
opposed to events, for example), and the internal implementation of 
`json/encoding` is already so close to that, I wonder if the APIs would end 
up looking very much the same, anyway.

Jonathan


On Friday, August 9, 2019 at 5:53:41 PM UTC+2, Robert Engels wrote:
>
> In other environments (e.g. Java), the streaming processors are distinct 
> from the instance oriented - usually for good reason as the APIs are very 
> different - the former is usually event based, and the latter returns 
> realized instances as a whole or an error. The streaming processors can 
> often skip ill-formed entities, and/or have them manipulated during 
> decoding.
>
> -Original Message- 
> From: Jonathan Hall 
> Sent: Aug 9, 2019 10:38 AM 
> To: golang-nuts 
> Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json 
> package 
>
> Thanks for the reply. My responses inline below.
>
> On Friday, August 9, 2019 at 5:14:52 PM UTC+2, burak serdar wrote:
>>
>> On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall  wrote: 
>> > 
>> > Can you say more? Better in which way? 
>>
>> Better in the way that it wouldn't change existing code.
>
>
> That doesn't seem like a benefit, in its own right
>
> I understand the desire not to just change code for its own sake, or add 
> extra features nobody needs. But people have been asking for these types of 
> features for several years.  This doesn't seem like a frivolous code change 
> to me.
>  
>
>> Also, I think 
>> the use cases for existing and proposed json encoders/decoders are 
>> different enough to justify a separate implementation.
>
>
> I don't think I agree with this.
>
> The proposal deals with a subset of current use cases, but not, strictly 
> speaking, a _different set_ of use cases. And the number of commentators on 
> the issues linked above, I think lends weight to the idea that the use 
> cases this proposal addresses are not insignificant, or fundamentally 
> "different".
>
> If I were to fork the standard `encoding/json` library, and add my 
> proposed functionality, the code would still be 95% the same. Standard 
> reasons for sharing code apply, as far as I can tell.
>
> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/df688733-a2e9-4bc8-aa7b-09267827007a%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/718e2b9e-39e2-44f2-9308-8c94e31afbff%40googlegroups.com.

[go-nuts] Re: How to propagate multiple errors using the new fmt.Errorf wrapping

2019-08-09 Thread Agniva De Sarker

This is the right way. What is the issue you are facing ? See 
https://tip.golang.org/pkg/errors/ for more info.

You can check for Layer1Error and Layer2Error using the Is function

errors.Is(err, Layer1Error)

errors.Is(err, Layer2Error)

On Friday, 9 August 2019 19:09:24 UTC+5:30, Alex wrote:
>
> Sorry, mixed things up in the code with layer1 and layer2... 
>
>
> var (
> Layer1Error= errors.New("some error on layer 1")
> Layer2Error= errors.New("some error on layer 2")
> )
>
> func main() {
> err := callLayer1Function()
>
> // do something with error
> }
>
> func callLayer1Function() error {
> err := callLayer2Function()
>
> // how to not lose layer2 error but also append a new layer1 error ?
> // this does not work, since you fully lose layer1 error
> // with pkg/err
> return fmt.Errorf("some specific layer 1 error message: %w", Layer1Error)
> }
>
> func callLayer2Function() error {
> // wrap an error of Layer2 here
> return fmt.Errorf("some specific layer2 error message: %w", Layer2Error)
> }
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8a149bf3-fa6b-41b3-94b3-517f41dd373b%40googlegroups.com.

Re: [go-nuts] app not compiling

2019-08-09 Thread Kurtis Rader

Insufficient information. What is "xorto"? What packages does it import?
Googling "readsym out of sync" turns up a few mentions such

https://github.com/golang/go/blob/master/src/cmd/link/internal/objfile/objfile.go


On Fri, Aug 9, 2019 at 7:38 AM  wrote:

> Hi:
>
>   can someone explain this message that I've gotten recently after
> installing "go version go1.12.7 linux/amd64" in a new computer and
> compiling an application named xorto:
>
> # xorto
> 2019/08/09 09:14:58 readSym out of sync
>
> The same application compiles and runs well in the same  environement in
> other machines.
> I suspect there is some library missing. If it is so how can I find it.
>
> Or, what else can it be ?. What does the message mean ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/cfe0731e-660a-4292-be55-f831f648cbec%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD8s9u2zMf-kS0tpnj4pFpJMwwketCmHqxxn_fa5sQAbjA%40mail.gmail.com.

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

2019-08-09 Thread Ian Davis

On Fri, 9 Aug 2019, at 3:33 PM, Jonathan Hall wrote:
> *I debated posting here, or straight to GitHub. If that's the better place, I 
> can move the thread there. * I have long wanted proper streaming support in 
> the `encoding/json` library. Lately I’ve been doing some digging to 
> understand the current state of things, and I think I’ve come to grips with 
> most of it.

> 
> A number of previous issues relate to this topic: 
> https://github.com/golang/go/issues/7872, 
> https://github.com/golang/go/issues/11046, 
> https://github.com/golang/go/issues/12001, 
> https://github.com/golang/go/issues/14140

> 
> I have read through each of these issues, and believe I have a fair 
> understanding of the problems associated with streaming JSON input/output. If 
> I'm overlooking something please enlighten me.

> 
> In a nutshell: The library implicitly guarantees that marshaling will never 
> write an incomplete JSON object due to an error, and that during 
> unmarshaling, it will never pass an incomplete JSON message to 
> `UnmarshalJSON`.

> 
> Work toward this was done about 3 years ago, on this CL: 
> https://go-review.googlesource.com/c/go/+/13818/

> Workt was eventually abandoned, apparently when the author was unsure how to 
> make the new behavior opt-in. I believe this proposal will solve that issue.


You may also be interested in a CL I created last year to add an unbuffered 
write mode to the encoder

https://go-review.googlesource.com/c/go/+/135595

I think I addressed all the review comments but it stalled behind a tangential 
issue around the current version's use of sync.Pool 
https://github.com/golang/go/issues/27735

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/70e5a2a1-70bf-4917-81c5-6504e110d9b2%40www.fastmail.com.

[go-nuts] Re: How to propagate multiple errors using the new fmt.Errorf wrapping

Hi Agniva,

the problem is: In the main function is no information that there was an 
Layer2 error (layer2 error is not included in the error anymore).
I don't know how to take the error from layer2 and wrap another error 
(layer1-error) around it.

You can only use the verb "%w" once in a fmt.Errorf() function afaik.
So if you have a wrapped error object e1, how would you enrich / wrap this 
with another error e2?


Thanks,
Alex

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e33b7257-5e68-48b2-b4ca-fc968a6c0ddf%40googlegroups.com.

Re: [go-nuts] app not compiling

2019-08-09 Thread Ian Lance Taylor

On Fri, Aug 9, 2019 at 7:38 AM  wrote:
>
>   can someone explain this message that I've gotten recently after installing 
> "go version go1.12.7 linux/amd64" in a new computer and  compiling an 
> application named xorto:
>
> # xorto
> 2019/08/09 09:14:58 readSym out of sync
>
> The same application compiles and runs well in the same  environement in 
> other machines.
> I suspect there is some library missing. If it is so how can I find it.
>
> Or, what else can it be ?. What does the message mean ?

The message means that the Go generated object file is corrupt.  The
first step would be to make sure that you have enough disk space, and
to run `go clean -cache` and try the build again.  If this is a
repeatable error, and you have enough disk space, and you aren't
seeing any other odd problems on that machine, please open a bug
report with complete reproduction instructions.  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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVcniyQ1pivd%3DmXubgM0YmiR-CXgELNe1URekz4GT%2BJRA%40mail.gmail.com.

[go-nuts] Re: How to propagate multiple errors using the new fmt.Errorf wrapping

2019-08-09 Thread Agniva De Sarker

I see. One way is to create a wrapper error type in layer1, which takes a 
layer2 error.  Just like os.PathError.

package main

import (
"errors"
"fmt"
)

var (
// Layer1Error = errors.New("some error on layer 1")
Layer2Error = errors.New("some error on layer 2")
)

type Layer1Error struct {
internal error
}

func (le *Layer1Error) Error() string {
return fmt.Sprintf("layer2 error: %v", le.internal)
}

func (le *Layer1Error) Unwrap() error {
return le.internal
}

func main() {
err := callLayer1Function()
fmt.Println(errors.Is(err, Layer2Error))
var l2err *Layer1Error
fmt.Println(errors.As(err, &l2err))
}

func callLayer1Function() error {
err := callLayer2Function()
return &Layer1Error{err}
}

func callLayer2Function() error {
// wrap an error of Layer2 here
return fmt.Errorf("some specific layer2 error message: %w", Layer2Error)
}


On Friday, 9 August 2019 22:43:11 UTC+5:30, Alex wrote:
>
> Hi Agniva,
>
> the problem is: In the main function is no information that there was an 
> Layer2 error (layer2 error is not included in the error anymore).
> I don't know how to take the error from layer2 and wrap another error 
> (layer1-error) around it.
>
> You can only use the verb "%w" once in a fmt.Errorf() function afaik.
> So if you have a wrapped error object e1, how would you enrich / wrap this 
> with another error e2?
>
>
> Thanks,
> Alex
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7a97e612-132c-46ac-ad6f-33a3c19632f8%40googlegroups.com.

[go-nuts] Re: How to propagate multiple errors using the new fmt.Errorf wrapping

Yes, sure. This is always possible. :-)

But this is kind of writing your own error wrapper. I was just wondering if 
this is somehow possible with the new error wrapper like it was with 
https://github.com/pkg/errors.

Am Freitag, 9. August 2019 19:35:42 UTC+2 schrieb Agniva De Sarker:
>
> I see. One way is to create a wrapper error type in layer1, which takes a 
> layer2 error.  Just like os.PathError.
>
> package main
>
> import (
> "errors"
> "fmt"
> )
>
> var (
> // Layer1Error = errors.New("some error on layer 1")
> Layer2Error = errors.New("some error on layer 2")
> )
>
> type Layer1Error struct {
> internal error
> }
>
> func (le *Layer1Error) Error() string {
> return fmt.Sprintf("layer2 error: %v", le.internal)
> }
>
> func (le *Layer1Error) Unwrap() error {
> return le.internal
> }
>
> func main() {
> err := callLayer1Function()
> fmt.Println(errors.Is(err, Layer2Error))
> var l2err *Layer1Error
> fmt.Println(errors.As(err, &l2err))
> }
>
> func callLayer1Function() error {
> err := callLayer2Function()
> return &Layer1Error{err}
> }
>
> func callLayer2Function() error {
> // wrap an error of Layer2 here
> return fmt.Errorf("some specific layer2 error message: %w", Layer2Error)
> }
>
>
> On Friday, 9 August 2019 22:43:11 UTC+5:30, Alex wrote:
>>
>> Hi Agniva,
>>
>> the problem is: In the main function is no information that there was an 
>> Layer2 error (layer2 error is not included in the error anymore).
>> I don't know how to take the error from layer2 and wrap another error 
>> (layer1-error) around it.
>>
>> You can only use the verb "%w" once in a fmt.Errorf() function afaik.
>> So if you have a wrapped error object e1, how would you enrich / wrap 
>> this with another error e2?
>>
>>
>> Thanks,
>> Alex
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/497b6f13-a4de-4780-904b-12b1fa53a8ef%40googlegroups.com.

[go-nuts] I know you cannot kill a goroutine, but ...

2019-08-09 Thread reiki33

Background:
UniVerse is a Pick model, multivalue database,
https://groups.google.com/forum/#!forum/mvdbms for some general information.
Multivalue databases permit more than one value in a column for a row.
Since you do not know the size of the column with hundreds or thousands of
values in the column-row, you do not know the size of the record. Access
dictates linked lists to handle variability in record size. So, every row
gets a unique primary key and stored in hash tables with an appropriately
large number of hash buckets for the data - key / value pairs. With good
hashing, I can often access a record in a single disk access. Group (hash
table bucket) locking happens within the environment, while users request
row locking. Each user in UniVerse is a separate O/S process. Locking
activity occurs in shared memory, using assembly test-and-set kinds of
instructions or host-specific semaphores.

After retiring, I decided it would be a fun experiment to build a
clean-room implementation of UniVerse. Go does not do interprocess
communication at the rate that would match the shared memory semaphore
activity in UniVerse. A natural match implements each user as a goroutine.
UniVerse provides an extended BASIC language for accessing and manipulating
table data that runs close to the engine. In a language you can do silly
things like create an infinite loop. In a production environment of 1000s
of users, you cannot simply bounce the environment because one user is
eating a CPU. An admin function to dismiss or kill a goroutine would be
ideal. Not possible in the current Go world.

For an infinite loop to exist, you need to branch "backwards" or call a
routine that calls you back with some possible indirection. (An equivalent
in Go is "for {}" with no break. Here, you would not get back to the
traditional mechanism of telling a goroutine to shut down where one of the
channels for select is the shutdown indicator.) There may be other
examples I have yet to think of. When I "compile" BASIC, I can put checks
into those two functions, call, and branch (to a lower address), without
inducing too much overhead. an unimportant detail is that the BASIC
compiles to a p-code run on a run machine, comparable to a JVM. I might
even be able to find the PC, Program Counter or IA, Instruction Address,
and insert some kind of trap instruction opcode, that would cause it to try
the select statement and see the shutdown channel. But in the general case,
this may be insufficient. I think a "context" timeout would interrupt a
properly long-running program in a way that might be hard to restart if
shutdown was not requested.

As a database, there is also the possibility of deadly embrace. Killing one
of the two (or more) goroutines in a deadly embrace would be useful. This
normally occurs on poorly managed acquisition of exclusive locks on
database table rows. I could forcibly release a lock, but then would need
extra work so that a user goroutine that thinks it exclusively owns a lock,
finds that it does not, and would need to gracefully exit or handle the
situation.

As a goroutine, each user does not have a STDIN, and STDOUT to communicate
with its user. Currently, the user communicates with the goroutine with a
socket connection. I can probably redesign, adding a new goroutine
accepting user requests/commands on a channel, and monitoring the shutdown
channel with a select in a loop. Otherwise, I could not get a goroutine to
shut down if it is waiting on user input from a socket, or a dropped
connection, although that begs the question of how to get the
socket-reading goroutine to now shut down.

The current Go implementation smells of cooperative multitasking. Not a bad
thing, per se, but makes it hard to stop in certain degenerate cases. Have
I missed a way to deal with some of the discussed issues?

The project has certainly been a good way to become familiar with a number
of the Go idioms. (BTW, I happen to *like* the current way of handling
errors!)

--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/622c48dd-5909-43a9-923a-ac74a7a8f0b2%40googlegroups.com.

Re: [go-nuts] I know you cannot kill a goroutine, but ...

2019-08-09 Thread Robert Engels

The standard method in nearly all languages including go is to close the 
connection from another routine. Alternatively you can use a timeout/deadline 
on every operation. 


> On Aug 9, 2019, at 1:34 PM, reik...@gmail.com wrote:
> 
> Background:
> UniVerse is a Pick model, multivalue database, 
> https://groups.google.com/forum/#!forum/mvdbms for some general information.
> Multivalue databases permit more than one value in a column for a row. Since 
> you do not know the size of the column with hundreds or thousands of values 
> in the column-row, you do not know the size of the record. Access dictates 
> linked lists to handle variability in record size. So, every row gets a 
> unique primary key and stored in hash tables with an appropriately large 
> number of hash buckets for the data - key / value pairs. With good hashing, I 
> can often access a record in a single disk access. Group (hash table bucket) 
> locking happens within the environment, while users request row locking. Each 
> user in UniVerse is a separate O/S process. Locking activity occurs in shared 
> memory, using assembly test-and-set kinds of instructions or host-specific 
> semaphores.
> 
> After retiring, I decided it would be a fun experiment to build a clean-room 
> implementation of UniVerse. Go does not do interprocess communication at the 
> rate that would match the shared memory semaphore activity in UniVerse. A 
> natural match implements each user as a goroutine. UniVerse provides an 
> extended BASIC language for accessing and manipulating table data that runs 
> close to the engine. In a language you can do silly things like create an 
> infinite loop. In a production environment of 1000s of users, you cannot 
> simply bounce the environment because one user is eating a CPU. An admin 
> function to dismiss or kill a goroutine would be ideal. Not possible in the 
> current Go world. 
> 
> For an infinite loop to exist, you need to branch "backwards" or call a 
> routine that calls you back with some possible indirection. (An equivalent in 
> Go is "for {}" with no break. Here, you would not get back to the traditional 
> mechanism of telling a goroutine to shut down where one of the channels for 
> select is the shutdown indicator.)  There may be other examples I have yet to 
> think of. When I "compile" BASIC, I can put checks into those two functions, 
> call, and branch (to a lower address), without inducing too much overhead. an 
> unimportant detail is that the BASIC compiles to a p-code run on a run 
> machine, comparable to a JVM. I might even be able to find the PC, Program 
> Counter or IA, Instruction Address, and insert some kind of trap instruction 
> opcode, that would cause it to try the select statement and see the shutdown 
> channel. But in the general case, this may be insufficient. I think a 
> "context" timeout would interrupt a properly long-running program in a way 
> that might be hard to restart if shutdown was not requested. 
> 
> As a database, there is also the possibility of deadly embrace. Killing one 
> of the two (or more) goroutines in a deadly embrace would be useful. This 
> normally occurs on poorly managed acquisition of exclusive locks on database 
> table rows. I could forcibly release a lock, but then would need extra work 
> so that a user goroutine that thinks it exclusively owns a lock, finds that 
> it does not, and would need to gracefully exit or handle the situation.
> 
> As a goroutine, each user does not have a STDIN, and STDOUT to communicate 
> with its user. Currently, the user communicates with the goroutine with a 
> socket connection. I can probably redesign, adding a new goroutine accepting 
> user requests/commands on a channel, and monitoring the shutdown channel with 
> a select in a loop. Otherwise, I could not get a goroutine to shut down if it 
> is waiting on user input from a socket, or a dropped connection, although 
> that begs the question of how to get the socket-reading goroutine to now shut 
> down.
> 
> The current Go implementation smells of cooperative multitasking. Not a bad 
> thing, per se, but makes it hard to stop in certain degenerate cases. Have I 
> missed a way to deal with some of the discussed issues?
> 
> The project has certainly been a good way to become familiar with a number of 
> the Go idioms. (BTW, I happen to *like* the current way of handling errors!)
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/622c48dd-5909-43a9-923a-ac74a7a8f0b2%40googlegroups.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+uns

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

2019-08-09 Thread Robert Engels

I'm sorry, maybe I didn't understand your original concern. There is an example of doing stream based processing in the json package (using Decoder).How is this not sufficient?The only problem I see with it is that it doesn't allow error correction/continuation, but in the modern world that seems rather rare (or very difficult to do well).-Original Message-
From: Jonathan Hall 
Sent: Aug 9, 2019 11:00 AM
To: golang-nuts 
Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

An interesting observation.Although in a sense, we already have the decoding half of that low-level streaming API exposed by way of the `json.Decoder` type.Would you be suggesting that a separate, stream-based API makes sense even within the stdlib?I'm not really sure what that separate API would look like, or do differently than my proposal (I'm open to new ideas, though).Given that the "Go way" of handling streams is with io.Reader/io.Writer (as opposed to events, for example), and the internal implementation of `json/encoding` is already so close to that, I wonder if the APIs would end up looking very much the same, anyway.JonathanOn Friday, August 9, 2019 at 5:53:41 PM UTC+2, Robert Engels wrote:In other environments (e.g. Java), the streaming processors are distinct from the instance oriented - usually for good reason as the APIs are very different - the former is usually event based, and the latter returns realized instances as a whole or an error. The streaming processors can often skip ill-formed entities, and/or have them manipulated during decoding.-Original Message-
From: Jonathan Hall 
Sent: Aug 9, 2019 10:38 AM
To: golang-nuts 
Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

Thanks for the reply. My responses inline below.On Friday, August 9, 2019 at 5:14:52 PM UTC+2, burak serdar wrote:On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall  wrote:
>
> Can you say more? Better in which way?

Better in the way that it wouldn't change existing code.That doesn't seem like a benefit, in its own rightI understand the desire not to just change code for its own sake, or add extra features nobody needs. But people have been asking for these types of features for several years.  This doesn't seem like a frivolous code change to me.  Also, I think
the use cases for existing and proposed json encoders/decoders are
different enough to justify a separate implementation.I don't think I agree with this.The proposal deals with a subset of current use cases, but not, strictly speaking, a _different set_ of use cases. And the number of commentators on the issues linked above, I think lends weight to the idea that the use cases this proposal addresses are not insignificant, or fundamentally "different".If I were to fork the standard `encoding/json` library, and add my proposed functionality, the code would still be 95% the same. Standard reasons for sharing code apply, as far as I can tell.

-- 
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 golan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/df688733-a2e9-4bc8-aa7b-09267827007a%40googlegroups.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/718e2b9e-39e2-44f2-9308-8c94e31afbff%40googlegroups.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/924142684.7377.1565381399326%40wamui-agami.atl.sa.earthlink.net.

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

On Fri, Aug 9, 2019 at 2:10 PM Robert Engels  wrote:
>
> I'm sorry, maybe I didn't understand your original concern. There is an 
> example of doing stream based processing in the json package (using Decoder).
>
> How is this not sufficient?
>
> The only problem I see with it is that it doesn't allow error 
> correction/continuation, but in the modern world that seems rather rare (or 
> very difficult to do well).

I was thinking similarly and after reading those github issues, it
looks like the main problem is with Encoder, and not with Decoder.
Encoder's problem can be solved by providing an unbuffered output
option that directly writes to the io.Writer.

I like the idea of stream-friendly marshaler/unmarshaler interfaces.

>
> -Original Message-
> From: Jonathan Hall
> Sent: Aug 9, 2019 11:00 AM
> To: golang-nuts
> Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json 
> package
>
> An interesting observation.
>
> Although in a sense, we already have the decoding half of that low-level 
> streaming API exposed by way of the `json.Decoder` type.
>
> Would you be suggesting that a separate, stream-based API makes sense even 
> within the stdlib?
>
> I'm not really sure what that separate API would look like, or do differently 
> than my proposal (I'm open to new ideas, though).
>
> Given that the "Go way" of handling streams is with io.Reader/io.Writer (as 
> opposed to events, for example), and the internal implementation of 
> `json/encoding` is already so close to that, I wonder if the APIs would end 
> up looking very much the same, anyway.
>
> Jonathan
>
>
> On Friday, August 9, 2019 at 5:53:41 PM UTC+2, Robert Engels wrote:
>>
>> In other environments (e.g. Java), the streaming processors are distinct 
>> from the instance oriented - usually for good reason as the APIs are very 
>> different - the former is usually event based, and the latter returns 
>> realized instances as a whole or an error. The streaming processors can 
>> often skip ill-formed entities, and/or have them manipulated during decoding.
>>
>> -Original Message-
>> From: Jonathan Hall
>> Sent: Aug 9, 2019 10:38 AM
>> To: golang-nuts
>> Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json 
>> package
>>
>> Thanks for the reply. My responses inline below.
>>
>> On Friday, August 9, 2019 at 5:14:52 PM UTC+2, burak serdar wrote:
>>>
>>> On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall  wrote:
>>> >
>>> > Can you say more? Better in which way?
>>>
>>> Better in the way that it wouldn't change existing code.
>>
>>
>> That doesn't seem like a benefit, in its own right
>>
>> I understand the desire not to just change code for its own sake, or add 
>> extra features nobody needs. But people have been asking for these types of 
>> features for several years.  This doesn't seem like a frivolous code change 
>> to me.
>>
>>>
>>> Also, I think
>>> the use cases for existing and proposed json encoders/decoders are
>>> different enough to justify a separate implementation.
>>
>>
>> I don't think I agree with this.
>>
>> The proposal deals with a subset of current use cases, but not, strictly 
>> speaking, a _different set_ of use cases. And the number of commentators on 
>> the issues linked above, I think lends weight to the idea that the use cases 
>> this proposal addresses are not insignificant, or fundamentally "different".
>>
>> If I were to fork the standard `encoding/json` library, and add my proposed 
>> functionality, the code would still be 95% the same. Standard reasons for 
>> sharing code apply, as far as I can tell.
>>
>> --
>> 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 golan...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/df688733-a2e9-4bc8-aa7b-09267827007a%40googlegroups.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/718e2b9e-39e2-44f2-9308-8c94e31afbff%40googlegroups.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/924142684.7377.1565381399326%40wamui-agami.atl.sa.earthlink.net.

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

[go-nuts] [security] Go 1.11.13 and Go 1.12.8 pre-announcement

2019-08-09 Thread Filippo Valsorda

Hello gophers,

We plan to issue Go 1.11.13 and Go 1.12.8 on Tuesday, August 13.
These are minor releases to fix multiple security issues.

Following our policy at https://golang.org/security,
this is the pre-announcement of those releases.

Cheers,
Filippo on behalf of the Go team

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2B2K_KqMHGwFxx8COqfy%2BZSpkRv7T98UtvaoEsvONV2bAEbFNA%40mail.gmail.com.

[go-nuts] [security] Go 1.11.13 and Go 1.12.8 pre-announcement

2019-08-09 Thread 'Filippo Valsorda' via golang-nuts

Hello gophers,

We plan to issue Go 1.11.13 and Go 1.12.8 on Tuesday, August 13.
These are minor releases to fix multiple security issues.

Following our policy at https://golang.org/security,
this is the pre-announcement of those releases.

Cheers,
Filippo on behalf of the Go team

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2B2K_KpsShgTgano_ksbP0jdRe-dorYXQGFWnkimtTQD76EBDA%40mail.gmail.com.

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

The problem is that when encoding, even with json.Encoder, the entire 
object is marshaled, into memory, before it is written to the io.Writer. My 
proposal allows writing the JSON output immediately, rather than waiting 
for the entire process to complete successfully first.

The same problem occurs in reverse--when reading a large JSON response, you 
cannot begin processing the result until the entire result is received.

To anchor these abstract concepts to real life, let me offer an example of 
each where this is quite painful:

When writing a CouchDB document, it may contain an arbitrary amount of 
data, possibly even including BASE64-encoded attachments. For some extreme 
cases, these documents may be multiple mb. Dozens or hundreds of kb is not 
at all unusual. A typical use case may have 10k of normal JSON, with an 
additional 200k of, say, an image.  The current JSON implementation buffers 
this entire payload, ensures there are no marshaling errors, then writes to 
the `io.Writer`.  My proposal would allow writing immediately, with no need 
to buffer 100s of kb of JSON.

In the case of CouchDB, the reverse may actually be more harmful (and I've 
already gone to some lengths to mitigate the worst of it, using 
json.Decoder's tokenizer API):

A typical query returns multiple documents (which, again, may be up to 
hundreds of kb each).  With the existing implementation, one must read the 
entire resultset from the network, before parsing the first document. My 
proposal would make it possible to begin reading the individual JSON 
documents (and indeed, even individual parts of said document), without 
waiting for the entire result to be buffered.

On Friday, August 9, 2019 at 10:10:23 PM UTC+2, Robert Engels wrote:
>
> I'm sorry, maybe I didn't understand your original concern. There is an 
> example of doing stream based processing in the json package (using 
> Decoder).
>
> How is this not sufficient?
>
> The only problem I see with it is that it doesn't allow error 
> correction/continuation, but in the modern world that seems rather rare (or 
> very difficult to do well).
>
> -Original Message- 
> From: Jonathan Hall 
> Sent: Aug 9, 2019 11:00 AM 
> To: golang-nuts 
> Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json 
> package 
>
> An interesting observation.
>
> Although in a sense, we already have the decoding half of that low-level 
> streaming API exposed by way of the `json.Decoder` type.
>
> Would you be suggesting that a separate, stream-based API makes sense even 
> within the stdlib?
>
> I'm not really sure what that separate API would look like, or do 
> differently than my proposal (I'm open to new ideas, though).
>
> Given that the "Go way" of handling streams is with io.Reader/io.Writer 
> (as opposed to events, for example), and the internal implementation of 
> `json/encoding` is already so close to that, I wonder if the APIs would end 
> up looking very much the same, anyway.
>
> Jonathan
>
>
> On Friday, August 9, 2019 at 5:53:41 PM UTC+2, Robert Engels wrote:
>>
>> In other environments (e.g. Java), the streaming processors are distinct 
>> from the instance oriented - usually for good reason as the APIs are very 
>> different - the former is usually event based, and the latter returns 
>> realized instances as a whole or an error. The streaming processors can 
>> often skip ill-formed entities, and/or have them manipulated during 
>> decoding.
>>
>> -Original Message- 
>> From: Jonathan Hall 
>> Sent: Aug 9, 2019 10:38 AM 
>> To: golang-nuts 
>> Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json 
>> package 
>>
>> Thanks for the reply. My responses inline below.
>>
>> On Friday, August 9, 2019 at 5:14:52 PM UTC+2, burak serdar wrote:
>>>
>>> On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall  wrote: 
>>> > 
>>> > Can you say more? Better in which way? 
>>>
>>> Better in the way that it wouldn't change existing code.
>>
>>
>> That doesn't seem like a benefit, in its own right
>>
>> I understand the desire not to just change code for its own sake, or add 
>> extra features nobody needs. But people have been asking for these types of 
>> features for several years.  This doesn't seem like a frivolous code change 
>> to me.
>>  
>>
>>> Also, I think 
>>> the use cases for existing and proposed json encoders/decoders are 
>>> different enough to justify a separate implementation.
>>
>>
>> I don't think I agree with this.
>>
>> The proposal deals with a subset of current use cases, but not, strictly 
>> speaking, a _different set_ of use cases. And the number of commentators on 
>> the issues linked above, I think lends weight to the idea that the use 
>> cases this proposal addresses are not insignificant, or fundamentally 
>> "different".
>>
>> If I were to fork the standard `encoding/json` library, and add my 
>> proposed functionality, the code would still be 95% the same. Standard 
>> reasons for sharing code apply, as f

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

Oh, thanks for pointing that out.

it is indeed very similar to my proposal. What do you think the chances of 
getting it resurrected and merged? Is more discussion still needed with 
respect to sync.Pool?

On Friday, August 9, 2019 at 6:15:31 PM UTC+2, Ian Davis wrote:
>
> You may also be interested in a CL I created last year to add an 
> unbuffered write mode to the encoder
>
> https://go-review.googlesource.com/c/go/+/135595
>
> I think I addressed all the review comments but it stalled behind a 
> tangential issue around the current version's use of sync.Pool 
> https://github.com/golang/go/issues/27735
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8b8b8eb8-48bd-4a89-964a-52c8e7c71d39%40googlegroups.com.

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

I think you're right that most people are frustrated by the encoder, but as 
I mentioned in another message just a bit ago, the same fundamental problem 
exists with decoder, and for certain workloads, I believe it should be 
solved.

Having said that, I think tackling the writer first definitely makes the 
most sense.

With the decoder, at least it's possible, although terribly cumbersome, to 
cobble together a solution with the tokenizer interface of json.Decoder. 
And truth be told, my proposal wouldn't really elminate the use of the 
tokenizer interface--but it would make it possible to use it on a burried 
type (i.e. within a UnmarshalJSONStream() method), to achieve the benefit 
of stream reading.



On Friday, August 9, 2019 at 10:17:41 PM UTC+2, burak serdar wrote:
>
> On Fri, Aug 9, 2019 at 2:10 PM Robert Engels  > wrote: 
> > 
> > I'm sorry, maybe I didn't understand your original concern. There is an 
> example of doing stream based processing in the json package (using 
> Decoder). 
> > 
> > How is this not sufficient? 
> > 
> > The only problem I see with it is that it doesn't allow error 
> correction/continuation, but in the modern world that seems rather rare (or 
> very difficult to do well). 
>
> I was thinking similarly and after reading those github issues, it 
> looks like the main problem is with Encoder, and not with Decoder. 
> Encoder's problem can be solved by providing an unbuffered output 
> option that directly writes to the io.Writer. 
>
> I like the idea of stream-friendly marshaler/unmarshaler interfaces. 
>
> > 
> > -Original Message- 
> > From: Jonathan Hall 
> > Sent: Aug 9, 2019 11:00 AM 
> > To: golang-nuts 
> > Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json 
> package 
> > 
> > An interesting observation. 
> > 
> > Although in a sense, we already have the decoding half of that low-level 
> streaming API exposed by way of the `json.Decoder` type. 
> > 
> > Would you be suggesting that a separate, stream-based API makes sense 
> even within the stdlib? 
> > 
> > I'm not really sure what that separate API would look like, or do 
> differently than my proposal (I'm open to new ideas, though). 
> > 
> > Given that the "Go way" of handling streams is with io.Reader/io.Writer 
> (as opposed to events, for example), and the internal implementation of 
> `json/encoding` is already so close to that, I wonder if the APIs would end 
> up looking very much the same, anyway. 
> > 
> > Jonathan 
> > 
> > 
> > On Friday, August 9, 2019 at 5:53:41 PM UTC+2, Robert Engels wrote: 
> >> 
> >> In other environments (e.g. Java), the streaming processors are 
> distinct from the instance oriented - usually for good reason as the APIs 
> are very different - the former is usually event based, and the latter 
> returns realized instances as a whole or an error. The streaming processors 
> can often skip ill-formed entities, and/or have them manipulated during 
> decoding. 
> >> 
> >> -Original Message- 
> >> From: Jonathan Hall 
> >> Sent: Aug 9, 2019 10:38 AM 
> >> To: golang-nuts 
> >> Subject: Re: [go-nuts] RFC for opt-in streaming support in 
> encoding/json package 
> >> 
> >> Thanks for the reply. My responses inline below. 
> >> 
> >> On Friday, August 9, 2019 at 5:14:52 PM UTC+2, burak serdar wrote: 
> >>> 
> >>> On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall  
> wrote: 
> >>> > 
> >>> > Can you say more? Better in which way? 
> >>> 
> >>> Better in the way that it wouldn't change existing code. 
> >> 
> >> 
> >> That doesn't seem like a benefit, in its own right 
> >> 
> >> I understand the desire not to just change code for its own sake, or 
> add extra features nobody needs. But people have been asking for these 
> types of features for several years.  This doesn't seem like a frivolous 
> code change to me. 
> >> 
> >>> 
> >>> Also, I think 
> >>> the use cases for existing and proposed json encoders/decoders are 
> >>> different enough to justify a separate implementation. 
> >> 
> >> 
> >> I don't think I agree with this. 
> >> 
> >> The proposal deals with a subset of current use cases, but not, 
> strictly speaking, a _different set_ of use cases. And the number of 
> commentators on the issues linked above, I think lends weight to the idea 
> that the use cases this proposal addresses are not insignificant, or 
> fundamentally "different". 
> >> 
> >> If I were to fork the standard `encoding/json` library, and add my 
> proposed functionality, the code would still be 95% the same. Standard 
> reasons for sharing code apply, as far as I can tell. 
> >> 
> >> -- 
> >> 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 golan...@googlegroups.com. 
> >> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/df688733-a2e9-4bc8-aa7b-09267827007a%40googlegroups.com.
>  
>
>

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

On Fri, Aug 9, 2019 at 3:32 PM Jonathan Hall  wrote:
>
> I think you're right that most people are frustrated by the encoder, but as I 
> mentioned in another message just a bit ago, the same fundamental problem 
> exists with decoder, and for certain workloads, I believe it should be solved.
>
> Having said that, I think tackling the writer first definitely makes the most 
> sense.
>
> With the decoder, at least it's possible, although terribly cumbersome, to 
> cobble together a solution with the tokenizer interface of json.Decoder. And 
> truth be told, my proposal wouldn't really elminate the use of the tokenizer 
> interface--but it would make it possible to use it on a burried type (i.e. 
> within a UnmarshalJSONStream() method), to achieve the benefit of stream 
> reading.

It may not be terribly cumbersome, and may not need the tokenizer
interface. I have a json streaming library (streaming in the sense
that multiple json docs one after the other, not one large doc) based
on the std encoder/decoder, and something like that can be developed
to deal with large json docs.

https://github.com/bserdar/jsonstream




>
>
>
> On Friday, August 9, 2019 at 10:17:41 PM UTC+2, burak serdar wrote:
>>
>> On Fri, Aug 9, 2019 at 2:10 PM Robert Engels  wrote:
>> >
>> > I'm sorry, maybe I didn't understand your original concern. There is an 
>> > example of doing stream based processing in the json package (using 
>> > Decoder).
>> >
>> > How is this not sufficient?
>> >
>> > The only problem I see with it is that it doesn't allow error 
>> > correction/continuation, but in the modern world that seems rather rare 
>> > (or very difficult to do well).
>>
>> I was thinking similarly and after reading those github issues, it
>> looks like the main problem is with Encoder, and not with Decoder.
>> Encoder's problem can be solved by providing an unbuffered output
>> option that directly writes to the io.Writer.
>>
>> I like the idea of stream-friendly marshaler/unmarshaler interfaces.
>>
>> >
>> > -Original Message-
>> > From: Jonathan Hall
>> > Sent: Aug 9, 2019 11:00 AM
>> > To: golang-nuts
>> > Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json 
>> > package
>> >
>> > An interesting observation.
>> >
>> > Although in a sense, we already have the decoding half of that low-level 
>> > streaming API exposed by way of the `json.Decoder` type.
>> >
>> > Would you be suggesting that a separate, stream-based API makes sense even 
>> > within the stdlib?
>> >
>> > I'm not really sure what that separate API would look like, or do 
>> > differently than my proposal (I'm open to new ideas, though).
>> >
>> > Given that the "Go way" of handling streams is with io.Reader/io.Writer 
>> > (as opposed to events, for example), and the internal implementation of 
>> > `json/encoding` is already so close to that, I wonder if the APIs would 
>> > end up looking very much the same, anyway.
>> >
>> > Jonathan
>> >
>> >
>> > On Friday, August 9, 2019 at 5:53:41 PM UTC+2, Robert Engels wrote:
>> >>
>> >> In other environments (e.g. Java), the streaming processors are distinct 
>> >> from the instance oriented - usually for good reason as the APIs are very 
>> >> different - the former is usually event based, and the latter returns 
>> >> realized instances as a whole or an error. The streaming processors can 
>> >> often skip ill-formed entities, and/or have them manipulated during 
>> >> decoding.
>> >>
>> >> -Original Message-
>> >> From: Jonathan Hall
>> >> Sent: Aug 9, 2019 10:38 AM
>> >> To: golang-nuts
>> >> Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json 
>> >> package
>> >>
>> >> Thanks for the reply. My responses inline below.
>> >>
>> >> On Friday, August 9, 2019 at 5:14:52 PM UTC+2, burak serdar wrote:
>> >>>
>> >>> On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall  wrote:
>> >>> >
>> >>> > Can you say more? Better in which way?
>> >>>
>> >>> Better in the way that it wouldn't change existing code.
>> >>
>> >>
>> >> That doesn't seem like a benefit, in its own right
>> >>
>> >> I understand the desire not to just change code for its own sake, or add 
>> >> extra features nobody needs. But people have been asking for these types 
>> >> of features for several years.  This doesn't seem like a frivolous code 
>> >> change to me.
>> >>
>> >>>
>> >>> Also, I think
>> >>> the use cases for existing and proposed json encoders/decoders are
>> >>> different enough to justify a separate implementation.
>> >>
>> >>
>> >> I don't think I agree with this.
>> >>
>> >> The proposal deals with a subset of current use cases, but not, strictly 
>> >> speaking, a _different set_ of use cases. And the number of commentators 
>> >> on the issues linked above, I think lends weight to the idea that the use 
>> >> cases this proposal addresses are not insignificant, or fundamentally 
>> >> "different".
>> >>
>> >> If I were to fork the standard `encoding/json` library, and add my 
>> >> proposed

[go-nuts] Re: buildmode=c-archive and statically linking into another lib

2019-08-09 Thread Justin Israel

On Friday, April 12, 2019 at 1:21:25 PM UTC+12, Chao Chen wrote:
> Do you any progress to solve the problem? I meet the same problem.
> 
> 
> when I call golang build shared library on python from alpine 3.9 
> container.failed with OSError: Error relocating ./cc.so: : initial-exec TLS 
> resolves to dynamic definition in ./cc.so
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> /usr/src/app # go build -o cc.so -buildmode=c-shared main.go
> 
> 
> 
> 
> /usr/src/app # readelf -d cc.so
> 
> 
> 
> 
> Dynamic section at offset 0x10cd10 contains 22 entries:
> 
> Tag Type Name/Value
> 
> 0x0001 (NEEDED) Shared library: [libc.musl-x86_64.so.1]
> 
> 0x0010 (SYMBOLIC) 0x0
> 
> 0x000c (INIT) 0x42000
> 
> 0x000d (FINI) 0x92ed9
> 
> 0x0019 (INIT_ARRAY) 0xa2078
> 
> 0x001b (INIT_ARRAYSZ) 8 (bytes)
> 
> 0x6ef5 (GNU_HASH) 0x270
> 
> 0x0005 (STRTAB) 0xa50
> 
> 0x0006 (SYMTAB) 0x378
> 
> 0x000a (STRSZ) 1026 (bytes)
> 
> 0x000b (SYMENT) 24 (bytes)
> 
> 0x0003 (PLTGOT) 0x10deb0
> 
> 0x0002 (PLTRELSZ) 720 (bytes)
> 
> 0x0014 (PLTREL) RELA
> 
> 0x0017 (JMPREL) 0x41a00
> 
> 0x0007 (RELA) 0xe58
> 
> 0x0008 (RELASZ) 265128 (bytes)
> 
> 0x0009 (RELAENT) 24 (bytes)
> 
> 0x001e (FLAGS) SYMBOLIC BIND_NOW STATIC_TLS
> 
> 0x6ffb (FLAGS_1) Flags: NOW NODELETE
> 
> 0x6ff9 (RELACOUNT) 11040
> 
> 0x (NULL) 0x0
> 
> 
> 
> 
> /usr/src/app # python test.py
> 
> Traceback (most recent call last):
> 
> File "test.py", line 2, in 
> 
> lib = ctypes.cdll.LoadLibrary('./cc.so')
> 
> File "/usr/lib/python2.7/ctypes/init.py", line 444, in LoadLibrary
> 
> return self._dlltype(name)
> 
> File "/usr/lib/python2.7/ctypes/init.py", line 366, in init
> 
> self._handle = _dlopen(self._name, mode)
> 
> OSError: Error relocating ./cc.so: : initial-exec TLS resolves to dynamic 
> definition in ./cc.so
It looks like there was some recent activity that relates to both your musl 
compiler issue and my original issue:
https://github.com/golang/go/issues/29674

This is specifically targeting Android issues it seems. 

I stopped trying to use Go C shared libraries in C++ libs/plugins after this 
post, since it couldn't cope with large shared plugin environment platforms 
where there was a race to a limited amount of static TLS slots. But now this is 
becoming relevant for me again with the new work being done in gopy to generate 
python extensions:
https://github.com/go-python/gopy/pull/180



> On Wednesday, May 25, 2016 at 7:14:02 AM UTC+8, Justin Israel wrote:
> I've got one more question, related to this process, now that this library is 
> seeing some production use...
> 
> 
> The C++ Go binding shared library is being used as a dependency in another 
> library. This other library is a plugin that gets loaded via dlopen. I am 
> seeing the following:
> 
> 
> dlopen: cannot load any more object with static TLS
> 
> 
> In doing some research, I found that this happens when shared libs default or 
> use "-ftls-model=initial-exec" and/or don't use "-fpic". So it a situation of 
> the big pool of plugins that get dlopen'd into this particular application, 
> and the static TLS slots running out when enough of them use initial-exec. 
> 
> 
> I was looking at my shared lib that is created via "go build 
> -buildmode=c-shared -gcflags=-shared -asmflags=-shared -installsuffix=_shared 
> -a" and I do see it using "-fPIC". After doing some SO research, someone 
> suggested doing the following to determine the TLS mode that is being used:
> 
> 
> http://stackoverflow.com/questions/22983986/is-there-a-way-to-determine-thread-local-storage-model-used-by-a-library-on-linu
> 
> 
> 
> $ readelf -d libgofileseq.so | grep FLAGS
> ... (FLAGS)    SYMBOLIC STATIC_TLS
> 
> 
> 
> It seems no combination of trying to add "-ftls-model=global-dynamic" to my 
> compile process can resolve the problem. Are there any suggestions of where 
> this change can be applied, to correct the situation where dlopen fails? We 
> have found that if this plugin using this shared library gets loaded first, 
> then we don't encounter the static TLS failure. 
> 
> 
> Justin
> 
> 
> 
> 
> 
> On Wednesday, May 18, 2016 at 3:11:57 PM UTC+12, Justin Israel wrote:
> I'm wondering if someone can tell me if this is either a limitation of 
> buildmode=c-archive static libs, or if I am really just doing something wrong.
> 
> 
> Problematic steps:
> export functions to  libgofoo.a using buildmode=c-archive
> statically link libgofoo.a into another library to produce libfoo.aSomeone 
> else consumes libfoo.a and libgofoo.a in their library, and get linker errors 
> about:
> ld: libgofoo.a(go.o): relocation R_X86_64_TPOFF32 against `runtime.tlsg` can 
> not be used when making a shared object; recompile with -fPIC
> libgofoo.a: could not read symbols: Bad value
>

[go-nuts] [hooks] go get --post-download "make"

2019-08-09 Thread Dorival Pedroso

Hi, is it possible to run scripts after go get?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bf522c3f-8649-4ef7-a445-fff579d23cf7%40googlegroups.com.

Re: [go-nuts] [hooks] go get --post-download "make"

2019-08-09 Thread saurabh singh

It's possible to run go get in a make but not the other way around.
What's your use case?

On Sat, Aug 10, 2019, 7:07 AM Dorival Pedroso 
wrote:

> Hi, is it possible to run scripts after go get?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/bf522c3f-8649-4ef7-a445-fff579d23cf7%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV-XB%3DUT46ep1_MLa%3D_M-ounUbwFEdxVLa-xC3B4r7-%3DyeazA%40mail.gmail.com.

Re: [go-nuts] [hooks] go get --post-download "make"

2019-08-09 Thread Dorival Pedroso

ok. I need the other way around (go get => calls make of bash)..

thsnks

On Saturday, August 10, 2019 at 12:15:18 PM UTC+10, saurabh singh wrote:
>
> It's possible to run go get in a make but not the other way around.
> What's your use case? 
>
> On Sat, Aug 10, 2019, 7:07 AM Dorival Pedroso  > wrote:
>
>> Hi, is it possible to run scripts after go get?
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/bf522c3f-8649-4ef7-a445-fff579d23cf7%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/409f61bd-c93e-434e-a6b5-1b01af844ca0%40googlegroups.com.

[go-nuts] Re: How to propagate multiple errors using the new fmt.Errorf wrapping

2019-08-09 Thread Agniva De Sarker

Can you show me how is it possible to do with pkg/errors ? It is not 
immediately apparent to me. The Causer interface is similar to the Unwrap 
interface and errors.Cause recursively unwraps an error until it finds one 
which does not implements the causer interface. So just with 
errors.WithMessage/Wrap, you can only unwrap an error, but cannot directly 
compare a nested untyped/unnamed error variable.


On Friday, 9 August 2019 23:21:57 UTC+5:30, Alex wrote:
>
> Yes, sure. This is always possible. :-)
>
> But this is kind of writing your own error wrapper. I was just wondering 
> if this is somehow possible with the new error wrapper like it was with 
> https://github.com/pkg/errors.
>
> Am Freitag, 9. August 2019 19:35:42 UTC+2 schrieb Agniva De Sarker:
>>
>> I see. One way is to create a wrapper error type in layer1, which takes a 
>> layer2 error.  Just like os.PathError.
>>
>> package main
>>
>> import (
>> "errors"
>> "fmt"
>> )
>>
>> var (
>> // Layer1Error = errors.New("some error on layer 1")
>> Layer2Error = errors.New("some error on layer 2")
>> )
>>
>> type Layer1Error struct {
>> internal error
>> }
>>
>> func (le *Layer1Error) Error() string {
>> return fmt.Sprintf("layer2 error: %v", le.internal)
>> }
>>
>> func (le *Layer1Error) Unwrap() error {
>> return le.internal
>> }
>>
>> func main() {
>> err := callLayer1Function()
>> fmt.Println(errors.Is(err, Layer2Error))
>> var l2err *Layer1Error
>> fmt.Println(errors.As(err, &l2err))
>> }
>>
>> func callLayer1Function() error {
>> err := callLayer2Function()
>> return &Layer1Error{err}
>> }
>>
>> func callLayer2Function() error {
>> // wrap an error of Layer2 here
>> return fmt.Errorf("some specific layer2 error message: %w", Layer2Error)
>> }
>>
>>
>> On Friday, 9 August 2019 22:43:11 UTC+5:30, Alex wrote:
>>>
>>> Hi Agniva,
>>>
>>> the problem is: In the main function is no information that there was an 
>>> Layer2 error (layer2 error is not included in the error anymore).
>>> I don't know how to take the error from layer2 and wrap another error 
>>> (layer1-error) around it.
>>>
>>> You can only use the verb "%w" once in a fmt.Errorf() function afaik.
>>> So if you have a wrapped error object e1, how would you enrich / wrap 
>>> this with another error e2?
>>>
>>>
>>> Thanks,
>>> Alex
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b4b65eec-fcc9-457f-af2c-6ea99cabc49f%40googlegroups.com.

[go-nuts] Re: How to propagate multiple errors using the new fmt.Errorf wrapping