Add slangc flag to -zero-initialize all variables

Adds -zero-initialize flag to set values to a __default() expression if they are missing an initExpr.
Fixes #3516

You should write
Fixes #xxxx
Or
Closes #xxxx
For GitHub to automatically link the issue.

I am wondering if we can have tests for cases when "-zero-initialize" is not used.
In game development, the uninitialized state is preferred over implicit initialization with zero values for the runtime performance reason.
I am little worried that we may accidently initialize variables to zero even when "-zero-initialize" is not used.

@jkwak-work Agreed that we need a test case to cover this.
Basically, when -zero-initialize is not specified, then we should not be generating default ctors if a type does not have any member initializers, when we should not be generating assignments in default ctors for members that are not initialized.
Then, if we don't synthesis such a default ctor, we won't be calling the default ctor at variable declaration sites.

I will add the test case, I agree that there should be one for each possible senario:

default init generated due to field init expression
no init should be generated due to 0 fields with init expressions

I think this works fine, but I wonder if the following makes sense:
When --zero-initialize is specified, we make all user defined structs and interfaces conform to IDefaultInitializable.
This means that if I have a struct MyType {}, it implicitly becomes struct MyType:IDefaultInitializable{} and then the interface requirement synthesis logic will kick in to automatically generate that the default ctor.
If have a interface IFoo, we will automatiaclly make it interface IFoo:IDefaultInitializable, so that any T:IFoo will also be default initializable and we will invoke the default ctor for variable definitions like T obj;.
We probably want to exclude stdlib from this behaivor, though.

logic{
AttributeVisitor::visitStruct()
{
    if (zero init is toggled we do)
    {
       --> addInterface(IDefaultInitializable).
    }
}

//...
in SemanticsDeclBodyVisitor::varDeclCommon --> if(IDefaultInitializableType), set all members as we do currently. This will result in a implicit generation of defaultCtor.

}

If we add IDefaultInitializable to structs if they don't already (transitively) have them, then when we are at ConformanceVisitor we will try to check if the type is indeed conform to IDefaultInitializable ( in SemanticsVisitor::checkConformance).
Then inside checkConformance, we will try to find a default ctor that will satisfy the requirement in IDefaultInitializable.
If we find it, we are good, and we can add it to the witness table.
If not, we will try to synthesize it in trySynthesizeConstructorRequirementWitness. There we should extend the logic and implement the ctor synthesis.

in SemanticsDeclBodyVisitor::varDeclCommon --> if(IDefaultInitializableType), set all members as we do currently. This will result in a implic ...

This logic is not necessary given the above flow.

If we add IDefaultInitializable to structs if they don't already (transitively) have them, then when we are at ConformanceVisitor we will try to check if the type is indeed conform to IDefaultInitializable ( in SemanticsVisitor::checkConformance).
Then inside checkConformance, we will try to find a default ctor that will satisfy the requirement in IDefaultInitializable. If we find it, we are good, and we can add it to the witness table. If not, we will try to synthesize it in trySynthesizeConstructorRequirementWitness. There we should extend the logic and implement the ctor synthesis.

in SemanticsDeclBodyVisitor::varDeclCommon --> if(IDefaultInitializableType), set all members as we do currently. This will result in a implic ...

This logic is not necessary given the above flow.

👍 Sounds good, I will go for an implementation around this.

@ArielG-NV Is that a question, or a finding? It seems that the new design should handle the situation fine?

While implementing I found an issue with inheritance and IDefaultInitalizable making sense to use.
If we have the scenario of inheritance where the parent does not have IDefaultInitalizable but the child has IDefaultInitalizable, calling the parent should not invoke IDefaultInitalizable logic. On the contrary, the child would be expected to exhibit behavior of IDefaultInitalizable for all inherited variables.

I don't why it is a problem if your description was to point out a problem. In Java or c++, when a child is XXX-able, it doesn't make their parent XXX-able.

I think my original question about design was not worded well.
My question is more of a question on how we plan to handle inheritance on the initialization side of member variables.

Do we follow existing C++ behavior:
struct myStruct_p
{
     int t1[3];
};

struct myStruct : myStruct_p
{
     int t2[3];
     myStruct() = default;
};
int main()
{
    myStruct s = myStruct(); // all members are default init'd
    myStruct_p s2 = myStruct_p(); // members are uninitialized
    return 0;
}

Or do we do something functionally equivalent to this [leave parents uninitialized]:
struct myStruct_p
{
     int t1[3];
};

struct myStruct : myStruct_p
{
     int t2[3];
     myStruct() = default;
};
int main()
{
    myStruct s = myStruct(); // only myStruct members (not inherited) are default init'd
    myStruct_p s2 = myStruct_p(); // members are uninitialized
    return 0;
}

I ask for the specifics since reducing register pressure on a GPU is significantly more important than the cost of initialization on a CPU. These approaches would also require significantly different code changes, it would be better to be sure of 1. or 2. before implementing.

If base is not default initializable, then we cannot automatically synthesize a default ctor. The same applies to normal members as well. If a struct has a member that is not default initializable, then we cannot automatically synthesize the default ctor for the type either.

Marking the title as WIP, please remove it once it is ready to review again.

This is good, but I want to test this with some compile performance benchmarks.

note: did not address all comments yet (https://github.com/shader-slang/slang/pull/3987#discussion_r1605529224)

I like to suggest to refactor the new boolean variable.

Likely best for future refactor, agreed.

Update: jkwak-work found a flaw with how std types were treated. This is being addressed.

Update: jkwak-work found a flaw with how std types were treated. This is being addressed.

Can you push the change so that I can see how it is changed?

Update: jkwak-work found a flaw with how std types were treated. This is being addressed.

Can you push the change so that I can see how it is changed?

pushed the changes

When I generated GLSL of the test, I see that "data1" is incorrectly unused with your code.
It seems like there is a bug in your implementation.

With this change, if I don't use "-zero-initialize" option, the results are expected to be same as before. And I tested it locally and saw that one of tests we have shows difference.
tests/language-feature/struct-field-initializers/struct-field-initializer-static.slang

Can you see why the result is changed with your code, and make sure everything works as expected?
The test is not failing but SPIR-V code is different when I compared the outcome with the following command.
slangc -target spirv-asm -o out.spirv tests/language-feature/struct-field-initializers/struct-field-initializer-static.slang

Took a bit to check because I wanted to get a clean master first*
There are differences. These of which I can explain, I will share the shaders for ease of reading:
### --> zero-init branch
#version 450
layout(row_major) uniform;
layout(row_major) buffer;

#line 7 0
layout(std430, binding = 0) buffer StructuredBuffer_int_t_0 {
    int _data[];
} outputBuffer_0;

#line 9
struct DefaultStructNoInit_base_0
{
    int data2_0;
};

#line 9
DefaultStructNoInit_base_0 DefaultStructNoInit_base_x24init_0()
{

#line 9
    DefaultStructNoInit_base_0 _S1;

    _S1.data2_0 = 2;

#line 9
    return _S1;
}

#line 16
struct DefaultStructNoInit_0
{
    DefaultStructNoInit_base_0 base_0;
    int data3_0;
};

#line 16
DefaultStructNoInit_0 DefaultStructNoInit_x24init_0()
{

#line 16
    DefaultStructNoInit_0 _S2;

#line 16
    _S2.base_0 = DefaultStructNoInit_base_x24init_0();

    _S2.data3_0 = 2;

#line 16
    return _S2;
}

#line 12
int data1_0;

#line 22
layout(local_size_x = 1, local_size_y = 1, local_size_z = 1) in;
void main()
{

#line 22
    data1_0 = 2;

    DefaultStructNoInit_0 noInit_0 = DefaultStructNoInit_x24init_0();

#line 24
    bool _S3;

#line 30
    if(noInit_0.base_0.data2_0 == 2)
    {

#line 30
        _S3 = noInit_0.data3_0 == 2;

#line 30
    }
    else
    {

#line 30
        _S3 = false;

#line 30
    }

#line 26
    outputBuffer_0._data[0U] = int(_S3);

#line 32
    return;
}

### --> master
#version 450
layout(row_major) uniform;
layout(row_major) buffer;

#line 7 0
layout(std430, binding = 0) buffer StructuredBuffer_int_t_0 {
    int _data[];
} outputBuffer_0;

int data1_0;

#line 9
struct DefaultStructNoInit_base_0
{
    int data2_0;
};

#line 9
DefaultStructNoInit_base_0 DefaultStructNoInit_base_x24init_0()
{

    data1_0 = 2;

#line 9
    DefaultStructNoInit_base_0 _S1;

    _S1.data2_0 = 2;

#line 9
    return _S1;
}

#line 16
struct DefaultStructNoInit_0
{
    DefaultStructNoInit_base_0 base_0;
    int data3_0;
};

#line 16
DefaultStructNoInit_0 DefaultStructNoInit_x24init_0()
{

#line 16
    DefaultStructNoInit_0 _S2;

#line 16
    DefaultStructNoInit_base_0 _S3 = DefaultStructNoInit_base_x24init_0();

#line 16
    _S2.base_0 = _S3;

    _S2.data3_0 = 2;

#line 16
    return _S2;
}

layout(local_size_x = 1, local_size_y = 1, local_size_z = 1) in;
void main()
{

#line 22
    data1_0 = 2;

    DefaultStructNoInit_0 noInit_0 = DefaultStructNoInit_x24init_0();

#line 24
    bool _S4;

#line 29
    if(data1_0 == 2)
    {

#line 29
        _S4 = noInit_0.base_0.data2_0 == 2;

#line 29
    }
    else
    {

#line 29
        _S4 = false;

#line 29
    }
    if(_S4)
    {

#line 30
        _S4 = noInit_0.data3_0 == 2;

#line 30
    }
    else
    {

#line 30
        _S4 = false;

#line 30
    }

#line 26
    outputBuffer_0._data[0U] = int(_S4);

#line 32
    return;
}

differences;

master:  static int data1 = 2; init's in the __init() of a function and at entrypoint. Now, only entry point sets the variable
data1 is now places lower in program code (since referenced first at a later date)

why this happens:
since we run ensureDecl(struct.member, DeclCheckState::DefaultConstructorReadyForUse), now the code sets up all modifiers+checks+inits correctly before we run bodyVisitor->visitAggTypeDecl()

When I generated GLSL of the test, I see that "data1" is incorrectly unused with your code. It seems like there is a bug in your implementation.

This is incorrect, master branch does things incorrectly.


Make $ deno doc --html read/resolve .js imports from .ts files if .js files dont exist

Currently I have one npm package where I declare .ts internal file imports as .js due to a sad compatibility benefit I get here: https://github.com/izelnakri/memoria/blob/main/packages/%40memoria/model/src/index.ts#L1
When I compile this project with tsc tsc can resolve and compile dependencies to a .js project distribution when project path is given. However I miss this feature currently given how new $ deno doc --html is, I think the command should resolve the .js files from .ts if .js doesnt exist because it seems this is what typescript team suggests and kind of implements internally.
Steps to reproduce
This should pass:
deno doc --html --name="@memoria/model" ./index.js

Deno does not behave like you are asking, and wont, and deno_doc follows the same logic and rules, so we won't change this


[KOGITO-1370] Add Cucumber tests for binary build

https://issues.redhat.com/browse/KOGITO-1370
Signed-off-by: Karel Suta<EMAIL_ADDRESS>Many thanks for submiting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[x] You have read the contributors guide
[x] Pull Request title is properly formatted: [KOGITO-XYZ] Subject
[x] Pull Request contains link to the JIRA issue
[x] Pull Request contains description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket
[ ] Your feature/bug fix has a unit test that verifies it
[x] You've tested the new feature/bug fix in an actual OpenShift cluster

To be able to run binary build test you need to reference local examples folder and have oc client and maven installed locally.

I'll get back to review this one once all @radtriste's comments were addressed.

@radtriste Please take another look, I hope I addressed all your comments.

@radtriste Ready for another round of review.

Considering enhancements based on https://github.com/kiegroup/kogito-cloud-operator/pull/239#discussion_r399238165 I think we can postpone merging of this PR after 0.9.0 release, not to block it.
This affects just tests anyway.

Considering enhancements based on #239 (comment) I think we can postpone merging of this PR after 0.9.0 release, not to block it.
This affects just tests anyway.

@sutaakar I'd say to merge and open a JIRA to follow up this refactoring

Created https://issues.redhat.com/browse/KOGITO-1597 to track the refactoring


Correcting animation frame-step when all frames have duration value provided

This PR:

Fixes a bug

Describe the changes below:
I noticed the total animation duration was not correct when defining an animation with frames that each have a duration value provided.
For example, for a 5-frame animation with each frame's duration set to 100ms I was seeing a total animation duration of 1000ms instead of 500ms. I looked into the source and saw that the next tick for the frame-step is always adding the calculated msPerFrame to the currentFrame.duration (100ms + 100ms in this case; resulting in 200ms for each frame, and 1000ms for the entire animation).
I made an update to the logic that takes into consideration if all the frames for the animation have duration values provided. In this case, the calculated msPerFrame is not needed when determining the nextTick value.
This change results in the example 5-frame animation correctly taking 500ms overall, with 100ms for each frame.
I have tested and verified the change in my own test project, but please take a look and let me know if there is anything I am not considering.
Phaser is amazing, thanks!

The issue #6712 is related to this and has been solved.
Sorry your PR was not used, but it helped us solve the issue, thank you! You have been credited in the Change Log


The client library should provide a better way to add any url parameters...

See my question on http://stackoverflow.com/questions/33982392/specify-login-hint-using-net-google-apis-oauth2-v2
and how I had to find a workaround to specify the login_hint parameter...

Thanks for reporting!
@squid808 Are you on it?

Yeah, it's been a heck of a week sorry. I'm trying to get things done at work so I can get some movement on this over lunch. Also, [excuses] and [more excuses]. =)
I'll get the first pull request in shortly, I promise.

It's OK. I just wanted to verify it.
No need to promise, do your best :)
Happy Friday!

Happy friday! No pull request yet (but here's the fork/branch) because I am working on adding in the additional unit tests required to fully test this out, AND it has some overlap with the other pull request (making the initializer public in the broker, for instance). I may need some help on said unit tests, what would be the best place for me to request that help?

I think that you can create a PR, with the title "DO NOT MERGE ....", and let's take it from there.
But.. The other PR you mentioned was already merged, you should merge it now to your repo as well.

Looks like this was done, so closing.


GEOMESA-2755 Initial implementation of CassandraSpatialRDDProvider

Work done for Cornell CS 5152 class. Contributions by: @rayjzeng @j-mez @lucaschen321
This pull request contains an incomplete implementation of a CassandraSpatialRDDProvider that providers Cassandra Spark support. The work for this integration is contained in two new modules: geomesa-cassandra-jobs and geomesa-cassandra-spark.
Current bugs and issues are documented inline in:

geomesa-cassandra/geomesa-cassandra-spark/src/main/scala/org/locationtech/geomesa/cassandra/spark/CassandraSpatialRDDProvider.scala
geomesa-cassandra/geomesa-cassandra-spark/src/main/scala/org/locationtech/geomesa/cassandra/spark/GeoMesaCassandraInputFormat.scala

going to close this, but feel free to re-open if anyone wants to work more on it.


file.GetCellValue() has a number of problems....

GetCellValue does not seem to return the formatted value. Nor does it return the RAW value in the RAW datatype that was Set(). The SetCellValue() takes an interface{} value that it uses to determine which formatting to apply. That too is confusing... if the source was text then the type determination is on my code. But that it is not returned plain or formatted consistently is a challenge.
Thanks

Thanks for your issue, this library doesn't support all number formats currently, according to the documentation, GetCellValue will try to get formatted value from a cell, if it is possible to apply a format to the cell value, it will do so, if not will return the raw value of the cell. The SetCellValue always sets the raw value for the cell If you wanna set the number format of the cell, create a new style with the number format by NewStyle and then bind style with the cell by SetCellStyle, also ref #862.

In this particular case I was given a spreadsheet from a 3rd party and I dumped the rows and cols in TSV format. When the file was opened in Excel or google sheet there was an integer column that was presented as integer but getcellvalue returned a trailing '.0'.
I understand the reply. If this is not a bug or feature please feel free to close.

Did you mean GetCellValue returns incorrect number precision of decimal type value? Could you provide more details or a spreadsheet xlsx attachment without confidential info?

The value in the spreadsheet cell was '12345' but when I pulled the value with GetCellValue()... it returned '12345.0'. Sorry I do not have a working example.

I have tested it seems to work well, I'll close this issue, if you have any questions, info of code, and attachments to reproduce this issue, please let me know, and reopen this issue at any time.


select option in stacked mobile mode

Hi Greg,
Is there a way to override the style to allow selecting of the rows in mobile stacked version and display the toolbar on top with the buttons? sort of similar to the screenshot below.

As it stands today no. I will have to think about adding such a feature

It looks like this functionality has been added since this issue was open, and exists in version 2.2.0.


Add a secondary radius to the SpherePointer to disable far interaction earlier

Overview
There is supposed to be a "dead zone" between disabling the far interaction and enabling (grabbable) near interaction with the SpherePointer. Previously there was a hardcoded margin in the IsNearObject function which has been removed, as well as a significantly larger base SphereCastRadius.
Introducing a configurable NearObjectMargin property adds back the dead zone, while keeping the SphereCastRadius at the desired smaller value (0.05m).
Also added a test to make sure the distance values work as expected.
Changes

Fixes: #5240 .

/azp run

/azp run


Add missing quotation in dependency string

The README file was missing a closing quote, making copy-paste of the dependency string introduce errors into a project.clj file.

Whoops, thanks!


Stopped the pluralization of collection name

- Summary
Removed pluralization of collection names in the CMS.
As suggested, this is the minimalist fix for #422
- Test plan
Pass all current tests and no additional tests required.
- Description for the changelog
Stopped the pluralization of collection name

@damienvdw thanks! Just one change needed, otherwise LGTM.

Wow, I really need more coffee.
It's fixed now 😄

Yeah, first open source PR ever ! 🎉

@damienvdw thanks, and congratulations! 🎉


Update dependencies

Summary:

[x] update dependencies  to the latest versions
[x] compile javascript files using the latest version of bucklescript (actually the PR changes only the auto-generated comment in each file)
[x] format all reason files using the latest version of refmt

In short, I think this PR must be merged before new ones will be created. Let me know what's your opinion about that 😉

I went through the files and added a comment to the only change in .js files that didn't just have comment changes.
There is some lines where I think refmt made it go too narrow but if it's a default I don't really care.

while we're on it I'm advocating for updating react-native, too. I used to be naive in a sense that we can do it one day in such a way that we won't break anything but we simply don't have neither manpower nor infra to do that.

✔ @wokalski done!
The 0.54.0 version of RN is available, but it uses<EMAIL_ADDRESS>which is incompatible with the current ReasonReact version due to the latest API changes in React. That's why I decided to update RN to the 0.53.3 version.

lib/js/src/components/image.js has a change other than comment

great!

This LGTM. Should we merge this @wokalski?

thanks 🎉

thank you @mobily 👍


Add a NumPy API Layer to Modin

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. What kind of performance improvements would you like to see with this new API?
It would be nice to be able to use the NumPy API to manipulate Modin objects, i.e. have a modin.numpy package.

I'm confused by #5422.  Is the idea a) to be able to call numpy.whatever(modin_object) or b) to make modin_object.to_numpy() give back a distributed numpy-like object?

The idea is b) - we want to create a distributed numpy object - just like our distributed pandas object. So modin.numpy.array() is a distributed object that has the same behaviors + API's as numpy.array()!

Doing that (well) seems like a really big increase in scope for modin.


.net installation

Problem encountered on https://dotnet.microsoft.com/en-us/learn/dotnet/hello-world-tutorial/install
Operating System: windows
even after installing the sdk it does not recognise the command

Did you close and open a new command prompt after the SDK installation?


Output Severity Level settings

Hi @matthewferreira,
Thanks for including the highlighting for cppcheck messages. I worked on settings to give the user the possibility mapping the cppcheck output to the diagnostic severity levels. I would like to have performance and style issues as warnings, for example, to see, if I can boost my code there.
You can try it out and acces them in the user / workspace settings. It is the setting cppcheck.severityLevels.
Could you provide this in the next update?

Had a bug in linter.ts at line 74. Please replace line with:
let d = new vscode.Diagnostic(r,(${severity}) ${message}, level);

I'm in the process of merging this in (probably done tomorrow). The linter was not picking up severity level changes on the fly, since config changes only trigger linting if the workspace changed as well. This is fixed. I also removed 'if (level !== undefined)' in favor of adding ' || vscode.DiagnosticSeverity.Information' to the line before. I wouldn't want to drop diagnostics just because the user made a config error.


Do not import minimal profile by default

environment.noXlibs breaks often things and is a hassle to use
documentation.enable having documentation available is desired
documentation.nixos.enable removes the man page for nixos-rebuild which is triggered by --help
programs.command-not-found.enable also command-not-found is useful

see https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/profiles/minimal.nix

github action is being flaky

Good idea! We should remove boot.isContainer as well due to similar quirks. Doing that also seems to help in solving #138, because isContainer changes a PAM module that's required for that to work from required to optional
A working replacement looks like this (in wsl-distro.nix):
      # We don't need a boot loader
      boot.loader.grub.enable = false;
      system.build.installBootLoader = pkgs.writeShellScript "fake-bootloader" "";
      boot.initrd.enable = false;
      system.build.initialRamdisk = pkgs.runCommand "fake-initrd" { } ''
        mkdir $out
        touch $out/${config.system.boot.loader.initrdFile}
      '';
      system.build.initialRamdiskSecretAppender = pkgs.writeShellScriptBin "append-initrd-secrets" "";

Lets move the removal of boot.isContainer to another PR to not open that pandoras box right now. For example I can imagine that we get problems with udev which gets activated then, audit, modprobe


fix(process_exporter): skip install when there's nothing to do

Just like in roles/node_exporter/tasks/main.yml: the install tasks can be skipped conditionally when process_exporter is already installed and reports the same version as the expected one.
This short patch is basically a copy-paste from roles/node_exporter/tasks/main.yml with the variables updated.

Obsoleted by #425


Remove some unnecessary type definitions

Remove some unnecessary type definitions when using the diamond operator.

LGTM, thanks for the cleanup!


Extract only content of pages

What are you working on?
Hi, I'm trying to get the content data of a PDF file and hash it to find out whether its pages' content was modified. I tried to create new PDFDocument and copy all pages from original file to the new file and hash it with SHA256, but everytime I did it, i didn't get the same hashed string. Some of other information like metadata change everytime i create a new PDFDocument.
Is there any idea to do that?
Additional Notes
No response

@ndtr2000  Can you please share if you were able to achieve this? If yes maybe share how.

@pranavburnwal So just as I said, the metadata was the problem. Specifically that is the creation and the modification date. So after copied to a new file, I changed the creation and the modification date to a specific date and I will get the same hash everytime I hash the new file (If the content wasn't changed).

Got it thanks!


[1.4] Update operator and release-builder

This pulls in fixes to operator and release-builder to correctly set the
hub and tag for baked in charts in istioctl. I verified this locally.

@howardjohn: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

release-test_istio_release-1.4
ab7d2448bd38a29e0ddc401d15d3ce65546433fa
link
/test release-test_istio_release-1.4

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


The validator does not work with collection arguments

Consider this validator
    public class FooValidator : AbstractValidator<Foo>
    {
        public FooValidator()
        {
            RuleFor(foo => foo.Bar)
                .NotEmpty()
                .NotNull();
        }
    }

And this action method
        [HttpPost]
        public Task Foobar([FromBody]IEnumerable<Foo> foo)
        {

        }

The library fails to validate

Please can you provide all the requested information when creating a new issue, including the version of FluentValidation you're using and which web framework you're using (MVC5/WebApi/AspNetCore) and the exact version.
I'll assume you're using ASP.NET Core 2.2, in which case this behaviour is correct.  By default, FluentValidation will attempt to find a validator for the exact type of the parameter, which in this case if IEnumerable<Foo>. You don't have a validator for IEnumerable<Foo>, only for Foo, so nothing will happen. There are 2 ways to handle this:

Create a validator that inherits from AbstractValidator<IEnumerable<Foo>>, which should then be invoked for the parameter. Internally it can call RuleFor(x => x).SetValidator(new FooValidator()) to invoke the FooValidator for each element in the collection.

Alternatively, you can turn on ImplicitlyValidateChildProperties (see this page in the documentation) which enables recursive detection of validators, and will then implicitly instantiate and invoke the FooValidator for you for each item in the collection.

(Don't mix the approaches though or you can end up having validation invoked twice , pick one approach or the other)

Sorry, yeah. Its core 2.2
Before you answered I tried just that. Does not work. The action method hit anyway
   public class FoosValidator : AbstractValidator<IEnumerable<Foo>>
   {
       public FoosValidator()
       {
           RuleForEach(foo => foo)
               .SetValidator(new FooValidator());
       }
   }

   public class FooValidator : AbstractValidator<Foo>
   {
       public FooValidator()
       {
           RuleFor(foo => foo.Bar)
               .NotEmpty()
               .NotNull();
       }
   }

But ImplicitlyValidateChildProperties  works, this should be teh default btw, its more inline with MVC Core default behavior. Thanks!

But ImplicitlyValidateChildProperties works, this should be teh default btw, its more inline with MVC Core default behavior. Thanks!

But it's not in-line with how FluentValidation works (which is to explicitly specify the validation hierarchy), which is why this is an opt-in behaviour and is not the default.
Also, you don't need to have both NotEmpty and NotNull on the same property (NotEmpty performs a not-null check internally).

Also, you don't need to have both NotEmpty and NotNull on the same property (NotEmpty performs a not-null check internally).

Yeah, added that when the action method hit.
But you might have a bug with the "standard" flow, my above code did not work.

If you want to put together a small sample project that reproduces the issue then I can try and take a look when I get some time.

If you want to put together a small sample project that reproduces the issue then I can try and take a look when I get some time.

No worries I can use the convention oven configuration approach, I like it better anyways.
We are looking at this lib as an replacement for our MVC attribute approach, since attributes means dependency to System.ComponentModel everywhere. But one thing they have is that you can query the IoC in a custom validator. This seems not to be possible with Fluentvalidaton? I guess you can do
    public class InvoiceValidator : AbstractValidator<Invoice>
    {
        public InvoiceValidator(IServiceProvider serviceProvider)
        {
            RuleFor(invoice => invoice.ToAccount)
                .Custom((account, ctx) =>
                {
                    if(!serviceProvider.GetService<IAccountValidator>().Validate(account))
                        ctx.AddFailure("Receiving bank account is not valid");
                });
        }
    }

But it creates dependecy on IServiceProvider everywhere and is a antipattern (service locator pattern). Injecting in the constructor will make it singleton so that will not work either. Any workaround?

Ah it seems the validator is registered transiant, so I can use constructor injection.

Yes validators are registered as transient by default to avoid the pitfalls that come with trying to inject dependencies into Singleton-scoped validators.
I’d inject the IAccountValidator directly though, rather than the service provider.

Yes validators are registered as transient by default to avoid the pitfalls that come with trying to inject dependencies into Singleton-scoped validators.
I’d inject the IAccountValidator directly though, rather than the service provider.

Downside is you need to run your rule mapping everytime. A singleton could have been cached. Probably not a problem for our models though. Yes, I ment that with  "Ah it seems the validator is registered transient, so I can use constructor injection.". Since its a transient scope I can use constrtor injection instead of service locator pattern.  Though a custom locator pattern for the context would have been pretty ok. Then you can benefit from singleton caching of the rules. Like
    public class InvoiceValidator : AbstractValidator<Invoice>
    {
        public InvoiceValidator()
        {
            RuleFor(invoice => invoice.ToAccount)
                .Custom((account, ctx) =>
                {
                    if(!ctx.GetService<IAccountValidator>().Validate(account))
                        ctx.AddFailure("Receiving bank account is not valid");
                });
        }
    }

Actually that functionality is already in place but not released yet. Coming in 8.2. You’ll be able to retrieve the service provider from the context (in asp.net core projects), and there are some shortcut methods for retrieving validators.
Regarding singletons: yes there is a performance benefit from caching, but it’s not huge. The expensive part is compiling the rule lambda expressions to delegates, but we already perform separate caching for this. You can of course register validators as singleton if you prefer, but I found that back when this used to be the default it created a huge amount of confusion for developers who didn’t understand the implications of dependency lifetimes, so defaulting to transient is the path of least resistance.


bug:

What version of daisyUI are you using?
3.0.1
Describe your issue
Loading icons and animations are not showing

What browsers are you seeing the problem on?
Chrome
Reproduction URL (optional)
https://stackblitz.com/edit/daisyui-cdn-3mjkuy/?file=index.html

Had a similar issue, but I'm using 3.0.3. Had to add autoprefixer as the css props mask-* are not available in chromium based browsers.

Tried this inside of my Electron app. Same issue. All instances of -mask-image or whatever it's called need to be replaced with webkit-mask-image.
Making this change makes things work properly

Fixed in 3.0.4

Seems like this same issue resurfaced at some point, I am having the exact same problem with 4+ (4.5.0)
I see mask-images browsing Chrome and my images don't get loaded. Works as expected in safari.
"devDependencies": {
"daisyui": "^4.5.0",
"autoprefixer": "^10.4.16",
"postcss": "^8.4.33",
"react-daisyui": "^5.0.0",
"tailwindcss": "^3.4.1"
},


Review Ticket

Collegeboard scoring
My hacks things

College board scoring is complete with comments
OOP hacks are complete
Front end is edited and creative (shown on local server)
Score: 3/3


Load custom CSS

Is it possible to enable some parameter to load custom CSS onto the page? It will be useful for many things. For one, loading a font-family that may not exist on target system.

We do not support nor plan to support it. This is considered out of scope for VS Code and code-server.

@sr229 I can see why it is out of scope for VSCode.
But for code-server, since code-server owns the whole webpage after auth redirection. There's no way to load additional styles without using some sort of user styles, which needs client-side setup and is not possible in many intended scenario of code-server (say, iPads).
For example, loading a custom font-family is a quite valid use case - it is common for webpages to import the font-family that it uses.

The ability to load fonts via CSS would be nice to have.
@sr229 from a quick look at the extension docs, extensions cannot embed fonts, only theme colours and icons.
@code-asher That would be a good idea, but it is undocumented what you would have to change either via injection or in the HTML, and it looks like to modify the HTML, you would have to build from source. This is likely not desireable from a UX standpoint.

See #1374


A programmatic API?

Hi, thanks for a great tool.
Have you considered adding a programmatic API? Maybe as simple as doxme(doxOutput).
I'll be happy to write a gulp plugin for you if there is an API.

Yep, sounds reasonable. JSON in, string out?

Added in 1.5.0

Wow, thanks for the promptness :) Looks great to me! :+1:

@tmcw so the gulp plugin is ready. Let me know if you have any thoughts regarding the API and such.


Implement pandas support

How tough do you think it'd be to implement pandas support? I'm thinking in the triage functions you could check if it is a pandas dataframe, and if it is just save the file as a list of its component parts, similar to how the pandas to_hdf method works. What do you think?

Most things I've tried to implement pandas support for have been tough because their API changed too frequently. That was probably a year or so ago now, so I guess it would depend on how stable they are now. Is there a list of stable component parts that could be used to deconstruct and reconstruct the objects?

In my experience it's been relatively stable the last year or so. Actually, I wonder if you could just do it using the pandas to_hdf method. This just asks for an h5 file path, and a 'key' to store the data. E.g., in the triage, if an object is a dataframe, then you would do df.to_hdf('./my_hdf.5', 'my_data').
Could you just call this method with the key being 'DF_MNE' or something like this? I doubt the dataframe h5 libraries will change too much over time...
Chris

The to_hdf sounds like a good approach. Then you get as much forward/backward compatibility for those objects as pandas supplies, which is great. I'm not sure how its writing function would interact with the already-opened hdf5 object/file we have, though. I guess you could delay writing all pandas objects to the end, but that sounds like a pain to keep track of. You might need to close the file, let pandas write, and reopen the file for every write. Clunky but it should work. Hopefully there's a better way.

I have definitely run into issues with h5io and pandas in the past. Been
meaning to open an issue but I haven't nailed down the bug yet. Basically
occasionally if you open an h5 file in pandas, and then do it with h5io in
some order, then the kernel dies. Maybe that bug would be unearthed if this
were implemented. I can try to take a whack at adding 'dumb' (aka, with
to_hdf) dataframe functionality if you like.
On Tue, Sep 15, 2015 at 5:38 PM, Eric Larson<EMAIL_ADDRESS>wrote:

The to_hdf sounds like a good approach. Then you get as much
forward/backward compatibility for those objects as pandas supplies,
which is great. I'm not sure how its writing function would interact with
the already-opened hdf5 object/file we have, though. I guess you could
delay writing all pandas objects to the end, but that sounds like a pain to
keep track of. You might need to close the file, let pandas write, and
reopen the file for every write. Clunky but it should work. Hopefully
there's a better way.
—
Reply to this email directly or view it on GitHub
https://github.com/h5io/h5io/issues/2#issuecomment-140588098.

I am -1 on adding it if it leads to such instability. To be clear, you mean h5io, this library, or h5py, the lower-level library that does all the heavy lifting? It sounds like pandas and h5py don't get along in some way. It's probably worth first making a minimal example where those two libraries don't get along, and then getting one of them to fix the bug.

fair enough - next time it happens to me I'll try to nail it down, then we
can revisit this if it's something sensible.
On Tue, Sep 15, 2015 at 5:44 PM, Eric Larson<EMAIL_ADDRESS>wrote:

I am -1 on adding it if it leads to such instability. To be clear, you
mean h5io, this library, or h5py, the lower-level library that does all
the heavy lifting? It sounds like pandas and h5py don't get along in some
way. It's probably worth first making a minimal example where those two
libraries don't get along, and then getting one of them to fix the bug.
—
Reply to this email directly or view it on GitHub
https://github.com/h5io/h5io/issues/2#issuecomment-140588729.

Hey - been looking into this now. I don't think it'd be too tough to incorporate this in the code that's already there. The following works just fine for me:
import h5io
import pandas as pd
import numpy as np
import h5py

# Create some fake data and write it to an HDF5 file
data = np.random.randn(100, 10)
data2 = np.random.randn(100, 5)
alldata = {'a': data, 'b': data2}
h5io.write_hdf5('./data/test_hdf_h5io.h', alldata, overwrite=True)

# More fake data, this time a df
df = pd.DataFrame(np.random.randn(100, 2), columns=['a', 'b'])
df.to_hdf('./data/test_hdf_h5io.h', 'h5io/df_1')

# Open the file to look inside
with h5py.File('./data/test_hdf_h5io.h', 'r') as f:
    ds = f['h5io']
    print(ds.keys())

# Finally show that we can read in the dataframe
dfin = pd.read_hdf('./data/test_hdf_h5io.h', 'h5io/df_1')
print(dfin.head())

# Note that we can't read in with h5io now
# it'd get confused at the group type but would be built in

So it seems that we could just include a check for whether it's a dataframe or series, keep those until the end, and once we've written to the file with h5py and close it, just run the to_hdf methods of anything that's been kept for the end.

And I should note that I never got any crashes as I alluded to before. I tried open files in pandas while they were open in h5io etc and it never crashed so..........that must mean that the problem is totally fixed and we will never encounter bugs again, right? right?

It seems like a tricky thing is "how do you write to an hdf5 file that's already open"?
One thought is something like this: add an extra list called "post_io". This will be returned by triage_write/read. Then, after the with statement that uses triage_write, you can add another for loop that goes through the post_io list. Each iteration of the list should supply the proper information to call whatever IO it's meant for. E.g.:
At the beginning of the loop, we'd add cleanup_io = []
Then inside _triage_write:
    elif isinstance(value, pd.DataFrame):
        rootname = root.name
        cleanup_data.append((rootname, key, 'dataframe', value))

That would add the necessary pieces for the to_hdf method. And then here's the outermost bit (note that we're seeing the tail end of the with statement where we return cleanup_data)
    cleanup_data = _triage_write(title, data, fid, comp_kw, str(type(data)))
for rootname, key, title, value in cleanup_data:
    if title == 'dataframe':
        _create_pandas_dataset(fname, rootname+'/'+key, title, value)

This could theoretically be extended to any IO system that won't work with an already-open file.
I guess a challenge with this is that _triage_write kind of implies that it's doing all of the necessary legwork, while this implementation basically says "not always". But I don't see how to do this otherwise, unless we just do custom pandas I/O stuff (e.g., here)

Maybe instead of cleanup_data we could call it other_data (meaning, data not saved/read by h5io). I'm a bit confused how come you need a isinstance(value, pd.Dataframe) in the _triage_write code. Wouldn't the other_data take a completely different writing path?
You say you can't read the hdf5 file anymore with read_hdf5 once you've also saved the Pandas data in there, how come?

Maybe instead of cleanup_data we could call it other_data (meaning, data not saved/read by h5io).

Good idea - sounds fine to me.

I'm a bit confused how come you need a isinstance(value, pd.Dataframe) in the _triage_write code. Wouldn't the other_data take a completely different writing path?

Well it's going to the same file, and might be nested inside of other structures like dictionaries, which is why I was putting it in triage write. E.g. I often save my data in a dict like {'subject': 'sub1', 'experiment': 'exp_a', 'data': dataframe_of_my_data}. If it's in triage_write then we can point the pandas to_hdf method to the specific root of the hdf5 we want.

You say you can't read the hdf5 file anymore with read_hdf5 once you've also saved the Pandas data in there, how come?

Because it's stored under the h5io group, so when h5io does read_hdf5 it will find the pandas object and raise an error since it's not implemented right now.

Can you put down what you think the calls should look like to incorporate Pandas data, then? I thought at first you wanted to be able to write pandas data in its own directory in the HDF5 file, but now I realize you're thinking of having pandas data be written to/read from by h5io instead (being careful about making sure it's an optional dependency of course :) ).
To avoid changing the API, we might need a return_other_data=False kwarg, that you'd need to set to True in order to deal with Pandas data properly. But it depends on if I'm thinking of the API correctly.

For example let's say I want to save my data = dict(a=1., b=some_pandas_data_frame) to h5io, and get the result back from disk (this is a minimal type example of your use case right?). How do you propose to do it?

Let me put together a PR and see what you think about it. Shouldn't take too much time (famous last words)

So trying to implement it makes me realize one challenge with having this sort of approach:
_triage_write operates in a sort of weird iterative way. It doesn't just loop through all of the pathways in the output hdf5 file. If it finds a list, tuple, dict, etc, then it calls itself once more. This means that we can't just have a cleanup_data attribute that we append to, because you'd get namespace collisions when a loop would call that function again.
All that is to say - I wonder if I am making things too complicated. What if instead of writing in native pandas functionality, we could basically just skip over pandas objects when using read_hdf? It is possible to read / write pandas objects to an HDF5 file on top of h5io. So we could assume that the user will handle their own pandas writing (they can place it to whatever key they want within the object).
So I think there are 3 options, in order of decreasing complexity/work:
Option 1 (most difficult)
Add full pandas support along the lines of what we've discussed already.
Option 2
Let pandas objects be stored w/in the root/node structure of the h5io data, but skip over them when doing reading.
Include an allowed_classes parameter to _triage_read. When reading the data, if a node isn't in the classes within the _triage_write loop, check if its type is in the allowed_classes list. If so, don't return an error. That way you could still write out the data.
So the syntax would be:
h5io.read_hdf5(my_file, allowed_classes=[pd.DataFrame])
and then at the end of _triage_read, you could add an extra check to the loop:
elif type_str == 'None':
    data = None
elif type in allowed_types:
    ...allow it to pass
else:
     raise TypeError('Unknown node type: {0}'.format(type_str))

The trick here is that h5io uses type_str not the class itself, so it would error when it first looks for the TITLE attribute.
Option 3 (least work)
Assume that the person will store pandas objects completely independently of the h5io nodes but maybe in the same file. In this case, I think the only change that should be made is to case "overwrite" to not overwrite the whole file, but just the root that is provided to write_hdf5. Otherwise if someone writes pandas, then someone writes h5io stuff with overwrite==True, it will overwrite the whole file.
Thus, you could do
h5io.write_hdf(my_file)
df.to_hdf(my_file, 'pandas/data')

At this point I'm kind of partial to 3, as it accomplishes something close with minimal overhead. What do you think?

Though probably 2 wouldn't be too much extra work. At the beginning of _triage_read, you could just do:
try:
    type_str = node.attrs['TITLE']
except IOError:
   if 'pandas_type' in node.attrs.keys():
       pass
   else
       raise IOError('Unsupported type etc etc')

_triage_write operates in a sort of weird iterative way. It doesn't just loop through all of the pathways in the output hdf5 file. If it finds a list, tuple, dict, etc, then it calls itself once more. This means that we can't just have a cleanup_data attribute that we append to, because you'd get namespace collisions when a loop would call that function again.

It operates recursively, which should be fine. For example you can add an argument other_data to the _triage_read function. The first call would set it to other_data=list(), and any subsequent recursive call would just do other_data.append(...). Same would be true of _triage_write.

Recursive! That was the word I was looking for yesterday. The best I could come up with was "weird iterative" haha.
I had actually started doing that before (with passing a container to the read/write functions), but didn't finish building it in because it seemed like it might clutter things up too much and you seemed like you didn't want to make very drastic changes. If however that sounds OK with you, then I'm happy to give it a shot.

What's the benefit here? Pandas folks have already developed and maintained for long time .to_hdf
Why reinvent things?

On 17 Dec 2015, at 18:34, Chris Holdgraf<EMAIL_ADDRESS>wrote:
Recursive! That was the word I was looking for yesterday. The best I could come up with was "weird iterative" haha.
I had actually started doing that before (with passing a container to the read/write functions), but didn't finish building it in because it seemed like it might clutter things up too much and you seemed like you didn't want to make very drastic changes. If however that sounds OK with you, then I'm happy to give it a shot.
—
Reply to this email directly or view it on GitHub.

So this would actually use to_hdf under the hood...it would just place the dataframe at the proper root/node in the hdf5 file (e.g., if you passed a dictionary and w/in the dictionary was a dataframe). The trick is that you have to run to_hdf on a closed file, so the actual writing can't be done in the _triage_write function.

I think you'd have to change every line where _triage_read or _triage_write gets called. It will look ugly but conceptually it's a small change.

ok cool - glad I didn't delete the branch where I was trying that then :) I'll make a PR and we can see how it looks.

Check out #5 for a first pass at _triage_write

Thanks for your help one this one @Eric89GXL!


add a bootstrap method to pseudo cli that expands cdk bootstrap and modifies the asset bucket with CORS

Addressed by #49


nginx module: missing resolve option

Issue description
server example.com resolve;  is valid configuration syntax. The module however does not allow such options (other than valid).
http {
    resolver <IP_ADDRESS>;

    upstream u {
        zone ...;
        ...
        server example.com resolve;
    }
}

It should be possible to influence the configuration such that "resolve" can be specified.
Technical details
Applies to master and 18.03.

Actually, this only applies to the commercial version. Still would be useful to also be able to configure the commercial version, but as such it's less pressing.
Open-source Nginx seems to be crippleware given that it doesn't support such a feature.

services.nginx.proxyResolveWhileRunning = true; works around this for you.
Also since we don't support the commercial version, I'm closing this. If you need support for it please open a PR :)


Fixes EVP AEAD decryption failures for CCM, GCM, OCB, and SIV

This PR is a backport of a recent PR aimed at fixing decryption issues for GCM, CCM, OCB...etc. by first encrypting the data, and then decrypting the ciphertext. This backport is intended for OpenSSL-3.3. This backport hasn't been tested against versions older than 3.3 as of yet, but I'll test that and report back here.
With these proposed changes, -evp aes-128-ccm -decrypt, ``-evp aes-128-gcm -decrypt` will execute successfully. Other modes such as SIV, GCM-SIV and OCB have also been tested.
Related issues are #24686 and #24250.

Currently this is a faithful backport of #25823. Making additional changes here would cause 3.3 branch to diverge, which would make further work difficult. Any such changes should be done in subsequent PRs.

@zelda923 CI is relevant

@zelda923 CI is relevant

Apologies @t8m for the delay. I did receive multiple emails about the failures but I was away.

This pull request is ready to merge

Squashed and merged to the 3.3 branch. Thank you for your contribution.


use noble for rolling ci

Merging, since build failures are genuine failures in compiling the packages in noble


Don't create infer-out directory or logs unless analyzing something.

This will stop Infer from creating an infer-out directory when just running infer.
(I run infer without any arguments somewhat often to look at documenting.)
One downside to this is that there will be no logs when running Infer without any commands - is this bad?

Thanks @tonycosentini  for the pull request! Yes, I think that it is legit to run infer as an equivalent to infer --help.


[5.4] Use parent connection if related model doesn't specify one

In reference to this https://github.com/laravel/framework/issues/9355#issuecomment-254759333
Currently there's no way to query posts on the parent connection "non_default_connection":
User::on('non_default_connection')->first()->posts;

This PR will use the parent model connection if the related model doesn't have a connection specified.

Is this going to be pushed back into 5.1 LTS as well?
If it resolves #9355 that would be great.

@davisonja not sure, 5.1 is technically closed for adding features, only bug fixes :)

Just for a reminder, what is the current behavior? It just uses the default connection null I'm guessing? Would there really be any way to fallback to this behavior if you wanted to in 5.4?

Yes it uses the default connection if not Model $connection was set.
With this PR there's no way to fallback to default no, unless you set the Model $connection to use the default connection. Not null, the default one.

The reason behind this change is multi-tenancy, to be able to do:
Songs::on('band-123')->with('artists')->get();

This will bring the artists of tenant band-123 instead of the ones in the default connection.

@themsaid True, I still feel it's a bug, though I concede that's primarily as I can't think of a use case for wanting
 Song::on('band-123')->with('artist')->get();
to (always) return artists from the default connection; and I am currently using it in a situation where we need the artists to come from 'band-123'.

@reno1979

I would really appreciate this fix.
We 'clone' parts of our database models into multiple connections, and because they are the same we can use our Eloquent Models on each connection.
When working with an eloquent model instance on a specific connection, I did not expect that the related models of that instance would be using the applications default connection. Causing corrupted data in the database or errors.
We 'solved' it for now using a queue on a new thread, that changes the default database connection before the process starts. This is not a real solution and feels like a hack.
We would like to be able to retrieve :
$dataFromConnection1 = $DummyModel::on('connection1')->first();
$dataFromConnection2 = $DummyModel::on('connection2')->first();
$dataFromConnection3 = $DummyModel::on('connection3')->first();

@themsaid @taylorotwell what's the status on this one?

why only 5.4 and not the current improvements on 5.3? when will 5.4 come out?

here: https://laravel-news.com/2016/01/laravel-release-process/ i see it'll be december?

Might not be then. Probably more like January, though it's not been decided.

@GrahamCampbell why not in the sub updates in 5.3?

This is a breaking change so can't go to 5.3.

@GrahamCampbell aah, when changing composer to 5.4 we can allready use the development version of 5.4 right? because this is an important one to us...

We inserted the code from the patch (Eloquent/Model.php) , but can't seem to get it working.
$featureModel = new \App\FeatureGroup;

$featureModel->setConnection('otherConnection');

$featureModel->get();  // Ok we are receiving data from 'otherConnection'

$featureModel->create(['en'=>['name'=>"general"],'nl'=>['name'=>"algemeen"]]);

// The created row is not in the 'otherConnection', but is placed in the default database....

Note: we are using https://github.com/dimsav/laravel-translatable

@reno1979 but the example you shared doesn't involve related models, which is the purpose of this PR.
Can you please open a new issue with an example on how to generate the issue? But without using a package, just a fresh laravel app cause packages may have changed the default behaviour.

@themsaid
Thank you for the quick reply.
We are not using any packages at the moment, but the create method keeps using the default db.
Our goal is to fill a related table (translations).
We are using artisan tinker, and tried the following:
\App\FeatureGroup::on('otherConnection')->getModel()->create(['name'=>'test']);
// a new row is inserted in the default db, but should be in the otherConnection db

/* OUR WORKAROUND */

$featureGroupModel = new \App\FeatureGroup;
$featureGroupModel->setConnection('otherConnection');
$featureGroupModel->save();

$featureGroupModel->id; // the given id is from the new table row in otherConnection db :)

Here's a helpful hint to setup a base model with this change now in place for 5.4.
If some of your models use an alternate connection, then you can override the default connection while still keeping it for all other models by having them all inherit from this class.
<?php

namespace App;

use Illuminate\Database\Eloquent\Model as BaseModel;

class Model extends BaseModel
{
    /**
     * Get the current connection name for the model.
     *
     * @return string
     */
    public function getConnectionName()
    {
        return config('database.default');
    }
}


ActorAddress: Paths become ActorTags and use them for DAs

This is a great first step ticket and could be picked up by a motivated contributor at any time.
It would greatly unlock the "remove tree" work.

What:
When we spawn we take a name today:
spawn(naming, ...)
This name is stored in the Actor's ActorAddress
This ticket:

keep it there but also introduce a field ActorTags which is a dict from actorTagID (UInt8) to Any OR String? not sure yet...
when we spawn, store a .name = name in the tags
implement the actor's .name and similar using this rather than delegating to the address

Eventually the address can then become an ActorID based one, and thus not have the name/path at all.

Relates to the ancient https://github.com/apple/swift-distributed-actors/issues/479 but I don;'t think this is so large as that other issue mentions

Paths as tags is implemented, but more cleanup to follow


Fixed formatting issue in README.md

A code blocks wasn't closed properly until the README file, causing some formatting issues.

I'll merge this for now, but it's already fixed on the internal repository so it will be cleared from the git history pretty soon.

Wow, what a pull request. So worth it, congratulations!


Pull in workshop basic re-work

Codecov Report

Merging #42 into pr_cleanup will decrease coverage by 24.13%.
The diff coverage is 91.97%.

@@               Coverage Diff               @@
##           pr_cleanup      #42       +/-   ##
===============================================
- Coverage       98.59%   74.45%   -24.14%
===============================================
  Files               2        5        +3
  Lines             355      685      +330
===============================================
+ Hits              350      510      +160
- Misses              5      175      +170

Impacted Files
Coverage Δ

servicex/servicex.py
59.94% <85.38%> (-39.02%)
:arrow_down:

servicex/cache.py
100.00% <100.00%> (ø)

servicex/data_conversions.py
100.00% <100.00%> (ø)

servicex/servicex_remote.py
100.00% <100.00%> (ø)

servicex/utils.py
83.42% <100.00%> (-14.73%)
:arrow_down:

Continue to review full report at Codecov.

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


IRuntime.stop() has unclear semantics in presence of local changes, delay-loaded channels

I'm not sure what snapshot collected by this API represents.
It can not produce correct design in presence of local changes, for two reasons:

Snapshotting logic assumes no local changes and likely works incorrectly (i.e. behavior is undefined)
Even if had some definition, serialization and de-serialization would either lose local state, or rehydrate it at the state where we can't properly ack local ops.

I believe all snapshotting and summarization calls should assert that pending state manager has no pending ops it's tracking - we need to add that.
The other part that is not very clear to me is what happens with data stores and DDSs that were not loaded yet, but have pending ops. I believe stop() will realize them all, which might be very expensive.
The overall problem is somewhat similar to data loss prevention that Wes is working on, but is complicated by potential code version differences, see here: https://github.com/microsoft/FluidFramework/pull/4597/files#r548197303
I believe we can partially solve it by

(staging) Starting with the serialization being just latest sequence number (semantically or literally), and rehydrating container at that sequence number. No other state (including local state) is saved, we lose local changes.
We move to move complicated design where

code proposal is actually not code proposal but document data schema proposal
99% cases are covered by code shipping dark, and existing code already understanding old and new data schema formats and be able to work with both (1% case results in data loss of local state).
We leverage data loss prevention work (Wes' work) to serialize container in old schema, and new code being able to rehydrate from it and start writing ops / snapshots in new data schema.

There's a lot to unpack in this issue, but let me try to ack the distinct problems first:

The reload snapshotting at best case loses local state, and at worst case may corrupt state since it cannot correctly understand inbound local ops after reloading.
The reload snapshotting will realize every data store/DDS that has ops in their pending queue. This is relatively expensive and unnecessary for hot-swap snapshot.

I think this issue is largely mitigated from issue #4600 (PR #4723), which makes it so that new code proposals that are incompatible (using the new "satisfies" function), will call ContainerContext.dispose() followed by Container.close(), then relying on the host to handle refreshing the page and loading a new container with new code. A key aspect here is that we no longer call ContainerContext.snapshotRuntimeState(), meaning we never call ContainerRuntime.stop().
We did add a loader option to enable hot-swapping container contexts (i.e. how it was working before), but we are just in a state of saying we don't fully support hot-swap.
Applying this refresh flow to the points above:

We lose local state, since we are disposing and closing. There should be no chance of corruption, since we have no pending local ops from the new Container's perspective.
We do not call the reload snapshot function, so we don't have this expensive wait. We do however have a page refresh, iframe swap, or something else that is likely expensive depending on how the host handles it.

@vladsud, for this issue, should we be thinking about cleaning up the hot-swap scenario? Or do we want to make changes to improve the new reload flow?

There's a lot to unpack in this issue, but let me try to ack the distinct problems first:

The reload snapshotting at best case loses local state, and at worst case may corrupt state since it cannot correctly understand inbound local ops after reloading.
The reload snapshotting will realize every data store/DDS that has ops in their pending queue. This is relatively expensive and unnecessary for hot-swap snapshot.

I think this issue is largely mitigated from issue #4600 (PR #4723), which makes it so that new code proposals that are incompatible (using the new "satisfies" function), will call ContainerContext.dispose() followed by Container.close(), then relying on the host to handle refreshing the page and loading a new container with new code. A key aspect here is that we no longer call ContainerContext.snapshotRuntimeState(), meaning we never call ContainerRuntime.stop().
We did add a loader option to enable hot-swapping container contexts (i.e. how it was working before), but we are just in a state of saying we don't fully support hot-swap.
Applying this refresh flow to the points above:

We lose local state, since we are disposing and closing. There should be no chance of corruption, since we have no pending local ops from the new Container's perspective.
We do not call the reload snapshot function, so we don't have this expensive wait. We do however have a page refresh, iframe swap, or something else that is likely expensive depending on how the host handles it.

@vladsud, for this issue, should we be thinking about cleaning up the hot-swap scenario? Or do we want to make changes to improve the new reload flow?

After discussion, I think the resolution to this issue is to move towards deleting the code that supports hot-swap context reload for now. There will be some work to rebuilding it (i.e. keeping runtime/summarizer stable through reload), but since we aren't using it at all for now, it will become stale anyway.
This should include deleting the old stop and snapshot functions, though there might be some other lingering dependencies, we can at least deprecate them and move towards deleting them.

After discussion, I think the resolution to this issue is to move towards deleting the code that supports hot-swap context reload for now. There will be some work to rebuilding it (i.e. keeping runtime/summarizer stable through reload), but since we aren't using it at all for now, it will become stale anyway.
This should include deleting the old stop and snapshot functions, though there might be some other lingering dependencies, we can at least deprecate them and move towards deleting them.


[Tubi] Extract audio language metadata if available.

Checklist

[X] I'm requesting a site-specific feature
[X] I've verified that I'm running yt-dlp version 2022.07.18 (update instructions) or later (specify commit)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've searched the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[X] I've read about sharing account credentials and I'm willing to share it if required

Region
USA
Example URLs
Film
English (Default, no language listed):
https://tubitv.com/movies/531743/yu-gi-oh-the-movie?start=true
Spanish: https://tubitv.com/movies/532867/una-familia-de-tantas?start=true
Swedish: https://tubitv.com/movies/475177/all-things-fair?start=true
Japanese: https://tubitv.com/movies/646274/the-legend-of-the-stardust-brothers?start=true
Chinese: https://tubitv.com/movies/522280/operation-mekong?start=true
Show
English: https://tubitv.com/tv-shows/365497/s01-e01-the-heart-of-the-cards?start=true
Spanish: https://tubitv.com/tv-shows/520360/s01-e01-el-corazon-de-los-naipes?start=true
Provide a description that is worded well enough to be understood
Currently yt-dlp sets the audio language metadata to English on any download from Tubi. On the video pages they include labels within the webpage for any media that is non-English and if there is no label then it is English (Default/No Label = English). There seems to be no other place than the webpage that mentions the language.
I've listed some links for different languages above, for both movies and shows. I've also noticed that some pages have multiple listed to be specific like:
Chinese, Mandarin, Sanskrit https://tubitv.com/movies/449366/extraordinary-mission?start=true
Not sure how or if this could be implemented but seeing as there was no open issue for it I thought I'd bring it up to see if there's a way to do it natively instead of the hacky way I'm getting it with xidel.
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
# peepee@poopoo:[~]: ./yt-dlp_linux -vU https://tubitv.com/tv-shows/520360/s01-e01-el-corazon-de-los-naipes?start=true
[debug] Command-line config: ['-vU', 'https://tubitv.com/tv-shows/520360/s01-e01-el-corazon-de-los-naipes?start=true']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version 2022.07.18 [135f05e] (linux_exe)
[debug] Python 3.10.5 (CPython 64bit) - Linux-5.11.0-41-generic-x86_64-with-glibc2.33 (glibc 2.33)
[debug] Checking exe version: ffmpeg -bsfs
[debug] Checking exe version: ffprobe -bsfs
[debug] exe versions: ffmpeg 4.3.2-0, ffprobe 4.3.2-0, phantomjs 2.1.1
[debug] Optional libraries: Cryptodome-3.15.0, brotli-1.0.9, certifi-2022.06.15, mutagen-1.45.1, secretstorage-3.3.2, sqlite3-2.6.0, websockets-10.3
[debug] Proxy map: {}
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Latest version: 2022.07.18, Current version: 2022.07.18
yt-dlp is up to date (2022.07.18)
[debug] Using fake IP <IP_ADDRESS> (US) as X-Forwarded-For
[debug] [TubiTv] Extracting URL: https://tubitv.com/tv-shows/520360/s01-e01-el-corazon-de-los-naipes?start=true
[TubiTv] 520360: Downloading JSON metadata
[TubiTv] 520360: Downloading m3u8 information
[debug] Formats sorted by: hasvid, ie_pref, lang, quality, res, fps, hdr:12(7), vcodec:vp9.2(10), acodec, filesize, fs_approx, tbr, vbr, abr, asr, proto, vext, aext, hasaud, source, id
[debug] Default format spec: bestvideo*+bestaudio/best
[info] 520360: Downloading 1 format(s): 1406
[debug] Invoking hlsnative downloader on "https://manifest.production-public.tubi.io/e8ea92fa-9af7-4c12-876c-6c2758b65f53/un9bncei/stream.m3u8?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjZG5fcHJlZml4IjoiaHR0cHM6Ly9mYXN0bHkudHViaS52aWRlbyIsImNvdW50cnkiOiJVUyIsImRldmljZV9pZCI6IjNkMDk2NGE2LTUzNDctNDI1My05YTA1LThiODQzZDk2ZTY5MyIsImV4cCI6MTY1OTQxNDkwMCwicGxhdGZvcm0iOiJXRUIiLCJ1c2VyX2lkIjowfQ.G5FlgIrt1_GLsMPquA2EgvnaZvOdbcgS1hIhN0dqXVE&manifest=true"
[hlsnative] Downloading m3u8 manifest
[hlsnative] Total fragments: 374
[download] Destination: S01 -E01 - El Corazon De Los Naipes! [520360].mp4
[download] 100% of 208.86MiB in 00:35
[debug] ffprobe command line: ffprobe -hide_banner -show_format -show_streams -print_format json 'file:S01 -E01 - El Corazon De Los Naipes! [520360].mp4'
[FixupM3u8] Fixing MPEG-TS in MP4 container of "S01 -E01 - El Corazon De Los Naipes! [520360].mp4"
[debug] ffmpeg command line: ffmpeg -y -loglevel repeat+info -i 'file:S01 -E01 - El Corazon De Los Naipes! [520360].mp4' -map 0 -dn -ignore_unknown -c copy -f mp4 -bsf:a aac_adtstoasc -movflags +faststart 'file:S01 -E01 - El Corazon De Los Naipes! [520360].temp.mp4'

# peepee@poopoo:[~]: mediainfo "S01 -E01 - El Corazon De Los Naipes! [520360].mp4" | grep 'Language'
Language                                 : English

On the video pages they include labels within the webpage for any media that is non-English and if there is no label then it is English

I don't see the labels. Could you show a screenshot?

Sorry for the late reply, it seems that since my original message they updated the site and removed the language label on the webpage. The only place I could find it was in the page source but at that point it's not worth the trouble.
Not sure if it's a bug with the new design or whatever but if they ever properly display it on the page again I'll reopen the issue.


Count number of files linted

We had some issues with globs when running tslint via npm (solved by adding quotes as per https://github.com/palantir/tslint/issues/1862). While we were investigating the issue it was really hard to tell if tslint was running as expected or not. In the end we had to deliberately break the linting in certain files to check tslint was linting the files we expected. I couldn't see anyway of enabling any verbose or debug output (for example) to show how many files have been linted. Is this a feature that would be of interest/fit with the direction of tslint? If so, I would be willing to work on a PR for it.

There's already an issue tracking this feature request. I'm closing this in favor of #2267


Method get_concrete_platform(::AbstractPlatform, ::Vector{CompilerShard}) not defined

That leads to errors whenever using any platform that is not of type Platform, e.g.:
julia> using BinaryBuilder

julia> BinaryBuilder.runshell(Linux(:x86_64);verbose=true)
[ Info: Checking to see if /home/jessica/Julia/libmpdec_builder/ is encrypted...
[ Info: Checking to see if /home/jessica/.julia/packages/BinaryBuilderBase/nW1CT/deps/ is encrypted...
ERROR: MethodError: no method matching get_concrete_platform(::Linux, ::Vector{BinaryBuilderBase.CompilerShard})
Closest candidates are:
  get_concrete_platform(::Platform, ::Vector{BinaryBuilderBase.CompilerShard}) at /home/jessica/.julia/packages/BinaryBuilderBase/nW1CT/src/utils.jl:23
  get_concrete_platform(::AnyPlatform, ::Vector{BinaryBuilderBase.CompilerShard}) at /home/jessica/.julia/packages/BinaryBuilderBase/nW1CT/src/utils.jl:61
  get_concrete_platform(::AbstractPlatform; kwargs...) at /home/jessica/.julia/packages/BinaryBuilderBase/nW1CT/src/utils.jl:55
  ...
Stacktrace:
 [1] get_concrete_platform(platform::Linux; kwargs::Base.Iterators.Pairs{Union{}, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
   @ BinaryBuilderBase ~/.julia/packages/BinaryBuilderBase/nW1CT/src/utils.jl:57
 [2] get_concrete_platform(platform::Linux)
   @ BinaryBuilderBase ~/.julia/packages/BinaryBuilderBase/nW1CT/src/utils.jl:56
 [3] BinaryBuilderBase.UserNSRunner(workspace_root::String; cwd::String, workspaces::Vector{Pair}, mappings::Vector{Pair}, platform::Linux, extra_env::Dict{String, String}, verbose::Bool, compiler_wrapper_path::String, toolchains_path::String, src_name::String, shards::Nothing, kwargs::Base.Iterators.Pairs{Union{}, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
   @ BinaryBuilderBase ~/.julia/packages/BinaryBuilderBase/nW1CT/src/UserNSRunner.jl:43
 [4] runshell(::Type{BinaryBuilderBase.UserNSRunner}, platform::Linux; verbose::Bool, kwargs::Base.Iterators.Pairs{Union{}, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
   @ BinaryBuilderBase ~/.julia/packages/BinaryBuilderBase/nW1CT/src/Runner.jl:1062
 [5] runshell(platform::Linux; kwargs::Base.Iterators.Pairs{Symbol, Bool, Tuple{Symbol}, NamedTuple{(:verbose,), Tuple{Bool}}})
   @ BinaryBuilderBase ~/.julia/packages/BinaryBuilderBase/nW1CT/src/Runner.jl:1054
 [6] top-level scope
   @ REPL[3]:1

The problem is using the platform as Linux(:x86_64), should use Platform("x86_64", "linux") instead.  Linux(:x86_64) is a simple compatibility shim with the old way platforms were defined, but it doesn't work very well and should be avoided.
Did you find
BinaryBuilder.runshell(Linux(:x86_64);verbose=true)

suggested somewhere in documentation?  We should remove it if that's the case

I found that call in another (unrelated) issue. However, in the section Build Tips, there is a link to Patchelf build_tarballs.jl which contains the lines:
platforms = [
    Linux(:x86_64, :glibc)
]

Creating a build_tarballs.jl with, e.g., Linux(:x86_64) in platforms also leads to the same problem.

In any case, if these constructors are to be avoided, I suggest they should be deprecated.

I'd love to :slightly_smiling_face:
@staticfloat can we remove the old constructors Linux(...), etc?  They don't really serve any purpose besides being confusing and causing errors.


ipfs: 0.4.4 -> 0.4.5-pre

Motivation for this change
Also updates ipfsapi to a more current version that contains a lot of bugfixes/features which are not available in the version on pypi.
Things done

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

[ ] NixOS
[ ] macOS
[x] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

While the python ipfsapi is -pre since there has not been an official release yet, ipfs itself is final.

A new repo version in a minor release? Jeez…


Add typing and type checking to tests

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 85.13%. Comparing base (4934386) to head (bedc805).
Report is 17 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #190      +/-   ##
==========================================
+ Coverage   83.22%   85.13%   +1.91%
==========================================
  Files          10       10
  Lines         900      895       -5
==========================================
+ Hits          749      762      +13
+ Misses        151      133      -18

Flag
Coverage Δ

pytest
85.13% <ø> (+1.91%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

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


Bug/devtooling 752 Integration Credential Fix

@HemanthDogiparthi12 can you work with @kavinbalagen to test this provider with the workitems automation.  Kavin we added the oauth client credential creation work to automate the creating of an oauth client for work item automation.  I want to make sure that accelerator still works after your changes.


Running make-clean / tf-reinit doesn't always work to refresh the state files

Describe the bug
We are a team of 3 developers deploying flowerehr on a single tenant.
Someitmes the state files have changed, and requests us to import the resources individually.
We try to run make-reinit command to update the lock files and backend state changes but after that runs successfully, it still requests to import some of the modules.
Are there better ways to manage the state file? something like remote state ?

State files are persisted remotely when running via CI. For local scenarios, it sounds like a remote resource is being modified outside of TF's state and that's when TF would prompt to manually import, so try to avoid this and only make changes via FlowEHR's make commands.
Closing as this sounds like an issue unrelated to codebase, but feel free to re-open if any questions or new errors.


Make reconciler only reconcile mesos tasks.

Changes proposed in this PR

Make reconciler only reconcile mesos tasks.

Why are we making these changes?
Right now if you have kubernetes + mesos enabled, the mesos reconciler sees all these kubernetes jobs not running in mesos and kills them off. Make the mesos reconciler only look at jobs in the relevant compute cluster instead.

Will merge when green


Do not fail on non-existing or “empty” script compilation

Do not consume ScriptSource TextResource nullable file property.
Rework the multi-kotlin-project-config-injection sample to demonstrate
a subproject with no build script.
See #302

After discussing this with @bamboo, we decided step back and fix that once we migrated to the new Kotlin embedded compiler API.


Add Moq.Analyzers.Benchmarks with a single sample benchmark

Add the project Moq.Analyzers.Benchmarks with a sample benchmark for diagnostic Moq1300. This pattern is copied from https://github.com/dotnet/roslyn-analyzers/blob/f1115edce8633ebe03a86191bc05c6969ed9a821/src/PerformanceTests/Tests/Enabled/CSharp_CA1416.cs, but where possible I used the types exposed by the Microsoft.CodeAnalysis.*.Testing libraries instead.
As part of the exercise, I filed https://github.com/dotnet/roslyn-sdk/issues/1165 to discuss if some of these helpers should move into the testing packages, and / or to document any existing profiling best practices.
This change doesn't attempt to hook the benchmarks into CI in any way; they're both currently too slow for that, and I'm not yet sure what (if anything) to gate on.

Here's a sample of the output:
| Method                 | Mean     | Error    | StdDev   | Median   | Ratio | RatioSD | Gen0      | Gen1      | Allocated | Alloc Ratio |
|----------------------- |---------:|---------:|---------:|---------:|------:|--------:|----------:|----------:|----------:|------------:|
| Moq1300WithDiagnostics | 378.6 ms | 12.70 ms | 37.26 ms | 371.9 ms |  1.80 |    0.29 | 9000.0000 | 3000.0000 |  58.72 MB |        1.37 |
| Moq1300Baseline        | 215.3 ms | 11.45 ms | 33.75 ms | 205.8 ms |  1.00 |    0.00 | 7000.0000 | 2000.0000 |  42.95 MB |        1.00 |


Is there a plan to eventually support Vue3?

Do you have any plans to support Vue3 in the near future? This looks like a good project, but I want to make sure it will be forward compatible. Thanks for your hard work!

Hi there, the 3.x release is available now.
npm install<EMAIL_ADDRESS>

The Slideout@3 used to work with Vue@3


Add prometheus metrics about the latency on the task queue

It should be done after https://github.com/meilisearch/meilisearch/pull/5044; otherwise, there will be a ton of conflicts.
It should also probably be done using the work of this PR: https://github.com/meilisearch/meilisearch/pull/5048
We should add the duration between now (at the time of the polling) and the enqueuedAt time of the oldest enqueued or processing task.
That gives us a measure of the global indexing latency of the engine.
To retrieve the oldest enqueued task, we can do a filtered query to the task queue with a limit of 1 and the reverse parameter introduced in the PR above.

I'll work on this!


Replace "watch"

Replace watch with node-watch in order to get a more streamlined codebase.
https://www.npmjs.com/package/node-watch

Oh, and make an interface for it, such that the IO isn't so weird and proprietary


more ws old code cleanup (leftovers from #425)

@Ivan-Shestakov to check it as part of the sanity and close


Improvements to table on curation app import page

Since deployment of       there are some bugs in the display of the data tables (studies, samples, associations) on the import page e.g. https://www.ebi.ac.uk/gwas/curation/submissions/625dbb2d0b24d90001d11e65?

Table should display a blank field or hyphen for missing data, rather than "undefined", which hampers readability

Search box is not functional and should be fixed.

Some strange fields appear that are not required for submissions, e.g. "Haplotype ID" @earlEBI please provide a list of any fields that are displayed, but should not be, or any additional fields that are needed.

Fields that should be displayed:
studies tab

Reported trait (currently shows the 'trait' but this is taken from the submission form which is not necessarily correct. It should match the reported trait field in Depocuration after traits have been uploaded.
EFO label
Background EFO label

Fields that should not be displayed:
studies tab:

Sample desc.

Associations
- Haplotype ID
- beta direction


core dumped issue

There is issue in line 5051 of  stbi__shiftsigned function of stb_image.h file, which cause a denial of service (assert fault) via a crafted bmp file.
5035 static int stbi__shiftsigned(int v, int shift, int bits)
5036 {
...
5049    STBI_ASSERT(v >= 0 && v < 256);
5050    v >>= (8-bits);
5051    STBI_ASSERT(bits >= 0 && bits <= 8);
5052    return (int) ((unsigned) v * mul_table[bits]) >> shift_table[bits];
5053 }
root@ubuntu:/libsixel-master/converters# ./img2sixel crafted.bmp
lt-img2sixel: stb_image.h:5051: stbi__shiftsigned: Assertion `bits >= 0 && bits <= 8' failed.
Aborted (core dumped)
Guoxiang Niu, Xiaolong Zhao, Muxing Guan, EaglEye Team

Fixed on v1.8.4, Thanks!


add license

The same problem as https://github.com/crypto-browserify/browserify-cipher/issues/2#issuecomment-380214214 occurs here too.


CSUB-829 Remove unused pallet/staking (CC2)

Description of proposed changes
Remove staking pallet
Practical tips for PR review & merge:

[ ] All GitHub Actions report PASS
[ ] Newly added code/functions have unit tests

[ ] Coverage tools report all newly added lines as covered
[ ] The positive scenario is exercised
[ ] Negative scenarios are exercised, e.g. assert on all possible errors
[ ] Assert on events triggered if applicable
[ ] Assert on changes made to storage if applicable

[ ] Modified behavior/functions - try to make sure above test items are covered
[ ] Integration tests are added if applicable/needed

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (fe5f85b) 75.94% compared to head (12df204) 13.68%.

Additional details and impacted files
@@             Coverage Diff             @@
##              dev    #1506       +/-   ##
===========================================
- Coverage   75.94%   13.68%   -62.26%
===========================================
  Files          80       31       -49
  Lines       12122     1001    -11121
  Branches        0      128      +128
===========================================
- Hits         9206      137     -9069
+ Misses       2916      864     -2052

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

@nathanwhit For upgrading versions, is this minor or patch update?

@nathanwhit For upgrading versions, is this minor or patch update?

I think that qualifies as spec_version -> 238, impl_version -> 0! The number in Cargo.toml follows version.rs.


WIN GUI 1.0.5 Wallet Connection problem

The "Connecting to Wallet" justs spins, but when I do a reload or force reload, the developer view shows the message "already connected, not reconnecting." And temp drive activity indicates that plotting is still occurring, so I am hesitant to restart/reboot. Is this a bug? Is there a workaround? Please advise.

I already fixed it. It will be part of RPC refactoring

Awesome! Thanks.
New single: "life"
| See the video: RUSS TOLMAN I LOVE LIGHTNING (FEAT. JAWBO)
Catch my radio show, "My Kinda Country," every Thursday, 2pm Pac on GimmeCountry.com
|
On Wednesday, April 21, 2021, 10:17:06 AM PDT, Zlatko Fedor<EMAIL_ADDRESS>wrote:

I already fixed it. It will be part of RPC refactoring
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I already fixed it. It will be part of RPC refactoring

Hi I read  under windows tip[s & tricks wiki" Sometimes your wallet database can get corrupted. If you get stuck on the "Connecting to wallet" spinner for more than 60 seconds, you will probably want to exit the app, delete your wallet database with Powershell, and then start the app again.
For version 1.0.x:
cd ~.chia\mainnet\wallet\db
del *.sqlite"
if I do that what happens - do I lose all my plots


tools/ci: update avr-gcc version for OSX

Summary
Experiments to fix MACOS CI
Impact
Testing

macOS build is very unstable recently, @pkarashchenko do you have any finding?

No. Just experimenting here. AVG GCC 12 does not provide correct symlinks unfortunately and I will need to think what to do. I thought that maybe an update of this component will give some influence. I will keep experimenting. Locally on my MacBook Pro all works well

avr ci already upstream, let's close this pr.


unit test won't clean up db after running

It's same as this issue from framework main repo. seems like here is a better place for it:
I'm using Yii2 module: (note that cleanup is enabled)
class_name: UnitTester
modules:
    enabled:
        - Yii2:
            part: ORM
    config:
        Yii2:
            cleanup: true
            configFile: '../config/backend/unit.php'

working with haveRecord() and seeRecord() methods:
    public function testWebsiteInsertion()
    {
        $this->tester->haveRecord(
            Website::className(),
            [
                'title' => 'test site',
                'language' => 'fa',
                'subdomain' => 'test',
                'themeId' => 1
            ]
        );

        $this->tester->seeRecord(
            Website::className(),
            ['subdomain' => 'test']
        );
    }

It does not clean up db after running! I traced it down to here Codeception\Module\Yii2::_after() :
        if ($this->transaction && $this->config['cleanup']) {
            $this->transaction->rollback();
        }

The if condition is true and transaction does rollback, but inserted rows do not get removed! I even traced Transaction class in framework core and there were no errors. I'm really stuck, did I miss something? are there other configurations?

@hesna Hello, I have the same problem. Have you found the solution?

We've recently patched Codeception module a bit. Could you try Codeception 2.1-dev?

@kaiserfedor Hi, sorry I have not. and have not yet tried this :point_up_2:

@samdark I've updated Codeception to 2.1.x-dev and problem is still reproduced, unfortunately.
I've tried begin and rollback transaction explicitly in test and it works well, but it's not solution.

I solve problem by modified method yiisoft/yii2-codeception/TestCase::mockApplication
https://github.com/yiisoft/yii2-codeception/blob/master/TestCase.php#L105
I added this code to begining of method:
if (isset(Yii::$app)) {
    return;
}

The problem is Codeception module begin transaction in one db connection and then TestCase::mockApplication create another db connection.

Are you sure you've checked latest 2.1 branch code? https://github.com/Codeception/Codeception/commit/c90ace2b69ee2332740018ff0489399ed7c89ada

@samdark  Yes, of course. This is part of my composer.lock:
"name": "codeception/codeception",
            "version": "2.1.x-dev",
            "source": {
                "type": "git",
                "url": "https://github.com/Codeception/Codeception.git",
                "reference": "c90ace2b69ee2332740018ff0489399ed7c89ada"
            },

Is it OK?

@ivokund isn't it the same thing your commit was intended to solve?

It's very similar, although not exactly the same thing. https://github.com/Codeception/Codeception/commit/c90ace2b69ee2332740018ff0489399ed7c89ada solved the same issue inside Yii2 connector. So when modules use it to create a testable application mocks (in functional tests), the same database connection is used in every one of these mock applications. Now the module and connector share the DB instance, so the rollbacks work correctly. But this is different, I believe Yii2 connector is not used here at all.
I have two ideas/guesses:

\Codeception\Module\Yii2::getModelRecord creates a new model object. Is the attached DB instance the same that's used here? Perhaps it should use the DB instance from the connector ($this->app->db) somehow?
Does this interfere with the transaction rollback logic? Probably not.

But I'm not sure in any of this. @Ragazzo can probably shed some light on this.

As I wrote above the problem is Codeception module create app instance here:
https://github.com/Codeception/Codeception/blob/2.1/src/Codeception/Lib/Connector/Yii2.php#L61
And then extension create another app instance here:
https://github.com/yiisoft/yii2-codeception/blob/master/TestCase.php#L120
This way transaction and test use different db connection.
I've created pull request, maybe it would be helpful:
https://github.com/yiisoft/yii2-codeception/pull/12

why you are using Yii2 connector in your unit tests ?

I'm not using Yii2 connector in my unit tests, I'm just using orm part of Yii2 module for cleanup database after unit tests like it describe in part "ORM modules" here http://codeception.com/docs/09-Data and here http://codeception.com/06-28-2014/unit-testing-with-database.html

for database cleanup in Yii2 you can use fixtures as was stated in docs for Yii2, thus you will not run in this problem. The basic workflow for unit-tests:

run migrate command to make your database schema up to date;
use fixtures in setUp / tearDown methods to populate schema with needed data or to clean up it;

I talk about remove data that have been insert into db while test is executed, not about data from fixture.

you can do it in tearDown anyway, plus you can write your own fixture if needed to remove this data, if it should be removed in other places too

Ok, I can do it in tearDown, I know it.  But @hesna and I talk about feature that is  described in official documentation, why should we not use it?

nope, you can use it but there is a drawback for that, initially it was not designed to use them both since for Yii2 we made fixtures and so on. But your fix will be incorrect for unit tests when you need to mock application for specific purpose in particular in one of the test methods in test case.

@Ragazzo I was just trying to figure out how things work at the time. you mean this feature works in functional tests? I actually gave up on it and used fixtures instead, but this feature is not working as it's supposed to and others might face with same problem. maybe it's better to get rid of cleanup option and make everyone use fixtures for this purpose?

yes, as for me it is better to remove this feature of cleanup, it was introduced by @DavertMik for his purposes when he was working with Yii2 and transactions rollback, thus it creates a lot of unnecessary questions and issues.

Please leave this option at least for functional tests (where it now works correctly). Rollbacks are a lot cleaner and faster way to undo all changes, than unloading fixtures.
Probably it would help to mention that it's only meant for functional tests. Plus the cleanup flag is currently not mentioned here at all: http://codeception.com/docs/modules/Yii2


The guid number '$(applicationInsightsKey)' does not match the expected pattern:

Describe the issue
Getting this error when running Run-AlPipeline from DevOps-Pipeline.ps1
##[error]c:\sources\MainApp Library\app.json(46,5): error AL1040: The guid number '$(applicationInsightsKey)' does not match the expected pattern: "^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$".
I ran with both version 2.0.16 and 2.0.17-dev with the same result.
Scripts used to create container and cause the issue
Used the same scripts and setup from the CICD hands-on lab with different app folders and secrets.
The app that is failing to compile doesn't have the 'applicationInsightsKey' but the 'applicationInsightsConnectionString'
"applicationInsightsConnectionString": "InstrumentationKey=ce0dddb9-0000-0000-0000-6e4291c6b5ef;IngestionEndpoint=https://westus2-0.in.applicationinsights.azure.com/",
Full output of scripts
...
Set appFolders = 'MainApp,MainApp Library'
Set testFolders = 'MainApp TestApp'
Set memoryLimit = '6G'
Set additionalCountries = 'dk,gb'
Set genericImageName = ''
Set vaultNameForLocal = 'CICDBuildVariables'
Set bcContainerHelperVersion = 'dev'
Set installTestRunner = True
Set installTestFramework = False
Set installTestLibraries = False
Set installPerformanceToolkit = False
Set enableCodeCop = False
Set enableAppSourceCop = True
Set enablePerTenantExtensionCop = False
Set enableUICop = True
Set useDefaultAppSourceRuleSet = False
Set doNotSignApps = True
Set doNotRunTests = False
Set cacheImage = False
Set CreateRuntimePackages = False
Downloading https://github.com/microsoft/navcontainerhelper/archive/dev.zip
BcContainerHelper version 2.0.17-dev
Determining artifacts to use
Found https://bcinsider.azureedge.net/sandbox/19.1.31832.0/us
Found https://bcinsider.azureedge.net/sandbox/19.1.31832.0/dk
Found https://bcinsider.azureedge.net/sandbox/19.1.31832.0/gb
.
.
.

 All rights reserved

##[warning]c:\sources\MainApp Library\app.json(46,5): warning AL0667: 'applicationInsightsKey' is being deprecated in the versions: '7.2' or greater. This property is being deprecated in favor of 'applicationInsightsConnectionString'. This warning will become an error in a future release.
##[error]c:\sources\MainApp Library\app.json(46,5): error AL1040: The guid number '$(applicationInsightsKey)' does not match the expected pattern: "^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$".
App generation failed with exit code 1
Removing container notraefik1-cloudrelease-nextminor
Removing notraefik1-cloudrelease-nextminor from container hosts file
Removing notraefik1-cloudrelease-nextminor-* from container hosts file
Removing C:\ProgramData\BcContainerHelper\Extensions\notraefik1-cloudrelease-nextminor
##[error]App generation failed with exit code 1

Didn't notice the Run-AlPipeline -applicationInsightsKey parameter was not getting any value, I didn't assign the variable $applicationInsightsKey


Remove Windows support (hopefully temporarily)

Perhaps this can be reverted once a viable solution for #5 has been found.

Well, not reverted in the GitHub PR sense, since this also includes a bunch of unrelated changes, but removal of Windows part could be manually reversed.


upd(insync-deb): <IP_ADDRESS>459 -> <IP_ADDRESS>481

@Henryws any ideas?

Add incompatible

Add incompatible

Why? I've specifically included the debian deb.

But it fails on Debian.

But it fails on Debian.

That's what I'm asking you, do you have any ideas why it's failing? The CI isn't helpful.

I got no idea.

Oh it's sysctl. I'll merge it, most normal systems have it.


got a cpu miner connected, incorrect hashrate

his hashrate is 859 undefined, i think hes only doing 3 sols and he is giving 800 minisols or so ;-)

Should be fixed now.


LLM response format structuring while streaming?

Hello,
With LangChain, I am able to quite easily stream LLM responses in a particular format (say, JSON), via JsonOutputFunctionsParser (see this doc, with { diff: false}), and get structured JSON every step of the stream.
With LangGraph, I am following this guide to ensure the agent responds in JSON format. However, this essentially breaks streaming: the LLM's structured output is not streamed token-by-token, as it is in LangChain – it comes out all at once. If I use the streamEvents API in combination with the response tool described in the previous guide to stream LLM output token-by-token, the structure enforcement breaks and I get no output.
Has anyone succeeded in this in LangGraph?

Hey @epleaner, thanks for raising this! I've added an example here:
https://langchain-ai.github.io/langgraphjs/how-tos/respond-in-format/#partially-streaming-json

Hey @jacoblee93 , thanks for the response. However, the logs shown in the LangGraph example you've linked do not show structured JSON at every step of the stream. The LangChain example I've linked in my original post does log structured JSON at every step of the stream.

do not show structured JSON at every step of the stream

Ah I see what you're saying, yeah will update later today.

Actually, I added it here:
      // You can also log the raw args instead:
      // console.log(chunk.tool_call_chunks);

Can you try that and LMK if it works for you? Keep in mind you may need to do some special parsing of args for points where we can't get fully valid JSON from the chunk.