[RFC] Enhancements for OSB Workloads

[RFC] Enhancements for OSB Workloads
Synopsis
This is an RFC for a proposal to enhance the workloads available with OpenSearch Benchmark.  It encompasses both including new workloads and adding additional capabilities to the existing workloads.
OpenSearch Benchmark currently ships with a small set of workloads that are used to evaluate the ingestion and query performance of OpenSearch clusters.  The limited number of workloads, small size of the associated data corpora and incomplete coverage of OpenSearch capabilities by the supplied queries is a hindrance to effective performance, scale and longevity testing.
This RFC outlines options to address some of these issues.
Motivation
OpenSearch Benchmark (OSB) is a performance testing framework intended for evaluating the performance of OpenSearch.  OSB is a workload generator that ships with a set of workloads, which are the scenarios that will be executed by the generator against a target cluster.  It is a fork of ESRally and can be used against OpenSearch clusters and Elasticsearch clusters that are v7.10 and under.  When OSB was forked, most of the workloads that ship with Rally were also forked.
A common use of OSB, for instance, is to benchmark different OpenSearch versions and compare them. For example, different versions can be installed on the same hardware configuration, and the same workloads run against each. Then the performance of these versions can be compared (for example, as latency vs. throughput curves) to see where one version does better than another, or if the performance of a newer version has regressed in some regard.  OSB’s capabilities include running benchmarks, recording the results, tracking system metrics on the target cluster and comparing tests.
Workloads have associated test scenarios (termed test_procedures) that include a set of operations including creating and deleting indices, checking the health of the cluster, merging segments, ingesting data and running queries.  From the perspective of OpenSearch performance, the latter two are evidently the ones of most interest.
For a user, the notion of “performance” exists in a certain context.  Most users and organizations are interested in how their cluster performs with regard to their own workload, which could be quite different from the workload run by a different user.  Organizations are usually reticent in sharing their workloads, which often contain proprietary data.  Therefore, the task of coming up with a representative set of workloads for OpenSearch in general is not a trivial one.
The workloads that ship with OSB contain an assorted set of scenarios from various domains, including search and log-analytics, with a range of document types, mappings and queries that the authors of Rally put together from publicly available data corpora.  They exercise various use-cases and do provide good insight into OpenSearch performance.   However, there are areas that are not covered well, leading to performance regressions such as this one.  This RFC focuses on the creation of additional workloads and enhancements to the currently included ones so that they exercise additional scenarios of interest in measuring OpenSearch Performance.
Areas for Enhancement
There are a few major areas of improvement with regard to the workloads available with OSB.  Some of them are enumerated below, not necessarily in priority order:

Increasing the size of the data corpora. The data sets associated with the current workloads tend to be rather small. They range from 100 MB to 75 GB, and most are under 10 GB. Such sizes are reasonable for single-node clusters based on small instance types, but are a hindrance when testing real-life multi-node clusters that utilize instances that have substantial memory and disk capacity. Providing a mechanism to increase the size of the corpora will help in this regard.
Better coverage of supported data types in OpenSearch.  OpenSearch supports several data types such as byte, short, float, double, geopoint and so on.  Backend performance of operations on these data types can change, for instance as a consequence of sort optimizations.  However, the existing workloads don’t exercise all these data types, and consequently, regressions might escape attention, for instance, see this issue.
Longer running workloads.  Performance regressions are not limited to throughput and latency degradation.  Issues such as memory leaks and increased CPU utilization may become apparent only after workloads have run for a long time.  The usual scenario with the included workloads is to run the default test procedure, which ingests data and runs a sequence of queries; this usually terminates in a few hours at most.  Being able to easily run more query iterations after a single ingestion will help surface such issues.  Increasing the size of the ingested corpora, repeating the ingestions over multiple days and extracting thread dumps on the target cluster may be areas to consider.
Quick-running workloads.  Identifying a set of representative workloads and/or parameters that enable a quick read of performance will be useful for several reasons, including being able to gate check-ins of changes.  One way might be to restore from snapshot and run only queries.
New workloads covering additional domains. The set of included workloads has remained static since the release of OSB. To keep the tool current and vital, it is essential to add workloads that represent new areas of interest such as machine learning, observability and so on. This item is not solely the province of the benchmarking team; it will require engagement with the extended open-source community to bootstrap.
Cataloging of the features exercised and filling in any gaps.  The included workloads cover areas such as ingestion, log-analytics and search, application domains such as web-server logs, geopoint searching, textual searching, etc.  However, there is no documentation characterizing the workloads and enumerating the types of queries that each features.  Doing this will help identify specific queries that are missing from the portfolio and that can be filled in.
Ability to easily add custom workloads.  A common question from users of OSB is regarding how they can add new workloads, especially ones that model their specific use-case.  Documentation regarding how to do this is slim.  Improving this, and providing an example of actual steps involved will go a long way in addressing this pain point.
Customer-representative workloads.  The workloads included with OSB were inherited from ESRally.  They were based on publicly-available data copora and sample sets of queries developed by the authors, to demonstrate how the tool might be used.  They don’t necessarily represent real-life user queries.  Performing a deeper exploration of the common use-cases of commercial users of OpenSearch will provide insight into how the workloads can be made more relevant to them.
Synthetic workloads.  It is not always possible to model a workload based on an existing workload, for instance, a user might be interested in modifying their schema to evaluate what-if scenarios.  Finding appropriate documents to ingest may not be straightforward either.  For such cases, synthetic workloads can be the solution.  Based on a schema definition and a specification of the desired characteristics and target size, a document generator can produce a large data set.  Templates could be used to generate appropriate queries as well.
Support for non-traditional scenarios.  Unlike a few years ago, OpenSearch clusters may not fit the traditional mold of a static number of data nodes equipped with on-disk storage.  Newer paradigms like tiered storage and serverless operation are becoming common.  Exercising performance testing for them require workloads that support such scenarios.  Some of the facets above like large corpora apply here as well.  But, they also need specific support — for instance, operations such as checking the cluster health may not be available with a serverless option.
Workloads for non-OpenSearch compatible services.  OSB is tied to the OpenSearch API and the current workloads operate only with OSB.  However, there are other applications and services that are used for log-analytics and search, such as Splunk and Loki.  Platform-neutral workloads will need to be an area of focus at some point in the future.

Stakeholders

OpenSearch users and developers, the primary consumers of any new and enhanced workloads
Opensearch developers implementing new features, who may be interested in performance testing them
Commercial managed services that track OpenSearch performance for the releases they offer
Corporate benchmarking teams, who may be interested in benchmarking their use-cases with OpenSearch against other options
OSB developers, responsible for implementing the workload enhancements

Proposed Priorities
As indicated above, enhancing the OSB workloads would be a multifaceted, complex, long-term and ongoing endeavor.  It will be need to be approached in prioritized phases.  Each of the areas outlined above would need in-depth research and analysis before they can be embarked upon.  Community engagement will help expedite the process, and indeed is crucial to enlarging the domains covered by the workloads.
With that in mind, this RFC suggests that a couple of the most pressing items in the list can be addressed first: providing a mechanism to increase the size of the data corpora and improving coverage for OpenSearch data types.  The solutions proposed below would alleviate the issues substantially in the short-term, but there will need to be on-going enhancements to these capabilities going forward as well.
The priorities of the items to tackle subsequently need to be evaluated and community feedback will be helpful in this regard.
Requirements
Here are the anticipated requirements for the two proposed areas of focus:
Increasing the size of the data corpora

The objective would be to provide a capability to increase the size of the data corpus associated with one workload initially; the timeseries workload http_logs is the proposed one
The user should be able to carry out performance tests with a data corpus in the size range of 100 GB to 250 GB, and perhaps larger.
Being able to control the timestamp sequence granularity in the generated documents will be helpful
Synthetic documents would be one possible approach, but duplication of the existing corpora will be a quick initial alternative
Queries that mesh with the generated timestamps will help control the subset of documents addressed in searches.

Better coverage of supported data types in OpenSearch

Either a new workload or modification of one of the existing workloads that operates on documents featuring additional data types.  Initially, timestamp, byte, short, float and double would be candidates for this exercise.
Documents that are to be ingested would include fields of these types.
Queries would carry out common operations on these data types such as basic searches, range operations, ascending and descending sorts and aggregations.
Sorts could be on numeric or string types.  Cardinality would be one of the facets considered.
Parameterizing the queries in one of the existing workloads may be one approach of tacking this item, but this needs to be investigated in more depth.
Aggregation and grouping should take into account the number of buckets.  Ranges could vary between 10 and 10K groups, increasing by orders of magnitude.

Use Cases

As an OpenSearch developer, I want to be able to track query performance for operations on supported data types such as bytes, integers, floating-point types, geo types, etc. I would like to be notified of regressions and be able to compare and co-relate performance of these different types.
As an OpenSearch user, I would like to have information on appropriate data types to use for my data models, that best fit my use-case and desired performance constraints.
As a OpenSearch engineer with Lucene expertise, I want to verify if low-level Lucene optimizations are surfaced in OpenSearch.
An an OpenSearch developer, I would like to run scale tests.
An an OpenSearch developer, I want to exercise scenarios for scenarios like UltraWarm, segment replication or parallelizing queries on Lucene segments, that require adequate amounts of data to provide meaningful data.
As an OpenSearch user, I want to run performance tests against multi-node clusters with replicated shards.  I expect to have ingestion and query run for reasonable durations rather than completing instantaneously.
As an OpenSearch user, I want to be able to create a small workload that demonstrates a new performance problem or a regression.

Implementation Notes
These rudimentary notes cover aspects relating to the first two proposed projects for now.  More details will be added as they become available while the investigation proceeds.
Better coverage of supported data types in OpenSearch

Cataloging of the existing workloads and the data types they support to identify the data types being covered currently
Identifying one or two workloads amenable to adding additional data types
Updating the mapping types with the new types
Modifying the documents in the target workload to add new fields corresponding to the new types
Parameterizing the queries to exercise the new types

Increasing the size of the data corpora

Initially will be a log-analytics workload based on http_logs.
Duplication of the corpora a configurable number of times in an initial phase
Rewriting one or more of the fields to eliminate duplicate documents
Generate the offset file in place
Update the index file specification for the workload
Update queries to work with the expanded corpora

How Can You Help?

Any general comments about the overall direction are welcome.
Indicating whether the areas identified above for workload enhancement include your scenarios and use-cases will be helpful in prioritizing them.
Provide early feedback by testing the new workload features as they become available.
Help out on the implementation!  Check out the issues page for work that is ready to be picked up.

Next Steps
We will incorporate feedback and add more details on design, implementation and prototypes as they become available.

[] #254

Better coverage of supported data types in OpenSearch

The bullets in the implementation notes cover a lot of cases, which is great!
I just wanted to call out some issues that I've encountered recently (which I would love to see covered by future benchmarks):

For some of the types, we should include cases where the corresponding field does or does not have doc values, or (where possible) where the field is or is not indexed. For example, there are some cases where there are optimizations based on IndexOrDocValuesQuery. Those optimizations will behave differently depending on whether the field is indexed, has doc values, or both.
I've stumbled across a couple of cases recently where performance is impacted by surprising combinations of "what's in the index", "what's in the query", and "what's in the index that matches the query". Usually, we expect that last category to have the most impact, but not always. For example, if you have a terms aggregation with an include clause with a lot of terms, and you run that aggregation on an index where that field has a lot of terms, it's going to take a long time -- regardless of whether the terms in the query match any of the terms in the index.
I would like to see some cases where we have index sorting enabled, since that can have significant impact on performance.

@msfroh those are all very good points, that will need to be kept in mind as the coverage of data types is improved.  We'll initially focus on adding queries for the data types that are not being exercised currently, and then add others for cases like the ones you mention above.

Customer-representative workloads. The workloads included with OSB were inherited from ESRally. They were based on publicly-available data copora and sample sets of queries developed by the authors, to demonstrate how the tool might be used. They don’t necessarily represent real-life user queries.
The title and the last disclaimer are counter to each other. Can you clarify does this represent customer workloads (representative not exact same query per se) so we can estimate the performance in real world ?

publicly-available data copora

@nandi-github The current workload is generated using public data but doesn't necessarily reflect customer workloads as its not generating using the actual customer data. Its almost impossible to create one workload that will be representative of all customers but a combination of these generic workloads along with other areas mentioned in this RFC would cover the broader surface area.

I remembered something from one of the benchmark systems that I worked with previously: It would let you measure the distinction between red-line QPS versus latency under normal load.
Essentially, it would benchmark in two phases:

Dial up the query traffic until you start to see rejections, then hold the pressure there for about a minute. That's your red-line QPS.
Then run the full benchmark (which would usually take ~30-40 minutes), sending traffic at something like 60% of red-line QPS, to measure latency under "normal load".

Usually a change that reduced the work involved in running a query would help both the red-line QPS and the observed latencies. Something like concurrent search would help observed latency, while hurting red-line QPS (unless it falls back to single-threaded under heavy load).

@msfroh Are you looking for gradual ramp-up feature to identify the max threshold of a cluster especially when running with multiple concurrent clients?

Are you looking for gradual ramp-up feature to identify the max threshold of a cluster especially when running with multiple concurrent clients?

That's part of it. Step 1 is to identify that max QPS threshold (i.e. what is the capacity of the cluster?)
Then step 2 is to run traffic (with multiple clients) at some proportion of max QPS, to simulate "reasonable load" (since a well-run system won't  run at 100% all the time -- what happens when a data center goes down?) to measure latency under "normal conditions".
As @nandi-github mentioned above:

It still need the query traffic pattern to be defined otherwise it is too subjective.

In the project where we were doing this kind of benchmarking, we had hundreds of thousands of queries from our production logs. While different queries had different latency and put different load on the system, the overall pool was big enough that any random 10k queries probably had about the same distribution of costs.

@msfroh, this is a feature other folks have been interested in as well, although the nuances of how it would work have been described in various ways.  There is an issue that touches on adding the capability to OSB to auto-scale and ramp up the intensity of the workload.  As you mentioned, this would need to take into account the differences between operations.  For instance, a complex aggregation would behave quite differently than a term query.  Scaling up will also need to take into account the capabilities of distributed workload generation.
Once the features requested in the issue above are implemented, it will be the right point to address your request.

Related to #199 and https://github.com/opensearch-project/neural-search/issues/430, I think we are adding a lot more options in OpenSearch recently for improving search relevance. Users can use neural queries, neural sparse queries, custom re-rankers, etc. in order to achieve better quality results. On top of this, for the ml side, they may have several models to choose from for each configurations.
That being said, with all of those options, it can be really hard for users to converge on an optimal configuration for search. While OSB allows users to get metrics around performance (latency, throughput etc.), users are unable to determine the benefits in search relevance they are getting. I know that it may not make sense to measure relevance information while running throughput/latency focused steps due to overhead, but I think that it would make sense to incorporate certain steps dedicated to relevance in the dedicated search workloads.  That way, a user only needs to run one workload in order to understand tradeoffs wrt to performance and relevance.
Please let me know if it makes sense to discuss in a separate issue.

Referencing issue related to autoscale feature - https://github.com/opensearch-project/opensearch-benchmark/issues/373


added vdropzone-sending event to modify request

I needed to add additional post data with the file, so I thought I'd create a pull request to see if you want to add it real quick.

Thanks so much @gborcherds for this!

Thanks!


Created item detailed page

Proposed Changes

Added new column (view details) to the Grid
Added new page to show a donut which represents the percentage of the selected item.

Checklist

[x] Feature developed
[ ] Created/updated unit tests
[ ] Comments in code
[ ] Documentation written

Coverage decreased (-1.8%) to 76.083% when pulling 1de9896b1b01fda1c5262ebc5eed4c540a16b780 on leonardoampuero:master into ddf7c8e1ee591036dbf2f6285e5ae412423f4f6e on ModusCreateOrg:master.


Remove unused configuration files from atmosphere directory

The atmosphere control directory contains several overlapping configuration files:
CNTLALL   PPCNTL  UAFILES_A  errflag  ftxx.new   ihist          parexe          prefix.PRESM_A
CONTCNTL  SIZES   UAFLDS_A   exstat   ftxx.vars  input_atm.nml  prefix.CNTLATM  um_env.py
INITHIS   STASHC  cable.nml  ftxx     hnlist     namelists      prefix.CNTLGEN

As noted here, the minimal set required is:
STASHC     UAFLDS_A   errflag  ihist          namelists       um_env.py
UAFILES_A  cable.nml  hnlist   input_atm.nml  prefix.PRESM_A

The extra files have been removed from the required configuration files in payu (https://github.com/payu-org/payu/pull/455) and can be removed from the configurations once those changes make their way into the latest version of payu.

Closing as this was addressed in #42 and #43


Weakness in instruction "How to Debug the Dreamview Start Problem"

Describe the bug
Weakness in instruction "How to Debug the Dreamview Start Problem".
To Reproduce
Follow the instruction. After typing

cmake ..

instruction tell

#backup pcl lib
mkdir -p /usr/local/lib/pcl.origin
mv /usr/local/lib/libpcl* /usr/local/lib/pcl.origin
#replace with our build
cp -a lib/* /usr/local/lib/

Expected behavior
Obviously instruction

make

is forgotten.
Desktop :

OS: [Ubuntu 16.04 LTS]
Browser [Chrome]
Version [Apollo 3.0 (r.3.0.0)]

@gladijos Yeah, you're right, good catch!
And would you like to submit a PR for this? All contributions are welcome!

@zhxt  thanks for answer! I never did it, but I'll try soon!

@gladijos Great!  You can refer to How to Contribute to Apollo and  How to create a pull request.
Feel free to let us know if you have any questions.

Stale issue closed.


register eos tokens offline

Is there a way to register eos tokens offline?
ie generate/sign the transaction offline and only publish online (not have to enter private mycrypto keys on an online computer)?

You can track our progress on getting this sorted in a clean matter here, as well as a workaround: https://github.com/MyCryptoHQ/MyCrypto/issues/1495#issuecomment-381275053


static ip dont seem to apply on ethernet interface (Olimex ESP32-POE)

When I set the "use ethernet" under adapter, the ethernet interface get a dhcp address, and I can access the webinterface through the ethernet. but when I set a static IP, it seem to ignores the static ip at still use a dhcp.
I can see that it save the ip config, and the checkbox "accquire IP Address automatically (DHCP)" is unchecked
Board: Olimex ESP32-POE
FW: 2.2.1

If you still have a reservation for the old address in your router it will use that no matter what based on the mac address.  There really are very few reasons where you might want a fixed IP on a device.  A DHCP reservation for the mac is much more reliable.

I am going to close this for now.  I have tested with another Ethernet board and the IP address assignment worked as advertised.  However, the way this works is a request for the specified IP address and the router can deny it if there is anything in the routing table that says otherwise.


multi color for multi tag

hi, thanks for this great lib!
i wanna ask, is it possible to use multi color for each item in tag list?
for example i have 5 tags, i want first and second tag is red background with black list and white color text, while third one is red list with transparent background and black text, rest of all is random.
thanks!

i have meet same problem,the TagGroup only one tag selected.can't set every tag style

protected TagView getTagAt(int index) {
return (TagView) getChildAt(index);
}
get the tagView

change protected to public , TagView is entend TextView. you can get you wanted

how can I change protected to public in the read-only file = =


firmware zips in wiki

New 3DS 11.2.0 to 10.4.0
Old 3DS 11.2.0 to 10.4.0
Both link to 11.1 versions

Linik is https://plailect.github.io/Guide/11.1.0_to_10.4.0_n3ds.torrent
should be https://plailect.github.io/Guide/11.2.0_to_10.4.0_n3ds.torrent

Fixed.

great work @Plailect


Add @types/mocha as dependency

Patch version to 1.1.14

@pana-cc you might want to remove the devDependency towards  "@types/mocha": "^5.0.0"

@pana-cc can you please also fix the indentation from line https://github.com/pana-cc/mocha-typescript/blob/924cabc7a40dd14419ad366605cad0fa7ce6d5e9/index.ts#L188 onward? I mixed up tabs and spaces...

@pana-cc I will create a new PR for this where I also fix the indentation I messed up with my previous PR (spaces instead of tabs)


Left behind trailing whitespace after writeln macro

Reproduce it with:
echo 'Zm4gbWFpbigpIHsKICAgIHdyaXRlbG4hKHJlc3VsdCwgIjwhLS0ge306IEN1cnZlOjpmcm9tX3BvaW50cyhDb29yZDIoeHgsIHh4KSwgKENvb3JkMih4eCwgeHgpLCBDb29yZDIoeHgsIHh4KSksIENvb3JkMigpKSAtLT4iLAogICAgaW5kZXgsIAogICAgKTsKfQo=' | base64 -d | rustfmt

error[internal]: left behind trailing whitespace
 --> stdin:3:3:11
  |
3 |     index,
  |           ^
  |

rustfmt 1.4.38-nightly (f624427 2022-02-06)

Thanks for submitting the issue!
I find that it's a little easier to include the snippet of code directly so anyone wanting to work on the issue can easily copy and paste it.
fn main() {
    writeln!(result, "<!-- {}: Curve::from_points(Coord2(xx, xx), (Coord2(xx, xx), Coord2(xx, xx)), Coord2()) -->",
    index,
    );
}

Does the issue only happen when the input is read from stdin? I'm not able to reproduce this when formatting the input from a file.

cd $(mktemp -d)
cargo init . --name abc
echo 'Zm4gbWFpbigpIHsKICAgIHdyaXRlbG4hKHJlc3VsdCwgIjwhLS0ge306IEN1cnZlOjpmcm9tX3Bv
aW50cyhDb29yZDIoeHgsIHh4KSwgKENvb3JkMih4eCwgeHgpLCBDb29yZDIoeHgsIHh4KSksIENv
b3JkMigpKSAtLT4iLAogICAgaW5kZXgsIAogICAgKTsKfQo=' | base64 -d > src/main.rs
cargo fmt

errors as intended ;)
That's why I provided the base64 input. Your editor may remove the trailing whitespace on its own.

Thank you for sharing.
The root cause of the problem is that it's impossible to apply the formatting rules to your input in any way that's compliant with all rules and your config settings (yes I realize those are at the default values). In these cases rustfmt simply leaves the code as you wrote it instead of trying to pick which rule(s)/config(s) to violate. Your original input had a trailing space, and rustfmt is simply flagging that as part of an indicator to let you know.
That's intentional behavior for the default, though I also realize some folks would prefer rustfmt forget about max_width in these cases. There's some instances where we have enhanced rustfmt to be able to do this, but it's feature gated so as to not introduce breaking changes.
The default behavior isn't going to change any time soon, so I'm going to close this. Here's some options available today for you to consider:

Set version=Two in your config file. Note that this will likely introduce other formatting changes, generally improvements, but it also is the flag that gives rustfmt the :+1: to not worry about the long string lit

You may also want to consider pairing this with error_on_unformatted=true to get a more explicit error about such long lines

Set format_strings=true in your config file to give rustfmt permission to wrap the long string lit in order to keep it within the max_width limit
Manually split\wrap the long string in the manner of your choosing such that it can fit within the max_width limit


[Feature request] Retry the unmounting operation?

Related to #114 .
Hi, thanks for your great work! Recently I encountered a ”resource busy“ error when using this tool in GitHub Actions workflow. Here is the log:
...
Done running the AppleScript...
Fixing permissions...
Done fixing permissions
Blessing started
Blessing finished
Unmounting disk image...
hdiutil: couldn't eject "disk2" - Resource busy
...

But I cannot reproduce it again:
...
Done running the AppleScript...
Fixing permissions...
Done fixing permissions
Blessing started
Blessing finished
Unmounting disk image...
"disk2" ejected.
Compressing disk image...
...

The code lines:
https://github.com/create-dmg/create-dmg/blob/121dbfac5ab5c0fde15c895b579130ca7dbfa95e/create-dmg#L407-L409
Could we wait a moment and try it again? I found something similar: https://github.com/LinusU/node-appdmg/pull/190 ( https://github.com/LinusU/node-appdmg/issues/142 and https://github.com/LinusU/node-appdmg/issues/161 )
I think a temporary set +e may be required since you set set -e on the top of the script.
Thank you for your time.

As the manual page of hdiutil said:

ERRORS
                                 ...                                  In
 general, it tries to turn these error numbers into localized strings for
 the user.  For background, intro(2) is a good explanation of our primary
 error domain: the BSD errno values.                ...                The
 following is a list of interesting errors that hdiutil can encounter:

 ...

 [EBUSY]            Resource busy.  Used if necessary exclusive access
                    cannot be obtained.  This error often appears when a
                    volume can't be unmounted.

from: https://ss64.com/osx/hdiutil.html

I looked up the code of "BSD errno":
https://github.com/apple/darwin-xnu/blob/8f02f2a044b9bb1ad951987ef5bab20ec9486310/bsd/sys/errno.h#L108 :
#define EBUSY           16              /* Device / Resource busy */

https://github.com/freebsd/freebsd-src/blob/de1aa3dab23c06fec962a14da3e7b4755c5880cf/sys/sys/errno.h#L69 :
#define	EBUSY		16		/* Device busy */

Therefore, I think it is sufficient to check whether the returned status code $? is 16 (compare with the code at https://github.com/LinusU/node-appdmg/blob/e1394d24b1be7799a3949ad0686cd9abb64339ee/lib/hdiutil.js#L67 ).

A PR with some unmount retries (maybe 2-3?) would be awesome @pzhlkj6612!


Update run_tests to generate xml reports for CI

This is a continuation/replacement of #529.
This PR adds the necessary CI config changes to run the chromium tests and report them in the various CI platforms.

Here is the test output in VSTS:

Test output in CircleCI can be seen here:
https://circleci.com/gh/electron/libchromiumcontent/6729?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
Appveyor test output here:
https://windows-ci.electronjs.org/project/AppVeyor/libchromiumcontent/build/1.0.1464/job/1nqd1llk489c2y3k/tests

@ckerr I made the requested changes you asked for.


Reorganize Form and Form.Attributes

Though the initial intention of splitting Form.Attributes from the ORM was a separation of concerns (the function of the Attributes library is not dependent on HOW the ORM operates, we could use them for classes for instance - similar to how EF operates), we have reached a level of complexity where it is starting to make sense to add a testing framework to Attributes to ensure reflection operates as desire, and perhaps more importantly to begin a more rigorous course of test driven development.
For this reason, I propose the following:

Encapsulate all the calls to FSharps reflection library(ies) in Form.Attributes

The benefit here is obvious, allowing the actual ORM to focus on interactions with databases.

Add, for the purpose of generality, population of SqlMapping records from non-record types with attributes, e.g.:

[<Table("aTable", DbContext.Default, Schema = "notPublic")>]
type SomeClass(someData) =
    [<Column("SomeData", DbContext.Default)>]
    member _.someData = someData

let classColumnMapping< ^T > state -> SqlMapping

Right now, the above is completely allowed by the compiler (attributes on types and properties don't care if the type is record or not), but since we have been encapsulating the population of SqlMapping in the ORM (even though the SqlMapping itself is in Attributes) it hasn't really made sense to provide the above functionality.
@Zalarian let me know your thoughts.

see branch dev-attribute-reorg for WIP POC

Privately discussed the pros/cons. Closing due to agreeing this is not the approach we want to take.


Documentation for onboard_service missing for 0.8.x

https://keptn.sh/docs/0.8.x/reference/cli/commands/keptn_onboard_service/
Documentation is not found and returns 404.

I ran into this issue due to a reference in https://tutorials.keptn.sh/tutorials/keptn-full-tour-dynatrace-08/index.html?index=..%2F..index#12
And as onboard is deprecated no documentation will be generated for that command.
See:
https://github.com/keptn/keptn/blob/1937f8461f960b5ba7d6de38ae463fdda9d8769e/cli/cmd/onboard.go#L12

Action item

Merge the content of the section Onboard a service into the section Create a service
Make sure that no keptn onboard service command is in the docs

Definition of Done

[ ] Content of Onboard a service about the Helm Chart requirements are merged into Create a service


xdg_shell: destroy children popups with parent surface

popups have a link in parent's surface->popups list and needs
to be freed before:
==6902==ERROR: AddressSanitizer: heap-use-after-free on address 0x6120001a0300 at pc 0x7fc1447acb50 bp 0x7fffd396e680 sp 0x7fffd396e670
WRITE of size 8 at 0x6120001a0300 thread T0
    #0 0x7fc1447acb4f in wl_list_remove ../util/signal.c:55
    #1 0x7fc14477d206 in destroy_xdg_popup_v6 ../types/xdg_shell_v6/wlr_xdg_popup_v6.c:162
    #2 0x7fc1447816e0 in destroy_xdg_surface_v6 ../types/xdg_shell_v6/wlr_xdg_surface_v6.c:108
    #3 0x7fc144a1c025 in destroy_resource src/wayland-server.c:688
    #4 0x7fc144a1c091 in wl_resource_destroy src/wayland-server.c:705
    #5 0x7fc14477fd6f in xdg_client_v6_handle_resource_destroy ../types/xdg_shell_v6/wlr_xdg_shell_v6.c:72
    #6 0x7fc144a1c025 in destroy_resource src/wayland-server.c:688
    #7 0x7fc144a20851  (/lib64/libwayland-server.so.0+0xc851)
    #8 0x7fc144a20d92  (/lib64/libwayland-server.so.0+0xcd92)
    #9 0x7fc144a1c140 in wl_client_destroy src/wayland-server.c:847
    #10 0x7fc144a1c21c in destroy_client_with_error src/wayland-server.c:307
    #11 0x7fc144a1c21c in wl_client_connection_data src/wayland-server.c:330
    #12 0x7fc144a1df01 in wl_event_loop_dispatch src/event-loop.c:641
    #13 0x7fc144a1c601 in wl_display_run src/wayland-server.c:1260
    #14 0x40a2f4 in main ../sway/main.c:433
    #15 0x7fc143ef718a in __libc_start_main ../csu/libc-start.c:308
    #16 0x40b749 in _start (/opt/wayland/bin/sway+0x40b749)

0x6120001a0300 is located 64 bytes inside of 264-byte region [0x6120001a02c0,0x6120001a03c8)
freed by thread T0 here:
    #0 0x7fc14690d880 in __interceptor_free (/lib64/libasan.so.5+0xee880)
    #1 0x7fc1447acce8 in wlr_signal_emit_safe ../util/signal.c:29
    #2 0x7fc1447a3cac in surface_handle_resource_destroy ../types/wlr_surface.c:576
    #3 0x7fc144a1c025 in destroy_resource src/wayland-server.c:688

previously allocated by thread T0 here:
    #0 0x7fc14690de50 in calloc (/lib64/libasan.so.5+0xeee50)
    #1 0x7fc144781d38 in create_xdg_surface_v6 ../types/xdg_shell_v6/wlr_xdg_surface_v6.c:415
    #2 0x7fc14147503d in ffi_call_unix64 (/lib64/libffi.so.6+0x603d)

Alternative would be to have popups listen to the parent's surface
destroy event and remove themselves from the list at this point OR on
their own destroy, whichever happens first, but that seems more
complicated for little benefit.

Can we actually get away with destroying resources at this point?

How do you reproduce this?

Can we actually get away with destroying resources at this point?

I thought destroying resource would do the right thing™?
The client doesn't like it (wayland fatal error "zxdg_shell_v6@20: error 2: xdg_popup was not created on the topmost popup") but I think it's the wrong one here, I need to take a closer look at some WAYLAND_DEBUG output.

How do you reproduce this?

konsole, go to any menu with a submenu, it happens when you hover over the entry that has a submenu and it would normally open a 2nd column... But you need to hack in some redefinition of wl_list_remove in wlroots/sway for asan to work, I just copy/pasted the implementation from wayland into some file in util/ so wlroots will use the local symbols instead of libwayland's and these have been compiled with asan.
You should be able to reproduce without this hack if you run sway/rootston in valgrind

I thought destroying resource would do the right thing™?

Not unless the client has indicated they'll no longer use it (which may be true in this case... or might not).

Not unless the client has indicated they'll no longer use it (which may be true in this case... or might not).

Then it's probably wrong, I guess we could just empty the list here but this might mean fixing how the popup behaves if it has no parent, I don't think this was planned for.
I don't like having two places that can remove a link from a list though, especially since link after wl_list_remove is not considered empty for wl_list_empty....

Yeah, I see the memory errors in valgrind, so this is a problem. But I have a feeling this works only because the client is being disconnected because of the error.

yeah now SirCmpwn said it I agree this is wrong, I'll think about it while at work today

Rewrote that popup fix to just cleanup the list instead, even if that feels ugly to me, that looks safe enough; and it probably should never happen with correct clients anyway.
Pushed a couple more fixes at the same time:

xwm has the same problem with parent/children, fixed the same way, but that chlidren list is never used so probably better to just make it go away unless there's plans to use it later.
the primary selection one is more straight-forward, unless cancel has any reason to use that event, but it's supposed to come from source_finish so I think that's ok?

:+1:


WIP PInvoke

When complete, I should be able to generate the contents of PInvoke.fs.


⚠ Bofrost.be has degraded performance

In f71062d, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1025 ms

Resolved: Bofrost.be performance has improved in b8477cc after 6 minutes.


[Addition]: 【----Welcome to appreciate the helium cheating in the big party!------ 】

Hotspot b58 Addresses
123456
Discord Handle
No response
Reason(s)
Welcome to appreciate the helium cheating in the big party!
Look blacklist proportion will understand, don't need I say more, you create the blacklist inside what is it? Serious metasomatism out!

Helium is a decentralized network of fair?
Helium is a decentralized network of fair?
Helium is a decentralized network of fair?
Helium is a decentralized network of fair?
Helium is a decentralized network of fair?
Helium is a decentralized network of fair?
Helium is a decentralized network of fair?
Helium is a decentralized network of fair?
Helium is a decentralized network of fair?
Helium is a decentralized network of fair?


feat(trace.py): add support for numeric labels

Please re-review @ronyis

:tada: This PR is included in version 1.43.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Proper Logging

As a follow up to a post merge #190 develop branch, the project should be cleaned up to include logging where appropriate. Uses of the various logging levels can be seen in the chart on the above pull request. Also as a part of this, the intention of trace logging should be more clearly defined and used accordingly.
This is especially crucial for #221 to involve non-encoded trace log messages.

Everyone should keep in mind that when they update files or make enhancements that they can use the logging classes and the appropriate log levels to give developers additional information


Complex graph rendering

I have 2k entities and edges in my graph, and it starts getting messy. I wonder what are the good practicies to deal with it?
At the moment i'm filtering based on node degree, which makes it look nicer, but it also loose the data.
Can you give some example, on how to dynamically change Node degree filter, based on zoom level or similar?
Or maybe there are some other techniques out of there?

This is not the place to discuss these kind of topics, since we try to focus here on bugs and features request for sigma.js, so I'll close this ticket.
However, some quick notes: We (at OuestWare) use various strategies to tackle this problem:

You can have a network with a layout, and play on filtering, search and/or highlighting, as we do in Retina (example)
You can dynamically build your graph, apply dynamic layouts, and allow your users to progressively expand the graph themselves, so they don't just get slapped with a huge graph at once. We have nothing public to showcase, but you can play with Neo4J Bloom to get some running example.
You can offer more controls to your users on what they can do with their networks, as we do in Gephi Lite (completely inspired from Gephi).

I hope this helps.


Skip validation of "company" in Shipping checkout step

Type: breaking
Describe the bug
As described in https://github.com/reactioncommerce/example-storefront/issues/494 the previously saved shipping address can't be edited and saved in checkout.
To Reproduce
Steps to reproduce the behavior:

Add Products to cart and checkout
Add a shipping address
Reload the page
Edit the address, notice that the save Button always stays greyed out.

Expected behavior
As all visible fields seem valid to the user, the Save button should be enabled.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop/Smartphone:
This error is device independent
Additional context
A saved address which is then fetched after after reload will contain company with a value of null, therefore making the validation isFormFilled fail.
Possible solution
Skip company when checking the fields for null, just like it is done with address2

:tada: This issue has been resolved in version 0.66.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


AST: fully qualify the friended complete template specialization

When building with Visual Studio, the following error is identified:
'SimpleRequest': non-class template has already been declared as a class template
note: see declaration of 'SimpleRequest'
Change the friend declarations to friend the complete template specialization
that we derive from to ensure that the templated class is friended
appropriately.  This repairs the build with Visual Studio and ensures that the
friending is more strictly checked.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

CC: @DougGregor @jrose-apple

CC: @swift-ci please test

Does friend SimpleRequest; work too?

Build failed
Swift Test Linux Platform
Git Sha - 9e08c0a7e6c56662907e9adbec65dc1643af51db

Yep, looks like it: https://godbolt.org/z/9YVoSM.
(Those Linux failures definitely aren't yours!)

Yeah, that does seem to work for me (14.13.26128).

@swift-ci please test and merge

@swift-ci please test and merge


SyntaxError: Unexpected reserved word

Describe the bug
Steps to Reproduce

Followed all install steps -- including python -m pipenv requirements > requirements.txt && python -m pip install -r requirements.txt
Finished backend steps and then launched new terminal to load frontend.
Received following error when running npm start:

~/OpenDevin/frontend
% npm start

<EMAIL_ADDRESS>start
vite

file:///home/xxxx/OpenDevin/frontend/node_modules/vite/bin/vite.js:7
await import('source-map-support').then((r) => r.default.install())
^^^^^
SyntaxError: Unexpected reserved word
at Loader.moduleStrategy (internal/modules/esm/translators.js:133:18)
at async link (internal/modules/esm/module_job.js:42:21)
Tried ignoring and loading <IP_ADDRESS>:3000 and received {"detail":"Not Found"}
Backend logs INFO reports:
INFO:     Started server process [10464]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://<IP_ADDRESS>:3000 (Press CTRL+C to quit)
INFO:     <IP_ADDRESS>:53266 - "GET / HTTP/1.1" 404 Not Found
INFO:     <IP_ADDRESS>:53266 - "GET /favicon.ico HTTP/1.1" 404 Not Found
INFO:     <IP_ADDRESS>:54462 - "GET / HTTP/1.1" 404 Not Found
Expected behavior
OpenDevin runs
Actual behavior
{"detail":"Not Found"}
INFO:     <IP_ADDRESS>:54462 - "GET / HTTP/1.1" 404 Not Found
Additional context

I run into this issue yesterday
Check npm version
node --version
If your version is older than 14.8.0, update Node.js
If you have nvm installed, you can upgrade using the following commands:
nvm install --lts
nvm use --lts

This helped me, but I'm not an expert here.

Yup this is an old node version. We explicitly require 14.8+

Thank you so much omutist! That absolutely was the problem. Everything's working now.


Improved Create safety and fixed bugs; removed debug print in Data

This just fixes bugs in the already-merged #152 so if merging that was a good idea (maybe not!), merging this is also a good idea.


feat(setup): add setup wizard and script runner

Add setup script for bee-stack:
Ref: #6 #15 #5

@planetf1 Do you have docker or rancher installed as well? It's preferred. Should I add another question to select a docker provider? I think most people have only one

@planetf1 Do you have docker or rancher installed as well? It's preferred in the script. Should I add another question to select a docker provider? I think most people have only one

I don't have docker (desktop) installed on macOS due to licensing/policy + technically too easy to get into messy clashes, especially when using podman in compatibility mode.
Similarly for rancher, though that remains installed (without compatibility set up)
I do have it on linux
podman has been a bit tricky in the past, but the most recent releases are a lot better with compatibility - most things now work. It's also the most license-friendly implementation (rancher is also good), so I think it's quite important to have support for .
podman also supports either the docker-compose provider, or it's internal one. Ideally it would be better to support either (especially as the plugin then becomes a global configuration). Neither seemed to past the test when I tried the PR earlier :-(
I can take a look at the script checks in more detail if it helps.

We cannot support outdated (v1) compose commands, the docker-compose with dash has reached end of life:
https://docs.docker.com/compose/install/
We support these, the appropriate should now be selected automatically if the version meets the requirements (>= 2.29):
podman compose
docker compose

You are of course free to use the manual section and run it however you wish, it's a compose file after all...
But the script will not support it


ServiceAuthorization config example correction

The config example currently has serviceAuthorization config element directly under system.serviceModel/behaviors. This is incorrect according to the documentation here (https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/wcf/serviceauthorization-element) and also generates design-time errors. It should be at system.serviceModel/behaviors/serviceBehaviors/behavior/serviceAuthorization.

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

ID: 03c886fb-4abc-88cc-1831-74a3241c59c5
Version Independent ID: 6933719f-0398-d9a8-57df-39fe09b40ae3
Content: How to: Create a Custom Authorization Policy
Content Source: docs/framework/wcf/extending/how-to-create-a-custom-authorization-policy.md
Service: unspecified
Product: dotnet-framework
GitHub Login: @dotnet-bot
Microsoft Alias: dotnetcontent

@zhenlan can you or your team look at this issue?

@jcondex can you please confirm?

ping @jcondex

Add @Lxiamail

@MaxWilson Yes, you are right, the serviceAuthorization element should be system.serviceModel/behaviors/serviceBehaviors/behavior/serviceAuthorization


Manually setting NODE_ENV

Details
How do we go about setting the NODE_ENV manually considering that Nuxt build would automatically change the NODE_ENV to production?
Ref: https://github.com/nuxt/nuxt/issues/19819

Hi @dextersiah, I wasn't actually aware of this limitation. I've introduced an env config to https://github.com/harlan-zw/nuxt-site-config that will stand in as a replacement for NODE_ENV. Available in v2.0.0-beta.37.
Through environment variables, you would use NUXT_SITE_ENV=staging or NUXT_PUBLIC_SITE_ENV=staging.
I'll improve docs on this as I go.
Will close for now but let me know if you have any feedback on this.


Browserslist: caniuse-lite is outdated.

This new vanilla Rails 7.1.1 install uses --css=tailwind and importmaps (rails new . --css tailwind). Starting the rails server with bin/dev generates a css Browerslist warning.
Specs:
Using asdf with ruby 3.2.2, nodejs: 21.0.0 (latest), npm: 10.2.0
08:47:48 web.1  | => Booting Puma
08:47:48 web.1  | => Rails 7.1.1 application starting in development
...
08:41:04 css.1  | Browserslist: caniuse-lite is outdated. Please run:
08:41:04 css.1  |   npx update-browserslist-db@latest
08:41:04 css.1  |   Why you should do it regularly: https://github.com/browserslist/update-db#readme
08:41:04 css.1  |
08:41:04 css.1  | Rebuilding...
08:41:04 css.1  |
08:41:04 css.1  | Done in 172ms.

Running the update npx command, as suggested, generates an error.
update-browserslist-db: Cannot find package.json. Is this the right directory to run npx update-browserslist-db in?
Could this be safely ignored or need attention? I have not seen this before. Granted, I have mainly used esbuild and not importmaps - perhaps it's looking for node_modules dir. I am just throwing this out there. Any guidance would be appreciated.

Duplicate of #283


SAK-22664 - Scaling issue in GB logic - Contributed patch

Before this goes in it would be good to get some metrics around performance in large sites for a before and after comparison.
Also, there is wording in there which is alarming (ref: serious scalability issues), but I think that is misleading. IIRC, the Hibernate Criteria API does this limited searching method internally anyway when it sees an IN clause with > 1000 items, because, well, it's an ORM and those sorts of driver specific internals are the exact thing its means to hide.
For a site with a few thousand users you would see a couple of extra queries per API call.

The issue HHH-1123 (https://hibernate.atlassian.net/browse/HHH-1123) that was created in 2005, actually wasn't fixed until Hibernate 4.1.7. Sakai is still on 3.6 and hasn't done the upgrade yet (https://jira.sakaiproject.org/browse/KNL-945), maybe for Sakai 12 now that Spring was updated. So I'm pretty sure all of these workarounds for the 1000 items are still needed.

I"m going to put up a new PR with just the change against getAllAssignmentGradeRecordsForGbItemLimited as that's what @smarquard said he was running on the ticket.


More annotation colors

Currently there are only four colors for markers/arrows and only three for line annotations (i.e. gutter annotations).
These are not enough and they aren't super accessible for colorblind people.
This would also be a good opportunity to allow customization of the amount of line annotation options, which would be useful for facilitators in the "most important lines" exercise.

Turns out this won't be a good opportunity to customize the amount of line annotation options, because the line-annotations div is a part of the svg, and so if it changes size then all the markers and arrows shift. In order to implement this we would need to make it so that the svg only covers the <pre> elements, which is easy enough, but it would also be a breaking change (although we can hotfix it by shifting all markers and arrows a bit to the right. This would work but only for people who use the default zoom setting.)
In summary: I think we should do it, but it would be a substantial change so it should be separated from "more annotations colors"

@katjam what do you think?
I used colors from the Material Design color palettes

I like the palette, but I wonder it the light and dark of each have enough meaningful / visible difference?
I thought for example it could be nice to colour the instantiation a dark red and all uses of it in light read, bit those tints are too close for that.
If it's an aesthetic choice to use one or the other (top or bottom row) in terms of general readability for an individual, then having a top level toggle of 'palette' would be better than presenting all on them in the modal.

@katjam what about this? it's 16 different hues with the same brightness (that you could configure in a top level toggle, like you said) (this would also work nicely with a dark theme toggle, where we could automatically turn the 100 level to a 800 and the 200 to a 700 for example)

Sounds good to me.


Bump version

Now u only need to add tag and push new version to cocoapods

@Stunner what about pushing tag to master and pushing new version of pod?

@MortMerr I no longer use this project and haven't personally thoroughly tested that this project works properly... I would hate to push out something that is error-prone to CocoaPods. If you are using this project and would be up to checking to ensure everything works fine and let me know. I will push out a new pod.
But the stipulation that I personally haven't approved it will still be attached to this project and Pod. I am only willing to do it seeing as no other contributors are active and there seems to still be interest in having an updated Pod for this project.


Correct environment setup for React, Redux

Run the app in production mode: gulp and see the console.
Warning: It looks like you're using a minified copy of the development build of React. When deploying React apps to production, make sure to use the production build which skips development warnings and is faster. See https://fb.me/react-minification for more details.

app.min.js:12 You are currently using minified code outside of NODE_ENV === 'production'. This means that you are running a slower development build of Redux. You can use loose-envify (https://github.com/zertosh/loose-envify) for browserify or DefinePlugin for webpack (http://stackoverflow.com/questions/30030031) to ensure you have the correct code for your production build.

The 2nd warning might be caused by uppercase env string in config.environment.type. I believe it should be lowercase so when the code is being minified, dev/prod conditions can be met:
if (process.env.NODE_ENV === 'development') { /* development code */ }

@vbulant I think both these errors may be solved by setting process.env.NODE_ENV to production (lowercase) when building the app.
I do not have experience testing this, but in Webpack examples when you build app you set NODE_ENV this way, and React catches propcess.env.NODE_ENV and build sources appropriately.
Have you tried setting it to prod?

Yep that’s what I meant by the second comment. As of now, we have uppercase PRODUCTION/DEVELOPMENT values in process.env.NODE_ENV and they should be lowercase as far as I know. Gonna test it as soon as possible. Thanks.

Setting lowercase development/production worked 👍


Revert "Removing unused fetch sub phase processor initialization during fetch… (#12503)"

This reverts commit da5b2053864f24dcb3b8c555a9fd19e0d91a14e6.

Description
Reverts https://github.com/opensearch-project/OpenSearch/pull/12503 that introduced regression in 2.13.0. Thanks a lot  @martijnbolhuis for spotting it and supplying the tests, @dblock for working with the contributor.
Related Issues
Closes https://github.com/opensearch-project/OpenSearch/issues/13467

Check List

[X] New functionality includes testing.

[X] All tests pass

[X] New functionality has been documented.

[X] New functionality has javadoc added

[X] Failing checks are inspected and point to the corresponding known issue(s) (See: Troubleshooting Failing Builds)
[X] Commits are signed per the DCO using --signoff
[X] Commit changes are listed out in CHANGELOG.md file (See: Changelog)
[X] Public documentation issue/PR created

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@jainankitk fyi, @msfroh @dblock please take a look folks (just a revert)

@reta - Thank you for this PR. Can you also include the repro as test case for identifying this going forward?

@jainankitk Do you see a fix that avoids the revert and fixes the issue?

We can include the changes from https://github.com/opensearch-project/OpenSearch/pull/13488 as part of this, or drop this and merge the other PR

Also, do we need to revert ScriptFieldsPhase change as well? I can also raise PR to just revert inner hits change if you want

I am going to revert the change in full and ask for more tests to be added after

I am going to revert the change in full and ask for more tests to be added after

@reta - Can you check #13488 once?

I am going to revert the change in full and ask for more tests to be added after

@reta - Can you check #13488 once?

It sounds like @reta and @msfroh would prefer to merge this PR vs. https://github.com/opensearch-project/OpenSearch/pull/13488, I'll let either of them to make that decision and hit the approve/merge buttons. I don't have a strong opinion other than I'm glad we're adding a test for the regression.


Close the terminal window without closing Bonsai/Gui

In an effort to reduce visual clutter

related to #115
Should speed up GUI launch if Bonsai doesn't need to always close

Resolved by #118


Expo with BDK-RN

Hi. I am trying to make bdk-rn work with expo.
I can't even generate a 12 word mnemonic. 👇🏼
Replication steps:
Note: I am using Node v18.19.0, npm v10.5.0, windows machine

Init expo

npx create-expo-app --template

Choose template: Blank (TypeScript)
"dependencies": {
    "expo": "~50.0.14",
    "expo-status-bar": "~1.11.1",
    "react": "18.2.0",
    "react-native": "0.73.6"
  },

Install bdk-rn

npm i --save bdk-rn

Update App.tsx

import { StatusBar } from "expo-status-bar";
import { StyleSheet, Text, View, Button } from "react-native";
import { Mnemonic } from "bdk-rn";
import { WordCount } from "bdk-rn/lib/lib/enums";
import { useState } from "react";

export default function App() {
  const [mnemonic, setMnemonic] = useState("");

  const handleClick = async () => {
    const mnemonic = await new Mnemonic().create(WordCount.WORDS12);
    setMnemonic(mnemonic.asString());
  };

  return (
    <View style={styles.container}>
      <Text>Open up App.tsx to start working on your app!</Text>
      <Button title="Generate" onPress={handleClick} />
      <Text>Test: {mnemonic}</Text>
      <StatusBar style="auto" />
    </View>
  );
}

...

Run the app

npm start

Use Expo Go to run the app (running on my iPhone 12)

Now I get the following error:
Possible unhandled promise rejection | TypeError: Cannot read property 'generateSeedFromWordCount' of null

cc @BitcoinZavior

There are 2 different workflows used by Expo to run Apps.

Managed workflow: where we can only use services/modules provided by Expo e.g npx expo start
Bare workflow: 3rd party libraries can also be used. “bdk-rn” is 3rd party for expo. e.g npx expo run:ios

bdk-rn just like any other RN module will work with Bare Workflow but not with Managed Workflow


Do we need more C code to handle operators?

static Result post_pos_neg_sign(State *state, bool can_be_operator) {

Fuzzer warns of unused can_be_operator, but the two calling functions do pass t/f in. Does post_pos_neg_sign need to distinguish between symops and numeric literals?

No.


FasterRCNN: 'xxx is not in the models registry'

when I try to create a custom model to replace the backbone of faster rcnn, the error happened.
I follow the tutorial step by step and it's wrong.

I get the reason，when i install the mmdet, i use the
pip install openmim
mim install mmdet

if i need to use custom model, i should install by git files
git clone https://github.com/open-mmlab/mmdetection.git
cd mmdetection
pip install -r requirements/build.txt
pip install -v -e .  # or "python setup.py develop"

I face the same problem, followed the custom installation, it still persists!
"MaskRCNN: 'CBSwinTransformer is not in the models registry'"


Visual of graph breaks when changing from having data to none

https://github.com/wuba/react-native-echarts/assets/45431116/634cb20a-e861-436b-af51-f5c228289acc
  if (TTBikeRef.current) {
      chart = echarts.init(TTBikeRef.current, "light", {
        renderer: "svg",
        width: E_WIDTH * 0.9,
        height: E_HEIGHT * customHeight,
      });
      chart.setOption(option);

My custom height will change depending of how many positions i have. (This happens to solve my legend vertical problem)
The problem is when I change graphs for example from Road to TT if i have data on Road my TT will be weird. See the video to understand it better. Thanks in advance

When there is no data, the Y-axis has no value to display, but we can set the maximum and minimum values to ensure that the y-axis has a value to display. Of course, the maximum value cannot be known, and you can also write a function to handle it, mainly to ensure The legend can be displayed when there is no value. such as this below shown:
 yAxis: {
    type: 'value',
    min:0,
    axisLabel: {
        formatter: '{value}%'
      },
    max: function (value) {
      if(!value.max) return 100;
      return value.max + 30;
    },
},

I don’t know if this can solve your problem, you can try it

Thanks for the response I will check it out. I do not want to show either the y-axis or the legend when I have no data.

Thanks for the response I will check it out. I do not want to show either the y-axis or the legend when I have no data.

I misunderstood. I thought you wanted the legend or y-axis to be displayed regardless of whether there is data. If your problem still cannot be solved or you would like us to provide support,  You can describe it in more detail so it's easier to find a suitable solution.

@yechunxi  Thanks you can see whats happening in the video. Probably I will post more of the code in the next few days. Thanks for the response.

  // CHART RELATED
  const RoadBikeRef = useRef<any>(null);
  useEffect(() => {
    const ROAD_BIKE_OPTIONS = {
      title: {
        show: chartSeries.length === 0,
        textStyle: {
          color: "#F7F3F0",
          fontSize: 20,
        },
        text: "No data available",
        left: "center",
        top: "20%",
      },
      grid: {
        right: "2%",
        // y2: 300,
        height: E_HEIGHT * 0.35,
      },
      tooltip: {
        show: chartSeries.length !== 0,
        trigger: "axis",
        textStyle: {
          color: "#F7F3F0",
        },
        backgroundColor: "rgba(61, 52, 62, 0.9)",
        valueFormatter: function (val) {
          return `${val} %`;
        },
        confine: true,
      },
      legend: {
        data: chartSeries.map((series) => series.name),
        icon: "circle",
        inactiveColor: "#64605D",
        textStyle: {
          color: "#F7F3F0",
        },
        orient: "vertical",
        bottom: 0,
        left: 0,
        // top: "bottom",
        // top: -20,
        //Paei to legend apo kato. Iparxi overlap provlima (na to kitakso)
      },
      xAxis: {
        type: "category",
        data:
          currentPeriod === "4 Weeks"
            ? Object.keys(week_buckets).reduce((arr, key) => {
                return arr.concat(key, "", "", "", "", "", "");
              }, [])
            : categories,

        axisLabel: {
          interval: 0,
        },
        axisTick: {
          alignWithLabel: true,
        },
      },
      yAxis: {
        type: "value",
        min: 0,
        axisLabel: {
          formatter: (val) => Math.ceil(val) + "%",
        },
      },
      series: chartSeries.map((series) => ({
        name: series.name,
        type: "line",
        smooth: true,
        data: series.data,
        symbol: "circle",
        lineStyle: {
          type: series.name.includes("Not") ? "dashed" : "solid",
        },
      })),
    };
    let chart: any;
    if (RoadBikeRef.current) {
      chart = echarts.init(RoadBikeRef.current, "light", {
        renderer: "svg",
        width: E_WIDTH * 0.9,
        height: E_HEIGHT * customHeight,
      });
      chart.setOption(ROAD_BIKE_OPTIONS);
    }
    return () => chart?.dispose();
  }, [chartSeries]);

I have one more when changing to TT bike. So whats happening if I have data on my chartSeries road_bike
and I change to TT_bike where my chartSeries and graph will be recalculated and I have no data. My first graph is looking like its compressed.

Any updates about this one? Currently the only problem we are having with our mobile graphs.

Bump. Any news? We are almost in time for publishing our app and graphs are one of the main parts.

I have not reproduced this problem. Can you provide a demo of the reproduction? I see that the x-axis of the chart in your code is variable, but it is not included in the useEffect dependency.

Sure I will try to create the reproduction later.

Unfortunately, I tried to create a reproduction but is so hard because we are using some custom functions, etc. I will try to explain it as well as possible.
In the first screenshot, I'm using the data that is coming from my chartSeries. As you can see everything is perfect.

Now I will press my button to change the dates. As you can see my chartSeries is an empty array as expected. Showing that no data is available. The only problem looks like it is smashed. Now I will press one more time my button to go to the next month

Here is the last time I pressed the button. ChartSeries is an empty array again as expected. As you can see in my final screenshot this is how no data available should be.

So what I found is when I change from having data to none the first time looks like smashed.
Hope I explained it well. I'm sorry for not being able to create a reproduction.
X-axis has no problem. Doesn't need to be included in my dependency.

After some debugging I found the problem is happening because of the chart height
As you see in my code above for my height im using my device height multiply by a custom height
  const customHeight: number = useMemo(() => {
    return bikePositions.length === 0
      ? 0.5
      : 0.5 + bikePositions.length * 0.023;
  }, [bikePositions]);

So if my custom height is 0.6(when I have data) and goes 0.5(zero data) we can see the smashed chart.

Now that you have found the cause of the problem, you can deal with the chart height issue according to the business, so I will close this issue

I'm sorry I will comment once again. I followed the doc adaptive-size(seems new guide)
I added a state first
  const [customHeight, setCustomHeight] = useState<number>(0);

Then I created a useEffect that updates that state based on my bikePositions
  useEffect(() => {
    const newHeight =
      bikePositions.length === 0
        ? 0.5 * E_HEIGHT
        : (0.5 + bikePositions.length * 0.023) * E_HEIGHT;
    setCustomHeight(newHeight);
  }, [bikePositions]);

Lastly I added an extra useRef to resize my graph
  useEffect(() => {
  chartRef.current.resize({
    width: E_WIDTH * 0.9,
    height: customHeight,
  });
}, [customHeight]);

The only problem I have (video below) is the flickering (probably double render). Probably Any tips? Sorry for commening once again. Thanks for the help in Advance.
https://github.com/wuba/react-native-echarts/assets/45431116/06a30dff-ab74-4484-a5a3-cf98850344bd


Failed to upload movie_id to compose-review-service

Hello,
I have been using DeathStarBench/mediaMicroservices for my research project. I have set up the application on Kubernetes using k8s-YAML files (thanks for providing that), along with Istio sidecar injection enabled (because I am working on traffic routing rules in between service versions).
When I first boot all the pods, everything seems working, however, after a while (continuously performing compose-review workload for a couple of hours), my pods (unique-id-service, movie-id-service, text-service, and user-service) all start to get the same error: "Failed to upload movie_id to compose-review-service".
Example log from "user-service":
TSocket::write_partial() send() <Host: compose-review-service Port: 9090>: Broken pipe
error: (UserHandler.h:502:UploadUserWithUsername) Failed to upload movie_id to compose-review-service
Can you help me with this?
Best!

same here

A wild guess: The continuous 'broken pipe' is because the failed connections are always pushed back to the connection pool. I think a failed connection should be abandoned and a new connection should be created.

I checked the latest code and found it is already fixed in commit 45b9e51b8dcd4016502dfaa4b7af866f941fd8dd in Apr 17.

A wild guess: The continuous 'broken pipe' is because the failed connections are always pushed back to the connection pool. I think a failed connection should be abandoned and a new connection should be created.

I checked the latest code and found it is already fixed in commit 45b9e51 in Apr 17.

Well, it is wired that the latest version of MediaMicroservices still pushes back failed connections.


Should return the original error in the callback function

If we do this as a 3rd parameter it should be a non-breaking change. This was requested by a customer.

Fixed in #15


Removed classmethod from scraper clases

Classmethod was causing issues since those methods were tied to instance,  so it can't be used there.

There is one of these instances where self is used inside the method body but the other instances look OK to me without this modification.


:sparkles: Allow restricting namespace for the controller manager

What this PR does / why we need it:
Adds support to restrict the controller manager to just reconciling a single namespace instead of all namespaces
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #228

/assign @ncdc @chuckha


[Rewrite] commands should be compatible with sublime text

Currently suplemon has lots of command similar to sublime, except that the naming is different.
For example we have 'close_file' and sublime has 'close'.

This will probably be part of the #161 overhaul.

external consistency is a great argument from a UX perspective for this design choice.

Closing for cleanup, will be looked at during the rewrite.


Environment variable override to request building the C dependency as part of the crate for crates that support this

METADEPS_${DEPENDENCY_NAME}_BUILD_INTERNAL or similar. This would have to come with a hook in build.rs or so, so that metadeps can a) error out if not supported by the crate, b) call into crate specific code for actually building.
The crate specific code then has to provide CFLAGS, LIBS, LDFLAGS etc back to metadeps.
As part of this it would also be useful to make it an error if two crates in the dependency chain build the same library.

Do you know a crate doing this "properly" (or at least not too badly) which could be a good starting point to implement this feature?

dav1d

That's the one I was looking. Just submit https://github.com/rust-av/dav1d-rs/pull/31 :)

There's also https://github.com/rust-av/dav1d-rs/issues/26, which is loosely relevant here

From this thread it was suggested to have a {auto,always,never} switch.
So I guess we'd want  METADEPS_${DEPENDENCY_NAME}_BUILD_INTERNAL={auto,always,never}?
Not sure about the default, auto makes things more convenient but one may accidentally end up statically linking because her installed version is older for example.
Currently internal build is usually gated with an explicit feature so maybe never would make more sense as default.

I agree about the default, yes. never

Here is what I have so far:
    pub fn add_build_internal<F>(&mut self, name: &str, func: F) -> &mut Self
    where
        F: 'static + FnOnce(&str) -> Library,

It works but the closure could fail so should return a Result. I'm not sure about the error type I should use. I tried Result<Library, dyn error::Error> but got a Sized error:
error[E0277]: the size for values of type `(dyn std::error::Error + 'static)` cannot be known at compilation time
  --> src/lib.rs:67:5
   |
67 |     build_internals: HashMap<String, Box<dyn FnOnce() -> std::result::Result<Library, dyn error::Error>>>,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
   |
   = help: the trait `std::marker::Sized` is not implemented for `(dyn std::error::Error + 'static)`
   = note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
   = note: required by `std::result::Result`

How would you handle that?

Box<dyn Error> would work, for example. But what do you want to do with that value? You probably want a small enum with a couple of variants for how things could possibly fails plus a string to print details.

I was wondering if we should allow users to report any Error or limit ourself with a few enum variants. I don't have much experience in this kind of API design, so I'll go with the latter if you think that's best. :)

The question is how you would handle arbitrary errors :) It's you calling the callbacks so you need to do something with the results.
In addition to the enum it would make sense to also add a slot in each value for passing a "source": https://doc.rust-lang.org/nightly/std/error/trait.Error.html#method.source
There users of the API could return their own things as needed.

What would be the type of the source then? I tried Box<dyn std::error::Error> but got this failure:
error[E0277]: `(dyn std::error::Error + 'static)` cannot be sent between threads safely
  --> src/lib.rs:40:1
   |
40 | / error_chain! {
41 | |     foreign_links {
42 | |         PkgConfig(pkg_config::Error) #[doc="pkg-config error"];
43 | |         BuildInternalClosureError(BuildInternalClosureError) #[doc="build internal closure failure"];
...  |
74 | |     }
75 | | }
   | |_^ `(dyn std::error::Error + 'static)` cannot be sent between threads safely
   |
   = help: the trait `std::marker::Send` is not implemented for `(dyn std::error::Error + 'static)`
   = note: required because of the requirements on the impl of `std::marker::Send` for `std::ptr::Unique<(dyn std::error::Error + 'static)>`
   = note: required because it appears within the type `std::boxed::Box<(dyn std::error::Error + 'static)>`
   = note: required because it appears within the type `BuildInternalClosureError`
   = note: required because it appears within the type `ErrorKind`
   = note: required because it appears within the type `Error`
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

Full code is here: https://github.com/gdesmott/metadeps/commits/build

I think I'm mostly done with this feature: https://github.com/gdesmott/metadeps/commits/build
Here is how it looks like in dav1d: https://github.com/gdesmott/dav1d-rs/commit/fddf79205c0343ef9970c00149afd9d75f953eab
@sdroege : can you please give it a look and tell me what you think of the API?
I'll open proper MRs when upstreaming (or when I'll create a fork if it goes to that).

Commented on the commit :) Generally looks nice to me.

Please consider also having a METADEPS_BUILD_INTERNAL={auto,always,never} or METADEPS_BUILD_INTERNAL=all:{auto,always,never} if the idea of having 1 single env var is still on the plate. The current experience with ssh2-rs clashing with libgit/curl on the tls impl makes me want to have a simple way to override all the behavior w/out having to deal with figuring out the right dependency needing to use pkg-config or do a local build.

Thanks for the suggestion @lu-zero .
I just added support for SYSTEM_DEPS_BUILD_INTERNAL env variable doing exactly that. It's part of the 1.3.0 release.

Thank you :)


Wrong error message from scipy.linalg.lapack.dgtsv

scipy.linalg.lapack.dgtsv gives the error:
error: failed in converting 1st argument `dl' of _flapack.dgtsv to C/Fortran array
When the array is the wrong length.
Code to reproduce:
>>>from scipy.linalg.lapack import dgtsv
>>>dgtsv(np.array([1,2,3,4]), np.array([1,2,3,4]), np.array([1,2,3]), np.array([1,2,3,4]))
error: ....

>>>dgtsv(np.array([1,2,3]), np.array([1,2,3,4]), np.array([1,2,3]), np.array([1,2,3,4]))

works fine

Hi @mikeWShef Lapack errors are generic and handled by f2py module of NumPy hence there won't be a custom explanation for the errors other than which argument has triggered the error.
Here we should have added a better argument checker that would print a slightly less ugly message but didn't. If you wish to add a PR is more than welcome otherwise I'll mark as good first issue to attract potential contributors.

It seemed like a simple problem and I tried to have a look at the code but couldn't even find where the function is defined, I clearly have a lot to learn about wrapping fortran code. If you can point me in the right direction I will have a try.

It is divided into a couple of files but this one lives in
https://github.com/scipy/scipy/blob/master/scipy/linalg/flapack_gen_tri.pyf.src
But normally the checks are done like this
https://github.com/scipy/scipy/blob/8dba340293fe20e62e173bdf2c10ae208286692f/scipy/linalg/fblas_l2.pyf.src#L383-L411
You don't need to learn all the stuff regarding Fortran wrappers but you can try yourself what would be a nice check.

scipy 1.4.1 gives the following error:
ValueError: 0-th dimension must be fixed to 3 but got 4

which is OK.

Is this still relevant or is the error message above sufficient?

The error message for several versions has been:
ValueError: _flapack._flapack.dgtsv: failed to create array from the 1st argument `dl` -- 0-th dimension must be fixed to 3 but got 4

The correct size of each array is determined from the second argument, d. In this case, d has four elements, and according to the documentation, dl needs one less. So the error message seems accurate.


Fill area between the lanes is added

Hi @Anujg935 , area between the lanes is detected and filled with color. Please review my PR

@bharath-acchu  great work 👍


Fixed the name attribute of file tag when using checkstyle format and no cache

Closes #6097

Any maintainer wishes to have a look at this?

pls target master branch instead, 2.19 is no longer maintained

@keradus
Something went wrong with a merge. Please close this PR. I will make a brand new one.


Fetching in-app messages from server failed.

Re: in-app messages. What does it mean when it logs Fetching in-app messages from server failed.? I was unable to receive in-app messages in my app.

Hi @coyksdev please share us some logs. It is probably some missing setup on your project. Please ask support directly for more informations. Thank you


Windows Store link in repo README is broken

Brief description of your issue
It results in a 404. One has to manually search for winget in the store itself, however it is not immediately obvious that App Installer and winget are the same thing. The description in the store should also make that clearer.

I don't see any problems. The title is clearly written.

Microsoft Store [Recommended]
The client is distributed within the App Installer package.

The msixbundle is also named Microsoft. DesktopAppInstaller

It must have been a temporary hiccup yesterday. It is now working for me as well. Sorry for the noise on the issue tracker. Closing.


fix fwjr error string

fixes #8056

Not sure about Python3 compatibility

@amaltaro, @ericvaandering, Please review

test this please

@ticoann hold on this fix for a little while. I'll try to fix it tomorrow in a way that's py3 compatible. If I fail, then we merge it for the next agent later this week :)

replaced by #8295


Additional Standard Questions and ReCaptcha V3 feature.

Critical Changes
Changes

Updated to Salesforce API 61.1 (Summer 24)
Added to google tag manager data layer 'event' : 'summit_' + page type
Added the ability to use Google reCaptcha v3
Added new standard question to ask about dietary restrictions
Added new standard question to ask about accessibility needs for the event
Updated look of apex messages on top of visualforce pages

Issues Closed

Closes #556
Closes #527

Review Guideline (Ryan)

Walk through of testing process, issues reviewed and identifying any other potential bugs as part of a package or general Pull Request.

Issues to Review

#556
#527

Testing Path
Key:

✅ = completed without issue or as expected)
🟡 = Met expectations, but potential issues
⛔ = Failed testing or met with issues causing missed expectations. Explanation provided)

Testing with Beta Package Install - 8/29
✅ New Scratch Org WITHOUT Summit Events Installed
✅ Installed Summit Events (throw away package provided by Thad of .34 (Beta 1))
✅ Configured Summit Events per the instructions on the Document Page
✅ Standard Event Creation works - Simple Event, Single Instance, Registration processed and captured in Salesforce
✅ Additional Standard Fields testing

Page Layout has standard fields present and aligned to other standard fields
When selected, they appear on the page.
When registered together, both information captured on the Registration
Independently tested Dietary restrictions, all functions work as expected
Accessibility tested and all functions work as expected.  Ask and Require does require the Yes/No answer, if Yes, the additional text box is required, which is what I expected to happen
Works just like other fields as part of the Standard fields in Registration!

✅ reCaptcha Testing

Fields appropriate appear on the page layout
Selected option and while the error appears on the registration page it does NOT stop the individual from registering, which is what I expected and would want

This is being tested as a Managed Package

Setup reCaptcha - worth noting

There is a limitation as to how many assessments can happen per month

While it is likely that organizations already have something in place, this is dependent on Google. Will be worth asking their marketing teams if there is a google reCaptcha they can leverage already.
Organizations will want to make an assessment as to how much traffic they get for just registration

Didn't fully configure and got a meaningful error message.

Setup Remote site settings, with relative ease

item to note - we will need to identify in documentation if someone can use something of their own. I don't believe that's the case as there are items within the code to support google, but @tcdahlberg you may want to identify what's possible if they don't use google as a campus/organization.

Set the Score at a 1 (MOST RESTRICTIVE) - and met with error
Set the Score at a 2 - met with error, which is expected as the notes and help text say between 0-1, but wanted to test something higher than 1.

Set the Score at 0.9 (More Restrictive) - and was able to register in a normal browser.
Set the Score at 0.9 (More Restrictive) - and was able to register in am incognito browser.

NOTE: In documentation, we will want to articulate that a .5 may be a good starting point.  The higher the score of a registration, the least suspect it is.  Setting the Score at 1 will block MORE people from registering as 0.9 is a relatively safe number.  There is a "Risky Definition" score. Anything lower the the defined score in Summit Events is defined as RISKY.  Anything higher than the defined score is considered safe.  So setting at a 0.9, means you want to be really suspicious of who's entering data into the registration field. Many people will come in at a 0.9.  Setting it at a .5 means you want to be somewhat suspicious, but not overally suspicious.  Setting is at 0.1 means you want to be open to most things and only the nastiest of bots can't register. @tcdahlberg We may want to update the help text in Custom Settings, assuming what I mentioned here is accurate, to say the following "Score is the Risk Definition. Ranging from 0-1, Zero is the least restrictive, 1 is the most restrictive. Suggested to start at 0.5"  Then on the "reCAPTCHA Score" on the Event Registration, in the Help Text and Description, say "If Google reCAPTCHA is used for the event this is the score that was returned for the registrant. Scores higher than the Risk Definition defined in Custom Settings are considered the least suspicious."

All thing worked as expected per the video as well as the information provided in the PR.
@tcdahlberg can you review my comments on the help text?  Some will have to be captured in documentation, but thinking help text can support the understanding of the reCaptcha scoring.

@rdblake21, great work testing and documenting testing as usual!
For the help text on the score field in custom setting I changed it to:

This score is the Risk Definition. It ranges from 0-1 with zero being the least restrictive. A value of 1 is the most restrictive. A suggested starting value at 0.5 is recommended.

I just made it into a more complete sentence (which is probably not super necessary).
I changed the help text on the registration object to the help text you recommended:

If Google reCAPTCHA is used for the event this is the score that was returned for the registrant. Scores higher than the Risk Definition defined in Custom Settings are considered the least suspicious.

Thanks!


Code for the offline datasets generation

Hi! Very cool benchmark! Is it possible to publish the code with which the datasets were generated? I am very interested in testing my ideas about memory in Offline RL setup. However, for a complete benchmark (e.g. for a paper), I would like to have datasets for both 11x11 and 13x13 mazes too.

Hi, thanks for interest! Unfortunately the code to generate datasets is not available, but if you are working on a related research project, I would be happy to chat and give some tips. Just drop me an email (it's in the paper).


Show text "Custom" if a dependency uses a custom license

This will avoid misunderstandings, someone might think that some dependency doesn't have a license at all.
Before:

After:

If we take a closer look at for example @splinetool/react-spline, they actually do not have a license. So 'custom' would be wrong.

We can merge this. But as @Chicken noted, it is indeed not always correct.
A minuscule problem.

That seems to be a bug with license-checker. Running license-checker --json > dependency-licenses.json generates custom licenses for both:

That seems to be a bug with license-checker. Running license-checker --json > dependency-licenses.json generates custom licenses for both:

Yep, it seemingly pulls those URLs from the README.md documentations of those dependencies. 😄

Oh I didn't mean to close this, skill issue with git...