[Feature] Ensure someone can defeat bounty before spawning

(optional) Is your feature request related to a problem?
Sometimes bounties spawn that are too powerful for everyone in the server, which pretty much hard locks the game.
Describe the solution you'd like
Make sure at least one person exist in the division that can defeat the bounty
(optional) Additional details
https://discord.com/channels/711548456019296289/711548456568750102/885557563326877716
(optional) Your discord tag
Novah

This should become unnecessary after #795
leaving it in candidate until we can test #795


How to use?

I immediately get shown the options page but I don't know what the keyboard shortcut is.

Hey Xof, in the options page, you should set up some shortcuts and save
them, and then you can test the shortcuts in the demo area. When you add a
new shortcut, the textfield on the left is the shortcut, and the textarea
to the right is the expanded text. Give that a shot and let me know if you
have any issues!
. Carlin
............................................
Product . Design . Development
e<EMAIL_ADDRESS>: +1<PHONE_NUMBER>
On Sun, May 3, 2015 at 11:20 AM, Xof Nagem<EMAIL_ADDRESS>wrote:

I immediately get shown the options page but I don't know what the
keyboard shortcut is.
—
Reply to this email directly or view it on GitHub
https://github.com/carlinyuen/ChromeAutoTextExpander/issues/13.


Clang compile error for file XLStyles.hpp

When trying to build a project that includes the OpenXLSX library I get below errors which causes ninja to fail:
[build] PATH/cpm-cache/openxlsx/d5fef227e58012c750c8837487d06d304d486720/OpenXLSX\headers\XLStyles.hpp:2126:9: error: explicitly defaulted copy constructor is implicitly deleted [-Werror,-Wdefaulted-function-deleted]
[build]  2126 |         XLStyles(const XLStyles& other) = default;
[build]       |         ^
[build] PATH/cpm-cache/openxlsx/d5fef227e58012c750c8837487d06d304d486720/OpenXLSX\headers\XLStyles.hpp:2193:45: note: copy constructor of 'XLStyles' is implicitly deleted because field 'm_numberFormats' has a deleted copy constructor
[build]  2193 |         std::unique_ptr    m_numberFormats;    // handle to the underlying number formats
[build]       |                                             ^
[build] C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.42.34433\include\memory:3451:5: note: 'unique_ptr' has been explicitly marked deleted here
[build]  3451 |     unique_ptr(const unique_ptr&)            = delete;
[build]       |     ^
[build] PATH/cpm-cache/openxlsx/d5fef227e58012c750c8837487d06d304d486720/OpenXLSX\headers\XLStyles.hpp:2126:43: note: replace 'default' with 'delete'
[build]  2126 |         XLStyles(const XLStyles& other) = default;
[build]       |                                           ^~~~~~~
[build]       |                                           delete
[build] PATH/cpm-cache/openxlsx/d5fef227e58012c750c8837487d06d304d486720/OpenXLSX\headers\XLStyles.hpp:2139:19: error: explicitly defaulted copy assignment operator is implicitly deleted [-Werror,-Wdefaulted-function-deleted]
[build]  2139 |         XLStyles& operator=(const XLStyles& other) = default;
[build]       |                   ^
[build] PATH/cpm-cache/openxlsx/d5fef227e58012c750c8837487d06d304d486720/OpenXLSX\headers\XLStyles.hpp:2193:45: note: copy assignment operator of 'XLStyles' is implicitly deleted because field 'm_numberFormats' has a deleted copy assignment operator
[build]  2193 |         std::unique_ptr    m_numberFormats;    // handle to the underlying number formats
[build]       |                                             ^
[build] C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.42.34433\include\memory:3452:17: note: 'operator=' has been explicitly marked deleted here
[build]  3452 |     unique_ptr& operator=(const unique_ptr&) = delete;
[build]       |                 ^
[build] PATH/cpm-cache/openxlsx/d5fef227e58012c750c8837487d06d304d486720/OpenXLSX\headers\XLStyles.hpp:2139:54: note: replace 'default' with 'delete'
[build]  2139 |         XLStyles& operator=(const XLStyles& other) = default;
[build]       |                                                      ^~~~~~~
[build]       |                                                      delete
[build] 2 errors generated.

As per https://github.com/troldal/OpenXLSX/commit/02f7d4243ecfcbd6b03174228290653983f7a634#diff-6df3199d905212627966d86c63ed0230a5f5e6d5643421752d3fc8f5a35a1099R2116 and following, I hope for this issue to no longer occur - @MoniqueRFC could you verify from the development-aral branch whether this is resolved now?

Thanks for taking care of it. I am getting two new errors though, while the original ones disappeared:
[build] In file included from PATH/openxlsx/47bc049774588e82186b6578589f1d5d22f404ba/OpenXLSX\OpenXLSX.hpp:49:
[build] In file included from PATH/openxlsx/47bc049774588e82186b6578589f1d5d22f404ba/OpenXLSX\headers/XLCell.hpp:65:
[build] PATH/openxlsx/47bc049774588e82186b6578589f1d5d22f404ba/OpenXLSX\headers\XLStyles.hpp:1293:19: error: explicitly defaulted move assignment operator is implicitly deleted [-Werror,-Wdefaulted-function-deleted]
[build]  1293 |         XLBorder& operator=(XLBorder&& other) noexcept = default;
[build]       |                   ^
[build] PATH/openxlsx/47bc049774588e82186b6578589f1d5d22f404ba/OpenXLSX\headers\XLStyles.hpp:1381:47: note: move assignment operator of 'XLBorder' is implicitly deleted because field 'm_nodeOrder' has no move assignment operator
[build]  1381 |         const std::vector< std::string_view > m_nodeOrder = { "left", "right", "top", "bottom", "diagonal", "vertical", "horizontal" };
[build]       |                                               ^
[build] PATH/openxlsx/47bc049774588e82186b6578589f1d5d22f404ba/OpenXLSX\headers\XLStyles.hpp:1293:58: note: replace 'default' with 'delete'
[build]  1293 |         XLBorder& operator=(XLBorder&& other) noexcept = default;
[build]       |                                                          ^~~~~~~
[build]       |                                                          delete
[build] PATH/openxlsx/47bc049774588e82186b6578589f1d5d22f404ba/OpenXLSX\headers\XLStyles.hpp:1659:23: error: explicitly defaulted move assignment operator is implicitly deleted [-Werror,-Wdefaulted-function-deleted]
[build]  1659 |         XLCellFormat& operator=(XLCellFormat&& other) noexcept = default;
[build]       |                       ^
[build] PATH/openxlsx/47bc049774588e82186b6578589f1d5d22f404ba/OpenXLSX\headers\XLStyles.hpp:1803:47: note: move assignment operator of 'XLCellFormat' is implicitly deleted because field 'm_nodeOrder' has no move assignment operator
[build]  1803 |         const std::vector< std::string_view > m_nodeOrder = { "alignment", "protection" };
[build]       |                                               ^
[build] PATH/openxlsx/47bc049774588e82186b6578589f1d5d22f404ba/OpenXLSX\headers\XLStyles.hpp:1659:66: note: replace 'default' with 'delete'
[build]  1659 |         XLCellFormat& operator=(XLCellFormat&& other) noexcept = default;
[build]       |                                                                  ^~~~~~~
[build]       |                                                                  delete
[build] 2 errors generated.

Thanks for checking! I am not very good with move and copy constructors yet, I basically started using them regularly when I started contributing here. I will fix those missing constructors and comment here when I upload a patch.

Gosh I hate how useless std::array is - I just realized these new errors come from me - by desperation - declaring what could be a static constexpr as a regular const for the insertion order arrays of XML element nodes.
std::array could be used in a constexpr, but it can't be passed to a function without either using a template OR providing both template arguments: the type therein and the amount of elements
:/ I will try to fix that now.

Okay, have a look at 7a726871e8e45e0c47302cbca0c39d5b2eac1b4c please - I made the offending const std::vector lines into inline static which appears to prevent the default copy-constructors & assignment operators from getting deleted.

Thank you very much for fixing this so fast despite all the obstacles, there are no more compile errors!! :)

Thank you for helping to improve the library! I'll close your related pull request now with reference to this issue. :)

@MoniqueRFC - would you be willing to test the newest patch to the development branch with CLang? Since I changed some lower level templated stuff, I would appreciate knowing whether there's anything the compiler will complain about, that I need to fix before merging into the master branch.
Help is appreciated! :)


powerdns: 4.2.0 -> 4.2.1

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/powerdns/versions.
meta.description for powerdns is: '"Authoritative DNS server"'.
meta.homepage for powerdns is: '"https://www.powerdns.com"

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 4.2.1 with grep in /nix/store/3y691ca57xcwyxdpfbg6akvvr0qwy18z-powerdns-4.2.1

directory tree listing: https://gist.github.com/1e51858f3835c720ec9bce1776b6a1d6

du listing: https://gist.github.com/b3eb6b74d2f6f48ce75f0160196417dd

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)
1 package rebuild(s)
1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
powerdns

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/3y691ca57xcwyxdpfbg6akvvr0qwy18z-powerdns-4.2.1 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A powerdns https://github.com/r-ryantm/nixpkgs/archive/394ec51d5cbbbe7ca7400ea612bb14b30b8c7939.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/3y691ca57xcwyxdpfbg6akvvr0qwy18z-powerdns-4.2.1
ls -la /nix/store/3y691ca57xcwyxdpfbg6akvvr0qwy18z-powerdns-4.2.1/bin

cc @mic92 @disassembler for testing.

@GrahamcOfBorg test powerdns


Move Canvas API funtion bindings into a CanvasContext object

Adds support for lineWidth property and strokeRect to demonstrate
CanvasContext class.
@nick-thompson, I've started messing with adding more of the Canvas API.  Thought I'd drop this PR over even if just as a discussion starter. Tried to encapsulate all the registering of native functions and properties into a little CanvasContext class so it's easily used from CavasView::paint().
If you like the general shape I can keep going with it and look at some Path2D support.

One interesting idea around Canvas API support is augmenting the standard CanvasRenderingContext2D API with some of the additional functions in juce such as drawRoundedRect (not part of the html Canvas API).
It would be nice to offer some additional drawing functions familiar to juce users without breaking the CanvasRenderingContext2D API and potential web based UIs.

Dropping comment here whilst I think about this.
Its actually probably not necessary to register methods and properties in every paint call. The CanvasContext class could simply have a pointer to a juce::Graphics instance as a data member.
Then in CanvasView::paint we just call CanvasContext::draw(&g) which reassigns the pointer uses in each of the native methods and callbacks and invokes onDraw etc. That could get rid of the overhead of registering methods in every single call to paint(). I'll experiment with it later when I return to my desk.

Woah, @JoshMarler you're amazing! Just seeing all these notifications now, I'll try to get through as much as I can this morning

@nick-thompson, No problem! there's no rush. Apologies if I've spammed you a little bit! I blame the lock-down and having little else to do!

@nick-thompson just sitting down to fixup the transform stuff and give this all a more thorough testing. I think having a transform member in CanvasContext will make the most sense based on the expected behaviour of the CanvasRenderingContext2D API. Be cool to hear your thoughts on the overall shape of this in the meantime. Still a slight work in progress. I'll aim to get this existing API calls all working flawlessly and won't add any further elements of the CanvasRenderingContext2D API until this PR goes in.

@JoshMarler overall, love this! Inheriting the DynamicObject is such a good idea, I never thought of it. Also you covered so much of the API already
I have two kind of high level thoughts– one of them is inline about the transform stuff, the other is: instead of receiving a pointer to a graphics context during paint, and a View ref at construction, what if the CanvasContext owned a juce::Image and all of the drawing routines happened on a juce::Graphics g(memberImage) pointing at that image? One on hand, that makes me feel a little better about lifetime stuff (referencing a raw pointer always makes me want to jassert everywhere and stuff), and on another I think that might leave room for some like easy draw routine caching. Then the CanvasView's paint() routine could basically be:
if (props["onDraw"] && props["onDraw"].isMethod()) {
    std::invoke(props["onDraw"].getNativeFunction(), args);
}
g.drawImageAt(canvasCtx->getImage(), 0, 0);

I think we would want to resize that image during CanvasView's resize() so that it always matches perfectly.
Besides that, I think instead of taking a View& at construction I'd rather implement a method on the CanvasContext that creates the js args for you. This way we avoid a circular dependency and the CanvasContext isn't necessarily coupled to a particular View as well. I could imagine somethign like this:
// This is CanvasView's `paint()` method
if (props["onDraw"] && props["onDraw"].isMethod()) {
    std::invoke(props["onDraw"].getNativeFunction(), canvasCtx->getNativeFunctionArgs());
}

What do you think? Besides those two ideas, I think this is basically ready to merge, and then we can tackle other paint methods in another PR as you suggested

@nick-thompson Ohh man yeah. I hadn't even thought about using an image. That could open up a really nice API for the look and feel override thing. Being able image states/UI snapshots etc. could open up all kinds of stuff. You clearly know the juce Graphics API better than me!
I'll have a go at this now.

@nick-thompson. Yeah nice the transform stack does the trick.

@nick-thompson, woop woop. Drawing to an image all working nicely. Will push up shortly. If it's cool with you I'd like to just give this whole PR a bit of a battle test. I'll try drawing various things just to make sure I haven't introduced any odd behaviour.

@nick-thompson, OK. So I have this all working with the transform stack and drawing to an Image in CanvasContext. However, resizing the image held by the CanvasContext isn't 100% straight forward.
We need to store a juce::Graphics instance in CanvasContext to preserve progressive transform state changes etc. (As per the current implementation). However, we cannot directly resize the image held by CanvasContext's Graphics instance so instead we need to replace/reconstruct the Graphics instance when we resize.
I can push the current working state up but basically in CanvasView::resize() we call the following CanvasContext::setSize() function:
        void CanvasContext::setSize(int width, int height)
        {
            image = juce::Image(juce::Image::ARGB, width, height, true);
            graphics = std::make_unique<juce::Graphics>(image);
        }

        void CanvasView::resized() override
        {
            ctx->setSize(getWidth(), getHeight());
        }

        void CanvasView::paint (juce::Graphics& g) override
        {
            View::paint(g);

            jassert(ctx);

            if (props.contains("onDraw") && props["onDraw"].isMethod())
            {
                std::vector<juce::var> jsArgs {{ctx.get()}};
                juce::var::NativeFunctionArgs nfargs (juce::var(), jsArgs.data(), jsArgs.size());

                std::invoke(props["onDraw"].getNativeFunction(), nfargs);
            }

            g.drawImageAt(ctx->getImage(), 0, 0);
        }

This all seems to be working fine and I thiiink this is OK but do you feel there is any more elegant way to do this? Drawing to an Image is really powerful and perfectly fits in with my look and feel requirement so I'd like to take that approach as you've suggested.

@nick-thompson, OK. So I have this all working with the transform stack and drawing to an Image in CanvasContext. However, resizing the image held by the CanvasContext isn't 100% straight forward.
We need to store a juce::Graphics instance in CanvasContext to preserve progressive transform state changes etc. (As per the current implementation). However, we cannot directly resize the image held by CanvasContext's Graphics instance, so instead we need to replace/reconstruct the Graphics instance when we resize.
I can push the current working state up but basically in CanvasView::resize() we call the following CanvasContext::setSize() function:

Ahhh right right, of course. Yea, I think your idea is great. The only thing I can think of is that if we're hanging onto the Graphics instance as a member variable, we'll probably want to make sure to reset the graphics context (https://docs.juce.com/master/classGraphics.html#ab8b7cd49bf1ff738c5ff848727e3bc75) at the beginning of CanvasView::paint(), otherwise context state changes (such as transformations) will accumulate with each successive call to onDraw
Besides that, yea, happy to go ahead with this plan, then squash and merge! And I'd love your help with the README afterwards. Thanks @JoshMarler

Ahh yeah, good shout on the reset. Not clear if resetToDefaultState clears transforms but failing that it's easy enough to just add a reset function to CanvasContext which resets the Graphics unique_ptr. Awesome. Will finish this all off first thing tomorrow

@nick-thompson. One other question I've ignored until now before we merge this.
Juce has slightly different path behaviour to the Canvas if we take a circle drawing example:
https://www.w3schools.com/html/tryit.asp?filename=tryhtml5_canvas_tut_path2
In the above example there is no need for a call to moveTo() before the call to arc(). Juce on the other hand will stroke the path from 0,0 to the start of the arc position.
I.e the following code doesn't product the same thing as the linked browser example:
  const radius = 40;
  ctx.beginPath();
  ctx.arc(100, 50, radius, 0, 2 * Math.PI);
  ctx.stroke();

The above produces this:

To render the desired shape we need to change the drawing code to use a moveTo()
  const radius = 40;
  ctx.beginPath();
  ctx.moveTo(100 + radius, 50);
  ctx.arc(100, 50, radius, 0, 2 * Math.PI);
  ctx.stroke();

Should this be considered an issue? We could add a startNewSubPath() call to the C++ implementation of things like arc() but part of me thinks this is undesirable and users will just have to be aware of the need to call moveTo()
            setProperty("arc", juce::var::NativeFunction {
                    [=](const juce::var::NativeFunctionArgs& args) -> juce::var {
                        jassert(args.numArguments >= 5 && args.numArguments <= 6);

                        const float x             = args.arguments[0];
                        const float y             = args.arguments[1];
                        const float radius        = args.arguments[2];
                        const float startAngle    = args.arguments[3];
                        const float endAngle      = args.arguments[4];
                        //TODO; Handle antiClockWise
                        //bool        antiClockWise = args.arguments[5];

                        const float width  = radius * 2;
                        const float height = radius * 2;

                        path.startNewSubPath(x, y);
                        path.addArc(x, y, width, height, startAngle, endAngle);

                        return juce::var();
                    }
            });

@nick-thompson, I've squashed this all down to a single commit and added some initial comments/documentation. If you're happy with the shape of everything then I think this should be good to merge now.

@nick-thompson, I've squashed this all down to a single commit and added some initial comments/documentation. If you're happy with the shape of everything then I think this should be good to merge now.

Awesome @JoshMarler this looks great! Two more small asks from me in there– the getProperty method and the jassertfalse becoming a warning, otherwise I'm ready to merge :)
To your point above about the moveTo, yea, that's tricky. I think you're right that it makes the most sense for users to just be aware of the need to call this moveTo here. Especially as you've put it here:

Calling moveTo() does not break the desired behaviour/output in a browser so the code is cross-compatible

I think that definitely answers the question. Maybe the takeaway here is that as we build out the documentation for CanvasView we should have a "things you should know" section or something where we can highlight little details like this

@nick-thompson, final two points actioned. Squashed changes again so good to go.

Merged! This is super cool, thanks for all your help Josh. As we continue building out the remaining API, I'd love to get a cool CanvasExample project going to show this feature off too :)

@nick-thompson, Yeah a canvas example project would be awesome. Totally up for assisting with that once some more of the API is implemented and DOCS added.
I have a little TODO list compiling. The below are my next tasks but I'll probably complete these after I've finished the HotReload refactor.
. Get fillText() strokeText(), font and textAlign working.
. Get drawImage() working with  string.
. Get gradients and stroke patterns (i.e. line - dash) working.


Use wait_for_any_log to wait/grep for logs to avoid test failures caused by buffering.

Multiplexed test can be found here

+1


run nf-test with awsbatch executor

Hy dev team,
Thanks for this nice tool.
When trying to execute nf-test with awsbatch it failes with:
Nextflow stderr:

  When using `awsbatch` executor an S3 bucket must be provided as working directory using either the `-bucket-dir` or `-work-dir` command line option

even tough workDir is set to a S3 path in nf-test.config.
I saw that the S3 path actually was created locally by nf-test. So my question are:

Is this a known limitation by design? If so, there are plans for integration?
Or else, is there something wrong that nees fine-tuning?

💭

Yes, that's currently a known limitation. We were discussing this internally today and we see the advantage of having this. We'll come back to you when we have a plan how to integrate that.

That would be fantastic feature! +1

Hey, any progress on that ?

Hello,
In your nf-test.config you can add:
options "-bucket-dir s3://your-bucket/some/path"
This at least allows my test to run with an awsbatch profile. However any files returned in output channels will be at that s3 location.

+1 on this issue, it is critical for my ci/cd testing

for some added context, you can see why this is happening if you add this line to your Nextflow main.nf
println("workflow.commandLine: ${workflow.commandLine}")

and then run nf-test test --verbose main.nf.test;
    > workflow.commandLine: nextflow -log /home/username/projects/my-pipeline/.nf-test/tests/3431ab1030a8e7bd96d6c6d85973429/meta/nextflow.log run /home/username/projects/my-pipeline/main.nf
-c /home/username/projects/my-pipeline/nextflow.config
-c /home/username/projects/my-pipeline/tests/nextflow.config
-params-file /home/username/projects/my-pipeline/.nf-test/tests/3431ab1030a8e7bd96d6c6d85973429/meta/params.json
-ansi-log false
-profile awsbatch
-with-trace /home/username/projects/my-pipeline/.nf-test/tests/3431ab1030a8e7bd96d6c6d85973429/meta/trace.csv
-w /home/username/projects/my-pipeline/.nf-test/tests/3431ab1030a8e7bd96d6c6d85973429/work

You can see that nf-test is appending the Nextflow cli arg -w to configure the work dir to a local directory, despite having the config set as this inside my nextflow.config for the awsbatch profile;
workDir = 's3://my-bucket/nextflow/workDir'

Notably, neither of these possible solutions within nf-test seem to work;
nextflow_pipeline {
    script "main.nf"
    profile "awsbatch"
    workDir "s3://my-bucket/nextflow/workDir"

gives error
🚀 nf-test 0.9.2
https://www.nf-test.com
(c) 2021 - 2024 Lukas Forer and Sebastian Schoenherr

Error: groovy.lang.MissingMethodException: No signature of method: main_nf$_run_closure1.workDir() is applicable for argument types: (String) values: [s3://my-bucket/nextflow/workDir"]

while this method
nextflow_pipeline {
    script "main.nf"
    profile "awsbatch"
    options "-work-dir s3://my-bucket/nextflow/workDir"

gives error
  Test [3431ab10] 'Should run without failures'
    > Nextflow 24.10.0 is available - Please consider updating your version to it
    > Can only specify option -w once. -- Check the available commands and options and syntax with 'help'
    FAILED (2.144s)

So unless I am missing something (?) it appears that there is no possible way to run nf-test but to execute the tasks on AWS Batch, as you normally can do trivially with Nextflow. Is this really the case? If so I would think this would be a serious issue because many pipelines' storage and compute requirements are too large to run locally even with a minimal dataset.
Let me know if there is some way to get AWS Batch execution working with Nextflow in nf-test, thanks

Another +1 on getting this feature implemented.

I would also like to this implemented!

as a follow up, I see that this does work instead;
nextflow_pipeline {
    name "Test case"
    script "main.nf"
    profile "awsbatch"
    options "-bucket-dir s3://my-bucket/nextflow/workdir"


Snyk now supports custom policies written in rego

But it's still in beta status.
Can I just change Custom Rule Support - Snyk cell into "yes" ?
https://snyk.io/blog/developing-custom-iac-rules-with-snyk-iac/
https://docs.snyk.io/products/snyk-infrastructure-as-code/custom-rules

@dharada1 go ahead and submit a PR


[Core] Verify test Generation in both autorest.csharp upgrading pipeline of sdk repo and Autorest.CSharp itself

API Change Needed
No
Background and motivation
Background
Right now, there is test generation feature in mgmt autorest.CSharp. The generated tests can be seen at https://github.com/Azure/autorest.csharp/tree/d6dd66df44128e4c7b09025e1debd824e2482468/test/TestProjects/MgmtKeyvault/tests/Generated/Mock
Currently these generated tests are mock tests that can be execute under the mock-service-host(https://github.com/Azure/azure-sdk-tools/tree/main/tools/mock-service-host). And meanwhile, we are in the procedure to generate live test based on swagger api scenario (https://github.com/Azure/azure-rest-api-specs/tree/main/documentation/api-scenario).
Motivation
We want the test Generation feature can be verified in 1) sdk repo when upgrading autorest.CSharp & 2) autorest.csharp TestProjects.
API / Feature Proposal
Feature1: verify Test Generation in SDK repo when upgrading autorest.CSharp
The "dotnet build /t:GenerateTest" has been supported in Autorest.CSharp, we want it's invoked in autorest.CSharp pipeline for all released Packages just like that now we are using "dotnet build /t:GenerateCode" to verify generated source code. (There is flag to control whether we enabled testGeneration for a single RP)
Feature 2: verify Test Generation result in TestProjects in Autorest.CSharp
We want to create some testProjects in AutorestCSharp which can verify generated api-scenario test.  Since there will be ARM-Template invocations in generated test, we come up two options to make these testProjects compilable in autorest.CSharp:

option 1: adding Faked Azure.ResourceManager.Resources and TestFramework classes in Autorest.CSharp, like we did here https://github.com/Azure/autorest.csharp/tree/feature/v3/src/assets/TestFramework
option 2: Release TestFramework into nuget, and adding real Azure.ResourceManager.Resources and TestFramework as dependencies of Autorest.CSharp. Since these packages in turn depend on Autorest.CSharp, there may be potential cyclic dependency issues doing this.

Would you please share your opinion on Feature1 and which option should I go for Feature2? Thanks!
Time Constraints and Dependencies
Sooner is better.
Stakeholders
@m-nash , @ArcturusZhang, @ArthurMa1978 , @lirenhe

Thank you for the well-written issue.   Transferring this over to the Autorest repository so that it can be tracked as part of CodeGen work.


Remove println statement from ReceiveMessageDirectives

I've no idea how this slipped through 😔

Same here! And I though I read the code quite carefully :)


Temporarily revert use of core::ffi::CStr

The move of CStr from std to core is not due to become stable until 1.64. The first nightly where it could be used without the unstable core_c_str feature was 2022-07-16, which is still pretty recent. Let's back this change out for now to give users pinned to older versions more time.
Checklist

[x] Sensible git history (for example, squash "typo" or "fix" commits): See the
Rewriting History guide for
help.
[x] Update the changelog (if necessary)

@phip1611 I missed this when looking at https://github.com/rust-osdev/uefi-rs/pull/506, I'd like to back this change out for now so that we don't break compilation on older Rust nightlies just yet, and file an issue to add it back in later.

Yeah, I see. It is very new. Should we add a - [ ] Does it change the MSRV? If so, update the Changelog. (or sth similar) to the MR template?

Created follow-up ticket https://github.com/rust-osdev/uefi-rs/issues/510


SWDEV-359377

SWDEV-359377
The proposed refactoring allows the user to specify the path of the directory of the matrix files.
This can be done either with the environment variable HIPSPARSE_CLIENTS_MATRICES_DIR:

export HIPSPARSE_CLIENTS_MATRICES_DIR=<path>
hipsparse-test

or from the command line (in that case the environment variable is ignored):

hipsparse-test --matrices-dir <path>

Hi @YvanMokwinski
Are you expecting QA to download the matrices? or we are keeping them in test packages itself ?

hipsparse-test is running but few is showing failed as "/opt/rocm-5.2.0-9996/bin/../matrices/nos3.bin" was not read

Reading matrix /opt/rocm-5.2.0-9996/bin/../matrices/nos3.bin...Cannot open [read] /opt/rocm-5.2.0-9996/bin/../matrices/nos3.bin
/long_pathname_so_that_rpms_can_package_the_debug_info/data/driver/hipSPARSE/clients/tests/test_bsrsm2.cpp:36: Failure
Expected equality of these values:
status
Which is: 7
HIPSPARSE_STATUS_SUCCESS
Which is: 0
[  FAILED  ] bsrsm2.bsrsm2_float (0 ms)
[ RUN      ] bsrsm2.bsrsm2_double

Hi @pramenku
There is small glitch I am going to fix, For now the command should be (wuth an extra / in the path.
./hipsparse-test --matrices-dir /opt/rocm/share/hipsparse/matrices/


Significant drop in accuracy for release version 0.4

I tried to run my old code on version 0.4 and observed a significant drop in accuracy, which could be as large as 10 percent. I create a simple example to replicate the bug with my own data. I think the bug is about the XdawnCovariance estimation. Could you please investigate this issue?
The data and code are attached. I compared the result using the same method with release version 0.3 and 0.4.
sample.zip

Thank you so much @DingkunLiu for this relevant issue!
Regression has been introduced in #214, wrongly removing a reshape step
https://github.com/pyRiemann/pyRiemann/pull/214/commits/45354b2c2883f6bf4a4855e64fac932a66cc2438#diff-f3762b7e6323643948e27df9777f362069925823b4779fe3571f5e1db3a400e9L104


Compile error message does not disappear after successful compile

Try to run code which generates compile error. Red message with compile error appears
Fix compile error. Compile error message stays

Solved in last release, closing!


External from included assets

Beforehand, I am somewhat ignorant in this regard, but is it possible to add one of the included assets as an external? Say if you load jQuery through this plugin, could I refer to it in the same webpack config as an external, to expose it as a global variable, or even use it in my app?
Not sure if what I'm asking even makes sense technically.

Are you referring to using the webpack.ProvidePlugin
If so then webpack actually automatically includes the package that you're providing into the generated bundles.

Or, if you mean using the externals section of the webpack config, then yes, you can set an external, and then also include the script for that external asset via html-webpack-include-assets-plugin

@hallaathrad Also, if you're interested, I built a separate plugin that uses html-webpack-include-assets-plugin to do this behind the scenes: html-webpack-externals-plugin.

@mmiller42 I've managed to get it working with the plugin @jharris4 suggested; yet I'm willing to give yours a try if only to reduce boilerplate.
Lemme get back to you later, when I get back to this. :+1:


Add popup window

Merge Popup Window to  Main

### Please ignore Webhint Error. Technical Support say it is a general bug.

Please Note that I received a message from Student's success informing me about my partner dropping off.
Please go on to approve this PR because I have no partner now to commit on my repo. Thank you!

Just work has been reviewed long enough. Can you kindly approve it so it so we can all go to sleep?

This is an excellent project no error
No error


How to pass data between commands in a job?

How can I pass output data from command.1 to command.2 within a job?
Something like this
#my.job
type=command
command=bash script.sh
command.1=bash script2.sh {command}
./scripts.sh
#!/bin/bash
exit 24

From what I understand, currently, the only ways are via JOB_PROP_OUTPUT_FILE or having one job write to a file in a predetermined location and have the next job read from that file. I think there should be a more explicit mechanism to do this though, such as having explicit properties for specifying the inputs and outputs for a job.

We can share data between jobs easily by writing to the JOB_PROP_OUTPUT_FILE. But there is no easy way to share data between commands within a job

For sharing data between commands within a job, how about writing to a temporary file and/or using a temporary directory using mktemp?


fix(rust): Rust strategy should update root Cargo files in a workspace

Cargo.toml updater now updates the main package version from the updater's version
cargo-workspace merges the root component's updates
rust strategy now updates all workspace members versions in sync (overridden by cargo-workspace plugin if configured)

Fixes #1170

Hmm, this is colliding with the cargo-manifest plugin. If you set the root component, it updates all the submodules to the same version, then the cargo-manifest plugin runs effectively doing nothing.

cc @jcornaz


Remove BC Layer for Symfony Dispatcher versions 4.3 and lower

This PR partially resolves https://github.com/Behat/Behat/issues/1305

Scrutenizer errors not introduced by this PR, they were already there.

I think longer term we should be looking at decoupling from the symfony interfaces here, but this looks fine

Anything needed from me here to push this forward?

Thanks!


Script Hugo release process

Based on https://github.com/goreleaser/goreleaser

@moorereason @spf13 @digitalcraftsman
Have a look at
https://github.com/bep/hugo/releases/tag/v0.20.110
And esp. the file names.
There are some subtle differences to get it consistent, but the main ones are like before to keep old Wercker deploys working etc.

But I have changed all the Unix to tar.gz as archive format.
This is a change that may break something, but I'm not sure what the reasoning behind the old zip files for all but the Linux builds. I would think zip should be a more problematic format on non-Windows.
I can change that back, maybe if you think of a good reason ...

This is complete:
https://github.com/bep/hugo/releases/tag/v0.20.113

I hadn't paid much attention to our old release filenames.  They're a mess!
Agree on the zip vs tar.gz change.
If we keep the "32bit" replacement, I prefer "32bit" to "32-bit."  Same for "64-bit."  The extra hyphen just adds more noise to a busy filename.
Personal preference, but I prefer all lowercase filenames.
Overall, looks much cleaner.  :+1:

If we keep the "32bit" replacement, I prefer "32bit" to "32-bit."

I'm not changing the Linux filename at all (it would break too many scripts, even some of mine).

What do you mean?  Our existing releases use "32bit" not "32-bit".

What do you mean? Our existing releases use "32bit" not "32-bit".

Which is the reason I ask other people to look at it ... I stared at those filenames side-by side, and they looked the same to me ... Thanks, I will fix the bit.


basic auth support

We are trying to run psi against a site that hasn't been released yet. The platform we are on requires us to have basic http authentication on the site before it is released. I would expect psi to work with url's of the type<EMAIL_ADDRESS>This fails for our site, despite working in browsers and even curl.

After digging into the code to determine if I could provide a pull request, I have determined that the url is being passed correctly to the googleapis package, and it is a fault of either the Page speed Insights API or the googleapis package.

@MobiusHorizons do you solve this problem otherwise?

No, we were unable to run against that instance. We simply had to run it against a different instance with slightly lower performance, that is primarily meant for testing. Basic auth support would still be very much appreciated, but I understand that that is a question for the google api, not this package.

All right, thanks u! My fellow had an Idea to switch the auth file for the PSI task and do that again after it's done to protect the site.

site protected
change file
site open
run psi
change file
site protected

but we found no time until now to test it. We use buddy.works as deployment tool. Maybe an interesting approach for you.
Cheers!


In vue-cli5, plugin will conflict with html-webpack-plugin.

When I using this plugin with vue-cli5, vue-cli-service serve and vue-cli-service build will throw error:
Error: Child compilation failed:
  Module parse failed: Unexpected token (1:0)
  File was processed with these loaders:
   * ./node_modules/.pnpm/html-webpack-plugin<EMAIL_ADDRESS>   *<EMAIL_ADDRESS>  You may need an additional loader to handle the result of these loaders.
  > <!DOCTYPE html>
  | <html lang="">
  |   <head>

I found html-webpack-plugin/lib/loader.js will check if there is any other loader, if exists it will return unmodified source, which cause error.
After some dig, I found add transformInclude hook and /\.html/ to plugin exclude config, unplugin will not create the loader which conflict with html-webpack-plugin and solve issue. But it also mean this plugin cant process html code. Maybe there is better way to fix this?

try this:
https://github.com/KeJunMao/unplugin-preprocessor-directives/blob/main/examples/vue-cli/vue.config.js#L11-L20

example:
https://github.com/KeJunMao/unplugin-preprocessor-directives/blob/main/examples/vue-cli/public/index.html#L10-L12

Thanks for fix! But I get another issue: the default include option of this plugin is **/*, which will include asset file like png and jpeg. In webpack environment, this plugin will change asset file content, so my image files can't display at all. I need to change include option to include: ['**/*.js', '**/*.ts'] to fix this problem. Vite environment work fine.

Yes, We do need better defaults, do you have any suggestions?


throw er; // Unhanded 'error' event

I set up all my environment variables, updated npm (now using 4.5.0), and ran npm install -g tiny-care-terminal. However, when I run tiny-care-terminal, I get this:
   Error: spawn sh /usr/local/lib/node_modules/tiny-care-terminal/standup-helper.sh ENOENT
    at exports._errnoException (util.js:874:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:178:32)
    at onErrorNT (internal/child_process.js:344:16)
    at doNTCallback2 (node.js:439:9)
    at process._tickCallback (node.js:353:17)
    at Function.Module.runMain (module.js:469:11)
    at startup (node.js:134:18)
    at node.js:961:3
events.js:141
      throw er; // Unhandled 'error' event
      ^

Error: spawn sh /usr/local/lib/node_modules/tiny-care-terminal/standup-helper.sh ENOENT
    at exports._errnoException (util.js:874:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:178:32)
    at onErrorNT (internal/child_process.js:344:16)
    at doNTCallback2 (node.js:439:9)
    at process._tickCallback (node.js:353:17)

Not super familiar with npm or node.

Seems like this is the same as issue #14 but im not entirely sure. But its something related with git-standup. By any change did you install git-standup?
See: https://github.com/notwaldorf/tiny-care-terminal#configure-the-dashboard

Try run npm install -g git-standup first. Not sure if this will help, but it is needed if you don't have it already. There is already a PR #18 trying to improve this.

I did install git-standup and it seems to work great. Still can't get tiny-care-terminal to run. :(

One additional thing:
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
That line does not return the directory that node-modules is in. However, even if I replace it with the directory that node-modules is in, I still get the same result.

And now, if I run sudo sh ./standup-helper.sh ~/dev/ (with ~/dev/ being where my repos are), I get the results of git-standup.

Duplicate of #14
There's a bunch of problems with git-standup; I'm just going to aggregate them under one issue

@jmkoni yeah, that DIR line only returns the right node_modules directory for a particular install of npm, i think (not with yarn, maybe using nvm) :(

Cross posted from #14:
OK! I published 1.0.4  that maybe works better? Anyone with a broken tiny-care-terminal want to install that and tell me if it's better, pretty please? 🙏


Flashing a custom firmware onto the EEPROM of the Intel I225-V Ethernet Controller

Hi, 5T33Z0!
I'm trying to flash a custom firmware onto the EEPROM of the Intel I225-V Ethernet Controller.
I use the firmware and tool recommended by the author. (I225MOD + eeupdate64e.efi)
Unfortunately, the file I225MOD is not flashed correctly and the adapter then does not work.
On the pictures in hex:

My original firmware
Author's modified firmware
My result after the firmware flashing

What is the my error?

I don't know. It worked for me. But there's a kext now for the I225. Maybe it works for you:
https://github.com/SongXiaoXi/AppleIGC

Thanks, I'll test!
Do I have to go back to stock firmware to use this kext? And what settings should I use?

I guess so. Becasue on my patched NIC, I didn't got a DHCP Lease with this kext. It connected to Ethernet but not to the Internet

Yes thanks, it works now for me.

stock firmware (Intel I225-V Ethernet Controller on Gigabyte-Z490-Vision-G)
AppleIGC.kext used
AppleIntelI210Ethernet.kext not used
SSDT-I225V.aml not used
boot-args e1000=0 used
DisableIoMapper = YES (PlistEdit Pro)
DisableIoMapperMapping = NO (PlistEdit Pro)

Great. Thanks for your report. I will add your settings to my article about fixing the i225-V!

5T33Z0, really can work without DisableIoMapper = YES
I used this setting to work my WiFi+Bluetooth: Fenvi FV-T919 BCM94360CD

Can you show me a screenshot that verifies that this kext is actually serving th I225-V? It should be possible using IORegstryExplorer. That would be useful.

Thank you very much!


API calls

Implement the actual API calls based on the user's credentials

API calls working. See API implementation.
Need to create mechanism for getting and storing API key from user.


[T4A2][T16-B1] Ong Li-Jen

Changed Parser.java and Person.java to better reflect class-level members.

Ready for review

@lijen1994 Some comments added. Please close the PR after reading comments.


Update README.md

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: himanshubeniwal sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Refactor

Separating Query is finished, better to merge before next code refactoring.

@ad3n  I got an error. Unexpected array result:
Problem
In PlantRepository.php, this method:
/**
     * @return Plant[]
     */
    public function findAllPlants()
    {
        $qb = $this->getRepository()->createQueryBuilder('p');

        $query = $qb->addSelect('SUM(p.areaCapacity) AS seedling_total')
            ->addSelect('p.id AS id')
            ->addSelect('COUNT(p.area) AS area_count')
            ->addSelect('sc.name AS seed_category')
            ->addSelect('s AS seed')
            ->from('AppBundle:Plant', 'p')
            ->innerJoin('AppBundle:Seed', 's', 'WITH', 'p.seed = s.id')
            ->innerJoin('AppBundle:Area', 'a', 'WITH', 'p.area = a.id')
            ->innerJoin('AppBundle:SeedCategory', 'sc', 'WITH', 's.seedCategory = sc.id')
            ->groupBy('p.seed')
            ->getQuery();

        return $query->getResult();
    }

will cause:
[Semantical Error] line 0, col 332 near 'p INNER JOIN': Error: 'p' is already defined.

So, I tried to comment PlantRepository.php line 49:
/**
     * @return Plant[]
     */
    public function findAllPlants()
    {
        $qb = $this->getRepository()->createQueryBuilder('p');

        $query = $qb->addSelect('SUM(p.areaCapacity) AS seedling_total')
            ->addSelect('p.id AS id')
            ->addSelect('COUNT(p.area) AS area_count')
            ->addSelect('sc.name AS seed_category')
            ->addSelect('s AS seed')
            //->from('AppBundle:Plant', 'p')
            ->innerJoin('AppBundle:Seed', 's', 'WITH', 'p.seed = s.id')
            ->innerJoin('AppBundle:Area', 'a', 'WITH', 'p.area = a.id')
            ->innerJoin('AppBundle:SeedCategory', 'sc', 'WITH', 's.seedCategory = sc.id')
            ->groupBy('p.seed')
            ->getQuery();

        return $query->getResult();
    }

It worked. But, the form of array result is not as expected:
PlantController.php on line 18:
array:2 [▼
  0 => array:1 [▼
    0 => Plant {#882 ▼
      -id: 1
      -area: Area {#646 ▶}
      -seed: Seed {#939 ▶}
      -seedlingDate: DateTime {#629 ▶}
      -seedlingAmount: 50
      -areaCapacity: 50
      -harvestingDate: null
      -disposingDate: null
      -note: null
      -action: null
      -updatedAt: null
      -createdAt: DateTime {#728 ▶}
    }
  ]
  1 => array:5 [▼
    "seed" => Seed {#939 ▶ …2}
    "seedling_total" => "70"
    "id" => 1
    "area_count" => "2"
    "seed_category" => "Vegetable"
  ]
]

Solution
When I changed line 42 in PlantRepository.php with $this->manager:
/**
     * @return Plant[]
     */
    public function findAllPlants()
    {
        $qb = $this->manager->createQueryBuilder('p');

        $query = $qb->addSelect('SUM(p.areaCapacity) AS seedling_total')
            ->addSelect('p.id AS id')
            ->addSelect('COUNT(p.area) AS area_count')
            ->addSelect('sc.name AS seed_category')
            ->addSelect('s AS seed')
            ->from('AppBundle:Plant', 'p')
            ->innerJoin('AppBundle:Seed', 's', 'WITH', 'p.seed = s.id')
            ->innerJoin('AppBundle:Area', 'a', 'WITH', 'p.area = a.id')
            ->innerJoin('AppBundle:SeedCategory', 'sc', 'WITH', 's.seedCategory = sc.id')
            ->groupBy('p.seed')
            ->getQuery();

        return $query->getResult();
    }

Then I changed the $manager property in AbstractRepository.php from private to protected. And voila! The array result will be correct.
This is the correct one:
PlantController.php on line 18:
array:1 [▼
  0 => array:5 [▼
    "seed" => Seed {#5110 ▶}
    "seedling_total" => "70"
    "id" => 1
    "area_count" => "2"
    "seed_category" => "Vegetable"
  ]
]

Conclusion
Please, fix it to get the correct array. I don't know whether changing the $manager property from private to protected is good or not.
Thanks.

I had merged it to the development branch. So, I think we can close this PR.


Maintain a proper changelog

Starting with 4.0.0, all changes are documented in the GitHub release changelog. This also includes a comprehensive list of all breaking changes from the respective release.


Removed all cancel actions notifications.

Removed all notifications after canceling actions.

Codecov Report

Merging #148 into master will not change coverage.
The diff coverage is 66.66%.

@@          Coverage Diff           @@
##           master    #148   +/-   ##
======================================
  Coverage    80.9%   80.9%
======================================
  Files          78      78
  Lines         728     728
  Branches       59      59
======================================
  Hits          589     589
  Misses        126     126
  Partials       13      13

Impacted Files
Coverage Δ

...mart-components/portfolio/share-portfolio-modal.js
10.81% <0%> (ø)
:arrow_up:

...art-components/portfolio/remove-portfolio-modal.js
91.66% <100%> (ø)
:arrow_up:

.../smart-components/portfolio/add-portfolio-modal.js
83.33% <100%> (ø)
:arrow_up:

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 51a05e0...3f880f9. Read the comment docs.

Codecov Report

Merging #148 into master will not change coverage.
The diff coverage is 66.66%.

@@          Coverage Diff           @@
##           master    #148   +/-   ##
======================================
  Coverage    80.9%   80.9%
======================================
  Files          78      78
  Lines         728     728
  Branches       59      59
======================================
  Hits          589     589
  Misses        126     126
  Partials       13      13

Impacted Files
Coverage Δ

...mart-components/portfolio/share-portfolio-modal.js
10.81% <0%> (ø)
:arrow_up:

...art-components/portfolio/remove-portfolio-modal.js
91.66% <100%> (ø)
:arrow_up:

.../smart-components/portfolio/add-portfolio-modal.js
83.33% <100%> (ø)
:arrow_up:

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 51a05e0...3f880f9. Read the comment docs.


refactor: add css tokens

Summary
Type

Feature

Summarise concisely:
What is expected?
Ultraviolet theme now provides css tokens.
The CSS files are located in "@ultraviolet/themes/public/style".  To import a theme, dark for instance, do : import<EMAIL_ADDRESS>The following changes were made:
New script to update the css tokens when updating the tokens from figma

hello there 👋
We don't use these variables for now, but just so you know these values are not correctly generated
    --color-other-data: [object Object];
    --color-other-gradients: [object Object];
    --color-other-icon: [object Object];

Fixed ✔


fix: ensure that report name is a valid resource name

Description
This adds the required extra validation to report names to fix #343. Also refactor the code to avoid duplication in this area.
I know plural package names are discouraged in Golang, but naming things is hard. Please let me know if you have any constructive input to naming.
Related issues

Close #343

Checklist

[x] I've read the guidelines for contributing to this repository.
[x] I've added tests that prove my fix is effective or that my feature works.
[ ] I've updated the documentation with the relevant information (if needed).
[ ] I've added usage information (if the PR introduces new options)
[ ] I've included a "before" and "after" example to the description (if the PR is a user interface change).

Looks good Erik! :) Can't think of a different name for reports, though It looks to me it makes more sense as pkg/reports than pkg/operator/reports as it is a code common to all reports which are all at the pkg level.

Thinking a bit more about it, I think resource names are important enough to actually let the code reside under pkg/apis. But it is technically not part of the API. It seems like there is a lot of duplicated code in this area, so I think it makes sense to add some kind of package for sharing code between the different "reports".

lol, I've seen this validation in one too many controllers. I wonder why there isn't yet validation code being part of controller-runtime or a library of the sort. Anyway, thanks for adding this!

The thing is that this "depends". We've never needed this in our internal controllers. The funcs to validate are there, you just have to use them correctly, depending on your use case.


Fix: minimal versions check

Checklist

[x] Updated guide with pertinent info (may not always apply).
[x] Squash down commits to one or two logical commits which clearly describe the work you've done.
[x] Unittest is a friend:)

This is a tiny fix for minimal versions. I stumbled about this issue when testing with the latest openraft:0.9.15 when executing in my pipeline:
cargo minimal-versions check --workspace

This change is

I got the same error, so I kinda think we should fix this in byte_unit, not Openraft🤔

Oh yes, that would make sense as well, of course.
I will just open a PR over there. Let's see how fast this will be merged (and published).
openraft could implement a temporary fix though until this has been released on crates.io I guess?

@sebadob
Thank you for bringing this issue to our attention.
This issue stems from a dependency crate rather than our crate directly. Introducing a new unnecessary crate solely to fix this issue may not be the most elegant solution.
If the minimal-versions check is critical for your application, a more appropriate solution would be adding rust_decimal = "1.15" in the application crate, but not in Openraft's Cargo.toml.

Yes it's coming from a dependency, but it's not being added, it's there anyway and nothing additional.
Checking for minimal versions is a good practice for any crate. This example may not be the best one, because the issue has been introduced in a version 3 years ago, but the same happens for new releases as well (sadly, quite often), which can lead to very weird errors, when you are stuck on an older version in your application for whatever reason.
It's fine for me to just close the issue then.

Checking for minimal versions is a good practice for any crate

Yeah, true, perhaps we can have this check in Openraft's CI as well:)

Checking for minimal versions is a good practice for any crate

Yeah, true, perhaps we can have this check in Openraft's CI as well:)

Running it on in Openraft root dir yields an error. I'm not sure if it is a bug of minimal-versions parsing Cargo.toml or I missed anything.
cargo minimal-versions check --workspace

info: running `cargo update -Z minimal-versions`
error: failed to load manifest for workspace member `/Users/drdrxp/xp/vcs/github.com/drmingdrmer/openraft/tests`
referenced by workspace at `/Users/drdrxp/xp/vcs/github.com/drmingdrmer/openraft/Cargo.toml`

Caused by:
  failed to parse manifest at `/Users/drdrxp/xp/vcs/github.com/drmingdrmer/openraft/tests/Cargo.toml`

Caused by:
  feature `bt` includes `openraft/bt`, but `openraft` is not a dependency
error: process didn't exit successfully: `/Users/drdrxp/.rustup/toolchains/nightly-2024-07-02-aarch64-apple-darwin/bin/cargo update -Z minimal-versions` (exit status: 101)

And running cargo +nightly update -Z direct-minimal-versions or -Z minimal-versions directly just fails(because of version selecting algorithm being not that smart?). It looks like it just locks version of quote to 1.0.0 because it is used directly in our Cargo.toml and then refuses to use a higher version even when a dependency crate requires.
cargo +nightly update -Z direct-minimal-versions

    Updating crates.io index
error: failed to select a version for `quote`.
    ... required by package `syn v2.0.0`
    ... which satisfies dependency `syn = "^2.0"` of package `openraft-macros v0.10.0 (/Users/drdrxp/xp/vcs/github.com/drmingdrmer/openraft/macros)`
    ... which satisfies path dependency `openraft-macros` of package `openraft v0.10.0 (/Users/drdrxp/xp/vcs/github.com/drmingdrmer/openraft/openraft)`
    ... which satisfies path dependency `openraft` of package `openraft-rocksstore v0.1.0 (/Users/drdrxp/xp/vcs/github.com/drmingdrmer/openraft/stores/rocksstore)`
versions that meet the requirements `^1.0.25` are: 1.0.37, 1.0.36, 1.0.35, 1.0.34, 1.0.33, 1.0.32, 1.0.31, 1.0.30, 1.0.29, 1.0.28, 1.0.27, 1.0.26

all possible versions conflict with previously selected packages.

  previously selected package `quote v1.0.0`
    ... which satisfies dependency `quote = "^1.0"` of package `openraft-macros v0.10.0 (/Users/drdrxp/xp/vcs/github.com/drmingdrmer/openraft/macros)`
    ... which satisfies path dependency `openraft-macros` of package `openraft v0.10.0 (/Users/drdrxp/xp/vcs/github.com/drmingdrmer/openraft/openraft)`
    ... which satisfies path dependency `openraft` of package `openraft-rocksstore v0.1.0 (/Users/drdrxp/xp/vcs/github.com/drmingdrmer/openraft/stores/rocksstore)`

failed to select a version for `quote` which could resolve this conflict

And cargo-minimal-versions seems to affect only Cargo.lock but Openraft, as a lib not app, does not include Cargo.lock in the repo.

And cargo-minimal-versions seems to affect only Cargo.lock but Openraft, as a lib not app, does not include Cargo.lock in the repo.

Yes it does. It basically uses the Cargo.lock to check for errors. As a crate you have the lock file in the .gitignore, but it is created anyway all the time when running tests, clippy, and so on. Not sure though why you can't easily run it inside openraft root. It has some issues with tests dependencies when I try, exactly the first one you posted.

If cargo-minimal-versions does not work, we can use the -Zdirect-minimal-versions flag directly (nightly toolchain needed though), here is how Nix handles it:
https://github.com/nix-rust/nix/blob/e8879e310f3f1ca7277588de44204bf14eb1991c/.github/workflows/ci.yml#L333-L354


ci: Add step for release to create a staging repository id

We use a curl request to obtain the staging profile URI for the
org.osgi group id. And then we make a curl request to start a
staging repository. The URL to the created staging repository
is place in the GitHub actions env context for access by later
steps in the job.

Looking at the script, I'm not sure if all of this is really necessary. I may have missed some requirements here that made it necessary to manually start a staging repository. When we deploy our gecko bundles to maven central we never have to jump through all these hoops, because sonartype starts a staging repo automatically.
In our case we only include the following bnd file if we want to do a release:
-plugin.sonatype: \
	aQute.bnd.repository.maven.provider.MavenBndRepository;\
		snapshotUrl=https://oss.sonatype.org/content/repositories/snapshots/;\
		releaseUrl=https://oss.sonatype.org/service/local/staging/deploy/maven2/;\
		index=${.}/sonatype.maven;\
		name='Sonatype'

-releaserepo.sonatype: Sonatype

That can work fine but sometimes OSSRH splits the deployed artifacts across multiple staging repositories as happened with the RC2 build I made a few days ago as a test. Those who were able to attend the project call yesterday saw this and we discussed it. @rotty3000 found the information to add these commands to start a staging repository so we can use that staging repositories deployment url to avoid multiple staging repositories. It worked correctly in my test last night. Thanks @rotty3000.
So yes, it really is necessary.


GitHub Pages: Jekyll causes URLs containing ~ to 404

On GitHub Pages, Jekyll causes URLs containing ~ to 404. Related: The url contains '~' seems to be routed to 404
Links to documentation of the various functions/interfaces/etc are nested under docs/~ or docs/<filename>/~, so with the default GitHub Pages setup, none of those pages can be viewed.
Workaround: Add an empty .nojekyll at the GitHub Pages root (project root or docs/) on the relevant branch; if GitHub Pages root is docs/, recreate this file every time after running deno doc --html (currently, deno doc --html deletes everything under docs/, so it has to be replaced every time).
Possible fixes:

Change ~ directory name to something else
Keep ~ as default directory name but make it configurable
Generate .nojekyll under docs/
Generate .nojekyll under project root
Generate .nojekyll in both places (!)
Don't generate .nojekyll, but automatically replace it if it already happens to exist in docs/
Add a config option for where to generate .nojekyll, if at all
Add a config option for whether to delete unrecognized dotfiles under docs/ (or even finer-grained config, e.g. a glob pattern for files to leave unchanged in docs/)
Do nothing and require userland workarounds
Other?

I personally would say "do nothing". jekyll is an external tool, and we cannot start accomodating for various scenarios of different distribution systems. I wouldn't really be in favour of adding .nojekyll. The ~ divider was decided on being the only really viable character that could be used. This however is probably something we should mention in docs.deno.com


MultipartWriter body breaks verbose printing of requests

When using multipart writer from aiohttp with -vv the output of requests errors out with
TypeError('decoding to str: need a bytes-like object, NoneType found')
  File "/home/rwhittier/.virtualenvs/rampie/lib/python3.7/site-packages/molotov/listeners.py", line 118, in send_event
    await listener(event, **options)
  File "/home/rwhittier/.virtualenvs/rampie/lib/python3.7/site-packages/molotov/listeners.py", line 15, in __call__
    await attr(**options)
  File "/home/rwhittier/.virtualenvs/rampie/lib/python3.7/site-packages/molotov/listeners.py", line 55, in on_sending_request
    raw += '\n\n' + self._body2str(request.body) + '\n'
  File "/home/rwhittier/.virtualenvs/rampie/lib/python3.7/site-packages/molotov/listeners.py", line 37, in _body2str
    body = str(body, 'utf8')

example scenario
    csrf_token = "d19599a81c7dfb33390937f871b870a249019a650961b3f2396c84698a8e4e5d"
    cookies = {
        "csrftoken": csrf_token,
        "dtk": "1d8jvjcvq0000901",
        "djdt": "hide",
        "sessionid": "mt3asqjzf8fsk6mlhplz6uyiahw6es23",
    }
    boundary = "----WebKitFormBoundaryFTEq5swUadPoHOyD"
    headers = {
        "X-CSRFToken": csrf_token,
        # "Content-Type": "multipart/form-data; boundary={}".format(boundary),
    }
    with aiohttp.MultipartWriter("form-data", boundary=boundary) as mpwriter:
        mpwriter.append(
            data,
            {
                "Content-Disposition": 'form-data; name="json"; filename="blob"',
                "Content-Type": "application/json",
            },
        )
        async with session.post(
            _API + "/api/submit_form/", data=mpwriter, headers=headers, cookies=cookies
        ) as resp:
            res = await resp.json()

this is due to multipart writer setting value to None explicitly when calling super() https://github.com/aio-libs/aiohttp/blob/master/aiohttp/multipart.py#L781
https://github.com/aio-libs/aiohttp/blob/master/aiohttp/payload.py#L128
Which the send event expects to be a value https://github.com/loads/molotov/blob/master/molotov/listeners.py#L30
It might make sense to have a writer instead to use to set the value using https://github.com/aio-libs/aiohttp/blob/master/aiohttp/payload.py#L196

Hey @KoalaTea - would you  be interested to contribute this feature? I have a bit of time to work on molotov again


Add .NET Provider

As part of implementing konveyor/enhancements#179, kantra must enable the dotnet-external-provider.

🎆 🤜 🤛


riemann-dash: 0.2.12 -> 0.2.14, use bundlerApp

Motivation for this change
New version available, security issues found by bundler-audit, and cleaner package using bundlerApp.
Things done

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

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

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

@GrahamcOfBorg build riemann-dash


Optional Label for Flights: Route type

One common element used by many airlines Type of route, this is to indicate if the route is Regional, Short Haul, Long Haul or Ultra Long Haul.
My airline uses this not only as a guide for pilots on the length of the route, but also to restrict novice pilots from flying international routes or long hauls.
I am aware a custom field can be added for this purpose, but I think is a common enough element that should be present by default as an optional element.

Would something generic, like tags, be a good solution?

I think I can add this as tags, is it only for searching/sorting on? Or is there some sort of restriction on the tags

could work, this can also be used to restrict these types based on rank


Transfer Pangeo infrastrcuture from Columbia into 2i2c territory

Context
After failure to get sustainable access to Columbia playground: https://github.com/2i2c-org/meta/issues/348, we decided we need to move forward with moving Pangeo infra to a 2i2c managed account.
We have an agreement from the community representative as per: https://github.com/2i2c-org/meta/issues/348#issuecomment-1279241994.
We need to figure out details about capacity involvement and the timeline.
Proposal
No response
Updates and actions
No response

Given pangeo access is part of onboarding checklist eg  2i2c-org/team-compass#651 is this likely to transferred anytime soon, and would I need access to existing?

@pnasrat I think we have given up on this happening for now, so you'd have to access the existing one I think.

That's correct. We are now in the last year of that Columbia-held Pangeo infrastructure grant.  I am working on a few avenues on what a PangeoCloud 2.0 may look like (and how it would be paid for) but, for now, going through Columbia IT is still required.

We did learn from Columbia that it shouldn't be too complex to set up "pass through billing", especially since we already do this with the VICTOR project at Columbia. I think it would require some extra work to figure out the contract details. It might be a significant amount of work and/or several months before it was completed (and I'd recommend @jmunroe spearhead this if we want to go that route). But just sharing here in case people really think the benefit would be worth it.

Note that we'll need to create an amended version of our contract with Columbia as part of the no-cost extension in https://github.com/2i2c-org/meta/issues/431. So this is the time to explore doing pass-through cloud costs if we want to do it. However if I don't get a strong signal from engineering that we need to do this, I'm not going to push it.

So this is the time to explore doing pass-through cloud costs if we want to do it. However if I don't get a strong signal from engineering that we need to do this, I'm not going to push it.

To answer that implicit question, I think we need to have a better picture about

I am working on a few avenues on what a PangeoCloud 2.0 may look like (and how it would be paid for)

@jmunroe, I think this is a topic for our shared agenda in the Comm and Eng meeting (already added it as a point to discuss).

FYI I've updated the top comment of the original tracking issue and we can use that to track the various steps in the process:

https://github.com/2i2c-org/meta/issues/279

We have decided this is not going to happen, and just make sure we don't get into more of these situations.


Invalid generated query where using columns as part of the update

Version: from 3.18.0 to 4.1.0
Module: quill-jdbc
Database: postgresql
Expected behavior
Using columns as part of the update as documented:
https://getquill.io/#writing-queries-actions-updatevalue-update
Generate a valid SQL query.
Actual behavior
val a = quote {
query[Person].filter(p => p.id == lift(999)).update(dummy => dummy.currentAge-> (dummy.currentAge+ 1))
}
Generate, at least on prepared queries used for compile time validation, an invalid statement, where variable name is used:
PREPARE p1 AS UPDATE persons SET current_age = (dummy.current_age + 1)

Note that column name have been correctly computed using snake case here.
Steps to reproduce the behavior
Create a query, using columns as part of the update and set-up compile-time query validation.
Workaround
Closest working version 3.16.5
@getquill/maintainers

I'm not sure about the difference between postgresql and mysql in regards to the query generation,
but what seems to be working is when all the parameter names are the same with version 4.1.0-V2:
quote {
  query[Person].filter(p => p.id == lift(999)).update(dummy => dummy.currentAge-> (dummy.currentAge+ 1))
}

turns into

UPDATE person AS p SET current_age = (dummy.current_age + 1) WHERE p.id = ?

quote {
  query[Person].filter(p => p.id == lift(999)).update(p => p.currentAge-> (p.currentAge+ 1))
}

turns into

UPDATE person AS p SET current_age = (p.current_age + 1) WHERE p.id = ?


Parameter onload="ciLoadDone();" is invalid

In the script tag example you have an onload event. that does not seem to be a valid function in the CILibrary.

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

ID: a832a509-b18c-d53c-2a31-dea5f85f09c4
Version Independent ID: 71b52352-5135-6ed3-b3f5-34df9c882915
Content: Pass Dynamics 365 URL to widget library
Content Source: ce/customer-service/channel-integration-framework/pass-url-widget-library.md
Service: dynamics-365-customerservice
GitHub Login: @susikka
Microsoft Alias: susikka

@MitchMilam Onload event is a JavaScript functionality and not a feature that is implemented in the CILibrary. I am working with internal developers to confirm this. Please stand by till further info.

ciLoadDone() is a function defined in the softphone sample code. So it is valid when softphone code is used for integration.
As I mentioned earlier, onload event is a standard JavaScript event to perform any action on the onload of the object. You can skip adding this tag if this is not relevant for your use case.


Support Task to run on Ray to have distributed capabilities.

seems interesting, can you elaborate more on that?


make style vs. static analysis rule groups clearer in README

Make the distinction more clear. Probably need another level over the 4 groups of rules up top.
Also need to link to the Node resolver readme/changelog from the core readme/changelog.

I self-assigned this, but anyone who wants to help re-write, the assistance is welcome. 😅

This also shouldn't hold up 2.0, since it's not semver-major.


Add file support

If a user is doing local development it helps
to have the Image Url include http

Thank you so much for this! I'm sorry it took me so long, but these changes are included in v1.4.0.
Cheers :tada:


Bump rust toolchain to 1.41.1

Motivation
Get the latest compile time checking fixes for statics.
Have you read the [Contributing Guidelines on pull requests]
yes
Test Plan
build/test/ci
Related PRs
none

@metajack, r+ when you've a moment.

@bors-libra r+

:pushpin: Commit d9cefb0 has been approved by metajack

:hourglass: Testing commit d9cefb040fb79520254525f00b1aa4100f4f2a09 with merge 2ff7bc1da7516ff5f57e2910e58e873923bc099d...

:broken_heart: Test failed - checks-circle_commit_workflow

@bors-libra retry
flaky test: smoke_test::test_full_node_basic_flow stdout
@rexhoffman Please file a bug for this flaky test if there's not one already. We'll probably also want to create a PR to add #[ignore] to the test or whatever.

:hourglass: Testing commit d9cefb040fb79520254525f00b1aa4100f4f2a09 with merge 74318b67f528a48583e772dca56f9f0433119b8d...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: metajack
Pushing 74318b67f528a48583e772dca56f9f0433119b8d to master...


Revise thermostat

https://github.com/JuliaReach/ReachabilityModels.jl/blob/79423d5c5dc709c8698c84d49dff880287d32bce/src/meta/thermostat.jl#L3

use INT since it is 1D.

set fixpoint_check = false

add new model ClockedThermostat that has a time variable in the state space.

ref notebook: https://github.com/mforets/escritoire/blob/master/2020/Week36/ClockedThermstat.ipynb


UI Bug / Improvement Request: Import data Dialog Box

When I import data from another table the records processed message flashes too quickly to be read.
Can you break out the ui on that show it shows records processed and then next line has executing statement...  or something else you deem appropriate.
Basically I'd like to be able to read the message.

What do you think about database messages about import statements ?

I'm not sure I understand what you mean.

It is a bug in progress monitor, will be fixed in the next version. Thanks for report.
But I can't show statement text because:

It can be too long (sometimes it takes hundreds of Kb and just printing it slows UI dramatically)
Statement execution happens too often (thousands times per second) and also slows UI

@serge-rider  yea that makes sense when I said "executing statement" i literally just meant the text "executing statements..." or something like that.


moving relevant pages to content/nodes

Closes: #???
Description

For contributor use:

[ ] Targeted PR against master branch
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Updated relevant documentation
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Added appropriate labels

these changes are now part of https://github.com/onflow/flow/pull/1105


403 Forbidden on API docs link

http://ceylon-lang.org/code/source/#ceylonlanguage_module links to "See the API documentation for more information." at
http://ceylon-lang.org/documentation/api/current/
That page gives me 403 Forbidden.
The page at http://ceylon-lang.org/documentation/api/current/ceylon/language works.

Fixed, thanks.


TypeError: Cannot read property 'reduce' of undefined

Hey, thanks for the library.
I'm having issues using gulp-flatten. I am using
  return gulp.src('./components/**/*.pug')
        // .pipe(print())
        .pipe(flatten())
        .pipe(pug({ verbose : false }))
        .pipe(gulp.dest("./../public/templates/"))

also tried
  return gulp.src('./components/**/*.pug')
        // .pipe(print())
        .pipe(pug({ verbose : false }))
        .pipe(flatten())
        .pipe(gulp.dest("./../public/templates/"))

Both produce the following error:
 TypeError: Cannot read property 'reduce' of undefined
    at _flatten (/home/james/Code/3drepo.io/frontend/node_modules/flatten/index.js:14:16)
    at flatten (/home/james/Code/3drepo.io/frontend/node_modules/flatten/index.js:11:10)
    at Gulp.<anonymous> (/home/james/Code/3drepo.io/frontend/gulpfile.js:56:15)
    at module.exports (/home/james/Code/3drepo.io/frontend/node_modules/orchestrator/lib/runTask.js:34:7)
    at Gulp.Orchestrator._runTask (/home/james/Code/3drepo.io/frontend/node_modules/orchestrator/index.js:273:3)
    at Gulp.Orchestrator._runStep (/home/james/Code/3drepo.io/frontend/node_modules/orchestrator/index.js:214:10)
    at Gulp.Orchestrator.start (/home/james/Code/3drepo.io/frontend/node_modules/orchestrator/index.js:134:8)
    at /usr/local/lib/node_modules/gulp/bin/gulp.js:129:20
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickCallback (internal/process/next_tick.js:104:9)

Using:
Node.js LTS 6.11.2
Gulp 3.9.1

Hey, @JamesMilnerUK
Sorry for late reply. Could you try following:
gulp.src('./components/**/*.pug')
        .pipe(flatten())
        .pipe(gulp.dest("./../public/templates/"))

Does it work?

I believe you tried using the flatten package, and not gulp-flatten.
npm install gulp-flatten --save-dev

var flatten = require('gulp-flatten');


Map Pan/Drag in Tablet/Mobile mode not working

I installed arcgis/webpack-plugin (^4.14) and noticed that my application in chrome in tablet or mobile mode has issues with panning/dragging.
If I run this git hub code it is giving me the same problem. If I change arcgis/webpack plugin to 4.13 then it works fine.

@dimpyvirk  Can you duplicate the behavior using this sample app in tablet or mobile mode? https://developers.arcgis.com/javascript/latest/sample-code/sandbox/index.html?sample=intro-mapview.
If the sample app works then the ArcGIS API for JavaScript is most likely not the issue. Usually these issues are related to CSS problems such as a DIV obscuring the map.
Be sure to update the CSS to the corresponding ArcGIS JS API version.  Also note, 4.15 is the latest API version: https://www.npmjs.com/package/@arcgis/webpack-plugin

@andygup the javascript code works fine https://developers.arcgis.com/javascript/latest/sample-code/sandbox/index.html?sample=intro-mapview.
The issue comes when running with angular. It works fine on Mozilla (in tablet) but not on chrome.

Interesting, it could be a zone.js issue. It works on my machine with "zone.js": "~0.10.2"

Did you try with ArcGIS JS API 4.15?
Which version of zone.js? Angular? Chrome?

Closing, no activity.

I noticed this problem emerged when upgrading from API 4.13 to 4.14. Seems to be related to this "Embedded map navigation enhancements" introduced in 4.14 as stated here.
I tryied forcing my "zone.js" to "0.10.2" but the issue persists. I'm trying to tweak a workaround on this, otherwise am stuck with 4.13. Any help on this would be much appreciated.

I noticed this problem emerged when upgrading from API 4.13 to 4.14. Seems to be related to this "Embedded map navigation enhancements" introduced in 4.14 as stated here since when pan fails the window is actually scrolled.
I tryied forcing my "zone.js" to "0.10.2" but the issue persists. I'm trying to tweak a workaround on this, otherwise am stuck with 4.13. Any help on this would be much appreciated.

@joaopaschoal can you try 4.16?

@dimpyvirk , I've already tryied the latest 4.17 and the problem is still. Anyhow I've just tryied esri-loader 2.15.0 which ships with api 4.16 with no success.

@joaopaschoal we'll also need the following info, thanks:

Device make/model
OS version
Browser and version

@dimpyvirk I belive Esri API uses dojo v5.0.4 since API v4.12, as noted here.
@andygup  my current environment is:

Windows 10 x64
Angular CLI: 7.3.10
Node: 10.20.1
Device: You can reproduce it directly from Chrome Dev Tools (toggle device mode) but it also happened in all Android devices we have tested so far :( take mine for instance: Xiaomi Redmi 4 Pro - Android 6.0.1 - MIUI Global <IP_ADDRESS>.
Browser: Google Chrome 86.0.4240.75 64 bit

I've also decided to create a simple repo reproducing this issue.
Thank you guys so much for any help, if there is anything I can do to assist or additional info I'll be glad to provide it.

@joaopaschoal thanks for the info. My first suggestion is to build this webpack branch of the repo and see if you have the same issues. Clone and npm install shouldn't take long.
It's possible Angular 7 is the culprit, it's a little over 2 years old now. This repo is using Angular 10. I tested it okay on an Android Pixel 2 - Android 11 - Chrome 86.

I've managed to isolate the problem, it was just a silly mistake of mine: I've found the imported css was still pointing to v4.13 (doh!)
@dimpyvirk , in case you are still stuck with this issue, make sure to also upgrade the css url. Mine seems stable now.
Thanks one more time for valuable help :) and sorry for this silly mistake.


Dataset

Hello Author ,
This is an amazing open source project especially for vocoders.
I was wondering if I can get the 78 hours dataset ? and if it is used in any training I would definitely cite you/the repo.
Thanks in advance!

The dataset has been contributed by various people, and I don't have the permission to redistribute it. There is a table with all contributors listed at https://utau.pl/hifipln/ if you ask them, maybe they'll be willing to share.


how can we get inputs and outputs from our python script

Could you please tell me how I can print out or output something to show my uploaded python script actually was successful?
Thanks!

Hi @IntrinsicInnovation. There are 2 solutions for this:

Send the output to your own server.
Raise an exception to contain your output. This can be later viewed as part of the upload status.

Thanks for that.  Also, is there an actual crypto mining python script that works with it?  (new to python here.)

@IntrinsicInnovation Iv’e never tried to execute a real miner as its against Azure license.


make-mod-scripts is not buildable with linux-linaro-qcomlt

If we enable any feature or package that requires out-of-tree kernel modules to be built then meta-qcom based builds fail because linux-linaro-qcomlt is not compatible with make-mod-scripts. In particular this makes is difficult to set the tools-profile image feature (because it tries to build lttng-modules).
So far I have tested only the dunfell packages. Is linux-linaro-qcomlt expected to support out-of-tree kernel modules?
Currently I have adopted the following trivial workaround but if this is something that should be fixed...
# Disable LTTng dependencies when building for qcom family parts. This is
# required because linux-linaro-qcomlt does not support out-of-tree
# module builds so we must avoid pulling in lttng-modules.
LTTNGUST:pn-packagegroup-core-tools-profile:qcom = ""
LTTNGTOOLS:pn-packagegroup-core-tools-profile:qcom = ""
LTTNGMODULES:pn-packagegroup-core-tools-profile:qcom = ""

well, I would say that it is not expected to fail.. what's the simplest way to reproduce the issue?

The simplest way is just to bitbake make-mod-scripts (normally the recipe gets pulled by the following line in module-base.bbclass, do_configure[depends] += "make-mod-scripts:do_compile").
An example error log is below, it is based on dunfell/db410c (using poky + meta-qcom):
| DEBUG: Executing python function extend_recipe_sysroot
| NOTE: Direct dependencies are ['virtual:native:/build/drt/openembedded/poky-3.1-dunfell/meta/recipes-devtools/bison/bison_3.5.4.bb:do_populate_sysroot', '/build/drt/openembedded/poky-3.1-dunfell/meta/recipes-kernel/kmod/kmod-native_git.bb:do_populate_sysroot', 'virtual:native:/build/drt/openembedded/poky-3.1-dunfell/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot', 'virtual:native:/build/drt/openembedded/poky-3.1-dunfell/meta/recipes-extended/bc/bc_1.07.1.bb:do_populate_sysroot', '/build/drt/openembedded/poky-3.1-dunfell/meta/recipes-devtools/binutils/binutils-cross_2.34.bb:do_populate_sysroot', 'virtual:native:/build/drt/openembedded/poky-3.1-dunfell/meta/recipes-connectivity/openssl/openssl_1.1.1l.bb:do_populate_sysroot', '/build/drt/openembedded/poky-3.1-dunfell/meta/recipes-devtools/gcc/gcc-cross_9.3.bb:do_populate_sysroot', 'virtual:native:/build/drt/openembedded/poky-3.1-dunfell/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:/build/drt/openembedded/poky-3.1-dunfell/meta/recipes-support/gmp/gmp_6.2.0.bb:do_populate_sysroot', '/build/drt/openembedded/poky-3.1-dunfell/meta/recipes-devtools/quilt/quilt-native_0.66.bb:do_populate_sysroot', 'virtual:native:/build/drt/openembedded/poky-3.1-dunfell/meta/recipes-support/lzop/lzop_1.04.bb:do_populate_sysroot', '/build/drt/openembedded/poky-3.1-dunfell/meta/recipes-core/glibc/glibc_2.31.bb:do_populate_sysroot', '/build/drt/openembedded/poky-3.1-dunfell/meta/recipes-devtools/gcc/gcc-runtime_9.3.bb:do_populate_sysroot', 'virtual:native:/build/drt/openembedded/poky-3.1-dunfell/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot']
| NOTE: Installed into sysroot: ['kmod-native', 'openssl-native', 'lzop-native', 'python3-native', 'gtk-doc-native', 'lzo-native', 'libnsl2-native', 'gdbm-native', 'util-linux-native', 'bzip2-native', 'sqlite3-native', 'libtirpc-native', 'libffi-native', 'libcap-ng-native', 'libpcre2-native']
| NOTE: Skipping as already exists in sysroot: ['bison-native', 'pkgconfig-native', 'bc-native', 'binutils-cross-aarch64', 'gcc-cross-aarch64', 'pseudo-native', 'gmp-native', 'quilt-native', 'glibc', 'gcc-runtime', 'patch-native', 'automake-native', 'libtool-native', 'xz-native', 'gnu-config-native', 'flex-native', 'texinfo-dummy-native', 'gettext-minimal-native', 'autoconf-native', 'zlib-native', 'readline-native', 'libmpc-native', 'linux-libc-headers', 'mpfr-native', 'libgcc', 'attr-native', 'm4-native', 'ncurses-native']
| DEBUG: sed -e 's:^[^/]*/:/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native/:g' /build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/sysroots-components/x86_64/openssl-native/fixmepath /build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/sysroots-components/x86_64/python3-native/fixmepath /build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/sysroots-components/x86_64/gtk-doc-native/fixmepath /build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/sysroots-components/x86_64/libpcre2-native/fixmepath | xargs sed -i -e 's:FIXMESTAGINGDIRTARGET:/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot:g; s:FIXMESTAGINGDIRHOST:/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native:g' -e 's:FIXME_PSEUDO_SYSROOT:/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/sysroots-components/x86_64/pseudo-native:g' -e 's:FIXME_HOSTTOOLS_DIR:/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/hosttools:g' -e 's:FIXME_PKGDATA_DIR:/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/pkgdata/dragonboard-410c:g' -e 's:FIXME_PSEUDO_LOCALSTATEDIR:/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/pseudo/:g' -e 's:FIXME_LOGFIFO:/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/temp/fifo.206557:g'
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing shell function do_configure
| NOTE: make HOSTCC=gcc  -isystem/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native/usr/include -O2 -pipe -L/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native/usr/lib                         -L/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native/lib                         -Wl,--enable-new-dtags                         -Wl,-rpath-link,/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native/usr/lib                         -Wl,-rpath-link,/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native/lib                         -Wl,-rpath,/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native/usr/lib                         -Wl,-rpath,/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native/lib                         -Wl,-O1 -Wl,--allow-shlib-undefined -Wl,--dynamic-linker=/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 HOSTCPP=gcc  -E HOSTCXX=g++  -isystem/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native/usr/include -O2 -pipe -L/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native/usr/lib                         -L/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native/lib                         -Wl,--enable-new-dtags                         -Wl,-rpath-link,/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native/usr/lib
  -Wl,-rpath-link,/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native/lib                         -Wl,-rpath,/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native/usr/lib                         -Wl,-rpath,/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native/lib                         -Wl,-O1 -Wl,--allow-shlib-undefined -Wl,--dynamic-linker=/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 CC=aarch64-poky-linux-gcc   -fuse-ld=bfd -fmacro-prefix-map=/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0=/usr/src/debug/make-mod-scripts/1.0-r0                      -fdebug-prefix-map=/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0=/usr/src/debug/make-mod-scripts/1.0-r0                      -fdebug-prefix-map=/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot=                      -fdebug-prefix-map=/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/recipe-sysroot-native=  -fdebug-prefix-map=/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work-shared/dragonboard-410c/kernel-source=/usr/src/kernel LD=aarch64-poky-linux-ld.bfd   AR=aarch64-poky-linux-ar  -C /build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work-shared/dragonboard-410c/kernel-source O=/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work-shared/dragonboard-410c/kernel-build-artifacts prepare
| make: Entering directory '/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work-shared/dragonboard-410c/kernel-source'
| make[1]: Entering directory '/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work-shared/dragonboard-410c/kernel-build-artifacts'
| /build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work-shared/dragonboard-410c/kernel-source/Makefile:658: include/config/auto.conf: No such file or directory
| /build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work-shared/dragonboard-410c/kernel-source/Makefile:706: include/config/auto.conf.cmd: No such file or directory
|   SYNC    include/config/auto.conf.cmd
|   GEN     Makefile
|   HOSTCC  scripts/basic/fixdep
|   HOSTCC  scripts/kconfig/conf.o
|   HOSTCC  scripts/kconfig/confdata.o
|   HOSTCC  scripts/kconfig/expr.o
|   LEX     scripts/kconfig/lexer.lex.c
|   YACC    scripts/kconfig/parser.tab.[ch]
|   HOSTCC  scripts/kconfig/lexer.lex.o
|   HOSTCC  scripts/kconfig/menu.o
|   HOSTCC  scripts/kconfig/parser.tab.o
|   HOSTCC  scripts/kconfig/preprocess.o
|   HOSTCC  scripts/kconfig/symbol.o
|   HOSTCC  scripts/kconfig/util.o
|   HOSTLD  scripts/kconfig/conf
|   GEN     Makefile
|   HOSTCC  scripts/dtc/dtc.o
|   HOSTCC  scripts/dtc/flattree.o
|   HOSTCC  scripts/dtc/fstree.o
|   HOSTCC  scripts/dtc/data.o
|   HOSTCC  scripts/dtc/livetree.o
|   HOSTCC  scripts/dtc/treesource.o
|   HOSTCC  scripts/dtc/srcpos.o
|   HOSTCC  scripts/dtc/checks.o
|   HOSTCC  scripts/dtc/util.o
|   LEX     scripts/dtc/dtc-lexer.lex.c
|   YACC    scripts/dtc/dtc-parser.tab.[ch]
|   HOSTCC  scripts/dtc/dtc-lexer.lex.o
|   HOSTCC  scripts/dtc/dtc-parser.tab.o
|   HOSTLD  scripts/dtc/dtc
|   HOSTCC  scripts/dtc/libfdt/fdt.o
|   HOSTCC  scripts/dtc/libfdt/fdt_ro.o
|   HOSTCC  scripts/dtc/libfdt/fdt_wip.o
|   HOSTCC  scripts/dtc/libfdt/fdt_sw.o
|   HOSTCC  scripts/dtc/libfdt/fdt_rw.o
|   HOSTCC  scripts/dtc/libfdt/fdt_strerror.o
|   HOSTCC  scripts/dtc/libfdt/fdt_empty_tree.o
|   HOSTCC  scripts/dtc/libfdt/fdt_addresses.o
|   HOSTCC  scripts/dtc/libfdt/fdt_overlay.o
|   HOSTCC  scripts/dtc/fdtoverlay.o
|   HOSTLD  scripts/dtc/fdtoverlay
|   HOSTCC  scripts/kallsyms
|   HOSTCC  scripts/sorttable
|   HOSTCC  scripts/asn1_compiler
|   HOSTCC  scripts/extract-cert
|   GEN     arch/arm64/include/generated/asm/cpucaps.h
|   CC      scripts/mod/empty.o
|   HOSTCC  scripts/mod/mk_elfconfig
|   MKELF   scripts/mod/elfconfig.h
|   HOSTCC  scripts/mod/modpost.o
|   CC      scripts/mod/devicetable-offsets.s
|   UPD     scripts/mod/devicetable-offsets.h
|   HOSTCC  scripts/mod/file2alias.o
|   HOSTCC  scripts/mod/sumversion.o
|   HOSTLD  scripts/mod/modpost
|   CC      kernel/bounds.s
|   CC      arch/arm64/kernel/asm-offsets.s
|   CALL    /build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work-shared/dragonboard-410c/kernel-source/scripts/checksyscalls.sh
|   CALL    /build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work-shared/dragonboard-410c/kernel-source/scripts/atomic/check-atomics.sh
|   LDS     arch/arm64/kernel/vdso/vdso.lds
|   CC      arch/arm64/kernel/vdso/vgettimeofday.o
|   AS      arch/arm64/kernel/vdso/note.o
|   AS      arch/arm64/kernel/vdso/sigreturn.o
|   LD      arch/arm64/kernel/vdso/vdso.so.dbg
|   VDSOSYM include/generated/vdso-offsets.h
|   OBJCOPY arch/arm64/kernel/vdso/vdso.so
| objcopy: Unable to recognise the format of the input file `arch/arm64/kernel/vdso/vdso.so.dbg'
| /build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work-shared/dragonboard-410c/kernel-source/arch/arm64/kernel/vdso/Makefile:61: recipe for target 'arch/arm64/kernel/vdso/vdso.so' failed
| make[2]: *** [arch/arm64/kernel/vdso/vdso.so] Error 1
| /build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work-shared/dragonboard-410c/kernel-source/arch/arm64/Makefile:201: recipe for target 'vdso_prepare' failed
| make[1]: *** [vdso_prepare] Error 2
| make[1]: Leaving directory '/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work-shared/dragonboard-410c/kernel-build-artifacts'
| Makefile:219: recipe for target '__sub-make' failed
| make: *** [__sub-make] Error 2
| make: Leaving directory '/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work-shared/dragonboard-410c/kernel-source'
| ERROR: oe_runmake failed
| WARNING: /build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/temp/run.do_configure.206557:1 exit 1 from 'exit 1'
| ERROR: Execution of '/build/drt/openembedded/poky-3.1-dunfell/build-dragonboard-410c/tmp/work/dragonboard_410c-poky-linux/make-mod-scripts/1.0-r0/temp/run.do_configure.206557' failed with exit code 1
~~

@daniel-thompson I could not reproduce bitbake make-mod-scripts failure this either with master or with dunfell branch, either with rpb distro or with nodistro (and using jut oe-core, meta-oe and meta-qcom). Could you please clarify, which kernel recipe is building the shared kernel source (and what is the commit id).

thanks. I could reproduce with dunfell.
We need to cherry pick
ddad8183490c (make-mod-scripts: pass CROSS_COMPILE to configure and build)
in oe-core/dunfell, it was merged in oe-core/master. I suspect it was needed in 'recent' kernel version.

that seems to be the context: https://lists.openembedded.org/g/openembedded-core/message/150143. Seems it's needed for 5.12++
I will ask the dunfell maintainer to take this patch.

Resolved in oe-core


Todos

1、Add support for ModelViewSet.  Views are not currently supported to inherit from ModelViewSet，because I don't know if the GET method comes from the retrieve() or the list()

finish