context: ease debugging of where a context was canceled?

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.10 linux/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/matthew/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/matthew/work"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build356255000=/tmp/go-build -gno-record-gcc-switches"
What did you do?
used context.WithTimeout() to make requests to google calendar api and outlook calendar api
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
What did you expect to see?
Making requests using contexts with timeouts should cancel when the timeout is reached
What did you see instead?
Contexts with timeouts are instantly failing with "context canceled" even though the timeout is set to time.Minute. The error goes away if I remove the timeout context and use one without any limit. It also seems to be transient to some extent

Sorry, but there isn't enough information here to say anything useful.  Please show us your code, or tell us how to recreate the problem.  Thanks.

import (
"net/http"
"os"
"time"
"golang.org/x/net/context"
"golang.org/x/oauth2"
"golang.org/x/oauth2/google"

)
var (
backgroundContext = context.Background()
oauthConfig       = &oauth2.Config{
ClientID:     os.Getenv("GOOGLE_PROJECT_CLIENT_ID"),
ClientSecret: os.Getenv("GOOGLE_PROJECT_SECRET_KEY"),
Endpoint:     google.Endpoint,
}
)
type calendarClient struct {
*calendar.Service
requestTimeout time.Duration
}
// NewCalendarClient creates a new authenticated Google Calendar client.
func NewCalendarClient(refreshToken string) (wf.Client, error) {
client, err := newClient(refreshToken)
if err != nil {
return nil, err
}
service, err := calendar.New(client)
if err != nil {
	return nil, err
}

return &calendarClient{Service: service, requestTimeout: time.Minute}, nil

}
func newClient(refreshToken string) (*http.Client, error) {
contextWithTimeout, cancel := context.WithTimeout(backgroundContext, time.Minute)
defer cancel()
return oauthConfig.Client(contextWithTimeout, &oauth2.Token{RefreshToken: refreshToken}), nil
}
func (client *calendarClient) GetCalendars() (*calendar.CalendarList, error) {
contextWithTimeout, cancel := context.WithTimeout(backgroundContext, time.Minute)
defer cancel()
return client.CalendarList.List().Context(contextWithTimeout).Do()
}
The issue is that when we call GetCalendars for example, it will instantly return "context canceled". When I use an empty context with no timeout, everything works as expected. This all began failing in the past couple of days since updates were made in the /x/net package

NewClient:

The returned client is not valid beyond the lifetime of the context.

But your code has:
func newClient(refreshToken string) (*http.Client, error) {
    contextWithTimeout, cancel := context.WithTimeout(backgroundContext, time.Minute)
    defer cancel()
    return oauthConfig.Client(contextWithTimeout, &oauth2.Token{RefreshToken: refreshToken}), nil
}

The defer cancel() causes the context to be cancelled before the client even gets to calendar.New.

I've seen this sort of issue crop up several times now.
I wonder if context.Context should record a bit of caller information (say, the PC of the immediate calling function) in context.WithTimeout and in calls to the CancelFunc returned by context.WithCancel. Then we could add a debugging hook to interrogate why a particular context.Context was cancelled.
Perhaps something along the lines of:
package context

// A DoneReasoner describes the reason a Context is done.
// The Context implementations returned by this package implement DoneReasoner.
type DoneReasoner interface {
	DoneReason() string
}

// DoneReason returns a human-readable description of the reason that ctx.Done() is closed,
// or the empty string if ctx.Done() is not closed.
func DoneReason(ctx context.Context) string {
	select {
	case <-ctx.Done():
	default:
		return ""
	}
	if r, ok := ctx.(DoneReasoner); ok {
			return r.DoneReason()
	}
	return ctx.Err().Error()
}

(CC @Sajmani @bradfitz for Context debuggability.)

@meirf I think there was a misunderstanding in how I described the problem. This code has always been using two contexts like I described but only in the past two days since we pulled updates to the vendor package did it start failing. There were not any changes whatsoever related to any of this code for several months besides pulling in the package update.
Only after we pulled in the update and everything started failing, we switched to contexts without timeouts and started seeing things succeed. If your explanation is correct, the defer cancel was not previously working as expected. Otherwise your explanation is not correct

Do you happen to have a record of which revision of the context package you were using previously, and which one you updated to?

only in the past two days since we pulled updates to the vendor package did it start failing.

Which vendored packages did you update? (Just x/net, or also x/oauth2?)

I've narrowed down the precise commit where things began to fail, and there are more vendor updates here than I'd previously thought. It looks like both packages (x/net and x/oauth2) were updated and that the previous version was decently old such that it may be very difficult to narrow anything down, but here are a couple of samples from the revisions:
"checksumSHA1": "dr5+PfIRzXeN+l1VG+s0lea9qz8=",		=>	"checksumSHA1": "GtamqiJoL7PGHsN454AoffBFMa8=",
"path": "golang.org/x/net/context",	 		=>	"path": "golang.org/x/net/context",
"revision": "f5079bd7f6f74e23c4d65efa0f4ce14cbd6a3c0f",	=>	"revision": "1e491301e022f8f977054da4c2d852decd59571f",
"revisionTime": "2017-07-19T21:11:51Z"			=>	"revisionTime": "2018-05-30T06:29:46Z"
"checksumSHA1": "hyK05cmzm+vPH1OO+F1AkvES3sw=",	        => "checksumSHA1": "xaHFy3C2djwUXtiURpX3/ruY8IA=",
"path": "golang.org/x/oauth2",	 		        => "path": "golang.org/x/oauth2",
"revision": "314dd2c0bf3ebd592ec0d20847d27e79d0dbe8dd",	=> "revision": "1e0a3fa8ba9a5c9eb35c271780101fdaf1b205d7",
"revisionTime": "2016-12-14T09:25:55Z"	                => "revisionTime": "2018-06-02T17:55:33Z"
Also, I re-tested the above code by leaving everything the same and completely removing the second context.WithTimeout inside of GetCalendars such that only the client has a timeout configured, and I see the same error

https://golang.org/cl/45370 is in that range and loosely matches @meirf's diagnosis. It looks like your vendor update uncovered a latent bug within your code.

I've confirmed that commenting out the defer cancel() inside of newClient does in fact successfully return our calendar data as expected, but it is still not matching what was diagnosed above since when the error occurs it is on GetCalendars, it isn't canceling prior to Calendar.New
Is the expectation that we exercise the client we retrieve to its fullest extent only to call cancel() at the last moment? And that if it's set on this client we shouldnt even need to bother with client.CalendarList.List().Context(), correct?
Can we rely on GC and just not bother holding onto the cancel func?

@fraenkel I'm fine with whichever, but doesn't putting it on the client prevent me from needing to duplicate this context code across all calls?

@matthewceravolo, please don't retitle the bug. We have a convention for how we use titles.
It still reads above like this is user error and you got lucky in the past, so I'd like to keep this bug about thinking about ways to make this debugging easier for other users making similar errors.

@bcmills I wouldn't use type assertion to introspect a Context because they are wrapped so often. If you want to attach a Done reason to a Context, I'd use a Context value.  This is overhead, though, so I'd make it opt-in in somehow. Perhaps provide a context.WithDebug method that adds a Context value for storing debugging info. The code in WithTimeout and WithCancel can check for this debug value to decide whether to walk the stack to record any information there.  The debug value needs to be installed at the top of the context stack to be seen by all derived contexts, so I'd enable it in the request handler (say) with a parameter like ?debugcontext=1.

I wouldn't use type assertion to introspect a Context because they are wrapped so often.

Good point. A Context.Value call with an exported (but opaque) key to retrieve the reason code should be fine.

If you want to attach a Done reason to a Context, I'd use a Context value. This is overhead, though, so I'd make it opt-in in somehow. Perhaps provide a context.WithDebug method that adds a Context value for storing debugging info. The code in WithTimeout and WithCancel can check for this debug value to decide whether to walk the call stack and record any information there.

Ironically, Context.Value is O(N) with the depth of Context nesting, whereas runtime.Caller(1) is O(1): the mere act of checking whether debugging is enabled may be significantly more costly than storing the debug information unconditionally.

I would store a *debug in the context to flatten the lookup, leaving it nil
when debugging is disabled.  Associating that debug value with an
unexported context key allows the debug info to propagate through Context
implementations outside the context package.
On Tue, Jul 17, 2018 at 3:52 PM Bryan C. Mills<EMAIL_ADDRESS>wrote:

I wouldn't use type assertion to introspect a Context because they are
wrapped so often.
Good point. A Context.Value call with an exported (but opaque) key to
retrieve the reason code should be fine.
If you want to attach a Done reason to a Context, I'd use a Context value.
This is overhead, though, so I'd make it opt-in in somehow. Perhaps provide
a context.WithDebug method that adds a Context value for storing debugging
info. The code in WithTimeout and WithCancel can check for this debug value
to decide whether to walk the call stack and record any information there.
Ironically, Context.Value is O(N) with the depth of Context nesting,
whereas runtime.Caller(1) is O(1): the mere act of checking whether
debugging is enabled may be significantly more costly than storing the
debug information unconditionally.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/26356#issuecomment-405705926, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJSK3TSfBWY21reU6GLskizNeC3fM3mEks5uHkBugaJpZM4VNsJ2
.

I wonder if errors might be a good solution for this problem? Rather than have duplicate information propagated in the context, just rely on the error returned when the context is cancelled to get a stack trace.

@Xopherus, that's a different problem from the one here. The first error upon cancellation arises at a call to ctx.Err(), which is arbitrarily far away from the call to the cancel() function.
This issue centers on identifying the call to the cancel function, not the call to the Err method.

@bcmills I think they're actually both the same - at least the implementation would the same for context.WithCancel. The timeout/deadline contexts would have slightly different implementations.
The cancelFunc returned by context.WithCancel is an anonymous function which sends an error to c.cancel which triggers the cancellation. That error is currently a global var, but what if we instead created that error within the cancelFunc using the new experimental errors package. We'd get information about which cancelFunc was called within the error itself. I can imagine with some slight refactoring we may be able to do the same for the other contexts.

@Xopherus, tons of code today uses == to compare against context.Canceled. We can't realistically change that to instantiate a new error for each call site.

Forgive my ignorance, but isn't that a big part of the errors experiment that's going on right now? I was under the impression that Go would be moving away from == for error inspection and to errors.As or errors.Is. I 100% agree with you that we should avoid breaking changes, so I'd like to find a way to do this in a graceful manner. Maybe that's already being discussed in other areas of the language?

errors.Is would allow us to return per-instance errors in a new API, but we cannot assume that existing code (using the existing API) will be updated to use that check. Compatibility requires that we not break programs that rely on today's documented behavior.

IMHO it's a common pain point within the community to arbitrarily receive a context.Canceled and not know what to do with it.
I feel like amending what context.WithCancel is the wrong solution though. The amount of code manually checking for cancellation is likely high.
Would a context.WithCanceler(context.Context) (cxt context.Context, canceler func(error)) be a decent compromise, with the argument to canceler propagated to all calls of ctx.Err()?
There is likely to be concerns of memory leaks, but having documentation that asks users to use constants and corresponding go vet checks could work well.

I have same problem and don't know how to debug this. The "CURRENT" below randomly produces:
&{%!t(string=context canceled)}
*errors.errorString

CURRENT
// ctx is `*http.Request.Context` which come from the handler.
func Insert(ctx context.Context) error {
	ctx, cancel := context.WithTimeout(ctx, 3 * time.Millisecond)
	defer cancel()

	qry := `INSERT INTO users (name) VALUES (?)`

	res, err := r.database.ExecContext(ctx, qry, "hello")
	// ....
}

WORK FINE
func Insert() error {
	ctx, cancel := context.WithTimeout(context.Background(), 3 * time.Millisecond)
	defer cancel()

	qry := `INSERT INTO users (name) VALUES (?)`

	res, err := r.database.ExecContext(ctx, qry, "hello")
	// ....
}

@BentCoder the difference between your CURRENT and WORKS FINE is the use of context.Background() instead of ctx. The context.Canceled error must be coming from ctx, since context.Background() is never canceled. (If the WithTimeout had expired, the error would be context.DeadlineExceeded).

Are there any updates on how to continue with this topic?
While I like the proposals from @bcmills to add a DoneReasoner or @neetle's one to add a description parameter to the CancelFunc to describe the reason for canceling a context, it only once gets beneficial when the ecosystem uses them in order to improve logging.
Adding a "stacktrace" as a context value on the other hand would already allow us to see where a new context was created and when resolving tha stacktrace context value, we could also see which one got canceled.

My project has been suffering from this issue, so I really like to see it resolved.
I think https://github.com/golang/go/issues/35791#issuecomment-649660330 by @Sajmani is a great summary of compatibility requirements. Unfortunately @neetle's proposed context.WithCanceler in https://github.com/golang/go/issues/26356#issuecomment-592342591 breaks API compatibility. @bcmills's proposed DoneReasoner in https://github.com/golang/go/issues/26356#issuecomment-404870718 keeps API compatibility, but IIUC optional interfaces are generally not liked (e.g. https://github.com/golang/go/issues/28728#issuecomment-532834952).
Just my two cents, but I have another idea. We can annotate errors if we could check if a deadline applied to a context was expired. I'm thinking of functions like this (pardon me for naive naming, it's just for explanation):
type CheckFunc func() bool

// WithCheckableDeadline is similar to WithDeadline, but it also returns CheckerFunc,
// which returns true if the current time is after t.
func WithCheckableDeadline(ctx Context, t time.Time) (Context, CheckFunc, CancelFunc)

// WithCheckableTimeout is similiar to WithCheckableDeadline above, but accepts a timeout.
func WithCheckableTimeout(ctx Context, d time.Duration) (Context, CheckFunc, CancelFunc)

We can use these functions to annotate errors on hitting timeouts, e.g.
func f(ctx context.Context) error {
  ctx, check, cancel := context.WithCheckableTimeout(ctx, 10 * time.Second)
  defer cancel()

  if err := someLongOperation(ctx); err != nil {
    if check() {
      return fmt.Errorf("f timeout reached: %w", err)
    }
    return err
  }
  return nil
}

Please note that calling CheckFunc is different from calling Deadline of an associated context and comparing it with the current time, because Deadline may return a deadline earlier than one applied with context.WithDeadline when a parent context has a deadline.

I'm going to think on this for a bit.

Are there any news on it?
I see a lot of "context canceled" errors which are not handled as there is no good way to investigate the root cause for those.

I am running into this trying to track down why a newly generated Buffalo app gives me context cancelled when trying to run in terminal on macOS, but not when running within GoLand where I could more easily debug it.:-(

Yes, agree.
On one of our enterprise systems we have random spikes from time to time.
And it's very hard to prove network administrators that it's network related because I'm not sure 100% about the root cause.

For those of you on this thread looking for an immediate fix, using an errors.Is-compatible library that wraps errors with stack traces could be a good solution. You would need to make sure all of your code uses errors.Is and errors.As instead of error equality, and you would need to return Wrap(ctx.Err()) instead of ctx.Err() directly, but it would otherwise give you stack traces. I personally like http://pkg.go.dev/github.com/zeebo/errs/v2

For me, it is potentially returned from the standard library (http).
So I am not controlling it.

Half the issue tends to be that we're compensating for poorly-written code here, rather than well-written code. "Just wrap the error" doesn't give an appropriate error when the context is cancelled by another thread entirely (see: spooky-action-at-a-distance)

I had less time to work on this than I hoped, sorry. Unassigning myself to open this up for others.

this is the problem i have currently and its beyond annoying,
i question myself: "Who the hell canceled my context and why?"  and it all happens in 3rd party code you cant control, good luck me at debugging this on a remote environment

imo context's Cancel() should receive argument 'reason string' so its somewhat debuggable, currenetly theres just stupid 'context canceled' constant that does not say anything about the context of cancellation

imo context's Cancel() should receive argument 'reason string' so its somewhat debuggable, currenetly theres just stupid 'context canceled' constant that does not say anything about the context of cancellation

#46273 suggests this as context.WithCancelReason.

I prototyped an API-compatible idea to just capture the call stack of WithCancel/Timeout/Deadline and provide a way to access it as a string. Would this be enough? We'd have to measure the time & space overheads:
https://go-review.googlesource.com/c/go/+/375977

I would really like that one could pass optional value to cancel and then one can include whatever you want there (an error, an error with a stack trace, a string). So the same as how you can pass to panic something.

I prototyped an API-compatible idea to just capture the call stack of WithCancel/Timeout/Deadline and provide a way to access it as a string. Would this be enough?

It's much better than nothing but, in the context of CockroachDB, it's not ideal. We too would like to pass a string as the cancellation reason. The stack trace will likely be quite ambiguous in many places, as various short-circuits will result in the same defer cancel() to fire.
I'm glad this issue is on the radar, though. It's a major pain for us, and a constant source of fights about the technicalities of how to hack around it.

@andreimatei @mitar I can prototype a way to pass in the string; my focus here is keeping the existing API backwards-compatible.
My interest in using the stack trace is that it improves debuggability for all existing code you don't need to change any of the cancelation sites to start getting the stack traces. This comes at the expense of capturing a stack trace at each call to WithCancel/Timeout/Deadline. If that's mostly happening close to RPCs and I/O operations, this might be fine.

My interest in using the stack trace is that it improves debuggability for all existing code you don't need to change any of the cancelation sites to start getting the stack traces. This comes at the expense of capturing a stack trace at each call to WithCancel/Timeout/Deadline. If that's mostly happening close to RPCs and I/O operations, this might be fine.

Oh, I had misunderstood what you change does. I though it captures a stack when cancel() is called, not when WithCancel() is called. The latter I think would be less useful for us than the former. I imagine the former should be doable?

This comes at the expense of capturing a stack trace at each call to WithCancel/Timeout/Deadline.

I also hadn't fully internalized this. A call to runtime.Callers() would likely be too expensive for the CockroachDB code. I've just measured it on a beefy Linux machine, and for a few frames it costs 350ns per call, and the cost seems to go up steadily with the number of frames. I think this would be too much :S. We make plenty of cancelable contexts. Also I think your patch would do one extra allocation for the callers buffer, in addition to the cancelCtx alloc. That's be unfortunate; we're already suffering significantly because contexts basically always escape to the heap - they're our number one source of allocations, as measured by allocation source. Consider allocating the two together; something like:
type cancelCtx struct {
   ...
   callers []uintptr
   callersAlloc [30]uitptr
}

func newCancelCtx(parent Context) cancelCtx {
        ctx = new(cancelCtx)
        ctx.Context = parent
	ctx.callers := ctx.callersAlloc[:]
	runtime.Callers(2, ctx.callers) // skip Callers and newCancelCtx
	return ctx
}

Capturing the stack trace at the cancel() call is likely to be uninteresting: usually cancel is called either via timer.AfterFunc (in the case of a deadline) or via defer, which may make it harder to debug if there are multiple defers in the same function. However, if your code often calls cancel directly from functions other than the ones that called WithCancel, I can see the use of capturing the stack trace at the cancel() call.
The same question arises for passing a string: should the string be passed to WithCancel/Deadline/Timeout, or to cancel? In either case, this would be a pretty messy API extension, so my preference would be to avoid making any API changes at all. I understand your performance concerns, though. Ideally we'd make this zero-cost by default.

If you're looking to pass a reason there's nothing stopping you from creating a custom context implementation.
My core issue want with this would be to deal with poorly-written functions that take a context. Having an opt-in higher up the stack would likely be a decent trade off between performance and ease of use.

@neetle Yes, we could provide a way to enable stack-trace capture via a parent context, and propagate bit that down to child context (e.g. in propagateCancel). So this would be off by default, and users could enable it by setting a parent context with ctx = context.EnableStackTraces(ctx) or somesuch. This would turn on stack tracing for all child contexts, providing people with programmatic control over the whole tree (e.g. to debug specific requests), and it avoids having to add "reason" strings everywhere WithCancel or WithDeadline are called (though in theory there shouldn't be a huge number of these, either).

If a "WithReason" style method is added, can I request that it take an error type instead of a string? The error could be wrapped with go1.13 errors package wrapping so what ctx.Err() returns is still errors.Is(err, context.Canceled), but that way more structured information could also be passed than just a string.

So we are then all arguing that #46273 should be reopen?

@mitar No, at this stage I'm just prototyping to get a feel for various ideas. My preference is to minimize API changes and improve debuggability in-place, but I understand performance concerns might make this difficult. Let's keep the discussion here for now

Capturing the stack trace at the cancel() call is likely to be uninteresting: usually cancel is called either via timer.AfterFunc (in the case of a deadline)

I don't have API specifics in mind, but I'd consider splitting the deadline case from the explicit cancellation case. When I get a DeadlineExceeded error, I'm mostly interested in what the respective deadline/timeout was. When an operation is explicitly canceled, I want to know who canceled it and why.

or via defer, which may make it harder to debug if there are multiple defers in the same function.

Implicitly or explicitly, I'd try to differentiate between the cancel function being called after the respective operation finished (because the API says that one must always call the cancel function), or if the cancel is called affirmatively to cancel an ongoing operation. The former case should be as cheap as possible, because nobody is expected to get a Canceled error because of it (the ctx in question is not expected to be in use by anybody). The implementation of the latter can be more expensive, because it's expected to only happen on unhappy paths.
I know you want minimal API changes. I guess I personally would be inclined towards maximal changes :).

If you're looking to pass a reason there's nothing stopping you from creating a custom context implementation.

We have such a context implementation, but it's not a nice one because ctx.Err() still returns the vanilla context.Canceled error (as it also does in @Sajmani 's proposed patch). It's also not nice because it forces us to allocate both our own context struct, and a WithCancel() context. The root of the problem for wanna-be Context implementers is the cancellation propagation code in the standard library, that makes it very expensive for stdlib implementations to interact with custom implementations: https://cs.opensource.google/go/go/+/refs/tags/go1.17.6:src/context/context.go;l=264
That code spawns a new goroutine to propagate cancellation from a stdlib ctx to a custom one. This is very expensive.
I've been timidly thinking of proposing to the go team to provide the required interfaces for custom implementations to participate in propagation as efficiently as the stdlib one, so that stdlib ctx can co-exist with the cowboys. I guess I'm asking now.

@andreimatei Others have suggested similar hooks, and IIRC we even prototyped some. That might be worthwhile, but IMO debugging context cancelation is a common enough problem that I'd like to make it better for everyone by default, if we can do so with acceptable cost.

I've been timidly thinking of proposing to the go team to provide the required interfaces for custom implementations to participate in propagation as efficiently as the stdlib one, so that stdlib ctx can co-exist with the cowboys. I guess I'm asking now.

Perhaps this deserves its own issue. I'd certainly be for it.

@jtolio There's prior discussion on this in #28728

Capturing the stack trace at the cancel() call is likely to be uninteresting: usually cancel is called either via timer.AfterFunc (in the case of a deadline) or via defer, which may make it harder to debug if there are multiple defers in the same function.

A given WithContext call site may have many possible cancel call sites, and while it's true that the cancel call is often just a deferred function, in some of the most interesting cases it is decidedly nontrivial.
For example, a server might construct a context.WithCancel for a background operation and store the cancel function in a map, and only invoke that cancel function when either the background operation completes or an RPC comes in to explicitly cancel it. In such a case it seems very important to distinguish between “canceled because the operation completed” and “canceled by RPC”, but the WithCancel call site would not distinguish them at all.

Based on the feedback from several of you, I'll prototype an alternative
that allows passing a value in via the cancel function.
On Fri, Jan 7, 2022 at 2:33 PM Bryan C. Mills @.***>
wrote:

Capturing the stack trace at the cancel() call is likely to be
uninteresting: usually cancel is called either via timer.AfterFunc (in the
case of a deadline) or via defer, which may make it harder to debug if
there are multiple defers in the same function.
A given WithContext call site may have many possible cancel call sites,
and while it's true that the cancel call is often just a deferred
function, in some of the most interesting cases it is decidedly nontrivial.
For example, a server might construct a context.WithCancel for a
background operation and store the cancel function in a map, and only
invoke that cancel function when either the background operation
completes or an RPC comes in to explicitly cancel it. In such a case it
seems very important to distinguish between “canceled because the operation
completed” and “canceled by RPC”, but the WithCancel call site would not
distinguish them at all.
—
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/26356#issuecomment-1007681687, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACKIVXOCQENNWK5TYHTYNDTUU45W7ANCNFSM4FJWYJ3A
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

@jtolio There's prior discussion on this in #28728

I had missed the developments around #28728 and their implications. Those changes seem to let us avoid the extra goroutine, which is great! That is, as long as we don't want to override the Done() method. Not being able to override it means that we have to pay some extra allocations because we have to pair a stdlib WithCancel ctx with our implementation, but that's not the end of the world. With this in mind, I've given a renewed push to our attempts to implement richer cancellation, linked below.

Based on the feedback from several of you, I'll prototype an alternative that allows passing a value in via the cancel function.

I'm excited to see what comes out of it!
FWIW, here's what we're trying within CockroachDB: a colleague's PR and my commit on top of it.

I've updated my CL with a new version that prototypes adding *Cause variants of WithCancel, Deadline, and Timeout.
The purpose of this design is to provide backwards-compatibility for existing code while enabling users to add cancelation "causes" where they need them.
I welcome feedback on the API with respect to whether it addresses this issue:
https://go-review.googlesource.com/c/go/+/375977/3/src/context/context.go
I need to write more tests, particularly for cases where there are multiple causes in a context chain, and with mixed cancelation orders.
I also need to write benchmarks so we can measure slowdowns on critical paths and any new allocations.

This is wonderful!
Unless I'm missing something, your Cause(ctx1) implementation can return an error from ctx2's cancel even if ctx1 was not canceled when ctx2 was canceled. In fact, it might return an error even if ctx1.Error() == nil (i.e. ctx1 is not canceled). This is when a ctx on the chain from ctx1 to ctx2 overrode the Done() channel. Right? This seems surprising.
Have you considered adding protection against this in the way that parentCancelCtx() does?
If you don't want to do that, consider exporting cancelCtxKey so that 3rd party implementors can hijack Value(cancelCtxKey).

@andreimatei I need to write some tests with chains of contexts and multiple causes. Hopefully that will help us see whether the returned causes are sensible or surprising. I'm explicitly propagating causes from parents to children in propagateCancel and cancelCtx.cancel—the same places where the context's error gets propagated. Glad to hear this API is directionally correct. If others agree, we'll need to take this up for proposal review.

@andreimatei I added some tests:
https://go-review.googlesource.com/c/go/+/375977/4/src/context/context_test.go#798
Do these exercise the case you were describing? (I'm not sure what ctx1 and ctx2 mean in your description).

I added test for cause vs. causeless cancels and more orderings. I also renamed things so the test is easier to follow. I think the behavior is pretty clear now: the first cancel cause sticks for all children, even if it's a nil cause.

Do these exercise the case you were describing?

I don't think so. The cases I'm thinking of are about a custom implementation of context that overrides the Done() channel - e.g. an implementation that doesn't inherit the cancelation of its parent. In such cases, your Cause implementation can return a non-nil cause for a context who's Err() is nil. This is true for both Cause(<custom ctx impl>), and for Cause(stdlib ctx derived from custom ctx). I think this is surprising. In the particular case of a stdlib ctx, I think we should guarantee that, if Err() is nil, Cause() is also nil. Would you agree?
Here's a small program that demonstrates what I'm talking about.
package main

import (
	"context"
	"fmt"
	"time"
)

type uncanceledCtx struct {
	p context.Context
}

var _ context.Context = uncanceledCtx{}

func (u uncanceledCtx) Deadline() (deadline time.Time, ok bool) {
	return time.Time{}, false
}

func (u uncanceledCtx) Done() <-chan struct{} {
	return nil
}

func (u uncanceledCtx) Err() error {
	return nil
}

func (u uncanceledCtx) Value(key any) any {
	return u.p.Value(key)
}

func main() {
	ctx1, cancel1 := context.WithCancelCause(context.Background())
	uc := uncanceledCtx{p: ctx1}
	ctx2 := context.WithValue(uc, "key", "val")
	cancel1(fmt.Errorf("cancel 1"))

	fmt.Printf("uncanceled: Err: %v, cause: %v\n", uc.Err(), context.Cause(uc)) // uncanceled: Err: <nil>, cause: cancel 1
	fmt.Printf("ctx2: Err: %v, cause: %v\n", ctx2.Err(), context.Cause(ctx2))   // ctx2: Err: <nil>, cause: cancel 1
}

The output of Cause(uc) and Cause(ctx2) is surprising to me.

Ah, thanks for the reproduction case. I would state the expectation in the reverse: Cause(ctx) is only valid (defined) if ctx.Err() != nil (which is the same as when ctx.Done() is closed). If ctx.Err() is nil, then Cause(ctx) is undefined. I can add this to the spec in the CL.
We could strengthen the spec for Cause to mirror what we say for Err:
	// If Done is not yet closed, Err returns nil.
	// If Done is closed, Err returns a non-nil error explaining why:
	// Canceled if the context was canceled
	// or DeadlineExceeded if the context's deadline passed.
	// After Err returns a non-nil error, successive calls to Err return the same error.
	Err() error

So we could add (and implement) "If ctx.Err returns nil, the Cause(ctx) returns nil."
I'd prefer not to add this strengthening of the spec unless there's a good reason to do so.
I expect most uses of Cause to check <-ctx.Done() or ctx.Err() != nil before calling Cause(ctx).

I would state the expectation in the reverse: Cause(ctx) is only valid (defined) if ctx.Err() != nil (which is the same as when ctx.Done() is closed). If ctx.Err() is nil, then Cause(ctx) is undefined. I can add this to the spec in the CL.

I expect most uses of Cause to check <-ctx.Done() or ctx.Err() != nil before calling Cause(ctx).

In my opinion, we should aim to relegate ctx.Err() to the past. I think we should aim for Cause(ctx) to completely replace it for new programs (because it's much better) (*). So I personally do not agree with the premise that any Cause() call should be preceded by an Err() call (or, rather, I don't think we should design Cause() with that mindset). There may be a preceding Done() call, but not always.
Another thing I wanted to bring up is making sure that custom ctx impls can participate in Cause() determination for themselves and their children. I think with your current patch that's not possible, because the key that Cause() looks for is not exported?
(*) If I'd have my druthers, we would make Cause() a new method on ctx (even if that means that custom Ctx impls will need to add that method to compile under the new go version. I'm not very familiar with the go compatibility promise but, as far as I'm personally concerned, there's not that many custom Ctx impls out there and the changes to them would be trivial (e.g. they can delegate to Err()).
I'd also consider adding a version of the Done() method that returns the error. It'd have to be a new channel per caller; I haven't thought through the performance implications.

@andreimatei, the Go compatibility policy does not allow new methods to be added to exported interfaces. So there is no plausible way to Cause to replace Err.
The best we could perhaps do is retrofit a top-level func Cause(Context) error function into the context package, which would use Cause if defined or Err otherwise.

Regarding compatibility, my goal with this CL is to avoid breaking anything, including existing implementations of the Context interface. Therefore I'm not adding Cause() to the Context interface.
My goal with Cause is not to replace Err, but to allow people to supplement Err with additional information.
I think you're saying that you'd like to check Cause(ctx) != nil instead of ctx.Err() != nil. If so, then indeed we'd need to make sure they are nil / not-nil at the same times. We'd probably also want to make Cause(ctx) == ctx.Err() when the user hasn't provided a cause. But this then makes it difficult to determine whether ctx.Done was closed due to cancelation or deadline exceeded (the user would need to encode this into their cause).
Regarding implementing Cause for custom contexts, users can do this easily by wrapping a context created using WithCancelCause. I'd like to keep things simple until there's a demonstrated need to support anything fancier.

All good points, @andreimatei , thank you.
I suggest at this point I write up the current state as a Proposal and document your suggestions as Alternatives to Consider.

Please take a look at #51365 and see if it addresses your use cases. Thanks!


Launch process needs some love

Currently the launching process is a bit rough.
It should know whether a process (either core or mc) was launched in a separate console window or not, and only pause the output (Press any key to exit...) if it was a new window.
Also mpf both should be changed to be platform specific since it's impossible to write a single python script that works for all platforms.
In general the whole process needs to be cleaned up a bit.

It would be nice if the game could reconnect after a kill and restart to a running mc. Maybe resetting the mc to have a clean starting point.
As the game has to wait for the mc to start, maybe the mc could spawn the game after it is running?
The „press any key to exit“ is only needed on platforms that close the process’ window on exit. If you open the shell yourself that should never happen. The default should be no message. You could add a parameter like -w (wait) to enable that message.

Also make sure both mpf and mc retry to connect forever

love made.
Fixed @Lamoraldus bullet points 2 and 3. 1 will have to wait until 0.31.


Route list doesn't display correctly in Safari

Started taking a look at this for a new project and noticed that the route list does not display correctly in Safari.

I know that a UI refresh is underway, so maybe this has already been taken care of, but wanted to make sure that checking that the UI does look correctly in Safari is considered.
Also, if there's a simple patch that could be applied to this while waiting for the UI refresh, that'd be great.
Thanks.

Oh. Could be done by simple patch.
will do this week.

Fixed in #124


Very Unstable

Compared to the previous version, this current trainer is very unstable. Weapon durability values change randomly after every in-game loading screen and rupees constantly reset to zero when selling/buying items at a merchant. In addition, the trainer crashes frequently, and when I try to reconnect to my Wii U, it crashes the game as well.
And what's more? The previous version of the trainer does not work with the previous setup (using CosmoCortney's codehandler) anymore, so I was forced to upgrade to this version and change my entire Homebrew/TCPGecko setup.
TL;DR: trainer works, but it's very unstable and unreliable. I preferred the previous version.

Please delete this comment since it is not a question,
you are just complaining
if it isnt working its not the trainers fault or joffners its the falut of your connection, setup, and or wii u
the trainer is working perfectly fine for me

First and foremost, do not ask me to delete my comment. If a site moderator or joffnerd himself finds my comment obtrusive, offensive, or otherwise inappropriate, they will delete it or request to have it deleted. Do not concern yourself with things that do not pertain to you.
Secondly, if one produces a program such as this, criticism (constructive or otherwise) is inevitable, and, I would imagine, welcomed. After all, it's the only way to improve it. If you contributed to the project, grow a thicker skin and learn to deal with feedback properly. If you didn't, please be quiet, as this comment wasn't intended for you. Again, mind your own business.
Also, please delete your comment since it is not a question. You are just complaining about a complaint.

TBH i am not a  software developer, if it doesn't work then i recommend using what does. It's always going to track bully's tcp gecko so you will have to deal with that being updated. Also, you can't connect until you have loaded a save.
I doubt i will update  it anytime soon tbh. I have  never had stability issues, it either works or doesn't.
While I appreciate feedback, just telling me its unreliable or unstable doesn't really help.

I appreciate the response, Joff. Big fan, by the way. The trainer's amazing. I did some troubleshooting over the past couple days with some pointers listed on the gbatemp.net forums, and it's working much better now. However, there's still the issue of when I disconnect the trainer from the Wii U, it crashes my game. It's not a huge issue (since I can just turn the Wii U off and then close the trainer), but it might be something worth looking into. As I said previously, this didn't happen with the previous version.
I understand you won't be updating it for the time being, but again, thank you for your time and the effort you put into this.
Also, if there's a somewhere I could make a donation to you or the project, do let me know. Since I don't know squat about coding or software development, I would like to at least support those who do.

Thanks for the kind words, didn't mean to be  short initially.
I just made a quick paypal button, never taken donations before but feel free to try it out:
https://joffnerd.s3.amazonaws.com/donate.html


Refactoring: Use specialized SemanticError constructors

Fixes #109.
This PR introduces specialized constructors for SemanticError for the various errors that can occur in the IR. This makes for better code readability, and for more standardized error messages.
I'm unsure whether I've picked appropriate names for the constructors, and I'm also not sure whether the SemanticError enum should be extended.

@grjte : Review comments addressed.

Thanks @jjcnn everything looks great to me now! Can you just squash the commits and update the commit message to the semantic style specified in our contributor doc? Then we'll be ready to merge

Done (I think).


DOM-52659 Provision bucket for flyte

Description
We want to provision an s3 bucket for flyte to use for pipeline results storage
Jira
https://dominodatalab.atlassian.net/browse/DOM-52659

Me and @miguelhar discussed and decided that the best course of action was to make flyte an object at the top level instead of a single variable so we can add more fields to it in the future. IMO also alleviates some of the confusion with passing flyte_enabled around, as we are now treating flyte as it's own entity.


controllers/limitador: use owner refs

So the deployment and the service are deleted automatically when a
Limitador object is deleted.

Fix limitador service namespace, which was harcoded to default
Fix tests: Removing Deleting a Limitador object because the test context does not support garbage collection link

@davidor can you also review this one? Thanks!


GET https://<IP_ADDRESS>:8443/api/v1/namespaces 403 (Forbidden) at bootstrap

can't be good, seems to actually be an issue in hawtio-oauth...

Fixed here -> https://github.com/hawtio/hawtio-oauth/commit/50e4c3134ab22f60d663c27917469950e93dc33a


adding item 'questionary' in requirements.txt

The item 'questionary' is import in main.py

Thank you for contributing @LeonardoGregoriocs 🚀
I didn't see it as I had it locally, and as unit tests aren't implemented yet (as well as automated pipelines to run them).


Could fastLMM dealt with repeatable records model

Hi,
I will conduct GWAS on the mouse data.
In my case, each individual could have multiple records shown as follow:
StrainID IID pheno
129X1.SVJ 162 8.54605
129X1.SVJ 426 8.13482
129X1.SVJ 57 8.00406
A.J 344 7.97635
A.J 346 8.27816
A.J 428 8.03877
My genotype data is based on Strain level.
From the instructions manual, I think fastLmm could dealt with such repeatable model.
Could I ask how to make fastlmm run under such model? Is there any manual for this?
In addition, there are two versions of fastlmm: python and C++.
Could both versions dealt with this? or just Python version?
Looking forwards to any of your possible reply! Thank you very much!
Best regards,
Tina.

Tina,
Thanks for looking at Fast-LMM.
My collaborators all know more about biology that I. They may be able to jump in.
For me, could you explain strain levels a bit more for a computer scientist? (e.g. you said that an individual could have multiple records, but in your example, I don’t see an repeated IIDs.)
Yours,
Carl
Carl Kadie, Applied Researcher, Microsoft
http://research.microsoft.com/~carlkhttps://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fresearch.microsoft.com%2F~carlk&data=04|01|carlk%40microsoft.com|6a20727660984438f06f08d652fdfd9c|72f988bf86f141af91ab2d7cd011db47|1|0|636787648220992986|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|-1&sdata=MgUF%2FYmmCGNQJnJAC1g33IEHNL1Hm9WWqBDM77PKZ5I%3D&reserved=0

From: Tinawang402<EMAIL_ADDRESS>Sent: Friday, November 23, 2018 4:09:21 PM
To: MicrosoftGenomics/FaST-LMM
Cc: Subscribed
Subject: [MicrosoftGenomics/FaST-LMM] Could fastLMM dealt with repeatable records model (#36)
Hi,
I will conduct GWAS on the mouse data.
In my case, each individual could have multiple records shown as follow:
StrainID IID pheno
129X1.SVJ 162 8.54605
129X1.SVJ 426 8.13482
129X1.SVJ 57 8.00406
A.J 344 7.97635
A.J 346 8.27816
A.J 428 8.03877
My genotype data is based on Strain level.
From the instructions manual, I think fastLmm could dealt with such repeatable model.
Could I ask how to make fastlmm run under such model? Is there any manual for this?
In addition, there are two versions of fastlmm: python and C++.
Could both versions dealt with this? or just Python version?
Looking forwards to any of your possible reply! Thank you very much!
Best regards,
Tina.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftGenomics%2FFaST-LMM%2Fissues%2F36&data=02|01||f450e0e750474f3c487b08d651a115e4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636786149621948725&sdata=7rvQFOSC2WB8iRxSytRnSfY6HsSRHpbL7j4Mij3WIkQ%3D&reserved=0, or mute the threadhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGPuvz36mhvLS8KQrzStOICMMl1Cp98dks5uyI4xgaJpZM4YxM1e&data=02|01||f450e0e750474f3c487b08d651a115e4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636786149621948725&sdata=089OrqzN5FidE08HbhoROwUkfPcd6PO5WBgQJOAqF7k%3D&reserved=0.

Hi,
The individuals with the same strain ID are genetically identical to each other.
You can try running fastlmm as is. The kinship matrix should reflect this automatically. There are some additional features that give you some computational savings, but will give the exact same result, just faster. Unless runtime is a severe limitation, I don't recommend using those, as they are not well documented.
--Christoph
Sent from my mobile.

Am 25.11.2018 um 18:56 schrieb Carl Kadie<EMAIL_ADDRESS>Tina,
Thanks for looking at Fast-LMM.
My collaborators all know more about biology that I. They may be able to jump in.
For me, could you explain strain levels a bit more for a computer scientist? (e.g. you said that an individual could have multiple records, but in your example, I don’t see an repeated IIDs.)
Yours,
Carl
Carl Kadie, Applied Researcher, Microsoft
http://research.microsoft.com/~carlkhttps://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fresearch.microsoft.com%2F~carlk&data=04|01|carlk%40microsoft.com|6a20727660984438f06f08d652fdfd9c|72f988bf86f141af91ab2d7cd011db47|1|0|636787648220992986|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|-1&sdata=MgUF%2FYmmCGNQJnJAC1g33IEHNL1Hm9WWqBDM77PKZ5I%3D&reserved=0

From: Tinawang402<EMAIL_ADDRESS>Sent: Friday, November 23, 2018 4:09:21 PM
To: MicrosoftGenomics/FaST-LMM
Cc: Subscribed
Subject: [MicrosoftGenomics/FaST-LMM] Could fastLMM dealt with repeatable records model (#36)
Hi,
I will conduct GWAS on the mouse data.
In my case, each individual could have multiple records shown as follow:
StrainID IID pheno
129X1.SVJ 162 8.54605
129X1.SVJ 426 8.13482
129X1.SVJ 57 8.00406
A.J 344 7.97635
A.J 346 8.27816
A.J 428 8.03877
My genotype data is based on Strain level.
From the instructions manual, I think fastLmm could dealt with such repeatable model.
Could I ask how to make fastlmm run under such model? Is there any manual for this?
In addition, there are two versions of fastlmm: python and C++.
Could both versions dealt with this? or just Python version?
Looking forwards to any of your possible reply! Thank you very much!
Best regards,
Tina.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftGenomics%2FFaST-LMM%2Fissues%2F36&data=02|01||f450e0e750474f3c487b08d651a115e4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636786149621948725&sdata=7rvQFOSC2WB8iRxSytRnSfY6HsSRHpbL7j4Mij3WIkQ%3D&reserved=0, or mute the threadhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGPuvz36mhvLS8KQrzStOICMMl1Cp98dks5uyI4xgaJpZM4YxM1e&data=02|01||f450e0e750474f3c487b08d651a115e4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636786149621948725&sdata=089OrqzN5FidE08HbhoROwUkfPcd6PO5WBgQJOAqF7k%3D&reserved=0.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Hi Carl,
Thank you very much for your email!
And sorry for not making my question clear!
Here is my case:
StrainID == FID (family ID);
My genotype data is based on FID.
Go back to my data example:
FID        IID pheno
129X1.SVJ 162 8.54605
129X1.SVJ 426 8.13482
129X1.SVJ 57 8.00406
For the FID "129X1.SVJ", three different IID 162, 426 and 57 have the same
genotypes; while records (pheno colum in the above example data) are
different.
I can't take average of the pheno across the IID as the power will be much
reduced.
I want to know, when I fit these data inside fastLMM, how fastLMM build up
similarity matrix?!
And could python and C++ versions of fastLMM do the same thing on my case?
If yes, I prefer to use C++ version of fastLMM, as I didn't use python too
much.
Looking forwards to your feedback!
Thanks again!
Best regards,
Tingting.
Christoph Lippert<EMAIL_ADDRESS>于2018年11月26日周一 上午5:14写道：

Hi,
The individuals with the same strain ID are genetically identical to each
other.
You can try running fastlmm as is. The kinship matrix should reflect this
automatically. There are some additional features that give you some
computational savings, but will give the exact same result, just faster.
Unless runtime is a severe limitation, I don't recommend using those, as
they are not well documented.
--Christoph
Sent from my mobile.

Am 25.11.2018 um 18:56 schrieb Carl Kadie<EMAIL_ADDRESS>Tina,
Thanks for looking at Fast-LMM.
My collaborators all know more about biology that I. They may be able to
jump in.
For me, could you explain strain levels a bit more for a computer
scientist? (e.g. you said that an individual could have multiple records,
but in your example, I don’t see an repeated IIDs.)
Yours,
Carl
Carl Kadie, Applied Researcher, Microsoft
http://research.microsoft.com/~carlk<
https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fresearch.microsoft.com%2F~carlk&data=04|01|carlk%40microsoft.com|6a20727660984438f06f08d652fdfd9c|72f988bf86f141af91ab2d7cd011db47|1|0|636787648220992986|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|-1&sdata=MgUF%2FYmmCGNQJnJAC1g33IEHNL1Hm9WWqBDM77PKZ5I%3D&reserved=0

From: Tinawang402<EMAIL_ADDRESS>Sent: Friday, November 23, 2018 4:09:21 PM
To: MicrosoftGenomics/FaST-LMM
Cc: Subscribed
Subject: [MicrosoftGenomics/FaST-LMM] Could fastLMM dealt with
repeatable records model (#36)
Hi,
I will conduct GWAS on the mouse data.
In my case, each individual could have multiple records shown as follow:
StrainID IID pheno
129X1.SVJ 162 8.54605
129X1.SVJ 426 8.13482
129X1.SVJ 57 8.00406
A.J 344 7.97635
A.J 346 8.27816
A.J 428 8.03877
My genotype data is based on Strain level.
From the instructions manual, I think fastLmm could dealt with such
repeatable model.
Could I ask how to make fastlmm run under such model? Is there any
manual for this?
In addition, there are two versions of fastlmm: python and C++.
Could both versions dealt with this? or just Python version?
Looking forwards to any of your possible reply! Thank you very much!
Best regards,
Tina.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftGenomics%2FFaST-LMM%2Fissues%2F36&data=02|01||f450e0e750474f3c487b08d651a115e4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636786149621948725&sdata=7rvQFOSC2WB8iRxSytRnSfY6HsSRHpbL7j4Mij3WIkQ%3D&reserved=0>,
or mute the thread<
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGPuvz36mhvLS8KQrzStOICMMl1Cp98dks5uyI4xgaJpZM4YxM1e&data=02|01||f450e0e750474f3c487b08d651a115e4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636786149621948725&sdata=089OrqzN5FidE08HbhoROwUkfPcd6PO5WBgQJOAqF7k%3D&reserved=0
.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftGenomics/FaST-LMM/issues/36#issuecomment-441460384,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOcrVXPgu7aL0Pr-heh_U861qNL4PuCpks5uyt3pgaJpZM4YxM1e
.

Tingting,
As Christoph said, everything should just work C both versions. It will treat every mouse (and it’s phenotype) as an individual even if they are clones. It will know they are clones and do the right things because it will see that their genotypes are the same.

Carl

From: Tinawang402<EMAIL_ADDRESS>Sent: Sunday, November 25, 2018 6:01:12 PM
To: MicrosoftGenomics/FaST-LMM
Cc: Carl Kadie; Comment
Subject: Re: [MicrosoftGenomics/FaST-LMM] Could fastLMM dealt with repeatable records model (#36)
Hi Carl,
Thank you very much for your email!
And sorry for not making my question clear!
Here is my case:
StrainID == FID (family ID);
My genotype data is based on FID.
Go back to my data example:
FID IID pheno
129X1.SVJ 162 8.54605
129X1.SVJ 426 8.13482
129X1.SVJ 57 8.00406
For the FID "129X1.SVJ", three different IID 162, 426 and 57 have the same
genotypes; while records (pheno colum in the above example data) are
different.
I can't take average of the pheno across the IID as the power will be much
reduced.
I want to know, when I fit these data inside fastLMM, how fastLMM build up
similarity matrix?!
And could python and C++ versions of fastLMM do the same thing on my case?
If yes, I prefer to use C++ version of fastLMM, as I didn't use python too
much.
Looking forwards to your feedback!
Thanks again!
Best regards,
Tingting.
Christoph Lippert<EMAIL_ADDRESS>于2018年11月26日周一 上午5:14写道：

Hi,
The individuals with the same strain ID are genetically identical to each
other.
You can try running fastlmm as is. The kinship matrix should reflect this
automatically. There are some additional features that give you some
computational savings, but will give the exact same result, just faster.
Unless runtime is a severe limitation, I don't recommend using those, as
they are not well documented.
--Christoph
Sent from my mobile.

Am 25.11.2018 um 18:56 schrieb Carl Kadie<EMAIL_ADDRESS>Tina,
Thanks for looking at Fast-LMM.
My collaborators all know more about biology that I. They may be able to
jump in.
For me, could you explain strain levels a bit more for a computer
scientist? (e.g. you said that an individual could have multiple records,
but in your example, I don’t see an repeated IIDs.)
Yours,
Carl
Carl Kadie, Applied Researcher, Microsoft
http://research.microsoft.com/~carlk<
https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fresearch.microsoft.com%2F~carlk&data=04|01|carlk%40microsoft.com|6a20727660984438f06f08d652fdfd9c|72f988bf86f141af91ab2d7cd011db47|1|0|636787648220992986|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|-1&sdata=MgUF%2FYmmCGNQJnJAC1g33IEHNL1Hm9WWqBDM77PKZ5I%3D&reserved=0

From: Tinawang402<EMAIL_ADDRESS>Sent: Friday, November 23, 2018 4:09:21 PM
To: MicrosoftGenomics/FaST-LMM
Cc: Subscribed
Subject: [MicrosoftGenomics/FaST-LMM] Could fastLMM dealt with
repeatable records model (#36)
Hi,
I will conduct GWAS on the mouse data.
In my case, each individual could have multiple records shown as follow:
StrainID IID pheno
129X1.SVJ 162 8.54605
129X1.SVJ 426 8.13482
129X1.SVJ 57 8.00406
A.J 344 7.97635
A.J 346 8.27816
A.J 428 8.03877
My genotype data is based on Strain level.
From the instructions manual, I think fastLmm could dealt with such
repeatable model.
Could I ask how to make fastlmm run under such model? Is there any
manual for this?
In addition, there are two versions of fastlmm: python and C++.
Could both versions dealt with this? or just Python version?
Looking forwards to any of your possible reply! Thank you very much!
Best regards,
Tina.
―
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftGenomics%2FFaST-LMM%2Fissues%2F36&data=02|01||f450e0e750474f3c487b08d651a115e4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636786149621948725&sdata=7rvQFOSC2WB8iRxSytRnSfY6HsSRHpbL7j4Mij3WIkQ%3D&reserved=0>,
or mute the thread<
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGPuvz36mhvLS8KQrzStOICMMl1Cp98dks5uyI4xgaJpZM4YxM1e&data=02|01||f450e0e750474f3c487b08d651a115e4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636786149621948725&sdata=089OrqzN5FidE08HbhoROwUkfPcd6PO5WBgQJOAqF7k%3D&reserved=0
.
―
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

―
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftGenomics/FaST-LMM/issues/36#issuecomment-441460384,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOcrVXPgu7aL0Pr-heh_U861qNL4PuCpks5uyt3pgaJpZM4YxM1e
.

―
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftGenomics%2FFaST-LMM%2Fissues%2F36%23issuecomment-441497258&data=02|01||3790d1f3a50540647ec108d653430a8e|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636787944730882418&sdata=J%2FlvPb5xHzMZFveMtIQdesW1mEft2EGusgi2EF3ps5s%3D&reserved=0, or mute the threadhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGPuv6c61P38SqJ5jre1BgsExeBZkYtFks5uy0togaJpZM4YxM1e&data=02|01||3790d1f3a50540647ec108d653430a8e|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636787944730882418&sdata=y%2B5G0ulVdfPPplRz8iSGzFgAbaL7q9Sygz2HCCpHQQA%3D&reserved=0.

Hi All,
Thank you very much for your email!
Your comments are quite helpful!
Now I am using fastLmm on my data.
Best regards,
Tingting.
Carl Kadie<EMAIL_ADDRESS>于2018年11月28日周三 上午6:18写道：

Tingting,
As Christoph said, everything should just work C both versions. It will
treat every mouse (and it’s phenotype) as an individual even if they are
clones. It will know they are clones and do the right things because it
will see that their genotypes are the same.

Carl

From: Tinawang402<EMAIL_ADDRESS>Sent: Sunday, November 25, 2018 6:01:12 PM
To: MicrosoftGenomics/FaST-LMM
Cc: Carl Kadie; Comment
Subject: Re: [MicrosoftGenomics/FaST-LMM] Could fastLMM dealt with
repeatable records model (#36)
Hi Carl,
Thank you very much for your email!
And sorry for not making my question clear!
Here is my case:
StrainID == FID (family ID);
My genotype data is based on FID.
Go back to my data example:
FID IID pheno
129X1.SVJ 162 8.54605
129X1.SVJ 426 8.13482
129X1.SVJ 57 8.00406
For the FID "129X1.SVJ", three different IID 162, 426 and 57 have the same
genotypes; while records (pheno colum in the above example data) are
different.
I can't take average of the pheno across the IID as the power will be much
reduced.
I want to know, when I fit these data inside fastLMM, how fastLMM build up
similarity matrix?!
And could python and C++ versions of fastLMM do the same thing on my case?
If yes, I prefer to use C++ version of fastLMM, as I didn't use python too
much.
Looking forwards to your feedback!
Thanks again!
Best regards,
Tingting.
Christoph Lippert<EMAIL_ADDRESS>于2018年11月26日周一 上午5:14写道：

Hi,
The individuals with the same strain ID are genetically identical to
each
other.
You can try running fastlmm as is. The kinship matrix should reflect
this
automatically. There are some additional features that give you some
computational savings, but will give the exact same result, just faster.
Unless runtime is a severe limitation, I don't recommend using those, as
they are not well documented.
--Christoph
Sent from my mobile.

Am 25.11.2018 um 18:56 schrieb Carl Kadie<EMAIL_ADDRESS>Tina,
Thanks for looking at Fast-LMM.
My collaborators all know more about biology that I. They may be able
to
jump in.
For me, could you explain strain levels a bit more for a computer
scientist? (e.g. you said that an individual could have multiple
records,
but in your example, I don’t see an repeated IIDs.)
Yours,
Carl
Carl Kadie, Applied Researcher, Microsoft
http://research.microsoft.com/~carlk<

https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fresearch.microsoft.com%2F~carlk&data=04|01|carlk%40microsoft.com|6a20727660984438f06f08d652fdfd9c|72f988bf86f141af91ab2d7cd011db47|1|0|636787648220992986|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|-1&sdata=MgUF%2FYmmCGNQJnJAC1g33IEHNL1Hm9WWqBDM77PKZ5I%3D&reserved=0

From: Tinawang402<EMAIL_ADDRESS>Sent: Friday, November 23, 2018 4:09:21 PM
To: MicrosoftGenomics/FaST-LMM
Cc: Subscribed
Subject: [MicrosoftGenomics/FaST-LMM] Could fastLMM dealt with
repeatable records model (#36)
Hi,
I will conduct GWAS on the mouse data.
In my case, each individual could have multiple records shown as
follow:
StrainID IID pheno
129X1.SVJ 162 8.54605
129X1.SVJ 426 8.13482
129X1.SVJ 57 8.00406
A.J 344 7.97635
A.J 346 8.27816
A.J 428 8.03877
My genotype data is based on Strain level.
From the instructions manual, I think fastLmm could dealt with such
repeatable model.
Could I ask how to make fastlmm run under such model? Is there any
manual for this?
In addition, there are two versions of fastlmm: python and C++.
Could both versions dealt with this? or just Python version?
Looking forwards to any of your possible reply! Thank you very much!
Best regards,
Tina.
―
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<

https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftGenomics%2FFaST-LMM%2Fissues%2F36&data=02|01||f450e0e750474f3c487b08d651a115e4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636786149621948725&sdata=7rvQFOSC2WB8iRxSytRnSfY6HsSRHpbL7j4Mij3WIkQ%3D&reserved=0>,

or mute the thread<

https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGPuvz36mhvLS8KQrzStOICMMl1Cp98dks5uyI4xgaJpZM4YxM1e&data=02|01||f450e0e750474f3c487b08d651a115e4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636786149621948725&sdata=089OrqzN5FidE08HbhoROwUkfPcd6PO5WBgQJOAqF7k%3D&reserved=0

.
―
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

―
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/MicrosoftGenomics/FaST-LMM/issues/36#issuecomment-441460384>,

or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AOcrVXPgu7aL0Pr-heh_U861qNL4PuCpks5uyt3pgaJpZM4YxM1e>

.

―
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftGenomics%2FFaST-LMM%2Fissues%2F36%23issuecomment-441497258&data=02|01||3790d1f3a50540647ec108d653430a8e|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636787944730882418&sdata=J%2FlvPb5xHzMZFveMtIQdesW1mEft2EGusgi2EF3ps5s%3D&reserved=0>,
or mute the thread<
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGPuv6c61P38SqJ5jre1BgsExeBZkYtFks5uy0togaJpZM4YxM1e&data=02|01||3790d1f3a50540647ec108d653430a8e|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636787944730882418&sdata=y%2B5G0ulVdfPPplRz8iSGzFgAbaL7q9Sygz2HCCpHQQA%3D&reserved=0>.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftGenomics/FaST-LMM/issues/36#issuecomment-442182751,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOcrVeLafun-qLf6vsEKmekLfVjBNgr4ks5uzZAigaJpZM4YxM1e
.


JOSS reviewer 2 comment 1

Review openjournals/joss-reviews#1643
sbmltoode is a great tool for fast conversion and simulation of ode models, the conversion to json strings is a great feature to have.
The software installs correctly on python 3.7, tests correctly with COPASI results, tutorials are clear. If possible, it would be nice to clarify how sbmltoode preserves model components potentially through applying standards like sed-ml and kisao. From a user perspective, the main goal of a converter would be to maintain the original model specification.
Also, if possible, a sentence in the text to compare COPASI and sbmltoode.

Since we expect users to take and modify or use the code generated by SBMLtoODEpy in ways we can't predict, the burden of applying SED-ML or KiSAO will have to be on the user. Additionally most SBML components are stored as entries in dictionaries that are members of the class implementing the model. Currently rules and initial assignments are not implemented this way and annotations stored in the SBML model are not retained. We plan to address these in a future update.
We updated the paper to expand on the comparison to COPASI. My comment to reviewer #1 addresses the comparison to COPASI and Systems Biology Format Converter in more depth.


VIM API Gaps

From @johnfn in #8760
I'm a Vim extension developer and I noticed you guys wanted to know the API gaps. I made an issue for each gap I'm aware of: #2771, #8096, #1431, #8094, #8093, #7177.
#2771 is the highest priority because it can't be worked around.
#8096 is also really important because although it can be worked around, I'm scared of breaking user's history.
The rest would be very nice to have.

Also includes  #9143.

Short summary of current Vim API gaps:
CJK
it's about #8133.
We had CJK IME issues with VS Code and not enough API exposed for external callers. Alex already fixed those bugs and provided two composing APIs, now CJK should be pefect. What's more, our Integrated Terminal also benefits from it https://github.com/Microsoft/vscode/issues/8892.
Scrolling
it's about #2177, #9143, #9220.
@sandy081 already provided us an API for moving cursors to screen lines and they work great. Now he is working on screen characters and Window/Screen Width information.

[x] Move cursor to specific Screen Line or line start, middle or end.
[ ] Lines in Visible Window. Eg, go to the Nth/Middle line in the window,  go to the Nth line from the bottom
[ ] Screen characters. Scroll screen N characters, it's likely an addition to gm.
[ ] Scroll Window/Page.

History, Live Position, SelectionChange Reason, BracketMatching
#8096, #8094 #8093 #7177 are all in the backlog.

I am removing Scroll Window/Page feature from the current plan. We will take a look at it for next iteration.

@sandy081 which issue do you defer?

@sandy081: @rebornix and I just ranked the backlog in the comment above to correctly reflect the priorities from the VIM perspective.

@sandy081 updated my summary and added 4 more separate items. Now they covered all missing features currently on our roadmap, those commands/motions on our roadmap are from Vim's quickref so if there is any missing command that's dependent on VS Code API support but not listed by Vim documentation, I'll update this summary.

@kieferrm Item I deferred is scrolling window / page feature - https://github.com/VSCodeVim/Vim/issues/210.

@rebornix I moved Scrolling and other Tabs items to backlog in above comment. Please arrange them in the order of Vim extension priority.
Thanks.

Implement all commands that are currently possible with @sandy081 's newly added API. Others are all moved to Backlog section, ordered by priorities.

This work will continue in August - moving the milestone accordingly


Item properties are displayed incorrectly

Hi,
thanks for this great program 👍
The properties of blue and purple items are displayed incorrectly.
The Items had always the same properties, but they are not correct.
For example:
The item in the inventory:

The item in the inventory how its been displayed in TQVaultAE:

Items have variations in their stats based on their seed. TQVault can only display the base values of an item.

I see.
That's very pitty. So you can't compare the items in the vault.
Will this function be available at some point?

Will this function be available at some point?

Probably not! Unless someone succeed at reverse engineer the algorithm.

Why does it work with Monstersets?

All items will show their base values, unmodified by their seed. Rarity does not play a role unfortunately.


Deprecated PyUnicode functions that must be updated

I just wanted to create this issue as a placeholder for certain c-extension functions used by pyodbc that are going to be removed in upcoming Python versions.  Here is the list I have so far:
To be removed in version 3.11:
PyUnicode_EncodeUTF8
PyUnicode_EncodeUTF16
To be removed in version 3.12:
PyUnicode_GET_SIZE
PyUnicode_AS_UNICODE
PyUnicode_AS_DATA
PyUnicode_FromStringAndSize
PyUnicode_FromUnicode
PyUnicode_GetSize
PyUnicode_FromObject
Ref:
https://docs.python.org/3/c-api/unicode.html
https://docs.python.org/3/c-api/call.html

There is one PR #792 that has made a start on converting the relevant code to the preferred functions.

I saw the PR - great job.  I left a question on one part.
This may be the first item for v5 *(#945).

@mkleehammer Under Python 3.10 PyUnicode_FromUnicode(NULL, size) triggers a DeprecationWarning message to stderr, breaking CGI scripts. Should I open a separate ticket to get this fixed on a faster track than #945?
To reproduce (pyodbc-4.0.32):
...
rows = cursor.fetchall()
logstring = repr(rows)

(Also, GitHub is somehow suppressing the comment you said you left on #792.)

What's the status of this now that #792 has been merged?

There are still plenty of deprecated functions that are causing warning messages during builds.  Until the Python 3.12 deprecated functions are replaced in the code, this issue still stands.

Fedora rawhide now has Python 3.12 and so pyodbc is failing to build.  Any progress on this issue?

Well, the py3 branch builds on Python 3.12 on Ubuntu, without fast_execute_many, and works with the PostgreSQL unit tests.
My conversion task list of this topic has a bunch of unchecked items, but I actually think they are done.  One difficultly with any PRs, is that the py3 branch is quite different from the production branch for now.

I've merged 5.0 with Python 3.12 support into the master branch and published 5.0.0 alpha2.  I'll make a final release of 5.0.0 in the next few days if no serious problems are found.
See the discussion here


PokeMMO not working

Describe the issue
PokeMMO crashes on launch
Instructions to reproduce
Install PokeMMO and start it
What version of LiveContainer are you using?
2.1.2
Other
No response

It's fixed, please try https://github.com/hugeBlack/LiveContainer/actions


Twilio sample for app engine flex.

Twilio sample for app engine flex.

LGTM with one minor suggestion!

LGTM!


Cleanup and sphinxificated docs.

To build the docs, go to the "docs/" dir and run "make html" then open "doc/_build/html/index.html" in a browser.

w00t!


Refactor Shop / Room Shop Display

Again just Updating this to suit Wisps Colour Scheme and stop it from being so bland. >~<
If you havent already seen it: Preview - http://prntscr.com/bm4r18
Asked several users and they liked it.and received generally positive responses.

aah pcool....
but if u do these additons to the custom.css as a custom css class
variables will get reduced n_n
less variables = more speed
Which is needed for realtime servers

Ignore Lord Haji, he is banned from our repo for a reason

@SerperiorBae Float submitted a PR on adding CSS to the shop so there is no use for this PR then.

The shop has been restyled in https://github.com/jd4564/Pokemon-Showdown/pull/105


Add support for Duck Player

Task/Issue URL: https://app.asana.com/0/1205008441501016/1207588004626729/f
Description

Add Duck Player support
Navigate from Duck Player back to YouTube
Add Duck Player settings
Open YT URLs in Duck Player if setting is Enabled(Always)
Add Duck Player Prime Modal
Add Contingency settings

Steps to test this PR
https://app.asana.com/0/0/1207704461779423/f
Note: There have been changes to the JS integration, so you might need to test these changes on the top of the stack
User preferences "Always" open Duck Player

[x] Open Settings -> Duck Player -> Set to always
[x] Type a YT URL on the omnibar
[x] Check Duck Player is loaded
[x] Navigate back and check you're going to the previous page your were visiting

User preferences "Always ask" trigger overlay

[x] Open Settings -> Duck Player -> Set to always ask
[x] Type a YT URL on the omnibar
[x] Check overlay is loaded in YT
[x] Check that watch here removes the overlay, and watch in Duck player navigates to Duck Player

User preferences "Never" stays in YT

[x] Open Settings -> Duck Player -> Set to never
[x] Type a YT URL on the omnibar
[x] Check video is loaded normally

Feature 1

[x] Open Duck Player
[x] Click Info button
[x] Check prime modal is correctly shown in both landscape and portrait

Feature 1

[x] See https://app.asana.com/0/1205008441501016/1207714050281768/f (How to test, at the bottom of the description)

Feature 1

[x] Open a video in Duck Player with settings to Always Ask
[x] Click the watch in YouTube Button
[x] Check overlay isn't shown

UI changes
See https://app.asana.com/app/asana/-/get_asset?asset_id=1207785858877769

UI changes

Re-tested, LGTM!


Mock-SAS v3.0: Object name "measReportConfig" should not be used in "CBRSrequestHandler/def handle_Http_Req"

In "CBRSrequestHandler/def handle_Http_Req" function, "measReportConfig" appears in several places, after reading the code it seems that it tries to check if the measurement report is sent out in heartbeat request message. But according to Specification, "measReportConfig" will never be in the request message, it only appear in response message from SAS to CBSD.
So over here the "measReportConfig" should be replaced by "measReport", because this is the one that appears in request message to represent measurement report information.

Removed this code from Mock-SAS code uploaded 1-September-2017.  Mock-SAS code uploaded 1-September-2017 addresses "meas Report" according to section 11.9 in Mock-SAS tutorial “11.9      Handling of measReport in Request Messages”.

verified


font-awesome_5: 5.1.0 -> 5.5.0

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/font-awesome/versions.
meta.description for font-awesome_5 is: '"Font Awesome - OTF font"'.

Checks done (click to expand)

built on NixOS

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 5.5.0 with grep in /nix/store/rk02imxhnmcy571ha04d2b5m31r49wvd-font-awesome-5.5.0

directory tree listing: https://gist.github.com/73a795a87643c4858875e36de71804dd

du listing: https://gist.github.com/aa100d84e23dd419b97b58fd5034e798

Rebuild report (click to expand)

4 total rebuild path(s)
1 package rebuild(s)
1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
font-awesome_5

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/rk02imxhnmcy571ha04d2b5m31r49wvd-font-awesome-5.5.0 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A font-awesome_5 https://github.com/r-ryantm/nixpkgs/archive/aabb20738083dab1a5fc06495613a9c75973692b.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/rk02imxhnmcy571ha04d2b5m31r49wvd-font-awesome-5.5.0
ls -la /nix/store/rk02imxhnmcy571ha04d2b5m31r49wvd-font-awesome-5.5.0/bin

cc @baldo for testing.

Unexpected error: command failed with exit code 1 on x86_64-linux (full log)
Attempted: font-awesome_5
Partial log (click to expand)
4f4cb7c2f55d14d24f10390ebfeab0d25af612f3
  inflating: /nix/store/rk02imxhnmcy571ha04d2b5m31r49wvd-font-awesome-5.5.0/share/fonts/opentype/Font Awesome 5 Brands-Regular-400.otf
Archive:  /build/file
4f4cb7c2f55d14d24f10390ebfeab0d25af612f3
  inflating: /nix/store/rk02imxhnmcy571ha04d2b5m31r49wvd-font-awesome-5.5.0/share/fonts/opentype/Font Awesome 5 Free-Regular-400.otf
Archive:  /build/file
4f4cb7c2f55d14d24f10390ebfeab0d25af612f3
  inflating: /nix/store/rk02imxhnmcy571ha04d2b5m31r49wvd-font-awesome-5.5.0/share/fonts/opentype/Font Awesome 5 Free-Solid-900.otf
fixed-output derivation produced path '/nix/store/6r00asmdxd5baj4fmdjq8h0zpn6crfk3-font-awesome-5.5.0' with sha256 hash '1drjc40glfqhwmfn3s4gz8hz1x0ncrwdr9n1i25m1l7pvsk26f5f' instead of the expected hash '17n2f9hwv15gm7g9zfj2xp3fvzia9a694h7q7cxg5kgyhfdfwqi5'
error: build of '/nix/store/3sr46piv9dn7hvcwmmvyfh6wl9lg7i4l-font-awesome-5.5.0.drv' failed

Unexpected error: command failed with exit code 1 on aarch64-linux (full log)
Attempted: font-awesome_5
Partial log (click to expand)
4f4cb7c2f55d14d24f10390ebfeab0d25af612f3
  inflating: /nix/store/rk02imxhnmcy571ha04d2b5m31r49wvd-font-awesome-5.5.0/share/fonts/opentype/Font Awesome 5 Brands-Regular-400.otf
Archive:  /build/file
4f4cb7c2f55d14d24f10390ebfeab0d25af612f3
  inflating: /nix/store/rk02imxhnmcy571ha04d2b5m31r49wvd-font-awesome-5.5.0/share/fonts/opentype/Font Awesome 5 Free-Regular-400.otf
Archive:  /build/file
4f4cb7c2f55d14d24f10390ebfeab0d25af612f3
  inflating: /nix/store/rk02imxhnmcy571ha04d2b5m31r49wvd-font-awesome-5.5.0/share/fonts/opentype/Font Awesome 5 Free-Solid-900.otf
fixed-output derivation produced path '/nix/store/6r00asmdxd5baj4fmdjq8h0zpn6crfk3-font-awesome-5.5.0' with sha256 hash '1drjc40glfqhwmfn3s4gz8hz1x0ncrwdr9n1i25m1l7pvsk26f5f' instead of the expected hash '17n2f9hwv15gm7g9zfj2xp3fvzia9a694h7q7cxg5kgyhfdfwqi5'
error: build of '/nix/store/pf3gr4vvmkg92vh487mv75hss6xyl9bg-font-awesome-5.5.0.drv' failed

Unexpected error: command failed with exit code 1 on x86_64-darwin (full log)
Attempted: font-awesome_5
Partial log (click to expand)
4f4cb7c2f55d14d24f10390ebfeab0d25af612f3
  inflating: /nix/store/rk02imxhnmcy571ha04d2b5m31r49wvd-font-awesome-5.5.0/share/fonts/opentype/Font Awesome 5 Brands-Regular-400.otf
Archive:  /private/tmp/nix-build-font-awesome-5.5.0.drv-0/file
4f4cb7c2f55d14d24f10390ebfeab0d25af612f3
  inflating: /nix/store/rk02imxhnmcy571ha04d2b5m31r49wvd-font-awesome-5.5.0/share/fonts/opentype/Font Awesome 5 Free-Regular-400.otf
Archive:  /private/tmp/nix-build-font-awesome-5.5.0.drv-0/file
4f4cb7c2f55d14d24f10390ebfeab0d25af612f3
  inflating: /nix/store/rk02imxhnmcy571ha04d2b5m31r49wvd-font-awesome-5.5.0/share/fonts/opentype/Font Awesome 5 Free-Solid-900.otf
fixed-output derivation produced path '/nix/store/6r00asmdxd5baj4fmdjq8h0zpn6crfk3-font-awesome-5.5.0' with sha256 hash '1drjc40glfqhwmfn3s4gz8hz1x0ncrwdr9n1i25m1l7pvsk26f5f' instead of the expected hash '17n2f9hwv15gm7g9zfj2xp3fvzia9a694h7q7cxg5kgyhfdfwqi5'
error: build of '/nix/store/f6dfbq1cfz5qrqfx6w6rsgs8f2rf63sd-font-awesome-5.5.0.drv' failed

Success on aarch64-linux (full log)
Attempted: font-awesome_5
Partial log (click to expand)
/nix/store/6r00asmdxd5baj4fmdjq8h0zpn6crfk3-font-awesome-5.5.0

Success on x86_64-darwin (full log)
Attempted: font-awesome_5
Partial log (click to expand)
/nix/store/6r00asmdxd5baj4fmdjq8h0zpn6crfk3-font-awesome-5.5.0

Success on x86_64-linux (full log)
Attempted: font-awesome_5
Partial log (click to expand)
Archive:  /build/file
4f4cb7c2f55d14d24f10390ebfeab0d25af612f3
  inflating: /nix/store/6r00asmdxd5baj4fmdjq8h0zpn6crfk3-font-awesome-5.5.0/share/fonts/opentype/Font Awesome 5 Brands-Regular-400.otf
Archive:  /build/file
4f4cb7c2f55d14d24f10390ebfeab0d25af612f3
  inflating: /nix/store/6r00asmdxd5baj4fmdjq8h0zpn6crfk3-font-awesome-5.5.0/share/fonts/opentype/Font Awesome 5 Free-Regular-400.otf
Archive:  /build/file
4f4cb7c2f55d14d24f10390ebfeab0d25af612f3
  inflating: /nix/store/6r00asmdxd5baj4fmdjq8h0zpn6crfk3-font-awesome-5.5.0/share/fonts/opentype/Font Awesome 5 Free-Solid-900.otf
/nix/store/6r00asmdxd5baj4fmdjq8h0zpn6crfk3-font-awesome-5.5.0


Convert to Web/Electron app

Java/Swing may have been a bad choice of what to use for this project. It has become fairly disorganized, and there is a fair amount of redundant code. It is also not that easy (it isn't difficult, but for such a small project it seems a bit odd) to install/set up. Ensuring cross-platform support also comes with its own set of difficulties. As a result, I believe it might be better to instead create a website (and possibly an Electron app) with the same functionality. It will pretty much need to be rewritten from scratch, but I can live with that.

o hai dere


DictTool.php - deleteSlang()

$dictCheck = $this->find($dictStore, $slang); this is not returning a boolean value, but the name of the variable makes it look so, please change it to something more appropriate.
if ($this->find($dictStore, $slang) !== false) should be if (! $this->find($dictStore, $slang))

Same applies to editSlang()

There should be space between line 121 and 122


Append "_P" to all PAK file names if it isn't already present

Mod files are normally incompatible with any aircraft that has an updated model or texture from the base game, or is a DLC aircraft. In order to solve this, .pak instead needs to be _P.pak
Some mod authors have updated their mods accordingly, and most newer mods take this into account, but older mod files do not have this filename suffix (here's an example), and they remain broken as a result. In addition, if any of the current aircraft are updated in the future, all of that aircraft's mods will instantly stop working unless they are renamed.
In order to solve this, users must rename the files accordingly, but this is not something they should be doing with Vortex. Instead, this extension should install all mod files by replacing .pak with _P.pak if the mod file doesn't already end in _P.pak to ensure every mod works.

Thanks for the suggestion @Azekthi ! That definitely seems like it should be easy enough to implement. I'll do some testing to make sure that doesn't break anything and it should make it into the next release 👍

@Azekthi I've just published 0.1.4 of the extension that includes this feature. It's live on Nexus Mods now, so give it a day or two to make it to Vortex and files should be renamed on installation.
This won't apply retroactively though, so you will need to reinstall any affected mods. Thanks again for the suggestion!

This is not working with single-pak files, ones that don't require the special installation process.

Shit, you're right. Thanks for spotting that @Azekthi, I'll fix that up

@Azekthi v0.1.5 has been uploaded now with this fixed (hopefully properly this time).
Give it a day or two to make it to Vortex and let me know if it's still not working right. Thanks again for reporting this!


ntp: fix cross-build

Motivation for this change
fix cross build

@GrahamcOfBorg build pkgsCross.armv7l-hf-multiplatform.ntp

Success on x86_64-linux (full log)
Attempted: ntp
Partial log (click to expand)
shrinking /nix/store/wvvqmdc96252smnxmy449rbiy2wa48rl-ntp-4.2.8p12/bin/ntpdate
shrinking /nix/store/wvvqmdc96252smnxmy449rbiy2wa48rl-ntp-4.2.8p12/bin/sntp
shrinking /nix/store/wvvqmdc96252smnxmy449rbiy2wa48rl-ntp-4.2.8p12/bin/ntpd
shrinking /nix/store/wvvqmdc96252smnxmy449rbiy2wa48rl-ntp-4.2.8p12/bin/ntpq
gzipping man pages under /nix/store/wvvqmdc96252smnxmy449rbiy2wa48rl-ntp-4.2.8p12/share/man/
strip is /nix/store/dxf1m7dhc4qb655bdljc1fsd74v1nag3-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/wvvqmdc96252smnxmy449rbiy2wa48rl-ntp-4.2.8p12/libexec  /nix/store/wvvqmdc96252smnxmy449rbiy2wa48rl-ntp-4.2.8p12/bin  /nix/store/wvvqmdc96252smnxmy449rbiy2wa48rl-ntp-4.2.8p12/sbin
patching script interpreter paths in /nix/store/wvvqmdc96252smnxmy449rbiy2wa48rl-ntp-4.2.8p12
checking for references to /build in /nix/store/wvvqmdc96252smnxmy449rbiy2wa48rl-ntp-4.2.8p12...
moving /nix/store/wvvqmdc96252smnxmy449rbiy2wa48rl-ntp-4.2.8p12/sbin/* to /nix/store/wvvqmdc96252smnxmy449rbiy2wa48rl-ntp-4.2.8p12/bin

Success on aarch64-linux (full log)
Attempted: pkgsCross.armv7l-hf-multiplatform.ntp
Partial log (click to expand)
patching script interpreter paths in /nix/store/fnw2qyl98gvrlxf4m91dzpy9k0d1fzmy-ntp-4.2.8p12-armv7l-unknown-linux-gnueabihf
basename: invalid option -- 'w'
Try 'basename --help' for more information.
basename: invalid option -- 'w'
Try 'basename --help' for more information.
/nix/store/fnw2qyl98gvrlxf4m91dzpy9k0d1fzmy-ntp-4.2.8p12-armv7l-unknown-linux-gnueabihf/bin/ntp-wait: interpreter directive changed from " " to "/nix/store/017xymp5i03qzigafnfx7sgf6602gmzq-bash-4.4-p23/bin/sh"
basename: invalid option -- 'w'
Try 'basename --help' for more information.
checking for references to /build in /nix/store/fnw2qyl98gvrlxf4m91dzpy9k0d1fzmy-ntp-4.2.8p12-armv7l-unknown-linux-gnueabihf...
moving /nix/store/fnw2qyl98gvrlxf4m91dzpy9k0d1fzmy-ntp-4.2.8p12-armv7l-unknown-linux-gnueabihf/sbin/* to /nix/store/fnw2qyl98gvrlxf4m91dzpy9k0d1fzmy-ntp-4.2.8p12-armv7l-unknown-linux-gnueabihf/bin

Success on aarch64-linux (full log)
Attempted: ntp
Partial log (click to expand)
shrinking /nix/store/v2f0a40nhcs6y3q369yf373wfnf6rkbc-ntp-4.2.8p12/bin/ntpdate
shrinking /nix/store/v2f0a40nhcs6y3q369yf373wfnf6rkbc-ntp-4.2.8p12/bin/ntpd
shrinking /nix/store/v2f0a40nhcs6y3q369yf373wfnf6rkbc-ntp-4.2.8p12/bin/sntp
gzipping man pages under /nix/store/v2f0a40nhcs6y3q369yf373wfnf6rkbc-ntp-4.2.8p12/share/man/
strip is /nix/store/428gs2z4b8f9byvghzlpbjwjb3a7jwxx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/v2f0a40nhcs6y3q369yf373wfnf6rkbc-ntp-4.2.8p12/libexec  /nix/store/v2f0a40nhcs6y3q369yf373wfnf6rkbc-ntp-4.2.8p12/bin  /nix/store/v2f0a40nhcs6y3q369yf373wfnf6rkbc-ntp-4.2.8p12/sbin
patching script interpreter paths in /nix/store/v2f0a40nhcs6y3q369yf373wfnf6rkbc-ntp-4.2.8p12
checking for references to /build in /nix/store/v2f0a40nhcs6y3q369yf373wfnf6rkbc-ntp-4.2.8p12...
moving /nix/store/v2f0a40nhcs6y3q369yf373wfnf6rkbc-ntp-4.2.8p12/sbin/* to /nix/store/v2f0a40nhcs6y3q369yf373wfnf6rkbc-ntp-4.2.8p12/bin
/nix/store/v2f0a40nhcs6y3q369yf373wfnf6rkbc-ntp-4.2.8p12

@GrahamcOfBorg build ntp

Success on x86_64-linux (full log)
Attempted: ntp
Partial log (click to expand)
/nix/store/wvvqmdc96252smnxmy449rbiy2wa48rl-ntp-4.2.8p12

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: ntp
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)
Attempted: ntp
Partial log (click to expand)
/nix/store/v2f0a40nhcs6y3q369yf373wfnf6rkbc-ntp-4.2.8p12

Success on x86_64-linux (full log)
Attempted: pkgsCross.armv7l-hf-multiplatform.ntp
Partial log (click to expand)
basename: invalid option -- 'w'
Try 'basename --help' for more information.
basename: invalid option -- 'w'
Try 'basename --help' for more information.
basename: invalid option -- 'w'
Try 'basename --help' for more information.
/nix/store/h7n5wvg3lshs2vbxp9pj8m8j79iqx43w-ntp-4.2.8p12-armv7l-unknown-linux-gnueabihf/bin/ntp-wait: interpreter directive changed from " " to "/nix/store/nii7pk6pv4x4as7vsxbvwyzjn67vax6r-bash-4.4-p23/bin/sh"
checking for references to /build in /nix/store/h7n5wvg3lshs2vbxp9pj8m8j79iqx43w-ntp-4.2.8p12-armv7l-unknown-linux-gnueabihf...
moving /nix/store/h7n5wvg3lshs2vbxp9pj8m8j79iqx43w-ntp-4.2.8p12-armv7l-unknown-linux-gnueabihf/sbin/* to /nix/store/h7n5wvg3lshs2vbxp9pj8m8j79iqx43w-ntp-4.2.8p12-armv7l-unknown-linux-gnueabihf/bin
/nix/store/h7n5wvg3lshs2vbxp9pj8m8j79iqx43w-ntp-4.2.8p12-armv7l-unknown-linux-gnueabihf


Chrome: diff view needs refresh to load the coverage

On the initial switch from a PR to the diff view, the coverage information no longer seems to be loaded.
For example, here are all the requests that happen on the switch:

Funnily, after a refresh the coverage information is correctly loaded.

I wonder if this is related but I have to uninstall and reinstall the Chrome extension to make the diff work.
Then, when I ran the test coverage again, it's gone and have to go thru the uninstall/reinstall again.

I'm having this issue on every file, both in diff view and when browsing a repository. Always requires a reload to make the coverage info show up.


Improve Contact Page Design to Match Website Theme and Enhance Responsiveness

issue #1014
screenshot
Before:

after:

Type of PR

[ ] Bug fix

[X] Feature enhancement

[ ] Documentation update

[ ] Other (specify): _______________

[X] I have made this change from my own.

[X] I have taken help from some online resources.

[X] My code follows the style guidelines of this project.

[X] I have performed a self-review of my own code.

[X] I have commented my code, particularly in hard-to-understand areas.

[X] I have made corresponding changes to the documentation.

[X] My changes generate no new warnings.

[X] I have tested the changes thoroughly before submitting this pull request.

[X] I have Checklist:

@PriyaGhosal  pls assign gssoc label


add missing feature to comparison "Reject unsigned commits"

add issue "Reject unsigned commits" #7455 to docu

Codecov Report

Merging #7456 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #7456      +/-   ##
=========================================
- Coverage   41.21%   41.2%   -0.01%
=========================================
  Files         469     469
  Lines       63557   63557
=========================================
- Hits        26193   26190       -3
- Misses      33943   33945       +2
- Partials     3421    3422       +1

Impacted Files
Coverage Δ

models/repo_list.go
72.08% <0%> (-1.02%)
:arrow_down:

models/gpg_key.go
55.83% <0%> (-0.84%)
:arrow_down:

modules/log/event.go
65.64% <0%> (+1.02%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 50d8d17...2cf1178. Read the comment docs.

-> duplicated with #2770


 However, reslicing can be expensive in a hot loop, so sometimes the code is rewritten to use indexes.
This is what the second variant does. I do realise that the two loops aren't equivalent - for example, if len(p) == 5, the second loop will panic since the length is not a multiple of 4. So I understand why the compiler needs to insert one bounds check.
Still, it seems to me like it should insert one, not four, since I've added the BCE hint. My first thought was that it couldn't prove that i >= 0, but changing the index to be unsigned still doesn't remove all the bounds checks that I'd expect.
I encountered this in the base64 encoder:
di, si := 0, 0
n := (len(src) / 3) * 3
for si < n {
        // Convert 3x 8bit source bytes into 4 bytes
        val := uint(src[si+0])<<16 | uint(src[si+1])<<8 | uint(src[si+2]) // 3 bounds checks

        dst[di+0] = enc.encode[val>>18&0x3F] // bounds check
        dst[di+1] = enc.encode[val>>12&0x3F] // bounds check
        dst[di+2] = enc.encode[val>>6&0x3F]  // bounds check
        dst[di+3] = enc.encode[val&0x3F]     // bounds check

        si += 3
        di += 4
}

Rewriting the loop to use reslicing like for len(src) >= 3 { ...; src = src[3:] } does remove the bounds checks, but slows down the encoder noticeably. Just like in my simple example above, BCE hints like _ = src[si+2] and unsigned indexes didn't help either.
I think there's probably a way to rewrite the loop index logic to trick BCE, but I think the compiler could be made smarter here. I'm not sure whether that should be an enhancement in the prove pass, or in the bounds check elimination pass.
/cc @aclements @rasky @josharian

Possibly related: https://github.com/golang/go/issues/24876

I believe this also affects the base64 decoder - see the comment above. The code iterates over a pair of slices in chunks, much like the encoder:
si := 0
for strconv.IntSize >= 64 && len(src)-si >= 8 && len(dst)-n >= 8 {
        if dn, ok := decode64(
                enc.decodeMap[src[si+0]],
                enc.decodeMap[src[si+1]],
                enc.decodeMap[src[si+2]],
                enc.decodeMap[src[si+3]],
                enc.decodeMap[src[si+4]],
                enc.decodeMap[src[si+5]],
                enc.decodeMap[src[si+6]],
                enc.decodeMap[src[si+7]],
        ); ok {

As before, I tried combining unsigned integers and BCE hints, but no results. I also tried juggling with the for loop conditions, but that didn't make a difference either.

I just realised that removing bounds checks from a loop that jumps more than one position per iteration might not be as easy as it sounds, because of overflows. Imagine:
i := 0
for i < len(data) {
    _ = data[i+0]
    _ = data[i+1]
    _ = data[i+2]
    _ = data[i+3]
    i += 4
}

If len(data) happens to be the maximum integer value, then i+2 could overflow and give a negative number, which would always be a panic when used as an index. Still, a _ = data[i+3] hint should still remove that "is negative" bounds check, since i+2 can't possibly overflow if i+3 didn't.
I presume this trouble disappears if we make the index variable unsigned, since an overflow will just get the index back to 0, which will definitely be within bounds.

/cc @zdjones

https://golang.org/cl/170125 might be interesting to the folks following this thread.