@withoutboats tried writing some basic async code that worked with streams and futures and discovered that as the RFC is currently defined, one needs to write a few different macros depending on what one's trying to do and (awaiting a Future, waiting on a value from a Stream, injecting a Future into a Stream, etc.). Also, it is possible to make streams become an iterator over Polls, but this is less useful than having a real iterator over values. So @eddyb remarked that @Zoxc's idea to include a third "Suspend" variant for CoResult would be a very good API decision and make abstractions more reusable and composeable, as I have also shown above. With a Suspend variant (triggered with a yield; with no arguments) one can collapse all of the previous macros into a single await!. Most people have agreed on the following, and it appears in the RFC:
macro_rules! await {
    ($e:expr) => ({
        let mut future = $e;
        loop {
            match future.poll() {
                Ok(Async::Ready(r)) => break Ok(r),
                Ok(Async::NotReady) => yield,
                Err(e) => break Err(e.into()),
            }
        }
    })
}

Also, I made a recommendation that in order to make Streams amenable to for loop usage, we make a small change to the language: for loops that occur in an asynchronous context operate on either a Stream or an IntoIterator, and if they operate on a Stream, they suspend whenever a value is not available. On IRC @eddyb seemed to like the idea. The transformation I have proposed is two posts above.
If I have missed something please comment. There are a lot of posts in this thread and I wanted a good summary point before it's too late to read through all of it.

Phew. Ok. Now that the summary is out of the way... I think to get to what nrc called a minimal RFC, we should

figure out Relocate and interior borrows / disallowing moves, which will deserve its own RFC, or if it's worth moving forward with the restricted semantics as proposed in this RFC
Iterate more on a top-level syntax or decide if we can punt on that for another RFC.
Are there going to be coherence issues like nikomatsakis is worried about if we use a bunch of blanket impls?
Experiment more with a "Suspend" or "Wait" variant because we went from having multiple macros to needing only one + yield. The equivalent could be done by manually specifying an enum variant (Async already exists for this) and using CoResult as it is already defined, so is this worth the extra variant for convenience?
Decide we should infer that a closure is a coroutine through the use of yield or if an explicit keyword is going to be used, and what that keyword should be given that the keyword || { body } form as well as ||* { body } are both syntactically ambiguous.

The generator/stream/future-ready await/yield from etc. I proposed is this:
macro_rules! await {
    ($e:expr) => ({
        let mut g = $e;
        loop {
            match g.advance() {
                Yield::Value(x) => yield x,
                Yield::Suspend => yield,
                Yield::Return(x) => break x,
            }
        }
    })
}

For futures, yield x will be dead code with x: ! so it will always work regardless of the yielding type of the surrounding "coroutine" or whatever.

For futures,  yield x  will be dead code with  x: !  so it will always work regardless of the yielding type of the surrounding "coroutine" or whatever.

I don't understand what technically the Suspend variant would bring: you can always yield an enum that encodes subcases (for example the difference between producing a value in a stream or waiting for an asynchronous process to be ready inside the stream logic). Considering a "yield x" is meaningless for futures whereas a "yield" is meaningless/useless for generators it seems to me this proposition, while not  bringing additional expressivity, would force the user to deal with some semantically irrelevant cases. Am I missing something?

You're missing the fact that the exact same condtructs (like my macro above) would work in multiple situations, as opposed to needing half a dozen variations. It makes generators/streams and asynchronicity orthogonal. Besides, users are not expected to interact with that enum directly.

@krstoff

It was decided that coroutines should be allowed to move out of their environment. In this way, they're really not FnMut or FnOnce, so the trait should be distinct.

I... did not have this impression. The first part is true: internally, if a coroutine only runs "to the end" once, then it can move out of its environment, unlike an FnMut. But externally, @vadimcn's original logic is still completely valid: as the caller, I do not care at all whether the FnMut I'm calling was implemented using yield, or "manually" as a state machine. They are observationally equivalent. If it looks like an FnMut and quacks like an FnMut then it should implement FnMut. I think this aspect of the design is very elegant (along with, tbh, most of the other aspects), and I would be against tossing it.
(Given that coroutines which do not move out of their environment could potentially be "started from the beginning again" after reaching the end of their body (as I observed in an earlier comment), it may make sense to also have a parallel set of GeneratorMut/GeneratorOnce traits which capture this difference and provide that ability. I'm not sure if that really makes sense - I haven't tried figuring out what the traits would look like. But either way, this is not mutually exclusive with implementing FnMut, and should be in addition to it, not instead of it, if we do add it.)

If possible, it would be great if we could make iterator combinators become streams, e.g. turning a flat_map(f) over an iterator into a stream by having streams returned by f (perhaps even an inline async closure which yield's one or more values).

You're missing the fact that the exact same constructs (like my macro above) would work in multiple situations, as opposed to needing half a dozen variations.

The actual number of variations is to be checked but I personally believe the first reason we ended up with multiple macros is that we really need to choose between multiple possible behaviors in the same context. To be honest it's not very clear to me what is the range of cases your macro is expected to handle. Could you be a bit more explicit? (what are the possible types for $e? In which kind of flow this macro is expected to work and what is the expected behavior?)

That macros works for both await from an async fn or stream on another async fn and yield from in a generator/stream, on another generator/stream. If we add syntax for the latter and it has this expansion, it can work for all of those usecases. Furthermore, it allows generators and streams to be interchangeable.

Do we really need separate Return and Yield type params for generators instead of forcing the return type to be ()? This would simplify the generator syntax from something like fn* f() -> R yields Y {…} to fn* f() -> Y {…}.
I know that other languages allow both yielding and returning a value from a generator, but I've never had any use case for that. The only thing that I can think of was implementing async functions on top of generators in JS (where yielding a promise would await it and returning a value would resolve the promise that our async function returned) until native async functions came along.
Please excuse me if what I say doesn't make much sense. I'm looking at all this from an end-user perspective and I'm not very interested in internals.

Yes, because futures return their final value, while continuously yield (or suspend now, I suppose) (). As stated previously, we want to be able to use these for asynchronous code, which does return.
I think generators is maybe a bit of a misnomer because people have a very specific notion of what a generator is, while these are more generally suspendable functions.
@glaebhoerl You make an extremely good point. I think it would useful, for instance, if I can map a coroutine over an iterator, which would be possible if (some!) coroutines automatically implemented FnMut.

@phaux
The return functionality is often used by async code internally.  Yielding values gets coopted to mean wait, and the result of the returned future is returned.
But you never see it because other languages hide it away for the most part, or specifically separate generators and async/await into two different concepts.
This proposal is not as friendly as it could be W.R.T. the end user perspective, but I think that in the long run it will just be clear what's going on from examples in documentation.  It's not that different from Python, for example.  It's just choosing to rely on library macros instead of language keywords.

The issue with async streams, as I see it, is that such a coroutine wants to be both async and a generator at the same time, which requires two kinds of yield: "not ready yet" and "here's the next value".

@eddyb's approach of introducing special syntax for the former would work fine, of course.   My reservation about it is that this essentially tailors a language feature to the specific library, which isn't even a part of std.  The futures-rs way is not the only way to implement futures.  For example, if our futures were boxed, or if we had self-borrowing figured out, as I tried to demonstrate here, we probably wouldn't need this special "not ready" state.
If we decide* that futures-rs is the way to do async in Rust and it's worth customizing the language for the needs of this library, I would actually be in favor of introducing await as a first-class syntax (perhaps along the lines of what @Zoxc proposed).
[*] ESR will be delighted!

My personal preference would be to keep the language agnostic and explicitly model the two yield outcomes as an enum.
The downside of this, is, of course, that when when implementing an async stream generator, you'd have to write something like yield Ready(Ok(x)).
One possible way around that, might be to desugar yield x as return Yield(x.into()).  We could then
write yield Ok(x) and that would be automatically converted to StreamPoll::Ready(x).
enum StreamPoll<T,E> {
    Ready(T),
    NotReady,
    Err(E)
}

impl<T,E> From<Result<T,E>> for StreamPoll<T,E> {
    fn from(x: Result<T,E>) -> Self {
        match x {
            Ok(v) => StreamPoll::Ready(v),
            Err(e) => StreamPoll::Err(e)
        }
    }
}

Another way is to have a yield_fut! macro, like @withoutboats proposed.

I think yield fut is best implemented as some sort of yield from operation (from is not a reserved word, another issue), with an overloadable operator along these lines:
trait Yielding {
    type Yields;
    fn yielding(self) -> Option<(Self::Yields, Option<Self>)>;
}

yield from foo;
// desugars to:
let mut secret = $foo;
loop {
    if let Some((yields, continuation)) = secret.yielding() {
        yield yields;
        if let Some(yielding) = continuation {
            secret = yielding;
            continue
        }
    }
    break
}

This can handle yielding from iterators in iter generators, and from futures and streams in stream generators. It does not solve the use cases of await!, including await!ing in stream generators.
I don't really think that yield from and await should be subsumed into a single construct.

@vadimcn, unfortunately, if you desugar into .into() calls, you could run into issues where something is too polymorphic, and more importantly now every type that you want to Yield has to implement Into, which if you don't standardize Target, you have to implement Into n times for n libraries. Also, as you mentioned, we still have the await! problem. eddyb's solution covers (as far as I can tell) all or most use-cases, simplifies the syntax, and provides us with an await macro right from the start.

@jan-hudec

The next continuation would be receiving both the object, by move, and the borrow and that would still need special treatment.

Hmm... I see... This may be a special case, but I think that problem disappears if all types Copy because then you don't need the barrow, if I understand correctly... On the other hand, I think this would disallow a lot of useful types that are not Copy.

It is not directly compatible though, because yield would be returning the continuation while await would have to be passing it into a call

I believe there was (and still exists) a suggestion that we should be able to pass in different parameters to different executions of a coroutine, and that could be useful for passing a continuation to be included or called from next.

and with the generalisation that each await in an async function can produce continuation of different type.

It does seem like, more or less, this can be accomplished by returning variants of a custom enum, right?

These two cases could be unified by creating a yield block in which the continuation would be available and for the plain yield case the continuation would be returned while for the await case it would be used as callback (via Future::and_then to avoid tweaking argument list in the macro).

You lost me here... Could you give an example?

a yield |cont| _expr(cont)_ would move the variables needed beyond that point to a new closure bound to thecont` expression.

IIUC, this is close to what I was imagining. But this suffers from the self-barrowing problem because it needs to move variables potentially many times.
@krstoff
Thanks for the much-needed summary post!

I don't think that pattern is going to work because the current RFC is not designed to rewrite things in a continuation passing style. That would be a significant departure from the transformation proposed here, which has the advantage of having a largely successful prototype written by erickt's stateful. Also, I don't expect secret = yielding; to work because I wouldn't expect the continuation to have the same type as the prior code.

The variable name continuation may have made that code confusing but I am quite confident that desugaring works. With the exception of the yield statement it compiles today: https://is.gd/ovYe6N
I think you must have misread it. The idea was that inside a generator, a yield from EXPR statement would be desugared to this loop / yield operation, and Yielding would be implemented by iterators, futures, streams, etc.

I didn't misread, but I also didn't think about it hard enough. :) Well, I misread and didn't see the Self, so they're definitely the same type. This won't work for immovable coroutines, though.

@krstoff I may have misunderstood the rules about what is allowed across yield points, but I don't believe there are any internal references across yield points (indeed, there are no references AFAICT - everything is passed by value).

In this RFC, no, but @tomaka and others have pointed out that most async code that is useful does and nrc wants the borrowing issues resolved in the long term. Any decisions we make now shouldn't hamper future expansions.

If we tweak await!() to return Async::NotReady instead of (), it works inside async stream generators quite nicely.

I really like the idea of using yield in the return type to declare a coroutine.
IIUC, a coroutine like:
pub fn infinite(start: i32) -> () yield i32 {
  let mut x = start;
  loop {
    yield x;
    x += 1;
  }
}

Will be translated to something similar to:
pub enum Coroutine000001 {
  State0(i32)
}

impl ::std::coroutine::Coroutine for Coroutine000001 {
  type Output = ::std::coroutine::Output<Return = (), Yield = i32>

  fn next(&mut self) -> Self::Output {
    match *self {
      Coroutine000001::State0(x) {
        *self = Coroutine000001::State0(x + 1)
        Self::Output::Yield(x)
      }
    }
  }
}

pub fn infinite(start: i32) -> Coroutine000001 {
  Coroutine000001::State0(start)
}

The return type of the coroutine can be omitted if it is ()
pub fn infinite(start: i32) -> yield i32 {
  ...
}

Many people are worried about closures being implicitly coroutines in the presence of yield (which also implicitly changes the type of return) and prefer an explicit keyword. Also, anything that looks like keyword || { body } is ambiguous because || already represents the or operator.

I guess that with yield in the return type, the ambiguity is fixed, right?
For example
|| -> yield i32 { yield 0 };

I guess that with yield in the return type, the ambiguity is fixed, right?

I don't think it is since in Rust, you could elide the return type of a closure. So this code should be equally valid:
|| { yield 0 }

Right?

I don't think it is since in Rust, you could elide the return type of a closure. So this code should be equally valid:
|| { yield 0 }

It is still possible to make the yield keyword always required for coroutine closures. The actual types can be elided, as regular closures.
|| -> yield { yield 0 }

Would be
|| -> () yield i32 { yield 0 }

So what exactly is this R yield Y thing?   Is it just an alias for CoResult<Y,R>?
If no, wouldn't it be strange that it appears as CoResult<Y,R> in every other context?
If yes, then would it be valid in every other type context, including patterns?  How would you refer to constituent variants of the enum?   Would they still be called Yield and Return?
Does it bother anyone that the order of operations in R yield Y is reversed?  (i.e. a coroutine first yields, then returns).

My understanding is that R yield Y is syntactic sugar for CoResult<Y,R>. So the clause R yield Y is a type, and I think it should be valid elsewhere, if that does not introduce new ambiguities...

Does it bother anyone that the order of operations in R yield Y is reversed? (i.e. a coroutine first yields, then returns).

We could make it yield Y -> R
fn foo() yield Y -> R { ... }

|| yield Y -> R { ... }

But it seems like this could actually be ambiguous in some cases... at least, it is using the obvious syntax...
|| yield {...}

So what exactly is this R yield Y thing?

Many people think that coroutines should be declared explicitly, instead of relying on the presence of the yield keyword in the body of the function (like Python).
There are some proposals (this is not an extensive summary; please, see the comments in the thread for more details):

Using an attribute:

https://github.com/rust-lang/rfcs/pull/1823#issuecomment-268187406

#[gen]
fn foo() -> impl Iterator<Item=i32> { yield 1; }
#[async]
fn foo() -> impl Future { let x = await(future)?; ...

https://github.com/rust-lang/rfcs/pull/1823#issuecomment-269122013

#[coro] || { ... }
#[coro] move || { ... }
#[coro] fn() -> T { ... }
#[async] fn() -> T { await!(); }

Using a new keyword, like coro, co, yielding, or gen:

You can see many examples if you find the text coro || and coro fn in this thread.
I think that this is the least feasible option, since:

coro is not a reserved keyword, so it can break existing code.
An expression like coro || { ... } is ambiguous.

Using a sigil, like *:

In https://github.com/rust-lang/rfcs/pull/1823#issuecomment-269031702 , they proposed ||* for closures:

// Maybe ambiguous with deref syntax?
*|| { ... }

// I think this has no ambiguity issues, and therefore is most
// promising, but I'm no expert...
||* { ... }

In https://github.com/rust-lang/rfcs/pull/1823#issuecomment-271176021 they proposed fn* for regular functions:

fn* count(n: usize) -> yield<usize, ()> {
    let mut i = 0;
    while i < n {
        yield i;
        i += 1;
    }
    return;
}

Using yield in the type of the function/closure.

AFAIU, yield is not only an alias for CoResult. It can be a way to declare explicitly that the function/closure is a coroutine.

We could make it yield Y -> R

IMHO, I think that -> R yield Y is easier to read. For example:

fn x() -> T { ... }: function x returns a T object.
fn y() -> T yield u8 { ... }: function y returns a T and yields u8 values.

The “best” syntax is something very subjective.

Well, those are a lot of comments. So here's what my intention was:

-> T "returns T"
yield U "yields U"
-> T yield U "returns T after yielding U"
that is, they're both optional, and the presence of the yield changes the fn to a generator
no, there wouldn't be any CoResult except maybe as some kind of implementation detail

you can't write T yield U elsewhere, it's rather "just another return type arrow"

then again, I wouldn't implement generators through the Fn traits anyway so that's irrelevant

Why do we want an explicit keyword to mark coroutines? I didn't find an adequate explanation in the thread above.
The examples above that mix closures and coroutines are not convincing as the solution ought to be:
fn once<T>(value: T) -> impl Iterator<Item = T> {
  move || {
    yield value;
    return ();
  }
}

fn empty<T>() -> impl Iterator<Item = T> {
  || -> impl Generator {
    return ();
  }

In other words, the correct way to be extra explicit is by using the type system and just specify a return type. The trait(s?) can be marked as a language item and as such special to the compiler then we won't need to rely on the presence of the yield keyword.
On the other hand, I also don't understand why yield-less coroutines should be allowed anyway? That just added overheads with no apparent benefit and so just relying on the presence of "yield" does make sense.

Originally, coroutines were just going to be syntactic sugar over closures with a special return type... In this case, it could be confusing that what seem like a normal closure would actually have some CoResult type that the user never explicitly used. This also explains why it is possible to have a "yield-less coroutine": it's possible to declare a closure of that type; i.e. it is mostly for consistency. Rather, if the co-routine-ness of the closure is declared explicitly, it would be less confusing.

In other words, the correct way to be extra explicit is by using the type system and just specify a return type.

I agree, and that is why I had construed the R yield Y syntax as a type... but it seems that others in the thread had different intentions.

@yigal100 @mark-i-m Any solution which can confuse a function returning a generator created elsewhere with a function that is the generator it's returning if there are no yields is suboptimal.

@eddyb I agree... I was just answering the question about the progression of this thread.

@eddyb I agree with you but this doesn't address my second question.
Coroutines are a generalization of functions - they are functions with additional suspension points. Hence a coroutine without those additional suspension points  is reduced back to a plain old function. So I still don't understand what benefit Rust gains by allowing this extraneous new state of a yield-less generator.
Another data point for this: C# has this redundancy and the compiler warns if the user puts an "async" modifier on a regular function without any "await"s inside.
I'd like a design such that a function with return type "Generator" is itself the generator iff it contains "yield"s in its body. Otherwise, it's a plain function returning an instance of the "Generator" type. This is also more efficient since the compiler doesn't need to perform redundant work for yield-less "coroutines".

@yigal100 We can't say that coroutines are a strict generalization of functions because coroutines don't have the same interface (e.g. they always return a CoResult of some kind). A coroutine that never suspends is different from a regular function/closure, just as Result<T, !> is different from T. Sure, they are morally equivalent, but they present a different interface.

@yigal100: You are right, a "yield-less coroutine" is kinda useless, so nobody in their right mind would construct one by hand.  There is, however, a use case for them: if you are writing a macro that emits yield's based on some external input sequence, you'd be majorly annoyed if the degenerate case (the empty sequence = no yields) would cause an obscure type mismatch error in the generated code.
This is analogous to how Rust started allowing empty structs with braces, which would appear superfluous at first sight.

BTW, I wonder if we could use this hack in macros:
|| {
    ...
    return <whatever>;
    yield !;
}


Refactored HoloToolkit in submodules

HoloToolkit is now made of 6 different submodules:

CrossPlatform: utility scripts used to wrap Win32 and WinRT APIs in a single API call that works in Unity editor and in a UWP app
Input: for cursor input and eventually other input-related content
Sharing: networking and sharing components
SpatialMapping: includes spatial mapping and plane finding
SpatialSound: positional audio
-Utilities: generic scripts, prefabs and shaders useful for HoloLens development

Hi @maxouellet, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Max Ouellet). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

This is great, please make it happen!


Adding pressure conversion calculator

I would like to add pressure conversion calculator in unit convertor section.
Please assign this issue to me.

Go ahead
Deadline 4 April,2021 11:59 PM IST


Android hardware features are optional

Updates the documentation to match the code, which is to specify the camera and autofocus as optional features.

Good change :)


Enabling conditions on functions

Hi all,
There are many cases where we need to have conditions as output of the mappings, similar to what is described here.
These are just some of concrete use cases we have, but there are many more.

When a given field is empty, the triple is not created
When a field represent ranges we need to be able to create instances for each value in the given range, e.g., XYZ12,14, means that we need to obtain three instances, i.e., ex:XYZ12, ex:XYZ13, and ex:XYZ14
When a field contains strings that should be split into two properties given a specific pattern

Hi @igrangel, @bjdmeest has proposed the conditions in functions https://kg-construct.github.io/rml-fnml/spec/docs/#conditions. We can close this issue as it's complete, and if you have any comment you can open a new issue or a PR.


Httpcontext is null

Is this a Bug or Feature request?:
Help
Description of the problem:
Hi all
I need some help I have been working on a way to load a page from within the program.cs file but I can not work out how this is done I have look on the web to find the answer but for the life of me, I cannot find anything that will work.
What I'm looking to do is after a lookup I need to load the page again with an added searchstring, I have all the code doing the look up and cross-checking but I'm unable to get the code to redirect to the page again with the added searchstring.
I have tried to DI the Httpcontecxt but this keeps returning null.
any pointers would be great.
Version of Microsoft.AspNetCore.Mvc or Microsoft.AspNetCore.App or Microsoft.AspNetCore.All:
Microsoft.aspnetcore.app 2.1.0

Hi. It looks like this is a question about how to use ASP.NET Core. While we do our best to look through all the issues filed here, to get a faster response we suggest posting your questions to StackOverflow using the asp.net-core-mvc tag.

Hi @mattman73.
Did you get a solution to your question already? Assuming you've already posted it on StackOverflow, did you?

Hi. We're closing this issue as there's been no response and we have been unable to reproduce it. If you have more details and are encountering this issue please add a new reply and re-open the issue.

Hi I did post on StackOverflow but no one has come back with a fix or a better way to get the information from HttpContext as it always returns null.


Unit tests

This is a WIP PR for more unit tests. We want to test all classes separately:

[ ] Case
[ ] Component
[ ] BaseModel
[ ] AdditionalCode
[ ] InputDataset
[ ] Discretization
[ ] ...

I'm submitting this now as a draft because I want to see if CodeCov will comment on this PR (and update as more commits are pushed) to show us the change in coverage (before merging).

Seems like CodeCov is not commenting. The updated codecov.yml probably has to be in the main branch for this. Will submit and merge as separate PR.

@dafyddstephenson Sorry, I haven't gotten very far with this yet. I started testing the cstar/case.py module, and just started testing the ROMSBaseModel object (see latest push). Let me know if you would like to help writing some unit tests for any of the classes.

Closing this. Will open new PR to track this.


Added next page, prev page so it works correctly on public and

private timeline. And it no longer appears on the register or login pages.


feat: require organism_cell_type_ontology_term_id column + support zebrafish validation

Reason for Change

#1049
See schema definition here

Changes

add required organism_cell_type_ontology_term_id column in obs for all datasets
Value should be 'NA' for all organisms but zebrafish (for now)
added validation rules for when organism ontology term id is Zebrafish
update _validate_spatial_cell_type_ontology_term_id for dataset rows with visium assay--now, both cell_type AND organism_cell_type should be "unknown" if in_tissue is 0 and assay is Visium.
- Note: while not explicit in the schema, I chose to also validate 'na' as an accepted value for organism_cell_type in this case, as the schema says it must be 'na' when organism_ontology_term_id is an organism not listed in the 'organism_cell_type_ontology_term_id' definition (i.e. Human/Mouse).
- While we could query for (organism_cell_type_ontology_term_id == "unknown" ) or ("organism_cell_type_ontology_term_id==na" AND 'organism_ontology_term_id' is human/mouse/etc), There is separate validation that already ensures 'na' is only used in that scenario, so I didn't see a need to validate it again as part of this visium check. Let's double check with product + users if this makes sense before merging.

Testing

unit tests + some clean-up in TestZebrafish class
updated the example anndata fixture to have new column

Notes for Reviewer

update _validate_spatial_cell_type_ontology_term_id for dataset rows with visium assay--now, both cell_type AND organism_cell_type should be "unknown" if in_tissue is 0 and assay is Visium.

Note: while not explicit in the schema, I chose to also validate 'na' as an accepted value for organism_cell_type in this case, as the schema says it must be 'na' when organism_ontology_term_id is an organism not listed in the 'organism_cell_type_ontology_term_id' definition (i.e. Human/Mouse).

I should reorganize and clarify the schema.

If organism is not zebrafish or fly, then the value must be "na". Break.
If zebrafish or fly, then define the "unknown" cases.
The value should never be "na" for zebrafish or fly.

"unknown" is not equivalent to "na".

update _validate_spatial_cell_type_ontology_term_id for dataset rows with visium assay--now, both cell_type AND organism_cell_type should be "unknown" if in_tissue is 0 and assay is Visium.

Note: while not explicit in the schema, I chose to also validate 'na' as an accepted value for organism_cell_type in this case, as the schema says it must be 'na' when organism_ontology_term_id is an organism not listed in the 'organism_cell_type_ontology_term_id' definition (i.e. Human/Mouse).

I should reorganize and clarify the schema.

If organism is not zebrafish or fly, then the value must be "na". Break.
If zebrafish or fly, then define the "unknown" cases.
The value should never be "na" for zebrafish or fly.

"unknown" is not equivalent to "na".

Thanks for the clarified schema, Brian!
It looks like we're on the same page re: this change--if visium AND in_tissue is 0 AND zebrafish or fly --> organism_cell_type is "unknown"
if NOT zebrafish or fly --> organism_cell_type is "na", including when visium AND in_tissue is 0


Gaps Between Bars: An Unsightly Visual

Throughout development, I noticed that the bars that are sorted in the list show small gaps between them. It does not look bad for small lists, allowing us to see the differences between the bars.

However, with greater lists, the effects compound to form an ugly white band effect.

I do not like it. It has to go.

These are my thoughts on a possible solution:
The width and height of a canvas element are both measured in pixels, which cannot be decimal values. Using decimal values creates the rounding error that creates the unsightly gaps between the bars. Thus, it is necessary to distribute them into whole numbers, as even as possible.
If our canvas has a width of m pixels which must be distributed into n bars, then each part must get at least k = floor(m / n) pixels. The canvas will have r = m mod n pixels remaining to be distributed.  This way, we can achieve the most even split possible.
I cannot wait to try and implement this.

I should get to sleep, though... NAH!

And the results are, drumroll please:

AND...

No gaps. I declare this a success.

Captain's Log:
As I review previously completed work for approval, I test rigorously. The fix for the white gap problem has not entirely worked as expected. This is a rendered ascending list of 333 elements:

There is a quite pronounced slant at the end of the render.

Ooops. I didn't mean to post that. Yet. Anyway, this improvement is still lacking a perfect fix.


deals with variables changing in value or cell

variable with same name, different cell: the notebook scrolls to the previous cell and flag it in red for a few ms
variable with same name, same cell: the notebook marks all dependent cells as dirty using an orange background that will remain until reexecution of the cell

Before merging, just need a way to explicitly untag a cell if the user is sure the state is ok (if the variable that has been re-executed has the same value)

this seem to cause webbrowser freeze, and is of questionable usefullness. maybe simply revert it?

@andypetrella

this is really useful actually, it has been asked many times, especially for large notebooks. this kind of thing prevent the notebook to be easily converted into code and rerunning a cell is common and has impact on others that you might forget.
distracting the user is then done on purpose! works as designed the :D
if the browser freezes we need to fix that (I didn't experienced it yet)

Can we make it optional?


Support for release bundle permissions

Is your feature request related to a problem? Please describe.
It is not possible yet to configure release bundle permissions. The feature is really valuable for JFrog Distribution users.
Describe the solution you'd like
Release bundle permissions can be configured with release_bundle block of artifactory_permission_target resource. User can specify include/exclude name patterns, list of the storage repositoritories and actions.
In addition to common read/write/annotate/delete/manage permissions, it's possible to specify release bundle specific distribute permission.
Describe alternatives you've considered
It does not seem there is a comparable alternative.
Additional context

@alexhung - I am not sure if distribution would fall into a new provider or this one

@chb0github Excellent point! This should be a separate provider.

Let's create a new repo and at least move this issue there

May be it's still worth to keep release bundles permissions as part of this provider, taking in account, that they are managed via the same /artifactory/api/v2/security/permissions/{permissionTargetName}. It seems also natural to assume, that they are configurable together with the repos/builds permissions if one look at https://www.jfrog.com/confluence/display/JFROG/Security+Configuration+JSON#SecurityConfigurationJSON-application/vnd.org.jfrog.artifactory.security.PermissionTargetV2+json.
It's also quite convenient to have one permission target per user or group, so this permission target includes all required permissions for repos, builds and release bundles simultaneously. Moreover some of users prefer this approach, due to the issue with populating of perimssions caches (fixed recently). RTFACT-26382 describes the problem with edge visibility, but it affected an ability to manage release bundles as well.
An attempt to configure the same permission target via two different providers will likely result in races.
At the same time, destinations permissions of Distribution looks like a good candidate to be implemented in a dedicated provider for Distribution: https://www.jfrog.com/confluence/display/JFROG/Distribution+REST+API#DistributionRESTAPI-PERMISSIONMANAGEMENT.


Upgrade SSM

As per this forum post https://our.umbraco.com/packages/website-utilities/vendr/vendr-support/105894-order-summary-does-not-expand-mobile-view#comment-330249 it appears the Simple State Machine library version we are using might have stopped working. Upgrading appears to resolve their issue so we should probably test this.

Closing this issue as in the upcoming update, I've dropped the need of this library alltogether


No longer works after update to 12.0

I upgraded my version of the Julia client to 12.0 and I have no prompt in the terminal.

Have you tried this? It worked for me.
http://docs.junolab.org/latest/man/faq/#Juno-doesn't-work-properly-after-an-Atom-update.-What-do-I-do?-1

Thank you for the help, the link solved it. I had to uninstall and reinstall them.
-------- Original message --------From: hanjo-kim<EMAIL_ADDRESS>Date: 2/18/20  15:37  (GMT-05:00) To: JunoLab/atom-julia-client<EMAIL_ADDRESS>Cc: YorkerCoder<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [JunoLab/atom-julia-client] No longer works after update to 12.0 (#688) Have you tried this? It worked for me.
http://docs.junolab.org/latest/man/faq/#Juno-doesn't-work-properly-after-an-Atom-update.-What-do-I-do?-1
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/JunoLab/atom-julia-client/issues/688?email_source=notifications\u0026email_token=ALOGMKWU6VOMSVZJGJJLL53RDRBHPA5CNFSM4KW5ULRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMETJTI#issuecomment-587805901",
"url": "https://github.com/JunoLab/atom-julia-client/issues/688?email_source=notifications\u0026email_token=ALOGMKWU6VOMSVZJGJJLL53RDRBHPA5CNFSM4KW5ULRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMETJTI#issuecomment-587805901",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]

Thank you Hanjo-kim, I have the same problem and your solution work for me.


perkeep: 20170505 -> 0.10.1

Motivation for this change
Updating perkeep to the latest version
Things done

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

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

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

cc @cstrahan

@Mic92 PTAL.


gnome-remote-desktop: Enable VNC support

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

We have decided to not ship it as per upstream recommendations:
https://github.com/NixOS/nixpkgs/commit/e9282f5ab9f829576faa9cfa7f90f1c2d83b9f59
Unless something changed, I would recommend people who need it to enable it
locally with an overlay.
On Wed, 7 Feb 2024 at 03:27, Shea Levy @.***> wrote:

@shlevy https://github.com/shlevy requested your review on: #286867
https://github.com/NixOS/nixpkgs/pull/286867 gnome-remote-desktop:
Enable VNC support as a code owner.
—
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/286867#event-11726314905, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFMEY35UYW2HTBOGRPM2SLYSLQ7LAVCNFSM6AAAAABC5BC4I2VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRG4ZDMMZRGQ4TANI
.
You are receiving this because your review was requested.Message ID:
@.***>

@jtojnar How about the current patch, which will make the overlay easier to write? I understand if you'd rather close this.
The only "something" that's changed is that there is no good RDP client for the Apple Vision Pro yet :sweat_smile:  I can live with an ugly patch until MS gets their app updated though.


feature/get-all-customers

There are no test cases.

@AmruthPillai, precisely my point. But writing test cases for this shouldn't be too much of a pain, I guess.


Diagnose if multiple declarations are on the same line

Previously, we only diagnosed if two statements were on the same line. Do the same check for declarations now.

@swift-ci Please test


CI - Run tests on macOS

Context
Filing a separate issue, so this doesn't get lost in the comments.
Our tests only use Ubuntu now.
Value and/or benefit
macOS is tested automatically.
Anything else?
No response

Related:

https://github.com/conda-incubator/conda-store/issues/507
https://github.com/conda-incubator/conda-store/issues/71
https://github.com/conda-incubator/conda-store/issues/562

From today's meeting, we should have a helpful error message here. Also, as a sidenote, we should change the default port to something other than 5000 (because 5000 doesn't work on Mac machines).

From .github/workflows/tests.yaml:
# osx takes forever to get a scheduled job

Note: du calculation is wrong on macOS, see here https://github.com/conda-incubator/conda-store/pull/559/files#r1342122743

Already in progress at #550


fix: fullURI of alertmanager

AlertManager fullURI needs to use client.alertmanagerURI, not client.rulerURI.

LGTM


Adding test for recursive model dump issue fixed in pydantic-core

Adding test for https://github.com/pydantic/pydantic/issues/9015

Please review


Update to PyArrow 1.0.0

This release now promises stability of the binary serialization format:
https://arrow.apache.org/docs/format/Versioning.html
Unfortunately it breaks compatibility with the older version of PyArrow
we were using so that we can no longer read existing MatrixStore files
after we update -- hence the need to update the test fixture. This means
there will be some coordination required around deployment, with a build
of the latest data created in the new format ready to swap into place.
Note that while this version does have native scipy.sparse matrix
support which would in theory mean we could drop some of the custom code
in our serializer, in practice the performance isn't good enough for our
purposes (the profile test case jumps from 2.5s to 4.3s). The PyArrow
code makes the same mistake we initially did which is to allow the
horribly expensive scipy.sparse initialisation code to run
unnecessarily.
Closes #2751

The latest prescribing file has been rebuilt using the new format:
matrixstore_2020-05_2020-07-27--16-25_6bad2978c4a7b439.sqlite


MINIFICPP-1288 - FlowController start/load refactor

It is easiest to review this PR on a per-commit basis.
The FlowController methods: start, stop, load, unload (and maybe even waitUnload), were strongly coupled and were controlled through FlowController states that made it difficult to argue about what goes on in each of them.
load had two versions with only minor differences, one reload (with a few extra steps) and one non-reload. The version that did the reload was only called during applyConfiguration, so I moved the extra behaviour required there (and renamed the related functions accordingly to prove there were no other instances of calling reload).
load was also changing the state of initialized_ read by only itself and start, but it is easy to argue that load is never called twice and start is never called without a preceeding load, proving this variable clutter.

Since the requirement of "one has to call load before start" is not documented anywhere, I would restore the initialized_ variable to prevent invalid usage of FlowController.
I fell into this trap of only calling stop/start instead of stop,unload/load,start while working on #875

I see what you mean, but I disagree. I would definitely avoid adding states like this to an object. I found it already quite a task to decipher in what state can we reach each of the member functions. How about either of these options:

I can make the FlowController a state machine with well defined transitions between states
I can add checks to the start method that ensure that the members set in load are indeed set.

I see what you mean, but I disagree. I would definitely avoid adding states like this to an object. I found it already quite a task to decipher in what state can we reach each of the member functions. How about either of these options:
1. I can make the FlowController a state machine with well defined transitions between states
2. I can add checks to the start method that ensure that the members set in load are indeed set.

I don't really understand what you mean by making FlowController a state machine or checking members, but in either case, if you can make it hard or impossible to use FlowController incorrectly, that would be a big plus in my opinion.


Failed on master 8 days ago -- https://github.com/dask/dask/runs/623073459?check_suite_focus=true#step:6:196
Strange that in the original appveyor failures, it fails on the first assertion attempt
    def test_cov():
        x = np.arange(56).reshape((7, 8))
        d = da.from_array(x, chunks=(4, 4))

>       assert_eq(da.cov(d), np.cov(x))

But on both the github actions failures I can find it's later on:
    def test_cov():
        x = np.arange(56).reshape((7, 8))
        d = da.from_array(x, chunks=(4, 4))

        assert_eq(da.cov(d), np.cov(x))
        assert_eq(da.cov(d, rowvar=0), np.cov(x, rowvar=0))
        with pytest.warns(None):  # warning dof <= 0 for slice
            assert_eq(da.cov(d, ddof=10), np.cov(x, ddof=10))
>       assert_eq(da.cov(d, bias=1), np.cov(x, bias=1))

The error seems to come out of np.mean(np.empty(shape=(1,), dtype=a.dtype)) which is being used to infer the proper dtype for the dask array.  np.empty is usually filled with the first uninitialized value of the same type, e.g.
In [106]: np.array([6], dtype="int64")
Out[106]: array([6])

In [107]: np.empty(shape=(1,), dtype="int64")
Out[107]: array([6])

In [108]: np.array([8], dtype="int64")
Out[108]: array([8])

In [109]: np.empty(shape=(1,), dtype="int64")
Out[109]: array([8])

In [110]: np.array([float("nan")])
Out[110]: array([nan])

In [111]: np.empty(shape=(1,), dtype="float64")
Out[111]: array([nan])

Couple things are weird, though.  First, there is no int nan that I'm aware of, so it shouldn't be able to initialize an empty array with that value.  Second, numpy handles nans
In [113]: arr = np.empty(shape=(1,), dtype="float64")

In [114]: np.mean(arr)
Out[114]: nan

But it's might be worth trying to initialize an array of shape (1,) within the test body and see if that makes this weirdness go away.

 I'll go ahead and optimistically close this.


FIX: document error on master branch according to #839

see Issue: https://github.com/lhorie/mithril.js/issues/839

Thanks!


Rewrite entire parser

We're using pest for now and abandoning separation before the AST.
In the future I may experiment again, but for now this works.
Further stages beyond the AST are still planned.

bors: r+

bors: r+


feat(FX-3321): add debounce to onchangetext requests in improved search

The type of this PR is: Enhancement

This PR resolves FX-3321
Description
Add debounce to reduce requests
Before:
https://user-images.githubusercontent.com/21178754/133793806-109861ca-e173-41a8-bb6f-e5fb2f873e16.mov
After:
https://user-images.githubusercontent.com/21178754/133793900-ba882081-2066-464f-b084-68968a8beb43.mov

PR Checklist (tick all before merging)

[x] I have included screenshots or videos to illustrate my changes, or I have not changed anything that impacts the UI.
[x] I have tested my changes on iOS and Android.
[x] I have added tests for my changes, or my changes don't require testing, or I have included a link to a separate Jira ticket covering the tests.
[x] I have added a feature flag, or my changes don't require a feature flag. (How do I add one?)
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added an app state migration, or my changes do not require one. (What are migrations?)
[x] I have added a changelog entry below or my changes do not require one.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

add debounce to reduce requests on improved search - gkartalis

This PR contains the following changes:

Dev changes (add debounce to reduce requests on improved search - gkartalis)

  Generated by :no_entry_sign: dangerJS against 76276a020294f2906b8bb8312f2f42a072e4bd86

🎉🎉🎉

Hi again, while QAing the app today's morning I noticed that the UX in the search is slightly less convenient than it was although we are only debouncing with 400ms. It got me thinking that debouncing with such a high interval might not be a good idea so is also with a very small interval because that would just never be reached. I would like to reimplement this using throttling to make sure that the user can always tell that there is something happening every short interval. I can create a PR to do it and you can also do it (sorry for the inconvenience)

Hello @MounirDhahri! Good thought! What about pairing on this sometime today?

Yes, of course, I added some time on your calendar, please feel to reschedule if the time doesn't fit you


build two miniapps in a apk

Ask your Question

I need build two or more mini apps in a apk, and acces chunk local

Can you provide more information? Some example or repro project?

I published an issues with all the information of my projects. Issue #151 .
I need to build both projects in one apk/ipa

The problem in #151 is likely caused by duplicated react-native-reanimated dependency - you need to somehow (depends on your setup) ensure there's only single react-native-reanimated. If you're using Module Federation, react-native-reanimated must be added to shared in every container: https://github.com/zamotany/module-federation-repack/blob/main/host/webpack.config.js#L313-L318
For reference: https://github.com/zamotany/module-federation-repack/pull/4
If you need to have 2 or more miniapps, you need to alter the XCode/Gradle build step to copy additional miniapps or you could create a Webpack plugin or use https://github.com/webpack-contrib/copy-webpack-plugin to copy miniapps as part of the host Webpack compilation.
In Re.Pack 2, the easiest way to do so is to use process.env[CLI_OPTIONS_ENV_KEY] and take bundleOutput, similarly to have OutputPlugin does it: https://github.com/callstack/repack/blob/2.x/packages/repack/src/webpack/plugins/OutputPlugin.ts#L57-L77

Closing as the issue became stale, and answer was provided.


Add /save command to save chat history

This pull request adds a new command, /save, to the chat application. When the user inputs /save, the chat history is saved to the docs/chat_history.txt file. This feature allows users to easily save and review their chat history.
refer https://github.com/neokd/NeoGPT/issues/136

Don't save it to docs. Save it to current working directory and add time stamp to the file name

okay, lemme fix that

@neokd fixed.


[glad] Build error

Copy issue body from C:/Users/zwj/vcpkg/installed/vcpkg/issue_body.md
System: Microsoft Windows Version 10.0.19045.3393
error: building glad:x64-windows failed with: BUILD_FAILED
I am using the latest port files with git pull and vcpkg update.

See #30604 on how to submit a failed port compile

Despite using the latest vcpkg version I still failed to build vcpkg install glfw3 glad glm.

@Guest-615695028 Please provide the error log.

This issue hasn’t been updated for a long time; if it is still an issue, please reopen this issue.


Revert "Merge pull request #3466 from karronoli/fix-curl-options-arg"

This reverts questionable idea of allowing std.net.curl OPTIONS requests with non-empty body.
See #3466

I'd hate to merge this myslelf.. Anyone?

I don't use libcurl or D's interface to it. So I don't really understand what this was or why it was wrong. But a question to answer, did this get into 2.068? I can't remember the point at which 2.068 branched, and this was merged a while ago. I'm happy to merge if it didn't get into 2.068.

See: https://github.com/D-Programming-Language/phobos/commits/v2.068.0?page=1
I grepped for curl but none of recent fixes are in stable/2.068.
This basically added capability to add request data to OPTIONS request b/c standard syas soemthing along the lines of "MAY have content". Still nobody ever uses it. Then it turns out the patch wasn't complete and the author requested to roll it back.

Yep, looking at source, it seems the changes did not make it into 2.068. Thanks.

Auto-merge toggled on


Handle mmap exception more gracefully in RapidsShuffleServer

Signed-off-by: Alessandro Bellina<EMAIL_ADDRESS>Improves handling of a potential IOException when attempting to mmap in a system without resources, with many small shuffle blocks, or with low settings for vm.max_map_count. This is an improvement related to https://github.com/NVIDIA/spark-rapids/issues/3040, but it is not the full solution.
The root of the problem is that the spilled blocks can be many, and that each block is likely to get mmaped when read or transmitted. When we have many small blocks, the access pattern in RapidsShuffleServer can create issues as documented in https://github.com/NVIDIA/spark-rapids/issues/3040.
With this code, I can get q72 at 3TB to fail to mmap when there is a surge of requests, but reattempt the mmap successfully. Note that this doesn't prevent other parts of the system to fail when we are close to the OS limits.

Thanks @jlowe. I added a couple of commits that should address the review comments.

build


HTTP Error 403: Forbidden (caused by <HTTPError 403: Forbidden>);

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm reporting that yt-dlp is broken on a supported site
[X] I've verified that I'm running yt-dlp version 2023.10.13 (update instructions) or later (specify commit)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[X] I've read about sharing account credentials and I'm willing to share it if required

Region
France
Provide a description that is worded well enough to be understood
lunarsol@lunarsol-CG8270:~/Documents$ sudo ./yt-dlp_linux -u<EMAIL_ADDRESS>-p ***** -P "/home/lunarsol/Vidéos" -o "%(playlist)s/%(chapter_number)s - %(chapter)s/%(title)s.%(ext)s" "https://www.udemy.com/hacking-ethique-le-cours-complet/"
[udemy:course] Downloading login popup
ERROR: [udemy:course] hacking-ethique-le-cours-complet: Unable to download webpage: HTTP Error 403: Forbidden (caused by <HTTPError 403: Forbidden>); please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
lunarsol@lunarsol-CG8270:~/Documents$ yt-dlp_linux -U
yt-dlp_linux : commande introuvable
lunarsol@lunarsol-CG8270:~/Documents$ ./yt-dlp_linux -U
Available version<EMAIL_ADDRESS>Current version<EMAIL_ADDRESS>Current Build Hash: 6d30ea8e0f299a91c22161e87746162e3ff4d34df78a7f5dc00d51d02086f908
yt-dlp is up to date<EMAIL_ADDRESS>Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[ ] If using API, add 'verbose': True to YoutubeDL params instead
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
[debug] Command-line config: ['-vU']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>[b634ba742] (linux_exe)
[debug] Python 3.10.12 (CPython x86_64 64bit) - Linux-6.2.0-36-generic-x86_64-with-glibc2.35 (OpenSSL 3.1.3 19 Sep 2023, glibc 2.35)
[debug] exe versions: ffmpeg 4.4.2 (setts), ffprobe 4.4.2, rtmpdump 2.4
[debug] Optional libraries: Cryptodome-3.19.0, brotli-1.1.0, certifi-2023.07.22, mutagen-1.47.0, sqlite3-3.43.2, websockets-11.0.3
[debug] Proxy map: {}
[debug] Loaded 1890 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Available version<EMAIL_ADDRESS>Current version<EMAIL_ADDRESS>Current Build Hash: 6d30ea8e0f299a91c22161e87746162e3ff4d34df78a7f5dc00d51d02086f908
yt-dlp is up to date<EMAIL_ADDRESS>

Duplicate of #1164


Histogram widget functionality, vmin, vmap, etc.

Expanding on discussion from #555, wanted to outline a couple situations where the current Histogram widget functionality should be expanded.
(1) Fine-grained vmin/vmax control for each ImageWidget panel. Right now, via the ImageWidget constructor, you can specify a global vmin/vmax for all panels in the graphic, like this:
iw = ImageWidget(data, figure_kwargs={"shape":(3,1)}, graphic_kwargs={"vmin":1, "vmax":30}) iw.show()
This fixes every ImageGraphic to the same vmax/vmin. There are definitely many cases where we'd want to modify the vmax/vmin for different panels.
(2) In many cases we just want the adjustable contrast (i.e. the ability to use the Linear Selectors to toggle the vmin and vmax of each ImageGraphic) without actually computing a histogram.
(3) Ability to turn off histograms/scalebars for some panels but not others. For example in calcium imaging maybe I want to show colorbars for extracted sources (in grayscale). However it's less meaningful to do so for RGB, so I'd like to avoid that.
Here is one possible path forward:

In the ImageWidget constructor, replace histogram_widget (currently a True/False value) with a list where we specify for each dataset whether we include a histogram, what the vmin/vmax are, etc.

Rename HistogramLUT to ContrastLUT - it now functions more generally as an interactive colorbar. We can add to its constructor the option to include/exclude histogram calculation. As @kushalkolar mentioned in #555 if histogram calculation is disabled, the "histogram" is just constant across all bins.

HistogramLUT now has vmin/vmax options. If these are not provided, HistogramLUT continues to use the vmin/vmax from ImageGraphic.

(1) Fine-grained vmin/vmax control for each ImageWidget panel. Right now, via the ImageWidget constructor, you can specify a global vmin/vmax for all panels in the graphic, like this:
iw = ImageWidget(data, figure_kwargs={"shape":(3,1)}, graphic_kwargs={"vmin":1, "vmax":30}) iw.show()

Do you think this could become too many kwargs and lots of possible combinations to parse, what about setting them afterwards:
iw = ImageWidget(data)
for subplot in iw.figure:
  ig = subplot["image_widget_managed"]
  ig.vmin, ig.vmax = <pre determined vmin vmax>

(2) In many cases we just want the adjustable contrast ... without actually computing a histogram.
(3) Ability to turn off histograms/scalebars for some panels but not others.

Sounds good to me, @clewis7 what do you think?
What about:

ColorbarLUTTool: basically what we have now except for the histogram, also see #550
HistogramLUTTool, subclasses ColorbarLUTTool and just adds the histogram

In ImageWidget they can specify a kwarg like contrast_tool=["histogram", "colorbar", None], makes it easy to parse.


Reason mode cleanup and refactoring

Removed the remains of the rust mode origins
Moved the utop integration into reason-interaction.el
Indentation support moved into reason-indent
First JSX syntax support
Boolean constanst true/false highlighted as constants instead of keywords
Added missing keywords: external/mutable/where/open

I've updated as per your requests. Let me know if there's anything else.

Awesome thanks, will try it out and merge when ready, good job!


Clone this table: prompted me to login and then did not clone

Following the "clone this table" link from a public table of a user (great addition!) while not being logged prompted me to log. After logging in I was redirected to my own dashboard but I was not notified about what happened to the clone action I requested. Looking in my tables it doesn't appear like the table was cloned.

Closing since we are using one-click app for cloning :) -> https://github.com/CartoDB/cartodb/pull/3632#discussion_r30303075


Move REST API docs support to sphinx-scylladb-theme

Motivation
We generate API documentation for https://github.com/scylladb/scylla-cloud-doc using Redocly and a set of custom scripts. However, it would be useful for other projects to generate their own REST API documentation. To achieve this, we could consider moving the documentation generation logic to this project.
Considerations
As part of this effort, we might need to add npm support to the toolchain. See https://github.com/scylladb/scylla-cloud-doc/pull/113#issuecomment-1467700163

Reopening


-e option allocates memory aggressively

See https://github.com/greymd/teip/wiki/Memory-Usage-Benchmark
-e requires approx 3 times as much memory as the standard input.
It can be reduced more.
Let me note my brief idea.
One of the reasons why it allocates large mount of memory is standard input is taken "hard copy" in _tee_thread.
https://github.com/greymd/teip/blob/v2.0.0/src/main.rs#L294-L349
Instead of hard copy of text, the text can be possessed in a linked list or a ring buffer.
If so, _tee_thread will not need to pass text through channel, instead, pass the index numbers of buffer.
Then, Main thread and _ex_thread may have to refer to the shared mutex object which indicates the latest index. All the data stored on the indexes smaller than the latest one would be released then.

Put help wante label.
Currently, I do not have enough resources to address this issue.
Any PRs are welcome.


Fixed german translations

@BlueVirusX Thank you! I've manually merge this PR as this conflict with #128.


Add seek method for StreamLayerClient.

Resolves: OLPEDGE-1352
Signed-off-by: Kostiantyn Zvieriev<EMAIL_ADDRESS>

Well done. A few cleanups and we can merge the PR.

One more thing. We strive to have more elaborate commit messages.
Could you please update the commit's message with a few sentences on why we're adding the seek method?
Thanks.

One more thing. We strive to have more elaborate commit messages.
Could you please update the commit's message with a few sentences on why we're adding the seek method?
Thanks.

Github didn't update pull request description after changing commit message. Should be better now.

Sorry, missed one mistake during the pevious review.

@HalynaDumych, I'm not sure about that. The meaning of the original doc is not that the method returns requested offsets but that the offsets belong to the request. Correct me if I'm wrong, @kzvieriev.

Sorry, missed one mistake during the pevious review.

@HalynaDumych, I'm not sure about that. The meaning of the original doc is not that the method returns requested offsets but that the offsets belong to the request. Correct me if I'm wrong, @kzvieriev.

Hm, I see your point. So, I got it wrong. Would it be ok if we change it to "Gets the stream offsets of the request"? "Gets the request stream offsets" is also ok, but may be misunderstood.

Sorry, missed one mistake during the pevious review.

@HalynaDumych, I'm not sure about that. The meaning of the original doc is not that the method returns requested offsets but that the offsets belong to the request. Correct me if I'm wrong, @kzvieriev.

Hm, I see your point. So, I got it wrong. Would it be ok if we change it to "Gets the stream offsets of the request"? "Gets the request stream offsets" is also ok, but may be misunderstood.

"Gets the stream offsets of the request" sounds good. What do you think, Kostia?

Sorry, missed one mistake during the pevious review.

@HalynaDumych, I'm not sure about that. The meaning of the original doc is not that the method returns requested offsets but that the offsets belong to the request. Correct me if I'm wrong, @kzvieriev.

Hm, I see your point. So, I got it wrong. Would it be ok if we change it to "Gets the stream offsets of the request"? "Gets the request stream offsets" is also ok, but may be misunderstood.

"Gets the stream offsets of the request" sounds good. What do you think, Kostia?

Looks great for me.


Add support for Eufy bulbs and switches

Add support for driving bulbs and switches from the Eufy range.
Description:
This PR adds support for Eufy devices from Anker. It's currently limited to bulbs and switches, I don't have access to any vacuums. Documentation will follow later this evening.
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#5145
Example entry for configuration.yaml (if applicable):
eufy:
  username: testuser@domain
  password: p4ssw0rd

Checklist:

[x] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[x] New dependencies have been added to the REQUIREMENTS variable (example).
[x] New dependencies are only imported inside functions that use them (example).
[x] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[x] New files were added to .coveragerc.

If the code does not interact with devices:

[ ] Tests have been added to verify that the new code works.

Not sure what the best thing is with the travis failure - hs seems like the logical name.

I disabled the check. Should probably look into whitelisting that name for pylint.

Great work! 🎉 🐬

For (2), can you test the commit I just pushed to https://github.com/mjg59/home-assistant/tree/eufy?

For (1), could you attach the traceback?

Okay, sorry for taking so long, I'm running on an older model Raspberry Pi and am embarrassingly inexperienced with git.
I think the traceback I posted above probably doesn't actually correspond with the problem I described in (1).  Sorry about that!  This traceback should be more relevant:
2018-04-25 19:13:30 ERROR (MainThread) [homeassistant.components.light] Error while setting up platform eufy
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity_platform.py", line 129, in _async_setup_platform
SLOW_SETUP_MAX_WAIT, loop=hass.loop)
File "/usr/lib/python3.5/asyncio/tasks.py", line 400, in wait_for
return fut.result()
File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
raise self._exception
File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run
result = self.fn(*self.args, **self.kwargs)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/light/eufy.py", line 31, in setup_platform
add_devices([EufyLight(discovery_info)], True)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/light/eufy.py", line 59, in init
self._bulb.connect()
File "/srv/homeassistant/lib/python3.5/site-packages/lakeside/init.py", line 100, in connect
return device.connect(self)
File "/srv/homeassistant/lib/python3.5/site-packages/lakeside/init.py", line 55, in connect
self.s.connect((self.address, 55556))
OSError: [Errno 113] No route to host
As for (2), I like the behavior in your updated code considerably better...
I did however notice that -
(3) if I change the bulbs' state outside of Home Assistant, either using the EufyHome app or using a Google Assistant voice command, Home Assistant doesn't seem to pick up on the change...  (Or at least the Home Assistant UI doesn't reflect the change.)  If I change a bulb's state using the Home Assistant UI, the EufyHome app does pick up on the new state within a few seconds.

Please continue troubleshooting in an issue.


Unable to detect iBeacon format

Hello, I was trying the sample code to scan nearby beacons. My can detect altbeacon an eddystore, however on the library cannot detect ibeacon format. Can i ask if did i missed something? thanks
`
func getBeacons(_ completed: @escaping(_ list: [RNLBeacon]) -> ()){
    if let detectedBeacons = scanner?.trackedBeacons() as? [RNLBeacon] {
        self.detectedBeacon = detectedBeacons
        completed(detectedBeacons)
        for beacon in detectedBeacons {
            if (beacon.beaconTypeCode.intValue == 0xbeac) {
                // this is an AltBeacon
                NSLog("Detected AltBeacon id1: %@ id2: %@ id3: %@", beacon.id1, beacon.id2, beacon.id3)
            }
            else if (beacon.beaconTypeCode.intValue == 0x00 && beacon.serviceUuid.intValue == 0xFEAA) {
                // this is eddystone uid
                NSLog("Detected EDDYSTONE-UID with namespace %@ instance %@", beacon.id1, beacon.id2)
            }
            else if (beacon.beaconTypeCode.intValue == 0x10 && beacon.serviceUuid.intValue == 0xFEAA) {
                // this is eddystone url
                NSLog("Detected EDDYSTONE-URL with %@", RNLURLBeaconCompressor.urlString(fromEddystoneURLIdentifier: beacon.id1))
            }
            else {
                NSLog("Some other beacon detectd")
                // some other beacon type
            }
            NSLog("The beacon is about %.1f meters away", beacon.distance)
        }
    }

}

`

You cannot use this code to detect the iBeacon format, because Apple intentionally filters out iBeacon packets from the scans visible by CoreBluetooth APIs, and this code uses CoreBluetooth APIs to do the scanning.


Affiliations

The problem is that an affiliation is a link between an organization and a person, but does not "belong to" either. So it's awkward to model via instVars because the two sides have to be coordinated. I'd theoretically like to have links as first class objects, but where to put them? And how does either side "find" them. Maybe it's a first class object that holds onto both sides and the commands, like add/remove are on the link. That might not be too bad.

https://github.com/seandenigris/My-People/blob/master/src/MyPeople/MpAffiliation.class.st


[Playground][Task]: Removing the google storage client from python scripts

What needs to happen?
Removing the google storage client from python scripts and using the cloud datastore client
Issue Priority
Priority: 2
Issue Component
Component: beam-playground

.take-issue


plot spacing and axis label issues on exported images

With the new updates, the rnav.plot_qc() plots are not spaced properly and run into one another. Also, when saving images through the matplotlib savefig command, the axis labels are frequently cut off in the exported image despite displaying correctly in RNAvigate Jupyter notebook in the OnDemand portal.

Thanks Scott! I will try to fix this soonish (like sometime this Summer). I'll let you know here.
Quick fixes:

If you just need it for a Powerpoint, you can drag and drop the image directly from Jupyter into Powerpoint.
If you need it for a figure, you can load the svg into Illustrator. Even though the artboard cuts off the labels, the vectors should still be there in the margins. Select all, scale down the vectors, and it should all fit. Another known issue is that in inches units, the figures are very large, even for a poster. You should scale it down first, then copy into a poster or paper figure.

I've increased the size of the left margin so that everything fits. Thanks Scott!


Context Block: enter custom values

I noticed a different behaviour from other pythons in context blocks here :
class Test:
    def __enter__(self):
        return "custom"
    def __exit__(self, *argv):
        ...
with Test() as custom_as:
    assert(custom_as == "custom")
print(custom_as)

it seems "as" does not alias the return value of __enter__.

Okay.

No plan to change this behaviour. I'd recommend users to return self in __enter__.


The time of the archive header is different from the local time

Ludusavi version
v0.22.0
Operating system
Windows
Installation method
Standalone
Description
Ludusavi's time in the filename of the game archive doesn't match the local time when it autosaves the game and is 8 hours different, hopefully this will be fixed!

Logs
No response

Hi! The zip filenames use UTC (indicated by the "Z" suffix). That's intentional to ensure consistent ordering of the files, even when you change time zones or experience daylight saving shifts. You can use the "date modified" column for the local time :)


Merge-EM Tweaks

Clean some things up, demonstrate naming convention for cache fields in SFuncs.

That's fine - I expected .range was user facing as many tests/algorithms refer to it rather than .original_range, so it seemed the de-facto interface.
My intent with non-dunderscored parameters is that they minimally define the SFunc input output relation. It seems like deduplicated range serves that purpose better.


Update UnitaryGate import now that qiskit.extensions is deprecated

qiskit.extensions is deprecated starting with Qiskit 0.45, and the UnitaryGate class has moved to qiskit.circuit.library. However, this class did not exist at this location prior to Qiskit 0.45, so this means having to bump the minimum Qiskit version as well.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 92.498%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2984

Relevant Lines:
3226

💛  - Coveralls

If we merge this before the next release, it will allow us to knock out a few DeprecationWarnings at the cost of requiring a more recent qiskit (i.e., one released in November rather than August).  I don't think this is a huge down side, but there's also no urgency to merge this before the next release.  (We'll definitely have to merge it before CKT can work with Qiskit 1.0, however.)


Cleanup kernel discovery with tests

Codecov Report

Merging #12290 (965bf80) into main (68fd872) will increase coverage by 0%.
The diff coverage is 86%.

@@          Coverage Diff           @@
##            main   #12290   +/-   ##
======================================
  Coverage     69%      69%
======================================
  Files        501      501
  Lines      31909    31881   -28
  Branches    4999     4990    -9
======================================
- Hits       22234    22222   -12
+ Misses      7793     7779   -14
+ Partials    1882     1880    -2

Impacted Files
Coverage Δ

...aw/finder/contributedLocalKernelSpecFinder.node.ts
86% <ø> (+3%)
:arrow_up:

.../raw/finder/localKnownPathKernelSpecFinder.node.ts
81% <83%> (+8%)
:arrow_up:

...w/finder/interpreterKernelSpecFinderHelper.node.ts
60% <87%> (+2%)
:arrow_up:

...rnels/raw/finder/localKernelSpecFinderBase.node.ts
81% <100%> (+<1%)
:arrow_up:

.../notebooks/controllers/controllerDefaultService.ts
61% <0%> (-8%)
:arrow_down:

...otebooks/controllers/controllerPreferredService.ts
71% <0%> (-6%)
:arrow_down:

...andalone/intellisense/intellisenseProvider.node.ts
85% <0%> (-2%)
:arrow_down:

...c/platform/interpreter/interpreterPackages.node.ts
73% <0%> (-1%)
:arrow_down:

src/notebooks/debugger/debuggerVariables.ts
69% <0%> (-1%)
:arrow_down:

... and 8 more


Node orphaned and stuck after early deletion of Machine

For providers (like Metal3) without a cloud-provider, there is no cleanup of orphaned Nodes. The suggested fix is that we implement our own cleanup logic. It should simply check if there are Nodes without corresponding Machines or Metal3Machines and in that case delete the Node.
What steps did you take and what happened:
This is a bit tricky because it depends on timing. We accidentally stumbled across it because we made a mistake in our e2e tests. The gist is that we didn't wait for a Machine to become running before it was deleted as part of a change to the MachineDeployment (but the underlying infrastructure was provisioned).
It goes something like this:

Create a cluster
Create a MachineDeployment
Wait for the worker machine to be almost ready and then delete it in some way. (What we did was change the template so the MachineDeployment rolled the Machine.)
The Node had just time to join the cluster, but the Machine never got a NodeRef.
The Machine was deleted but the Node stuck.

What did you expect to happen:
The Node should be removed together with the Machine.
Anything else you would like to add:
See https://github.com/kubernetes-sigs/cluster-api/issues/7237 for more details.
/kind bug
/help

I am not sure we should handle this edge-case at the time of deletion or we should ask the controller to periodically check for orphaned nodes, but in any case this is a legit issue!
/triage accepted

I should mention also that in the CAPI issue they mentioned that this may be something they can adopt if it turns out to be general and useful for more providers. :slightly_smiling_face:

/remove-lifecycle stale
@lentzi90  have you seen this issue recently ? or have you heard anything from CAPI community related to this?

I have not seen it happen recently, but the issue is definitely still there. It is just rare that it happens. Specific "weird" use-cases could trigger it. From CAPI perspective they are interested in a solution to this, but since the issue does not exist for all (most?) providers they are not going to work on it for now. If we come up with a good solution they would potentially be interested in adopting it.
(Other providers may not have this issue since the cloud provider integration is basically solving it for them.)

/remove-lifecycle stale

/remove-lifecycle stale

/lifecycle frozen
No idea how to reproduce this if anyone have a reproduction please comment!

We observed the same issue recently.

For a guaranteed reproduction I think we would have to do something like pause CAPM3 or edit the code so it never adds the NodeRef


Generated target antipattern: misuse of ConsumeData

From https://llm-exp.oss-fuzz.com/Result-reports/scheduled/2024-08-31-weekly-all/sample/output-libtheora-th_comment_query/02.html
  // Generate fuzzed comments.
  for (int i = 0; i < tc.comments; ++i) {
    tc.comment_lengths[i] = fuzzed_data.ConsumeIntegralInRange<int>(1, 128);
    tc.user_comments[i] = (char *)malloc(tc.comment_lengths[i]);
    if (!tc.user_comments[i]) {
      continue;
    }
    fuzzed_data.ConsumeData(tc.user_comments[i], tc.comment_lengths[i]);
  }

    fuzzed_data.ConsumeData(tc.user_comments[i], tc.comment_lengths[i]);

is wrong, because ConsumeData doesn't guarantee it'll write tc.comment_lengths[i] bytes of data, leading to potential false positive OOB reads afterwards.
This should instead be:
    tc.comment_lengths[i] = fuzzed_data.ConsumeData(tc.user_comments[i], tc.comment_lengths[i]);

Is there some instruction we can give to prevent this misuse of FDP ? @DavidKorczynski @DonggeLiu

Similar issues: #301 and #164. We need to see if we can fix them now with our new models, otherwise we'll have way too many false positive crash reports.

Could we document this somewhere (e.g., a file in the repo/bucket)?
Then I can ask LLM agents to read the file.

We can probably base this on https://github.com/google/oss-fuzz-gen/blob/931da8970a1ca8a3f44cca332e2c27a43ff7a2bd/prompts/template_xml/cpp-specific-priming-filler.txt#L30 ? And add some more emphasis on avoiding these bad patterns.

It might also be worth considering have a separate "validator" agent that focuses on finding these bad patterns and fixing them.

It might also be worth considering have a separate "validator" agent that focuses on finding these documented bad patterns and fixing them.

An important point here is that the triage correctly labels this a "Bug" (bug here means bug in OFG), so our existing agent already get's it correct in that sense. We could try and get the triage_crash into our build/run loop in a similar fashion to fix_generated_fuzz_target and if triage_crash determines the harness to be erroneous then we ask it to fix it: https://github.com/google/oss-fuzz-gen/blob/43bf4db9534c49ef14eb34c970499c786a892aa2/experiment/evaluator.py#L386-L425


Implement and Test PointMass with Raytrace.

This may already work.  We need a test comparing raytrace to PointMassExact, including timing.

The test is implemented.  The lens model for raytrace must be debugged.

This requires #177 and others.  We need to try to get rid of the monolithic lens/simulator models

PointMass works approximately with Raytrace.  There are minor visible differences compared to PointMassExact, but no more than can be explained by numerical error.


spanmetrics dashboard premiere

Changes
Sample spanmetrics dashboard showing service and operational level throughputs and latencies.

Merge Requirements
For new features contributions please make sure you have completed the following
essential items:

[x] CHANGELOG.md updated to document new feature additions
[ ] Appropriate documentation updates in the docs

Maintainers will not merge until the above have been completed. If you're unsure
which docs need to be changed ping the
@open-telemetry/demo-approvers.

awesome!

Thanks for accepting it. With my pleasure! 🥳
Very soon, we will need to change the spanmetrics naming, namespace, and metric structure ... a breaking change is incoming.


Package import specifier "#app/entry" is not defined...

Hello - thank you for your work on this,
I just did a bare-bones install / hello world test to try things out but it errors on this line
Package import specifier "#app/entry" is not defined in package .../.pnpm/vitest-environment-nuxt@0.6.8_vitest<EMAIL_ADDRESS>------------------------------
- Operating System: `Darwin`
- Node Version:     `v18.14.0`
- Nuxt Version:     `3.2.3`
- Nitro Version:    `2.2.3`
- Package Manager<EMAIL_ADDRESS>- Builder:          `vite`
- User Config:      `debug`, `dev`, `devServer`, `modules`, `pinia`, `auth`, `runtimeConfig`, `css`, `app`
- Runtime Modules<EMAIL_ADDRESS>`<EMAIL_ADDRESS>`<EMAIL_ADDRESS>- Build Modules:    `-`
------------------------------

// vitest.config.ts

import { defineVitestConfig } from 'nuxt-vitest/config'

export default defineVitestConfig();

// my-test.test.ts

// @vitest-environment nuxt
import { test } from 'vitest'

test('my test', () => {
  expect('something').toBe('something else')
})

I ran into the same issue, when trying to set up a dev env of the repo as described in the README.
A workaround for me was to roll back to the previous version (0.6.7), install everything, run the preparation and upgrade to the latest version afterwards where I ran the same stuff again.

That issue seems resolved for me now when installing the most recent version.

I still have this issue with the latest version. Here is a minimal reproduction - just run npm run test. Any ideas on a workaround?
https://stackblitz.com/edit/github-yf4ytd?file=package.json

EDIT: found that the issue is only with nuxi test, it works fine when running vitest.

Confirmed for me too.
Happy to close - however I'd imagine it should work with nuxi test ?

The issue is that nuxi test invokes vite programmatically. I am not sure whether it respects the user's vitest config file. Feel free to raise an issue upstream at https://github.com/nuxt/nuxt.


Create test_diagnostic.py

Pull Request
Description
Adding tests for the FieldDiagnostic class in diagnostics.py
This pull request addresses #96

[ ] init

[ ] check_step

[ ] do_diagnostic

[ ] inspect_resource

[ ] print_diagnose

[ ] initialize

[ ] csv diagnose

[ ] finalize

[ ] make sure you are pulling from a dev branch on your fork

[ ] check for code linting

This is supposed to be a draft but I can't seem to change it.

Weird...I can't make it draft either.

I made it draft. There's something fishy going on with the UI. It didn't seem like it wanted to let me make it draft, but it did after waiting a few seconds.

I'm closing this and creating a new PR with the same contests because I messed something up with git. Whoops


Falcor npm version bump to pick up "use strict" fixes

There have been issues around leaked globals from falcor-path-syntax and function.name in falcor which prevents people from using falcor in a "use strict" environment.
I'm publishing a new version of<EMAIL_ADDRESS>which picks up these changes, so that<EMAIL_ADDRESS>should be usable with "Babel" and other environments which enforce "use strict".
Just issuing the PR for visibility, before I publish to npm, since there were a couple of modules which needed bumping, due to the falcor-paht-syntax bump.

falcor to 0.1.14
falcor-router to 0.2.11
falcor-json-graph to 01.1.7

Related threads:
https://github.com/Netflix/falcor/issues/586
https://github.com/Netflix/falcor-path-syntax/pull/25
https://github.com/Netflix/falcor-path-syntax/pull/21
https://github.com/Netflix/falcor/pull/597

Published. Let me know if you see anything out of whack.


Restore navigation stack on open

Is your feature request related to a problem? Please describe.
When opening an existing database, navigation starts at the top of the program (e.g. address 0)
Describe the solution you'd like
Navigation stack (previously visited functions) to be restored and current location to updated to last position. This navigation need not be synchronized to the server as different uses may have different areas they are working in.
Describe alternatives you've considered
This could possibly be incorporated as a plugin but I haven't explored the API or hooks for executing on close.

There is a 9.0.5 fix for the cursor portion of this ticket.
The history restore is still being investigated.


Updates

Now initialize all class attributes with None and removed usage of hasattr which simplifies and clarifies some code.
Improved handling of start_time, end_time, duration, and steps in manager.py which fixed a bug in which users couldn't input start_time and have the simulation run successfully.
simplified handling of horizontal_diffusivity in opendrift model.
user can change end_time, duration, and steps and have the others update accordingly. Tests added to check this.
changed known model "CIOFS_now" to "CIOFSOP" to avoid upper/lower issues and include "OP" for "operational".
many more tests and improved behavior for attribute checks and updates

I am going to merge this since it won't pass tests until a new version of opendrift is released.


Enable compression by default.

Compression structure changes and implementation have been tested. Compression end-to-end also tested in Perf environment. This change enable compression by default.  In case something goes wrong, it can be disabled by ambry-frontend-config entry

Codecov Report
Base: 73.01% // Head: 60.94% // Decreases project coverage by -12.06% :warning:

Coverage data is based on head (04469ff) compared to base (0c87a05).
Patch has no changes to coverable lines.

Additional details and impacted files
@@              Coverage Diff              @@
##             master    #2311       +/-   ##
=============================================
- Coverage     73.01%   60.94%   -12.07%
+ Complexity    10499     8550     -1949
=============================================
  Files           757      757
  Lines         58220    58220
  Branches       7150     7150
=============================================
- Hits          42507    35482     -7025
- Misses        13357    20371     +7014
- Partials       2356     2367       +11

Impacted Files
Coverage Δ

...ava/com/github/ambry/config/CompressionConfig.java
100.00% <ø> (ø)

...rc/main/java/com/github/ambry/store/TimeRange.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...java/com/github/ambry/notification/UpdateType.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...n/java/com/github/ambry/store/CostBenefitInfo.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...om/github/ambry/store/CompactAllPolicyFactory.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...thub/ambry/notification/BlobReplicaSourceType.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...github/ambry/store/CompactionPolicySwitchInfo.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...github/ambry/store/StatsBasedCompactionPolicy.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...hub/ambry/store/HybridCompactionPolicyFactory.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...ambry/store/StatsBasedCompactionPolicyFactory.java
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 185 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Complete recovery of the images ''optimized" by imgbot

Issue: ImgBot deleted several metadata files resulting in MASSIVE loading time of the images LUL
Future: Raise an issue with proper quantitative analysis on a custom repo.

all things are now in order.


Highlight past or future days

If you switch exactly a year in the past or the future the current day of month will also be highlighted.

Hey. Yes, that's actually intentional. If you don't like it, you can change it by passing day_id="%Y-%m-%d" to the constructor, see line 45.

You are right, thanks. I did not see that. -> nice solution


Fixed rare issue with components initialization

Found today problem with rendering simple DOM tree in browsers that doesn't support custom-elements natively (all except Google Chrome).
DOM tree example
<component1>

		<component2 id="id1">
			<content>
				Some content
			</content>
		</component2>

		<component2 id="id2">
			<content>
				Some content
			</content>
		</component2>

		<component2 id="id3">
			<content>
				Some content
			</content>
		</component2>

</component1>

Last <component2> node that was not initialized after appending to document. Problem was with MutationObserver shim that was not firing event on appending child nodes to section.some-class2.
I was trying to recreate issue in tests with simple DOM manipulations but with no luck. MutationObserver shim was working properly.
So here is a list of circumstances that could lead to this problem:

<component2> on attached callback moves some child nodes to component2.nextSibling. This behaviour is similar to  element that move inappropriate elements away.
Around 100+ components and subcomponents are rendering on the page at the same time.
Components' content renders with virtual-dom lib.
Changes to document are made in batches with using fastdom lib.

P.S. I will continue my attempts to reproduce this problem in tests. But for now i wasn't be able to do this

I guess my problem is related with this line of code that can lead to increasing elements length. Need to investigate... maybe there should be another fix...

If i am right the problem is in this line of code. Because MutationObserver callback is synchronously fired before cleaning lastBatchedRecord this could lead to adding other nodes exactly like in case i faced today. Native MutationObserver callbacks are fired at the "end of micro-task" (there is a good explanation in this article) and i am afraid can't be achieved properly with setTimeout. Only promises behave same way but that is not an option for browsers that does not have support for them.
Will make another fix tomorrow.

Yep, fully aware of microtasks etc. The only thing I could recommend trying is removing batching and setTimeout, but that'd have adverse affects on peformance most probably because batching helps to eliminate unnecessary opts iirc.

Do you think we'll need to do anything in master to fix this? I'm not really sure how to reproduce it so I can't really help you there. Also, the mutation observer polyfill has been split from the core in master. It's now over at https://github.com/skatejs/polyfill-mutation-observer.

Couple more questions:

Does this happen if you remove the virtual-dom and fastdom layers?
 Do you want me to hold off on merging this until then?
Since you said "will make another fix tomorrow", does that mean that this doesn't fix the issue?

I'm not overly concerned about it, but it'd be interesting to see if this affects IE performance.

I think what you're experiencing in not being able to reproduce it might be because of fastdom. I'm not certain, but in order to batch dom mutations it'd have to override internal methods. It's probably delaying those which would mean you're right int that it becomes out of sync. You might be able to reproduce it by delaying an appendChild.

Good morning. Yes i want to put this PR on hold until i finish my investigations. I hope i will complete them in 2-3 hours

I think the problem was not with fastdom but with rendering pipeline. I'll try to explain:

DOM tree in my example renders
Subcomponentes are created and they moved child nodes to siblings.
MutationObserver fires handler and shim starts to collect changes.
Because eTargetParent is similar to lastBatchedRecord.target (this) shim appends new nodes to already sent childNodes collection

I should notice that this problem take place because there were no other changes in DOM tree

Since you said "will make another fix tomorrow", does that mean that this doesn't fix the issue?

This PR fix my issue but it is more hack then proper fix. That is why I want to look into MutationObserver shim

Well... the problem is not with MutationObserver but with traversing through childNodes here. childNodes is live collection and i see only two way to handle this:

Freeze childNodes
Don't cache length

Second way is more performant then freezing.

Updated comment and i think this fix is the best from performance point of view. But always open to discuss other ways to fix this problem.

:+1: let me know when you're ok for this to be merged. Are you able to check to see if this needs fixing on master? I'm happy if you just spot the part in master that needs changing rather than trying to integrate master to where you're reproducing the issue.

Our QA team is still testing this fix. I'll post results here when they are done. Later will check master branch if it is need to be fixed ;)

Let me know when I can merge this :)

Our QA team gives green light to this fix. You can merge it ;)

Created issues for master and the mutation observer polyfill repo.

Checking master for possible changes right now. Going to create PR soon


chore(disc): unify duration settings and naming

Closes #483
use consistent naming:
timeout -> expiration
update docs, and tune default values, following geth.

Codecov Report

Merging #539 (90893a8) into main (3df8618) will decrease coverage by 0.01%.
The diff coverage is 35.48%.

@@            Coverage Diff             @@
##             main     #539      +/-   ##
==========================================
- Coverage   72.76%   72.74%   -0.02%
==========================================
  Files         243      243
  Lines       24704    24712       +8
==========================================
+ Hits        17975    17976       +1
- Misses       6729     6736       +7

Impacted Files
Coverage Δ

crates/net/discv4/src/lib.rs
51.61% <33.33%> (-0.10%)
:arrow_down:

crates/net/discv4/src/config.rs
57.82% <38.46%> (-1.05%)
:arrow_down:

crates/net/network/src/listener.rs
81.81% <0.00%> (-2.28%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.