Hello,
Thanks for the answer. I've still some question then. The whole point of my
poc was to be able to get the LLVMIR of GO then put it into an iOS app with
bitcode enable. What are you saying is that it is not possible to achieve
this? Or it's possible but I've to add the missing symbols? If is
Hi!
On Mon, Jan 3, 2022 at 5:34 PM Gaurav Maheshwari
wrote:
> 1. Do you think it would be better to expose methods which can allow to
> control Stack depth, e.g. it is quite common to wrap external libraries in a
> thin-proxy library in large codebases but dropping proxy layer from
>
On Mon, Jan 3, 2022 at 9:48 PM Davi Marcondes Moreira
wrote:
> I've read the docs for https://pkg.go.dev/go/build and
> https://pkg.go.dev/cmd/go#hdr-Build_constraints but I couldn't find anything
> explicitly related to test execution.
It is not related to test execution. The build system
Hi, happy new year y'all! I just want to make sure of something, probably
it's just a boolean question (yes/no).
I've been working on a project where all test files are declaring a build
constraint at the first line, like the ones below:
// +build unit
or
// +build integration
When I run the
Did you check https://github.com/cockroachdb/errors ? How does it differ
from cockroachdb/errors?
On Mon, 3 Jan 2022 at 08:05, Mitar wrote:
> Hi!
>
> I have recently published a new package which provides errors with a
> stack trace, similar to now archived github.com/pkg/errors, but
>
Thanks for the detailed comparison. I do agree that a leaner library as a
base library is better for a lot of use-cases.
Few questions/suggestions on the APIs:
1. Do you think it would be better to expose methods which can allow to
control Stack depth, e.g. it is quite common to wrap external
Hi!
Yes, I have. My view is that both github.com/pkg/errors and
gitlab.com/tozd/go/errors aim at being more or less a drop-in
replacement for core errors, but adding stack traces to errors. Since
Go has now Errorf which can wrap existing errors to augment their
messages, the utility functions in
