[NF4] Add quantize_() API support for NF4

Background
When I was working on INT8 training stuff a while back, I realized there was no issue to make NF4 training work with quantize_() API (i.e. swap plain tensor with tensor subclass). This is because autograd+compile still works correctly for __torch_function__ (might not be the case in the past when NF4 was implemented) -> eliminate the need for custom nn.Module for downstream users as well as need for explicitly call to linear_nf4().
Usage
from torchao import quantize_
from torchao.dtypes.nf4 import nf4_weight_only

model = ...
quantize_(model, nf4_weight_only())  # works for both training and inference. NF4 weight is non-trainable

This would also compose nicely with LoRA, making QLoRA implementation more seamless. e.g.
from torch import nn
import torch.nn.functional as F

class LoRALinear(nn.Module):
    ...
    def forward(self, x):
        out = F.linear(x, self.weight)  # self.weight can be NF4Tensor
        out = out + self.lora_b(self.lora_a(x)) * (self.alpha / self.rank)
        return out

lora_layer = LoRALinear(...)
quantize_(lora_layer, nf4_weight_only())  # now this becomes QLoRA

This would be really neat.


Resume download after losing connection

After losing connection, all of my files which are downloading serially stop download, i also set retry download too, but it doesn't work

Please check the call-back of retry  in FileDownloadListener. If the first task still failed after tried, the first one will receive the call-back of error and the next one  will start download.

I tried it in FileDownloader Demo with just close the network connection of the device.

Can I set the time for every retry of download?

Yes, You can set connectTimeout(default 10s)、readTimeout(default 10s)、writeTimeout(default 10s)、 etc. Ref DemoApplication

could you please show me a way to set the time for every retry of download?

could you please show me a way to set the time for every retry of download?

Ref DemoApplication

when does the filedownloader service stop?

You have to stop the filedownloader service manually by invoke FileDownloader.getImpl().unBindService().

Sorry   I checked the demo application, but i really don't know how to set the interval time for every retry. I mean when i lose connection, the download continuously retry without waiting. I tried to let it sleep in the retry method of listener, but it doesn't work since it is in the main thread. Or how can i make the download process run in a separate thread?
I tried with this code,  but it is no use!
new Thread(new Runnable() {
public void run() {
token = CreateDownloadTask(url,path).ready();
FileDownloader.getImpl().start(listener, true);
}
}).start();

I know what you want now....
Sorry..... FileDownloader didn't provider any interface to support 'set the interval time for retry', it will retry immediately without waiting.
I know what you want, but FileDownloader downloads the file in the separate process, and in the current architecture, we can pause it, but can't block it in the UI process.

Maybe you can re-download manually in some seconds when receiving the call-back of error.

Ok, thanks!


Add ability in CollectSQLProfile.ps1 to read instances from a file

Fixes #163
Description
Allows for supplying a csv file of Host/Instance pairs to avoid calling the CollectSQLProfile.ps1 in a loop.
Related Issue
This project only accepts pull requests related to open issues.

If suggesting a new feature or change, please discuss it in an issue first.
If fixing a bug, there should be an issue describing it with steps to reproduce

https://github.com/rubrikinc/rubrik-scripts-for-powershell/issues/163
Motivation and Context
If there are dozens, hundreds or more instances, the command line may exceed the maximum number of characters allowed.  Using a csv file avoids this limit.
How Has This Been Tested?
Tested using 80+ instances on numerous on prem machines.
Types of changes
What types of changes does your code introduce? Put an x in all the boxes that apply:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:
Go over all the following points, and put an x in all the boxes that apply. If you're unsure about any of these, don't hesitate to ask. We're here to help!

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTION document.
[x] I have updated the CHANGELOG file accordingly for the version that this merge modifies.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Hello, Do you have an example of what the CSV file should look like? I want to update documentation as well before I push this through. The script already accepts a comma separated list of server instances


Check script fails if subcommands are not installed

Starting from a fresh dev environment, bootstrap/check script fails unless the following are installed:

cargo-count
cargo-outdated
cargo-deps
cargo-audit
sass

It also requires the nightly toolchain.

Thanks for noticing that, I should have tested with a new machine. the check call has been removed from bootstrap, and comments have been added to call out cargo dependencies and the requirement for nightly. Thanks for logging this!


gradient="to-r from-yellow-400 via-red-500 to-pink-500"  none-effect

The syntax is
bg-gradient-to-r from-yellow-400 via-red-500 to-pink-500
https://unocss.antfu.me/?html=DwEwlgbgBALgpgDxgWgKwIDa0SgxnAO3gCcoAHAFnICMAOAKCiaeoHNlXiBDcQlGAPbJSAM2ICAtsgCecDBgEB3ZBQAMqqBDBdhcEGnWwhZMAQDWB1fQB8jKAFcCA3AGcX9YAHpwEW0A

I think it makes sense to support the optional prefix for from, via, to to make this usage works. Just like how we did with flex="gap-2" and grid="gap-2"


Revert back to Expo Go from Ignite v10 CNG

Describe your recipe idea
With Ignite v10 moving to Expo CNG as default and introducing some new dependencies that at not Expo Go compatible, this recipe will help others move back towards Expo Go compatibility. This issue is a work in progress since v10 is not finalized but can be monitored here: https://github.com/infinitered/ignite/milestone/20

[ ] package.json start scripts
[ ] remove MMKV, put back async storage
[ ] remove keyboard controller, utilize KeyboardAvoidingView

Closed by #180


iOS 17 support

https://github.com/mobile-dev-inc/maestro/blob/e768b912ce3509bae85560d9d6871992487f3f6a/maestro-cli/src/main/java/maestro/cli/util/DeviceConfig.kt#L6-L10
This appears to imply 15 and 16 are supported.

Hi
Could please provide to latest iOS version support

This was implemented in https://github.com/mobile-dev-inc/maestro/pull/1569


Remove runOnStartup from timer binding and template

RunOnStartup has a problem where it will run every time that the function app gets loaded up due to other bindings (such as another function reading queue messages). This means that the function wont actually run according to the schedule. We need to remove it from the templates and the binding.json so that this option is disabled.

Yeah, TimerTrigger RunOnStartup is really intended for a long running host that doesn't restart often (as in classic WebJobs SDK scenarios). It's also useful for testing, which is why I think our templates inherited this from my initial samples.


Spread isn't properly checked

Bug Report
🔎 Search Terms
optional, spread
🕗 Version & Regression Information
4.2.3
⏯ Playground Link
https://www.typescriptlang.org/play?#code/KYDwDg9gTgLgBASwHY2FAZgQwMbDgQTDABsBPfJUgdwAs1gARTGTOAbwCg5u4ArCAEZMWAfgBc7AL4BuLj0gRiwzOKmyecTJVr0AyixgBXAM6q2Mud0xEyAFVJhgZixuOZimKKQCi4YNgMECCRTCXN1eQhjYwQBYmB9TxhhJwljGChkAHMIqxtSAAUoYHR6JFxQuHTMpBzLOCpMBBhsgrQggBNVJEMAWwE0XMRjCmDSXogTVQEIRWAtIcMYXrN6jQBtAGtgUkQkKozsgF1Vauyhlx5DKGJTw9qhjuZgAFUwJ9QuiR7+wfqP4AAYWKzy+cB+AygQ2KvH8LWCKW6fUhskkHA4oEgsD2qAwODwhBIu04GgQHTS9zqGhMaAAkuSDjUqTx0sAwBSmXAAD5wQxIDolZDADpDGgIJkAGWQmw52W5vP5gqQwqGyFxADcEMAqMowpJ5XyBeghSL6lpqHRirqCPkKBb6MoDYrjcrTRoAcD5p8kb8oRw0RxsMF0pp8hJCWQ4ABedhyMkSADkmGMHQTABp6jSoPTE8nUxnXKh2XAkyn0-UxZLpbmywWeGq0JrtdbDUrhXWrNpLYxmJgJAqjSaO3APSDPhIAEwAZgALNOZ-70RwAPTLuC+RwBYWafZoKDQODdwPB+DYLS4eIdCPkLsO3vh223q296Ox7gAOk-1iJGZkcCXq7cAAxAAjBIe4Ht2wxwEGUDFAEgbnsAl7XnaOjPiw75ZvSr4Jm4HToAmsgrmucBARO4FwZB9DQbB8EwMeISnkhKGPvaGGYGBNpEmh3aOjGJK8sYdIMgmvTABAVAJv60hwEAA
🙁 Actual behavior
TS doesn't throw error on incorrect spread (look into PG link)
🙂 Expected behavior
TS throws error on incorrect spread (look into PG link)

This is the intended behavior. Spreads are allowed to contribute excess properties.

Look: the same action in JS done in different ways treated by TS differently:

userId will appear here and IT IS OK

When I try to set userId explicitly TS errors:

Result in JS eventually is the same: userId will appear in canceledApplyAnywhereData which SHOULD NOT happen as such property is not declared in ApplyAnywhereData.

Object types in TS are unstrict:
declare const a: { x: number, y: boolean }
const b: { x: number } = a // Ok

Object literal types are checked strictly:
const b: { x: number } = {
  x: 5,
  y: true, // Error, we probably didn't mean to do this
}

This is dangerous.

This has and will continue to cause the very kinds of bugs that the typechecker should be preventing. I hope this can be reconsidered in the future considering how nice of a feature spread is yet has been effectively banned on my team for this behavior.


Fix nullness errors in TestPipeline

Since #31229 made me take a quick look at this code, I thought I would also eliminate the nullness errors. The code could really be simplified too. There is a whole class hierarchy just for one enforcement...

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[x] Update CHANGES.md with noteworthy changes.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

R: @shunping

PTAL. I kicked the tests until they were green.

LGTM! Thanks for improving the clarity of the code, @kennknowles !


Licensing clarification

Is there anyway the doc can clarify if the licensing is an add-on tenant license, or an add-on user license?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d1fa045c-9edd-2d50-8c55-25b5be8ec9c8
Version Independent ID: d1fa045c-9edd-2d50-8c55-25b5be8ec9c8
Content: Get Started with app governance
Content Source: CloudAppSecurityDocs/app-governance-get-started.md
Service: defender-for-cloud-apps
GitHub Login: @dcurwin
Microsoft Alias: dacurwin

Thanks for your question. We'll investigate and get back to you.

@mgowing - I just realized that while we updated the documentation months ago, we didn't inform you here. Sorry for the delay.


Madvoc 3->4: Body is empty for req.getReader() as well ass @In @Scope(BODY)

Current behavior
Sorry, to nag again :-/
After porting an Madvoc application from v3.x to 4.x it cannot read any PUT Body content. The originally, ported form was:
       @Action("/list/{id}") @PUT
	public JsonResult updateList(@In("id") String id) {
            return GroceryService.get().updateGroceryList(id,  request.getReader());
	}

I modified it to this form which does not help:
        @Action("/list/{id}") @PUT
	public JsonResult updateList(@In("id") String id, @In @Scope(BODY) String listJson) {
            return GroceryService.get().updateGroceryList(id,  new StringReader(listJson));
	}

I'm a little bit lost and hope I do not miss anything. Tested it with two web servers to sort out the issue thre.
Expected behavior
request.getReader() and/or  @In @Scope(BODY) String listJson should contain the actual request body text.
Steps to Reproduce the Problem
git clone --depth=3 --branch=master https://github.com/bentolor/microframeworks-showcase.git showcase
cd showcase
./gradlew :jodd:run

Then go to http://localhost:8080/, Click "Lists" in the left section, "Edit" in the List, Remove an item, press Save.
OR
Open Project with IDEA IntelliJ and Run "Jodd: Run Example".
OR
./gradlew :jodd:jettyRun

to use Jetty instead of Undertow.
Any ideas what I'm missing?

Ok, this one I need to check, it seems your using it correctly the @Scope. Sorry for the trouble, will be back soon.

ok, @bentolor here are the results! Sorry for waiting...

First, the String type issue. Currently how Madvoc idea behind the BODY scope is to parse the body into the target type. Since target type is String in your case, the parsing fails. So that explains the issue you are having.
I can fix that easily - when the target type is String, do not parse. The only edge case is when the body is really a JSON string like "string\u123" - that supports escaping and other things. In this edge case the string would not be parsed. I do not know how to distinguish this special case.
The idea behind BODY is to use the destination type right away - in your case, it would be the GroceryList. No need to parse for yourself! However, parsing fails at the moment since I didn't add the UUID JSON converter. I will add that immediately.

But wait! You can make it work now, like this:
public JsonResult updateList(
    @In("id") String id,
    @In @Scope(SERVLET) String requestBody)

why? because SERVLET scope contains set of reserved names that can be used for injecting various things. I have some documentation here but not a complete list of reserved names.
So to summarize my action points:

[ ] add UUID Json type converter

[ ] update doc to list all reserved names

[ ] should BODY scope only deal with JSON parsing? If not, how to distinguish between JSON strings and rawbody?

[ ] Should I add simple placeholders for all reserved names instead? For example:
@In @Scope(SERVLET) BodySupplier body

wdyt?

Hi @igr
thanks for having a look on my example so quickly.
I was aware that I can later on directly use a typed argument. But in the first step I wanted to stick with the plain text to be in control of the deserialization/serialization i.e. to configure the expected java.util.Date format.
As the ID is derived from the URL I'd also expect that Madvoc does not touch the Body unless advised and therefore request.getReader() still continues to work.

should BODY scope only deal with JSON parsing?

Your comment lets me a little bit in doubt: Is Scope.BODY directly tied to a JSON Datatype or specific data serialization mechanism? What If the Body i.e. contains XML-Content?
The whole statement comes a little puzzling to me, because I understood the Scope directive as a way to tell Jodd in which scope to look for or write to desired values, but not in which data format it will be stored there.
It's clear to me that Madvoc needs some form of data type conversion for @In and @Out. But I'm currently wondering where I can control it in general. And even more: if I can have different conversion rules for different areas (i.e. lets say I have two @InOut java.util.Date targets, but in the one case I expect 2018-01-01 and in the other place a full ISO Datetime 2018-01-01 11:12:33.
So here are a few counter questions

How can I configure the Data type conversion applied to  @In and @Out in genereal? (ie. XML or aspects of JSON format)
Can I override the applied conversion for specific places (as described above)?
Why did request.getReader() stop working though all other values are only from the URL? I'd expect it should continue to work.

Should I add simple placeholders for all reserved names instead?

To be honest, the whole concept of reserved name i a little new to me and I miss a section named "Reserved/Predefined injection names" or alike explaining in a short table what I get.
If I understand you correctly, depending on the scope I can use different, predefined names to access preexisting values in that Scope like:
 @In("request") @Scope(ScopeType.SERVLET)
 HttpServletRequest r;
 @In("body") @Scope(ScopeType.REQUEST)
 String b;

Am I right?
If yes, I'd vote for some form of XXXX.SERVLET_REQUEST and  XXXX.REQUEST_BODY or alike. Not sure what XXX should be. InjectionParameters.SERVLET_REQUEST ?

@bentolor you are right! Let's make it beautiful :)
Let's go over few topics we have here :)
[1] Existing injections and reserved names
Since REQUEST scope was meant for getting only the request query params and attributes, we have the SERVLET scope, that is used to retrieve many different things. Your last examples should be written like this (I'm writing this just for the sake of documentation):
@In("request") @Scope(SERVLET)
HttpServletRequest r;
@In("requestBody") @Scope(SERVLET)
String b;

The full list of reserved names is listed in ServletContextScopeInjector (yeah, I just forgot we have them :):
public static final String REQUEST_NAME = "request";
public static final String SESSION_NAME = "session";
public static final String CONTEXT_NAME = "context";
public static final String REQUEST_MAP = "requestMap";
public static final String REQUEST_PARAM_MAP = "requestParamMap";
public static final String REQUEST_BODY = "requestBody";
public static final String SESSION_MAP = "sessionMap";
public static final String CONTEXT_MAP = "contextMap";
public static final String CSRF_NAME = "csrfTokenValid";

I will change these names and remove the NAME suffix.
SERVLET scope is aware of the types, too - meaning, if you put a ServletReuest field you don't need to use above reserved name:
@In @Scope(SERVLET) HttpServletRequest request;

I believe this is a nice feature; just need to document it better :) Please let me know how this existing feature looks; personally, I find this very convenient. The only thing I am not happy with is where to put the definition of the names, currently, they are in ServletContextScopeInjector (where they are actually used); but this class is kind of 'internal' class, and users really do not need to be aware of it - for that reason it makes more sense to define it in the ScopeType.SERVLET as that class defines, as you correctly noticed, the source where the data comes from.
Wdyt?
[1.1] Replace reserved names with types
Instead of having reserved names (like above), we can simply replace them with the custom types. This way we don't have to wonder where to define them :)))
It would look like this:
@In
RequestBody b;
...
b.get(); // to retrieve the body.

Of course, each class would have NAME static fields, so the following would be ok:
@In(RequestBody.NAME)
RequestBody b;

wdyt?
[2] Simple conversion and mappings
Let me quickly answer how to make simple conversions for input/output parameters. Madvoc support annotating the setter methods:
Date date;
@In
void setDate(String dateString) {
    this.date = MyUtil.convert(dateString);
}

and/or you can simply annotate field, but if setter and/or getter exist, Madvoc will use them:
@In String foo;
void setFoo(String myFoo) {
    this.foo = MyUtil.convert(myFoo);
}

This is not so a feature of Madvoc but of our BeanUtil super bean class :) All type conversions are also set in BeanUtil; for example, I've added UUID converter there.
Users can use this feature to perform JSON/XML conversion as well:
GroceryList groceryList;
@In(requestBody) @Scope(SERVLET)
void setGroceries(String body) {
    this.groceryList = JSONParser.create().parse(body);
}

Not saying this is the solution, but I find this fine if it is used in few places.
[3] Finally, the source vs format :)
Excellent point! I agree. The scope should define the source.
How we can define the format? So far we are using @Action annotation to specify different behavior. For example:
@Action public void foo() {...}
@RestAction public void bar() {...}

These two actions have different behaviour - the mapping can be different, the results processing can be different... If we go in this direction, you would have e.g. @XMLAction that does different parsing.
But this approach makes things less 'visible', as the @In annotation may be set outside of the method - and now the same annotated field may be set differently depending of the action annotation, e.g.:
@In String body

@Action foo1()
@RawAction foo2()

For this reason I would not like this approach, but would like to specify the formatting on the field itself.
What would be the best way to do so?

@In(formater=MyFormatter.class) - nah, dont like so much
@DataType - i like this better! to have an annotation that actually defines which type of data it is, and then you can register your own data formatter. e.g. @DataType(JSON), @DataType(XML), @DataType(RAW). The annotation argument is a string so it is easy to extend. Byt I would like better name then Datatype - maybe ContentType, but this is not a real content type (exampe with two different date types).
?

So, let's define this! I would be happy to implement, as I have it on todo for some time.
(SORRY FOR LONG POST:)

Hi @igr
again – your time and positive energy, which is very appreciated!
I'm trying to be short:
[1] Existing injections and reserved names

Better documentation regarding reserved names would be a great improvement! Honestly I skipped "Context and Servlet scope" and did not understand its intention. It was too confusing for me. I would expect it more like

Injectable Servlet and Request properties
The Madvoc SERVLET scope allows you to access and use the following values which can be accessed by the following injection names.
|| Name || Constant |Type || Value ||
| request |  XXXX.REQUEST  | javax.servlet.HttpServletRequest | The … |
Hint: For HttpServletRequest, HttpSession, ServletContext you can ommit the name. Madvoc will autodetec on the type.
[existing example expanded by a) a Method example to access the request body and b)  maybe a example how to access URL request parameters]

I love @In @Scope(SERVLET) HttpServletRequest request; !
The placement & naming of the injection names should clearly allow the user to incept that it's linked to the SERVLET context. Honestly – I'd probably always fall into the expectation that i..e Request Parameters and Body are to be found within the REQUEST scope. And after reading the Javadoc of ScopeType even more.
1.1 Replace reserved names with types
Hmmm – Pro: Typesafe. Con: Type proliferation; Maybe unexpected to use custom types to access well-defined attributes for the servlet scope.
Would probably stick to names: Can be transparently expanded. And eventually referring injection values by a String-based named is IMHO the foundation mechanism it alway boils down to. Inferring the injection name via types is only a nice convenience, not a good design foundation.
Type conversion during injection
If I understand you correctly, there is currently no design infrastructure for implicit type conversion beyond the defaults provided by BeanUtil. This might cause issues i.e. as in my current example.
As far as I understand this will not work for nested properties i.e. when I receive GroceryList and need special handling for GroceryList.date.
Given the "microframework" scope I think your way of using additional setter Methods as Injection Target is a viable way to keep things simple.

Type conversion
Madvoc uses BeanUtil to convert the between the source and target types during the injection. Default converters are available for most Java platform types like …,…,.….
If you need to do custom type conversion you can add an additonal setter method and  redirect the injection point via @In
Date date;
void setDate(Date date) {     this.date = date; }
Date getDate() {     return this.date; }
@In void setDate(String dateString) {     this.date = MyUtil.convert(dateString); }

I'm currently not sure if the upper would work (due to the two setters) and if this would also work for nested properties (like in my case the root injectable being GroceryList)

[ ] Add a section "Type conversion" in Madvoc/Injection.
[ ] Fix 404 Link "Jodds type converter utility" in https://jodd.org/beanutil/
[ ] If BeanUtil supports adding custom type conversion I'm currently not aware of it.

[3] Data Source vs. Data format
I threw a  look into RestAction and then RestActionConfig to be able to understand what you are talking about. There I found this block
		setNamingStrategy(RestActionNamingStrategy.class);
		setActionResult(JsonActionResult.class);

"ActionResult" or "ResultType" gives me an immediate picture about what these statements are talking about. I find DataType a little troublesome as it is to generic about which data type we are talking.
Need to think on this for a good proposal. Will come back later.

@bentolor thank you for your time, this is a great thread :)
[1] Existing injections and reserved names

Better documentation regarding reserved names would be a great improvement! Honestly I skipped "Context and Servlet scope" and did not understand its intention. It was too confusing for me. I would expect it more like

True, true! Awesome example, filed an issue here: https://github.com/oblac/jodd-site/issues/18 Will do. Sorry for that :(

Honestly – I'd probably always fall into the expectation that i.e. Request Parameters and Body are to be found within the REQUEST scope.

I understand (and agree). Just have no idea how to make difference between the String body from any parameter/attribute. The only idea I have is to use custom types, e.g.:
@In @Scope(REQUEST) RequestBody requestBody;

I am not sure if there is a way to distinguish between the body and parameters using the same annotation. That's why we added the BODY scope.
1.1 Replace reserved names with types

Would probably stick to names: Can be transparently expanded. And eventually referring injection values by a String-based named is IMHO the foundation mechanism it alway boils down to. Inferring the injection name via types is only a nice convenience, not a good design foundation.

True. Moreover, this new classes would be simple value holders and is sort-of un-natural. But I would definitly move defintion of names from current class to e.g. the Scope class, it makes much more sense!
[2] Type conversion during injection

If I understand you correctly, there is currently no design infrastructure for implicit type conversion beyond the defaults provided by BeanUtil. This might cause issues i.e. as in my current example.

Not by Madvoc (except using a setter). But let's use your case as a requirement!

As far as I understand this will not work for nested properties i.e. when I receive GroceryList and need special handling for GroceryList.date.

Correct.

Given the "microframework" scope I think your way of using additional setter Methods as Injection Target is a viable way to keep things simple.

True, but... I would like to give it a try to design simple way of specifying converters for single injection; that might work for you.

I'm currently not sure if the upper would work (due to the two setters) and if this would also work for nested properties (like in my case the root injectable being GroceryList)

Would work only for first level. Two setter of the same name would not work (probably), i usually use different names.
[3] Data Source vs. Data format

"ActionResult" or "ResultType" gives me an immediate picture about what these statements are talking about. I find DataType a little troublesome as it is to generic about which data type we are talking.

To recap:

set conversion behavior in ActionConfig (so user can use either a custom annotation or @ActionConfiguredBy). Injections are managed by the same action configuration - like you said, user would understand it. However, it is not immediately clear what is injected; moreover the number of combination of different conversions and existing configs would multiply the number of different action configs (JsonRestAction, JsonAction, PlainRestAction, PlainAction...)

so far as I see an additional optional annotation should be introduced:

@In @Type(RawString) @Scope(BODY) String body;
@In @Type(Json) @Scope(BODY) Foo foo;
@In @Type(MyJson) @Scope(BODY) GroceriesList;

although type is a terrible name here. Maybe Mapper?

btw, shouldn't Jodd be able to parse both:

2018-01-01
2018-01-01 11:12:33

by default (without any additional settings)?

We can different injections depending on the content-type.

if json content-type, use JsonParser
if xml content-type, use XmlParser
if User wants a raw content, he can enforce content type:

@In @ContentType(text) @Scope(Body) String body

if user wants custom json, he can use his own content type variant:

@In @ContentType("application/json;customList") @Scope(Body) body

I believe that we might leveredge the existance of the HTTP content type and have a mapper for each content type. I was planning to add this to also for the action mapping, as for now you cant map an action to a content type.

I am not sure if there is a way to distinguish between the body and parameters using the same annotation. That's why we added the BODY scope.

Reserved name requestBody is not an option?

I would like to give it a try to design simple way of specifying converters for single injection; that might work for you.

I see two variants as a user here:

You have some special requirements in a few places and need/want to change it with low-key effort just in-place. Mapper oder TypeAdapter like in Gson sound like reasonable names to me.

@InOut @Mapper(MyCustomFooMapper.class) @Scope(BODY) Foo foo;
@In("id") @Mapper(MyUUID2.class) UUID2 uuid;

It turns out your model is a collection of oddities; therefore you want to replace the whole type conversion infrastructure.

@MadvocAction(mapper = GsonMapper.class)
public class ListAction {

    @Action("/list") @GET
    public JsonResult listAllLists() { …}

    @Action("/list", mapper = XmlMapper.class) @POST
    public JsonResult createList(@In @Scope(SERVLET) String requestBody) { … }
}

Examples only as rough idea; not polished proposal.
I'm not sure how to get this smoothly in sync with the ActionConfig approach. For example, how to control the type mapping here:
@RestAction("{id}") @GET  public User findUser() {  return someUser;    }

btw, shouldn't Jodd be able to parse both date format?

Did not test. In any case I also need to control the returned format.

We can different injections depending on the content-type

Supporting different content types at once might be an important extension. But being able to configure the serialisation/deserialization in general is precursor for that to me.

Reserved name requestBody is not an option?

Hm, not sure... I personally don't like exception cases: this only word would become reserved. Then someone else might need and ask for the e.g. request's content type or for http method name and for who-knows-what, and soon the list of reserved names expands.
I was trying to find a name that is invalid for parameters and attributes, but there is none.
For that reason, I would rather use different scopes. Maybe the name 'scope' is wrong, as they indicate the servlet's scope, hence the issue; it is more "the source of the injection value" (and I do not know a better word in English for that :).

You have some special requirements in a few places and need/want to change it with low-key effort just in-place. Mapper or TypeAdapter like in Gson sound like reasonable names to me.

Like it! Good point!

It turns out your model is a collection of oddities; therefore you want to replace the whole type conversion infrastructure.

Got it - this way we basically define a mapper for all the conversion that happens in this action class.

Examples only as rough idea; not polished proposal.

This is what I need the most , no worries.

Supporting different content types at once might be an important extension. But being able to configure the serialisation/deserialization in general is precursor for that to me.

Agree. Let me dive into the code and work on the rough Mapper proposal.

I didn't forget this. Before adding a mapper, I had to change how Scopes works. Now, the scope is simply defined by the annotation.
This means that you can use a default Body scope, but also it means that you can build a XMLBody scope pretty easily and use that one.
Furthermore, Ive added InjectionPoint - place where I could store potential Mapper information, for each injection point. This would mean that scope could use this information to use the correct mapper.
My only question now is should we add a mapper - as it is quite easy to build custom scopes - just make a class. Maybe it is too much for little Jodd? :)

I'm not sure if I'm able to follow:

https://github.com/oblac/jodd/blob/981f0bcc2956f80a50dab0d81d712906945d539b/jodd-madvoc/src/main/java/jodd/madvoc/config/InjectionPoint.java sounds like a reasonable place to declare transformation
But I'm now completely uncertain about how the new API design looks like either for a XMLBody case nor a using InjectionPoint to perform custom data type transformations

@bentolor here is the idea, not yet documented as it is totally fresh.
From now on the scopes are defined in annotations by specifying the scope name. The scope is a 'thing' that actually performs injection/outjection of a value from the context into the Target. The scopes are singletons.
The scope name can be either class name or some random name you make it. So the whole process goes like this:

OPTIONALLY register manually the scope: scopeResolver.registerScope(XmlBody.class); or scopeResolver.registerScope("name", XmlBody.class). ScopeResolver is part of the Madvoc components and it is easy to reach any time during the initalization.
Define a String constant with either the registered name from step 1 or just equals to new scope class name.
use your name in Scope annotation
Create your MadvocScope class.

Basically, you are doing this:
	@Scope(XmlBody.class)
    public void myaction()

I didn't want to depend on the class (due to Java limitations) but the String, so what you do is this:
    @Scope(XMLBODY)
    public void myaction()

where XMLBODY is a String constant with new scope name or full class name.
THe scope is easy to write:
public class XmlBodyScope implements MadvocScope {

    @PetiteInject
    you_can_inject_anything here

	@Override
	public void inject(final ActionRequest actionRequest, final Targets targets) {
		final String body = actionRequest.readRequestBody();
		if (StringUtil.isEmpty(body)) {
			return;
		}

		targets.forEachTargetAndIn(this, (target, in) -> {
			final Object value = MYXML_CONVERSION(body, in.type()); // CONVERT!

			target.writeValue(in.propertyName(), value, true);
		});
	}

Once again: you just write your own MadvocScope type that does the conversion. There is just this additional step of having the String name registration, instead of realying on the class.
P.S. I could remove the String names for scopes, but since Java allows only literals, you would be needed to write .class on every Scope annotation, and I simply didnt like that. You can't have a static constant of class and use that in annotation.

With latest commit it is even easier, you can just extend default BodyScope class and overide a parsing method:
https://github.com/oblac/jodd/commit/81cdeef0538cdeaf4d57a44a0058be95f01d22e1#diff-642f7bbe1cfa64fa27c9ecaacdce1162R57

@igr Currently very busy; will try to respond on weekend. Keep tight!

I tried to understand the idea behind scopes. Let me see if I was able to get it straight:

"Scopes" are implementations which are able to inject/outject a set of values from a source context retrieved via a fixed, shared set of methods declared by MadvocScope into one injection target.
Purely for simplification, your MadvocScope declares String constants referring to these different implementation. AFAIK this is motivated by the search for an elegant API
You are contemplating about using new, custom scope to reflect different source formats. This is mostly motivated due to the fact, that currently "BodyScope" is bound to JSON input

A few comments about the general design in detail

"1." already limits somehow the set of possible "context". Because you only have a fixed set of methods to retrieve you source context. This makes it IMHO rather unlikely that so. wants to create a new bunch of new "scopes"
"2." breaks a basic principle of design: The superclass (indirectly) refers its subclasses. Introducing a new subclass would require you to change the superclass on any change. I don't think this is generally a bad idea, if we agree, that the set of Scopes are rather fixed
More confusingly – if the set of options are already fixed, why – as a user – do I need to discover MadvocScope to find out how to use the Scope annotation class typically?
Regarding data conversion/data mapping I think we have two layers

converting from/to the source context into a generic value map and
converting one value stored within the context  value map into a target type very specific to the specific injection target point

My POV on data transformation

The current BodyScope is a very unique one in the set of predefined Scopes, because in most other Scopes. the scope itself already provides a direct way to read/access single source values. Only in body, the scope itself needs to "understand" a source data format.
My primary focus was pointed at the data conversion required to transform (typically a string) from the source context via a way very specific for the very specific injection target field/parameter.

WWBC (what-would-bentolor-code)
I would try to keep it plain, simple and stupid:

Introduce a BodyScope and a JsonBodyScope. The later is what your current BodyScope does. The former is simply a "one value as string : the request body text". If you already have support for XML maybe I'd add also a XmlBodyScope. But its not needed because of the following:
I'd also add support, to be able to declare a custom data mapper class for the conversion of the value I receive from the context into the target type.
And last but not least: Contemplate about, transforming @Scope(MadvocScope.BODY) directly into some @Body-Annotation

This could i..e. look like this:
@Action("/list") @POST
public JsonResult createList(@In @Body @Mapper(MyTypeMapper.class) MyType mySpecialType) { … }

@Action("/list") @PUT
public JsonResult createList(@In @JsonBody MyType receivedfromJson) { … }

@Action("/list") @PUT
public JsonResult createList(@InOut @Cookie String sessionId) { … }

To stick to your original question

My only question now is should we add a mapper - as it is quite easy to build custom scopes - just make a class. Maybe it is too much for little Jodd? :)

I think the granularity of the Scope is not appropriate, because you need to be able to control the mapping per injection field and not per source context.

@Scope("name") vs @Scope(Name.class)

Because if you use only  @Scope("name") instead of  @Scope("fully.qualified.classname") the name itself requires Madvoc to now how to turn this string into the implementation class. So probably I'd either

stick to @Scope(Name.class) or
add additional @Body-annotations for Convenience.

Hope this helps

Thank you for detailed review @bentolor!
 I was not completely satisfied with my latest refactorings, but it was a step forward.
Thank, I truly appreciate it! Can I send you some Jodd laptop stickers, I have few of them around? No kidding, just email me your address :)))

Added everything.
The difference is that @Mapper is now not only Madvoc but applies on any BeanUtil, hence it can be used in different situations as well.

I will close this issue. This feature will come in Jodd 5.
Please let me know if you notice something weird :)

The difference is that @Mapper is now not only Madvoc but applies on any BeanUtil, hence it can be used in different situations as well.

This sounds great and absolutely appropriate!


2 transactions stucked untill now

2 of my transactions are not cleared yet
Transaction 1 @

Check these screenshots. And plz clear those soon
Thanks
Regards

Hi @Onlyforcryptoc Please make sure you use a fee of 0.0001 ZEN in any transactions you send using the wallet. If 0 ZEN is used for the fee transactions can take a very long time to confirm, or fail to confirm completely.
Please let us know if you have any further questions.

How to add fee on horizen wallet ?
On Thu, 14 Apr, 2022, 12:48 am Angievii, @.***> wrote:

Hi @Onlyforcryptoc https://github.com/Onlyforcryptoc Please make sure
you use a fee of 0.0001 ZEN in any transactions you send using the wallet.
If 0 ZEN is used for the fee transactions can take a very long time to
confirm, or fail to confirm completely.
Please let us know if you have any further questions.
—
Reply to this email directly, view it on GitHub
https://github.com/HorizenOfficial/zencash-mobile/issues/144#issuecomment-1098396917,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJAFRKL4GM4DY3LWFEB2RMDVE4MWTANCNFSM5TGJONCQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

لم يتم مسح 2 من معاملاتي بعد العملية 1 @ تحقق من لقطات الشاشة هذه. ورجاء مسح تلك قريبا مع تحياتي الشكر

Hay

Hay


Results with AdjLogits

Hi Thank you for your great work. How can I reproduce the results with AdjLogits for CIFAR-LT ACC?

Hi Thank you for your great work. How can I reproduce the results with AdjLogits for CIFAR-LT ACC?

I use the same strategy of
stage2.py in this repo  https://github.com/amazon-science/long-tailed-ood-detection
Based on our final checkpoint, we train adj-logits as same as stage2  tuning methodology

Thank you very much.
How can I calculate the prior_gamma1, and prior_gamma2 values for a new dataset like ImageNet-LT dataset?


SIP binaries support on macOS

Currently we don't load into sip protected binaries on macOS. We have a way to fix it, need to implement.
If you face a use case where mirrord failed to load on macOS, please upvote/comment on this ticket with details so we can prioritize it accordingly.

Status update:
https://github.com/metalbear-co/mirrord/pull/706
Makes it possible to run a sip protected binary with mirrord, also via a shebang chain.
However, we don't yet bypass SIP for binaries that are executed by the executed binary. So things like bash scripts, where usually almost each command is starting some SIP protected binaries won't work on Mac as expected yet. Working now on supporting this.
Small note: we should now put a hash of the original file in the path of the patched file, so that if you write a bash script with a shebang, run it with mirrord, we patch it and save it, then you change your script and run it with mirrord again, we now patch the new version, and not use the old patched version.

Additional note: we should probably mark all the generated files as excluded from filesystem hooks.
Maybe even walk the shebang chain also on Linux to mark all to be ignored regardless of SIP?
It seems for example that when running a script with this shebang #!/bin/bash bash opens the file of the script for reading (and does not find it if FS is not disabled).
Are there scenarios where a user would want some scripts/commands to be read from the pod?

I agree but the filter should probably be extension of file and that should be general enough.

Small note: we should now put a hash of the original file in the path of the patched file, so that if you write a bash script with a shebang, run it with mirrord, we patch it and save it, then you change your script and run it with mirrord again, we now patch the new version, and not use the old patched version.

Agree. Create an issue on that, we'll probably wait a bit with that as that's pretty edgy, but ofc we want to fix it.

Created. https://github.com/metalbear-co/mirrord/issues/717
Should be very easy though, if it's the 1 line change I think it is, I would include it in the PR for this issue, if that's ok.

Created. #717 Should be very easy though, if it's the 1 line change I think it is, I would include it in the PR for this issue, if that's ok.

Wouldn't bother right now. It might seem simple, but testing/actual running might become complicated.

Status update: while testing the new hook with bash scripts, found out that the children processes get the environment the application (in that case, bash) started with, without the existing-agent variables. So I'm now adding handling for that in the hook (check if env vars passed in execve include the agent vars, if they don't create new array that does include and pass that instead).

Still missing: support when running from an IDE.

Still missing: support when running from an IDE.

I believe this should be a separate issue - I think in most cases IDE resolves to the real binary so shebang cases are okay, and usually binaries ran aren't SIP.
Having said that, do create the issue and let's raise suggestions on how it would work, until someone faces it then we'll prioritize it.

Tracking SIP IDE support on https://github.com/metalbear-co/mirrord/issues/747 :)

SIP supported with the exceptions of #747 and the theoretical situation described in https://github.com/metalbear-co/mirrord/pull/759#issuecomment-1319969427.


Fix opt_horizontal_padding() example

This slightly modifies the opt_horizontal_padding() example in the documentation. This one is a bit odd because during manual testing, GT.opt_horizontal_padding(scale=3) did not seem to work (which was chalked up to a bounds issue in an argument check) but the code shows it does accept a scale value of 3---and the API docs also has an example of this working in https://posit-dev.github.io/great-tables/reference/GT.opt_horizontal_padding.html#great_tables.GT.opt_horizontal_padding.
Fixes: https://github.com/posit-dev/great-tables/issues/214

Oh strange, thanks for looking into it :o


Add more options to fail on insufficient coverage

Enforcing code coverage is good and the current option --fail-under-lines is a way to do it but unfortunately rather crude one. Percentage is relative and may change due to amount of code changing vis-a-vis covered code. The llvm-cov report does provide absolute values of covered and uncovered for each of the 4 categories:

function
line
region
branch

The better way would therefore be to fail coverage on uncovered absolute values rather than percentages which is volatile. That way if new code is added that is fully covered the coverage will pass. However when new code is not fully covered it will also require changing of the threshold(s) which is good thing - it might be justified of course but nevertheless should be visible.
I propose the following options:
--fail-uncovered-functions
--fail-uncovered-lines
--fail-uncovered-branches
--fail-uncovered-regions

I think referencing absolute values instead of percentages is an interesting idea. I'm fine with adding this as an experimental option.

However when new code is not fully covered it will also require changing of the threshold(s) which is good thing

I think this is not necessarily a good thing when there are multiple PRs, because it easily causes merge conflicts.

I think referencing absolute values instead of percentages is an interesting idea. I'm fine with adding this as an experimental option.

Thanks!

However when new code is not fully covered it will also require changing of the threshold(s) which is good thing

I think this is not necessarily a good thing when there are multiple PRs, because it easily causes merge conflicts.

This would happen only if you had multiple PRs that are all worsening coverage. Something nobody would want I presume. And if it happens regularly then enforcing coverage is probably not what is wanted.

This would happen only if you had multiple PRs that are all worsening coverage.

Note that this can also be caused by PRs that improve coverage (if the current coverage is not 100%).

PR A adds a test for function A1 and reduces uncovered lines from 5 to 3.
PR B adds a test for function B1 and reduces uncovered lines from 5 to 4.
Merging both PRs reduces uncovered lines from 5 to 2, but there is a merge conflict.

Ah, sorry, I somehow misunderstood that the values passed to those options are concrete values. It is thresholds, so my comment above is wrong.


ValueError: multiclass format is not supported

Hi，I tried your new update code 。but I got this error
Traceback (most recent call last):
File "train.py", line 43, in
train()
File "train.py", line 40, in train
model.train()
File "/home/dl/VSST/dm/ganomaly-master/lib/model.py", line 168, in train
res = self.test()
File "/home/dl/VSST/dm/ganomaly-master/lib/model.py", line 259, in test
auc = evaluate(self.gt_labels, self.an_scores, metric=self.opt.metric)
File "/home/dl/VSST/dm/ganomaly-master/lib/evaluate.py", line 24, in evaluate
return roc(labels, scores)
File "/home/dl/VSST/dm/ganomaly-master/lib/evaluate.py", line 46, in roc
fpr, tpr, _ = roc_curve(labels, scores)
File "/home/dl/anaconda3/envs/pytorch0.4/lib/python3.7/site-packages/sklearn/metrics/ranking.py", line 622, in roc_curve
y_true, y_score, pos_label=pos_label, sample_weight=sample_weight)
File "/home/dl/anaconda3/envs/pytorch0.4/lib/python3.7/site-packages/sklearn/metrics/ranking.py", line 396, in _binary_clf_curve
raise ValueError("{0} format is not supported".format(y_type))
ValueError: multiclass format is not supported

Hi, can you tell me what was the command you run on the terminal to get the error?

@samet-akcay
python train.py --dataset cifar10 --abnormal_class ariplane
when I print the net ,I also find the discriminator‘s structure is not same as the paper。 it lacks the fourth conv 。512。 does it matter？

@samet-akcay ， I find the second question is in skipganomaly . And in skipganoamly,is the discriminator loss right?  I think it shouldn't have err_g_lat

@ samet-akcay，我发现第二个问题是skipganomaly。在skippganoamly中，鉴别器损失正确吗？我认为它不应该有err_g_lat

hi,I met the same question in your topic description, can you tell me how you handle this problem?

@ samet-akcay，我发现第二个问题是skipganomaly。在skippganoamly中，鉴别器损失正确吗？我认为它不应该有err_g_lat
Hi,I met the same question in your topic description, can you tell me how you handle this problem about 'multiclass format is not supported'.

Hi, I also meet the same question, Have you fixed it? Can you help me?


Migrate CI to GitHub Actions

This PR sets up CI on GitHub Actions.
Everything runs green.

Thanks!


Classification stage in the CNN

I am using this project in my Bachelors thesis but I have encountered a problem
My idea was to build a hand gesture recognition system that could tell what gesture is the system receiving as an input. I was hoping that the output could provide the label for the gestures' name.
However, from what I have experienced with this project, the output resulting from the classification layer is a series of values describing fingers' angles and hand orientation.
Is there a way in which the system could be trained so that the output of the classification stage provides the label for the gesture dataset name (as if we wanted to find out the gesture category each input belongs to)??
Thanks in advance.

Hi @miguelml99 thank you for your interest in this project, I have not used this code for quite a while so couldn't answer your question.
But if you are interested in hand gesture recognition from RGB image you may want to refer to a more recent project using Google's Mediapipe.
All the best to your project!

Hi, @limgm Thank you for your response.
I am using the realsense depth camera D435i so I need to benefit from depth images. However ill take a look into your RGB project, it seems promising and ambitious :)
Coming back to the hand tracking project, I have seen that you implemented the left-hand tracking capability. I haven't tried this one yet, but is there a way to recognize/track both left and right hands simultaneously??
(just in case you know/remember, I understand it´s been long since you last worked with this project. )
Thanks for your help!


Temporary licensing backfill issue

This document references "temporary licensing backfill issue" but I cannot find out what this exactly means. It also reference the "previous FAQ" but again it is not clear on which FAQ it is referring to. Please update this article with more clarification on these two issues. The 10 year audit license becomes available in early 2021 so it would be great to have this clarification as soon as possible so organizations can plan appropriately. Thank you.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 027a1632-76a4-9e87-8376-c10ddfc3e116
Version Independent ID: 10c72509-5d4a-25d3-caf8-361474f68cd8
Content: Advanced Audit in Microsoft 365 - Microsoft 365 Compliance
Content Source: microsoft-365/compliance/advanced-audit.md
Service: o365-seccomp
GitHub Login: @markjjo
Microsoft Alias: markjjo

@maximumdave Thanks for catching this. We will remove the references to previous FAQ and licensing backfill issue. It's not applicable anymore and doesn't impact an organization's ability to plan for the 10-yr retention of audit records. For 10-yr audit log retention, you just need to make sure that the users whose audit records you want to retain for 10 yrs are appropriately licensed, and to implement audit log retention policies to retain records for 10 years.
Licensing backfill was as issue when we first released Advanced Audit back in Feb. 2020. It meant that Advance Audit package may not have been rolled out to an organization when it was first released. Earlier versions of this topic had an FAQ item that addressed this and had steps to mitigate it for uses by unassigning and then reassigning the Adv Audit app for an E5 user in the M365 admin center. Since this is no longer necessary to do, we removed the FAQ; however as you cited, we didn't remove the reference to it. If you're curious about the mitigation (again, it's no longer necessary) you can view the view the history of this topic in github (see PR submitted on Sept 18th, title "updated adv audit FAQs as per marketing and PM").
Thanks again for the heads up.


bitcoin jpgs

request to add bitcoin jpgs to the collections

what is missing here?
the files should be good
@MillHaus33


Lag with GPU acceleration

VSCode Version:

Version: 1.47.1 (user setup)
Commit: 485c41f9460bdb830c4da12c102daff275415b53
Date: 2020-07-13T22:42:53.386Z
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.19041

OS Version: Windows 10 2004

Steps to Reproduce:

scroll any text with mouse or keyboard, activate terminal with hotkey, move terminal pane from left to right, scroll in sidebar, resize panes - pretty much any action with any kind of input
response time between 2 and 10 seconds

Does this issue occur when all extensions are disabled?: Yes

Things go back to normal when running code --disable-gpu
Similar lags observed with Insider version

Version: 1.48.0-insider (user setup)
Commit: cb31fc6ce2b4da3520392b622aa3ebc5b313533b
Date: 2020-07-15T05:34:49.078Z
Electron: 8.3.3
Chrome: 80.0.3987.165
Node.js: 12.13.0
V8: 8.0.426.27-electron.0
OS: Windows_NT x64 10.0.19041
Performance data collected here https://github.com/microsoft/vscode/issues/101596#issuecomment-658932185
This is all happening inside virtual machine: VMWare, 12 core CPU, 16GB RAM, accelerated graphics.
Host: Windows 10 2004, NVidia GeForce GTX 1070, i8700K CPU 12 virt cores.
No other electron app seems to be affected in that VM and it was working fine previously. Doesn't seem to be related to any rare VMWare or NVidia driver update.
cc @deepak1556

Are you still experiencing this issue with latest stable ?


python312Packages.ondilo: 0.4.0 -> 0.5.0

Diff: https://github.com/JeromeHXP/ondilo/compare/refs/tags/0.4.0...0.5.0
Changelog: https://github.com/JeromeHXP/ondilo/releases/tag/0.5.0
Description of changes

Things done

Built on platform(s)

[ ] 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
[ ] 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

[ ] Fits CONTRIBUTING.md.

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

Result of nixpkgs-review pr 305703 run on x86_64-linux 1

5 packages built:

home-assistant-component-tests.ondilo_ico
python311Packages.ondilo
python311Packages.ondilo.dist
python312Packages.ondilo
python312Packages.ondilo.dist


feat: add possibility to get continuation of YTMusic UpNext Tab

The changes add a function to get a continuation of the UpNext PlaylistPanel or PlaylistPanelContinuation.
Therefore a further test was added. :)

The test currently seems a bit difficult as the Youtube Music Playlist I used and works from my computer, does not seems to work from the github runner. :/
If someone found a got Playlist alternative, feel free to adapt it. :D

@LuanRT Do you see some blockers for this PR? :)

@Duell10111 Nope. I'll try it out and merge it as soon as I can.


Enable AppVeyor Builds

Follow up on #408
AppVeyor is configured for the repository, however a repository admin would need to go to https://ci.appveyor.com/projects/new and flip the switch for the automated Windows builds to happen.

I think I flipped the bit.  I guess we'll see on the next pull request.

Yep, it's working.


React.lazy()

View formatted RFC
Note: I just wrote up the RFC. The semantics are designed by @sebmarkbage and @acdlite.

Is the idea that the return value of lazy() MUST return a promise that resolves to {default: Component}? The downsides of that strike me as out weighing the convenience of having write lazy(async () =>  (await import('./Button')).default) or the same in plain promises. React almost always prefers explicit longer code to convenience so it seems a bit of an odd choice out here to require .default for what is probably(?) code that will be written not super often.

Is the idea that the return value of lazy() MUST return a promise that resolves to {default: Component}?

In the scope of this proposal, yes.

The downsides of that strike me as out weighing the convenience of having write lazy(async () => (await import('./Button')).default) or the same in plain promises.

Which downsides are you referring to?

React almost always prefers explicit longer code to convenience so it seems a bit of an odd choice out here to require .default for what is probably(?) code that will be written not super often.

I think the RFC goes into detail about why we specifically want access to the module object. This will be important for future work on the new server renderer.
An "explicit" proposal that doesn't lose this future potential would be something like
lazy(() => import('./Button'), Button => Button.default);

At this point it's going to be so common though that it might as well be the default (pun intended) behavior.

Which downsides are you referring to?

the inability to use named exports, or potentially do any post-import transform/instrumentation

I think the RFC goes into detail about why we specifically want access to the module object.

Sorry yeah, I can see how that would be useful, but it also feels premature? As you noted what the module object returned here even looks like is nebulous and undefined, even in Node for the SSR case. This limitation doesn't seem to really put react in a better position for the future since there is no reason why users can't do import('./Buttons').then(_ => ({ default: _.SaveButton }). Potentially breaking any future deeper integrations.
I would also add that it feels uncomfortable to me that React would want integrate so tightly into the module space, before there is a clear sense of what the standard there is. Folks do so. many. weird things in webpack, et al, to meet their needs that this is going to be a moving target for a looong time.

(do I think this a really cool addition to the API!)

the inability to use named exports, or potentially do any post-import transform/instrumentation

The proposal mentions we could add named exports to this.

Sorry yeah, I can see how that would be useful, but it also feels premature?

We're starting work on this now (both standard proposals and the new server renderer implementation) so I wouldn't say it's premature. This is going to become a very active area of work for us.

This limitation doesn't seem to really put react in a better position for the future since there is no reason why users can't do import('./Buttons').then(_ => ({ default: _.SaveButton }).

We'll document that you're supposed to pass the module object, and nothing else. For sure, some people will ignore it, but then adopting the new server renderer isn't forced upon them. People who follow the recommendation would have an easier path.
Again, if this doesn't work out, we can surely relax it in the future. In fact that's what the original proposal was (it took any Promise) but then we decided to make it stricter.

// Why don't we want to support this though?
const Button = lazy(async () => {
  const Components = await import('./components');
  // Resolve to named export:
  return components.Button;
});

I think the return statement should have a capital 'C'?

I think that once some of the other pieces of this puzzle fall into place. I suspect that the syntactical overhead will strongly push people towards the default exports. Especially if we can even get rid of the call to “lazy” in the default export case.

Nice (I'm already using it https://github.com/pomber/code-surfer-editor/blob/master/src/LazyCodeEditor.js#L4 😁).
Do you have in mind any special API for preloading? Or is the idea to preload it like any other suspenseful component (rendering it, maybe hidden)?

In the alternatives, it's listed as a possibility to:

Call it something long like createLazyComponent.

Has there been any more public discussion on the naming? Outside of the context of this discussion,React.lazy wouldn't necessarily be clear or self-documenting in the same way the rest of the React API is.
For example, the functions dealing with refs say so explicitly (createRef, forwardRef).
The functions dealing with components say so explicitly (createElement, cloneElement, isValidElement).
Since this probably isn't used in too many places throughout a code base, I think the tradeoff of adding extra characters for the sake of explicitness might be worth considering.

On the topic of default exports...
Here are a list of reasons to avoid default exports (via @basarat)
https://basarat.gitbooks.io/typescript/docs/tips/defaultIsBad.html
I think most of the React community uses default exports however many, following the practices above, do not use default exports and prefer named exports.

The longer term vision includes making literally every component in the whole code base use this. So you can imagine that syntax overhead will be a big deal and familiarity counter balance any explicitness concerns.

The longer term vision includes making literally every component in the whole code base use this

I have a hard time imagining how this will place nicely with bundlers and efficient code splitting...at the moment that would create a new bundle per file in webpack no?

at the moment yes

The longer term vision includes making literally every component in the whole code base use this.

I might be able to see the utility in that if you have a massive team working on components in a distributed fashion, where what code is being rendered for any given user might be impossible to reason about.
For an average sized site, though, the extra latency of loading each component bundle individually would surely outweigh whatever gain you have from a faster initial page load.
Maybe in an HTTP/2 world?

practical named exports example btw Material UI exports a lot of components as named exports, if it makes sense maybe it's worth including the extension now? I also seethe value in limiting new API's initially

When rehydration is possible, there needs to be away to tell the client to eagerly load components that were loaded lazily on the server and/or prime the lazy components cache before the initial render.
maybe a provider like api that can be queried to provide such info, and given the injected data to prime the cache

Trying to find a component in .default seems totally arbitrary. It should just use the resolved value as a component. Or maybe check .default afterwards if the resolved value is not a component.

If I place outside of Suspense I get:
An update was suspended, but no placeholder UI was provided.
I haven't seen any examples that note this, is this expected?
https://codesandbox.io/s/n731ny9kjl

Can you explain how Suspense will be able to make use of the actual module record?

 If so, how would the behavior be different if Suspense couldn’t access the module record, just the component?

@j-f1 Suspense  doesn't access the module record, Suspense is expecting a component or at least the promise of a component.

@GarethSmall that behavior is changing, that some of the point of the RFC here

@j-f1 Do you mean the lazy function or the Suspense component?

@GarethSmall I mean the React.lazy function, but the RFC says the module record will be useful to Suspense.

@j-f1 Ahh okay, I apologize I mis-spoke from a lack of understanding, so what I was doing was a bad practice, here's an expert from the RFC:
Is this what you were talking about?
The second part of the question is why don't we still allow passing something without a .default property?
// Why don't we want to support this though?
const Button = lazy(async () => {
  const Components = await import('./components');
  // Resolve to named export:
  return components.Button;
});

We intentionally don't support this in the scope of this proposal. This gives React an opportunity to integrate more tightly with the module system on the server in the future. There are no proposed standards for this yet, but the new Suspense-capable React server renderer we'll soon be working on will benefit from having a chance to introspect the import() result directly (rather than just a component). For example, it could change a priority of a pending request for the Button.js module once it knows that a component of the Button type is going to be lazily rendered. We can't do this if we break the link between the module and the component. While this depends on future experimentation and standardization work, this design leaves more space for it. We can always remove this restriction later if it doesn't end up being beneficial. (That's also why the proposal doesn't support arbitrary Promises as component types.)

Thanks for explaining; that makes a lot more sense.

How does this interact with React.memo? Would this work?
const Button = React.memo(React.lazy(
    () => import('third-party-button')
);

No. The argument to memo has to be a function component, which lazy isn't (it is a special type). We should error on this.
It works the other way around though. Which is consistent with what we say in memo RFC: it should be applied at the definition site. You can wrap in your own component at the call site if you really need this.

The argument to memo has to be a function component, which lazy isn't (it is a special type). We should error on this.

Is this also true for React.forwardRef then?

For an average sized site, though, the extra latency of loading each component bundle individually would surely outweigh whatever gain you have from a faster initial page load.

@matt-casey
I think you might be confusing the syntax (import is asynchronous) with a specific behavior (create a bundle per component). There's absolutely no reason why tools like webpack need to create a separate bundle per dynamic import. If they had access to usage statistics, they could instead be smart about bundling modules together in the most efficient way based on which are likely to be rendered together.
The "longer term" vision Sebastian alluded to is not about the current webpack behavior. But about allowing a better bundling solution.

Regarding named exports.
I hear where you’re all coming from. If you disagree with our recommendation to use default exports for split points, you can use a workaround described in https://github.com/reactjs/rfcs/pull/64#discussion_r226683684. You could even your own lazyNamed helper that does this. Yes, it’s hacky and it might make it more difficult for you to benefit from the future work on the streaming rendering. But it seems like this isn’t a concern shared by many people on the thread. This makes sense since it applies to the future and not to today. And because details are very vague at this point (we’re just beginning to investigate this). We have to think about the future though because otherwise we’ll have to make breaking changes later.
This RFC has a limited surface. It's targeted at the main use case we want to start handling (default imports). There is a door open for supporting named imports in future RFCs, but it is out of scope of this one. This one is intentionally very limited. We expect to understand this problem space more within the next several months and then we can revisit that discussion with a better understanding.
I understand you want us to support your use case today. But we don’t have all the information yet, and if the solution is too broad, it’s very likely we’ll have to deprecate or make breaking changes to it in the next release. Nobody likes breaking changes. Therefore, for now we’d like to focus it on the parts we feel more confident in.
I hope this makes sense, even if you disagree.

The "longer term" vision Sebastian alluded to is not about the current webpack behavior. But about allowing a better bundling solution.

@gaearon
I think that makes sense, I was thinking very much in the context of today's webpack.
I can definitely imagine having everything lazy-loaded if the compiler were smart enough. It would be great to move that decision of where to code split out of the code-base itself and put it into the compiler's hands.
I realize now that in order to give the compiler the flexibility to do that, you'd have to do exactly what @sebmarkbage said and wrap literally every component in React.lazy.

When rehydration is possible, there needs to be away to tell the client to eagerly load components that were loaded lazily on the server and/or prime the lazy components cache before the initial render.

Yes. This is something we want to be able to do automatically, which is why we need the module information (rather than just the Promise to a component). Then the server could send this information to the client embedded in the small runtime.

It's not clear how server-side rendering works. To be more concrete - when component got imported.
It is not a question on a client side - all "userspace" loaders execute import function on Component render, and lazy will do the same. This is right and clear - import something only when you used it.
But on server side, it's very opinionated:

loadable-components waits for all components to be loaded, to do this library traverse react-tree by it's own
universal-component uses babel plugin to convert async imports to sync requires but still require some stuff only on component render
imported-components imports everything on HOC definition, so by the time server started - everything is already imported, and there are no actions to be made later. This also enabled some features, like per-connection mocking(here is an explanation why one need it), which could be very useful to make rendering more server-side friendly.

So - when imports will work on a server?

@theKashey
Supporting today's server renderer is out of scope of this proposal (as mentioned in the RFC).
In the future Suspense-capable server side renderer (which is fully asynchronous and can stream chunks while waiting for data) my mental model is that dynamic imports would be somehow rewritten to be synchronous, but the renderer would remember which modules got rendered, so that it can increase their priority as they're being sent to the client interleaved with data and HTML.

This is almost certainly outside the scope of this RFC but I wanted to see if there was any interest in lazy imports as a codebase security mechanism. What I'm thinking of is a paradigm where the code is stored in the cloud (Firebase Storage or the like) and streamed to and loaded by the client contingent on some separate backend user authentication.

Going with this limited version (default imports only) for now. It's possible we'll add named imports later.


Error while installing plugin version 2.2.0

I am trying to install the plugin (version 2.2.0 currently) and no matter the way I try it fails to be installed. I am not sure which command to use, since the recommended "plugin -i entity-resolution -url  http://goo.gl/DGQuUe" is not working.
I get the following errors:
bin/plugin -i entity-resolution -url  http://goo.gl/DGQuUe
-> Installing entity-resolution...
Trying http://goo.gl/DGQuUe...
Failed: IOException[Can't get http://goo.gl/DGQuUe to /data/websci/elasticsearch/elasticsearch-1.5.0/plugins/entity-resolution.zip]; nested: FileNotFoundException[http://dl.bintray.com/yann-barraud/elasticsearch-entity-resolution-plugin#elasticsearch-identity-resolution-plugin-0.1.zip]; nested: FileNotFoundException[http://dl.bintray.com/yann-barraud/elasticsearch-entity-resolution-plugin#elasticsearch-identity-resolution-plugin-0.1.zip];
Trying https://github.com/null/entity-resolution/archive/master.zip...
Failed to install entity-resolution, reason: failed to download out of all possible locations..., use --verbose to get detailed information
I also tried installing it manually by downloading the file and executing this command
bin/plugin install file:plugins/elasticsearch-entity-resolution-plugin-<IP_ADDRESS>.zip
, which again didn't work.
This is the error:
Trying https://github.com/file:plugins/elasticsearch-entity-resolution-plugin-<IP_ADDRESS>.zip/archive/master.zip...
Failed to install file:plugins/elasticsearch-entity-resolution-plugin-<IP_ADDRESS>.zip, reason: failed to download out of all possible locations..., use --verbose to get detailed information
I also tried lots of urls and most of the times the error is either:
Error while installing plugin, reason: IllegalArgumentException: Plugin installation assumed to be site plugin, but contains source code, aborting installation.
or
Error while installing plugin, reason: IllegalArgumentException: Plugin installation assumed to be site plugin, but contains source code, aborting installation.
konstantina.lazaridou@isfet:/data/websci/elasticsearch/elasticsearch-1.5.0$ bin/plugin -u -v install larsga/elasticsearch-entity-resolution
or
Error while installing plugin, reason: ElasticsearchIllegalArgumentException: Illegal plugin name:

Hi,
Just download the 2.2.0 zip file and install like in documentation https://www.elastic.co/guide/en/elasticsearch/plugins/2.2/installation.html

I have already mentioned above that I tried to use the documentation and it doesn't work. Both for urls and files.
This command:
** bin/plugin install file:plugins/elasticsearch-entity-resolution-plugin-<IP_ADDRESS>.zip**
doesn't work and shows the above errors.


Make test262-harness.py Python 3-compatible

indent are using to do arithmetic compare
leading < indent, and None can't do that.
JerryScript-DCO-1.0-Signed-off-by: Yonggang Luo<EMAIL_ADDRESS>

Note that this is another py 2vs3 issue:
$ python2 -c "print(1 < None)"
False
$ python3 -c "print(1 < None)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: '<' not supported between instances of 'int' and 'NoneType'

Note that this is another py 2vs3 issue:
$ python2 -c "print(1 < None)"
False
$ python3 -c "print(1 < None)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: '<' not supported between instances of 'int' and 'NoneType'

Yeap, I am using python3 to running the script, python2 are on the way to gone

For the records, the following traceback was in the original commit message:
Traceback (most recent call last):
  File "C:\work\study\languages\typescript\jerryscript\tools\runners\test262-harness.py", line 937, in <module>
    sys.exit(main())
  File "C:\work\study\languages\typescript\jerryscript\tools\runners\test262-harness.py", line 925, in main
    code = test_suite.run(options.command, args,
  File "C:\work\study\languages\typescript\jerryscript\tools\runners\test262-harness.py", line 825, in run
    cases = self.enumerate_tests(tests, command_template)
  File "C:\work\study\languages\typescript\jerryscript\tools\runners\test262-harness.py", line 772, in enumerate_tests
    strict_case = TestCase(self, name, full_path, True, command_template)
  File "C:\work\study\languages\typescript\jerryscript\tools\runners\test262-harness.py", line 487, in __init__
    test_record = parse_test_record(self.contents, name)
  File "C:\work\study\languages\typescript\jerryscript\tools\runners\test262-harness.py", line 314, in parse_test_record
    yaml_attr_parser(test_record, attrs, name, onerror)
  File "C:\work\study\languages\typescript\jerryscript\tools\runners\test262-harness.py", line 245, in yaml_attr_parser
    parsed = yaml_load(attrs)
  File "C:\work\study\languages\typescript\jerryscript\tools\runners\test262-harness.py", line 70, in yaml_load
    return my_read_dict(string.splitlines())[1]
  File "C:\work\study\languages\typescript\jerryscript\tools\runners\test262-harness.py", line 94, in my_read_dict
    (lines, value) = my_read_value(lines, value, indent)
  File "C:\work\study\languages\typescript\jerryscript\tools\runners\test262-harness.py", line 117, in my_read_value
    return my_multiline_list(lines, value)
  File "C:\work\study\languages\typescript\jerryscript\tools\runners\test262-harness.py", line 139, in my_multiline_list
    elif leading < indent:
TypeError: '<' not supported between instances of 'int' and 'NoneType'

LGTM (informal)

Please rebase.

rebased


Fixed #32632, Fixed #32657 -- Removed flawed support for Subquery deconstruction.

Subquery deconstruction support required implementing complex and expensive
equality rules for sql.Query objects for little benefit as the latter cannot
themselves be made deconstructible due to their reference to model classes.
Making Expression @deconstructible and not BaseExpression allows interested
parties to conform to the "expression" API even if they are not deconstructible
as it's only a requirement for expressions allowed in Model fields and meta
options (e.g. constraints, indexes).

buildbot, test on oracle.

do y'all know if this was backported to django 3?

Yes, it's included in Django 3.2.1+.


Support for GCP Cloud Run

What problem are you facing?
I'd like to provision a Cloud Run Service resource.
How could Crossplane help solve your problem?
Implement GCP Cloud Run managed resources from this API https://cloud.google.com/run/docs

Is anyone working on this?
If not, I'd be interested in giving it a try, if there are any good guides on how to implement a resource AND the effort is not overwhelmingly large.

Hi @wfaler ! Yes, there is Provider Dev Guide as a doc and also a video where I'm implementing GCP PubSub managed resource that you can follow along.
Feel free to join our Slack and ask for help whenever you need!

@muvaf thanks for the pointers! I'll probably hold off on this (anyone else wanting to do it, feel free).
It looks as if Cloud Run doesn't have an official Go API yet?
I guess I could try to call the REST API's directly to work around it, but not sure I have the patience or time to wrap my skull around it at the moment, unfortunately. :(


[5th Edition OGL by Roll20] No background images

Is there a reason we are not using the assets for the background images?
Exe: background: url(/images/dndstyling/CharScroll.svg);

Greetings @deltmd
I'll need some more details.  You can toggle it off and on in the Game Settings.
Thanks,
Cassie

Thank you, I misunderstood.


Google Drive Login in expired after restart

Describe the issue
Google Drive Login in session expired after restart livecontainer.
Instructions to reproduce
I'm using the IPA download from here
What version of LiveContainer are you using?
3.0.0
Other
No response

This problem seems to be caused by sideloading detection of Google software


UI not proper for Post if long content.

If we post a memory with long content, then it allows.
But the issue is that it's shown with the whole content and it scrolls for the whole page as shown below. Also it affects it's sibling post height.
Note: The post is without opening the read more button.

I think that this should be limit to the content to be shown.
Please assign me this issue.

Can I contribute to this issue ?
please consider assigning


Unable to deploy a Linux ElasticPremium App Service Plan in the West Europe region

Hi!
I'm unable to deploy a Linux ElasticPremium App Service Plan in the West Europe region.
Request URL: PUT: https://management.azure.com/subscriptions/00-000-000-00/resourceGroups/test-rg/providers/Microsoft.Web/serverfarms/test-premium-linux?api-version=2019-08-01
Request Body:
{
  location: "West Europe",
  kind: "elastic",
  properties: {
    reserved: true
  },
  "sku": {
    "name": "EP1",
    "tier": "ElasticPremium",
    "size": "EP1",
    "family": "EP",
    "capacity": 1
  }
}

Response code: 409
Response body:
{
  "error": {
    "code": "InvalidResourceLocation",
    "message": "The resource 'test-premium-linux' already exists in location 'eastus' in resource group 'test-rg'. A resource with the same name cannot be created in location 'West Europe'. Please select a new resource name."
  }
}

Replacing the location field with North Europe (for example) works without a problem.
According to the docs, this functionality should be available on the West Europe region
https://azure.microsoft.com/en-us/global-infrastructure/services/?products=functions&regions=non-regional,europe-north,europe-west

Hi @MilheiroSantos based on the service response, the resource looks like already exists, please help double check it
The resource 'test-premium-linux' already exists in location 'eastus' in resource group 'test-rg'. A resource with the same name cannot be created in location 'West Europe'. Please select a new resource name.

Gosh, pasted the wrong error message!
The error I got initially was something like: Requested features are not supported in region. Please try another region.
I tried to recreate the error I got initially, and it seems it's working fine now.
Thank you! Closing this issue.


0x80073cfc : The application cannot be started. Try reinstalling the application to fix the problem.

Brief description of your issue

The winget-cli can't run while i using relative sub command.
Steps to reproduce
Use winget with any sub command, such as search, list, etc

Expected behavior

Actual behavior

PS C:\Users\causingbrick> winget list
Failed to open the source; try the 'source reset' command if the problem persists.
An unexpected error occurred while executing the command:
0x80073cfc : The application cannot be started. Try reinstalling the application to fix the problem.
PS C:\Users\causingbrick> winget search qq
Failed to open the source; try the 'source reset' command if the problem persists.
An unexpected error occurred while executing the command:
0x80073cfc : The application cannot be started. Try reinstalling the application to fix the problem.

I had tried rest the source but no help.
Environment
[winget --info]

Windows: Windows.Desktop v10.0.21354.1
Package: Microsoft.DesktopAppInstaller v1.11.10771.0
Windows Package Manager v0.2.10771 Preview

@CausingBrick
What source(s) do you have configured?
winget source list
Is there a policy blocking the Microsoft Store?
What was the result of winget source reset?
Do you have any settings affecting the "autoUpdateIntervalInMinutes"?

@CausingBrick
What source(s) do you have configured?
winget source list
Is there a policy blocking the Microsoft Store?
What was the result of winget source reset?
Do you have any settings affecting the "autoUpdateIntervalInMinutes"?

Thanks for your reply!

winget source list result:

PS C:\Users\causingbrick> winget source list
Name    Argument
--------------------------------------------
winget  https://winget.azureedge.net/cache
msstore https://winget.azureedge.net/msstore

There is no policy  blocking the Microsoft Store, I can install apps in it nomally.
winget source reset resulst :

PS C:\WINDOWS\system32> winget source reset
The following sources will be reset if the --force option is given:
Name    Argument
--------------------------------------------
winget  https://winget.azureedge.net/cache
msstore https://winget.azureedge.net/msstore
PS C:\WINDOWS\system32> winget source reset --force
Resetting all sources...Done

The value of "autoUpdateIntervalInMinutes" is 1 in settings.json.

@CausingBrick the "autoUpdateIntervalInMinutes" is a bit short. Our default is 5 minutes. That setting is what the client uses to determine if it should check for a newer source package and download it. If you have a great network connection to the Internet you should be able to download, install, run commands with the source. Can you try increasing that value and see if you get different results?
Did you install the Windows Package Manager via GitHub releases, or the Microsoft Store?
Would you mind using [Windows]+[f] to submit feedback for "Apps" / "Windows Package Manager"? That will result in logs being sent so we can try some additional troubleshooting.

Today I ran the winget without modifying the settings with the settings.json, its perform normally. I don't know the reason, maybe my wi10 rebooted several times for windows update last night.

Feel free to re-open the Issue if this happens again.


probably a bug in asm functions

Hi,
any reason why this this lines are commented out?

Hi, I wrote simple test that demonstrates this bug:
`
#include
#include <stdint.h>
#define AVX2 1
#include "shuffle_dictionary.hpp"
#include "intersection/naive.hpp"
#include "intersection/branchless.hpp"
#include "intersection/avx2.hpp"
static void printArray(const char* arrayName, uint32_t* array, size_t size)
{
std::cout << arrayName << ": " << size << " elements:" << std::endl;
std::cout << "\t";
for (size_t i = 0; i < size; ++i)
{
std::cout << array[i] << ", ";
}
std::cout << std::endl;
}
int main()
{
prepare_shuffling_dictionary_avx();
alignas(32) uint32_t list1[] = {
	1, 2, 3, 4, 5, 6, 7, 8,
};
alignas(32) uint32_t list2[] = {
	1, 2, 3, 4, 5, 6, 7, 8,
};
const size_t size1 = 1; // trying to compare only one element from list1, but because of bug another 7 elements are also compared.
const size_t size2 = sizeof(list2) / sizeof(list2[0]);

alignas(32) uint32_t result[size1 < size2 ? size2 : size1]; // in case of bug in intersect_vector_avx2_asm, the function can fill up to max(size1, size2)

printArray("List1", list1, size1);
printArray("List2", list2, size2);

std::cout << std::endl;

{
	size_t count = intersect_vector_avx2_asm(list1, size1, list2, size2, result);
	printArray("Intersection(asm)", result, count);
}
{
	size_t count = intersect_vector_avx2(list1, size1, list2, size2, result);
	printArray("Intersection(cpp)", result, count);
}

}
`

Thank you both. You are absolutely right. I pushed a fix.
 It's probably not worth to remove anyway.


[question] Does a deep equal check exist ?

Is they something like R.deepEqual(obj1,obj2) to check whether obj1 and obj2 have the same values recursively ?

R.equals is deep. Ramda uses deep equality everywhere except in R.identical.

Ok, great, thanks, didn't know


rocAL - Video_pipeline Support

Video Reader to read, decode and return a batch of sequences in NFHWC format
Video Reader Resize to fuse reading and decoding
Sequence Reader to read sequence from directory of video stream
Sequence Rearrange to rearrange frames in sequence
Meta Data support for the video reader.
Enabled HIP Backend support for the video pipeline.

@rrawther This PR passes all unit tests specified in documentation.

@rrawther I have merged master and codacy errors were resolved after the fix.

@paveltc: Can you please run tests on this PR
@LakshmiKumar23 : Can you run SSD training on this PR for performance?

@paveltc: Can you please run tests on this PR @LakshmiKumar23 : Can you run SSD training on this PR for performance?

@rrawther SSD training converged in 59 minutes at the 55th epoch

@rrawther I ran the tests on this PR and commented that they passed. I'm not sure what happened to my previous comment.

@kiritigowda to check the Jenkins failure

passing CI


Adopt Ruff

Why not? All the cool kids are doing it :sunglasses:
Closes https://github.com/wagtail/cookiecutter-wagtail-package/issues/58
This PR replaces

isort
flake8
flake8-bugbear
flake8-comprehensions
black
blacken-docs

with ruff, and provides a very similar ruff config to what we previously had for those tools.
In this PR, I have stuck to doing everything with pre-commit hooks and no local installs. I am not making the switch away from hook repos to using "local" here, just to keep the scope constrained. I do plan to do that, but it is another issue for another day.

@chris48s what do you think of adding a separate ruff workflow like https://github.com/torchbox/wagtail-bynder/blob/main/.github/workflows/ruff.yml -- this will add handy inline annotations on the PR should there be failures

what do you think of adding a separate ruff workflow like...

Sounds like a reasonable improvement. It requires us to drop the "delegate all linter management to pre-commit" thing and install our tools in the local environment first, which I do plan to deal with, but I think should be another issue - as stated in the top post. I don't think we need to do all that in this PR for it to be worth merging.


@nuxt/icon not working in histoire

I added @nuxt/icon to my project. In the project it is working fine but in histoire it is not working.
In histoire it is not able to render the stories that contain components that use @nuxt/icon.
On devtools console you always see the error:

it doesn't matter if mode is css or svg, it doesn't matter if from iconify icon libs, global components or custom collections, it is simple not able to work with it. The error is always the same.
Here is a reproduction: https://stackblitz.com/edit/nuxt-starter-kckxy8
run the histoire to see the story not getting rendered and the console error in devtools.
Please help!

Another user confirmed here: https://github.com/histoire-dev/histoire/issues/746#issuecomment-2253783496 that it is broken since @nuxt/icon version 1.0.0
<EMAIL_ADDRESS>is the last version which was working in histoire. So i guess it is a bug that came up with the refactor

@antfu this is NOT fixed for mode="svg" .. the linked merged fix only fixes it for the css version but when using mode svg it is still not working. Please check the reproduction and please reopen the issue as not fixed.

I also encountered a similar problem. I can only use it normally by specifying mode="svg", but this is not a fundamental solution.


[hitbtc, bleutrade]

@timmolter the Bluetrade change is a little controversial.  Basically the exchange will only supply 1 api key.  So allowing people to create 2 nonces (by creating 2 instances of the exchange) is invalid.
Thoughts?
I've requested they change their policy, because only having one api-key is too limiting.