On Fri, Aug 7, 2015 at 4:07 AM William Reade william.re...@canonical.com
wrote:
I'm not strongly attached to my clock; I hacked it together because I
needed it, and the only remotely interesting feature is `Alarm(t time.Time)
-chan time.Time` which is just `return
Just some context - Ben Johnson is an active member of the Go community,
works in Go every day, and has several popular packages in use by many
third parties. I would not worry about depending on his work from a
quality or responsiveness aspect.
As with John, I haven't looked at the exact code,
Hi,
I'd like to add a new third-party dependency for testing:
github.com/benbjohnson/clock. I intend to use this for testing forthcoming
retry scheduling logic in the storage provisioner. Any objections?
Cheers,
Andrew
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or
On 29 May 2014 21:48, William Reade william.re...@canonical.com wrote:
Masking is often necessary, and information hiding is valuable, and
depending on spooky action at a distance is generally foolish. But the
granularity with which we want to track the propagation of a given error is
*much*
On 29 May 2014 20:00, Jeroen Vermeulen jeroen.vermeu...@canonical.com wrote:
On 2014-05-29 09:50, roger peppe wrote:
On 29 May 2014 04:03, Tim Penhey tim.pen...@canonical.com wrote:
Errors are worth treating specially here because they're
they pass up through multiple layers, so it's very
On 2014-05-30 15:08, roger peppe wrote:
Two: a caller can deal better with some errors, given more detailed
information. You can help by attaching more information to the error (tags,
taxonomy, properties) but only on a best-effort basis. You accept that you
don't know exactly which errors
On 29 May 2014 04:03, Tim Penhey tim.pen...@canonical.com wrote:
On 29/05/14 01:11, roger peppe wrote:
Writing code to explicitly declare function return types is also
a perpetual drag on refactoring, but it's also incredibly useful.
The set of possible returned errors *should* be part of the
On 28 May 2014 19:40, Nate Finch nate.fi...@canonical.com wrote:
I think the main problem with errgo as it exists, is that it is very awkward
to allow error type information to pass through:
return errgo.Mask(err, errgo.Any)
This line is very misleading. It's saying - mask the error
On 2014-05-29 09:50, roger peppe wrote:
On 29 May 2014 04:03, Tim Penhey tim.pen...@canonical.com wrote:
Errors are worth treating specially here because they're
they pass up through multiple layers, so it's very easy to break abstraction
boundaries by relying on specific error types. I
What Roger is talking about, is when an error is implementation-specific
and may change if the implementation changes.
For example, if you have a black box service that saves data, it might
write to the network or it might write to a filesystem, but where it saves
is an implementation detail.
Note that this kind of error masking doesn't need to be done in the same
package as the base error package. I made a little standalone package
http://godoc.org/github.com/natefinch/filterr that does it, we could do
something similar if we wanted to keep the error package simpler (which is
always
Masking is often necessary, and information hiding is valuable, and
depending on spooky action at a distance is generally foolish. But the
granularity with which we want to track the propagation of a given error is
*much* finer than the granularity of judicious information hiding: the
error is
On 28 May 2014 00:46, William Reade william.re...@canonical.com wrote:
Roger
We have had many long discussions, and you have provided much valuable
input: in particular, explaining to us that we were completely off-base re:
the attempts to use a slice vs a linked list in the error stacks. And
I just saw this thread after replying to the other one.
Fundamentally, I think comparing errors for equality
is misguided. That said, a simple approach that
doesn't use DeepEquals is possible:
func sameError(e1, e2 error) bool {
defer func() { recover() }()
return e1 == e2
}
On 28 May
I haven't seen any code or a description of what you're doing, so it's
really hard for me to help.
Broadly, what are you trying to accomplish? Maybe we can help avoid the
need to do something that Go doesn't support well.
On Tue, May 27, 2014 at 9:43 PM, Tim Penhey
I propose we change the name of the package to something other than errgo,
so that Roger can keep his name, and we can make the behavior whatever fits
best for Juju. Yes, we should make it a general-use package, but it should
be designed for Juju, meeting our needs. Roger can post errgo wherever
On 27 May 2014 04:02, Tim Penhey tim.pen...@canonical.com wrote:
On 23/05/14 02:47, roger peppe wrote:
Any particular reason to wrap the errgo functions rather than using errgo
directly? Personally, I see the role of the errors package to be about
specific error classifications (something that
Roger
We have had many long discussions, and you have provided much valuable
input: in particular, explaining to us that we were completely off-base re:
the attempts to use a slice vs a linked list in the error stacks. And we
did indeed agree to use errgo (as the only proposed implementation that
On 28/05/14 12:43, Nate Finch wrote:
This sounds like one of those if you have to ask this question, you're
doing something wrong.
Can you give an example of where we need this?
Sure... let's say we have a stack of errors, for simplicity of the
argument lets say it is a slice of error
On 28/05/14 13:31, Nate Finch wrote:
If you're talking about errgo, if all we care about is transition, but
not what the actual types are, we could just record in the list when we
mask the type.
We could, but that would mean walking the list every time you want to
check the cause. It would
On Wed, May 28, 2014 at 8:47 AM, Tim Penhey tim.pen...@canonical.comwrote:
On 28/05/14 12:43, Nate Finch wrote:
This sounds like one of those if you have to ask this question, you're
doing something wrong.
Can you give an example of where we need this?
Sure... let's say we have a stack
On 28/05/14 13:48, Andrew Wilkins wrote:
On Wed, May 28, 2014 at 8:47 AM, Tim Penhey tim.pen...@canonical.com
mailto:tim.pen...@canonical.com wrote:
On 28/05/14 12:43, Nate Finch wrote:
This sounds like one of those if you have to ask this question,
you're
doing something
On Wed, May 28, 2014 at 9:52 AM, Tim Penhey tim.pen...@canonical.comwrote:
On 28/05/14 13:48, Andrew Wilkins wrote:
On Wed, May 28, 2014 at 8:47 AM, Tim Penhey tim.pen...@canonical.com
mailto:tim.pen...@canonical.com wrote:
On 28/05/14 12:43, Nate Finch wrote:
This sounds like
On Wed, May 28, 2014 at 10:39 AM, John Meinel j...@arbash-meinel.comwrote:
The address of the real value is the same.
Are you referring to the backing array? That is not what is being compared,
so that's not a useful property.
John
=:-
On May 28, 2014 6:04 AM, Andrew Wilkins
I think we need concrete examples which Tim should have in the test suite.
John
=:-
On May 28, 2014 6:50 AM, Andrew Wilkins andrew.wilk...@canonical.com
wrote:
On Wed, May 28, 2014 at 10:39 AM, John Meinel j...@arbash-meinel.comwrote:
The address of the real value is the same.
Are you
On 28/05/14 15:48, John Meinel wrote:
I think we need concrete examples which Tim should have in the test suite.
John
=:-
On May 28, 2014 6:50 AM, Andrew Wilkins andrew.wilk...@canonical.com
mailto:andrew.wilk...@canonical.com wrote:
On Wed, May 28, 2014 at 10:39 AM, John Meinel
On 14 May 2014 10:24, Tim Penhey tim.pen...@canonical.com wrote:
Hi all,
I took it upon myself to get Rog's errgo library used inside juju-core.
Thanks for doing this.
Dimiter recently did a hunk of work in the juju-core/errors package to
have functions to add context to some core error
I agree with Roger, I don't think a wrapper around Errgo is the right way
to go. If we don't like the way errgo behaves, we should change it. It's
our package, let's have it work the way we want it to work.
On Thu, May 22, 2014 at 10:47 AM, roger peppe rogpe...@gmail.com wrote:
On 14 May 2014
Hi all,
I took it upon myself to get Rog's errgo library used inside juju-core.
Dimiter recently did a hunk of work in the juju-core/errors package to
have functions to add context to some core error types while keeping
their type.
What I did was to move this errors package out of juju-core and
I'd like gccgo to pass reliably, but I think it falls under a CI test
rather than a pre-commit test. (Because otherwise it roughly doubles the
time it takes to know whether your patch will land.)
I don't have specific feedback on the behavior differences, but the changes
seem sane to me. An
On Wed, May 14, 2014 at 8:12 AM, John Meinel j...@arbash-meinel.com wrote:
I'd like gccgo to pass reliably, but I think it falls under a CI test rather
than a pre-commit test. (Because otherwise it roughly doubles the time it
takes to know whether your patch will land.)
I agree. We can setup
On 6 February 2014 22:00, Nate Finch nate.fi...@canonical.com wrote:
So, I took a deeper dive into Tim's newly renamed arrar package, and
compared it to Roger's errgo package.
Before I go into the implementations, I want to write down some goals:
1: Make it easy to wrap errors from deeper in
On Fri, Feb 7, 2014 at 5:24 AM, roger peppe rogpe...@gmail.com wrote:
http://play.golang.org/p/Ze_YTCcfzm
Note that, even ignoring the doc comment, it is easy to tell by
looking at the high
level function, ReadPacketFromNetwork, what classifiable errors might
be returned from
it. This
On 7 February 2014 12:14, Nate Finch nate.fi...@canonical.com wrote:
On Fri, Feb 7, 2014 at 5:24 AM, roger peppe rogpe...@gmail.com wrote:
http://play.golang.org/p/Ze_YTCcfzm
Note that, even ignoring the doc comment, it is easy to tell by
looking at the high
level function,
On 06/02/14 14:14, Nate Finch wrote:
One thing I noticed was that it looked like it wasn't generating an
actual stack trace ever. I think that's pretty critical to knowing how
you got to the spot where you got the error.
I made the default behaviour of the error message to match exactly what
So, I took a deeper dive into Tim's newly renamed
arrarhttps://godoc.org/github.com/juju/arrarpackage, and compared it
to Roger's
errgohttps://godoc.org/launchpad.net/~rogpeppe/errgo/errors-package/errorspackage.
Before I go into the implementations, I want to write down some goals:
1: Make it
On 04/02/2014, Tim Penhey tim.pen...@canonical.com wrote:
Docs need a little work.
Can you give us an inspirational example of an error message made
clearer at least?
I know Roger has hacked on something along these lines in the past,
I'm curious to hear his thoughts on your stab at tracebacks
37 matches
Mail list logo
