proposal: testing: Add log/slog support

In a test, you often want to mock out the logger. It would be nice to be able to call t.Slog() and get a log/slog logger that send output to t.Log() with the correct caller information.
See https://github.com/neilotoole/slogt for an example of a third party library providing this functionality, but note that it cannot provide correct caller information:

Alas, given the available functionality on testing.T (i.e. the Helper method), and how slog is implemented, there's no way to have the correct callsite printed.

It seems like this needs to be done on the Go side to fix the callsite.

Expanding on this little, there are two cases of logging during testing:

Sometimes you want to examine the log and ensure that some info is in the log.
Sometimes you just want to provide debug information.

This is just about case 2. For that reason, I thinking testing.Slog() should return a slog.Handler that is essentially a slog.TextHandler, except it always logs to the testing.Log stream.
For case 1, people can just log to a bytes.Buffer and poke around as usual, or maybe there can be a log/slog/testslog that has a handler that just appends slog.Records to a big slice you can look at after the test.

See also previous discussion
https://github.com/golang/go/issues/56345#issuecomment-1295757032
https://github.com/golang/go/issues/56345#issuecomment-1296266768

Sometimes you just want to provide debug information.

Yeah, I agree having something like "if this test fails, show me some logs" is a productive idea and different from testing logged output.
The twist seems like - the way that testing observes stack metadata reports lines related to the structure and control flow of running tests. The way that slog observes stack metadata reports where code has decided to emit a slog.Record. We might want both kinds of observations, for example we might have a discrete chunk of test logic where the code under test emits a number of slog.Records worth looking at - we'd want a line annotation for the test logic, and one for each Record.
I had some results decorating a testing.TB with Handler methods and a buffer that would replay slog.Logger calls when t.Error was hit, this kind of thing (https://go.dev/play/p/mPkMxYq2CK__z?v=gotip) ... this approach dictates a particular way of collating slog output via testing.TB hooks, which doesn't feel quite right, however.
I do think other approaches might need a way to access the result of testing.common.skipFrame.

In a test, you often want to mock out the logger

Speak for yourself...

Does the file:line annotation from t.Log help in debugging the test failure? The file:line of the caller should already be available by setting slog.HandlerOptions.AddSource=true.
In my experience the  file:line annotation from t.Log generally makes the test harder to debug because log output and the failure message from t.Error/t.Fatal look identical. This is particularly problematic when logs come from a background goroutine and the failure message appears in the middle of the logging output.
If the goal is to only display log lines when a test fails, I've seen this approach (https://go.dev/play/p/WXHWdRW8s4Z) in a few places:
func testLogger(t *testing.T) *slog.Logger {
	t.Helper()
	buf := new(bytes.Buffer)
	opts := &slog.HandlerOptions{AddSource: true}
	log := slog.New(slog.NewTextHandler(buf, opts))

	t.Cleanup(func() {
		if !t.Failed() {
			return
		}
		t.Helper()
		t.Log("log output\n", buf.String())
	})
	return log
}

This approach makes the failure message and log lines much more distinct. It also addresses some of the challenges in test2json when tests use t.Parallel. The obvious disadvantage is that log output is no longer streamed.
Maybe t.Slog() could omit the leading file:line annotation? Or alternatively a t.Output() that returns an io.Writer that prints without the file:line annotation could be passed to a slog.Logger?

@dnephin

In my experience adding the file:line annotation from t.Log to log output generally makes the test harder to debug because log output and the failure messages from t.Error/t.Fatal look identical.

I'd be totally happy if the output would made to be look different. But I don't think that is possible with the current API. If you log to stdout/stderr, the output looks different, but is then also not correlated with the actual test and interleaved with its t.Error calls. So you end up with a slodge of logging output, then a list of tests runs and failures.

If the goal is to only display log lines when a test fails

Even if you only get the output of failed tests, that still means if you have more than one of those you have no idea what log output belongs where. And even if you only have one failing test (e.g. by re-running it with -run), you have no idea what log output happens before and which happens after the failure.
So, no. The goal is not only to limit log output to failures - it's also to correctly correlate and interleave it with other test output.

https://github.com/golang/go/issues/52751#issuecomment-1515001733 would make more third-party solutions possible, as the top post here discusses.

if you only get the output of failed tests, that still means if you have more than one of those you have no idea what log output belongs where

Looking at the output of https://go.dev/play/p/8s2T3VcEi7C, go test, go test -v, and go test -json all make it clear where the output comes from, for both stdout and t.Log. Stdout interleaved with t.Log is difficult to read, but having worked on projects that use t.Log for logger output, I would argue the file:line annotation from t.Log only makes the cause of the failure harder to find.
Looking at that ouptut I realize that stdout is also hidden by go test when the test passes, so that also can't be the goal of this proposal.

The goal is ... also to correctly correlate and interleave it with other test output.

That is already possible today, so that must not be the purpose of this proposal.

@dnephin
For me at least, not when I run it locally.

https://github.com/golang/go/issues/52751#issuecomment-1515001733 would make more third-party solutions possible, as the top post here discusses.

What does #52751 provide that isn't already possible with slog.HandlerOptions.AddSource=true ?
A library like https://github.com/neilotoole/slogt could implement a handler that:

formats the source attr without the directory (see this example).
format the record as file:line: time=... level=INFO ...
log it with t.Log

This would match exactly the output proposed in #52751.
The problem faced by https://github.com/neilotoole/slogt  must not be retrieving the line that called log.Info, that's already available from slog.HandlerOptions.AddSource=true.
In https://github.com/golang/go/issues/52751#issuecomment-1197360193 I suggested what was missing was a way to print test output that was indented and displayed in the same place as t.Log output, but without the standard file:line annotation. I believe at that time (go1.18) the stdout from tests behaved differently (was not hidden when the test passed, and was grouped separately from t.Log output).
Looking at the output today (https://go.dev/play/p/ES9_Y5BC5kj), it seems those problems are fixed. It should already be possible to implement a logger that has the behaviour described in https://github.com/neilotoole/slogt#deficiency by writing the log output with:
fmt.Printf("    %v: %v\n", filepath.Base(source),  logMsg)

I believe the formatting of test output has changed a few times (from tabs to 4 spaces, and where stdout is printed). It seems possible it could change again in the future.  A t.Print or t.Output returning io.Writer might be more reliable.

@Merovius what version of Go?  Is that from go1.18?  The output you shared is what I remember as well, but I can no longer reproduce with the two latest versions of Go.

go version go1.21rc2 linux/amd64. It's been like this ~forever, for me.

TBF, with -v it interleaves the output correctly. I don't think it used to (again, for me, as far as I remember, all that jazz). So maybe that makes me happy.

What does #52751 provide that isn't already possible with slog.HandlerOptions.AddSource=true ?

While AddSource captures file:line data wherever code under test has chosen to log, #52751 would offer a way to get the file:line of test inputs or other arbitrary points of interest that occur in testing code. This information, from the testing suite rather than the code under test, could be slog.Attr-ized and emitted in slog records (or even baked into handlers).
I think using hooks in testing to trigger emitting logs from code under test is usually plausible, but there are some limitations to this approach. First, it's no longe consistently structured output. Second, it doesn't cover some arrangements. For example, if I have routines for test setup and teardown, there might be interesting activity captured in logs but this doesn't neatly line up with the hooks testing provides. It's not that #52751 solves these issues exactly, but more flexibility in obtaining accurate file:line information from the testing suite would be useful; the information would be conspicuously missing otherwise.

Let me try to summarize.
The request seems to be for a slog.Logger whose output behaves like that of t.Log: it is interleaved properly with the other output from the testing package, and without -v it appears only for failed tests.
The request isn't merely for structured logging that behaves like t.Log, like you could get with something like t.Info(msg, "k1", v1, "k2", v2). I take it no one wants that. For one thing, I don't see why anyone would prefer structured logs to formatted logs for test output, which should be designed for maximum human readability. For another thing, you could get that output with t.Logf("msg=%q k1=%v k2=%v", msg, v1, v2) if you really wanted it. The solution must actually expose a slog.Logger, so it can be injected into the code under test.
The discussion about source locations (file:line information) doesn't seem relevant to this proposal. We already have an accepted proposal, #52751, that adds general source location marking to testing. The slog package already allows you to include, exclude or reformat the source line of the logging call.
So if a slog.Logger with interleaved output is what's wanted, then something like https://go.dev/play/p/nnu-8RLql0X, written without any new API, should almost do it. It will produce interleaved and indented output when run with -v on the current (1.21 prerelease) version of the testing package:
=== RUN   TestTestLogger
    level=INFO msg="info 1"
    t1_test.go:48: t.log
    level=INFO msg="info 2"
    t1_test.go:50: t.log
    level=INFO msg="info 3"
    ...

The -json flag also results in properly interleaved output. Without any flags, the output isn't interleaved, and all of it appears, for passing tests as well as failing ones.
So does that make everyone, as @Merovius says, "happy enough"?

Writing to os.Stdout does not play well with (the lack of) -v, nor does it play well with parallel tests. That said, I think instead it would be fine to use something like
type testWriter struct {
   t *testing.T
}
func (w *testWriter) Write(b []byte) (int, error) {
    t.Logf("%s", b)
    return len(b), nil
}

and then use slog.NewTextHandler(&testWriter{t}, nil)
Perhaps all that is needed is some kind of t.LogWriter() io.Writer method, which could be used with log.New, slog.NewTextHandler, and slog.NewJSONHandler.

t.Output sounds fine to me.

Here's a problem: When you use t.Logf or fmt.Fprintf(t.Output(), ...), you'll always get the right output for the test you're in. But if you write
func Test(t *testing.T) {
    logger := slog.New(slog.NewTextHandler(t.Output(), nil))
    ...
}

then all uses of logger, even in subtests, will write to the output for whatever t was when the logger was constructed. Even without -v, you'll see the output for all subtests, both succeeding and failing ones, grouped with the parent test.
I don't know how annoying or error-prone that's going to be.

all uses of logger, even in subtests, will write to the output for whatever t was when the logger was constructed.

Seems like it's a moving target - while this is probably the wrong thing for tables of unit tests, this seems like the right thing for wider integration tests.

So does that make everyone, as @Merovius says, "happy enough"?

FWIW, I'd mention Kubernetes' ktesting as another interesting exploration of how to integrate testing and logging (pre-slog). I think the approach of testing.T.Output as well as https://github.com/golang/go/issues/52751 is enough to make some third-party extension like this a lot more reasonable, so of course everyone's happy :)

The current proposal is to add the methods
package testing
func (*T) Output() io.Writer
func (*B) Output() io.Writer
func (*F) Output() io.Writer

Writes to tbf.Output() will behave like tbf.Log:

They will appear along with other output for tbf's test/benchmark/fuzz.
Lines will be indented.
They will be displayed only for failing tests, unless the -v or -json flags are provided, in which case they will always be displayed.

@carlmjohnson, this is your issue. If you're okay with this change, could you modify the issue title, and edit your top post to include the above or link to this comment?

Will you also add a new method to the testing.TB interface?

I think as long as Output doesn't add line numbers, it's good.

@ChrisHines I don't see how we could add a method to TB without breaking backwards compatibility.

@jba The authors of testing.TB carved it out of the backwards compatibility contract, see: https://cs.opensource.google/go/go/+/refs/tags/go1.20.6:src/testing/testing.go;drc=38cfb3be9d486833456276777155980d1ec0823e;l=880
	// A private method to prevent users implementing the
	// interface and so future additions to it will not
	// violate Go 1 compatibility.
	private()

As far as I know the only way to implement testing.TB outside of the testing package is to embed it in another type, but in that scenario adding a new method to TB also adds the method to any type that embeds it. :)

To answer the unasked question "why should we add Output" to testing.TB? ...
The practice of writing a logger adapter to forward messages to t.Log is pretty common (I think). It's certainly not new, I've been doing it for years. Our internal logging package (which is basically a blending of uber/zap and go-kit/log) provides just such a wrapper that looks essentially like:
func TestLogger(t testing.TB) rlog.Logger {
    f := func(p []byte) (int, error) {
        t.Logf("%s", p)
        return len(p), nil
    }
    testLogger := NewLogger(writerfunc(f))
    return DuplicateKeyDetector(testLogger, t)
}

type writerfunc func([]byte) (int, error)

func (f writerfunc) Write(p []byte) (n int, err error) { return f(p) }

With the current proposal we could delete the local f function and writerFunc type and just pass t.Output directly to NewLogger. If the method is added to testing.TB this would not require a local interface declaration and type assertion`.
Also of note: DuplicateKeyDetector fails any test for code that tries to log a record with conflicting log keys. The test code for DuplicateKeyDetector mocks testing.TB as seen below. This code would not be broken by adding a new method to testing.TB.
type mockTBInterface struct {
	ErrorStrings []string
	testing.TB
}

func (m *mockTBInterface) Errorf(format string, args ...any) {
	m.ErrorStrings = append(m.ErrorStrings, fmt.Sprintf(format, args...))
}

This may be a similar/overlapping proposal with #43936 where slog output on testing was suggested as a possible way to accomplish test metadata output.

@ChrisHines I did not know about the exception for testing.TB. I guess we would add TB.Output then.

#43936 asks for the ability to add new JSON directly to the test2json output.
Instead of new API in testing it seems like some connection to slog would make more sense.
But that connection would look differently from just using TB.Output, so maybe we should rethink this part.

I'm not sure it needs to look different than TB.Output. A JSON log analyze ought to be able to read JSON nested inside of JSON.

Maybe to help the log analyzers, add a new action for TB.Output. Something like
{
  "Time":"2023-07-25T16:54:03.554841-04:00",
  "Action":"log",
  "Package":"example.com/foo",
  "Output":"{\"nested\": true}"
}

Instead of "Action": "output".

Here's an alternative design that aims to satisfy #43936 as well as this issue.
If t is a testing.T (or B or F), then t.Slog() returns a *slog.Logger. The logger's handler cannot be modified. Its output is coordinated with the rest of the test output. It has no minimum level—all log events are output. It uses the TextHandler format normally, or JSON if the -json flag is present, in which case it appears like
{"action": "log", "record": {"message": "debugging  info", "level":"INFO", "requestID": 123}}

It is now easy to annotate tests with metadata as #43936 asks for, with code like
t.Slog().Info("debugging info",  "requestID", 123)

To satisfy the needs of this proposal, the logger returned by t.Slog() can be passed directly to the code under test. Or the handler can be wrapped to set a minimum level, modify the record, or whatever else is desired, by writing
logger := slog.New(newWrappingHandler(t.Slog().Handler()))

Trying to satisfy both cases likely makes it not ideal for either.
As noted in https://github.com/golang/go/issues/43936#issuecomment-949146528 the testing package doesn't emit JSON directly, so t.Slog() would not be able to emit JSON. It would have to emit some logging format that can be parsed by cmd/test2json. Can the TextHandler output be easily an unambiguously parsed into JSON? How would these lines be distinguished from the existing text output that uses === RUN, etc for framing of events?
A tool attempting to use this new action=log output for metadata would need to be concerned about every possible attribute used by any library that emits logs to slog.Logger. At the very least anyone trying to use it for metadata would have to construct long unique keys to ensure that some library doesn't use the same attribute key. A t.Metadata wouldn't have these problems because only the test cases and maybe a few testing helpers would have access to t.Metadata.
Many of the tools that use the -json output today (IDEs, CI systems, etc) use the run/pass/fail actions to learn about the tests, but will generally print the TestEvent.Output field of action=output events directly to the user. Today logs from a test run would be included in action=output events. When a user switches to t.Slog() the logs will be output from an action=log event. At the very least the TestEvent.Output field of these events should contain the text output of the log. Even then, if the tool that's consuming these events is strict about the actions, there's a reasonable chance it will discard these new events with action=log instead of treating them like action=output. That seems like it could be considered a breaking change. An action=metdata doesn't have this problem because test metadata isn't an important part of the test output. A system reading the test2json output only needs to be concerned about the metadata it knows how to consume, it wouldn't need to be updated to maintain correct behaviour.
Both #43936 and this proposal are similar in that they deal with structured data, but otherwise the use cases are quite different.

So perhaps the dichotomy could be summarized as:

There is a need to be able to associate Stdout (and Stderr) of the code under test with the test case itself... short of backwards incompatible changes to how os.Stdout/Stderr work, the next best thing would be to expose output object(s) directly on testing.TB which can be passed to the code under test. The intent would be to allow this output from the code under test to display with the actual test output, ideally without breaking existing tools reading this via test2json (and also having a chance to work correctly with parallel tests!)
There is a need to be able to have tests emit Metadata to a compatible reader; ideally this has a different "channel" than raw output to allow out of band communication between the test and some test observer.

Slog was mentioned in both places... but I think that @dnephin is right here - fundamentally the requirements are different. The intent is to have separate channels for these different types of data. And it's not clear that code under test should have the ability to emit Metadata for the test incidentally by using slog (I would argue that it should not; test Metadata should require using the testing.TB directly because the code should be aware its talking to a text observer... though I'm willing to be wrong here!). So consider my earlier comment a (likely) red herring :)

I'm more optimistic about t.Slog when thinking about a tool like jq reprocessing output. I also wonder if the TestEvent struct defined in cmd/internal/test2json is like helper-aware file:line stuff - is it unwise to expose these details?

2. There is a need to be able to have tests emit Metadata to a compatible reader; ideally this has a different "channel" than raw output to allow out of band communication between the test and some test observer.

That suggests calling it TB.StdOut() and TB.StdErr().

If we add these it should definitely not be spelled with different casing than the top-level os variables (Stdout and Stderr).

I don't think we understand what is needed here yet. If people are happy with t.Output, they can do that easily themselves:
type testWriter struct {
   t *testing.T
}
func (w *testWriter) Write(b []byte) (int, error) {
    t.Helper()
    t.Logf("%s", b)
    return len(b), nil
}
func TestOutput(t *testing.T) { return &testWriter{t} }

Or you could write a slightly longer one that only writes whole lines. It seems hard to believe that we need to add new API just for that.

In these meandering discussions, it can be good to return to the top comment, which asked specifically for slog+testing integration. The benefits of that would be that slog's file:line could replace what testing would use, and go test -json could embed slog's JSON value into the event or at least flag it as JSON.
Maybe I'm the only one, but these seem like reasonable reasons to do a direct testing+slog integration, in which case the API would be something like
// Slog returns a structured logger that writes to the test case output, like t.Log does.
// When used with go test -json, any log messages are printed in JSON form.
// A TestEvent corresponding to a log message has OutputType "slog", and the Output field contains the JSON text.
func (*T) Slog() *slog.Logger

I'm just brainstorming here. Happy to hear other suggestions.

If people are happy with t.Output, they can do that easily themselves...

People have done something like that, but the source location is wrong.

The motivation for t.Output is to have output that behaves like t.Log without the file:line prefix that is added by t.Log.  There are a few cases where the prefixed file:line is undesirable.

it makes the actual test failure more difficult to find when all of the log output lines look the same as the test failure messages (because they all have file:line prefix)
when using slog, you only care about the file:line where the log was emitted, which slog already provides with AddSource=true. The prefixed file:line of some random test helper, an unrelated line where the logger happened to be created in a test, or an internal stdlib package is not helpful.

Someone could use slog with os.Stdout, the problem with that approach is shown here: https://github.com/golang/go/issues/59928#issuecomment-1614094364. go test will print that output instead of hiding it.
The "behaves like t.Log" means that  go test should hide the output in passing tests, instead of showing it. That would allow someone to trivially create an slog logger using t.Output , while still giving them control over other logger settings.

// A TestEvent corresponding to a log message has OutputType "slog", and the Output field contains the JSON text

What's the use case for "output as json". I thought that part of the discussion was an attempt to satisfy #43936. The concensus seemed to be that these were actually different use cases and that we shouldn't try to solve both together.

The suggestion is that t.Slog returns a logger with a special slog.Handler that behaves like t.Log. That raises some questions.

What is the minimum level of the handler? The default handlers use Info, but we are logging failed tests, so perhaps Debug makes more sense. But then logs at lower levels wouldn't appear, and they might be helpful.

One aspect of slog's flexibility is that an application can provide a handler that processes some values specially. For example, an application might log values of type func() T, and its handler might call those functions just before it outputs the log event. That sort of lazy evaluation is not part of slog, so special functionality like this wouldn't be available to the testing handler.

One advantage of t.Output is that it's just an io.Writer, so the application could use its own handler with it. But that has its problems too. Perhaps the application handler doesn't take an io.Writer, or maybe it outputs a binary format.
I don't think there's a perfect answer, but if we go with t.Slog then the user can always wrap the testing handler with their own:
type myTestingHandler struct {
   h slog.Handler
}

func newTestingLogger(t *testing.T) *slog.Logger {
    return slog.New(&myTestingHandler{h: t.Slog.Handler()})
}

// Enabled enforces a minimum level of Debug-10. It does not call h.h.Enabled,
// so whatever minimum level the testing handler uses is ignored.
func (h *myTestingHandler) Enabled(ctx context.Context, level slog.Level) bool {...}

// Handle replaces attribute values of type `func() T`  with the result of invoking the function,
// then calls h.h.Handle.
func (h *myTestingHandler) Handle(ctx context.Context, r slog.Record) error {...}

Another possibility is that t.Slog could take a slog.HandlerOptions, which would make it easy to set a minimum level and perform some special actions, including the lazy evaluation I described above.

@dnephin, if I understand you right, you are criticizing Russ's claim that people can write t.Output themselves. We agree they cannot because of the source location.
But do you have a problem with Russ's actual suggestion, which aligns with the top post, to have a t.Slog method that behaves like t.Log in the relevant ways (no output for passing tests, etc.)?
I don't think it's critical that the -json flag results in JSON output, but it could make life easier for the consumer of the output. Instead of a line like
{"Time":"...","Action":"slog","Package":"p","Test":"t","Output":"msg=hello k1=1 k2=2"}

where you'd have to parse the output string to recover the key-value pairs, there would be
{"Time":"...","Action":"slog","Package":"p","Test":"t","Output":{"msg":"hello","k1":1,"k2":2}}

which is JSON all the way down.

Another possibility is that t.Slog could take a slog.HandlerOptions, which would make it easy to set a minimum level and perform some special actions, including the lazy evaluation I described above.

Is there another possibility, something like passing t.Slog a slog Handler, and generating log lines for significant testing events from the t (or derived t, etc.)?
Currently testing.TB implementations are a bit privileged - source location in relation to testing.TB.Helper is the obvious one. Resolving this would require greater access to some the internal implementation, or testing.TB implementations could learn to generate slog logging lines. The latter seems messy but finite - I think the destination would be another testing type along the lines of T or B that also knows how to slog.

@jba to be honest, I'm a bit confused about why we went back to talking about t.Slog. I reread this entire comment history in an attempt to understand. In June through August it seems like everyone was happy with testing.T.Output() io.Writer. What changed?

But do you have a problem with Russ's actual suggestion, which aligns with the top post, to have a t.Slog method that behaves like t.Log in the relevant ways (no output for passing tests, etc.)?

First I'd like to challenge the idea that this aligns with the top post. To summarize, the top 2 posts said this about using a logger in tests:

Sometimes you want to examine the log and ensure that some info is in the log.

I believe everyone agrees that this case is already handled by bytes.Buffer. I think this is relevant to the proposal because some tests should explicitly not use an API like t.Slog, and should always use something like:
buf := new(bytes.Buffer)
logger := slog.New(slog.NewJSONHandler(buf, nil)) // or maybe a custom handler to capture the attributes

I think the existence of a t.Slog would make this pattern (using a bytes.Buffer) more difficult to discover.

Sometimes you just want to provide debug information. This [proposal] is just about [this case].

The original problem was the lack of relevant file:line information, but I think I showed in https://github.com/golang/go/issues/59928#issuecomment-1614096137 that the problem isn't a lack of file:line info (that's already available from slog.HandlerOptions.AddSource=true). The problem is actually that t.Log adds an unnecessary and misleading file:line for an irrelevant source location.
testing.T.Output() io.Writer seems like the obvious solution to not only this problem, but a number of other problems I've had in the past when trying to output more detailed failure messages. I believe that was confirmed in https://github.com/golang/go/issues/59928#issuecomment-1645961767  - "I think as long as Output doesn't add line numbers, it's good."

Perhaps the application handler doesn't take an io.Writer, or maybe it outputs a binary format.

It seems like it should always be possible to accept an io.Writer. If the application accepts a higher level interface like slog.Handler or slog.Logger you can easily construct those from an io.Writer. I don't understand why someone would print a binary format to the test output. I'd expect that to go to a buffer.
I think you've already found many of the problems with func (*T) Slog() *slog.Logger. A func (*T) Slog() *slog.Handler was proposed in the second post. I think that's slightly better, but I don't understand why that would be preferred over t.Output given that both would require a line of code to construct the actual logger. I'd like to explore that a bit more, but first a response to another point.

I don't think it's critical that the -json flag results in JSON output, but it could make life easier for the consumer of the output.
{"Time":"...","Action":"slog","Package":"p","Test":"t","Output":{"msg":"hello","k1":1,"k2":2}}

I didn't realize this originally, but I think this has the same problem as I described in https://github.com/golang/go/issues/59928#issuecomment-1650864807.

Many of the tools that use the -json output today (IDEs, CI systems, etc) use the run/pass/fail actions to learn about the tests, but will generally print the TestEvent.Output field of action=output events directly to the user.

Structured JSON output in the Output field breaks the most common use case for test2json output. Any tools reading this now have to convert the JSON back into the text format (whatever was parsed by test2json).
In other words, I don't think the logger should write unescaped JSON in the Output field, as https://github.com/golang/go/issues/59928#issuecomment-1650545429 says, whatever is reading the Output can handle decoding the nested JSON. That shouldn't be a problem.

If I understand correctly there are a few options been discussed for something like t.Slog:
Option 1
func (*T) Slog() *slog.Logger

(Ignoring the part about "When used with go test -json, any log messages are printed in JSON form.", since I've made an argument against that in the second part of https://github.com/golang/go/issues/59928#issuecomment-1873008910).
I think https://github.com/golang/go/issues/59928#issuecomment-1869698665 already calls out the problems with this approach.
I'll add that In general I'd probably want to hide the timestamp from this output, so I'd want something like
ReplaceAttr: func(groups []string, a slog.Attr) slog.Attr {
	// Remove time from the output for predictable test output.
	if a.Key == slog.TimeKey {
		return slog.Attr{}
	}
...

But that may not be application in all cases. The lack of extensibility makes this not a good option.
A variation on this option from the second post:
func (*T) SlogHandler() *slog.Handler

I think this has the same problems.
Option 2
To address those problems the methods could accept handler options.
func (*T) Slog(handlerOpts slog.HandlerOptions) *slog.Logger
...
func (*T) SlogHandler(handlerOpts slog.HandlerOptions) *slog.Handler

What does the go test and go test -v output look like for this logger? Is is equivalent to:
opts := &slog.HandlerOptions{AddSource: true, Level: slog.LevelDebug}
logger := slog.New(slog.NewTextHandler(t.Output(), opts))

If that's the output format it doesn't seem like these new methods on T add much.
Or would it be more like this?
source.go:512: level=INFO msg="something happened" key=value

I mentioned in https://github.com/golang/go/issues/59928#issuecomment-1612317905, in my experience this makes test failures more difficult to debug because the log output looks too similar to the failure message. This problem is considerably worse when logs are output from a background goroutine, because the failure is not at the end of the output, but somewhere in the middle of many log lines, and they all have a similar prefix.
#62728 helps address that problem for test2json output, but I this the problem remains for the standard text format.
Option 3
My proposal is this:
// Output returns a writter that writes to the test case output, like t.Log does, without any leading
// file:line annotations.
func (*T) Output() *io.Writer

// SlogHandlerOptions returns options appropriate for constructing an slog.Handler. The default
// level is set to slog.LevelDebug, AddSource = true, and slog.TimeKey will be omitted from the
// attributes.
func SlogHandlerOptions() *slog.HandlerOptions

This approach makes the common case fairly easy:
logger := slog.New(slog.NewTextHandler(t.Output(), testing.SlogHandlerOptions()))

while still making it possible to customize the logger:
opts := testing.SlogHandlerOptions()
opts.Level  = slog.LevelTrace
logger := slog.New(slog.NewTextHandler(t.Output(), opts))

and allowing the "capture logs for comparison" case to look similar:
buf := new(bytes.Buffer)
logger := slog.New(slog.NewJSONHandler(buf, testing.SlogHandlerOptions()))

SlogHandlerOptions does not really need to be in the testing package. It could be copied around initially. It should be under 10 lines.

I agree with @dnephin. The only thing I’ll add is that besides bytes.Buffer it might be nice to have a slice of slog records to use for test log verification, but that should be a separate proposal. I think t.Output solves this case and leaves things open for whatever future log stuff comes up.

t.Output gives much more flexibility for other use cases.


Download only a subset

Hello,
Would it be possible to download only a subset of repository? I am only interested in a very small set of repository and I would want to download everything from them, but not the rest of Github (it's pretty huge).

Yes, you can download a date range, see: https://www.githubarchive.org/. If you need to filter by other dimensions, you can query and export just the data you need from BigQuery.


Add spellings for personal website

@jonleung made a commit for this already but apparently didn't submit a PR. I removed lowercase "alice" from the dictionary since alice1337 should have been in backquotes.

Looks good to me!


Popover cssClass does not target correct area. (Ionic V4)

Bug Report
Ionic Info
Run ionic info from a terminal/cmd prompt and paste the output below.
Ionic:

   ionic (Ionic CLI)          : 4.1.2 (/usr/local/lib/node_modules/ionic)
   Ionic Framework            : @ionic/angular 4.0.0-beta.11
   @angular-devkit/core       : 0.7.5
   @angular-devkit/schematics : 0.7.5
   @angular/cli               : 6.1.5
   @ionic/ng-toolkit          : 1.0.8
   @ionic/schematics-angular  : 1.0.6

Cordova:

   cordova (Cordova CLI) : 8.0.0
   Cordova Platforms     : not available
   Cordova Plugins       : not available

System:

   Android SDK Tools : 26.1.1 (/Users/williamterrill/Library/Android/sdk/)
   ios-deploy        : 1.9.2
   NodeJS            : v8.11.1 (/usr/local/bin/node)
   npm               : 5.6.0
   OS                : macOS High Sierra
   Xcode             : Xcode 9.4.1 Build version 9F2000

Describe the Bug
when using the popover components, the cssClass: "popover_class" targets the parent page and not the popover itself.
Steps to Reproduce
Steps to reproduce the behavior:

Create new ionic 4 project
generate new component: (ionic generate component testPopover)
Create button in home page that points to ts file:

      <ion-button icon-only solid *ngIf="admin" (click)="presentTest($event)">
          <ion-icon name="menu"></ion-icon>
        </ion-button>

In home.page.ts file, add this code (and all associated imports):

import { PopoverController } from "@ionic/angular";
import { TestPopoverComponent } from "../test-popover/test-popover.component"

  async presentTest(args) {
    const popover = await this.popoverCtrl.create({
      component: TestPopoverComponent,
      event: args,
      componentProps: args,
      translucent: true,
      cssClass: "popover_class"
    });
    return await popover.present();
  }

in global.scss or variable.scss add:

.popover_class{
  --background: blue;  // to take care of a possible css4
  background: blue;     // to treat it as normal css

}

After an 'ionic serve' press the menu button.  Instead of just the background color of the popover container turning blue, the background of the parent page turns blue.

Expected Behavior
the cssClass property of the popover Component should only affect the container of the popover component, and not the parent container
FWIW: The only way that I can see to change the background color (or any other property) of the popover is by placing:
.popover-content.sc-ion-popover-ios{
background: yellow;
}
in either variable.scss or global.scss.

The class is being properly applied to the ion-popover element. The problem here is when you style the background you are changing the background of the element that takes up the full width/height over the content. If you were to set the background to something with transparency, for example:
.popover_class {
  background: rgba(0, 0, 0, 0.4);
}

You'll see the page itself isn't getting the background. Because the overlay components (alert, action sheet, popover, etc) aren't using shadow DOM, you can use normal CSS to target whichever element you want to style. So to style just the content:
.popover_class .popover-content {
    background: lightsteelblue;
}

Whether or not we will be adding CSS Variables to target certain elements is something we still need to discuss internally though.

outstanding.  That makes more sense.  Thank you for the help.

@brandyscarney Don't know if anything changed between when you commented and Ionic v4.0.0-beta.19, but the solution you provided is not working currently with the beta.19. However, I did notice that it does work if I have my ViewEncapsulation set to None. Is this normal?
Also, the solution you provided, is this a clean approach as we are directly accessing the component's internal class (.popover-content)? The ionic team could decide to change this class name any time without notice, as .popover-content in a way isn't a publicly documented class, which would break this implementation for many people.


Root-Config does not run

Not able to run root-config project due to below error
Error: single-spa-layout: The HTMLElement passed to constructRoutes must be . Received TEMPLATE
at single-spa-layout.min.js:2
at WEBPACK_DYNAMIC_EXPORT../node_modules/single-spa-layout/dist/umd/single-spa-layout.min.js.e.constructRoutes (single-spa-layout.min.js:2)
at Module../src/root-config.js (root-config.js:8)
at webpack_require (bootstrap:19)
at Object.0 (react-mf-root-config.js:9858)
at webpack_require (bootstrap:19)
at bootstrap:83
at Object.execute (bootstrap:83)
at i (system-core.js:276)

Hi @ajaybeniwal, this is usually caused by installing the wrong version of single-spa-layout, which can happen if you don't use the version specified in the yarn.lock file. Try running yarn install instead of npm install, as instructed in the readme.


Enable Brotli and GZIP compression

This seems like a quick implementation on nginx.

This is a deployment concern which has been addressed for UNICEF's deployments. There is nothing to do within the app, so I suggest that this issue be closed.

Great, it looks like the HTML is compressed:

I think the JS and CSS files are not getting compressed:

Maybe those MIME types need to be specified? https://stackoverflow.com/questions/5131916/how-to-deflate-js-file-in-nginx#5132440

I have raised an issue in the DevOps board to continue the work on this. Closing this issue.


Wrap text

For long text value, is there a way to display it on multiple line (wrap text)?

Hi,
currently not, but thanks for the idea. I will take it up for 0.3.2 but first I need to release 0.3.1.
Regards,
Guy

Hi,
I've been able to do it by updating the template (adding item-text-wrap in few places)
'',
'',
'',
'',
'',
'',
'',
'{{viewModel.cancelLabel}}',
'',
'',
'{{viewModel.selectedItemsLabel}}',
'',
'',
'{{viewModel.getItemValue(selectedItem, viewModel.itemViewValueKey)}}',
'',
'',
'{{viewModel.selectItemsLabel}}',
'',
'{{viewModel.getItemValue(item, viewModel.itemViewValueKey)}}',
'',
'',
''
Date: Fri, 23 Oct 2015 00:14:13 -0700
From<EMAIL_ADDRESS>To<EMAIL_ADDRESS>CC<EMAIL_ADDRESS>Subject: Re: [ion-autocomplete] Wrap text (#102)
Hi,
currently not, but thanks for the idea. I will take it up for 0.3.2 but first I need to release 0.3.1.
Regards,
Guy
—
Reply to this email directly or view it on GitHub.

Hi @touletan,
thanks for your contribution. I just added it to the master and it will be release in 0.3.1.
Thanks and regards,
Guy


Refactored u8 to use the BlockExt trait

Checklist

[ ] Linked to Github Issue
[ ] Unit tests added
[ ] Integration tests added.
[ ] This change requires new documentation.

[ ] Documentation has been added/updated.

Codecov Report
Attention: Patch coverage is 92.72727% with 12 lines in your changes missing coverage. Please review.

Project coverage is 91.61%. Comparing base (b2f1568) to head (9dc3601).
Report is 11 commits behind head on main.

Files
Patch %
Lines

src/libfuncs/uint8.rs
92.72%
12 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #667      +/-   ##
==========================================
- Coverage   91.95%   91.61%   -0.35%
==========================================
  Files         112      115       +3
  Lines       34265    34561     +296
==========================================
+ Hits        31509    31663     +154
- Misses       2756     2898     +142

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Really minor: divide is slow and serializing

It might not matter too much, but it irks me: the divides in unvme_fio.c
     u64 slba = io_u->offset / unvme.ns->blocksize;
     int nlb = io_u->xfer_buflen / unvme.ns->blocksize;

are slow (divide is a serializing and generally slow instruction).  Since I doubt
NVMe will ever support non-powers-of-two sizes, it might be worth computing
    unvme.ns->blocksize_lg2 = log2(unvme.ns->blocksize);

at init and use shifts
     u64 slba = io_u->offset >> unvme.ns->blocksize_lg2;
     int nlb = io_u->xfer_buflen >> unvme.ns->blocksize_lg2;

where log2() is left as an exercise for the reader.

Ok, I added the pageshift and blockshift values to the unvme_ns_t structure.

thanks


Holding records 8xx fields

@joycebcat at currently we only pull the 852s from the holding records into the Blacklight holdings block. Should we include additional fields in 850-880?
We currently are including 856, 866, 867, and 868 from the bilbiographic record. Would we ever want to strip these out from the bib record (like we do with the bib 852s?). I know that most of the time the 856 in the bibliographic matches with the elf locations. However this isn't always true.
In bib 4609321 the bib 856s don't correspond to an online holding location. In this case there is no way to match up the links to the holdings with certainty. The holding record also has an 866 field not present in the bib record.
In bib 7617477, there are 856s in the holdings record which are different from the bib record's 856s.

Just to clarify this:

In bib 4609321 the bib 856s don't correspond to an online holding location. In this case there is no way to match up the links to the holdings with certainty. The holding record also has an 866 field not present in the bib record.

There are two holdings, and we've digitized both. There are descriptive notes about the holdings in each holding record, but the links to the digitized versions are in the bib record. The problem is that we don't have a way to know which link (856) should be associated with which holding.
I'm sure there are reasons why this is more difficult that it sounds, but to me the solution would be to put the 856s in the holding records rather that the bib record.
(FWIW, longer term, I'd love see the PUDL or next iteration thereof become a separate holding location, so that we can facet on it just like any physical location--perhaps that's worth considering as part of this conversation?)

It's also worth noting that in the case of 4609321, there's probably a case to be made for the two holdings to be cataloged separately; one is a complete Gutenberg bible, and the other is a fragment, with different provenance, etc.

@tampakis We had a reason for not putting the URL into the holdings record --it was related to searching capabilities and maintenance issues in Voyager initially, but follows what developed as common practice of putting this into the bib data.  Yes, matching up with a specific holding will be a problem in some cases--not too many as we tend to have separate records for each e-version of material we license.  The problems will almost entirely be with our own material which we have digitized.  Sigh.  Jon points out in his earlier message how cataloging decisions interact with this topic.
We never want to use 852 from the bib record, we DO want to use 856 from the bib, but no other holdings fields from the bib.  Officially our current practice is that other than the 856, all holdings data related to Princeton is stored in the mfhd.
I think the suggestion about the Digital Library as a location of its own is worth considering more closely.

Ok thanks @joycebcat. Your comments imply to me that we should be indexing more of the mfhd into Solr. I'm interested in your thoughts about bib vs mfhd 866, 867, 868. Should we exclude the bib 86X fields like we do the 852s?

@joycebcat are you saying that many of the PUDL items we have stored URLs in the catalog will not have one our "elf*" holding locations?

No, I'm saying that the cases where there are multiple 856s in the bib relating to different holdings records will be an issue with pudl material, and shouldn't/won't be a problem with anything else.

@tampakis The only "holdings" data we should harvest from the bib record is 856.  Yes, we should exclude other 86x fields from the bib--they will not apply to Princeton.  (To what extent to we use 867 and 868????)

@joycebcat this is what I took from the Voyager config file: https://github.com/pulibrary/orangeindex/blob/development/lib/traject_config.rb#L842-L876
The 867 populates a field called "Supplements" and the 868 populates a field called "Indexes." At the very least I need to make sure that these fields only get included from the mfhd.

@tampakis OK. Thanks.


cron time + DST trouble

I'm using Fugit.parse('55 6 * * 2#1 America/Los_Angeles') for a monthly alert.
This has been alerting fine at 6:55 all the time, but 2020-12-01 it alerted 1 hour early (5:55).
Last time it alerted Nov 3 at 6:55 AM which was in DST already, so I'd have expected that to fail and not the December one, but there is a chance it was scheduled before DST kicked in.
I reproduced the issue using Timecop.travel('2020-11-30') and Fugit.parse('55 6 * * 2#1 America/Los_Angeles').next_time.to_debug_s and it looks like the timezone is wrong:
Timecop.travel('2020-11-30')
# => 2020-11-30 00:00:00 -0800
Fugit.parse('55 6 * * 2#1 America/Los_Angeles').next_time.to_s
# => "2020-12-01 07:55:00 -0700" <-- wrong ?
Time.now
# => 2020-11-30 00:09:15 -0800

Hello,
quick question, what version of fugit are you using?

1.3.3
.... update all my gems, but results were the same, will deploy that and see if the alert comes early again

Thanks.
1.3.9 has a change in the way it deals with DST transition, hence my question. I will test on 1.4.1.

sounds like the bug I saw, I'll report back in a month if it reproduces :)
On Tue, Dec 1, 2020 at 1:42 PM John Mettraux<EMAIL_ADDRESS>wrote:

Thanks.
1.3.9 has a change in the way it deals with DST transition, hence my
question. I will test on 1.4.1.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/floraison/fugit/issues/48#issuecomment-736838419, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAACYZYZARDKNGWN33WFKRDSSVPKRANCNFSM4UJLG7XQ
.

Could you please give me the output of
uname -a
bundle exec ruby -v
bundle exec ruby -e "p [ :env_tz, ENV['TZ'] ]"
bundle exec ruby -r et-orbi -e "EtOrbi._make_info"
bundle exec ruby -r fugit -e "p Fugit::VERSION"

on your system?
Thanks in advance.

don't work on this, good chance it's done ... will report back if it's not :)


[#2708] 1.6.1-RC1 release

(1.6.1-RC1 -> 1.6.1-SNAPSHOT)

Codecov Report

Merging #2727 into master will decrease coverage by 0.04%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2727      +/-   ##
==========================================
- Coverage   40.75%   40.71%   -0.05%
==========================================
  Files        1773     1773
  Lines       61124    61124
  Branches     8589     8589
==========================================
- Hits        24913    24888      -25
- Misses      36211    36236      +25

Impacted Files
Coverage Δ

.../java/com/navercorp/pinpoint/rpc/cluster/Role.java
0% <0%> (-71.43%)
:x:

...a/com/navercorp/pinpoint/rpc/util/StringUtils.java
0% <0%> (-28.58%)
:x:

...rp/pinpoint/rpc/control/ControlMessageDecoder.java
66.07% <0%> (-14.29%)
:x:

...pinpoint/rpc/ChannelWriteFailListenableFuture.java
57.14% <0%> (-14.29%)
:x:

...vercorp/pinpoint/rpc/packet/ClientClosePacket.java
72.22% <0%> (-11.12%)
:x:

.../pinpoint/rpc/client/PinpointClientHandshaker.java
67.36% <0%> (-6.95%)
:x:

...navercorp/pinpoint/rpc/common/SocketStateCode.java
83.75% <0%> (-2.5%)
:x:

...m/navercorp/pinpoint/test/OrderedSpanRecorder.java
77.9% <0%> (-1.17%)
:x:

...corp/pinpoint/rpc/stream/StreamChannelManager.java
75.86% <0%> (-1.15%)
:x:

...orp/pinpoint/rpc/server/DefaultPinpointServer.java
80.68% <0%> (-1.14%)
:x:

... and 5 more

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 ec5ac89...27d7e1c. Read the comment docs.


Windows logging to file on different drive fails

On Windows, when logging to a file on a different drive, where the file and the directory do not exist, fails. Logs are not written to the file, the log file is not created, and the directory is not created. The following is the output from the reproducer program.
date       time         ( uptime  ) [ thread name/id ]                   file:line     v|
2023-05-03 15:14:38.455 (   0.058s) [main thread     ]             loguru.cpp:659   INFO| arguments: C:\\Users\\pnova\\loguru\\loguru_repro\\x64\\Debug\\loguru_repro.exe
2023-05-03 15:14:38.459 (   0.059s) [main thread     ]             loguru.cpp:662   INFO| Current dir: C:\Users\pnova\loguru\loguru_repro\loguru_repro
2023-05-03 15:14:38.459 (   0.059s) [main thread     ]             loguru.cpp:664   INFO| stderr verbosity: 0
2023-05-03 15:14:38.459 (   0.059s) [main thread     ]             loguru.cpp:665   INFO| -----------------------------------
2023-05-03 15:14:38.459 (   0.059s) [main thread     ]             loguru.cpp:809    ERR| Failed to open 'D:\logs\everything.log'
2023-05-03 15:14:38.459 (   0.059s) [main thread     ]       loguru_repro.cpp:13     ERR| Log something
2023-05-03 15:14:38.459 (   0.059s) [main thread     ]             loguru.cpp:538   INFO| atexit

Reproducer:
#include "loguru.hpp"

int main(int argc, char **argv)
{
    loguru::init(argc, argv);

    // D: drive exists, but D:\logs\everything.log does not exist:
    loguru::add_file("D:\\logs\\everything.log", loguru::Append, loguru::Verbosity_MAX);

    LOG_F(ERROR, "Log something");
}

The issue is rather that the parent folder is not created when it doesn't exist. Make sure to create it yourself then:
// D: drive exists, but D:\logs\everything.log does not exist:
std::filesystem::path log_file_path = "D:\\logs\\everything.log";
std::filesystem::create_directories(log_file_path.parent_path());
const auto log_file_path_string = log_file_path.string();
loguru::add_file(log_file_path_string.c_str(), loguru::Append, loguru::Verbosity_MAX);

LOG_F(ERROR, "Log something");

I agree however that it would be great if loguru handled this correctly by itself internally. However, it's quite a C mess.

Ah, my mistake, thanks for the response. Closing issue.


Cannot delete git-annex directory

Getting this:
[jcohen@gra-login3 ~]$ rm -rf data-multi-subject/
rm: cannot remove 'data-multi-subject/.git/annex/objects/Mm/XM/SHA256E-s18582870--fc52f3193bbfd019e72467c15cac7a32259e52e86a251e654501143b917f5ffc.nii.gz/SHA256E-s18582870--fc52f3193bbfd019e72467c15cac7a32259e52e86a251e654501143b917f5ffc.nii.gz': Permission denied

I remember @kousu had a trick, but i forgot what it was. We should document it.

Just sudo it.
git-annex is extra-paranoid even more than regular git, and sets all the files and even their containing folders read-only. -f can't override that. You could also do chown -R +w data-multi-subject/.git/annex; rm -r data-multi-subject.
I'll put this on my list of complaints about git-annex.

Just sudo it.

oopsi 😬
[jcohen@gra-login2 ~]$ sudo rm -rf data-multi-subject

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for jcohen:
jcohen is not in the sudoers file.  This incident will be reported.

You could also do chown -R +w data-multi-subject/.git/annex; rm -r data-multi-subject.

I get (i've only copy/pasted one example, for clarity):
rm: cannot remove 'data-multi-subject/.git/annex/objects/kf/Mj/SHA256E-s9041156--693308b91a69d98479a91f66b07902bbc7ed98f214c3c62aec2534d6e7b4aa61.nii.gz/SHA256E-s9041156--693308b91a69d98479a91f66b07902bbc7ed98f214c3c62aec2534d6e7b4aa61.nii.gz': Permission denied

This is what I get for answering threads late at night! Try this:
chmod -R +w data-multi-subject/.git/annex; rm -r data-multi-subject

There is a clean way to rm -rf repo, if you config the repository during initialization stage:
git config core.sharedRepository group

I've found this issue while searching for a solution to the the same problem, on an unrelated repository. Eventually, I've got the hint (with the warning of accidental deletion) from git annex author:
https://git-annex.branchable.com/forum/less_paranoid_mode/
I hope it helps.


Refactor navigation bar components on unauthenticated pages

These are duplicated in a few places, makes updating them a bit of a pain and I didn't want to do it in #852. Refactoring that into a shared component with the right hand side remain flexible will make maintaining/changing things in those unauthenticated pages there easier going forward.

@darrenvong I don't totally understand this, is it still an issue?

Yes, there is a lot of copy and pasted code if you look on the landing page, sign up and login page when they have the same mobile and desktop markup in some places. I think we can be smarter by refactoring into a base and use props to make the small bit that are different configurable, similar to what we're planning to do for the community base

I think this is done


The background is transparent in some themes

The Blue Topaz theme I am using, and I don't know why it caused the window background to become transparent. I have resolved the issue by change the CSS. Thank u for developing this very useful plugin.

I'm glad you find the plugin useful. This issue is likely caused by the theme you are using, which probably set the --background-secondary CSS variable to a transparent colour. There isn't really a good fix I can do for this on my end unless I hard-code the background-color (which is undesirable as well).


Need help with installation

Hey, It would be great if someone helps me with the installation process on how to run this locally on my computer

Hey, It would be great if someone helps me with the installation process on how to run this locally on my computer嘿，如果有人能帮我安装如何在我的计算机上本地运行它，那就太好了。

I can help you


APS-530 Add additional fields to CAS1 withdrawal emails

Relates to https://dsdmoj.atlassian.net/browse/APS-530
The following emails have been updated to include a link to the application timeline, and the name of the person who triggered the withdrawal:

application withdrawn
assessment withdrawn
request for placement withdrawm
match request withdrawn
placement withdrawn

This is controlled by a feature flag that is disabled in prod by default

Thanks, this is very clear.
But I'm not sure why we need a feature flag here? Probably I'm missing some complexity, but would it be adequate and simpler to:

introduce the new template at Notify
change the code to use that new template
remove the old template at Notify once the new code has been deployed to production

Using this approach we have the potential for new emails to be used in production before we've had a chance to test them in pre-prod. Note that we don't have a way to test these emails until we get to pre-prod
I think we need a discussion about email templates in general. If we rendered the template 'in code' and used notify as a glorified SMTP relay that would avoid this issue.


Do we really support application/xml?

The default value for --structured-mime-types includes the following:
  "structuredMimeTypes": [
    "application/json",
    "application/xml",
    "text/plain",
    "text/xml",
    "text/yaml"
  ],

Do we really support serialization of application/xml?  Are the text/yaml and text/xml processed by the text serializer?  Does the method signature accept/return as a string?

We support the generation of models. However we don't have serialization and deserialization implementations today.

FYI I've removed those mime types from the default supported ones in https://github.com/microsoft/kiota/pull/2078
I guess we should now rename this issue to add serialization support for those types.

@darrelmiller is there documentation around creating and registering custom serializers for Kiota that you could share? Our team has just hit a situation where we wanted to use Kiota proxies with a XML-based API.
From your comment above, I assume creating a serializer for XML and plugging it in should be a supported extension point.

@julealgon
For serialization you would need to implement these two interfaces.

https://github.com/microsoft/kiota-dotnet/blob/main/src/abstractions/serialization/ISerializationWriter.cs
https://github.com/microsoft/kiota-dotnet/blob/main/src/abstractions/serialization/ISerializationWriterFactory.cs

For deserialization

https://github.com/microsoft/kiota-dotnet/blob/main/src/abstractions/serialization/IParseNodeFactory.cs
https://github.com/microsoft/kiota-dotnet/blob/main/src/abstractions/serialization/IParseNode.cs

Once this is done, you will register the serializer and deserializer as is done here with the client and you should be able to make requests.
https://github.com/microsoft/kiota-samples/blob/dc238d655fc0e7fb3d1886affd95cd663385329c/msgraph-mail/dotnet/ApiClient.cs#L32
You can also checkout the example implementation for form serialization here for inspiration.
https://github.com/microsoft/kiota-dotnet/tree/main/src/serialization/form


Support custom file extensions (through patterns)

/reference https://github.com/babel/babel-brunch/issues/7
Adds support for the pattern attribute provided to brunch plugins. This allows babel-brunch to support any number of file extensions, because we're the Javascript community and we can't decide on anything :smile:

Well done. Thanks.

Thanks! Mind bumping the version a patch release?

Working on it. It'll be a minor version bump to 5.1.0


strings: optimize ToLower()

Hi,
I want to optimize the ToLower function and its dependencies.
Reduce memory allocation, early return...
Why
I made a small pkg for patern matching https://github.com/IGLOU-EU/go-wildcard
I wanted to add a "case-insensitive" option, but it loses a lot of performance, even for an empty string.
Bench
BenchmarkMatch/0-16             454892713            0.9726 ns/op           0 B/op          0 allocs/op
BenchmarkMatch/1-16             349304181            2.928 ns/op           0 B/op          0 allocs/op
BenchmarkMatch/2-16             476728009            2.127 ns/op           0 B/op          0 allocs/op
BenchmarkMatch/3-16             290518609            3.822 ns/op           0 B/op          0 allocs/op
BenchmarkMatch/4-16             124291632            8.709 ns/op           0 B/op          0 allocs/op
BenchmarkMatch/5-16             23469135            48.56 ns/op        0 B/op          0 allocs/op

BenchmarkMatchCasefold/0-16      7673000           216.3 ns/op        48 B/op          1 allocs/op
BenchmarkMatchCasefold/1-16      7057550           223.6 ns/op        48 B/op          1 allocs/op
BenchmarkMatchCasefold/2-16      6580888           215.7 ns/op        48 B/op          1 allocs/op
BenchmarkMatchCasefold/3-16      3193930           451.2 ns/op        96 B/op          2 allocs/op
BenchmarkMatchCasefold/4-16      3213775           473.1 ns/op        96 B/op          2 allocs/op
BenchmarkMatchCasefold/5-16      2305406           481.4 ns/op        32 B/op          1 allocs/op

If you can come up with a correct optimization, feel free to send a CL with benchmarks.
Otherwise I don't see anything actionable here.


Firebase ui-auth dependencies do not resolve: manifest merger failed

Step 2: Describe your environment

Android device: N/A
Android OS version: 6
Google Play Services version: N/A_____
Firebase/Play Services SDK version: 10.1 _____
FirebaseUI version: 1.1.1____

compileSdkVersion 25
buildToolsVersion "25.0.2"
Step 3: Describe the problem:
I'd like to use the firebase-ui-auth with google, ex:
    startActivityForResult(
            AuthUI.getInstance()
                    .createSignInIntentBuilder()
                    .setIsSmartLockEnabled(!BuildConfig.DEBUG)
                    .setProviders(Arrays.asList(new AuthUI.IdpConfig.Builder(AuthUI.EMAIL_PROVIDER).build(),
                            new AuthUI.IdpConfig.Builder(AuthUI.GOOGLE_PROVIDER).build()))
                    .build(),
            RC_SIGN_IN);

But I'm unable to resolve the dependencies
Steps to reproduce:
Make project with deps
compile 'com.android.support:appcompat-v7:25.1.0'
compile 'com.android.support:design:25.1.0'
compile 'com.squareup.okhttp3:okhttp:3.5.0'
compile 'com.google.firebase:firebase-messaging:10.0.1'
compile 'com.google.firebase:firebase-core:10.0.1'
compile 'com.google.firebase:firebase-crash:10.0.1'
compile 'com.firebaseui:firebase-ui-auth:1.1.1'

Observed Results:
Error is Error:Execution failed for task ':app:processDebugManifest'.

Manifest merger failed : Attribute application@supportsRtl value=(true) from AndroidManifest.xml:15:9-35
is also present at [com.firebaseui:firebase-ui-auth:1.1.1] AndroidManifest.xml:14:18-45 value=(false).
Suggestion: add 'tools:replace="android:supportsRtl"' to  element at AndroidManifest.xml:11:5-50:19 to override.

Same result if I add:
compile 'com.google.android.gms:play-services-auth:10.0.1'
Relevant Code:
n/a

@andrewrapp look at the issue #520

That seems to have fixed it. In addition I had to add xmlns:tools="http://schemas.android.com/tools" to the manifest. Thanks!


lz4: 1.8.2 -> 1.8.3

Upstream release notes, quickfix release for corruption bug

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Fits CONTRIBUTING.md.

Success on x86_64-darwin (full log)
Attempted: lz4
Partial log (click to expand)
post-installation fixup
Patching '/nix/store/g4468haap38gkfwrspmm9bccvvhbhlgp-lz4-1.8.3-dev/lib/pkgconfig/liblz4.pc' includedir to output /nix/store/g4468haap38gkfwrspmm9bccvvhbhlgp-lz4-1.8.3-dev
gzipping man pages under /nix/store/r4vqqbnh8sk3g0r5rm8gakp26sfzfgri-lz4-1.8.3/share/man/
strip is /nix/store/4w56qihlrddav67p7d1vy5qkyayaqw11-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/r4vqqbnh8sk3g0r5rm8gakp26sfzfgri-lz4-1.8.3/lib  /nix/store/r4vqqbnh8sk3g0r5rm8gakp26sfzfgri-lz4-1.8.3/bin
patching script interpreter paths in /nix/store/r4vqqbnh8sk3g0r5rm8gakp26sfzfgri-lz4-1.8.3
strip is /nix/store/4w56qihlrddav67p7d1vy5qkyayaqw11-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/g4468haap38gkfwrspmm9bccvvhbhlgp-lz4-1.8.3-dev/lib
patching script interpreter paths in /nix/store/g4468haap38gkfwrspmm9bccvvhbhlgp-lz4-1.8.3-dev
/nix/store/r4vqqbnh8sk3g0r5rm8gakp26sfzfgri-lz4-1.8.3

Success on aarch64-linux (full log)
Attempted: lz4
Partial log (click to expand)
strip is /nix/store/y4ymnvgxygpq05h03kyzbj572zmh6zla-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/l9jahmqrr2dx3x7fn52hll3bgsy51rv4-lz4-1.8.3/lib  /nix/store/l9jahmqrr2dx3x7fn52hll3bgsy51rv4-lz4-1.8.3/bin
patching script interpreter paths in /nix/store/l9jahmqrr2dx3x7fn52hll3bgsy51rv4-lz4-1.8.3
checking for references to /build in /nix/store/l9jahmqrr2dx3x7fn52hll3bgsy51rv4-lz4-1.8.3...
shrinking RPATHs of ELF executables and libraries in /nix/store/pzz2vc0kg7k97465hgvviycnkm582a4q-lz4-1.8.3-dev
strip is /nix/store/y4ymnvgxygpq05h03kyzbj572zmh6zla-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/pzz2vc0kg7k97465hgvviycnkm582a4q-lz4-1.8.3-dev/lib
patching script interpreter paths in /nix/store/pzz2vc0kg7k97465hgvviycnkm582a4q-lz4-1.8.3-dev
checking for references to /build in /nix/store/pzz2vc0kg7k97465hgvviycnkm582a4q-lz4-1.8.3-dev...
/nix/store/l9jahmqrr2dx3x7fn52hll3bgsy51rv4-lz4-1.8.3

Success on x86_64-linux (full log)
Attempted: lz4
Partial log (click to expand)
strip is /nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/z1z4wjx5lcpjz8k49602dqlmkh2j89sa-lz4-1.8.3/lib  /nix/store/z1z4wjx5lcpjz8k49602dqlmkh2j89sa-lz4-1.8.3/bin
patching script interpreter paths in /nix/store/z1z4wjx5lcpjz8k49602dqlmkh2j89sa-lz4-1.8.3
checking for references to /build in /nix/store/z1z4wjx5lcpjz8k49602dqlmkh2j89sa-lz4-1.8.3...
shrinking RPATHs of ELF executables and libraries in /nix/store/p6kbarwy7lha9sngd5w24cw6i8k250lz-lz4-1.8.3-dev
strip is /nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/p6kbarwy7lha9sngd5w24cw6i8k250lz-lz4-1.8.3-dev/lib
patching script interpreter paths in /nix/store/p6kbarwy7lha9sngd5w24cw6i8k250lz-lz4-1.8.3-dev
checking for references to /build in /nix/store/p6kbarwy7lha9sngd5w24cw6i8k250lz-lz4-1.8.3-dev...
/nix/store/z1z4wjx5lcpjz8k49602dqlmkh2j89sa-lz4-1.8.3

Time to do the "move to staging" dance and tag everyone for no reason because "github" ;(.
/me starts dancing

Timed out, unknown build status on x86_64-darwin (full log)
Attempted: lz4
Partial log (click to expand)
cannot build derivation '/nix/store/6y4kz2cszr206y4c0g2f6j8shnwdw62b-perl-5.28.0.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/x4vkib8a9pdr5ws23zz5nkgbx2j64a4n-pkg-config-0.29.2.drv': 3 dependencies couldn't be built
cannot build derivation '/nix/store/ynmxpnvbzw3zdmkddq615bg5zac1amcy-unzip-6.0.drv': 3 dependencies couldn't be built
cannot build derivation '/nix/store/kzx3rmxp28kdf1wxpiqikmjwc9clnfvx-openssl-1.0.2p.drv': 3 dependencies couldn't be built
cannot build derivation '/nix/store/mi69karlwrj6nvll82cq0lra0riv8hr3-libssh2-1.8.0.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/7slh3201sgzm3czr7bv67j1fvkv929xg-nghttp2-1.32.0.drv': 7 dependencies couldn't be built
cannot build derivation '/nix/store/3hgark3b9md8vs9w72n3y9nxlg5xlqix-curl-7.61.1.drv': 8 dependencies couldn't be built
cannot build derivation '/nix/store/1gjyajh201677rqiaigqaz33h0rmgr79-source.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/v54k9lp53gsg2jkdslh8mxaqaik1qqha-lz4-1.8.3.drv': 3 dependencies couldn't be built
error: build of '/nix/store/v54k9lp53gsg2jkdslh8mxaqaik1qqha-lz4-1.8.3.drv' failed

Success on aarch64-linux (full log)
Attempted: lz4
Partial log (click to expand)
strip is /nix/store/p9akxn2sfy4wkhqdqa3li97pc6jaz3r1-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/zkv7knyzwv4y8aggm4qr8r3x8wvgfvxw-lz4-1.8.3/lib  /nix/store/zkv7knyzwv4y8aggm4qr8r3x8wvgfvxw-lz4-1.8.3/bin
patching script interpreter paths in /nix/store/zkv7knyzwv4y8aggm4qr8r3x8wvgfvxw-lz4-1.8.3
checking for references to /build in /nix/store/zkv7knyzwv4y8aggm4qr8r3x8wvgfvxw-lz4-1.8.3...
shrinking RPATHs of ELF executables and libraries in /nix/store/szcqi6g285h13iwynp1crhiq9xjf4zrq-lz4-1.8.3-dev
strip is /nix/store/p9akxn2sfy4wkhqdqa3li97pc6jaz3r1-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/szcqi6g285h13iwynp1crhiq9xjf4zrq-lz4-1.8.3-dev/lib
patching script interpreter paths in /nix/store/szcqi6g285h13iwynp1crhiq9xjf4zrq-lz4-1.8.3-dev
checking for references to /build in /nix/store/szcqi6g285h13iwynp1crhiq9xjf4zrq-lz4-1.8.3-dev...
/nix/store/zkv7knyzwv4y8aggm4qr8r3x8wvgfvxw-lz4-1.8.3

The release notes strongly recommends to backport this. so please also backport to staging-18.03

@dtzWill : nice dance :+1:

picked to staging-18.09: 1f1c8079b32


Are sub-routers or router-groups possible?

Like for instance the following:
subRouter := bone.New()
subRouter.GetFunc("/getNames", GetUserNamesControllerFunc)
subRouter.GetFunc("/getEmail", GetUserEmailControllerFunc)

router.Handle("/user", subRouter)

I would like this code to handle the /user/getNames and /user/getEmail urls but it does not work. Is this functionality supported?

No :/ But i will take a look at this, for instance you can do that:
subRouter.GetFunc("/user/getNames", GetUserNamesControllerFunc)
subRouter.GetFunc("/user/getEmail", GetUserEmailControllerFunc)

I know it's not exactly what you want, but until i found a way to implement your feature, it could be a simple workaround ...
And thanks for your contribution ! :)

It should work now, just check example 003 or in the changelog at the end of the README !
If you encounter any problemes let me know ! :)

Thank you for you very quick response, wow! Will try as soon as I can.


Error: Address somename@ could not be added to new cloud distribution group.  Manual addition required.

I just upgraded to version <IP_ADDRESS> and now I get the same error message for all migration jobs. This looks to me like some address parsing bug.
Anonymized Log snipped:
[23.02.2023 10:48:46] - A hybrid remote routing address was not present.  Adding hybrid remote routing address.
[23.02.2023 10:48:46] - Calculated hybrid remote routing address = some.name@
[23.02.2023 10:48:46] - Determine if the calcualted routing address is already in use.
[23.02.2023 10:48:46] - Calculated hybrid remote routing address is not present - continue.
[23.02.2023 10:48:46] - Error processing address: some.name@
Write-ErrorMessage : Cannot process argument transformation on parameter 'EmailAddresses'. Cannot convert value
"System.Collections.Generic.Dictionary`2[System.String,System.Object]" to type
"Microsoft.Exchange.Data.ProxyAddressCollection". Error: "The address 'some.name@' is invalid: The address
'some.name@' isn't a valid Unified Messaging address, so a prefix must be specified."
At C:\Users\s.fietzek\AppData\Local\Temp\tmpEXO_yeotnggm.l51\tmpEXO_yeotnggm.l51.psm1:1101 char:13
+             Write-ErrorMessage $ErrorObject
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Set-DistributionGroup], ParameterTransformationException
    + FullyQualifiedErrorId : [Server=DU0PR08MB7762,RequestId=e65f39dd-b4c2-c279-15b0-d3d60a6f680d,TimeStamp=Thu, 23 F
   eb 2023 09:48:46 GMT],Write-ErrorMessage

Name                      : Some Name
Alias                     : some.name
PrimarySMTPAddressorUPN<EMAIL_ADDRESS>ExternalDirectoryObjectID : 3eea8f1b-7746-4861-92bf-1a86b036e574
ErrorMessageDetail        : Cannot process argument transformation on parameter 'EmailAddresses'. Cannot convert value
                            "System.Collections.Generic.Dictionary`2[System.String,System.Object]" to type
                            "Microsoft.Exchange.Data.ProxyAddressCollection". Error: "The address 'some.name@' is
                            invalid: The address 'some.name@' isn't a valid Unified Messaging address, so a prefix
                            must be specified."
Attribute                 : Cloud Proxy Addresses
ErrorMessage              : Address some.name@ could not be added to new cloud distribution group.  Manual addition
                            required.

[23.02.2023 10:48:46] - Remove the SMTP Address added by creating the temporary DL.
[23.02.2023 10:48:46] - Removing<EMAIL_ADDRESS>[23.02.2023 10:48:46] - END SET-Office365DLMV

I can provide a full log directly but not in public.
Looking at the migrated distribution list, everything looks fine to me despite the error message.

Thank you for the snippet - I'm not sure why this is randomly failing when it's not failing in test cases.  I've reproing both success and failure.
I changed the logic for calculating the routing domain to account for a customized domain.  The variable for the customer domain was set to NULL and there is an IF statement that triggeres pulling the onmicrosoft.com domain.  This is skipped if the administrator specifies this.  For whatever reason this is working at times and not.
I changed the string initialization to just be a blank string "" and the if statement to test for this.  I'm now 100% in the stress tests.
Version .7 will go live here shortly that has this fixed.
Tim
==============================
Timothy J. McMichael
Senior Support Escalation Engineer
<EMAIL_ADDRESS>(980)-776-7465
Hours:  Sunday - Wednesday 08:00 - 16:00 eastern time zone.
Manager:  Tom Roughley<EMAIL_ADDRESS>Premier Support -<PHONE_NUMBER>
Broad Commercial Support -<PHONE_NUMBER>
==============================
From: TPok1707 @.>
Sent: Thursday, February 23, 2023 5:53 AM
To: timmcmic/DLConversionV2 @.>
Cc: Subscribed @.***>
Subject: [timmcmic/DLConversionV2] Error: Address somename@ could not be added to new cloud distribution group. Manual addition required. (Issue #125)
I just upgraded to version <IP_ADDRESS> and now I get the same error message for all migration jobs. This looks to me like some address parsing bug.
Anonymized Log snipped:
[23.02.2023 10:48:46] - A hybrid remote routing address was not present.  Adding hybrid remote routing address.
[23.02.2023 10:48:46] - Calculated hybrid remote routing address = some.name@
[23.02.2023 10:48:46] - Determine if the calcualted routing address is already in use.
[23.02.2023 10:48:46] - Calculated hybrid remote routing address is not present - continue.
[23.02.2023 10:48:46] - Error processing address: some.name@
Write-ErrorMessage : Cannot process argument transformation on parameter 'EmailAddresses'. Cannot convert value
"System.Collections.Generic.Dictionary`2[System.String,System.Object]" to type
"Microsoft.Exchange.Data.ProxyAddressCollection". Error: "The address 'some.name@' is invalid: The address
'some.name@' isn't a valid Unified Messaging address, so a prefix must be specified."
At C:\Users\s.fietzek\AppData\Local\Temp\tmpEXO_yeotnggm.l51\tmpEXO_yeotnggm.l51.psm1:1101 char:13

        Write-ErrorMessage $ErrorObject

        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo          : NotSpecified: (:) [Set-DistributionGroup], ParameterTransformationException

FullyQualifiedErrorId : [Server=DU0PR08MB7762,RequestId=e65f39dd-b4c2-c279-15b0-d3d60a6f680d,TimeStamp=Thu, 23 F

eb 2023 09:48:46 GMT],Write-ErrorMessage

Name                      : Some Name
Alias                     : some.name
PrimarySMTPAddressorUPN<EMAIL_ADDRESS>ExternalDirectoryObjectID : 3eea8f1b-7746-4861-92bf-1a86b036e574
ErrorMessageDetail        : Cannot process argument transformation on parameter 'EmailAddresses'. Cannot convert value
                        "System.Collections.Generic.Dictionary`2[System.String,System.Object]" to type

                        "Microsoft.Exchange.Data.ProxyAddressCollection". Error: "The address 'some.name@' is

                        invalid: The address 'some.name@' isn't a valid Unified Messaging address, so a prefix

                        must be specified."

Attribute                 : Cloud Proxy Addresses
ErrorMessage              : Address some.name@ could not be added to new cloud distribution group.  Manual addition
                        required.

[23.02.2023 10:48:46] - Remove the SMTP Address added by creating the temporary DL.
[23.02.2023 10:48:46] - Removing<EMAIL_ADDRESS>[23.02.2023 10:48:46] - END SET-Office365DLMV
I can provide a full log directly but not in public.
Looking at the migrated distribution list, everything looks fine to me despite the error message.

Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftimmcmic%2FDLConversionV2%2Fissues%2F125&data=05|01|timmcmic%40microsoft.com|32464c609ead4659694608db158c133b|72f988bf86f141af91ab2d7cd011db47|1|0|638127463587678845|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=Dkr2F%2BPzdSHQObxWwyEBT0mzT8z3elctdTKj2Vx5WY0%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAKGTN6K43U7ZP27IZSCRDDTWY46PJANCNFSM6AAAAAAVFO7FVQ&data=05|01|timmcmic%40microsoft.com|32464c609ead4659694608db158c133b|72f988bf86f141af91ab2d7cd011db47|1|0|638127463587678845|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=0cXFNvN7LsQ%2BUanM0ZWXdvH4kb4eS%2FvbDvFmEUKeuU4%3D&reserved=0.
You are receiving this because you are subscribed to this thread.Message ID<EMAIL_ADDRESS>

Confirming you should now see this resolved?

I got this to too, and it was Azure AD guests, I had to add them manually.

Azure AD guest accounts cannot be members of distribution lists unless it is a guest account synced from on premise.
Could you by chance provide logs or more specifics?
This issue was fixed already in the other case.
==============================
Timothy J. McMichael
Senior Support Escalation Engineer
<EMAIL_ADDRESS>(980)-776-7465
Hours:  Sunday - Wednesday 08:00 - 16:00 eastern time zone.
Manager:  Tom Roughley<EMAIL_ADDRESS>Premier Support -<PHONE_NUMBER>
Broad Commercial Support -<PHONE_NUMBER>
==============================
From: smtp25gmailcom @.>
Sent: Thursday, March 16, 2023 5:50 AM
To: timmcmic/DLConversionV2 @.>
Cc: Tim McMichael @.>; Comment @.>
Subject: Re: [timmcmic/DLConversionV2] Error: Address somename@ could not be added to new cloud distribution group. Manual addition required. (Issue #125)
I got this to too, and it was Azure AD guests, I had to add them manually.

Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftimmcmic%2FDLConversionV2%2Fissues%2F125%23issuecomment-1471627427&data=05|01|timmcmic%40microsoft.com|f050a8bc43d54d9348ad08db2603bf99|72f988bf86f141af91ab2d7cd011db47|1|0|638145569767507394|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=3F7xbdcMNog3W7JsBbH0Uhn8dsPgcgCif5R0vrjZxAo%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAKGTN6LO7NSMWROLK5CUIKDW4LO23ANCNFSM6AAAAAAVFO7FVQ&data=05|01|timmcmic%40microsoft.com|f050a8bc43d54d9348ad08db2603bf99|72f988bf86f141af91ab2d7cd011db47|1|0|638145569767663630|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=upptYifnN1TbC%2Fqada%2B2q8YeCRhfLLeDKvc%2BrxSYJxA%3D&reserved=0.
You are receiving this because you commented.Message ID<EMAIL_ADDRESS>


Generically expose URDF joint dynamics.

This is aimed at simulation use cases like #54 and #55, where simulation needs dictate different non-zero joint dynamics parameters.
In ur.urdf.xacro I provide an example loading the joint dynamics properties from a config file, but followed the treatment of initial_positions so that no config file is necessary to use the xacro:ur_robot macro in other contexts.
For the Gazebo Classic use case, I want to compute the dynamics parameters dynamically from other data, setting the joints' friction attributes to a multiple of the joints' effort limits like here.
(See discussion in #55 and Universal_Robots_ROS2_Gazebo_Simulation/#19 for context.)
In other user code including ur_macro.xacro I think this should not require any changes.

This should likely wait and build on top of #59 or equivalent.


Add method to get database infos

OK for the tests, but the test-db files don't provided these database informations. So checking with empty string would not be an appropriate test


Cannot install bionic legs in Warg

Bionic legs of any size are unable to be installed on warg.

Warg test.txt
Test save file (extension type changed because Github)

Good catch, seems I missed the bionic legs in the code. Should be fixed now!


[Bug] Images from local file paths not displaying correctly if contains special characters like % or #

Example filename that would not display correctly:
SHAUN%20OF%20THE%20DEAD%20Bloopers%20#t=18.jpg

After a short research it seems like it's only % and # characters that are causing issues because of how URLs are being encoded when browser is rendering HTML code. So far it seems like it's not possible to fix it in any way from IPyPlot module level.
Best effort would be just display a warning msg for each local image file URL containing either # or % characters.

One more option to consider would be to automatically convert local URLs with faulty characters to PIL.Image objects or something similar.


Github API returns "Problems parsing JSON" since v2.50.0

I'm making a POST request to https://api.github.com/repos/bartinger/grunt-github-release-asset/releases to create a release.
I used v2.47.0 before and everything worked fine, but when I upgraded to v2.51.0 and got 400 Problems parsing JSON even though the json was valid. I narrowed it down and found out that a change between v2.49.0 and v2.50.0 is causing this error.
I also enabled the debug mode and made a diff of the complete output, however both outputs where identical (besides dates and stuff).
Is this a bug in the package.
The code to reproduce the error is createRelease(...)

Which debug method did you use, NODE_DEBUG=request or request-debug?  Try request-debug if you haven't already.
That, or a standalone example that reproduces the problem, will be most helpful.

@simov I suspect this is related to #1309 and #1310.

With request.debug = true so (NODE_DEBUG=request). I'm going to try it with request-debug as well.

Here is the complete diff between v2.49.0(upper) and v2.51.0(lower). The Validation Failed error is expected. It seemes to me that the body is stringified twice in 51.
17c17
<         date: 'Fri, 23 Jan 2015 21:29:13 GMT',
---
>         date: 'Fri, 23 Jan 2015 21:27:23 GMT',
22c22
<         'x-ratelimit-remaining': '4954',
---
>         'x-ratelimit-remaining': '4960',
37c37
<         'x-github-request-id': 'B2BC6CCA:1D6A:58C506C:54C2BD29',
---
>         'x-github-request-id': 'B2BC6CCA:1D69:3D1E7A1:54C2BCBB',
40c40
<         'x-served-by': '2811da37fbdda4367181b328b22b2499' },
---
>         'x-served-by': '474556b853193c38f1b14328ce2d1b7d' },
53,54c53,55
<         'content-length': 53 },
<      body: '{"tag_name":"0.1.1","name":"Release 0.1.1","body":""}' } }
---
>         'content-type': 'application/json',
>         'content-length': 67 },
>      body: '"{\\"tag_name\\":\\"0.1.1\\",\\"name\\":\\"Release 0.1.1\\",\\"body\\":\\"\\"}"' } }
59c60
<         date: 'Fri, 23 Jan 2015 21:29:14 GMT',
---
>         date: 'Fri, 23 Jan 2015 21:27:24 GMT',
61,62c62,63
<         'content-length': '195',
<         status: '422 Unprocessable Entity',
---
>         'content-length': '89',
>         status: '400 Bad Request',
64c65
<         'x-ratelimit-remaining': '4953',
---
>         'x-ratelimit-remaining': '4959',
75c76
<         'x-github-request-id': 'B2BC6CCA:1675:B671514:54C2BD2A',
---
>         'x-github-request-id': 'B2BC6CCA:1D68:26F3BE3:54C2BCBB',
78c79
<      statusCode: 422,
---
>      statusCode: 400,
80,83c81,83
<       { message: 'Validation Failed',
<         errors: [Object],
<         documentation_url: 'https://developer.github.com/v3/repos/releases/#create-a-release' } } }
< Fatal error: Validation Failed(422)
---
>       { message: 'Problems parsing JSON',
>         documentation_url: 'https://developer.github.com/v3' } } }
> Fatal error: Problems parsing JSON(400)

Ah, I see.  Here's your fix:
## github.js
 Github.prototype._request = function (method, url, body, callback) {
 	return request({
 		method: method,
 		url: url,
 		headers: this.headers,
-		body: body ? JSON.stringify(body) : undefined,
+		body: body || undefined,
 		json: true,
 	}, callbackWrapper(callback));
 }

request will call JSON.stringify for you.  We used to only do this if body was an object, but now, we support sending primitive JSON values like strings.
(btw, GitHub supports diff syntax highlighting nicely, I edited your comment accordingly.)

@Bartinger you should not stringify the value of the body key if the application/x-www-form-urlencoded header value is not being set, can you try with passing the raw JSON object to the body key?
 I was assuming something like that. Passing the object to the body works. Thanks a lot for the quick help and the Github tip.


[v0.4.0-rc3] Stop resource save draft status error

Describe the bug

When update a stopped resource and save as draft. It status is still stop.
Steps to reproduce

Edit a stopped resource.
Save as draft

Uploading 录屏2023-11-24 17.54.24.mov…
Result

Resource status is stop.
Expected behavior

Resource status change to undeployed.
Environment

Walrus version: v0.4.0-rc3

Additional context
Add any other context about the problem here.

Why do we expect the status change to undeployed? It seems reasonable to be in stopped.

Stop seems more reasonable than undeployed in this senario.


feat(core): add 3D geometry primitives

Those are basic items for 3D, I haven't reexported those yet in the prelude module.

add Vector3 and related ops
add Vertex3 and related ops
add tests
move 2D objects into a dedicated geometry submodules

Scope

[x] Code: if relevant, add affected target

Type of change

[x] New feature(s)

Codecov Report
Attention: Patch coverage is 73.15175% with 69 lines in your changes missing coverage. Please review.

Project coverage is 81.50%. Comparing base (798c5e8) to head (5fb7261).

Files with missing lines
Patch %
Lines

honeycomb-core/src/geometry/dim3/vertex.rs
45.31%
35 Missing :warning:

honeycomb-core/src/geometry/dim3/vector.rs
58.75%
33 Missing :warning:

honeycomb-core/src/geometry/dim3/tests.rs
99.11%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #181      +/-   ##
==========================================
- Coverage   81.97%   81.50%   -0.48%
==========================================
  Files          32       35       +3
  Lines        4538     4795     +257
==========================================
+ Hits         3720     3908     +188
- Misses        818      887      +69

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

I'll address all issues regarding comparison in another PR since it will also apply to Vertex2. Other stuff I'll add to this PR.

Do you think that a conversion from Vertex2 to Vertex3 should be useful?

Yes, I'll add it. It will be required if we implement CMap2 to CMap3 conversion later.


WebGL and RGBA32F Texture format

Hi,
I had already created an issue on this subject ( [https://github.com/bkaradzic/bgfx/issues/592] ) which becomes old and was left unresolved in depth.
After some more investigations, i am now convinced that there is an issue in bgfx.
The first thing is that creating a float texture in raw JS/WebGL as below works on both last Chrome and FireFox which both have OES_texture_float extensions.
        var data = new Float32Array([
            0.5, 0., 0., 1.
            , 0., 1., 0., 1.
            , 0., 0., 1., 1.
            , 1., 1., 0., 1.
        ]);

        gl.bindTexture(gl.TEXTURE_2D, neheTexture);
        gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 2, 2, 0, gl.RGBA, gl.FLOAT, data);
        gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, gl.NEAREST);
        gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.NEAREST);
        gl.bindTexture(gl.TEXTURE_2D, null);

Second point, according to Emscripten documentation, when using EGL API to create GL context, all available and non-performance impacting extension are enabled automatically.
This point out that we should be able to create float texture using emscripten.
Third point, i have checked the test done by bgfx to determine whether the GL_RGBA32F is supported, which seems to be incorrect.
s_textureFormat[TextureFormat::RGBA32F] contains :

internal format : 0x8814, which is not present neither in OpenGLES 2.0 nor in WebGL 1.0 specs. This value is defined by bgfx here.

format : 0x1908 corresponding to GL_RGBA, OK

type : 0x1406 corresponding to GL_FLOAT OK

The expected internal format is also GL_RGBA to check correctly GL_RGBA32F texture format support.
Therefore bgfx::Caps says that GL_RGBA32F is not supported, only emulated.
This constrat with GL_RGBA16F which is flagged as supported, we have format == internal format in texture format support test.
Any hint ?
Regards,
Harold

I just noticed something with Chrome that loses me :

If BGFX_CONFIG_DEBUG=1, RGBA16F texture format is flagged as supported
Without BGFX_CONFIG_DEBUG=1, RGBA16F texture format is only flagged as emulated

My use case is to load environement map as RGBA16F texture and the env map appears only in case of supported texture format.

Why does BGFX_CONFIG_DEBUG flag make difference about texture format support ?
What is the meaning of emulated texture format ?

Thanks,
Harold

What is the meaning of emulated texture format ?

It means it will be converted to some other supported format in runtime.

internal format : 0x8814, which is not present neither in OpenGLES 2.0 nor in WebGL 1.0 specs.

Can you add the same line:
https://github.com/bkaradzic/bgfx/blob/master/src/renderer_gl.cpp#L1624
for RGBA32F next to it?

Fixed detection: https://github.com/bkaradzic/bgfx/commit/7749b745f798ccb2969fbb9223e6d1c24535d635

Hello,
The correct line is
setTextureFormat(TextureFormat::RGBA32F, GL_RGBA, GL_RGBA, GL_FLOAT);
You added
setTextureFormat(TextureFormat::RGBA32F, GL_RGBA, GL_RGBA, GL_HALF_FLOAT);
I just tested and RGBA32F texture format is now supported on both Chrome and FireFox. :)
There is still the issue with Chrome described above :

With BGFX_CONFIG_DEBUG=1, RGBA32F and RGBA16F are supported
Without, both format are not supported, only emulated and does not work correctly

This happens only with Chrome, both texture format are supported on FireFox independently to BGFX_CONFIG_DEBUG=1 flag presence.
Regards,
Harold

I enabled debug output in release build and it seems correct:
../../../src/bgfx.cpp (1167): BGFX 	[x x x   f  M] RGBA32F
Change this line to #if 1:
https://github.com/bkaradzic/bgfx/blob/master/src/bgfx_p.h#L15

Sadly, i performed same test and i still have
[bgfx.cpp,1167] BGFX 	[* * *      M] RGBA32F

:(
I am under window 7 pro SP1 64 bits, using Chrome 52.0.2743.116 m (64-bit) which seems to be latest version.
I will dig to find out the line activated by BGFX_CONFIG_DEBUG flag that makes things working.

Ok, i found it !
https://github.com/bkaradzic/bgfx/blob/master/src/renderer_gl.h#L994
Replacing BGFX_CONFIG_DEBUG by 1 only here fixe the issue :
bgfx.cpp,1167] BGFX 	[x x x   f  M] RGBA32F

It should be something like error code consumed by a call to glGetError when GL_CHECK is called.
Therefore the texture format support test does not grab the error and consider that the format is supported.
But strangely, my float texture is well loaded and used as env map.
Any insight ?

The above analysis seems only partialy good :

Without GL_CHECK enabled and only with chrome i get an INVALID_VALUE error after glTexImage2D call done here : https://github.com/bkaradzic/bgfx/blob/master/src/renderer_gl.cpp#L1163
There is no GL_CHECK into initTestTexture, so error code cannot be consumed by it
With GL_CHECK enabled, i do not have the INVALID_VALUE

Strange thing : Changing this line by below line make no more INVALID_VALUE error emitted.
GLenum err = glGetError();

Now, i am lost :)
Regards,
Harold

Ah I get it... Lame GL... glGetError is FIFO, not current state. So it's popping some error from before.

Sadly,
GLenum err = glGetError();

return GL_NO_ERROR.
And according to spec :
Thus, glGetError should always be called in a loop, until it returns GL_NO_ERROR, if all error flags are to be reset.

it does not seem to have stacked old error.

Well, i did not found the solution ... :(
I can not spend more time on this issue. so i will stick to the "add glGetError()" workaround until a real fix.
I guess you are not working on Windows ? If you need some help to test something on Windows, tell me.
Regards,
Harold

Hello,
I see that you have integrated a flushGlError(); at beginning of initTestTexture().
It fixes the problem so i can close this issue.
Thanks :)


Added tr-TR language.

I just added the Turkish lang to klasa.

I'll also translate docs if @MrJacz's pull request about tutorials merged. I think we'll need a community for Turkey.


Users tab - additional column

On the users tab, an additional column that shows which users some of the significant sys admin permissions (when users have multiple permission sets assigned), this column will help identify where something has been provisioned in error. I can see the Key permissions column, but don't think it currently flags that the user has access to export all data.

At this time we are checking the following permissions: apiEnabled, viewSetup, modifyAllData, viewAllData.
i know there was a bug about this info but can't find the issue in the tracker.

When testing 1.9 current in beta I have the following screen on User tab, will it be ok for you??

For some reason in the current version that you have permission are always empty! this will be fixed in 1.9!

Yeah, i thought it was my sandbox so i had to refresh/logout login to see the permissions.
Additional permissions to check could be:

Export Reports
Manage Connected Apps
Manage Multi-Factor Authentication in User Interface
Manage Package Licenses
Manage Release Updates
Modify Metadata Through Metadata API Functions
Weekly Data Export

All of these permissions under Manage users  are deemed high risk for orgs under SOX scope (compliance) where these permissions are usually limited to specific users only.


box shadow added on back to top only on hovering

Closes
Closes #1634

Description

Screenshots
https://github.com/OSCode-Community/OSCodeCommunitySite/assets/119532943/10e7b8c7-bff9-4100-bc11-f91935ceba70

Note to reviewers

Checklist:

[x] I have linked the PR to the correct issue.
[x] I have read the Contribution Guidelines
[x] I have built and tested the changes, and they do not break or show any errors.

@Divesh2003 ..


Added Xoken Labs

Can you tell me a little about what you use Haskell for?

We are developing a new permission-less blockchain using Haskell. Includes
P2P protocols, DHTs, Consensus protocols, Nodes etc.
Yes we do offer remote positions! Thanks
+91 99723 11255
www.xoken.org
On Thu, Mar 8, 2018 at 12:02 PM, Erik Mossberg<EMAIL_ADDRESS>wrote:

Can you tell me a little about what you use Haskell for?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/erkmos/haskell-companies/pull/51#issuecomment-371393767,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ah8KtqxolGjQRJBICi2wIW2Tq87As2inks5tcNCDgaJpZM4SiNH9
.

Thanks, I will use this PR as the source