Iris has stolen code and erased contribution history. It is not a project
operated in good faith, and shouldn't be used.
On Tue, Jul 13, 2021 at 05:34 Jim Idle wrote:
> If you are just starting out, I would use Iris rather than gin-gonic. You
> can then borrow from the many examples for that fra
I don't have enough context about your development environment to say
you're using modules ·incorrectly·, but I'm fairly certain you're making
life significantly harder for yourself by trying to work with 137 (!) of
them at once. It is totally unsurprising that gopls is having trouble with
that
I've repeatedly built "service container" or "corp kits" like the one
you're describing, as well as helped a number of orgs improve their
own versions of the thing in a consultant capacity. I think everyone
has the same reaction that you do: why are we duplicating all this
effort? But I can say wit
Error messages don't include any contextual information by default. If
the path to a Go file is in there, it's because whatever created the
error message (or modified it at some point) put it there. Where is
that error created, and what touches it as it flows through the call
stack to the logging s
On Wed, Feb 21, 2018 at 1:10 PM, Bakul Shah wrote:
> On Wed, 21 Feb 2018 20:53:20 + Henrik Johansson
> wrote:
>>
>> That's not necessarily true.
>> The tool can understand from the tag and assert or even rewrite the imports
>> to make the compiler happy.
>>
>> On Wed, Feb 21, 2018, 21:51 Sam
On Wed, Feb 21, 2018 at 11:22 AM, Sam Whited wrote:
> Something that is still unclear to me even after reading todays post is how I
> would manage the various package import paths created by the import
> compatibility rule.
> The way this is currently done is through tools such as gopkg.in, will
As far as I understand it
- github.com/user/foo is expected to house package foo for SemVer 0.x.x – 1.x.x
- github.com/user/foo/v2 is expected to house package foo for SemVer 2.x.x
- github.com/user/foo/v3 is expected to house package foo for SemVer 3.x.x
And so on. Appending the additional path
I think it's cost without much benefit. By definition, if a package
exists on your filesystem, you know where it came from: you put it
there, and you can inspect the path.
On Tue, Aug 1, 2017 at 7:19 PM, roger peppe wrote:
> On 1 August 2017 at 18:04, Peter Bourgon wrote:
>> Gener
Generally nice list. I find these items controversial i.e. shorthand
for I don't agree with them ;)
- Use assert-libraries
- Don't under-package
- Use package comment
On Mon, Jul 31, 2017 at 1:39 PM, wrote:
> Hey, I just released a Go Styleguide, please let me know what you think!
>
> --
> You
ested in helping us get to a place of stability faster,
please volunteer in those tickets :)
[0] https://github.com/golang/dep/issues/225
[1] https://github.com/golang/dep/issues/291
Cheers,
Peter.
On Thu, Apr 13, 2017 at 9:25 AM, Peter Bourgon wrote:
> And an update: thanks to the excellent
!
[0] https://github.com/golang/dep/pull/342
On Tue, Mar 28, 2017 at 10:38 AM, Peter Bourgon wrote:
> On Tue, Mar 28, 2017 at 3:14 AM, Russ Cox wrote:
>> On Mon, Mar 13, 2017 at 5:09 PM, Russ Cox wrote:
>>>
>>> By far the most important things to do with
he mark here?
>
> On Tuesday, March 28, 2017 at 5:39:06 AM UTC-3, Peter Bourgon wrote:
>>
>> On Tue, Mar 28, 2017 at 3:14 AM, Russ Cox wrote:
>> > On Mon, Mar 13, 2017 at 5:09 PM, Russ Cox wrote:
>> >>
>> >> By far the most important things to d
On Tue, Mar 28, 2017 at 3:14 AM, Russ Cox wrote:
> On Mon, Mar 13, 2017 at 5:09 PM, Russ Cox wrote:
>>
>> By far the most important things to do with dep right now are (1) build
>> something people can use and get benefit from today and eliminate blockers
>> to adoption and (2) based on experienc
// establish the net.UDPConn and context.Context here.
go func() {
for {
if err := conn.Read(p); err != nil {
return
}
// do something with p
}
}()
go func() {
<-ctx.Done()
conn.Close() // will interrupt the above goroutine with an error
ret
On Tue, Mar 21, 2017 at 10:34 PM, wrote:
> So I am new to Go and upon developing some things I am curious about best
> practices for building/releasing libraries which will be used by other
> programs in Go.
>
> Coming from a Java world, when you build a library, you build an actual
> artifact
On Fri, Nov 25, 2016 at 12:53 AM, Brad Fitzpatrick wrote:
> In light of the CEO of Reddit admitting to editing user comments (see dozen
> news stories today), I propose we delete the /r/golang subreddit.
That would be a dramatic overreaction, and a real shame.
> That is so beyond unethical and
You might want to take a look at https://github.com/marcusolsson/goddd
and https://github.com/go-kit/kit/tree/master/examples/shipping.
On Mon, Oct 31, 2016 at 12:02 PM, JM wrote:
> im building a micro service layer using the following folder structure. I
> have unit tests for everything and eac
. wrote:
> Yes, through plain assignment. What problems arise from that?
>
> On Monday, September 12, 2016 at 11:21:05 PM UTC+8, Peter Bourgon wrote:
>>
>> How are you replacing the reference to the original map? If you're
>> just using plain assignment e.g. x.myMap
How are you replacing the reference to the original map? If you're
just using plain assignment e.g. x.myMap = newMap then that's not
safe. You could use sync/atomic.Value if you always made sure to do
map reads via the Load method.
On Mon, Sep 12, 2016 at 5:04 PM, sqweek E. wrote:
> Ok so after g
As a reminder, in July I started the Go Packaging Proposal doc[0] with
the goal “To produce, have accepted, and implement a complete proposal
which addresses the concern of package management.” Thanks to everyone
who’s signaled interest. That process involves creating a small
committee to drive the
Slack peterbourgon.
On Fri, Jul 29, 2016 at 9:45 AM, Peter Bourgon wrote:
> Hello,
>
> For well over a year, a group of dedicated Gophers have been
> discussing the package management situation on a dedicated mailing
> list, in Slack #vendor, and several communication channels
Ah! Ha. All good.
On Sat, Aug 6, 2016 at 17:51 'Jessica Frazelle' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> Sorry Peter that got stuck in moderation I wrote it before your other
> message
>
> On Saturday, August 6, 2016, Peter Bourgon wrote:
>
&
Again, there is no nomination process for the committee right now. Please
don't propose yourself or others.
On Sat, Aug 6, 2016 at 17:11 'Jessica Frazelle' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> +1 to Dave Cheney.
>
> I agree we need as simple a solution as possible.
>
> I propos
c940d7bd55644
>>
>> I am seeking a second for my nomination.
>>
>> Thank you
>>
>> Dave
>>
>> On Friday, 29 July 2016 17:46:01 UTC+10, Peter Bourgon wrote:
>>>
>>> Hello,
>>>
>>> For well over a year, a group of dedicated
nd
comment.
https://docs.google.com/document/d/18tNd8r5DV0yluCR7tPvkMTsWD_lYcRO7NhpNSDymRr8
As much as anything can be official, I hope that this will be the
official process, leading to the long-desired blessed solution.
Regards,
Peter Bourgon.
--
You received this message because you are sub
On Fri, Jul 8, 2016 at 6:29 AM, wrote:
> Hey All,
>
> Originally asked on twitter but a more long-form medium is required to
> answer this question. I've recently been working on adding logging to a
> library and have been replacing what was once a custom logging interface
> with just *log.Logger
On Tue, Jul 5, 2016 at 9:19 PM, Sam Whited wrote:
> On Tue, Jul 5, 2016 at 1:52 PM, Peter Bourgon wrote:
>> Since you removed the vendor/ directory from jitsi/jap, everything is
>> working as expected, right?
>
> Yes, but the vendor dir was in the application code, not the
Since you removed the vendor/ directory from jitsi/jap, everything is
working as expected, right?
On Tue, Jul 5, 2016 at 8:46 PM, Sam Whited wrote:
> On Tue, Jul 5, 2016 at 1:37 PM, Peter Bourgon wrote:
>> As of today, if your binary vendors any other package, you need to
>> ensu
On Tue, Jul 5, 2016 at 7:24 PM, Sam Whited wrote:
> On Tue, Jul 5, 2016 at 12:15 PM, Keith Rarick wrote:
>> You don't have to vendor anything from your own repo, but you do have to
>> vendor everything from outside your repo. (To be precise, the distinction is
>> between inside and outside the di
29 matches
Mail list logo
