allow customization of the output of panic!() to stderr with 'panic handlers'

Rendered
EDIT: heavily modified since first commits!

Related: https://github.com/rust-lang/rfcs/issues/1089
I’m strongly in favour of this. Here’s a few more motivational points:

Makes Erlang-style just-fail tasks more possible;
Silent panic!() needs not to emit code for lines, messages and whatnot reducing the size of panic!() by a considerable amount;
Fixes https://github.com/rust-lang/rust/issues/24099, in a sense.

It should be noted, that state of (silent) panic is not entirely undetectable: join on thread returns Err side of Result and main thread exits the process with a certain error code.

This sounds great to me.

This doesn't need to be implemented as another rule to panic!() since the macro is already marked as stable. It can be implemented as an unstable function in std::rt::unwind, where it would have considerably less inertia against it.

Why change the behavior of plain panic!()?
Panics can carry arbitrary values so in libstd style I guess we could have a PanicBuilder::new().silent(true).message("just giving up").panic() - type API. Only half in jest! Since panics can carry non-string objects that can be a nice way to carry the options to the place it is caught.
I'm not sure how feasible this is to implement, but as you know the panic value is wrapped in Box<Any + Send> when carried, so the handler can extract a specific panic options value by downcasting.

FWIW, I don't think making this change should be considered a violation of stability. It wouldn't affect the API, so there's no backwards-compatibility issues as far as compilation goes, and I'm finding it hard to imagine how turning off a message printed to stderr on task panic would break anybody.
That said, I'd still prefer to have to opt-in to silent panics. The idea of passing a panic configuration value to panic!() is clever, but also seems like a weird thing to expose. I'd rather just have something like panic_silent!() (which could internally panic with a value of a known type which is tested for in std::panicking::on_panic()).

@kballard It breaks the invariant that panic!() always prints an error message. We can't assume that people aren't relying on panic!() to print an error message even when not passed any arguments.

@cybergeek94 Printing a message to stderr is not part of the documentation for panic!(). So it's not something we guarantee, it's just something that we happen to do today.

So having panic!() at the top level of your code would just end your program with no message whatsoever? I'm not a fan of that idea, it seems like a huge gotcha to cause the behavior of this macro to change so fundamentally depending on the lack of arguments. I would prefer a separate macro if this behavior is desired.

One more thing: even though we consciously and infamously support "catching" unwinding, that doesn't mean we should be encouraging that use as a normal error-handling solution. A panic at runtime indicates a problem, and if you're really panicking so often that you're clogging up your logfiles then I need to ask what your architecture is like that you feel the need to resort to that approach.

@kballard Panicking with a known value for panic_silent! is of course ok. I wanted to point out that panicking with values is already exposed, you can pass an arbitrary value to panic!(...) which is by design.

Instead of having panic_silent!(), might it make sense to have panic!(panic::silent) or something? Basically add a value that isn't currently accepted to panic!().

Could changing the output of plain panic!() break compiletest? AFAIK it captures stdout/stderr.
FWIW, I think panic!() should always print a message in debug builds, it could be silenced by default in release builds, and an explicit panic_silently!() (yeah, I would write that out, because it should be uncommon) could be added.
This way we don't lose debugging information on panics, and we can have tight code in release builds.

I think there is a related problem which makes panic not very useful for messaging failure and that there is nothing it can carry.  It's very hard for a panic handler to figure out why exactly something panicked.  You can't even set an integer to signal something upwards.
I think there is more that needs doing than just removing an error message.

This doesn't need to be implemented as another rule to panic!() since the macro is already marked as stable.

Why change the behavior of plain panic!()?

Printing a message to stderr is not part of the documentation for panic!(). So it's not something we guarantee, it's just something that we happen to do today.

FWIW, I think panic!() should always print a message in debug builds, it could be silenced by default in release builds, and an explicit panic_silently!() (yeah, I would write that out, because it should be uncommon) could be added.

This way we don't lose debugging information on panics, and we can have tight code in release builds.

@bluss is right, the logging lies in std::panicking::on_panic(). It would be easier than I expected to remove logging.
From what has been brought up, I think the best solution is as follow:

Allow replacing the default panic handler instead of simply adding new handlers to it
Add a few off-the-shelf panic handlers to be registered:

debug (the current default) - output the thread name, line number, file name and panic message
release - output the panic message only
silent - do not output anything

By default, debug would be used in debug builds and release in release builds. silent would have to be explicitly used.

Here's how it would be used:
use std::thread;

fn main() {
    thread::spawn(|| {
        // use the default panic handler, `debug`, the one we currently have

        some_optional.unwrap();
    }).join();

    thread::spawn(|| {
        // Always use the `silent` handler
        thread::on_panic(thread::handlers::silent);

        // This will never display a message

        // Use cases:
        // - abort thread silently on errors unrecoverable at its level,
        //   but recoverable at the process level, and spawn a new one
        a_third_party_function_that_could_fail();
    }).join();

    thread::spawn(|| {
        // Always use the `basic` handler
        thread::on_panic(thread::handlers::basic);

        // This will simply display whatever is passed to `panic!` on panic,
        // much like println!()

        // Use cases:
        // - abort thread on invalid input with a user-friendly message
        if !is_valid(input) {
            panic!("Invalid input - please try again");
        } else {
            // ...
        }

    }).join();

}

This would undoubtedly offer the most flexibility, without breaking backward compatiblity.
To have debug messages on debug builds and bare-bones messages on release builds, users could simply do this:
thread::on_panic(
	if cfg!(debug) {
		thread::handlers::debug
	} else {
		thread::handlers::basic
	}
);

Or this could be the default, but I'm not sure rustc supports debug flags, or whether this would be desirable.
What do you think?
PS: I'm not familiar with the RFC process - should I update the RFC to integrate these changes, even if it implies changing the feature name from silent_panic to panic_handlers or something like that?

Panics can carry arbitrary values

Or carry none. panic!() carries "explicit panic" even though it wasn’t asked to/was asked to not carry anything.

I'm not sure how feasible this is to implement, but as you know the panic value is wrapped in Box<Any + Send> when carried, so the handler can extract a specific panic options value by downcasting.

Changing that to Box<Option<Any + Send>> is a possiblity, I guess.

Allow replacing the default panic handler instead of simply adding new handlers to it

You already can replace panic handler to your own by not using libstd and providing your own panic_fmt language item.

I'm not familiar with the RFC process - should I update the RFC to integrate these changes, even if it implies changing the feature name from silent_panic to panic_handlers or something like that?

Its your RFC, you may change it anytime until it is accepted. Just note what changes you made and keep commit history.

@nagisa

You already can replace panic handler to your own by not using libstd and providing your own panic_fmt language item.

This is arguably not handy for something as simple as changing what is output to stderr.

Its your RFC, you may change it anytime until it is accepted. Just note what changes you made and keep commit history.

Glad to know that! I'm working on the second iteration.

From both implementation complexity and API standpoint I, personally, prefer original suggestion.

It surely is simpler, but it's less customizable and flexible. I believe panic!() deserves more.

I heavily modified the RFC in the last commit.

+1

+1, although there are a few things that need clarifying:

What's the signature of "on_panic" - presumably it only allows a 'static callback?
How does this interact with scoped threads: if the handler returns false, does the parent thread still panic?
How are handlers chained together, repeated calls to "on_panic"?
How does this interact with "catch_panic"?
What is the panic handler allowed to do? Is it safe for it to be a completely custom implementation, or is it possible for handlers to violate memory safety by doing the wrong thing?
If I wanted to set up a channel to send panic information back to the thread which spawned this one, how would that be done?

-1. What bstrie said on encouraging use of panic. Catching panics should only be done for esoteric FFI reasons.

@Ericson2314 And yet we are currently allowing panic catching. The standard library accounts for panics (think mutex poisoning). A lot of library functions can and do panic. If we are to drop support for clean panicking, we should drop support for panic! itself in release builds, right?
Unwinding a thread's stack and running destructors has uses, even though I would often prefer a Result-based solution. And as I said, since you cannot prevent exceptional panics in third-party functions, you should be able to handle them properly.
@Diggsey I doubt I'm qualified enough, but your questions alone shed light on potential problems, so it would probably better to leave refactoring of the handler mechanism (which already exists, although it's unstable) for a later RFC, and change this one to a simple mode selection, which changes the behavior of the  on_panic handler depending on the current panic! logging mode.
I'll update the RFC, thanks for your comments.

@Ericson2314: Rust aims to be a lot for a lot of people with very diverse needs. We are not going to break the current uses of panic/catching (for example compiletest, which a lot of things already depend on).
So we may as well make it more flexible so that people like you can have minimal silent panics, and people like me can enjoy all the information they get when their programs crash. Win-Win!

@alexcrichton: Not exactly the same, but Java allows to register any number of atExit() handlers, which are run when only active daemon threads remain.

Thanks for the RFC @filsmick! I personally prefer the "add a handler" approach than the "special case 0 arguments" approach.
Could you also expand the detailed design section a little more? In theory an RFC should be able to be implemented just by referencing its text, but currently there's a lot of open questions in the implementation section which I think would benefit from writing down signatures of functions, constants, statics, etc, as well as the rustdoc documentation that will go with them.

@alexcrichton I was not sure adding a handler would be the best idea because, well, I'd need to write an implementation to fix the caveats with the design and provide function signatures that work, and I'm not sure I can do that, as a lot of code in rt::unwind is unsafe, and I'm not really comfortable working with unsafe code.
Additionally, I didn't think this was necessary until now; I will get on it as soon as possible. It's certainly better to use customizable handlers, if they are safe.

@alexcrichton I was not sure adding a handler would be the best idea because, well, I'd need to write an implementation to fix the caveats with the design and provide function signatures that work, and I'm not sure I can do that, as a lot of code in rt::unwind is unsafe, and I'm not really comfortable working with unsafe code.

That's ok! These kinds of details can often have a big impact on the detailed design of the RFC, however, so it's much better to weed them out sooner rather than later. I'd be willing to help out with any questions if you have them! (I'm acrichto on IRC).

Additionally, I didn't think this was necessary until now; I will get on it as soon as possible. It's better to use customizable handlers, if they are safe.

I don't believe that there's any fundamental unsafety here. The spec will likely have that a panicking on_panic handler will abort the process, which will alleviate most worries. For example, here's how I would handle @Diggsey's questions:

What's the signature of "on_panic" - presumably it only allows a 'static callback?

Yes, 'static and also Send + Sync if it's not thread-local.

How does this interact with scoped threads: if the handler returns false, does the parent thread still panic?

While an open question, I would expect no interaction with scoped threads at all (e.g. handlers are totally thread local). This very much depends on the outcome of the RFC though, and could be considered a drawback either way!

How does this interact with "catch_panic"?

I don't think that this feature does really that much, it just means that whenever a panic is initiated these handlers will run. The catch_panic function is worried about the other side, preventing the panic from aborting the process if uncaught.

What is the panic handler allowed to do? Is it safe for it to be a completely custom implementation, or is it possible for handlers to violate memory safety by doing the wrong thing?

I would expect anything to be safe, but panicking would abort the process. Do you have any specific concerns in mind @Diggsey?

If I wanted to set up a channel to send panic information back to the thread which spawned this one, how would that be done?

I would personally love to see a FnMut trait bound instead of a function pointer argument, which would allow capturing data, but otherwise one could set up thread-local-storage for an endpoint of the channel.

@alexcrichton Those seem like very sane answers - I didn't have any specific concerns other than the RFC being somewhat vague, and not being quite sure what was necessary to maintain safety in the event of a panic, although now I realise that since unwinding happens only after the handlers have run, there shouldn't really be any problems.

@Diggsey ok cool, I think the other key part is the 'static bound on the handler (if it can capture data), but with those we should be good to go!

@filsmick

The standard library accounts for panics (mutex poisoning comes to my mind).

Things like mutex poisoning exist not because the panic is expected to be caught, but because values can and are shared among multiple threads. Panicking a thread does not take down the whole process, which means any mechanism of data sharing (Mutexes, channels, etc) needs to be tolerant of panics. In the case of Mutexes, because it's expected that most values that one might put into a Mutex won't have been written to be tolerant of panics (as values typically become inaccessible after a panic if they're not shared between multiple threads), poisoning is used to prevent the other threads from accessing potentially invalid data.
Which is to say, the existence of standard library constructs that gracefully handle panicking does not indicate that end-user code is expected to catch panics, it just means that end-user code is expected to be able to safely share data between multiple threads.

@kballard I think this PR is not about catching panics - it's about being able to customise the behaviour when one occurs. The original motivation was to be able to avoid printing out an error message including line numbers to the end user, but other uses including logging the panic, or notifying the user a different way that something went wrong. This PR does not introduce any new ways to catch a panic, or even make any existing ways easier.

@Diggsey This PR is about altering the behavior of panics. The original motivation was actually to silence the panic altogether; the RFC has been completely rewritten since then to allow for other behaviors.

This PR does not introduce any new ways to catch a panic, or even make any existing ways easier.

This PR is all about making it easier to use panicking as a control flow mechanism. The original goal was to be able to write panic!() to abort a worker thread early without having to thread error-handling code through it all. I was responding to a comment that was making the argument that the existence of stdlib code that handles panics is evidence that panics are expected to be handled in a "clean" fashion, which I'm taking to mean that panicking should be usable as a control-flow mechanism (rather than something that only happens in exceptional cases).

@filsmick @llogiq My understanding is panics always indicate bugs, and the only reason we support catching is because unwinding into foreign code is undefined behavior -- for example without catching a panic in rust callback might not kill the current thread. Because a panic is a bug, I think trying to make panics "pretty" is well missing the point -- debug your damn program!
Hiding the line number and file name on release builds may be justifiable, haven't thought through all the ramifications of that.

My understanding of panics is that while they should not be used for fine-grained error handling, it would be perfectly reasonable to use panics at a thread level, to eg. terminate a worker thread early. That's one of the reasons why "thread::spawn" doesn't propagate the panic into the calling thread.

debug your [the hypothetical developer, not you two] damn program!
Even if you restrict panics to only those cases which represent a bug, it's unreasonable to expect ALL possible bugs to have been removed. It should be possible (and recommended) to have code in place to allow the bug to be reported and reproduced, perhaps even automatically.

My understanding of panics is that while they should not be used for fine-grained error handling, it would be perfectly reasonable to use panics at a thread level, to eg. terminate a worker thread early. That's one of the reasons why "thread::spawn" doesn't propagate the panic into the calling thread.

As I see it, one would benefit in that an unrecoverable error in a worker thread need not take down the entire program, but one shouldn't purposely through a panic just to kill the worker thread early, as panics are only for unrecoverable errors, and this is intended behavior.

Even if you restrict panics to only those cases which represent a bug, it's unreasonable to expect ALL possible bugs to have been removed. It should be possible (and recommended) to have code in place to allow the bug to be reported and reproduced, perhaps even automatically.

I suppose a single, top-level catch to do this in a client-facing desktop is perhaps the least evil of non-orthodox uses of exception catching. But such a desktop program will link foreign code, and is thus prone to segfaults and their ilk, so a separate monitor process is a more robust way to report all errors. If we're assuming rust-bugs exist, we might as well foreign/ffi bugs exist too.

@kballard, @Ericson2314 I can understand your fears of panic-misuse. But if we hobble panic handling because of this fears, we will hurt those who wish to use it to good effect.
I think the RFC should start from the most outrageously powerful design and explore what we can take away without unduly restricting its usefulness. Don't restrict your thinking to code running in production. This code must somehow be produced, debugged, etc., so anything that can help these activities should be regarded as a valid use case.
For example, I can see a good use for both per-thread panic handlers and a global catch-all panic handler. If we'd allow both, the global handler could even handle panics in a thread-panic handler. The use case is a developer may want to take drastic measures if the global handler is invoked (e.g. crash and restart an application), but may not care about certain threads that only perform ancillary tasks.
On the other hand, I don't think that handler chaining will carry its weight, because it's probably simple enough to build on top of a single handler that does the publish-subscribe-tango, and because I don't see many cases where chaining would be useful (if anyone comes up with one, I'll be interested to hear it).

Given that there are plans to allow toggling "panic => abort" with a compile time flag, I am not a fan of mechanisms that make it easy to determine the difference between the two (which any catch mechanism assuredly does).
But I also don't exactly see how this RFC is about that; it's about making sure that the error that is logged doesn't have to go through stderr.  As an example of where this matters, I had to write elaborate, brittle stderr redirect logic for rustbox in order to make sure the panic even showed up (because all the stderr output will disappear when the Rustbox destructor is run).  This RFC (as far as I can tell) would let me deal with this in a much saner way (for example, creating Rustbox could register a global handler with a reference to a log string behind a static mutex, and output could be delayed until the Rustbox destructor ran).

:+1:, this should help with panic! debugging, one could core-dump (https://code.google.com/p/google-coredumper/), generate a better backtrace, abort spectacularly or do any number of other useful things.

The thread::on_panic(thread::handlers::basic); function looks like a singleton to me.
What if two pieces of code both call thread::on_panic without knowing that they conflict with each other? I can see two solutions: either the function returns the previous handler, or the current thread's panic handler can only be modified once. Both solutions are complete non-sense.
Instead, for me the panic handler should be decided when building the thread, for example by adding a method to the thread::Builder. It shouldn't be possible to modify it once the thread has spawned.

What do you do about the main thread, then?

I'm not sure I understand.
At one place, the RFC says:

This RFC proposes to allow control over what happens beside unwinding when a thread panic by changing the panic handler of this thread, instead of simply adding new ones with rt::unwind::register.

But below it says:

Handlers that simply add a layer of logging return true to execute the next one in the list, and 'overriding' handlers return false to stop there.
Handlers are called in reverse order of registration (first registered, last called), to place the 'most important' ones (usually one of thread::handlers) at the top.

So do you change the panic handler or do you have a stack of handlers?

@tomaka I don't think allowing to change the panic handler mid-thread is non-sense. Other languages deal with this problem in a similar manner, e.g. C has setjmp and kill/sigaction (at least on POSIX), Java has Thread#setUncaughtExceptionHandler(…).
Also, it's useful: Imagine that you have a task that has multiple phases (for the sake of the argument, let's take two). The first phase is very important and you absolutely want to handle panics of this phase in the application. The second phase is just a nice-to-have thing that you don't really care about.
Would you like to split the task into two threads just to install a different panic handler? Or would you create a flag that tells the panic handler to behave this or that way? Both solutions look cumbersome. Allowing the thread to say: "Ok, I'm done with the important stuff, from now on just kill me if I panic" makes the code much simpler.
I agree that there's potential for abusing this to trip other developers. But I think the benefits outweigh this cost.

Just because other languages do it doesn't mean it makes sense.
Given your example, it would make sense to have something that looks like this:
thread::with_panick_handler(callback, || {
    phase1();
});

phase2();

Instead of this, which looks cumbersome to me:
thread::set_error_handler(callback1);
phase1();
thread::set_error_handler(callback2);
phase2();

@tomaka Agreed, your first snippet looks better, even if it's a bit closure-happy. :smile:
I usually forget that other languages' APIs did not enjoy the functional goodies that we have. Apart from the 'panick' (typo?), I'm very much in favor of such an API.

@tomaka

I'm not sure I understand.

The RFC changed a few times, sorry for this - what I meant is that currently, you can add panic handlers but not suppress the behavior of the default one. With a boolean return deciding to continue or not the execution, it is possible to effectively override the default handler and any others if needed.
Currently, the solution is cumbersome, and I'm looking for ways to improve it.
@llogiq

On the other hand, I don't think that handler chaining will carry its weight, because it's probably simple enough to build on top of a single handler that does the publish-subscribe-tango, and because I don't see many cases where chaining would be useful (if anyone comes up with one, I'll be interested to hear it).

One way would most concerns:

Use an environment variable to change the behavior of panic process-wide (if only one mode is ever needed in the program, use that - we use environment variables such as RUST_LOG already, and they are overridable from inside the program)
Allow customization of panic inside a thread. Why inside and not when it's created? Because libraries like thread pool or multithreaded web frameworks hide the creation of the thread, and it should be possible to change the handler without editing their source code or requiring them to expose the handler. Plus, what @llogiq said about phases of a task.
There is only one panic handler instead of a chain; no memory leaks by adding too many at once. If one wants to call other handlers, they have to call them from inside theirs. This is entirely based on the assumption that chained handlers ( what we currently have are rarely necessary in actual code. Since there is only one handler, there is no return value.
I'm not sure about the signature of the register function. Wouldn't FnMut with a 'static bound work?

What do you think about this?
@alexcrichton:

This may changed based on the outcome of the RFC, but this is a good bit of API surface area to be adding for this feature, and it may be nice to trim it down a bit. For example with a closure-based approach the silent handler is just |_, _, _| true, and it's not clear to me that basic needs to be built-in. We may even be able to get by without exposing the default debug handler to start out as well.

Exposing such common handlers makes code using them self-documenting. Would you prefer this:
// Silence panic messages
thread::on_panic(|_, _, _|);

or this:
thread::on_panic(thread::panic_handlers::silent);

In general I would also like to see a very detailed description as to how exactly these signatures will look like. A sample implementation would be perfect, but this needs to be more detailed moreso than just "these names will be added to the module"

I'll get on that as soon as the API proposal is polished enough - it's changing a lot at the moment, thanks to the feedback of all the contributors!

@filsmick

Use an environment variable to change the behavior of panic process-wide (if only one mode is ever needed in the program, use that - we use environment variables such as RUST_LOG already, and they are overridable from inside the program)

I'm not sure if I'd like to have this as an env setting. It doesn't seem too useful and we usually have different target binaries for dev and release anyway, so using a compile-time config would suffice (I also worry if in any security-sensitive application an attacker could trip our programs by supplying bad data to the environment).
As I said, I quite like @tomaka 's suggestion. The closure clearly scopes the panic handler, making it impossible to forget to un-register it. The default handler |_, _, _| {} would then be implicit outside of any with_panic_handler scope, so we won't need to add one to the API.
Maybe we could even have threads inherit their creators' panic handlers which would mean that any thread created within a with_panic_handler scope would get the preset handler, thus removing the need for a distinction between a global and thread-local handler. Then again, this could open up concurrency problems, as a handler would now run within a thread and all threads it creates within its scope. I'm not sure if the API simplification is worth the hassle.

@llogiq

I'm not sure if I'd like to have this as an env setting.

A compile-time flag would be very nice, indeed. How would you go about implementing this, though? The flag would be set when compiling Rust itself, not the target program, right?

As I said, I quite like @tomaka 's suggestion. The closure clearly scopes the panic handler, making it impossible to forget to un-register it.

The problem with exposing handlers only when creating threads is that you can't change the handler from inside a thread spawned by a library. This is a big problem.

Maybe we could even have threads inherit their creators' panic handlers which would mean that any thread created within a with_panic_handler scope would get the preset handler, thus removing the need for a distinction between a global and thread-local handler. Then again, this could open up concurrency problems, as a handler would now run within a thread and all threads it creates within its scope. I'm not sure if the API simplification is worth the hassle.

Having a global variable / config flag which is used as the handler unless specified otherwise would probably do?

@filsmick

The flag would be set when compiling Rust itself, not the target program, right?

Wrong. It would just be another #cfg variable that is set on compiling the program. Perhaps we could even reuse an existing one.

The problem with exposing handlers only when creating threads is that you can't change the handler from inside a thread spawned by a library. This is a big problem.

I think you misread @tomaka 's suggestion, this is not about exposing handlers when creating threads, but allowing a scoped API within a thread. The thread::with_panic_handler(handler, || { … }) call would actually be inside of the thread that wants to use the handler. And the closure makes the scope of the handler explicit, which is nicer than having
thread::handle_panics_with(myHandler);
// scope of myHandler here
thread::handle_panics_with(defaultHandler);
// bad: need a defaultHandler here just for going back.

We should also think about what happens if thread::with_panic_handler calls are nested.

@llogiq I did misread his suggestion, see my edit above. This is actually a clean solution

Wrong. It would just be another #cfg variable that is set on compiling the program. Perhaps we could even reuse an existing one.

A cfg inside the standard library couldn't hold a function / closure object, though. This would require using a global, with a safe API to access it (thread::set_default_panic_handler?).

Ok, @filsmick, I probably wrote too complicated.
There is only one panic handler, which does nothing. On debug build (or given a reasonable cfg variable like debug_panic), we extend the _start function to run main with a panic handler that prints extensive debugging information instead of just running main.
Again, we have two open questions:

Are panic handlers inherited from threads? Do we care if they are called from multiple threads?
What happens when we nest with_panic_handler invocations? What happens to the panic handlers of threads started within the panic handler's scope?

I'm currently leaning in the direction of "have panic handlers be thread-safe, have with_panic_handler(…) restore the previous handler for this thread only, while threads started from within its scope keep the handler". This would make the API very simple, as there's only one function and one panic handler signature.

I like llogiq's approach: however instead of requiring handlers to be thread-safe, we could require a bound of Copy + Send, and new threads would get a copy of the parent thread's panic handler.

Yeah, that would work, too. Plus, it allows specialized cloning for more complex handlers, while simple ones will likely be Copy anyway.

@filsmick
I'd probably prefer the empty-closure of the two of those suggestions you made as it avoids having to add silent as a name, although this may also depend on the exact outcome of the API as others have been discussing.

@Diggsey, @llogiq

I like llogiq's approach: however instead of requiring handlers to be thread-safe, we could require a bound of Clone + Send, and new threads would get a copy of the parent thread's panic handler.

The unfortunate part about having a global handler is that it needs to be deallocated at some point (or at some point unset). The deallocation may not be so much of a problem if this ends up with a scoped-like API, but the "un-set" stage can be difficult depending on whether Clone or Sync is used. I'd personally recommend against Clone as it would be quite nice to use arbitrary closures for these kinds of handlers, but unfortunately none of those are Clone.
We've definitely had desires for "inheriting state" among spawned threads in the past, especially with relation to I/O handles of child threads. We haven't currently explored the space, but I can see where it would be quite nice here! There are synchronization and such worries we'd have to work out, but that also depends on the precise API :)

@alexcrichton I'm not sure what you mean about deallocation/unsetting. With a scoped-like API, the closure can be stored on the stack, with a thread local function pointer which points to the currently active panic handler. No allocation/deallocation and setting/unsetting happens using a RAII mechanism within "with_panic_handler", exactly as the new scoped API works.
I thought that Clone would be implemented for closures consisting of Clone types, is that not the case?

That is not the case. The compiler doesn't treat Clone specially in any way.

@alexcrichton Both are valid concerns. But we cannot have Sync for plain closures, can we (Apart from the fact that the usual handlers won't need to synchronize except perhaps on printing (but that's inherent in stderr, isn't it?)?
Perhaps we can have the best of both worlds by having a PanicHandler trait that can be impl'd for Fns that would implement a handle method and a subthread method where the former will just call our closure and the latter will just return a pointer to self by default. More complex handlers could then still allocate (and be dropped using RAII semantics) and implement specialized subthread methods. Something like
trait PanicHandler : Sync {
    fn handle(obj: &(Any+Send), file: &'static str, line: u32);

    fn subthread() -> PanicHandler;
}

and our thread could then implement the function
fn with_panic_handler<T>(handler: PanicHandler, scoped: T) where T : FnMut();

Could that somehow be made to work?

We need to solve cloning closures at some point.

@bluss Probably, but it's quite hard to get right because interactions in a multithreaded environment may be subtle, and I don't think we will need this here.
I think we should follow the "make easy things easy and hard things possible" approach from Perl, and allow very simple closures while providing tools to build handlers for more complex situations (that may involve sharing of data between threads).
I have a (very early) pre-RFC to auto-derive Sync for immutable empty closures on internals, unfortunately, it's down momentarily. With this change, we could simply impl PanicHandler for `'static Fn+Sync', thus taking care of the simple case.

The Pre-RFC is on internals and I also submitted it to reddit, where it got an instructive discussion, which suggests that we don't even need to care about capturing.
Following that discussion, we could have Arc<Fn(…) + Sync> implement PanicHandler and also implement Into<PanicHandler> for Fn(…) by wrapping it in an Arc::new(&handler as &(Fn(...) + Sync).
Then our API would change to with_panic_handler(Into<PanicHandler>, FnMut())
The beauty of this solution is that we don't need to work around any safety restrictions, and make it ridiculously easy to create a new handler.

@Diggsey

@alexcrichton I'm not sure what you mean about deallocation/unsetting. With a scoped-like API, the closure can be stored on the stack, with a thread local function pointer which points to the currently active panic handler. No allocation/deallocation needed, and setting/unsetting happens using a RAII mechanism within "with_panic_handler", exactly as the new scoped API works.

I agree that a scoped-like API solves some issues, but there are still other issues that exist:

If you have a global handler, then you cannot "un-set" the handler (e.g. leave the scope in which it is registered) until all current invocations of that handler have returned.
If you have a thread-local handler and inheritance via Clone, then you'll need to clone the closure into child threads, but then this is an owned value which needs to be deallocated at some point.

In general this all depends on the exact semantics of the API chosen, but there's some pitfalls here and there to watch out for.

@llogiq

But we cannot have Sync for plain closures, can we (Apart from the fact that the usual handlers won't need to synchronize except perhaps on printing (but that's inherent in stderr, isn't it?)?

I believe we can!
use std::cell::Cell;

fn foo<T: Sync>(_: T) {}

fn main() {
    // OK, the environment is 'Sync'
    let a = 1;
    foo(|| println!("{}", a));

    // Error, the capture of `Cell` is not `Sync`
    let b = Cell::new(a);
    foo(|| println!("{}", b.get()));
}

I think this plays into your pre-RFC, and/or other comments, but all this inference happens today already.

Perhaps we can have the best of both worlds by having a PanicHandler trait that can be impl'd for Fns that would implement a handle method and a subthread method where the former will just call our closure and the latter will just return a pointer to self by default.

What I'm worried about is that this extra trait looks a lot like Clone + FnMut(...), and the composability there would perhaps be nicer. I also have concerns above about cloning closures as it involves dealing with an owned value that needs to be destroyed at some point (this just needs to be specified when/where this happens).

I wrote an example implementation of this (without any form of inheritance):
https://gist.github.com/Diggsey/715f264f6cb69b3132d6

If you have a global handler, then you cannot "un-set" the handler (e.g. leave the scope in which it is registered) until all current invocations of that handler have returned.

Yes, I always intended it to be thread-local.

If you have a thread-local handler and inheritance via Clone, then you'll need to clone the closure into child threads, but then this is an owned value which needs to be deallocated at some point.

Yes, the thread-local handler would first be cloned, the clone would then be moved to the new thread as part of the spawning process (hence the Send bound), and then the stub for the new thread calls the user's closure within a "with_panic_handler" block.
AFAICT, there are two potential issues:

Closures don't currently implement Clone, but that needs to be fixed anyway (especially as Copy implies Clone, and closures are already Copy!)

It might seem initially as though the spawn code would need to be aware at compile-time of the type of the current panic handler in order to make a closure of the correct type. However, that can be solved by just adding a layer of indirection (ie. a box):

trait BoxClone<T> { fn box_clone(&self) -> Box<T>; }

impl<T: PanicHandler> BoxClone<PanicHandler> for T {
    fn box_clone(&self) -> Box<PanicHandler> { Box::new(self.clone()) }
}

Now the spawn code can just always move a Box<PanicHandler> into newly spawned threads, which can be obtained by box-cloning the existing thread-local panic handler.

@alexcrichton Since writing my pre-RFC I received a week's worth of teaching on the subtle semantics of the Fn-types, closures, lifetimes and threads from some of you fine folks :smile:
So I agree, we don't even need a trait.
Regarding the global handler: couldn't it be a const &'static (Fn(...)+Sync)? In that case, what would actually need to be destroyed?

@Diggsey

I wrote an example implementation of this (without any form of inheritance): https://gist.github.com/Diggsey/715f264f6cb69b3132d6

I'd be a little worried about the usage of unsafe there, but would it be possible to use thread::ScopedKey instead for the implementation? That may also be able to lift the 'static bound on the closure as well (and make the code 100% safe)

@llogiq

Regarding the global handler: couldn't it be a const &'static (Fn(...)+Sync)? In that case, what would actually need to be destroyed?

Unfortunately, though a type such is quite difficult to construct (due to the 'static lifetime).

Overall it looks like this thread's going in a few different directions. There's a few questions to consider:

Should a panic handler be thread-local or global?
If a panic handler is thread-local, should it be inherited?
Should panic handlers be owned values or set within a scope of a program?

Following the discussion it sounds like there's different answers to each of these depending on where you're reading, and implementation-wise they can all likely work in one way or another, but the high-level design needs to be settled on first.

@alexcrichton Unfortunately I can't use ScopedKey because it currently has an unnecessary implicit "Sized" bound on the types it can store. My use of "unsafe" should be valid, as I'm doing exactly the same thing as ScopedKey, although obviously it would be preferable to use an existing safe wrapper and have a 100% safe solution.
Also I didn't add the 'static bound without reason - without the 'static bound it would be impossible to extend the code to add inheritence.

@Diggsey oh fascinating! Upon re-inspection I believe that ScopedKey could definitely have ?Sized bounds everywhere to allow usage with trait objects.

Also I didn't add the 'static bound without reason - without the 'static bound it would be impossible to extend the code to add inheritence.

Well unfortunately it's also not currently possible to add inheritance as you're storing a trait object which can't use Clone (as it's not object safe), so a new trait would need to be introduced here. The trait could then possibly require that the cloned handler adhere to 'static where the source doesn't necessarily have to.

Well unfortunately it's also not currently possible to add inheritance as you're storing a trait object which can't use Clone (as it's not object safe), so a new trait would need to be introduced here. The trait could then possibly require that the cloned handler adhere to 'static where the source doesn't necessarily have to.

Yeah, the code from my comment a couple of posts back has an example of how I was planning on doing it:
trait BoxClone<T> { fn box_clone(&self) -> Box<T>; }

impl<T: PanicHandler> BoxClone<PanicHandler> for T {
    fn box_clone(&self) -> Box<PanicHandler> { Box::new(self.clone()) }
}

(This assumes PanicHandler includes a Clone bound)

This RFC could be generalized with the FnAsync proposal to create custom safe handlers.

@l0kod I don't think it's necessary for panic handlers to be re-entrant, because double panics result in an abort.

Sorry for not being around these days, I'm currently quite busy because of my studies. I haven't forgotten this RFC, and I actually have been thinking a lot about the most flexible design for this API, but I will only have time to resume participating in it in a few weeks. I hope it can wait that long.

I just thought of an in-tree use case for this.
Landing pad generation eats up a lot of compile time so it's been occasionally suggested that rustc turn them off. We haven't though because this would have a very bad impact on the user experience of ICE reporting (also embedding rustc).
Custom panic handling would give rustc more options when an ICE happens. For example, rustc itself could be a small program that runs the build in a separate process, which could IPC the compiler output and whatever context is needed from an ICE back to the main process.

I think I lack sufficient perspective and familiarity with some parts of the language to finalize the RFC. It seems to be agreed upon that it would be beneficial to implement the core idea - custom panic handlers. Would it be possible to hand over this RFC to someone more familiar with its potential uses, like the one @brson suggested?

I updated the RFC with implementation details. I tested the proposed changes locally and they worked in a small example I created.

Here's my PoC implementation (src/libstd/rt/unwind/mod.rs): https://gist.github.com/filsmick/211cedc23efa523d6b49
Here's a simple example of how it's used: https://gist.github.com/filsmick/38d01523cfdbcdd9c97f

Could the UX for handlers be improved by Into<str>?
At least the code could be written as obj.downcast_ref::<&'static str>().unwrap_or_else(|o| obj.downcast_ref::<String>().unwrap_or(&"Box<Any>")), right? All that match business looks pretty cumbersome.

Not sure. This code was taken from the current panic handler. I'm keeping the current Callback function signature for maximum backward compatibility and to keep the RFC simple; no need to change what works. The comments say the Any trait object is used to avoid generic instantiation on a rarely-called function.
You shouldn't have to rewrite a panic handler that often anyway, so a few extra lines won't hurt as much, and if you want to write a lot of different handlers, you can still abstract those matches away with a function, macro or whatever.

I would very much like to see either handler inheritance or a global "default handler", but this seems like a great first step in that direction.

I have added the PanicData struct to my local implementation, but if it lives in rt::unwind it's unstable even if reexported, making it impossible to write custom handlers on stable. Is this acceptable?

I think that some of the business in std::rt that exists today (registering handlers via on_panic) should probably be jettisoned entirely as well. It may be more consistent to have just precisely one panic handler for a thread instead of possible multiple ones. For example if a panic handler is set then it should override the default "print to stderr" handler. It looks like the current design/implementation don't provide a way to turn that off?
The only other question I would have is whether we want the ability to manipulate the previous handler. For example if I set a new handler, should I be able to call the old handler as well? Other similar mechanisms, like sigaction, sort of allow this, so it's a possibility we may wish to explore.

@alexcrichton As far as I know, the current implementation doesn't allow to replace the current behavior, only to define a 'sink' stderr to hide the output of on_panic.
To manipulate the previous handler, we can provide a get_panic_handler function which returns the currently defined one. Users can call it before set_panic_panic_handler.
I'll work on a design working with closure and addressing these points. Would a FnMut argument for set_panic_handler do?

To manipulate the previous handler, we can provide a get_panic_handler function which returns the currently defined one

Unfortunately if a generic is taken then the semantics would be that it would take the current panic handler instead of just returning it.

Would a FnMut argument for set_panic_handler do?

I believe Fn reflects more accurately what's going on here because it avoids the need for an extra RefCell in TLS (e.g. this can be invoked in a recursive fashion).

@alexcrichton What about returning a reference to the closure?

Unfortunately that can't be done due to the API of TLS itself for safety
reasons
On Mon, Jul 6, 2015 at 10:21 AM Yohaï Berreby<EMAIL_ADDRESS>wrote:

@alexcrichton https://github.com/alexcrichton What about returning a
reference to the closure?
—
Reply to this email directly or view it on GitHub
https://github.com/rust-lang/rfcs/pull/1100#issuecomment-118930030.

@filsmick would be up for updating this RFC with some of the comments I've had here? I believe @sfackler would also be willing to take up moving this RFC forward if you're short on time!

@alexcrichton I will, when I have a stable-ish implementation of the new design with closures.
As for the old handler, since it's not possible to move out of ScopedKey, I'm thinking about storing and returning a Rc.

Here's a working example of the use of the new API: https://gist.github.com/filsmick/e0505d7171c997b45a53
@alexcrichton does this address your concerns about being able to get a handle to the previous handler?

RFC updated.

Thanks for the update @filsmick! I'd personally have some reservations about exposing the Rc type as an implementation detail (and possibly having it as an implementation detail at all..), but I have a feeling @sfackler may share my concerns, and he's volunteered to start sheperding this RFC. As a result I'm going to reassign this to him.

I reread the updated RFC and have some comments:

The choice of Fn for the handler seems somewhat limiting - it seems to me that FnOnce would be the more intuitive choice given that a thread can only unwind once.
I'm not sure I'm totally on board with using a Fn trait at all. It is convenient to define, but pretty limiting - e.g. the note that we can't add a Clone bound. An explicit trait can allow us to avoid those limitations as well as making the API a bit more explicit.
The RFC states that some form of handler inheritance can be added in the future but I don't think this is possible in the current formulation - Rc isn't Send, and neither is the Fn itself.
I agree with @alexcrichton's reservations about exposing Rc in the API. An ownership-based API with take_panic_handler that unregisters and returns the current handler by value (I guess replacing it with the default) seems like it would avoid those pitfalls.
We should think at least to some extent about the direction we want to go in the future (e.g. handler inheritance) to make sure the proposed API will enable those features. For example, how specifically should inheritance work? One option would be to have a single handler stored in an Arc, and shared between threads, but that would require extra bounds, and prevent us from using FnOnce style handlers. Another option would be to add a Clone bound to the handler. Or should it be some different kind of method to allow for handlers that can't be inherited?

The choice of Fn for the handler seems somewhat limiting - it seems to me that FnOnce would be the more intuitive choice given that a thread can only unwind once.

The one case I can think of for calling the handler twice would be a double-panic. It'll end up in a process abort no matter what but it allows the application to act on the double panic at least.

I'm not sure I'm totally on board with using a Fn trait at all. It is convenient to define, but pretty limiting - e.g. the note that we can't add a Clone bound. An explicit trait can allow us to avoid those limitations as well as making the API a bit more explicit.

Could you elaborate on what you're thinking about with Clone? I suspect it ties into the inheritance story for if we Clone it, but otherwise I'd push for Fn to not have a one-off trait for this basically.

Panic handlers run after the whole thread has unwound, right? Double panics would only be an issue if the handler itself panics then, in which case it seems like abort is definitely the best option if it allows an API that takes &mut self or self rather than &self.
The Clone suggestion was tied in the the inheritance story. It's pretty crucial that we allow some way to avoid having to explicitly set the handler for every thread in existence. The two ways that I see of going about this would be something similar to Java, which has a global default uncaught exception handler that you can swap out, or an inheritance scheme where new threads get a copy of the spawning thread's handler.
The Java style API would probably translate to a globally installed handler factory thing, while the inheritance option would require some way to get a new handler out of an existing one.
In addition, I imagine we'd want to allow the handler to be configured in thread::Builder which would require Send handlers.

@sfackler No, unless the proposal has changed since I last commented (quite possible) panic handlers would run first, and then the stack would unwind.

@sfacker Threads could set up their own handlers, so they would not necessarily need to be Send.
However,

Should we opt to copy the Java solution (which if my experience doesn't fail me already gets us more than 90% of the use cases), the global handler needs to be Send and must be able to be called more than once, which rules out both FnOnce and FnMut.
Should we go with the more complete inheritance-based solution, all handlers would need to be Send to let other traits inherit them.

How about a trait that can be implemented plus a default impl or wrapper struct+impl for &'static Fn(..)s?

An alternative to a Send+Sync global handler for the Java approach would be a global Send+Sync "handler factory" that produces thread-local handlers which on their own wouldn't need any bounds.

@sfackler yeah as @Diggsey mentioned we run these handlers currently before unwinding, so the double-panic part may come into play.
I'm somewhat leaning more towards only having a global handler as it allows building thread-local handlers on top, so in that sense it seems more flexible. Along those lies I'd want the handler to be Send + Sync so we're basically just allowed to call it concurrently.

+1 for this. Writing an ugly message to stderr isn't the best thing to do when you have a bug.

+1
My current problem is that I am working on a library using coroutines, that is supposed to handle panics of coroutines it manages. It also implements tests that exercises panic conditions in multithreading cases (so the terminal gets severely trashed).

@dpc Of course as we know from certain logging frameworks the right thing to do in such cases is to use an MPSC queue + thread to write the messages.

@llogiq : I don't understand.

Your problem is that multiple threads may write to the console. To avoid trashing the terminal with concurrent writes, you need to serialize the output. Now there are two ways to do that: Either have the panic output lock the console (which has its own set of problems), or send the stack info to a helper thread that your library spins up to output the stack traces. The panic helper thread then becomes the synchronization point. Of course to send the stack infos, one needs some kind of MPSC queue (e.g. a channel).

I don't want to synchronize anything. I'm not printing anything. It's just panic!() in my tests (which I'm testing) that prints things, that I don't asked it to. :)

So you want to silence panic!()? Or send some info to a web service? Or put it in an errors.log? What exactly do you want panic!() to do?

@llogiq I don’t think exact use case is important in this discussion. It is pretty clear already that @dpc would need custom panic handlers (global (which are not impossible at the moment, but pretty painful to do) or thread local) anyway.

Yes. I just wanted to state my usecase, and why I +1 this RFC.

:+1: Cool stuff.

@nagisa It is not clear to me if catch_panic would suffice for @dpc 's use case, that's why I'm asking.

@llogiq
When logging to stderr you can rely on write(2) atomicity.

What's the status of this?

@arielb1 As per https://github.com/rust-lang/rfcs/pull/1100#issuecomment-132446488, there are some problems with my last proposal. The idea itself - custom panic handler - seems to have been well received, but the proposed implementation is far from perfect.
Unfortunately, my studies take up a lot of time so I probably won't be able to come up with a new, reasonably good implementation spec in the following months. So unless somebody else does, well, it may take a long time for this to be accepted and implemented.

cc @ranma42 (I started doing some work on TLS and panicking, I might be able to contribute if I get some spare time)

I'm all for this PR. I help develop a terminal graphics library and stderr is not a valid stream we want to be printing exceptions to. We currently have no tools to copy / redirect stderr in rust, this would allow us to properly do so

I'm all for this PR. I help develop a terminal graphics library and stderr is not a valid stream we want to be printing exceptions to. We currently have no tools to copy / redirect stderr in rust, this would allow us to properly do so

This RFC still wouldn’t allow copying or redirecting stderr per se. It is, however, already possible on at least POSIX systems by using dup2(2).
use std::os::raw::c_int;
extern { fn dup2(fd1: c_int, fd2: c_int) };

fn main(){
    // create a fd
    unsafe { assert!(dup2(your_fd, 2) != -1); }
}

For those interested, @sfackler has posted an alternate RFC to this one which is more centered around global handlers.

:bell: This RFC is now entering its week-long final comment period :bell:
Note that this entering FCP at the same time as #1328 and the two will likely be decided upon as a unit.

@alexcrichton I'm pretty sure this RFC can't be merged as-is, and I wouldn't want it to, since the issues @sfackler's pointed out haven't been addressed. Should I close it now?

It's true that the libs team would be unlikely to merge this as-is, but it represents an alternative strategy from #1328 that we're willing to consider. Along those lines we're fine leaving this open as a proxy for the "thread local strategy" vs the "global handler strategy".

The libs team discussed this RFC during triage yesterday and the conclusion was to merge #1328 and close this one. Thanks again for the RFC though @yberreby!


Maven Central

Many thanks for open sourcing this great library! Would you consider uploading it to Maven Central? I can't add jitpack as a maven repository in some of the projects I'd like to use this lib, unfortunately.

I would consider it but it'll have to go on the to do list because I've a bit of a backlog and haven't uploaded anything there before.

I can help you with the setup. Ping me.
You will need:

An account on sonatype (Nexus: https://oss.sonatype.org, Jira: https://issues.sonatype.org/ -- it is the same login)
With the ownership of a groupId
You also need to sign your artifacts, which requires some GPG setup.

From a build point of view:

you will need following plugins:

id 'signing' to sign your artifacts
id 'io.github.gradle-nexus.publish-plugin' to manage the publication on sonatype

Optionally:

I am also using id 'net.researchgate.release' to change the version (management of -SNAPSHOT suffix) and tag the version

I did not do a complete review, but some other

version management: in a lot of project the version is a.b.c-SNAPSHOT while you develop. Maybe it is not compatible with jitpack. And it it is changed too a.b.c when you create the release. And then it is bumped to a.b.(c+1)-SNAPSHOT to work on the next version.
some changes to the generated pom to add some required sections.

Ping me if you need more details.
There are also tons of tutorials on the web.

What you could also consider is joining an existing organization like the one I am participating to: https://github.com/OpenAPITools (I did not ask if this would be possible, In my opinion OpenAPI and JSON-Schema are related topics).
All the administrative tasks are already solved and you would join an helpful community. But I can understand that you prefer keeping full ownership on your project. (I also have the setup to publish on maven central my own side projects -- not shared with the community)


[0.9.5-nightly] COUNT() not working

Hi,
I have been using the influxdb-0.9.5_nightly_9633410-1.x86_64 for the last week to record data and the count aggregate function is not working as expected. I have just upgraded to  0.9.5-nightly-ef84e33 and the problem remains. I have one measurement metric with one field value.
I have several tags (e.g. Type & "Managed Entity"). If I do a query to show the values added in the last day for value I get a list. (limited to 1 for brevity here):
> Select  value from metric WHERE Type = 'Event'  AND TIME > now() - 1d limit 1
name: metric
------------
time                    value
1446806868301000000     101

HOWEVER if I do a count then I get null:
 > Select  count(value) from metric WHERE Type = 'Event'  AND TIME > now() - 1d
name: metric
------------
time                    count
1446779243868660021

@benbjohnson related to the QE refactor?

@beckettsean The QE refactor is still in a branch so it won't affect anything coming out of master.

@ivanscattergood -- do you see this issue with <IP_ADDRESS>?

It works fine in <IP_ADDRESS>
---- otoolep wrote ----
@ivanscattergoodhttps://github.com/ivanscattergood -- do you see this issue with <IP_ADDRESS>?

Reply to this email directly or view it on GitHubhttps://github.com/influxdb/influxdb/issues/4701#issuecomment-155225753.

I upgraded to 0.9.5 nightly yesterday, and I got exactly same error.

I am unable to replicate this.
> create database mydb
> insert metric,Type=Event value=101
> Select  value from metric WHERE Type = 'Event'  AND TIME > now() - 1d limit 1
name: metric
------------
time                    value
1447348895184066731     101

>  Select  count(value) from metric WHERE Type = 'Event'  AND TIME > now() - 1d
name: metric
------------
time                    count
1447262513434782993     1

Can you show me a select * from metric so I can see all fields/tags?  Fields and tags are case sensitive, is that causing the problem?

Using populated database (_internal), cannot repro on 0.9.5-nightly-905437c
> select autoFlush from wal where hostname='sean-0.9.5' and nodeID='1' and time > now() - 1d limit 1
name: wal
---------
time			autoFlush
1447268610000000000	159274

> select count(autoFlush) from wal where hostname='sean-0.9.5' and nodeID='1' and time > now() - 1d
name: wal
---------
time			count
1447268577578500563	58697

Also cannot repro with latest
InfluxDB shell 0.9.5-nightly-ebb9172
> use _internal
Using database _internal
> select autoFlush from wal where hostname='sean-0.9.5' and nodeID='1' and time > now() - 1d limit 1
name: wal
---------
time			autoFlush
1447268770000000000	156511

> select count(autoFlush) from wal where hostname='sean-0.9.5' and nodeID='1' and time > now() - 1d
name: wal
---------
time			count
1447268764714990027	58674

@ivanscattergood can you give SHOW TAG KEYS FROM metric and SHOW FIELD KEYS FROM metric?
@xvtom can you give any output to show the issue happening for you, too? It would really help to have more than one repro case to attempt.

Here’s the output requested:

SHOW TAG KEYS FROM metric
name: metric

tagKey
BU
Category
Column name
Component
Data Unit Type
Data View
Datacenter
Environment
Gateway
HARole
Location
Managed Entity
Probe
Row name
Sampler
Subcomponent
Variable name
name: metric
fieldKey
Error count
Ok count
Severity id
Type
Warning count
value
Ivan Scattergood
Business Driven IT
Office:  +44(0)207 0971639
Mobile:  +44 (0)7813 79 7753
Skype:  BusinessDrivenIT
Ivan<EMAIL_ADDRESS>http://www.BusinessDrivenIT.comhttp://www.businessdrivenit.com/
From: Sean Beckett<EMAIL_ADDRESS>Sent: 12 November 2015 19:08
To: influxdb/influxdb<EMAIL_ADDRESS>Cc: Ivan Scattergood<EMAIL_ADDRESS>Subject: Re: [influxdb] [0.9.5-nightly] COUNT() not working (#4701)
Also cannot repro with latest
InfluxDB shell 0.9.5-nightly-ebb9172

use _internal

Using database _internal

select autoFlush from wal where hostname='sean-0.9.5' and nodeID='1' and time > now() - 1d limit 1

name: wal

time            autoFlush
1447268770000000000 156511

select count(autoFlush) from wal where hostname='sean-0.9.5' and nodeID='1' and time > now() - 1d

name: wal

time            count
1447268764714990027 58674
@ivanscattergoodhttps://github.com/ivanscattergood can you give SHOW TAG KEYS FROM metric and SHOW FIELD KEYS FROM metric?
@xvtomhttps://github.com/xvtom can you give any output to show the issue happening for you, too? It would really help to have more than one repro case to attempt.
—
Reply to this email directly or view it on GitHubhttps://github.com/influxdb/influxdb/issues/4701#issuecomment-156203924.

Thanks for the output, @ivanscattergood. I notice there's a field in the WHERE clause of your examples, I was testing with tags in the WHERE clause.

Yep, it's the field in the WHERE clause that's causing the issue:
InfluxDB shell 0.9.5-nightly-ebb9172
> use _internal
Using database _internal

# COUNT without field works fine:

> select count(memSize) from wal where time > now() - 10m
name: wal
---------
time			count
1447372252444579785	124

# COUNT with field returns nothing:

> select count(memSize) from wal where metaFlush = 19 and time > now() - 10m
name: wal
---------
time			count
1447372256395823973

# Data matches the selection criteria from the broken COUNT query:

> select memSize from wal where metaFlush = 19 and time > now() - 10m
name: wal
---------
time			memSize
1447372506000000000	0
1447372516000000000	0
1447372526000000000	5556
1447372536000000000	0
1447372546000000000	0
1447372556000000000	5556
1447372566000000000	0
1447372576000000000	0
1447372586000000000	5556
1447372596000000000	0
1447372606000000000	0
1447372616000000000	5556
1447372626000000000	0
1447372636000000000	0
1447372646000000000	5556
1447372656000000000	0
1447372666000000000	0
1447372676000000000	5556
1447372686000000000	0
1447372696000000000	0
1447372706000000000	5556
1447372716000000000	0
1447372726000000000	0
1447372736000000000	5556
1447372746000000000	0
1447372756000000000	0
1447372766000000000	5556
1447372776000000000	2778
1447372786000000000	0
1447372796000000000	5556
1447372806000000000	2778
1447372816000000000	0
1447372826000000000	0
1447372836000000000	2778
1447372846000000000	0
1447372856000000000	0
1447372866000000000	2778

Does not exist in <IP_ADDRESS>:
# 0.9.5 output

> insert four701 value=1,foo=2
> insert four701 value=1,foo=3
> insert four701 value=1,foo=2
> insert four701 value=1,foo=3
> insert four701 value=1,foo=2
> insert four701 value=1,foo=3
> select count(value) from four701
name: four701
-------------
time	count
0	6

> select count(value) from four701 where foo=2
name: four701
-------------
time	count
0

# 0.9.4 output:

> insert four701 value=1,foo=2
> insert four701 value=1,foo=3
> insert four701 value=1,foo=2
> insert four701 value=1,foo=3
> insert four701 value=1,foo=2
> insert four701 value=1,foo=3
> select count(value) from four701
name: four701
-------------
time			count
1970-01-01T00:00:00Z	6

> select count(value) from four701 where foo=2
name: four701
-------------
time			count
1970-01-01T00:00:00Z	3

@ivanscattergood -- does adding fill fix your issue? Like so:
select  value from metric WHERE Type = 'Event'  AND TIME > now() - 1d limit 1 fill(0)

We believe this issue is now fixed in master and will be in 0.9.5-rc2.

Not fixed, still incorrectly reports zero when there are matching points:
> select count(value) from four701
name: four701
-------------
time	count
0	6

> select * from four701 where foo = 3
name: four701
-------------
time			foo	value
1447438449694435399	3	1
1447438454838871141	3	1
1447438455382336680	3	1

> select value from four701 where foo = 3
name: four701
-------------
time			value
1447438449694435399	1
1447438454838871141	1
1447438455382336680	1

> select count(value) from four701 where foo = 3
name: four701
-------------
time	count
0	0

>

The last value should be 3, not zero. It's incorrectly reporting no matching points, but the previous query shows there are matching points, as long as there's no COUNT() function applied.

OK, looks like I might fixed the wrong bug. Taking a look now.

I believe this is fixed by https://github.com/influxdb/influxdb/pull/4789

Fixed in and cherry-picked to 0.9.5.


Wardship: set assign_public_ip for ecs to false, add vpc endpoint

@matt-k1998 Terraform plan evalaution detected changes to resources that require approval from a member of @ministryofjustice/modernisation-platform

@matt-k1998 Terraform plan evalaution detected changes to resources that require approval from a member of @ministryofjustice/modernisation-platform

@matt-k1998 Terraform plan evalaution detected changes to resources that require approval from a member of @ministryofjustice/modernisation-platform


[HOLD for payment 2023-10-12] [$500] Dev:  Login - Console error when visiting sign-in-with-google

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open staging.new.expensify.com/sign-in-with-google

Expected Result:
No console error
Actual Result:
A console error (Failed prop type: The prop 'isInModal' is marked as required ...) appears
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[x] Android / Chrome
[ ] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: Dev 1.3.73-0
Reproducible in staging?: n
Reproducible in production?: n
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/93399543/913dcb0f-5849-413a-a07d-28e06bff3599
https://github.com/Expensify/App/assets/93399543/1e3330a1-0ca5-4f87-beca-e082bdcb75d9
https://github.com/Expensify/App/assets/93399543/68e51b20-00ac-4405-aaf6-d0d3f1aa6ad8
Expensify/Expensify Issue URL:
Issue reported by: @bernhardoj
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1695564791087179
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~019dc980db27c78760
Upwork Job ID:<PHONE_NUMBER>376038912
Last Price Increase: 2023-09-26
Automatic offers:

bernhardoj | Contributor | 26980116
bernhardoj | Reporter | 26980118

Proposal
Please re-state the problem that we are trying to solve in this issue.
A console error shows when visiting /sign-in-with-google page.
What is the root cause of that problem?
sign-in-with-google page shows a SignInPageLayout component that requires isInModal props to be passed but we pass nothing.
https://github.com/Expensify/App/blob/4ea4a55ad2c9ecdb66d45cc1872612ea22e4605f/src/pages/signin/ThirdPartySignInPage.js#L60-L64
https://github.com/Expensify/App/blob/4ea4a55ad2c9ecdb66d45cc1872612ea22e4605f/src/pages/signin/SignInPageLayout/index.js#L41-L42
What changes do you think we should make in order to solve the problem?

sign-in-with-google page will never be shown on an RHP, so we can always pass isInModal as false.
or we can set isInModal optional and set false as the default value.

Proposal
Please re-state the problem that we are trying to solve in this issue.
while entering /sign-in-with-google page a typescript error occurs which indicates a prop for the component SignInPageLayout named isInModal is missing.
What is the root cause of that problem?
the root cause is lack of isInModal prop passing from parent component ThirdPartySignInPage.
What changes do you think we should make in order to solve the problem?
the missing prop is used to determine whether the style for small screen should be implemented or large.
Judging by the error the previous page is ThirdPartySignInPage and due ti the fact that lack of this prop hasn’t effected the UI so we might as well fix it by setting the value in the previous page to false.

Not sure why external label was applied directly here

This should have been part of initial implementation or regression, but looks like it has been a month since it was implemented, so fine fixing it here

@allroundexperts mind taking care of the BZ checklist this week?

Bumped BZ checklist

Pending completion of BZ checklist before we issue payment

Still waiting on checklist. I think we can bump to Weekly.

Bumped in Slack

BZ checklist complete. All set to issue payment!

This PR qualifies for a speed bonus, so we need to issue the following payments:

@bernhardoj - $750 for PR + speed bonus. Paid via Upwork.
@bernhardoj - $50 for reporting the bug. Paid via Upwork.
@allroundexperts - $750 for C+ review + speed bonus. Paid via NewDot.

@bernhardoj $750 sent for PR + bonus and contract ended!

@bernhardoj $50 sent for reporting and contract ended!

Wooo, ty! Closing as this is all set. Payment summary message is here.

$750 payment approved for @allroundexperts based on BZ summary.


Better error message when $KUBECONFIG not set

Currently if $KUBECONFIG is not get you get an error message like:
[localhost][err] [FATAL][2017-09-26 09:39:15 -0400][context][namespace]    Configuration invalid
[localhost][err] [FATAL][2017-09-26 09:39:15 -0400][context][namespace]    - Kube config not found at

This will change the second line to "$KUBECONFIG not set" which should be easier to understand.

Change looks good, but could you please add test coverage for this in test/unit/kubernetes-deploy/runner_test.rb?

Test Added


Bad AV_* names

Dear developpers,
In the bebop_driver/src/bebop_video_decoder.cpp, lines 93, 95, 97, I had to modivy the CODEC_* macros with AV_CODEC_* ones.
Thank you for your useful job,
Best regards
Hervé

I open an pull requests to fixed it.
fixed build bebop_driver on ROS Melodic #218
Best regards


Refactor WebSocket code

Purpose

This adds more minor improvements to the code

Approach

N/A

Samples

N/A

Remarks

N/A

Check List

[ ] Read the Contributing Guide
[ ] Required Balo version update
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #19519 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #19519   +/-   ##
=======================================
  Coverage   15.71%   15.71%
=======================================
  Files          47       47
  Lines        1266     1266
  Branches      197      197
=======================================
  Hits          199      199
  Misses       1054     1054
  Partials       13       13

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 c72d4a3...794d167. Read the comment docs.


Image filter position

Hello,
I'm trying to place a filter (with ImageObjectFilterRender) at specific position of my stream like this :

And with the code :
val imageObjectFilterRender = ImageObjectFilterRender()
it.glInterface.setFilter(1, imageObjectFilterRender)
imageObjectFilterRender.apply {
    setImage(bitmap)
    setPosition(TranslateTo.TOP_RIGHT)
}

Is there any way to specify ratio or position like in my picture ?
Thanks :)

As you can read here:
https://github.com/pedroSG94/rtmp-rtsp-stream-client-java/wiki/Real-time-filters
setFilter(position, filter) is only necessary if you use multiple filters.
In your case, you can use set filter like:
val imageObjectFilterRender = ImageObjectFilterRender()
it.glInterface.setFilter(imageObjectFilterRender)
imageObjectFilterRender.apply {
            setImage(bitmap)
            setPosition(TranslateTo.TOP_RIGHT)
            setScale(50f, 20f)
}

Many thanks !
I have noticed that the BaseFilterRender is less cleaner than the ImageObjectFilterRender (it depends on the device). So finally I'm converted all my watermark into Bitmap and I make only ImageObjectFilterRender.  I guess this is less efficiant in term of performance, but the incrustation is in better quality.


Fix empty block retrieval

So I've finally managed to find the issue which caused RetrieveBlockData not to work in #293. The problem was in the wrong root calculation in wrapped NMT for empty blocks.
P.S. This was my first adventure through the whole rsmt2 stack and it took unexpectedly long to find out the problem is still somewhere in LL. Original symptoms were too confusing but was kind of fun 🍵

and it took unexpectedly long to find out the problem is still somewhere in LL.

This is great investigative work! It was a tricky bug that snuck it's way in over the course of a month. We had to refactor quite a bit to include namespaces in the erasure data, then we started using the "minimum" viable data availability header. It took me a while to understand precisely why, and I'm the one who wrote the damn bug in the first place :laughing:
I wish I would have reached out Wednesday when I heard you were having an issue with RetrieveBlockData, maybe I could have saved you some headache...
great work!

Codecov Report

Merging #299 (d38c150) into master (8524627) will increase coverage by 0.06%.
The diff coverage is 100.00%.


Activity Suggestion.

This feature has been added.
I am looking into adding the album artwork but it does not seem to be natively supported. unless im missing something. It looks like this can be done with a separate script but that is not something I would want.

This is added but I dont see a good way to have this active with multiple servers. so I think im going to make a bool in the config to it can be disabled.


Improvement: @Generated annotation to mark code that should be ignored by JaCoCo

Hi,
It would be nice to have an "@Generated" annotation with class retention policy that can be ignored by code coverage tools like JaCoCo. This should work similar to how it's done for Immutables and Lombok.
Thanks in advanced.

@akayoshi29 I guess you could just mark the entire generated folder as an exclusion to jacoco. In gradle it will look like this:
<build.gradle>
...
jacocoTestReport {
	afterEvaluate {
		classDirectories.from = files(classDirectories.files.collect {
			fileTree(dir: it,
			exclude: [
				"com/myapp/genDir/**",
				"com/myapp/someOtherexclusion/**"
			])
		})
	}
}
...

Cheers
Nikao

@niclarcipretti Thanks for your response but JaCoCo analyzes only the bytecode. If I do what you say, I exclude tests for abstract or default methods. I don't want to exclude them, I want to exclude only generated code.

Hi @akayoshi29,
Querydsl generates whole classes. So, you shouldn't have any non generated code within it imo. Making them the perfect candidates for jacocos exclusions. Can you elaborate a little more with some examples, if you disagree?
Cheers

@niclarcipretti Yes, QueryDsl generate the whole class but it is in the same directory of the interface or abstract class in the bytecode.
For example :

files project :
-- src/main/java/org/example/querydsl/Object.java
-- target/generated-sources/org/example/querydsl/Qobject.java
bytecode :
-- target/classes/org/example/querydsl/Object.java
-- target/classes/org/example/querydsl/Qobject.java
So, if I exclude "org/example/querydsl/**", I exclude the Object.java but I want to keep it.

I can exclude "org/example/querydsl/Q*" but if  I have different folders which use QueryDsl, I have to do this for all of these and they must not have object start with Q.
I prefer a generic solution like Lombok. With Lombok, I use the default behavior of JaCoCo :

Lombok behavior : add only a file "lombok.config" in the project  with the value "lombok.addLombokGeneratedAnnotation = true" which generate their own @Generated tag in bytecode
JaCoco behavior : check Lombok tag to ignore all methods and classes generated by Lombok.

Cheers

@akayoshi29 in this use case, you're right.
Usually, we separate entity mapping classes in a specific package and add this package to exclusions, once you don't need  code coverage in entity classes.
Best of luck
Nikao

@akayoshi29 I found the same problem, then I found the solution in the documentation, you can set an option querydsl.packageSuffix in your pom.xml or build.gradle.
for example, in my pom.xml
<plugin>
  <groupId>com.mysema.maven</groupId>
  <artifactId>apt-maven-plugin</artifactId>
  <version>1.1.3</version>
  <executions>
    <execution>
      <goals>
        <goal>process</goal>
      </goals>
      <configuration>
        <outputDirectory>target/generated-sources/java</outputDirectory>
        <processor>com.querydsl.apt.jpa.JPAAnnotationProcessor</processor>
        <options>
          <!-- set the generated-sources package suffix-->
          <querydsl.packageSuffix>.querydsl</querydsl.packageSuffix>
        </options>
      </configuration>
    </execution>
  </executions>
</plugin>

and then, the files project:

-- src/main/java/org/example/domain/object.java
-- target/generated-sources/org/example/domain/querydsl/Qobject.java

you can ignore the querydsl package in your test coverage config

Thank you @NaixSpirit.
I would have preferred the annotation in the bytcode but it's a good alternative.
Thanks again.

Sounds reasonable to me. If anyone would like to contribute this change I think we can merge it.

I have a pull request for this. https://github.com/querydsl/querydsl/pull/2657


Using data-html with ability to create a new option displays [object Object]

If you set your select2 widget to use html by setting the "data-html" attribute to true, and also have the ability to create new options, the new option will show as [object Object] instead of rendering the text properly.  The offending code is here:
https://github.com/yourlabs/django-autocomplete-light/blob/master/src/dal_select2/static/autocomplete_light/select2.js#L11-L32
I am not sure why you need to wrap the text in a span if the item is being created, but if you are using HTML, the template function will return a span object, which you are then trying to insert as text into the second span.  Changing the text to HTML works, and does not break the non-HTML case, although I am not sure if that's an ideal solution or if it should be detecting this case and only inserting one wrapping span.

I am also experiencing this issue! I guess a workaround for me would be a way to apply a class to the query results container once it gets created - is there a way to do this that anyone knows of? It doesn't look like overriding the JS as they describe works the way I was expecting it to

I'm also experiencing this.
I've submitted a PR that should fix this based on your comments @mitchelljkotler

Hi all,
Please try PR #1181 by @syserr0r and let us know if that works for you prior to releasing.
Thank you deeply :tophat:

@madison-ookla sorry about that, it seems the docs are not updated, see the change in docs in a2705b40c4f92a3ed0da949fe4a9786ee6e86660
(RTFD builds fine, digging to figure the docs problem)

@madison-ookla my bad, the link you are showing from the docs is from version 3.5.1, but 3.6.0 was released on July 6, the right link is fine:
https://django-autocomplete-light.readthedocs.io/en/master/tutorial.html#overriding-javascript-code

@syserr0r @jpic I can confirm that when I edit the files in my container to reflect the changes of #1181, the create object tab behaves as expected! Although this creates a new problem for me, as I need to find some other way to modify the HTML of the Please enter <x> or more characters section of the dropdown...

@madison-ookla thank you ! It was merged and will release by the end of the week.
If you want to wait a couple of months, I'm pushing this to production soon:
https://oss.yourlabs.me/autocomplete-light/
And then will finish up #1168


docs/siteconfig.rst: adapt comments to reality

A couple lines below this it says "count: 0", so replace "three" with
"zero".
Signed-off-by: Nathan Cutler<EMAIL_ADDRESS>

Wouldn't it make a bit more sense to s/0/3/ ?

@znc: +1 (fixed, rebased, repushed)

Thanks @smithfarm! Sorry for not seeing this earlier as well :)


How to use useSprings hooks and reset the initial drag state for multiple items?

Here is my code, the problem happens when my algorithm changes the coordinates of the points dynamically. With single useSpring I can control this using the initial function, but with multiple I can't, any tips?
`const [springs, setSprings] = useSprings(items.length, (index: number) => {
// Getting right coordinates
let [x,y] = newPointValues(index)
return {x,y}
});
const [isDragging, setIsDragging] = useState(false)

const bindDrag = useGesture({
    onDrag: ({dragging, args: [index], movement}) => {
        console.log("[dd] dragging")
        if (itemIndex !== index) {
            // set current item index
            setItemIndex(index);
        }

        // Save relative position
        calcPosition(index, movement)

        setIsDragging(dragging)

        let [mx, my] = movement

        setSprings((i: number) => {
            if (index !== i) return
            return {x: mx, y: my}
        })
    }
}, {
    drag: {
        bounds: relativePos,
        initial: () => {
            // Initial get called before all gesture events, how to get index of right element?
            return (itemIndex !== undefined && newPointValues(itemIndex!!)) || [0, 0]
        }
    },

})`

An example is available here https://codesandbox.io/s/react-typescript-forked-zk6wl, as you can see the initial function return the value of the item dragged before

You can try saving initial position on hover event:
onHover: ({ args: [index] }) => (itemIndex !== index) && setItemIndex(index)

I'll leave this open as I'll investigate to possibly make initial accept an argument. Not exactly sure how for now.

@riccardocaranfil this should be now possible in v8 latest beta. Bounds and initial can now be functions of the gesture state, meaning you can do something like you suggested:
bounds: ({ args: [index] }) => ({ left: 100 * index }),
initial: ({ args: [index] }) => [springs[index].x.get(), springs[index].y.get()]

Fixed in v8

@dbismut I'm updating now the code and I'm getting no state in the initial callback
Here my code:
  const bindDrag = useGesture({
    onDragStart: () => {
      ...
    },
    onDrag: ({args: [index], movement}) => {
        ...
    },
    onDragEnd: ({args: [index], movement}) => {
       ...
    },
}, {
    drag: {
        bounds: bounds,
        rubberband: true,
        initial: ({args: [index]}) =>  [springs[index].x.get(), springs[index].y.get()]
    },
})

The problem is that in the initial function the state object is  undefined
Can you help me?

Can you upgrade to the latest beta v10 10.0.0-beta.7 ? It is pretty stable and fixes some bugs from v9. The initial prop is replaced by from though, and you should use offset with it rather than movement.
Also, as a side note useGesture is a bigger import than useDrag. If you just need it for onDragEnd or onDragStarthandler I'd recommend to use first and last state props.

@dbismut I updated the library as you suggest and now I can get the index, but not the really first time
    const bindDrag = useDrag(({args: [index], first, last, offset}) => {
      if (first) {
          ....
      } else if (last) {
          ...
      } else {
          ...
      }
  }, {
      ...
      from: ({args}: any) => {
          // {args: [index]} <--- error destructuring cause args is undefined at the begining
          const index = args?.[0]
          return index !== undefined ? newPointValues(index) : [0,0]
      }
  })

Any other tips?
Thanks

Hi, please provide a sandbox, that would really help.

@riccardocaranfil thanks a lot for raising this, it was indeed a bug. Should be resolved in latest v10 beta.
https://codesandbox.io/s/example-react-use-gesture-issue-forked-q0bui

@dbismut Thanks for you're suggestions now I have all working fine.
I have only one question: while dragging the dots I notice there is a sort of friction (I've already play a bit with the "friction" property) and the dot doesn't follow the mouse perfectly as I expect, do you know why this happens?
PS. The problem is more visible if you zoom a bit in

@riccardocaranfil this is not related to @use-gesture, this has to do with react-spring, you should use the immediate option if you don't want the trail / spring effect.
Basically you should do this:
set({ x: myXValue, immediate: true })

Btw, feel free to upgrade to @react-spring/web (latest is v9.2), this will result in a lighter install and less peer dependency warnings!


Fixed pandas FutureWarning

Description

Fixing pandas FutureWarnings:
https://pandas.pydata.org/docs/whatsnew/v1.4.0.html#deprecated-dataframe-append-and-series-append
https://github.com/pandas-dev/pandas/issues/42825
Motivation and Context

How Has This Been Tested?

[ ] Pass the test by running: pytest qlib/tests/test_all_pipeline.py under upper directory of qlib.
[ ] If you are adding a new feature, test on your own test scripts.

Screenshots of Test Results (if appropriate):

Pipeline test:
Your own tests:

Types of changes

[x] Fix bugs
[ ] Add new feature
[ ] Update documentation

Thanks. It looks great!
Welcome to join Qlib's contributors

Thanks. It looks great!
Welcome to join Qlib's contributors


Cannot start nuxt:  The requested module 'vite-plugin-inspect' does not provide an export named 'default'

Environment

Operating System: Windows_NT
Node Version:     v18.16.1
Nuxt Version:     3.7.4
CLI Version:      3.9.0
Nitro Version:    2.6.3
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      devtools
Runtime Modules:  -
Build Modules:    -

Reproduction
fresh install
Describe the bug
I started  a new project:
npx nuxi@latest init my-project
then cd my-project
and yarn dev
the first thing i got is this error
Additional context
No response
Logs
[7:10:59 PM]  ERROR  Cannot start nuxt:  The requested module 'vite-plugin-inspect' does not provide an export named 'default'

  import Inspect from 'vite-plugin-inspect';
  ^^^^^^^
  SyntaxError: The requested module 'vite-plugin-inspect' does not provide an export named 'default'
  at ModuleJob._instantiate (node:internal/modules/esm/module_job:124:21)
  at async ModuleJob.run (node:internal/modules/esm/module_job:190:5)

I am experiencing this as well.

Same with node 18.18.0 and yarn 3.6.3

It looks like the exports were changed in v0.7.39 release of vite-plugin-inspect, if you're using pnpm you can temporarily override this with the following in your package.json:
  "pnpm": {
    "overrides": {
      "vite-plugin-inspect": "0.7.38"
    }
  }

I'm having the same problem today. Tried and retried and get the same result.

This is worked with yarn
"resolutions": {
    "vite-plugin-inspect": "0.7.38"
  }

Not an optimal solution, but as a workaround if you are using a package manager like bun which doesn't support overrides yet. You can disable nuxt devtools until this is fixed.

If you are using npm, you may use:
  "overrides": {
    "vite-plugin-inspect": "0.7.38"
  }

cc: @antfu

As @wheatjs said, the only fix for me was to delete   devtools: { enabled: true }, from nuxt.config.ts

As @wheatjs said, the only fix for me was to delete  devtools: { enabled: true }, from nuxt.config.ts

Same here, by removing this line of code, the project then launched correctly.

As @wheatjs said, the only fix for me was to delete  devtools: { enabled: true }, from nuxt.config.ts

Same here, by removing this line of code, the project then launched correctly.

I just changed enabled to false and it worked.

It should be fixed in the latest version. Sorry for the trouble.


Microk8s 266 on [Multipass|VBox] 10.1-full-56 on Mac not launching pods properly

I start with the following commands, after which it seems that the pods stay in PENDING. This is on a Mac - macos mojave version 10.14.1. I wonder if it is reproducible on a different host os? I even try running other pods, like nginx, and no luck. On another run, using cached snaps, I saw that several of the pods made it to RUNNING, but were then evicted and remained in PENDING. I print that out after this block:
==> multipass launch -n fred bionic
==> multipass shell fred
~$ sudo snap install microk8s --classic
~$ sudo snap install kubectl --classic
~$ export KUBECONFIG=/snap/microk8s/current/client.config
~$ microk8s.enable dns dashboard
~$ kubectl get pod -n kube-system
NAME                                              READY   STATUS    RESTARTS   AGE
heapster-v1.5.2-74f7978789-j5mnc                  0/4     Pending   0          65s
kube-dns-67b548dcff-zjqs6                         0/3     Pending   0          71s
kubernetes-dashboard-67d4c89764-dtq84             0/1     Pending   0          65s
monitoring-influxdb-grafana-v4-8467db6558-x55p4   0/2     Pending   0          65s
Here's a print out from a run where pods were evicted:
NAME                                              READY   STATUS    RESTARTS   AGE
heapster-v1.5.2-6595b788df-fbbq6                  0/4     Pending   0          11m
kube-dns-67b548dcff-8vngd                         0/3     Pending   0          11m
kube-dns-67b548dcff-mrxh9                         0/3     Evicted   0          12m
kubernetes-dashboard-67d4c89764-g779z             0/1     Evicted   0          12m
kubernetes-dashboard-67d4c89764-zs55n             0/1     Pending   0          11m
monitoring-influxdb-grafana-v4-8467db6558-8gq6l   0/2     Pending   0          12m
Version Information:
=> multipass version
multipass  2018.10.1-full-56-g9ff5e89
multipassd 2018.10.1-full-56-g9ff5e89
=> snap list
Name      Version    Rev   Tracking  Publisher   Notes
core      16-2.35.5  5742  stable    canonical✓  core
kubectl   1.12.2     585   stable    canonical✓  classic
microk8s  v1.12.2    266   stable    canonical✓  classic
=> lsb_release -a
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.1 LTS
Release:	18.04
Codename:	bionic

I've tried this with vagrant/virtualbox and 18.04 .. no luck .. same issue .. the pods stay in pending.

I've also tried 16.04 / xenial on both multipass, vagrant .. no luck.

Turns out the issue was an out of memory issue :(.

Hi @carmine ,
Here is what you can do:

Check you have a "Ready" node:

kubectl get no

Check that the node has no disk or memory presure:

kubectl describe no

I just tried starting a multipass machine  and got a VM with 1GB of ram:
> free -m
              total        used        free      shared  buff/cache   available
Mem:            985         448          86           0         450         387
Swap:             0           0           0

For this reason kubectl describe no was reporting MemoryPressure   True    ...   KubeletHasInsufficientMemory   kubelet has insufficient memory available
Something else you should be aware of is that we set the eviction policy in the kubelet arguments (https://github.com/ubuntu/microk8s/blob/master/microk8s-resources/default-args/kubelet#L13).
Thanks

Thanks for additional info, that is really helpful, particularly regading the eviction policy. I'll reopen the issue, as I think the the hard eviction limit seems to be too high ..
--eviction-hard="memory.available<500Mi,nodefs.available<1Gi,imagefs.available<1Gi"
The default, according to https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#eviction-policy, seems to be
memory.available<100Mi
I like that microk8s calls out the limit specifically, but any reason not to use the default of 100Mi? This is microk8s .. :-)

The rational was that on your working station 500MB is too few so microk8s would rather not degrade the overall UX. However I have no facts to back this so let's use the default 100MB and if we see we are taking too much heat we can reconsider.


Modal dialog to list users from Team names

Is your idea related to a problem? Please describe.
We have an internal change for which we would like to propose contribution in part.  Users would like to understand who is in the Teams, without having to access the separate roles based access system (Cognito or otherwise), for purposes of locating contacts for governors/stewards/owners/users of a dataset/share/env/org, so that they can contact individuals to ask questions or get support.
Describe the solution you'd like
The feature would turn various appearances of the Team names text throughout data.all, into clickable links that pop up a modal dialog showing the users in the Teams.
For default data.all this would use Cognito for looking up the users; for custom roles based access systems it would use that custom system (and need to be implemented by the admins of that data.all instance).
P.S. Don't attach files. Please, prefer add code snippets directly in the message body.

PR is available here:  https://github.com/data-dot-all/dataall/pull/1627
Since we don't have Cognito available to us, we could use some help with feedback and testing on the Cognito aspects of this change, if there is interest in accepting this contribution.

Closing as completed in #1627 - thanks for the contribution @rbernotas


In category modal: Category without label can be inserted

This should not be possible.

Looks fine, thx!


[fix] default handlers for head

see #3894
add default handling for HEAD requests. follow "get" handling but do not return body in the end.
custom head handlers in endpoint files are respected and take precedence over get.
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[x] Ideally, include a test that fails without this PR but passes with it.

Tests

[x] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

I just pushed a cosmetic change — the camelCased variables conflicted with the code style, and it was a bit of a wall-of-text, but it was tricky to do in a commit suggestion