[SPARK-36824][R] Add sec and csc as R functions

What changes were proposed in this pull request?

Add secant and cosecant as R functions.
Why are the changes needed?

SEC and CSC have been added thus these functions need R support.
Does this PR introduce any user-facing change?

Yes, users can now call those functions as R functions.
How was this patch tested?

unit tests added.

Test build #143499 has started for PR 34067 at commit 1464972.

Test build #143499 has finished for PR 34067 at commit 1464972.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/48010/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/143499/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/48010/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/48010/

Merged to master.


WIP: Stripe Payments Intents API SCA-compliant Payment Plugin

Signed-off-by: Janus Reith<EMAIL_ADDRESS>Resolves #1 and #5304(Reaction Repo)
Impact: breaking|major
Type: feature|refactor
Issue
The existing Stripe Payment Plugin relies on a deprecated API, and is not usable in the EU anymore (potentially similar regulations outside EU too) due to Strong Customer Authentication.
Solution
This PR adds a new Payment Plugin for the Stripe Payment Intents API, which implements necessary requirements for SCA.
It covers creating a Payment Intent using a new GraphQL mutation createStripePaymentIntent and the four default Payment provider actions: Create a payment, Capture a payment, List refund, Create a refund.
Besides the stripe credit cart from, this API plugin also works with the wide range of other Payment solutions enabled through stripe, like Google Pay or Apple Pay, since these also rely on the same Payment Intents API.
Breaking changes
This plugin should be able to run independently from the existing stripe plugin and should, although not verified yet, be able to run side by side.
The storefront might receive a breaking change if we replace the Stripe integration there with the SCA-compliant one, will elaborate further in a separate issue.
Testing

Add the new Stripe integration to your storefront(Instructions WIP, I have it prepared but figuring out wether to make it a separate package and best practices for distribution in general. Could also PR it right to storefront for now. )
Add the Stripe API Keys to both storefront and API, Keys are the same format as before.
Create a cart and proceed though the checkout steps
Complete the order by using Stripe Testing CC numbers. Be sure to check with 3D-secure enabled cards too see 2FA in action.
Capture the payment for the new order in the backend
Issue a partial refund, see that the created refund(s) are listed.

Maybe also check back with your Stripe Dashboard to confirm transactions.
Todo
Integration tests for the four payment plugin functions and the token mutation need to be added.
Further thinking
To keep things simple, createStripePaymentIntent will for now take the cartId and optionally the cartToken(similar to the anonymous/account cart when adding cart items) and create a payment intent in stripe for that cart total.
This reflects the way existing Payment plugins works on the cart level.
Other use-cases might be direct single-product checkouts which skip a cart entirely. (Did this for client projects, works).
We could make providing a cartId optional and optionally accept productConfiguration(productId + variantId) and the id of a fulfillment Method instead to calculate a total out of that.

pushing to internal branch in order to work on next steps.

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Follow up Copenhagen BIDS-Prov meeting

This issue is open to keep track of discussions / things to do following BIDS-derivatives meeting :

We need an example in BIDS-Prov spec on how to include custom code for some of the steps
The file-level provenance that we had in older version can be more intuitive when writing the provenance of a single file and should probably included back in the spec

Tentative examples from ephys are at: https://github.com/bids-standard/bep021/issues/8#issuecomment-1604206239

Question could the BIDS-Prov file be in .prov.json and not .prov.jsonld to be simpler for the devs who know json (suggestion by Arnault)
We should consider making it possible to use BIDS url as identifiers

Dora, Stefan, Arnault, Robert, Camille discussed Prov in ephys


Adding engines field to warn the user about node compatibility

https://docs.npmjs.com/files/package.json#engines
#14

Thanks.


exomiser prioritization broken for some genes

Traceback (most recent call last):
   File "/usr/src/app/variants/models/jobs.py", line 189, in run_query_bg_job
     _inner()
   File "/usr/src/app/variants/models/jobs.py", line 173, in _inner
     for batch in batched(
  File "/usr/src/app/variants/models/jobs.py", line 36, in batched
     batch = list(islice(it, n))
   File "/usr/src/app/variants/models/jobs.py", line 113, in _read_records
     payload["phenotype_score"] = phenotype_scores[line.entrez_id]
 KeyError: '83642'

RCA
The genes are properly scored. Some of the genes of the variants have no corresponding entrez id in the results of the exomiser.
Resolution proposal
Return None if the entrez id can't be looked up.


feat!: refactor detection & add yarn berry support

This PR is a bit of a breaking change, but one that makes sense in my eyes.
Before we had a very simple structure, the package manager name was also the command, for a lock file there was an extra type.
However, this causes problems if you want to provide support for multiple Package Manager versions, as an example yarn berry but also pnpm 6.
Because I can't just add "yarn" or "pnpm" to the package manager array again.

With this PR everything is brought together, there is an array with the Package Manager objects which contain the name, the version, the command and a lockFile.
#12
After this PR we can also solve #11, and we can add similiar situations with package Manager versions more easier in the future.

Thanks for working on this PR @Intevel and sorry for delay i needed a moment to check it locally.
I love the overall direction. Have added few refactors, to generalize idea of supporting same package manager with multiple versions. For yarn, we have two detectors for instance now.


Nice example

Very nice example.
What do you think about of a bit user interaction like mark an app in DetailsActivity as favorite?

I am happy you liked the example. Adding like/dislike feature is a nice feature. But unfortunately I don't have time these days to update this example, maybe after some weeks I will back to update it. Or if you like to participate in developing this example, it will be great :D


[SPARK-31768][ML][FOLLOWUP] add getMetrics in Evaluators: cleanup

What changes were proposed in this pull request?
1, make silhouette a method;
2, change return type of setDistanceMeasure to this.type;
Why are the changes needed?
see comments in https://github.com/apache/spark/pull/28590
Does this PR introduce any user-facing change?
No, 3.1 has not been released
How was this patch tested?
existing testsuites

Test build #134469 has started for PR 31334 at commit 9549fa3.

Test build #134469 has started for PR 31334 at commit 9549fa3.

Test build #134469 has finished for PR 31334 at commit 9549fa3.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test build #134469 has finished for PR 31334 at commit 9549fa3.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/134469/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/134469/

Merged to master/branch-3.1

Merged to master/branch-3.1

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/39055/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/39055/


when transfer .ditamap file to odt format output,the title of the odt file is not correct

when transfer .ditamap file to odt format output,the title of the odt file is not correct.
I try the pdf format,the title of pdf file is correct.
so maybe there is something wrong in the 'org.dita.odt' directory.
Here is the sample the dita install pkg give:

the correct title should be 'Working in the garage' which is in the sequence.ditamap file in the sample directory.
since we need to use dita to manage our user manual ,so pls help to give some feedback as soon,thanks

Fixed by #2059


Charts all switch to last chart instance data

When I resize the window, or click a chart legend, all my chart instances change to the last chart in the series.
Occurs when populating charts through $('.data-elements').each((i, el) => {
// populate chart instances here
});

@nickdeamons so you're creating new charts on resize? If so, you need to destroy() the old ones before reusing the canvas objects

I am using the existing canvas elements. I've confirmed that only the data points are changing, not the legend/axis.

is it possible to post a fiddle?

http://surescripts.msistg.com/NPR2015/
best I can do for now

I think its still related to needing to destroy() the old charts if new charts are being created but I couldn't find exactly where the charts are created.

This code generates charts:
_createClass(LineChart, [{
key: 'init',
value: function init(labelsObj, dataSetsObj, optionsObj) {
var self = this;
        self.dataObj = dataSetsObj;
        self.chartObj = new Chart(self.contextElement, {
            type: 'line',
            data: {
                datasets: self.dataObj,
                labels: labelsObj
            },
            options: optionsObj
        });

This code calls the class to generate the charts based on AJAX JSON data:
$.ajax({
dataType: 'json',
url: 'Content/data/DataExchangeCharts.json',
success: function success(data) {
$('.data-exchange').each(function (i, el) {
currentSettings = LineChartSettings;
var chartName = $(el).attr('data-chartName');
            currentChartData = data[chartName].dataPoints;
            var currentChart = new LineChart($(el).attr('id'), chartName);

            currentSettings.labels = data[chartName].labels;
            currentSettings.datasets[0].data = currentChartData;
            currentSettings.datasets[0].label = chartName;

            console.log(currentSettings.datasets[0].data);

            currentChart.init(currentSettings.labels, currentSettings.datasets, currentSettings.options);
        });
    }
});

I tried to have another look at this, but I can't find the implementation of LineChart even though I know it was there when I looked before

It looks like the code to debug this no longer exists. If I understood correctly, when the window resized new data was retrieved via Ajax and the charts recreated.
I think the modification to make this work would be to store the last created chart object for each canvas by name
var chartMap = new Map();

$.ajax({
        dataType: 'json',
        url: 'Content/data/DataExchangeCharts.json',
        success: function success(data) {
            $('.data-exchange').each(function (i, el) {
                currentSettings = LineChartSettings;
                var chartName = $(el).attr('data-chartName');

                currentChartData = data[chartName].dataPoints;

                // Ensure old chart is deleted before canvas is reused
                if (chartMap.has(chartName)) {
                  chartMap.get(chartName).destroy();
                  chartMap.delete(chartName);
                }
                var currentChart = new LineChart($(el).attr('id'), chartName);

                currentSettings.labels = data[chartName].labels;
                currentSettings.datasets[0].data = currentChartData;
                currentSettings.datasets[0].label = chartName;

                console.log(currentSettings.datasets[0].data);

                currentChart.init(currentSettings.labels, currentSettings.datasets, currentSettings.options);
                chartMap.set(chartName, currentChart);
            });
        }
    });


Docker autogenstudio

I updated the Dockerfile.full, and Dockerfile.base with autostarts for AutogenStudio. I figured there would probably be a lot of attention on this project. Now that we have an excellent front end, we might as well make it a seamless setup.
Why are these changes needed?
Easy setup for Autogen Studio
Related issue number
#1172  #1241

Checks

[ X] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
[ ] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[X ] I've made sure all auto checks have passed.

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

Comparison is base (135bca4) 32.11% compared to head (b63aec0) 31.92%.
Report is 4 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1275      +/-   ##
==========================================
- Coverage   32.11%   31.92%   -0.19%
==========================================
  Files          32       32
  Lines        4391     4394       +3
  Branches     1024     1025       +1
==========================================
- Hits         1410     1403       -7
- Misses       2865     2873       +8
- Partials      116      118       +2

Flag
Coverage Δ

unittests
31.92% <ø> (-0.14%)
:arrow_down:

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

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

Why the file start-docs-server.sh is added to the website folder?

And I believe these two PRs should coordinate?  Both are trying to add docker for autogenstudio. @victordibia @gagb

@r3d91ll before I review your PR what do you think about: #1286

I'm in full support of it. I didn't have the time to track down why the Dockerfile.dev had a package conflict. Your solution is elegant as it solves the local build issue I saw as well as the codespaces issue you found. We just need to make sure that users know to look in the .devcontainers. I'm willing to draft this for now or close in lieu of your pull.

@r3d91ll before I review your PR what do you think about: #1286

I'm in full support of it. I didn't have the time to track down why the Dockerfile.dev had a package conflict. Your solution is elegant as it solves the local build issue I saw as well as the codespaces issue you found. We just need to make sure that users know to look in the .devcontainers. I'm willing to draft this for now or close in lieu of your pull.

Thank you for the kind words! Would you like to draft it and I can very quickly review it?

@r3d91ll before I review your PR what do you think about: #1286

I'm in full support of it. I didn't have the time to track down why the Dockerfile.dev had a package conflict. Your solution is elegant as it solves the local build issue I saw as well as the codespaces issue you found. We just need to make sure that users know to look in the .devcontainers. I'm willing to draft this for now or close in lieu of your pull.

Thank you for the kind words! Would you like to draft it and I can very quickly review it?

Thank you for the consideration, but unfortunately, I will not have the time to give this the attention it deserves until early next week. Given the critical nature of ensuring a smooth development process and the importance of avoiding the pitfalls associated with developing as root – a topic I'm quite passionate about, as evidenced by my recent pull request (#1251) – it might be more pragmatic for you to take the lead on this.
If you're able to address it before Sunday, I will certainly make time to review it then. Otherwise, I plan to tackle it early next week. Our collective focus on providing clear guidance and maintaining best practices for our developers is paramount, especially in the context of developing as root and the risks that poses to our community.
Best regards

@r3d91ll before I review your PR what do you think about: #1286

I'm in full support of it. I didn't have the time to track down why the Dockerfile.dev had a package conflict. Your solution is elegant as it solves the local build issue I saw as well as the codespaces issue you found. We just need to make sure that users know to look in the .devcontainers. I'm willing to draft this for now or close in lieu of your pull.

Thank you for the kind words! Would you like to draft it and I can very quickly review it?

Thank you for the consideration, but unfortunately, I will not have the time to give this the attention it deserves until early next week. Given the critical nature of ensuring a smooth development process and the importance of avoiding the pitfalls associated with developing as root – a topic I'm quite passionate about, as evidenced by my recent pull request (#1251) – it might be more pragmatic for you to take the lead on this.
If you're able to address it before Sunday, I will certainly make time to review it then. Otherwise, I plan to tackle it early next week. Our collective focus on providing clear guidance and maintaining best practices for our developers is paramount, especially in the context of developing as root and the risks that poses to our community.
Best regards

I agree with the importance of this @r3d91ll! I will submit a PR tomorrow morning and add you as a reviewer :)

@r3d91ll before I review your PR what do you think about: #1286

I'm in full support of it. I didn't have the time to track down why the Dockerfile.dev had a package conflict. Your solution is elegant as it solves the local build issue I saw as well as the codespaces issue you found. We just need to make sure that users know to look in the .devcontainers. I'm willing to draft this for now or close in lieu of your pull.

Thank you for the kind words! Would you like to draft it and I can very quickly review it?

Thank you for the consideration, but unfortunately, I will not have the time to give this the attention it deserves until early next week. Given the critical nature of ensuring a smooth development process and the importance of avoiding the pitfalls associated with developing as root – a topic I'm quite passionate about, as evidenced by my recent pull request (#1251) – it might be more pragmatic for you to take the lead on this.
If you're able to address it before Sunday, I will certainly make time to review it then. Otherwise, I plan to tackle it early next week. Our collective focus on providing clear guidance and maintaining best practices for our developers is paramount, especially in the context of developing as root and the risks that poses to our community.
Best regards

I agree with the importance of this @r3d91ll! I will submit a PR tomorrow morning and add you as a reviewer :)

@r3d91ll here is the PR https://github.com/microsoft/autogen/pull/1333

@r3d91ll before I review your PR what do you think about: #1286

I'm in full support of it. I didn't have the time to track down why the Dockerfile.dev had a package conflict. Your solution is elegant as it solves the local build issue I saw as well as the codespaces issue you found. We just need to make sure that users know to look in the .devcontainers. I'm willing to draft this for now or close in lieu of your pull.

Thank you for the kind words! Would you like to draft it and I can very quickly review it?

Thank you for the consideration, but unfortunately, I will not have the time to give this the attention it deserves until early sometime next week. It might be more pragmatic for you to take the lead on this. My day job is pretty all-consuming at the moment and I can only spare time on my weekends.
If you can address it before Monday, I will certainly make time to review it then. Otherwise, I plan to tackle it sometime Monday or Tuesday at the earliest.
Best regards

@r3d91ll the other PR was merged, please feel free to suggest changes per your this PR: https://github.com/microsoft/autogen/pull/1333

FWIW I think that this PR could be improved by adding something about data/config persistence. As it stands any customisation a new user does will be lost when the container restarts. Maybe add something around volume mappings? Otherwise this is awesome and it does "just work" - nice work @r3d91ll

@gagb @victordibia checking in here.

@r3d91ll before I review your PR what do you think about: #1286

I'm in full support of it. I didn't have the time to track down why the Dockerfile.dev had a package conflict. Your solution is elegant as it solves the local build issue I saw as well as the codespaces issue you found. We just need to make sure that users know to look in the .devcontainers. I'm willing to draft this for now or close in lieu of your pull.

@r3d91ll the new dev containers were merged some time ago. If you'd like to include changes of this PR, let us know or better make a new PR.

@r3d91ll I am closing this PR. Please re-open if you need these changes.


[BETA] apm-beta link does not work to install packages from source

Prerequisites

[x] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: not possible for this particular problem, as it relies on loading packages.
Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
The usual means to install a package from source (for example if you're developing on it) is to clone the repository, apm link (or apm link --dev), and apm install. This doesn't work to install packages to atom-beta, at least on my and @t9md's macs. (see conversation on slack)
Steps to Reproduce

Install atom beta from atom.io/beta
Open it, and install the shell tools from the menu
Close it, and open up your terminal of choice (iTerm2 for me)
git clone https://github.com/thomaslindstrom/color-picker.git
note that this is just an example, you can use any package you like
cd color-picker
apm-beta link
apm-beta install
Re-open atom beta
Open settings > packages, and search for color-picker

Expected behavior:
The package is installed and I can configure its settings
Actual behavior:
The package shows the install button, does not work, and I cannot configure its settings
Reproduces how often:
100% of the time, as far as I can tell
Versions
$ atom-beta --version
Atom    : 1.51.0-beta0
Electron: 5.0.13
Chrome  : 73.0.3683.121
Node    : 12.0.0

$ apm-beta --version
apm  2.5.0
npm  6.14.5
node 10.20.1 x64
atom 1.51.0-beta0
python 3.8.1
git 2.27.0

Additional Information
This isn't possible to test in safe mode, since it's based on installing and using a package, which safe mode disables.

this is fixed by #21065

the only work around is to downgrade to atom v1.50.0-beta-0

Closing this in favor of the linked issue. Thanks for the incredibly quick turnaround time, @UziTech


added coreosenabled option to create location and test

There is now an option to make a location CoreOS enabled on location create. Adding this field to the go-sdk.
sources: https://containers.cloud.ibm.com/global/swagger-global-api/#/satellite-location
https://cloud.ibm.com/docs/satellite?topic=satellite-locations#locations-create-cli

Tested locally:
In Dallas, London, Tokyo (CoreOS-supported)
-- coreos-enabled = true created a CoreOS-enabled location
-- coreos-enabled = false created a non-CoreOS-enabled location
-- no CoreOS option created a non-CoreOS-enabled location
In Osaka (no CoreOS support)
-- coreos-enabled = true returned expected error: "description": "IBM Cloud Satellite is not configured for HyperShift features in this region. Choose a different region and try again.",
-- coreos-enabled = false created a non-CoreOS-enabled location
-- no CoreOS option created a non-CoreOS-enabled location


Dev widget

I've added iframe to the bottom of the front page (index.html)
The iframe will display contents of flags.html, a new html page to just display the flags (tried to follow the same order from the crwa webpage: https://www.crwa.org/flagging-program.html)
Also, i've added code to the flagging.py so it can render flags.html. It's currently getting the data from dataframe locally.

Merged and LGTM! This one took a while, sorry about that, but it's in finally 🙌


Fix the S2 bugs in num_utils.py and ml_exp.py

metalibm: based on the commit 345616fbc8aa24542739b9a55486e91c2545065a
pythonsollya: based on the commit c40fa75977e7b90094bf9073b40e1da38b7f6e81

Thank you @TimoTokki for the request, it is ok from my point of view.


Meta issue for returns in functions with void related return types

This is a meta-issue for tracking errors associated with returns in block bodied sync and async functions whose return type is void, Future<void>, or FutureOr<void>.
Tests are here: https://dart-review.googlesource.com/c/sdk/+/52742
We say that a type T contains void if T is void, or if T is FutureOr<S> and S is void.
My understanding of the intended rules are as follows:

In an asynchronous function with return type T:

return; is an error unless flatten(T) is void
return exp; is an error if exp has static type S and flatten(S) is not assignable to flatten(T)
return exp; is an error if exp has static type S and flatten(T) is void and flatten(S) is not void

In a synchronous function with return type T

return; is an error unless T contains void
return exp; is an error if exp has static type S and S is not assignable to T
return exp; is an error if exp has static type S and T is void and S is not void
return exp; is an error if exp has static type S and T is FutureOr<void> and flatten(S) is not void

cc @lrhn @eernstg @munificent
@lrhn I'm not sure which side of the argument around return 3 in a void function you came down on.  The last rule from the async clause and the last two rules from the sync clause are intended to address those cases.  Let me know what you think.

I agree with almost everything here, except it's not covering all the FutureOr<void> cases.
And I still want to ensure that return; is equivalent to return null as void; in every way.
There are three different return type cases for synchronous functions:

is void
contains void (is FutureOr/n/<void>)
does not contain void.

The "is void" case only allows returning void. That includes return;, return voidExp; and fall-through at end of function.
The "contains void" cast allows returning void, but also allows returning anything up to Futuren<void>, but no further.
The handling of "is void" should be consistent with the "contains void" where /n/=0.
The "does not contain void case does not allow returning anything that contains void.
In other words, define (probably with a less generic name):
  matches(T, S) ::=
      true if `T` is `void` and `S` is `void`
      true if `T` is `FutureOr<X>` and matches(X, flatten(S))
      false otherwise

and then:

In a synchronous function with return type T

return; is an error unless T contains void
return exp; is an error if exp has static type S and S is not assignable to T
return exp; is an error if exp has static type S, T contains void, and not matches(T, S).

Since void is not assignable to anything but types containing void, the second item covers S being void and T not containing void.
The first item is compatible with return null as void since matches(T, void) would always be true when T contains void.
For asynchronous functions, we we really just flatten both types and do the same thing:

In an asynchronous function with return type T:

return; is an error unless flatten(T) contains void
return exp; is an error if exp has static type S and flatten(S) is not assignable to flatten(T)
return exp; is an error if exp has static type S, flatten(T) contains void, and not matches(flatten(T), flatten(S)).

I haven't checked if there is any +/-1 errors in my counting here, but I think it should work, and it looks remarkably symmetric (which I take as a good sign).
Synchronous examples allowed by this:
void foo() { return; }
void foo() { return null as void; }
void foo() { }
FutureOr<void> foo() { return; }
FutureOr<void> foo() { return null as void; }
FutureOr<void> foo() { return Future<void>.value(); }
FutureOr<void> foo() { return null as FutureOr<void>; }
FutureOr<FutureOr<void>> foo() { return; }
FutureOr<FutureOr<void>> foo() { return Future<void>.value(); }
FutureOr<FutureOr<void>> foo() { return Future<Future<void>>.value(); }
Object foo() { return 42; }

Disallowed examples:
void foo() { return 42; }
void foo() { return null as FutureOr<void>; }
FutureOr<void> foo() { return 42; }
FutureOr<void> foo() { return Future<int>.value(); }
FutureOr<void> foo() { return Future<Future<void>>.value(); }
FutureOr<FutureOr<void>> foo() { return Future<Future<Future<void>>>.value(); }
Object foo() { return; }
Object foo() { return null as void; }

Asynchronous examples allowed:
void foo() async { return; }
void foo() async { return null as void; }
void foo() async { return Future<void>.value(); }
Future<void> foo() async { return; }
Future<void> foo() async { return null as void; }
Future<void> foo() async { return Future<void>.value(); }
Future<void> foo() async { return Future<void>.value() as FutureOr<void>; }
Future<FutureOr<void>> foo() async { return; }
Future<FutureOr<void>> foo() async { return null as void; }
Future<FutureOr<void>> foo() async { return Future<void>.value(); }
Future<FutureOr<void>> foo() async { return Future<FutureOr<void>>.value(); }
Future<FutureOr<void>> foo() async { return Future<Future<void>>.value(); }
Future<FutureOr<void>> foo() async { return Future<Future<void>>.value() as FutureOr<Future<void>>; }
Object foo() async { return 42; }

Disallowed examples:
void foo() async { return 42; }
void foo() async { return Future<int>.value(); }
Future<void> foo() async { return 42; }
Future<void> foo() async { return Future<Future<void>>.value(); }
Future<FutureOr<void>> foo()  async { return 42; }
Future<FutureOr<void>> foo()  async { return Future<Future<int>>.value(); }
Future<FutureOr<void>> foo()  async { return Future<Future<Future<void>>>.value(); }
Object foo() async { return; }

The "is void" case only allows returning void. That includes return;, return voidExp; and fall-through at end of function.

I'm surprised that you don't want to allow returning FutureOr<void> from a void function since the analogy to regular assignability suggest it would (it "could work"), but it's fine with me.

The "contains void" cast allows returning void, but also allows returning anything up to Futuren<void>, but no further.
The handling of "is void" should be consistent with the "contains void" where /n/=0.

Note that my definition of contains was not recursive as you seem to be assuming here.  This was a deliberate choice to match the non-recursive nature of "flatten".  I'm fine with making it recursive though.  I think contains and matches might be better structured as the following then.
We say that T contains S iff one of the following is true:

T is S
T is FutureOr<X> and X contains flatten(S)

We say that T void contains S iff T contains void and T contains S.
Now we have the following rules:

In a synchronous function with return type T

return; is an error unless T contains void
return exp; is an error if exp has static type S and S is not assignable to T
return exp; is an error if exp has static type S, T does not void contain S

In an asynchronous function with return type T:

return; is an error unless flatten(T) contains void
return exp; is an error if exp has static type S and flatten(S) is not assignable to flatten(T)
return exp; is an error if exp has static type S and flatten(T) does not void contain flatten(S)

WDYT?

I'd still prefer not to return anything from a void function, but we have to accept existing code which returns void expressions. Generalizing that, I want it to be allowed to return any type which is part of (when unfolding the union type) the return type (but not a subtype if it's only because of a subtype relation to void).
So a return type of FutureOr<FutureOr<void>> should allow any of:

void
Future<void>
FutureOr<void>
Future<Future<void>>
Future<FutureOr<void>>
FutureOr<Future<void>>
FutureOr<FutureOr<void>>

and nothing else.
That exactly matches your "/contains/" relation, it's  {S | FutureOr<FutureOr<void>> /contains/ S}, so I think it is a good combination of a recursive "contains" and "matches".
That allows you to return the result of a function with the same return type (or any part of a union-return type) directly, even if it contains void, but nothing else.
I think the /void contains/ rule must be written as:

T /void contains/ S if T /contains/ void implies T /contains/ S.
Otherwise T = FutureOr<int> and S = int would be an error because T does not /void-contain/ S.
If we do that, then I think it does indeed work exactly like what I specified. I'm not sure /void contains/ carries its own weight, though, so maybe just say:

return exp; is an error if exp has static type S, and T /contains/ void and not T /contains/ S.

(which is more readable than a negated implication, but then, almost anything is)

SGTM.

So, summary:
Define: T contains S:

true if T is S,
true if T is FutureOr<X> and X contains flatten(S), and
false otherwise.

(Effectively this means that the unfolding of the FutureOr union types of T contains exactly S).
The rules for a synchronous non-generator function with declared return type T are:

return; is an error unless T contains void.
return exp; is an error if exp has static type S and S is not assignable to T.
return exp; is an error if exp has static type S, T contains void and not T contains S.

The rules for an asynchronous non-generator function with declared return type T are:

return; is an error unless flatten(T) contains void.
return exp; is an error if exp has static type S and flatten(S) is not assignable to flatten(T).
return exp; is an error if exp has static type S, flatten(T) contains void and not flatten(T) contains flatten(S).

This LGTM, except that we need to say:

return; is an error unless T contains void or T is dynamic.

and similarly for the async case.

I've fleshed this out with some more details here:  https://dart-review.googlesource.com/c/sdk/+/52742 .
I'm running presubmits now.  I see some new errors that are good, but there's one class that I have a bit of a hard time justifying.  Specifically, consider:
Future<int> firstThing() {...}
Future<int> nextThing() {...}
Future<void> waitForSomethings() async {
    var a = await firstThing();
    // Do stuff
    return nextThing();
}

This is now an error.  Looking at the examples of this that I see in code, it doesn't look to me like bad code.  Futures encapsulate two things: control, and data.  It doesn't make much sense to say void a = 3, but it seems much more reasonable to say Future<void> a = returnsFutureBool().  The former is pointless, but the latter preserves the control aspect of the Future while discarding the data.
Do we really care to make this an error?

it seems much more reasonable to say Future<void> a = returnsFutureBool().

Yeah, that seems reasonable to me for exactly the reason you state. "I don't care what this returns, but I do care when it returns."
If you go on to await or call .then() on that future and attempt to use the result, you'll get an error at that point. So I don't think we lose any real safety by not showing the error earlier when assigning the Future<...> to Future<void>.

If we're considering return statements in async functions to be concerned with completion of the returned future then we're out of "returned value" land and back in "calling a method" land:
Future<void> f() {
  // The following really means `myCompleter.complete(3)`, passing `3`
  // to a parameter of type `void`.
  return 3; // OK because we always allow passing arguments to such a parameter.

  // The following really means
  // `let v = await Future<int>.value(3) in myCompleter.complete(v)`
  // so we are again just passing an argument (of type `int`) to a parameter
  // of type `void`.
  return Future<int>.value(3); // OK, same as above
}

Using that perspective we would never complain about values being discarded, presumably unintentionally, because they are "returned to void". That's simply not an issue for return in an async function.
Another thing is that we could have void f() async {...} where the returned future is marked as "should be discarded", but we have explicitly chosen to consider that as an acceptable setup (it's a "fire-and-forget" operation). So that's the real violation that we could have with an async function, but we have settled that as ok already.
If we do this then will never complain about unintentionally-forgotten values with return-from-async, and that may or may not be unacceptable.
But I think it would be a really confusing situation if we start mixing the two perspectives (1: return e makes e a returned expression also in an async function, or 2: return e in an async function is concerned with a method call passing e or await e as an actual argument).

The specification of async functions does not mention completers, and I'd prefer to look at async functions as if they return a value of the correct flattened type, which is then used to complete the actually returned Future ... somehow.
That is the body of Future<int> foo() async { should be treated (mostly) like a function returning int. Allowing Future<int> in the return expression is just backwards compatibility (I'd not add it today if we didn't already have it), but it just works as if each return e; has an implicit await inserted.
So it's 3: return e in an async function is actually return await e;. It is a return at the base type, not the future type.

I've created this CL, which is aimed at handling funny combinations like "return type Future<int>, got a Future<Object>" and MyFuture<C> above) in a meaningful manner.

I abandoned said CL: We will suspend that topic for now, leaving implementations as well as specification unchanged.

Agreed on spec has landed.


[Feature Request:] Add option to switch to finetuned openvino models

Such as this: https://huggingface.co/ShadowPower/waifu-diffusion.openvino/tree/main
This is the anime finetuned model.
A Pokemon finedtuned model came out today, and I'm guessing more people will want to port these finetuned models to openvino.
The exact file(s) to move is unclear. If a feature to switch the models with parameters is too difficult, a readme guide for how to switch out model files would be great.

Good idea.
Just add a boolean command line parameter like:
    parser.add_argument('--local', default=False, action='store_true', help='Optional. Enable use of locally available network files instead of downloading via huggingface_hub.')

And check the boolean flag to either use a local (hard-coded) path or download via huggingface_hub:
    self._text_encoder = self.core.read_model(
        "local/text_encoder.xml" if local else hf_hub_download(repo_id=model, filename="text_encoder.xml"),
        "local/text_encoder.bin" if local else hf_hub_download(repo_id=model, filename="text_encoder.bin")
    )

Then call it like this:
    python demo.py --prompt "Street-art painting of Emilia Clarke in style of Banksy, photorealism" --local

And you will get Waifu-Diffusion like this:

demo.py already has a parameter to specify alternative models.
You can use the waifudiffusion model with the current codebase like this:
python demo.py --model "ShadowPower/waifu-diffusion.openvino" --prompt "Street-art painting of Emilia Clarke in style of Banksy, photorealism"

demo.py already has a parameter to specify alternative models.
You can use the waifudiffusion model with the current codebase like this:
python demo.py --model "ShadowPower/waifu-diffusion.openvino" --prompt "Street-art painting of Emilia Clarke in style of Banksy, photorealism"

... but only if the model is known and reachable by huggingface-hub...

Does anyone know how to convert models to IR format? The openVINO docs say you need a .pb or .pbtxt file, but I can only find the .ckpt files.

@Drake53 you're awesome, nice fork!
Have you found that information out yet?
So, docs say convert from bin/pt/pth (the naming convention should mean the same) to onnx
I assume bin/pt/pth models are the ones in the unet folder on huggingface.
I assume most people are really stuck as there is no public repo visible to convert onnx to IR format.
You may need to ask @ShadowPower so we can replicate what he did. https://github.com/ShadowPower


Nice to have: armv7l-linux binary GHC in 9.2 or 9.4 series

After #193037, we no longer have a 9.2.* bindist for armv7l-linux. This lengthens the bootstrap chain for ghcHEAD on that platform to ghc8107BinaryMinimal -> ghc924 -> ghcHEAD. This is not too bad, since ghcHEAD is mostly maintained as a testing ground for the upcoming, hadrian-based GHC 9.6. It would be nice to sort it out until that release comes out, though.
There are three options:

Ideally, GHC HQ fixes their armv7l-linux CI runners and publishes a armv7l-linux bindist for a new release in the 9.2 or 9.4 series (9.6 would not really help, since thanks to hadrian self-bootstrapping has become less viable).
We restore ghc922BinaryMinimal and drop all platform support except armv7l-linux, using 9.2.4 to bootstrap in general, but 9.2.2 for armv7l. I'd accept such a PR today.
We look elsewhere for bindists. @amjoseph-nixpkgs looked into reusing Debian's GHC packages as bootstrap seeds for GHC, but to no avail so far. One hope I have is that hadrian requires to build a bindist as an intermediate build artifact (which causes us much annoyance in the GHC derivation) which is installable anywhere in theory. Maybe other distributions with wider official platform support can be bothered to publish these bindist artifacts which would be easier for us to reuse.

3. @amjoseph-nixpkgs looked into reusing Debian's GHC packages as bootstrap seeds for GHC, but to no avail so far.

The main obstacle I hit is the fact that GHC writes absolute pathnames into its installed image in a very large number of places.  After patching all of the pathnames I could find, and running patchelf, I hit extremely cryptic glibc link errors involving GLIBC_PRIVATE which led me to believe that I'd either missed some pathnames or done something wrong with patchelf.
It's not impossible; it's just less attractive than a longer bootstrap chain.
Hydra has machines which canExecute armv7l-linux, so uploading a blessed ghc924 built by Hydra to tarballs.nixos.org might be a better solution.  This is basically the same thing as patchelfing Debian packages, except that we aren't outsourcing the build to Debian (could be viewed as a positive thing).
It's a bigger issue on platforms which none of Hydra's machines canExecute.

Also, how far did previous efforts at building ghc with hostPlatform!=buildPlatform get?
Unless there's some sort of enormous obstacle there, I think that's the most attractive long term solution.  Then we could treat ghc the way we treat gcc in the bootstrap-files tarball -- cross-compile the seed compiler from whatever platforms Hydra supports.
IMHO in the long run this is the only sustainable strategy for nixpkgs to deal with compilers that are written in their own language.

Also, how far did previous efforts at building ghc with hostPlatform!=buildPlatform get?

I agree with you that this is probably the best option for the long term – we should probably open an issue for implementing this. It definitely used to be possible, but:

It regressed in hadrian, see ghc#22006 (ignore my initial misconception about the GHC build system in that thread).
The way it works is quite ugly: You need to configure GHC the same as you would the GHC cross compiler targeting the host platform, i.e. you need to pass --host=${stdenv.buildPlatform.config}, --target=${stdenv.hostPlatform.config} (cross compiling a cross compiler is not possible at all!). The difference to the build->host cross compiler is then that you build until GHC Stage 2 instead of Stage 1, i.e. let the cross compiler rebuild GHC one more time – which will of course only be executable on the platform it targets.
There would be a correctness issue for building a cross-compiled GHC: In an effort to shrink the shell wrapper for GHC (which isn't gone yet sadly) and to prevent the wrong tools from being used by accident I've started passing more and more absolute paths to GHCs configure step. The problem is that GHC's build system only really distinguishes between tools for build and tools for target (this is also a reason why you can't build a GHC with three different platforms) – this means practically that the build->target tools will leak into the final GHC, so building a GHC hinges on the invariant that build->target == host->target (in fact we have an assert for this). To cross compile GHC we'll need to work around this issue by modifying the ghc.settings file after the build process – this is hopefully the only place where these references exist.

Overall I think it's worth undertaking this, but it's a big job. Also GHC upstream doesn't test this (to my knowledge) and the whole thing feels a bit like an accidental possiblity. Getting this to work for hadrian would be great, since we'll be able to carry that forward, but realistically we'd also need it for make since hadrian seems to buggy on older GHC versions (which we'd need for bootstrapping) to switch.


require namespacing all components

I cannot use this framework with components (such as checkboxes) from a different library because the material styles override them. Because the styles are applied in a general manner to all checkboxes, I need to tediously override each and every style. If these styles were applied based on a classname such as 'mcs-checkbox', this would not be an issue.
Every other modern css framework namespaces its styles to avoid these types of collisions, and materialize should as well.

That would be a huge refactor and probably will not be a 1.x release.

@rhaines-chewy
Easy solution in the meantime is simply to not import the sass components that you don't want to use. You should be doing this anyway to reduce the size of your css file.
I personally don't agree with namespacing, for a couple of reasons:
Firstly, I want simple semantic markup. I stopped using Bootstrap because of the ridiculous classnames. I want shorter classnames - and none at all if possible!
Secondly, I don't think it's ideal to be mixing and matching components from different frameworks unless completely necessary.

+1 (or better +many ;-)) for this request.  I see it a huge problem that Materialize styles (CSS) and/or touches (JS) all DOM elements of a certain type, e.g. input[type=text] or, even worse, body,  I want to consider a library like Materialize as a set of components and styling methods I can use/apply at places I choose.

@josvos it is customizable at component level, if you take the time to look at the docs.

@pwcreative I don't see that... in forms.js for example, the first function seems to select all input[type=text] (and more) elements

@josvos the vast majority of users will want to target all form elements in this way. If you absolutely must have control over this, then you've found where you need to make your amends.

@pwcreative referring to a "vast majority of users" that do not need something is in general not a good argument for not improving a product.  I have to admit I also do not understand your problem with a specific namespace to explicitly mark elements as being subject to Materialize: this is IMHO cleaner and more elegant from a developer-perspective.
BTW, my ultimate goal (see also my comment on another issue) is to be able to generate a set of (completely independent) web components from the Materialize sources (or add this to the project, what I would prefer).  I think this is very doable (I already did some experiments), but the "global nature" of the code (CSS/JS applies to everything) was the first obstacle I came across.

@josvos I think your end-goal is perhaps part of the longer timeframe, just from looking at commits and comments etc, but conversely it could be argued that you needing something is not necessarily a good argument for making massive breaking changes ;)
And I already explained I prefer less classnames, not more, and personally have no need for them. I find the components fairly easy to manipulate should I not require the standard behaviour or styling.
I hope you get to where you need to be bro :)


Importing draftjs breaks server side rendering

Do you want to request a feature or report a bug?
Report a bug
What is the current behavior?
By importing draftjs utils
import { convertToRaw, Editor, EditorState, RichUtils } from 'draft-js';
Our app breaks. According to Next.js, the likely solution is to require() in componentDidMount.
DraftJS non-rendered data/logic and objects shouldn't require the DOM to exist, especially not before actually utilizing the functions (which I tried in componentDidMount). The problem is that importing draft-js requires the DOM, and I don't think it should. That logic should be part of <Editor/> componentWillMount/componentDidMount rather than a global script polluting the import process
Cannot read property 'indexOf' of undefined
TypeError: Cannot read property 'indexOf' of undefined
    at Object.<anonymous> (/lawyer-portal/node_modules/draft-js/node_modules/fbjs/lib/getDocumentScrollElement.js:11:72)
    at Module._compile (module.js:653:30)
    at Object.Module._extensions..js (module.js:664:10)
    at Module.load (module.js:566:32)
    at tryModuleLoad (module.js:506:12)
    at Function.Module._load (module.js:498:3)
    at Module.require (module.js:597:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/lawyer-portal/node_modules/draft-js/node_modules/fbjs/lib/getScrollPosition.js:11:32)
    at Module._compile (module.js:653:30)
    at Object.Module._extensions..js (module.js:664:10)
    at Module.load (module.js:566:32)
    at tryModuleLoad (module.js:506:12)
    at Function.Module._load (module.js:498:3)
    at Module.require (module.js:597:17)
    at require (internal/module.js:11:18)

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. You can use this jsfiddle to get started: https://jsfiddle.net/stopachka/m6z0xn4r/.
I don't have time for this right now
What is the expected behavior?
Importing draftJS utils shouldn't break SSR by accessing non-existant properties in a headless browser context.
Which versions of Draft.js, and which browser / OS are affected by this issue? Did this work in previous versions of Draft.js?
Next.js 8.0.3
DraftJS 0.0.11 and 0.0.10

Hack solution / workaround reinforces that import is the problem
This works, but with a large delay
  constructor(props) {
    super(props);
    this.state = {
      editorState: null,
    };
  }

  componentDidMount() {
    draftConvert = require('draft-convert');
    draftJs = require('draft-js');
    convertFromHTML = draftConvert.convertFromHTML;
    convertToRaw = draftJs.convertToRaw;
    Editor = draftJs.Editor;
    EditorState = draftJs.EditorState;
    RichUtils = draftJs.RichUtils;
    this.setState({
      editorState: this.newEditorState(this.props.initialValue),
    });
  }

Hack solution / workaround reinforces that import is the problem
This works, but with a large delay
  constructor(props) {
    super(props);
    this.state = {
      editorState: null,
    };
  }

  componentDidMount() {
    draftConvert = require('draft-convert');
    draftJs = require('draft-js');
    convertFromHTML = draftConvert.convertFromHTML;
    convertToRaw = draftJs.convertToRaw;
    Editor = draftJs.Editor;
    EditorState = draftJs.EditorState;
    RichUtils = draftJs.RichUtils;
    this.setState({
      editorState: this.newEditorState(this.props.initialValue),
    });
  }

FWIW in our project we are using SSR with draft-js and it works OK, no DOM emulation layer required.  We're running it in node, though, not a headless browser context (whatever that is).
There must be something else about your setup that is triggering this issue.

I'm not sure about the specifics, but we're using Next.js, which uses node, express, and webpack  and invokes top-level component lifecycle method "getInitialProps". Node is a headless context, and global is the keyword replacement for window which has document.
The most important evidence:

the stack trace /node_modules/draft-js/node_modules/fbjs/lib/getDocumentScrollElement.js
the fact that importing after didMount solves any issues


[improvement][broker]Add replicate all subscription state switch on the broker side.

Fixes #xyz
https://github.com/apache/pulsar/issues/23768

Main Issue: #xyz
https://github.com/apache/pulsar/issues/23768

PIP: #xyz

Motivation
In the current version of Pulsar, when performing cluster data synchronization, in order to continue consuming the consumption message location recorded in the source cluster after switching from the source cluster to the target cluster, it is necessary to configure the parameter repliceSubscriptionState=true on the client side to replicate the subscribed consumption location information.
There may be some issues with this, such as when my cluster needs to be migrated, if there are dozens of business teams involved in this cluster, then I need to align the migration action with all business teams to ensure that everyone switches and changes at the same pace.
However, this difficulty is very high, as there are complex upstream and downstream dependencies in the data flow between different businesses. At the same time, the business needs to modify the code online in order to replicate the subscription status, which makes our migration efficiency heavily dependent on the business.
For this scenario, we expect to have a global control switch for subscription state replication on the server, which can be enabled to replicate all subscription state information in the cluster without the need for business code modification.

Modifications
Add a switch on the broker side to replicate all subscription states from the source cluster to the target cluster.

Verifying this change

[ ] Make sure that the change passes the CI checks.

(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (10MB)
Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

[ ] Dependencies (add or upgrade a dependency)
[ ] The public API
[ ] The schema
[ ] The default values of configurations
[ ] The threading model
[ ] The binary protocol
[ ] The REST endpoints
[ ] The admin CLI options
[ ] The metrics
[ ] Anything that affects deployment

Documentation

[ ] doc
[x] doc-required
[ ] doc-not-needed
[ ] doc-complete

Matching PR in forked repository
PR in forked repository:
https://github.com/yyj8/pulsar/pull/11

@yyj8 The feature added in this PR would need to be covered with a PIP. There's also #23770 which has been proposed just now. Could you work with together with @nodece so that we could combine both features in the same PIP since they are so closely related. That might also impact the design and implementation. /cc @nodece

@lhotari Good idea, I suggest we should add this feature to the #23770, I also required this feature.

This PR introduces an override for the replicateSubscriptionState configuration from the consumer level, which is currently correct for the version being worked on. However, this conflicts slightly with PIP #23770, which proposes a configuration at the namespace and topic levels to control subscription replication. The issue arises because PR #23770 assumes that the consumer-level configuration for replicateSubscriptionState is not set, and instead, replication behavior is driven by namespace and topic policies.
To avoid this conflict and align with PIP #23770,  I propose modifying this PR to ignore the replicateSubscriptionState configuration from the consumer level. This would ensure that subscription replication is controlled exclusively by the namespace and topic policies.
If you can set the subscription replication in the namespace or topic level, I belive this should be correct.


Home page > What information do we ask for

A page explaining what information we ask consultation participants, AC's, and CC's for.
This will be dependent on Delphi round 1 results.

AC: https://www.figma.com/file/AXufBnFAVHvGdsxnQMVhNF/The-Accessibility-Exchange-Wireframes?node-id=2260%3A72097
CC: https://www.figma.com/file/AXufBnFAVHvGdsxnQMVhNF/The-Accessibility-Exchange-Wireframes?node-id=2260%3A74628
Participants to come after Delphi results confirmed.


ABOUT ROUTES

hi i have intalled version 5 in laravel 5.8 but. I have problem with api routes otherwise web routes are working fine. please help me how can solve that.
Thanks

Hi,
You need to find out if your routes are loaded, for example in your route service provider.

where do i need to load my routes in module service provider or my main laravel service provider, getting confused with them, please help my out. Thanks

Thanks @nWidart routes problem is now solved. I have loaded routes in main laravel routes service provider instead of module's routes service provider.


Quests like in Go map or StreetComplete

Are there plans to add a "quests" mapping mode like in Go map or StreetComplete? I think this feature is one of the main reasons people are using these apps..
A few examples for quests:

Add opening times for businesses
Add surface types
Add street names for streets with no name

Maybe similar to #119

Frankly, I'd keep projects separate. Every Door is for quick mapping of everything. Having quests would slow a user down. SC is indeed popular because quests make editing accessible and fun. But this editor is more like JOSM: no hand-holding, steeper learning curve, but nothing can stop you once you get going.


Bug fix

Multiple fixes:

In the previous version, the code doesn't register a new home & we only recompute data if there are changes in signs
Correction of crashes in prod

Refactor:

Remove useless code

Feature:

Add a new config if we remove a house

I saw that I did a mistake, the code will detect what I want but it will not save the config in the database. I will correct it


RuntimeError: Invalid settings file [settings]

While running song_recognizer initialise, I got an error : Invalid settings file [settings]
Also, hash.db is not create automatically.

What was the solution?

What was the solution?

You have to append a system path like this.
sys.path.append('/home/os_202000828/Desktop/abracadabra/abracadabra')
More information, you can see this blog. If you want to ask about this please comment this issue or email to me<EMAIL_ADDRESS>

which blog?

Sorry to my mistake.
문제해결 | 샤잠(shazam) 노래인식을 구현한 abracadabra 사용하기 - https://splendidlolli.tistory.com/m/597
This blog written by Korean. If you want to translate to English, Use Translation.
You have to know that our problem is the missing path about module.

That issue is fixed, but when ever im trying to create an api using this package its not starting the server do you have any idea about this ?

when i used this api in the past, i couldn't catch any issue you said.
If you have an message about error, show me full message about that.


Templates do not update

Describe the bug
Cannot Update Templates. Tried to modify the event detail template but updates are not saved.
To Reproduce
Steps to reproduce the behavior:

Go to templates
make change
save changes
see no effect

Expected behavior
updated template
Screenshots
If applicable, add screenshots to help explain your problem.
Error log
Note: Debug DLL's
Please replace the current extension DLL's with the debug DLL's (if these are available with the release) and reproduce the error with the debug DLL's before pasting the error log.
Paste the error log that is related to this issue.
Additional context
Add any other context about the problem here.

This is solved in the upcoming release 7.0.3
See also issue #137 and PR #135


Adding requirements and readme as a data file

Package building in conda will fail because it will not find requirements.txt
Similar to deepface, we should add readme and requirements as a data file in the setup.py
https://github.com/serengil/deepface/blob/master/setup.py#L15

Closed with PR - https://github.com/serengil/retinaface/pull/78


In ci-build.yaml and codeql.yaml, there is no copyright note

The copyright note in ci-build.yaml and codeql.yaml needs to be updated.

@sanfern, the issue has been successfully resolved. Therefore, we can close this issue now.


DragListener's transform should accept Properties

We have MVT Properties all over, this should help keep code clean.

Implemented above, closing.


Feature request: Ability to update node firmware from provided Url

I'm looking into the firmware upgrade functionality that was recently added and it looks like it's only possible to update the firmware through the DCL.
It would be nice to have the ability to download the firmware from a provided Url directly for testing.

We actually have this already but we didnt yet have time to document it. Stay tuned as it will follow soon

Great! I was just looking at the API-commands in the source code and couldn't see how one could trigger the update from a provided Url. Can  you give me a hint until the docs gets there?

Great! I was just looking at the API-commands in the source code and couldn't see how one could trigger the update from a provided Url. Can you give me a hint until the docs gets there?

Not yet as we need to finish it. Currently the path to store manual update json files is hardcoded.
Ensure that the path /root/updates exists and place the json files in there. Here is one example of such a file.
65521-32769-2-OTA-Requestor-Example-App.json

Wouldn't it be better to put the updates directory under the data directory by default?

I see that this was released now:
https://github.com/home-assistant-libs/python-matter-server/pull/884
Where can I find any docs on how to use this new feature?

I see that this was released now:
#884
Where can I find any docs on how to use this new feature?

I would also be interested in details on how to use the local OTA feature.
A dedicated explanation for the usage in combination with Homeassistant OS (where the Matter Python Server runs in a Docker instance) would be an awesome addition.
@agners, since you implemented the feature. Could you please help providing a short "how to"?

@fish12345 you need to have the json file in place when the Matter Server starts (the json files are only parsed on startup). You may need to use --ota-provider-dir to provide a custom directory which you bind mount into the container.

@agners Do you have a sample json file with the correct file::// syntax for the update directory with the corresponding --ota-provider-dir syntax?

Thanks @agners, the information that the json files are only parsed on startup was the key for me.
I copied the json file to /root/addon_configs/core_matter_server/updates/ on my Homeassistant. Turns out they already expose the ota path. After that, I started the Matter server addon.
Now the update can be started.
@olavt, I also tried to copy the firmware image next to the .json file and use "otaUrl": "file:///my_file.ota" in the .json file.
It seems to work, but transmission is still ongoing, so I don't know for sure yet.

@agners Maybe there should be an API to be able to create the json information without having to upload it to the filesystem and without having to re-start the Python Matter Server?

@agners Maybe there should be an API to be able to create the json information without having to upload it to the filesystem and without having to re-start the Python Matter Server?

That is out of scope for now. Feel free to PR that if you like.


checkboxes do not react to user input

Some checkboxes do not react to user input at all.
These
parser.add_argument("--tt",   default=True, action="store_true",    help="tt")
parser.add_argument("--ff",  default=False, action="store_false",   help="ff")

are broken.
Run this gist:  https://gist.github.com/drandreaskrueger/b66a7c4dde5bcd58e919
and you'll see.
There is no difference between run 1 and run 2 for those checkboxes.
Or is it me, and I haven't understood it yet? Then please explain, thanks a lot!

+:100: for providing a gist of your issue!
Gooey is behaving correctly (for once!).
Firstly, I modified your gist to remove Gooey and use plain old argparse. You can check it out here: https://gist.github.com/chriskiehl/dd64741019aa270a4b39. That takes Gooey out the equation so we can just mess around with the raw CLI args.
So, Let's step through this.
You set up an argument where the default is True. That means that if no command line argument is supplied, then tt will receive a value of True.
parser.add_argument("--tt",   default=True, action="store_true",    help="tt")

And if we run your program with no arguments, we'll see that it indeed defaults to True
$ python drandreaskrueger_example.py
--truefalse True
--falsetrue False
--truetrue True
--falsefalse False

Now, the look at the second part of the argument, the action param:
parser.add_argument("--tt",   default=True, action="store_true",    help="tt")

That is set to store_true, which, means, if it receives a command line argument, that it will set the value of tt to True.
Now we run your program and give it the -tt flag
$ python drandreaskrueger_example.py -tt
--truefalse True
--falsetrue False
--truetrue True
--falsefalse False

And.. we get the exact same output. The same thing would happen with your -ff example as well. You've structured them such that the absence of a CLI argument produces the same thing as the presence of a CLI argument.
So that's why it looks like the check boxes aren't working. They are working (behind the scenes Gooey just feeds the --tt and --ff arguments to your program), it just looks like they're not, because regardless of the program input, they ultimately end up in the same state.

Chris, wow. Thanks a million for this examination, and perfect presentation.   Great!

it just looks like they're not, because regardless of the program input, they ultimately end up in the same state.

Hmmm ...
Then perhaps it might make sense to issue some warning to never combine
default=True,  action="store_true"

or
default=False, action="store_false"

because in those cases the checkbox user input (nor the argparse.ArgumentParser CLI input if I understand you correctly) is not getting passed on to the program?
Admittedly, it was my first day with Gooey, and I had never used argparse.ArgumentParser before, so I faced a bit of a learning curve there. But that checkboxes input does not result in any variable change did confuse me a bit. Very happy that you clarified this for me. Very.
I suggest you include that topic into your manual.
Taking breaks from coding I should :-)
After I had typed the whole thing, and had come up with that foobar way of presenting it, and tested and debugged the script, and created the example gist, and had it all uploaded, and the computer switched off ... I realized that I only need 2, not 4 options anyways.
solutions:
default=True
If I need a default=True checkbox, I will use the
default=True,  action="store_false"

checkbox, and negate the args parser answer.
default=False
If I need a default=False checkbox, I will use the
default=False,  action="store_true"

checkbox, and take the args parser answer as the answer.
Correct?

Now I am almost there.
I have just had the idea how to automate that negation in case of default=True.
My (real app's) code looks like this now:
parser = ArgumentParser(description="Still learning argparse and gooey.")

parser.add_argument("--errors", default=False, action="store_true" , help="Show each file access error.")
parser.add_argument("--omit",   default=True,  action="store_false", help="Omit empty days in printout.")

args = parser.parse_args()

print "These are the arg parser results:"
for p in ("errors", "omit"): print "%s : %s" % (p, args.__getattribute__(p))

print "Now solve the correct conversion True <-> False:"
for p, negate in (("errors", False),
                  ("omit",   True)):
    value = args.__getattribute__(p)
    value = not value if negate else value
    print "%s : %s" % (p, value)

Please help: What is the way to read out the settings from parser?
The idea is that instead of repeating the default-choice via (("errors", False), ("omit",   True)), I could read out the parser.argument["errors"].default, and parser.argument["omit"].default - and depending on those choices I could negate, or not.
But I don't understand how ArgumentParser is internally storing the .add_argument attributes. You do - that's how you built Gooey, right?
Thanks!


Icons Not loading in feedback page

Can you assign me this issue?

I hope this message finds you well. I would like to formally request to be assigned to the issue regarding the implementation of a "No products found" message for filtered product results.
@rajuljha

@codervivek5 gssoc-ext label is missing


Does not work with queryBuilder and selectRaw

Summary of problem or feature request
Using queryBuilder->selectRaw and then passing the queryBuilder to DataTables throws an exception of Illegal offset type in isset or empty, because $column is a laravel class (Expression) instead of a string.
Code snippet of problem
$queryBuilder = DB::table("table");
$columns = [
    "IFNULL(table.id, joined_table.id) AS id",
    "IFNULL(table.vendor, joined_table.vendor) as vendor"
];
$queryBuilder->selectRaw(implode(",", $columns));
$queryBuilder->rightJoin("joined_table", function(JoinClause $join) {
    $join->on("joined_table.vendor", '=', "table.vendor");
    $join->on("joined_table.id", '=', "table.id");
});
Datatables::queryBuilder($query)->make(false);

This returns the following JSON:
{
"draw":4,
"recordsTotal":355,
"recordsFiltered":0,
"data":[],
"error":"Exception Message:\n\nIllegal offset type in isset or empty"
}

due to the code on this line for datatables 8.x and this line for datatables 7.x.
get_class($column) == 'Expression' while DataTables expect a string
System details

Operating System: Ubuntu 16.04 (homestead)
PHP Version: PHP 7.1
Laravel Version: 5.4
Laravel-Datatables Version: 7.10.1 / 8.1.0

Thanks for the hints. If you can, please do not hesitate to submit a PR for a fix.


A proposal to solve 10 direct ancestor limit

The code below resolves the swift 10 direct ancestor limitation. If you think it is a good option you could introduce it in the example.
import SwiftUI
import SwiftUIRouter

struct RouterModel: Identifiable {
    var id = UUID()
    var path: String
    var view: AnyView
}

struct Routes: View {

    let routes:[RouterModel] = [
        RouterModel(path: "/page1", view: AnyView(Page1View())),
        RouterModel(path: "/page2", view: AnyView(Page2View())),
        RouterModel(path: "/page3", view: AnyView(Page3View())),
    ];

    var body: some View {
        Router {
            VStack {
                ContentView(routes: self.routes)
            }
        }
    }
}

private func ContentView(routes: [RouterModel]) -> some View {
    Switch {
        ForEach(routes) { route in
            Route(path: route.path, exact: true) { _ in
                AnyView(route.view)
            }
        }

        // Main view
        Route {
            MainPageView()
        }
    }
}

Thanks for the example! There are multiple ways to solve the 10 direct ancestor limit. The ForEach loop is a great method when working with dynamic (remote) data. Another option is one I described in a previous issue.
The Readme and example project could probably do with some examples that solve the issue. No doubt about that.


Updating the kernel installation script as per new package name

MIOpen kernels package name update PR - https://github.com/ROCmSoftwarePlatform/MIOpenKernels/pull/10

@pruthvistony Please describe why this is needed, what changes are made, and the priority level. Thanks!

@pruthvistony Please describe why this is needed, what changes are made, and the priority level. Thanks!

Apologies, missed to give the explanation.
Currently the MIOpen kernel package names ends with numbers(the package name seen the header of the package), this is not desirable and causes confusion for multi version ROCm installation. So the change is done to append "pkg" to the package name.

@daniellowell,
Can you please help on getting this code merged.


Use without Gatsby

Hi all! I’m coming here as the maintainer of remark et al, and would like to see a standalone project, for example so that it can be used directly with remark, but also for example with Next or MDSveX.
It seems like there’s only a small layer of Gatsby-specific code here?
For the remark part, there are certain Gatsby-esque things in this project, such as using raw HTML strings: https://github.com/raae/gatsby-remark-oembed/blob/fbca804afd3b1235521db742bb36325c8365ae79/gatsby-remark-oembed/utils/tranformsLinkNodeToOembedNode.js
That works fine if you’re indeed going to make HTML, and Gatsby (and MDX@1) are doing some magic there, but with MDX@2 we’re going remove it in favor of an AST: hast (rehype) (which the other stuff made on remark already supports).
Is this of interest?

Hello,
Yes I would love to that. The plan is to get the oEmbed code into its own module, then a remark module and then use those as the foundation for plugins for different frameworks (Next, Gatsby, Eleventy, etc).
I will take closer look at AST and make sure we comply when we get to this work. Would love to get some review of the code when we get there, or contributions. I have limited time available the next months, but hoping to get more people evolved as soon as I manage to outline the path forward so people feel more comfortable contributing.

Totally accidental closing of this issue...

Am I correct in thinking that it would be better if the node got replaces with something different than the html type.
So if its an iframe, make the type: element and the tagName: iframe etc. So that hast-util-embedded would return true?

Correct!
The typical flow is:

parse a document into mdast
do things on mdast nodes
turn mdast into hast
do things on hast nodes
turn the hast into whatever: serialized javascript (MDX), React nodes (react-markdown / rehype-react), Vue/Svelte etc, or serialized HTML (rehype-stringify)

In unified, these steps are up to users (see for example this codesandbox). In MDX, Gatsby, and react-markdown, these are done by those projects.
Markdown nodes can be cleanly mapped to HTML nodes, but we can’t easily map strings of HTML to HTML, because:

now you need an HTML parser, which is heavy and complex
HTML in markdown doesn’t have to make sense: it could be XML or completely broken
Strings of HTML don’t make sense to MDX, because it deals with JSX

The alternative I like best, and is supported by all these tools (including Gatsby for years), is to define how something should turn into hast (html nodes) on mdast (markdown nodes). Here is a little example where the mdast nodes are texts, but it should turn into a span with some certain properties in hast: https://codesandbox.io/s/remark-rehype-debug-forked-zs711?file=/src/index.js:874-1169.
Note though: as you’re getting strings of oembed HTML from server, those need to be parsed somewhere. I like using parse5, and then there’s an adapter to turn it into hast: hast-util-from-parse5
A different thing, gatsby-remark-oembed isn’t really about markdown, it’s more about HTML, so using it as a rehype plugin would make more sense in unified/mdx/mdsvex/next (although I don‘t think gatsby-transformer-remark supports it)

Thank you for all this info! Will try to test some of this out :D

Cool Benedicte! Let me know if I can be of help!

Looking at this first quarter of 2021 I see I do not have much time. Will hopefully start splitting the projects up into reusable components. But this work will be postponed until April.

Looking at this first quarter of 2021 I see I do not have much time. Will hopefully start splitting the projects up into reusable components. But this work will be postponed until April.


Improve Elasticsearch Interface

The interface for taking PDFs and uploading them through tika to elasticsearch works but is ugly. Needs work.

The interface has been enhanced with the "index space" feature. see #468


Caching partitions metadata in memory.

This CR adds LRU cache support for the partitions metadata for the
versioned and volatile layers.
The user is able to set for each partition request param: "online-only" and "online if not found in cache".
By default for each request uses mode "online if not found in cache".
This mode decreases the count of requests to the services.
Disabling some tests. The tests will be enabled on the next CRs.
Resolves: OLPEDGE-1667
Signed-off-by: Oleksii Zubko<EMAIL_ADDRESS>

Codecov Report

Merging #287 into master will decrease coverage by 2.7%.
The diff coverage is 48.2%.

@@           Coverage Diff            @@
##           master    #287     +/-   ##
========================================
- Coverage    89.5%   86.9%   -2.7%
========================================
  Files          59      61      +2
  Lines        1757    1835     +78
  Branches      218     236     +18
========================================
+ Hits         1573    1594     +21
- Misses        102     144     +42
- Partials       82      97     +15

Impacted Files
Coverage Δ

...dataservice-read/lib/client/VolatileLayerClient.ts
76.1% <9.1%> (-20.7%)
:arrow_down:

...ataservice-read/lib/client/VersionedLayerClient.ts
77.8% <16.7%> (-15.4%)
:arrow_down:

...aservice-read/lib/cache/MetadataCacheRepository.ts
50.0% <50.0%> (ø)

...k-dataservice-read/lib/client/PartitionsRequest.ts
89.5% <60.0%> (-10.5%)
:arrow_down:

...olp-sdk-dataservice-read/lib/client/QueryClient.ts
77.8% <62.5%> (-9.4%)
:arrow_down:

...lp-sdk-dataservice-read/lib/cache/KeyValueCache.ts
88.9% <83.3%> (-11.1%)
:arrow_down:

@here/olp-sdk-dataservice-read/lib/cache/index.ts
100.0% <100.0%> (ø)

...lp-sdk-dataservice-read/lib/client/FetchOptions.ts
100.0% <100.0%> (ø)

...k-dataservice-read/lib/cache/ApiCacheRepository.ts
87.5% <0.0%> (-12.5%)
:arrow_down:

... and 5 more

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 50f86b1...364fd50. Read the comment docs.


fix: compress subtree can no longer be attacked

There was a small attack possible as length could be bigger than 255 causing a commutativity between a very big path and a small path to result in same value.

Since all lengths are same size the previous approach should also be working, this PR is less important. I'll ask research team to take a look to see what is better.


Refactor role ocm-install-core

Added CRD wait to /resolve #11
Refactored tasks to fit inventory centric model

/cc @TheRealHaoLiu @gurnben


Configuration Record does not display list of entities

Dynamics 365 Online version 1612 (<IP_ADDRESS>)
Imported the DCRMEditableGrid_1_0_6_0_managed.zip solution and attempted to create a new D CRM EG Configuration record; the "Display grid on entity" dropdown is blank, and the console indicates Failed to load resource: the server responded with a status of 500 (Internal Server Error)
Same error using Chrome or IE
//this is the xml errorcode returned from  /api/data/v8.2/dcrmeg_dcrmegtranslations?fetchXml=%253Cfetch%2520version=%271.0%27%2520output-format=%27xml-platform%27%2520mapping=%27logical%27%2520distinct=%27false%27%253E%253Centity%2520name=%27dcrmeg_dcrmegtranslation%27%253E%253Cattribute%2520name=%27dcrmeg_dcrmegtranslationid%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_name%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_lcid%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_widthisautocalculated%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_width%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_systemfields%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_selectedgridheaders%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_selectfields%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_relatedentitylookup%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_readonly%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_maxrecordsperpage%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_fieldsontheform%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_displaysumfornumericvalues%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_displayonlyrelatedrecords%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_displaygridonentity%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_displaydatafromentity%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_customfields%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_allfields%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_targetentityisrequiered%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_entitytodisplaythegridonisrequiered%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_atleasetonefieldmustbeselected%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_fieldcondition%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_fieldvalue%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_setcondition%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_configcancel%27%2520/%253E%253Cattribute%2520name=%27dcrmeg_removecondition%27%2520/%253E%253Corder%2520attribute=%27dcrmeg_name%27%2520descending=%27false%27%2520/%253E%253Cfilter%2520type=%27and%27%253E%253Ccondition%2520attribute=%27dcrmeg_lcid%27%2520operator=%27eq%27%2520value=%271033%27%2520/%253E%253C/filter%253E%253C/entity%253E%253C/fetch%253E
{
  "error":{
    "code":"","message":"Invalid XML.","innererror":{
      "message":"Invalid XML.","type":"System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]","stacktrace":"   at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.RetrieveMultiple(QueryBase query, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType, Boolean checkAdminMode)\r\n   at Microsoft.Crm.Extensibility.OData.CrmODataExecutionContext.RetrieveMultiple(QueryBase query)\r\n   at Microsoft.Crm.Extensibility.OData.CrmODataServiceDataProvider.ExecuteQueryForEntitySet(CrmODataExecutionContext context, String entitySetName, CustomQueryOptions queryOptions, String fetchXml)\r\n   at Microsoft.Crm.Extensibility.OData.CrmODataServiceDataProvider.RetrieveEdmEntityCollection(CrmODataExecutionContext context, String entityCollectionName, String castedEntityName, ODataQueryOptions queryOptions)\r\n   at Microsoft.Crm.Extensibility.OData.EntityController.GetEntitySet(String entitySetName)\r\n   at lambda_method(Closure , Object , Object[] )\r\n   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass10.<GetExecutor>b__9(Object instance, Object[] methodParameters)\r\n   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.Execute(Object instance, Object[] arguments)\r\n   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken cancellationToken)\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n   at System.Web.Http.Controllers.ApiControllerActionInvoker.<InvokeActionAsyncCore>d__0.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n   at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__2.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n   at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__1.MoveNext()"
    }
  }
}

Hi,
Thank you for reporting this issue. Please download and import the new release which contains a fix for this bug.
https://github.com/mehrgithub/dcrmeg/releases
Please let me know if the issue has been resolved.
Thank you,
Mehrdad

It works! Thanks so much.
From: Mehrdad Hatteffi<EMAIL_ADDRESS>Sent: Saturday, June 24, 2017 4:20 AM
To: mehrgithub/dcrmeg<EMAIL_ADDRESS>Cc: T Jason Mayo<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [mehrgithub/dcrmeg] Configuration Record does not display list of entities (#17)
Hi,
Thank you for reporting this issue. Please download and import the new release which contains a fix for this bug.
https://github.com/mehrgithub/dcrmeg/releases
Please let me know if the issue has been resolved.
Thank you,
Mehrdad
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/mehrgithub/dcrmeg/issues/17#issuecomment-310832799, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ALVw7x77NYWDre4JOF9ysESU9KU9YBZnks5sHPDegaJpZM4OCxjN.

Mehrdad, I’m a little confused about using the script callback functions to dynamically update fields (like calculations, etc.); is there an object model to interact with the grid and set/update values? I tried updating one of the fields {rowdata.Fields[i].Value} in the GridRowOnload event, but I didn’t see the changes in the UI. Also, would it be possible to dynamically filter the lookups? I need one filtered on a form field, and the other filtered based on the relationship to the first…I really love what you’ve done with the grid, but without that feature we won’t be able to meet our client requirements. ☹
Thanks, much appreciated!
From: Mehrdad Hatteffi<EMAIL_ADDRESS>Sent: Saturday, June 24, 2017 4:20 AM
To: mehrgithub/dcrmeg<EMAIL_ADDRESS>Cc: T Jason Mayo<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [mehrgithub/dcrmeg] Configuration Record does not display list of entities (#17)
Hi,
Thank you for reporting this issue. Please download and import the new release which contains a fix for this bug.
https://github.com/mehrgithub/dcrmeg/releases
Please let me know if the issue has been resolved.
Thank you,
Mehrdad
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/mehrgithub/dcrmeg/issues/17#issuecomment-310832799, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ALVw7x77NYWDre4JOF9ysESU9KU9YBZnks5sHPDegaJpZM4OCxjN.


autoflake/black/isort do not resolve to the same file

Suppose a file is stable under autoflake, black and isort. If an import is added and then later unused and removed via autoflake, one might presume black and isort would resolve back to the same file. This certainly introduces potentially many diffs.
Minimal example
Start with an empty directory with foo.py and no config files of any sort:
# foo.py
from package import item1, item2, item3, item4, item5, item6, item7, item8, item9

a = item1, item2, item3, item4, item5, item6, item7, item8, item9

This is stable under autoflake, black and isort:
❯ black foo.py && ruff foo.py --select=F401,I001 --fix
All done! ✨ 🍰 ✨
1 file left unchanged.

Now add an additional import to breach black's default line-length:
# foo.py
from package import item1, item2, item3, item4, item5, item6, item7, item8, item9
from package import item10

a = item1, item2, item3, item4, item5, item6, item7, item8, item9
a = item10

This is stable after two runs:
❯ black foo.py && ruff foo.py --select=F401,I001 --fix
All done! ✨ 🍰 ✨
1 file left unchanged.
Found 1 error (1 fixed, 0 remaining).

❯ black foo.py && ruff foo.py --select=F401,I001 --fix
All done! ✨ 🍰 ✨
1 file left unchanged.

with the end result being:
# foo.py
from package import (
    item1,
    item2,
    item3,
    item4,
    item5,
    item6,
    item7,
    item8,
    item9,
    item10,
)

a = item1, item2, item3, item4, item5, item6, item7, item8, item9
a = item10

Now remove the usage of item10, i.e., the last line. autoflake will remove the import of item10, with the end result (again stable after two runs):
# foo.py
from package import (
    item1,
    item2,
    item3,
    item4,
    item5,
    item6,
    item7,
    item8,
    item9,
)

a = item1, item2, item3, item4, item5, item6, item7, item8, item9

However, this is unlikely the desired result. Removing successive imports can even leave you with:
# foo.py
from package import (
    item1,
)

a = item1

This is most certainly not the desired result.
P.S. Workarounds exist: e.g., run isort once with force-single-line and then you can disable it again to recover the very original stable state.

The thing is, I think this is consistent with the isort and black's behaviors: they always add the trailing comma when expanding, and they respect trailing comma when contracting, so it's not possible to revert back to a state like from package import item1 once you've expanded an import. I don't see how we could support this without not respecting trailing commas.

Hi @charliermarsh , I understand, however I feel this slightly misses black's own philosophy of minimizing diffs. To that end, this is the workaround I mentioned:
# foo.py
from package import (
    item1,
)

a = item1

Add force-single-line
echo '[tool.ruff.isort]\nforce-single-line = true' > pyproject.toml

then re-run
❯ black foo.py && ruff foo.py --select=F401,I001 --fix
All done! ✨ 🍰 ✨
1 file left unchanged.
Found 1 error (1 fixed, 0 remaining).

and we get the required behavior:
# foo.py
from package import item1

a = item1

Of course, I'd then essentially remove the force-single-line setting to recover the original settings.

Hi @charliermarsh , I understand, however I feel there is a case here because I strongly subscribe to black's own philosophy of minimizing diffs. To that end, this is the workaround I mentioned:
# foo.py
from package import (
    item1,
)

a = item1

If we add force-single-line
echo '[tool.ruff.isort]\nforce-single-line = true' > pyproject.toml

and then re-run:
❯ black foo.py && ruff foo.py --select=F401,I001 --fix
All done! ✨ 🍰 ✨
1 file left unchanged.
Found 1 error (1 fixed, 0 remaining).

we get the required behavior:
# foo.py
from package import item1

a = item1

Of course, I'd then essentially remove
 ❯ rm pyproject.toml

to recover the original settings.

You can run black with --skip-magic-trailing-comma then it will always collapse the imports when possible.

Thank you @tmke8 , I think this works just about perfectly.


Add support for WordPress Site Icon

Hi guys,
Does Timber support Site Icons that can be set in the Customization screen of WP?
https://developer.wordpress.org/reference/functions/get_site_icon_url/
If not, do you plan to implement such function?
I know that I can display it using Timber function wrapper, but I'd love to see this built into the global site ($this) Timber object.
Thanks, Piotrek

@piotrkulpinski — good idea! I made that happen today — check out #1228 (now in master)


⚠ File access (beta) has degraded performance

In 2474f9e, File access (beta) (https://beta.fyle.uk/file/fish) experienced degraded performance:

HTTP code: 200
Response time: 5783 ms

Resolved: File access (beta) performance has improved in e6bf44b.


[BUG] Dependencies version checking not handling python release candidate correctly

Describe the bug
When using Python 3.11.0rc1, an exception is thrown stating this is not a release less than 3.12. I suspect that there being no space between 3.11.0 and rc1 is causing this version test to fail.
An exception occurred: IndividualInceptionClassifier requires python version to be <3.12, but system python version is 3.11.0rc1 (main, Aug 12 2022, 10:02:14) [GCC 11.2.0].
Steps/Code to reproduce the bug
from aeon.datasets import load_unit_test

X_train, y_train = load_unit_test(split="train")
X_test, y_test = load_unit_test(split="test")

inctime = InceptionTimeClassifier(n_epochs=20,batch_size=4)
print(inctime.fit(X_train, y_train))

Expected results
InceptionTimeClassifier(batch_size=4, n_epochs=20)
Actual results
File "/home/username/aeon_test.py", line 10, in <module>
    print(inctime.fit(X_train, y_train))
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/aeon/classification/base.py", line 175, in fit
    self._fit(X, y)
  File "/usr/local/lib/python3.11/dist-packages/aeon/classification/deep_learning/_inception_time.py", line 249, in _fit
    cls = IndividualInceptionClassifier(
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/aeon/classification/deep_learning/_inception_time.py", line 540, in __init__
    super().__init__(
  File "/usr/local/lib/python3.11/dist-packages/aeon/classification/deep_learning/base.py", line 63, in __init__
    super().__init__()
  File "/usr/local/lib/python3.11/dist-packages/aeon/classification/base.py", line 86, in __init__
    super().__init__()
  File "/usr/local/lib/python3.11/dist-packages/aeon/base/_base_collection.py", line 44, in __init__
    _check_estimator_deps(self)
  File "/usr/local/lib/python3.11/dist-packages/aeon/utils/validation/_dependencies.py", line 351, in _check_estimator_deps
    compatible = compatible and _check_python_version(obj, severity=severity)
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/aeon/utils/validation/_dependencies.py", line 289, in _check_python_version
    raise ModuleNotFoundError(msg)
ModuleNotFoundError: IndividualInceptionClassifier requires python version to be <3.12, but system python version is 3.11.0rc1 (main, Aug 12 2022, 10:02:14) [GCC 11.2.0].

Versions
Python 3.11.0rc1 (main, Aug 12 2022, 10:02:14) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from aeon import show_versions;show_versions()
System:
python: 3.11.0rc1 (main, Aug 12 2022, 10:02:14) [GCC 11.2.0]
executable: /usr/bin/python
machine: Linux-6.5.0-26-generic-x86_64-with-glibc2.35
Python dependencies:
pip: 23.3.1
setuptools: 69.0.1
scikit-learn: 1.4.1.post1
aeon: 0.7.1
statsmodels: None
numpy: 1.26.2
scipy: 1.12.0
pandas: 2.0.3
matplotlib: 3.8.4
joblib: 1.3.2
numba: 0.59.1
pmdarima: None
tsfresh: None

Hi @zobelb I do not seem to be able to reproduce your issue on python 3.11. What is your TensorFlow version ? That might be the origin of the conflict. I'm using 2.16.1.
from aeon.datasets import load_unit_test
from aeon.classification.deep_learning import InceptionTimeClassifier

X_train, y_train = load_unit_test(split="train")
X_test, y_test = load_unit_test(split="test")

inctime = InceptionTimeClassifier(n_epochs=20,batch_size=4)
print(inctime.fit(X_train, y_train))

System config :
System:
    python: 3.11.8 | packaged by conda-forge | (main, Feb 16 2024, 20:40:50) [MSC v.1937 64 bit (AMD64)]
executable: C:\Users\antoine\anaconda3\envs\test_env\python.exe
   machine: Windows-10-10.0.22631-SP0

Python dependencies:
          pip: 24.0
   setuptools: 69.2.0
 scikit-learn: 1.4.2
         aeon: 0.8.0
  statsmodels: None
        numpy: 1.26.4
        scipy: 1.12.0
       pandas: 2.0.3
   matplotlib: None
       joblib: 1.4.0
        numba: 0.59.1
     pmdarima: None
      tsfresh: None

Antoine, this is with the Tensorflow Docker containers that are packed with Python 3.11.0rc1. My suspicion is that it's the "rc1" part that is causing the issue from what I can see in the code. I've tried creating a development install of the aeon package on my computer but am running into issues with that so I can't verify my theory.
ERROR: Project file: aeon has a 'pyproject.toml' and its build backend is missing the 'build_editable' hook. Since it does not have a 'setup.py' nor a 'setup.cfg', it cannot be installed in editable mode. Consider using a build backend that supports PEP 660.
I thought setuptool 69.2.0 should get rid of that error.

You get this error while trying to install aeon from sources right ? This should indeed not happen, which command are you using ?
I'll take a look at the rc1 thing, maybe @MatthewMiddlehurst knows more or maybe @hadifawaz1999 has encountered similar issues during his work on DL ?

Following the instructions here: https://www.aeon-toolkit.org/en/stable/developer_guide/dev_installation.html

A bit strange that an old release candidate is being used, but I'm sure there's a valid reason. Not sure if the function for version checking can handle that, I agree.
AFAIK setuptools>=64 supports PEP 660? The install failure seems a bit weird. If you raise the build-system bound in pyproject.toml does that change anything?

Good job !
If you want to contribute this change you are welcome to ! Just tell us wheter you would want to do it (so we can implement the fix ourselves if you don't). If you need some help on contributing don't hesitate to message us on Slack.