go-micro become too unstable to be used in production

My question,
go-micro is a great project, it has saved me and our tiny team quite a lot time.
But we come across some serial problems recently,

go-micro version changed too frequent
go-micro website changed too frequent
go-micro plugin and docs are not so up to date

go-micro v4 can't not be install with simple refer to docs.
just like this one: https://github.com/asim/go-micro/issues/2344 has bugged a lot people.
I just updated my project from v2 to v4, and I have been blocked by this problem too.
I have to dig into code, docs, and a lot things to figure it out.
I am not here to complain or point out that I shouldn't do that.
I just want to say, if, the project has these things

not so clearify docs
not so stable versions
hard to install and use (not very simple if I could say)

I think the project will loose quite a lot users, and potential mantainers.
Which could affect vitality for such a great opensource project.
Again, go-micro is still a great project.
Wonderful job

I moved on from go-micro a long time ago. I appreciate you want support, docs, further maintenance but literally no one is being paid to do that. So my advice would be, find a library that's well supported. Go Micro was started 7 years ago. New libraries are coming out with fresh devs and new ideas that are better in the long term.

Yes, I know the history about go-micro, go-nitro and m3o version change history.
I understand this now.

Or we can all start to contribute more via either issues or PR and help the maintain the project, since we all love it. I think that’s exactly the point for an open source project. Great job! @everyone

I get the idea,
so, what are the priorities right now?

do we have a leader or leaders for this prj, who can decide which should be attended to first
does this prj has some sort of donation still, so there could be more attenders be drawed to
what's the roadmap for this prj

This is a personal project I built many years ago. Right now I'm still the owner of it. The years of work are mine along with those who contributed something along the way. There's no roadmap and no form of donations. I have done both of these in the past and wasted significant amount of effort to earn very little for my work. This project will not go that route again.
My honest advice. Use something else.  The number of projects is endless. Please don't push your agenda here to try to make this more than what it is. The owner of the project is quite literally telling you to use something else. That should be indication enough that this is just a project that sits on GitHub and nothing more.

Thanks for your valuable time and patient answer.
Maybe it worth nothing, but this project is quite a beatiful and elegant work, I respect that.
Best wishes

Thank you for your kind words. I know that you mean well and many others do too. Open source is just difficult for solo maintainers. While others could contribute more, no one ends up doing it full time.
At this point it's easier to just let go and have minor fixes.


Update Composer dependencies (2021-07-21-00-04)

Visual regression test passed!
View the visual regression test report


Identify ownership of vocabulary code types

As a first step in reviewiewing the ICES reference lists, creating an overview of ownership of the different vocabularies.

linked to https://github.com/ices-eg/DIG/issues/278


ValueX type parameter

Summary
An optional type parameter has been added to the valueX() snippet. The valueCodeableConcept() snippet has also been removed and integrated with the valueX snippet.
New behavior
The valueX() function will now default to using the type parameter to determine the return type when this parameter is included. If the type parameter is not included; or is included and the specified type is not recognized, the old inferential approach is used. Also, the separate valueCodeableConcept snippet has been removed in favor of including 'valueCodeableConcept' as a parameter in the base valueX snippet.
Code changes

type was added as an optional parameter to the valueX() snippet. A valueByType() helper function has also been introduced, returning the appropriate value[x] element based on the type parameter rather than the value parameter. This new helper function returns null if the type parameter is recognizable.
'valueCodeableConcept' has been added as a supported type to the valueX() snippet. Consequently, the valueCodeableConcept() snippet and all of it's references have been removed throughout the codebase and replaced with valueX() references with a 'valueCodeableConcept' argument.

Testing guidance
Ensure that all tests pass from MEF, also ensure that all bundles still validate when run from the base icare extraction client. Happy Testing!

This looks good! I had one minor comment inline. However, I'm also wondering if there is a way to simplify the valueByType and valueX functions. I noticed there are a few block that are reused, like the block for a valueQuantity when it is a string and the block when valueQuantity is an object. I noticed that at least that second case, valueQuantity when it is an object, is different in the two functions. Is there a reason for that? If not, I'm worried we might have similar cases that would happen in the future and I'm wondering if there's a better way to reuse the different values we want to return. That might require some refactoring and I'm not 100% how it should work or if it would be worth it, so I'm curious to see what you think, and I'm happy to discuss an approach.

So there's actually no good reason for valueQuantity being different in the two functions, I had just added the getQuantityUnit() call in the valueX() function but forgot to do the same in the valueByType() function. This, I think, is indicative of a problem. The good news is that there's definitely a way to refactor this so that two functions aren't needed at all so I'll go ahead and consolidate them!

This will also need a rebase, since the validation tests have been merged in!


Add unit/integration testing

Add unit/integration testing using a standard framework compatible with React (such as jest).

@guzman-raphael I think I can start with writing the test cases and try to get familiar with the project. May I be assigned to this issue?

@ChihweiLHBird Awesome, thanks for the help. :handshake: You are now assigned.

@ChihweiLHBird I see you've signed up with an account with DataJointIO which provides access to our tutorial database (tutorial-db.datajoint.io) using the same username/password. If so, you can use these details to login using datajoint-labbook to help you develop your tests. I've shared with you a simplistic contributor_company schema which should be sufficient to minimally test most merged features (below is a diagram of the pipeline). Have a look in the Table Information to understand the relationship between the tables.

First tests added in #130. Integrated into CI in #140.


cowsql: 0.15.2 -> 1.15.3

Description of changes
tag v0.15.2 seems to have vanished and replaced by v1.15.3. Let's use commit refs instead of tags here.
The archive hash is exactly the same.
Failing hydra build: https://hydra.nixos.org/build/238289174/nixlog/5
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

I would rather continue to use tags. It's a shame they deleted one tag, but one deletion does not equate a pattern.

That's fair. I can switch to the currently available tag then


How to get the Submission.csv

On the detection stage, after training and testing the detector, i have got the series_lbb.npy and the series_pbb.npy. I want to ask how can i change the pbb.npy to the Submission.csv?

I think you can run https://github.com/wentaozhu/DeepLung/blob/master/evaluationScript/frocwrtdetpepchluna16.py


Use Docker 1.10 in CircleCI

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "circle2" git@github.com:chungers/infrakit.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842353726704
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.


changed host address to localhost

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
http://guh.guru:8080/job/guh-webinterface-pull-request/9/
Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
http://guh.guru:8080/job/guh-webinterface-pull-request/10/
Test PASSed.


video_to_video plumbing

Is the pipeline 'video-to-video' ? I have been calling it 'live-video-to-video' - see https://github.com/livepeer/go-livepeer/pull/3210
Can the main branch be main? Easier to track and keep up to date, and it seems there is a lot of stuff in the feature/live-ai that we do not need

Fixed docker paths in https://github.com/livepeer/ai-worker/pull/233/commits/b302de95022a14aa586a26c3586e283465185490 @emranemran - the commit showed up as you since it was from your machine

I like the flattening of app/python/infer into app/infer. Everything in this repo involves inference though... how about app/live since that describes the use case?

I like the flattening of app/python/infer into app/infer. Everything in this repo involves inference though... how about app/live since that describes the use case?

I think it's a good idea. Let me rename it


Add Jobs API

Describe the feature/proposal
New APIs available for the jobs api:
https://github.com/cicoyle/dapr/blob/5c382fe60f05b92d185d3a4c8c65298eb6a10226/dapr/proto/runtime/v1/dapr.proto
This is ready to be picked up.
Context: https://github.com/dapr/dapr/issues/7246
Release Note

RELEASE NOTE:

I updated the title to be jobs api for consistency :)

I updated the title to be jobs api for consistency :)

👌
This issue is being closed as completed #196


[Bug]:issue with redis vector store index?

Bug Description
set_global_service_context(service_context = service_context)
vector_store=RedisVectorStore(index_name=folderpath[i],index_prefix="llama_index",redis_url=configdata["REDIS_URL"],overwrite=False)
loaded_index = VectorStoreIndex.from_vector_store(vector_store,service_context=service_context)
query_engine = loaded_index.as_query_engine(similarity_top_k= 3,streaming=True)
response = query_engine.query(input_txt)
https://gpt-index.readthedocs.io/en/latest/examples/vector_stores/RedisIndexDemo.html
Version
0.8.44
Steps to Reproduce
Retriever = loading_index.as_retriever()
Retriever.retrieve(input_txt)
Relevant Logs/Tracbacks
No response

What is the issue you are having?

Exception Details : Exception occured in single document query in redis. details :Property vector_score not loaded nor in schema

Thank you so much for the support with the above snippet.
Now i have a query that what is is meant by vector_score exactly and do we have any specific or default value for that Vector_Score parameter while loading or extracting  the data to the redis?


Add support for visualizing PIL images in list columns

Codecov Report

Merging #154 (dfb1156) into dev (03715a7) will decrease coverage by 0.41%.
The diff coverage is 28.57%.

@@            Coverage Diff             @@
##              dev     #154      +/-   ##
==========================================
- Coverage   84.87%   84.46%   -0.42%
==========================================
  Files          45       45
  Lines        2804     2825      +21
  Branches      493      495       +2
==========================================
+ Hits         2380     2386       +6
- Misses        320      335      +15
  Partials      104      104

Flag
Coverage Δ

unittests
84.46% <28.57%> (-0.42%)
:arrow_down:

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

Impacted Files
Coverage Δ

meerkat/columns/list_column.py
58.92% <28.57%> (-18.22%)
:arrow_down:

Continue to review full report at Codecov.

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


Automatically lint documentation examples

Right now there is nothing to enforce that documentation examples are actually valid Smithy models. While somebody might run an example through validation when they initially commit it, things can skew over time. Case in point: #295. Ideally we should have a linter, run by CI, that extracts all those examples and runs them through validation. It should also find examples that have IDL and AST formats side by side and assert that they're equal.
There is a minor downside here in that examples will need to be a little more verbose. Right now we exclude parts that don't matter for the purpose of the example, but that often results in something that isn't a valid model by itself.
This might be a bit tricky to implement depending on the availability of a good Java rst parser.

This might be a bit tricky to implement depending on the availability of a good Java rst parser.

A Sphinx extension would be a more idiomatically correct way to do this. Sphinx's included doctest extension is a good starting place. Writing Sphinx Extensions will give context.
I realize it's Python and y'all are a Java shop, but... ❤


[Release] sdk/resourcemanager/keyvault/armkeyvault/1.0.0

/azp run

/azp run go - armkeyvault - ci


Transpilation pain and compatibility

We need work around the way iter-tools is packaged, and of course discuss compatibility.
I think is reasonable having these class of environments supported:

old browsers: IE11 (I know it is a pain but for many people lacking of IE11 support is a show stopper)
current/green browsers (no async iter)
future browsers
node 8
node 10
future node

I can the issue better with a table:

ES2015*
Iterator
Async Iterator

Node 8
X
V
X

Node 10
X**
V
V

Future Node
V
V
V

IE11
V
X
X

Current browsers
V
V
X

Future Browsers
V
V
V

* native or through webpack/rollup
** need to use a flag so It is unlikely will be used on production that way
We can sum up like this:

no transpilation: future node and browsers
transpile only  ES2015: node 10
transpile ES2015, async-iter: node 8
transpile async-iter: current browsers
transpile async-iter, and iter (ES5): IE11

:sob:
What's your view? @conartist6

I have realised there is also the case of a library that uses iter-tools as a dependency.
What should they use?
This is what I would expect:
browser and node future: untranspiled version
node 8/10: require version
But what about async iter compatibility and node. Is there any point in including async iterables where they are no supported by the environment (streams don't expose async iterables in node 8, for example).
double :sob:

Here's a proposal:
Splitting the package in 2:

iter-tools
async-iter-tools

and only taking care of transpiling es2015 imports.
Notifying in the readme that they require transpilation where iterators or async iterators are not supported.

First I love the idea that everyone gets exactly the code that they know how to run, but that doesn't exist yet. Right now the status quo is that package authors transpile down to es5 language features.
The only place that a split is actually starting to form is with .mjs files, where the benefits of not transpiling imports/exports are substantial for static analysis, and there is a reasonable mechanism for the support haves and have nots to choose the correct file based on whether they know how to parse it. Note though that in many cases the expectation is still that other than import/export the files will be using only es5 features. Presently (and still in my diff) these people become second-class citizens by being forced to use the commonjs files which cannot easily be statically analyzed, and are forced to use different paths (/es5). This group is almost certainly the most major constituency, so sacrifices like that seem ill advised.
The use case for this library is still a little unique though since it's meant for use with iterators and generators and there's a category of people who are leveraging these features in their non-library code particularly because they know that the support landscape for it meets their needs.
I think the split should be between, say, iter-tools, and iter-tools-es, where both versions export both .js and .mjs modules, but iter-tools compiles everything else down to es2015 and is recommended for use by library authors, and iter-tools-es transpiles only transpiles async iterators. When the support landscape fo async iterators becomes broad enough you can do a major version bump on iter-tools-es and drop the transpilation step. You can merge iter-tools-es back into iter-tools (and deprecate the -es package) as soon as anyone has any idea how to manage an ecosystem that has a target of anything other than es5 syntax.

The good news is that if you want to publish two packages it's quite easy to do in my diff.

What about this:
Let's keep a single package and single index.js containing sync and async functions. We transpile in these formats:

transpile
es2015 modules
iterators
async iterators
for

future node/browsers

V

node 10

V

V
node 8

V
V
IE11

V

current browsers

Also I would keep a different folder for every format.
@conartist6 I saw in your PR you have .mjs and .js in the same folder, that might be confusing for library consumers.

Or even:

transpile
es2015 modules
async iterators
iterators
for

future node/browsers

V

node 10/current browsers with browserify

V
V

node 8/current browsers with browserify

V
V
V
IE11 with browserify

V

current browsers with webpack/rollup

V
V
IE11 with webpack/rollup

I prepared and experiment to check how does import work.
main package
package.json
{
  "name": "testmodule",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "webpack": "^4.9.1",
    "webpack-cli": "^2.1.4"
  }
}

a.mjs
import test from 'test1';
console.log(test);

b.js
const test = require('test1');
console.log(test);

webpack.config.js
const path = require('path');

module.exports = [
  {
    entry: './a.mjs',
    output: {
      filename: 'abundle.js',
    }
  },
  {
    entry: './b.js',
    output: {
      filename: 'bbundle.js',
    }
  },
];

package "test1"
package.json
{
  "name": "test1",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "module": "index.mjs",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

index.js
module.exports = 'commonjs';

index.mjs
export const value = 'es2015';

test using node
I have tested the behaviour of running a.mjs and b.js (a.mjs require node --experimental-modules).
The result is that only the "main" field in package.json is taken into consideration. "module" is ignored.
The behaviour is probably fine giving we don't care about treeshaking while using node.
test using webpack
Things gets really strange here:
"module" is definitely taken into consideration but:

a.mjs import the commonjs module
b.js import the es2015 module

I think the esmodule transition pretty much is confusing. I've got maybe 4 hours into reading various opinions about it and nobody has yet convinced me that there exists any single set of best practices which if followed will eliminate the headaches.
I think publishing 5-6 copies of the code in the same package is significantly worse, and just passes all of the uncertainty straight along to users, who are likely to make incorrect decisions.
I think there are really only two main use cases:

People who need to support all browsers in wide circulation (library authors, commercial sites)
People who eyeball browser compatibility tables and and are willing to natively use what's supported by modern browsers (internal tools devs, next gen experiences, me)

For better or worse a fully transpiled library should work in every environment, so I think that's has to be the baseline way of supporting the first group until IE11's end of life (2025? ugh...).
The second group knows who they are; they will self select into it. That's why I think providing them the means to self-select (e.g. 'iter-tools-es' or 'iter-tools@esnext'?).
For my part I'm building an isomorphic es6 application. I'm doing it in part because I see no movement from the community on moving on from es5 as the standard compilation target, and I intentionally wanted to find the points of friction that were preventing that. Well, I guess I have.

Interesting finding about node --experimental-modules not respecting package.json module field. I suspect that the module bundlers are all configurable in terms of what their order of preference is for file extensions.

So you would go for:
es2015 module -> future browsers
commonjs -> current browsers/node
es5 (commonjs) -> everyone else
With the caveat that everyone that wants the best perf will provide the transpilation from the original e2015 source. is this correct ?

I think it's just a full combination of two factors:
transpiled to es5 vs. transpiled to es6
and
es2015 module vs. commonjs module
I still think the module differences can be handled by publishing .js and .mjs side by side. That leaves only es5 vs. es6, which can safely be addressed without threat to isomorphic users by using a different package name or tag. Users for whom performance is a major concern will use the es6 version and run their code in an environment with es6 support.
By the way, webpack's default configuration for file extensions is: ["", ".webpack.js", ".web.js", ".js", ".json"]. However, create-react-app's default includes .mjs before .js.

My reasoning is: if you do the simplest thing, it should just work. All other concerns, including tree shaking and perf should be secondary. You should be able to get incremental improvements if you know what you're doing, and I think this method allows you to:
If you want tree shaking, use create-react-app (next version which integrates webpack4, should be released soon) or configure your bundler to include .mjs before .js ones.
If you want better perf at the cost of IE11 support, use the -es or @next package.

@conartist6
I think I now understand your point of having .js and .mjs in the same folder.
But for a general adoption is important a better support of current environments. For example we can't treat node 8 as second class citizen.
And I am sure other users can be frustrated if their use case are getting a suboptimal version.
I am quite sold to have:

untranspiled .mjs and .js the root (just like your PR)
es5 compatible .mjs and .js in the es5 folder
es2015 compatible .mjs and .js in the es2015 folder

In the long run es5 and es2015 folder can be dropped.

Ok, great, I think that seems pretty much sensible in terms of what to offer and in what combinations. I hadn't counted in the fully untranspiled copies, but they'll be the smallest files so it won't add much weight.
I still think the root should be the es2015 (safe/universal) and then the folders can be for  semitranspiled (modern) and untranspiled (future).

Give me a heads up before you push v4. I'll submit another PR with the changes we discussed here.

@conartist6 I think the changes are all here:
https://github.com/sithmel/iter-tools/pull/10
I have also updated to babel7 (there was an issue with the transpilation of "asyncExecute").
And some other minor change.

@conartist6 master is now up to date with the latest changes.
I also updated the doc. It will be published soon

@conartist6  One last thing. I have tried to publish with https://github.com/sithmel/iter-tools/blob/master/package.json#L24:
    "dist": "npm run build && copyfiles -f package.json LICENSE README.md dist/ && cd dist && json -I -f package.json -e \"this.main='index.js';this.typings='index.d.ts';this.module='index.mjs'\" && npm publish",

The problem is that, running "npm publish", it runs prepack. Prepack runs "build" and this is not good.
Also I am bit confused on how this can work when using 'npm link'

Eventually I decided to keep it simple.
const takeWhile = require('iter-tools').takeWhile; // ES5 is default
import { takeWhile } from 'iter-tools'; // ES5 is default

const takeWhile = require('iter-tools/es5').takeWhile; // ES5
const takeWhile = require('iter-tools/es5/take-while'); // ES5
import { takeWhile } from 'iter-tools/es5'; // ES5

const takeWhile = require('iter-tools/es2015').takeWhile; // ES2015
const takeWhile = require('iter-tools/es2015/take-while'); // ES2015
import { takeWhile } from 'iter-tools/es2015'; // ES2015

const takeWhile = require('iter-tools/es2018').takeWhile; // ES2018
const takeWhile = require('iter-tools/es2018/take-while'); // ES2018
import { takeWhile } from 'iter-tools/es2018'; // ES2018

Also I found the trick to make node work with the correct version: just not specifying the extension in the "main" field in package.json.
Published as 4.0.1


Switch from a fixed list of disposable domains to dynamic whitelisting/blocking

Having a fixed list of disposable domains that can only be changed by deploying makes it very difficult to respond to attacks in a timely manner. So rather than that use a dynamic approach that logs domains and keeps track of any trending domains and then whitelist/block as appropriate. Any domains that are blocked are silently ignored so that a script can't detect easily when it needs to change to a different domain. It logs and aggregates parent domains to provide a defence agains a revolving subdomain attack - blocking the parent domain will block all the subdomains automatically.

Probably makes sense to move the signature.domain_allowed? check into the email job to get it out of the request/response cycle in the off chance it's an expensive lookup.  It might be good to introduce a "fraud" state to the signature and if signature.domain_allowed? fails in the job we transition the signature - it can also be used as a value to let us find all those signatures later for forensics or de-blocking if we've got it wrong.
Speaking of which, we'll need a script or job to run when an existing domain changes from allowed to blocked or vice-versa.  This would go through signatures that match it and change their states, update counts if they were already validated, actually send the verify email if they were pending.  Perhaps we need fraud-pending and fraud-validated as states to distinguish theses two cases.

Closing this because tracking DNS is a thankless task


Add neutron-ovn service to deploy this agent on EDP Nodes

Depends-On: https://github.com/openstack-k8s-operators/neutron-operator/pull/231
Depends-On: https://github.com/openstack-k8s-operators/edpm-ansible/pull/463
Related-Issue: OSP-26191

/lgtm

dataplane operator image builder / call-build-workflow / operator-index (push)  failing
Wrongly pushed to repo instead of the fork, will recreate PR, closing it and deleting the branch.

Pushed https://github.com/openstack-k8s-operators/dataplane-operator/pull/485


segfault during build of rocFFT on Fedora

What is the expected behavior

build without segfault

What actually happens

segfault during build

How to reproduce

build on Fedora rawhide (39 at the moment) using system packages for the dependencies

Environment

Hardware
description

GPU
Advanced Micro Devices, Inc. [AMD/ATI] Vega 20 [Radeon Pro VII/Radeon Instinct MI50 32GB] (rev 06)

CPU
AMD Ryzen 7 5700X 8-Core Processor

Software
version

ROCK
no binary driver, kernel 6.4.0-0.rc6.20230614gitb6dad5178cea (fedora package)

ROCR
v5.5.0 (fedora package)

HCC
v5.5.1 (fedora package)

Library
v16.2 (fedora package built from fork)

Tagging @Mystro256 as he has worked on packaging many of the dependencies here.
The Issue
Important note: I'm working to package ROCm in Fedora so I'm building upon the bits we already have packaged instead of using AMD's prebuilt packages or building everything in /opt/rocm.
Before I get to the packaging part, I'm just trying to build rocFFT on my local machine. As part of this, I'm doing the following
git checkout release/rocm-rel-5.5
mkdir build
cd build
cmake .. -DCMAKE_CXX_COMPILER=hipcc -DCMAKE_C_COMPILER=hipcc -DSQLITE_USE_SYSTEM_PACKAGE=ON -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug
make -d

The output I get on screen ends with
Reading makefile 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/build.make'...
Reading makefile 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/compiler_depend.make' (search path) (no ~ expansion)...
Reading makefile 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/progress.make' (search path) (no ~ expansion)...
Updating makefiles....
 Considering target file 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/build.make'.
  Looking for an implicit rule for 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/build.make'.
  No implicit rule found for 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/build.make'.
 Finished prerequisites of target file 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/build.make'.
 No need to remake target 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/build.make'.
 Considering target file 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/compiler_depend.make'.
  Looking for an implicit rule for 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/compiler_depend.make'.
  No implicit rule found for 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/compiler_depend.make'.
 Finished prerequisites of target file 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/compiler_depend.make'.
 No need to remake target 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/compiler_depend.make'.
 Considering target file 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/progress.make'.
  Looking for an implicit rule for 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/progress.make'.
  No implicit rule found for 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/progress.make'.
 Finished prerequisites of target file 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/progress.make'.
 No need to remake target 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/progress.make'.
Updating goal targets....
Considering target file 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/build'.
 File 'library/src/CMakeFiles/rocfft_kernel_cache_target.dir/build' does not exist.
 Considering target file 'rocfft_kernel_cache_target'.
  File 'rocfft_kernel_cache_target' does not exist.
  Considering target file 'library/src/CMakeFiles/rocfft_kernel_cache_target'.
   File 'library/src/CMakeFiles/rocfft_kernel_cache_target' does not exist.
   Looking for an implicit rule for 'library/src/CMakeFiles/rocfft_kernel_cache_target'.
   No implicit rule found for 'library/src/CMakeFiles/rocfft_kernel_cache_target'.
   Considering target file 'library/src/rocfft_kernel_cache.db'.
    File 'library/src/rocfft_kernel_cache.db' does not exist.
    Considering target file 'library/src/rocfft_rtc_helper'.
     Looking for an implicit rule for 'library/src/rocfft_rtc_helper'.
     No implicit rule found for 'library/src/rocfft_rtc_helper'.
    Finished prerequisites of target file 'library/src/rocfft_rtc_helper'.
    No need to remake target 'library/src/rocfft_rtc_helper'.
    Considering target file 'library/src/rocfft_aot_helper'.
     Looking for an implicit rule for 'library/src/rocfft_aot_helper'.
     No implicit rule found for 'library/src/rocfft_aot_helper'.
    Finished prerequisites of target file 'library/src/rocfft_aot_helper'.
    No need to remake target 'library/src/rocfft_aot_helper'.
   Finished prerequisites of target file 'library/src/rocfft_kernel_cache.db'.
   Must remake target 'library/src/rocfft_kernel_cache.db'.
library/src/CMakeFiles/rocfft_kernel_cache_target.dir/build.make:73: update target 'library/src/rocfft_kernel_cache.db' due to: target does not exist
/usr/bin/cmake -E cmake_echo_color "--switch=" --blue --bold --progress-dir=/home/tflink/rocm/rocFFT/build/CMakeFiles --progress-num=48 "Compile kernels into shipped cache file"
Putting child 0x55b75d6d6d20 (library/src/rocfft_kernel_cache.db) PID 2800333 on the chain.

Reaping losing child 0x556ff224f9c0 PID 2800332
make[1]: *** [CMakeFiles/Makefile2:455: library/src/CMakeFiles/rocfft_kernel_cache_target.dir/all] Error 2
Removing child 0x556ff224f9c0 PID 2800332 from chain.
Reaping losing child 0x5604d1b40ba0 PID 2795876
make: *** [Makefile:156: all] Error 2
Removing child 0x5604d1b40ba0 PID 2795876 from chain.

Using system gdb (not ROCgdb) to get the backtrace:
Thread 16 "rocfft_aot_help" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe23f16c0 (LWP 2800618)]
0x0000000000000000 in ?? ()
:(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff7de1e7c in amd::Comgr::create_data_set (data_set=<optimized out>, data_set=<optimized out>)
    at /usr/src/debug/rocclr-5.5.1-8.fc39.x86_64/rocclr/cmake/../device/comgrctx.hpp:197
#2  hiprtc::RTCProgram::RTCProgram (this=<optimized out>, name=..., this=<optimized out>, name=...) at /usr/src/debug/rocclr-5.5.1-8.fc39.x86_64/hipamd/src/hiprtc/hiprtcInternal.cpp:38
#3  0x00007ffff7dcd75b in hiprtc::RTCCompileProgram::RTCCompileProgram (name_="rocfft_rtc.cu", this=0x7fffd0245ff0)
    at /usr/src/debug/rocclr-5.5.1-8.fc39.x86_64/hipamd/src/hiprtc/hiprtcInternal.cpp:98
#4  hiprtcCreateProgram (prog=0x7fffe23f05c0,
    src=0x7fffd0135f80 "#define ROCFFT_CALLBACKS_ENABLED\n\n// Copyright (C) 2016 - 2022 Advanced Micro Devices, Inc. All rights reserved.\n//\n// Permission is hereby granted, free of charge, to any person obtaining a copy\n// o"..., name=0x66a385 "rocfft_rtc.cu", numHeaders=0, headers=0x0, headerNames=0x0)
    at /usr/src/debug/rocclr-5.5.1-8.fc39.x86_64/hipamd/src/hiprtc/hiprtc.cpp:86
#5  0x00000000005d9aa0 in compile_inprocess (
    kernel_src="#define ROCFFT_CALLBACKS_ENABLED\n\n// Copyright (C) 2016 - 2022 Advanced Micro Devices, Inc. All rights reserved.\n//\n// Permission is hereby granted, free of charge, to any person obtaining a copy\n// o"..., gpu_arch="gfx906") at /home/tflink/rocm/rocFFT/library/src/rtc_compile.cpp:30
#6  0x000000000041163d in cached_compile (kernel_name="fft_rtc_fwd_len512_sp_op_CI_CI_sbrc_erc_z_xy_aligned_CB", gpu_arch_with_flags="gfx906", generate_src=..., generator_sum=...)
    at /home/tflink/rocm/rocFFT/library/src/rtc_cache.cpp:496
#7  0x000000000040dbe2 in main::{lambda()#1}::operator()() const (this=<optimized out>) at /home/tflink/rocm/rocFFT/library/src/rocfft_aot_helper.cpp:469
#8  std::__invoke_impl<void, main::{lambda()#1}>(std::__invoke_other, main::{lambda()#1}&&) (__f=...)
    at /usr/bin/../lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/bits/invoke.h:61
#9  std::__invoke<main::{lambda()#1}>(main::{lambda()#1}&&) (__fn=...) at /usr/bin/../lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/bits/invoke.h:96
#10 std::thread::_Invoker<std::tuple<main::{lambda()#1}> >::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=<optimized out>)
    at /usr/bin/../lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/bits/std_thread.h:292
#11 std::thread::_Invoker<std::tuple<main::{lambda()#1}> >::operator()() (this=<optimized out>)
    at /usr/bin/../lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/bits/std_thread.h:299
#12 std::thread::_State_impl<std::thread::_Invoker<std::tuple<main::{lambda()#1}> > >::_M_run() (this=0x868030)
    at /usr/bin/../lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/bits/std_thread.h:244
#13 0x00007ffff62e31d3 in std::execute_native_thread_routine (__p=0x868030) at ../../../../../libstdc++-v3/src/c++11/thread.cc:104
#14 0x00007ffff5e8d777 in start_thread (arg=<optimized out>) at pthread_create.c:444
#15 0x00007ffff5f1449c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Hmm.. I'm not super familiar with this component, but it looks like hipRTC is trying to call a null function pointer in libamd_comgr.so.  Is libamd_comgr.so present in the default library search path when this is run?  Is it loaded, according to gdb's info sharedlibrary command when the crash occurs?

libamd_comgr.so is in /usr/lib64 which is part of the default search path on this system
# ll /usr/lib64/libamd_comgr*
lrwxrwxrwx. 1 root root      17 May 24 18:00 /usr/lib64/libamd_comgr.so -> libamd_comgr.so.2
lrwxrwxrwx. 1 root root      21 May 24 18:00 /usr/lib64/libamd_comgr.so.2 -> libamd_comgr.so.2.5.0
-rwxr-xr-x. 1 root root 9484672 May 24 18:00 /usr/lib64/libamd_comgr.so.2.5.0

Is it loaded, according to gdb's info sharedlibrary command when the crash occurs?

:(gdb) info sharedlibrary
From                To                  Syms Read   Shared Object Library
0x00007ffff7fcb000  0x00007ffff7ff0eb5  Yes         /lib64/ld-linux-x86-64.so.2
0x00007ffff7e78970  0x00007ffff7f8207b  Yes         /lib64/libsqlite3.so.0
0x00007ffff7d8c6a0  0x00007ffff7dea598  Yes         /lib64/libhiprtc.so.5
0x00007ffff661e230  0x00007ffff6960468  Yes         /lib64/libamdhip64.so.5
0x00007ffff62a4590  0x00007ffff63c5d22  Yes         /lib64/libstdc++.so.6
0x00007ffff7cb63d0  0x00007ffff7d2a8f8  Yes         /lib64/libm.so.6
0x00007ffff65df6d0  0x00007ffff65f9f75  Yes         /lib64/libgcc_s.so.1
0x00007ffff5e26780  0x00007ffff5f83d8d  Yes         /lib64/libc.so.6
0x00007ffff65c5630  0x00007ffff65d317b  Yes         /lib64/libz.so.1
0x00007ffff540e4d0  0x00007ffff5463f72  Yes         /lib64/libamd_comgr.so.2
0x00007ffff5017070  0x00007ffff50d2ac9  Yes         /lib64/libhsa-runtime64.so.1
0x00007ffff65b7c10  0x00007ffff65bd035  Yes         /lib64/libnuma.so.1
0x00007ffff4c4e090  0x00007ffff4e2056a  Yes         /lib64/liblldELF.so.16
0x00007ffff6591010  0x00007ffff65aa32f  Yes         /lib64/liblldCommon.so.16
0x00007ffff1367510  0x00007ffff3f33417  Yes         /lib64/libclang-cpp.so.16
0x00007fffe9ec0840  0x00007fffed568622  Yes         /lib64/libLLVM-16.so
0x00007ffff6562b10  0x00007ffff6574950  Yes         /lib64/libhsakmt.so.1
0x00007ffff65447b0  0x00007ffff6556495  Yes         /lib64/libelf.so.1
0x00007ffff652eb90  0x00007ffff6539681  Yes         /lib64/libdrm.so.2
0x00007ffff651f5b0  0x00007ffff652514a  Yes         /lib64/libffi.so.8
0x00007ffff64ea8d0  0x00007ffff6509bf4  Yes         /lib64/libedit.so.0
0x00007ffff64ba670  0x00007ffff64cc8a4  Yes         /lib64/libtinfo.so.6
0x00007ffff64a1830  0x00007ffff64a61c1  Yes         /lib64/libdrm_amdgpu.so.1
0x00007ffff6149e40  0x00007ffff61f01f2  Yes         /lib64/libzstd.so.1

@cgmb FYI

@evetsso, if it helps, these are complete steps to reproduce the issue in a docker image:
$ docker run -it --rm --device=/dev/dri --device=/dev/kfd --security-opt seccomp=unconfined fedora:rawhide
dnf upgrade
dnf install rocm-hip-devel rocrand-devel sqlite-devel rocm-comgr-devel hsakmt-devel rocm-runtime-devel git vim cmake lld clang clang-libs clang-resource-filesystem clang-tools-extra llvm gdb
git clone https://github.com/ROCmSoftwarePlatform/rocFFT.git
cd rocFFT
git checkout release/rocm-rel-5.5
mkdir build
cd build
cmake .. -DCMAKE_CXX_COMPILER=hipcc -DCMAKE_C_COMPILER=hipcc -DSQLITE_USE_SYSTEM_PACKAGE=ON -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug
VERBOSE=1 make -j16

You can then get a bit closer to the problem with:
cd /root/rocFFT/build/library/src
gdb -ex r --args ./rocfft_aot_helper "" /root/rocFFT/build/library/src/rocfft_kernel_cache.db /root/rocFFT/build/library/src/rocfft_rtc_helper gfx906

It can also help to install debug packages:
# enable debug repo and install debug libs by changing 'enabled = 0' to `enabled = 1`
vim /etc/yum.repos.d/fedora-rawhide.repo

# install the debug packages
dnf install clang-libs-debuginfo elfutils-libelf-debuginfo glibc-debuginfo hsakmt-debuginfo libdrm-debuginfo libedit-debuginfo libffi-debuginfo libgcc-debuginfo libstdc++-debuginfo libzstd-debuginfo lld-libs-debuginfo llvm-libs-debuginfo numactl-libs-debuginfo rocm-comgr-debuginfo rocm-hip-debuginfo rocm-runtime-debuginfo sqlite-libs-debuginfo zlib-debuginfo ncurses-libs-debuginfo

# fix a missing directory or gdb will complain
mkdir /usr/src/debug/rocclr-5.5.1-9.fc39.x86_64/rocclr/cmake

There's too much that has been optimized out for me to understand what is wrong and I'm not very familiar with hiprtc.

Just as a data point, Debian is using rocFFT from 5.5.1, built with HIP from 5.2.3 and LLVM 15. It has not encountered this problem, so I suspect this might therefore be related to a change in a low-level component like HIP, comgr, or clang.

Interesting.. I just tried @cgmb's repro steps (i.e. with the latest rawhide as of today) and get different behaviour now that ROCm 5.6 has been released:
[100%] Compile default kernels and solution-map kernels into shipped cache file
terminate called after throwing an instance of 'std::runtime_error'
  what():  In file included from <built-in>:1:
In file included from /builddir/build/BUILD/clr-rocm-5.6.0/redhat-linux-build/hipamd/src/hiprtc/hip_rtc_gen/hipRTC_header.h:5:
In file included from /builddir/build/BUILD/clr-rocm-5.6.0/HIP-rocm-5.6.0/include/hip/hip_runtime.h:62:
In file included from /builddir/build/BUILD/clr-rocm-5.6.0/hipamd/include/hip/amd_detail/amd_hip_runtime.h:112:
In file included from /builddir/build/BUILD/clr-rocm-5.6.0/hipamd/include/hip/amd_detail/amd_hip_atomic.h:25:
/builddir/build/BUILD/clr-rocm-5.6.0/hipamd/include/hip/amd_detail/amd_device_functions.h:82:52: error: redefinition of '__ffsll'
__attribute__((device)) static inline unsigned int __ffsll(uint64_t input) {
                                                   ^
/builddir/build/BUILD/clr-rocm-5.6.0/hipamd/include/hip/amd_detail/amd_device_functions.h:70:52: note: previous definition is here
__attribute__((device)) static inline unsigned int __ffsll(unsigned long long int input) {
                                                   ^
1 error generated when compiling for gfx906.

make[2]: *** [library/src/CMakeFiles/rocfft_kernel_cache_target.dir/build.make:74: library/src/rocfft_kernel_cache.db] Aborted (core dumped)
make[1]: *** [CMakeFiles/Makefile2:512: library/src/CMakeFiles/rocfft_kernel_cache_target.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

So hipRTC in ROCm 5.6 is no longer trying to follow a null function pointer at least.  Again, I'm not really familiar with hipRTC, but I also don't see any obvious changes in the clr commit log between ROCm 5.5 and 5.6 that would explain this.
This new error seems to be Fedora-specific, and caused by https://src.fedoraproject.org/rpms/rocclr/blob/rawhide/f/0001-add-uint64_t-variant-for-__ffsll.patch - ideally the reason for that patch has gone away with ROCm 5.6 and it can just be reverted.  But I'm not familiar enough with the original problem to be sure.

Hi @tflink, do you have any update?  Has the behaviour changed for you with ROCm 5.6?

Apologies for the delay, I've been messing with how I get notifications and managed to miss a few from github.
I see the same behavior you do when I build 5.6.0. I started patching out the kernel cache during the build when I learned that's how the debian package is handling the issue.
I rebuilt rocclr to not use the patch you linked to and while the runtime_error goes away, the build just hangs after [100%] Built target rocfft with rocfft_aot_help and rocfft_rtc_help taking up almost all available CPU. I let this sit in that state for about 15 minutes before killing the processes manually under the assumption that it's not going to finish. I think I saw the the same behavior on RHEL 9.2 when I tried to build rocfft using the official AMD repos for the dependencies. I'll attempt to reproduce there to make sure.
If I patch out the kernel cache parts in the same way that the debian patch does, rocfft builds and doesn't hang at the end of the build process.
Is the best way to help you reproduce issues with container images?

Also, I spoke with the author of the uint64 patch you linked to (@trixrt) and as far as we know, it's still needed for blender.

I see the same behavior you do when I build 5.6.0. I started patching out the kernel cache during the build when I learned that's how the debian package is handling the issue.

I do not encounter this issue on Debian. rocfft 5.5.0-1 built successfully and did not include that patch. I only patched it out of the build because I had not yet figured out where the cache should be installed according to Debian policy, and it seemed wasteful to build the cache if it wasn't going to be installed.

I do not encounter this issue on Debian. rocfft 5.5.0-1 built successfully and did not include that patch. I only patched it out of the build because I had not yet figured out where the cache should be installed according to Debian policy, and it seemed wasteful to build the cache if it wasn't going to be installed.

Good to know, thanks

I'm getting the same issue with hanging at the end of the rocfft build on RHEL 9.2 using the AMD supplied packages for deps. Am I just being impatient? I left this build alone for longer, though. rocfft_aot_help and rocfft_rtc_help have the CPU pretty much pegged and it's been in this state for 45 minutes now.

The end of the build does take a very long time, as that's when we're compiling all of the kernels that we want to distribute with the library, for all enabled architectures.  The optional ROCFFT_BUILD_KERNEL_CACHE_PATH CMake parameter that was the subject of #430 can help somewhat, by defining a place where these kernels are persistently stored between builds so that they can be reused.  But it doesn't reduce the initial amount of work that the build would want to do.
rocFFT will be perfectly functional if the cache is not built or distributed with the library.  But that means that all kernels will need to be compiled at runtime, since rocFFT will not find any that are distributed with it.  Creation of FFT plans will take longer, but the plans will still work.
A middle ground might be to remove architectures from AMDGPU_TARGETS.  Fewer architectures in that list means fewer kernels that need to be compiled at the end of the build.  rocFFT will still work on an architecture that is not in this list, because it will still compile kernels on-demand at runtime.

Yeah, I didn't kill the build on RHEL and it turns out that it took about 1.5 hours to do that last part. I'll redo the fedora build locally and let it run. Unless something strange happens, it looks like we're going to have to deal with that patch and find some sort of fix.

After revering that patch, rocFFT builds and works fine on this system. It turns out that the unit_t-variant patch was not only breaking compile but it was apparently the root cause of an issue that was keeping the library from working when compiled w/o cached kernels.
Thanks for the help with debugging this.


No such file renders/{}/file_list.txt

Hello,
I finally managed to orientate better my dataset and now I want to start training. The train stops here:
rnd_img_pth = os.path.join(
                self.root, "renders/{}/file_list.txt".format(cls_type)
            )

It says it cannot find the /renders/{}/file_list.txt between my files. I don't know what it is and I don't know what is the renders folder. I am trying to investigate more. It's safe to put it in a try except or is it needed?
The same things goes for linemod dataset

I see, they come from raster_triangle.

I'm getting same error but i don't know how to fix it.
i'm using colab now and got error message =
FileNotFoundError: [Errno 2] No such file or directory: '/content/PVN3D/pvn3d/datasets/linemod/Linemod_preprocessed/renders/ape/file_list.txt'

I can't understand how to fix this error with " raster_triangle " github.
I'm exactly same that :  I don't know what it is and I don't know what is the renders folder, and how to fix it

Follow the README in raster_triangle  and generate the render and fuse data. The generated data will be in the Linemod_preprocessed/renders and Linemod_prepocessed/fuse respectively.


Cleanup of Pipeline Driver Syntax and Documentation

This is a general list of problems that I see remaining in some of the drivers. This is not a functionality issue but I think should still be resolved for homogeneity of syntax.

In the ORCA Driver, we should decide to move the Orca parser to a separate module in the parsing folder of molli, that or we should move the xtbout.py functionality to the XTB driver
In the ORCA Driveroptimize_ens method should be changed to basic_calc_ens, as it was above, but there's a repetition driver for some reason
Many of the functions in the driver are lacking adequate documentation up to standard with the rest of Molli
In the XTB Driver The energy_m function prep has a different name for post (energy), we should fix this to energy_m.
We should decide if we want to add ConformerEnsemble versions of the functions that do not currently have them. This shouldn't be too much work since there are plenty of examples.

Orca parser definitely should go into a separate submodule
Why should optimize_ens be changed? I'm not sure I'm following
Yes, documentation is lacking. We should figure out how to add that, I'm completely swamped at the moment
Agreed
I personally don't think we should add the ConformerEnsemble version of everything in existence, but others may feel differently.

The optimize_ens comes after we had already defined basic_calc_ens using the same behavior. You can see the code in the backend, and i think for just homogeneity of function naming it should be fixed.
On a completely separate note, an additional thing we should fix is removal of unnecessary functions in the openbabel driver. Many are relics from before we had more robust implementation.

The optimize_ens comes after we had already defined basic_calc_ens using the same behavior. You can see the code in the backend, and i think for just homogeneity of function naming it should be fixed.

optimize_ens just extends basic_calc_ens functionality, but it does not replace it in any way. It means that we can define other functions that use basic_calc_ens  as a lower-level code. I still don't see any problem.

agree on basic_calc_ens, I see it now!


[Google Translate] Allow binding aliases for translation sets

Extension
https://www.raycast.com/gebeto/translate
Description
I love the translate extension, but 70% of the time I need Portuguese -> English and 30% of the time, English -> Portuguese. It would be very nice to have an alias for each, so p2e will get me Portuguese -> English and e2p will get me English -> Portuguese.
Who will benefit from this feature?
I believe, anybody who has a second language that they're not fully comfortable with yet.
Anything else?
No response

As I understand, you are using. Translate Form, correct?
You can try to use hotkey CMD + SHIFT + S to switch languages:
https://user-images.githubusercontent.com/13422799/222929499-953f43c1-4eac-4fa8-b493-1cd2667fcee2.mov


Can I do "Collection group queries" to Firestore from Cloud Function using firebase_functions_interop?

Greetings.
Please I need some help:
Can I do "Collection group queries" to Firestore from Cloud Function using firebase_functions_interop?
Thanks in advance.

This is something I'm looking for too.


Add backwards compatibility tests for automation

Add backwards compatibility tests for the plugin to automate end-to-end upgrade paths for faster releases. Developer documentation for implementing bwc tests and hooking them to CI: https://github.com/opensearch-project/opensearch-plugins/blob/main/TESTING.md#backwards-compatibility-testing

Marked as closed since Erics PR was merged.


Edit Az SSH Arc Doc to have more details nonpublic cloud support

Added comment about how non-public clouds like Az Gov is currently not supported by SSH ARC

@johnmarco
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Install error, No matching distribution found for datasets==2.10.1

git clone https://github.com/OptimalScale/LMFlow.git
cd LMFlow
conda create -n lmflow python=3.9 -y
conda activate lmflow
conda install mpi4py
pip install -e .
------------log
pip install -e .
 Could you try different pip source?

I use https://pypi.org/project/datasets/2.10.1/#files  fix it.

what is the pip source? Could you try different pip source?

Yes, thank you. It works now~

great!


GOARCH variable for windows should be amd64

By submitting a PR to this repository, you agree to the terms within the Checkmarx Code of Conduct. Please see the contributing guidelines for how to create and submit a high-quality PR for this repo.
Description
The install instructions for Windows says to set GOARCH=am. It should say GOARCH=amd64 like the other operating systems. There's no impact on the CLI operation.
References
None.
Testing

Describe how this change was tested. Be specific about anything not tested and reasons why. If this solution has unit and/or integration testing, tests should be added for new functionality and existing tests should complete without errors.

Does not change the operation of the CLI so no testing needed.
Checklist

[NA] I have added documentation for new/changed functionality in this PR (if applicable).
[NA ] I have updated the CLI help for new/changed functionality in this PR (if applicable).
[X ] All active GitHub checks for tests, formatting, and security are passing
[X ] The correct base branch is being used

@CxFriese Thanks for your contribution


grouping multiple fields

Can qdrant search by grouping multiple fields? I see that the search_groups API only support one grouping field.

Hi, @yuasa1hiromi, sorry for the late response
No, you can only group by one field


Pre-release filter for Maven Central

Similar to the Nuget vpre variant, I'd love a way to filter for stable or pre-releases on Maven Central. Currently it will always display the latest version.
I could use versionPrefix but then I have to update the version each release.

I think the reason we haven't attempted to implement this for maven is that the response we get from maven central (example: https://repo1.maven.org/maven2/com/google/guava/guava/maven-metadata.xml ) don't allow us to know if a given version is classed as a pre-release by the registry or not. I also suspect that not every project on maven central follows the exact same rules for how a version string would communicate that a release is a pre-release.


Is this compatible with ESP-IDF release/v4.1 and release/v3.3?

We would like to integrate this into our projects which are currently based on release 4.1 and 3.3. Would this be compatible with those versions?
Thanks!

This project is compatible with release v4.3, not compatible with release 4.1 and 3.3. Because some apis are not the same, like console  api in components/debug, led api in examples/dev_kits/common_components/led.
what functions do you will use in espnow, you may try to change the api to your  IDF version.

Hello @LJYSP
Does this project work with the idf v4.2.2 ? Can we directly use the components ?
Does the Components utils are based on the v4.3 ??

@sagar448 Please refer to the instructions of idf-version and checkout it to the master branch.


Add roles

Should we merge this even if you are getting the issue with forbidden when calling the API? Is it possible to provide/retain the other code path so I can toggle back to the API key if the default credential doesn't work with notebooks?

Merging DefaultAzureCredentials based azd configuration into main


Change site and machine namespace to use continent name

The hub fullname was used previously but as it was not exported to the object plenary, it was impossible to locate the site template (not included by default in the object plenary)

Hosts must be rebuilt to use the new namespace

This PR also adds the hub information in the object plenary under /hardware/sysloc/region.
Fixes #104
Change-Id: I71e59ffa750a264b88ecf35ae3e6ebecd73f98e2

You are right, a flush is enough but a recompile also if you want to assess that everything is ok, isn't it? I don't know if a coordinated approach is really needed (but you may prefer to do it this way), until you don't remove the old templates (they are not removed by flush). I'll update the comment.


[Admin] Fix broken link

Docs Build status updates of commit d834adb:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/reference/requirement-sets/excel-preview-apis.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Placeholder overlapping item being dragged

Describe the bug
Hi,
Starting on v1.4.3 an issue was introduced through this PR that makes it that if you just click an item without dragging it the placeholder will overlap the item. This is due to the fact that the placeholder gets added to the DOM without the react-draggable-dragging class being added to the item that is being clicked. Thus the zIndex of that item isn't being set to render in front of the placeholder.
With < v1.4.3 that particular issue is not present but a variant of it. This time the issue arises if you just drag the item a tiny bit, same reason, the placeholder is present but not the react-draggable-dragging class.
Your Example Website or App
https://react-grid-layout.github.io/react-grid-layout/examples/0-showcase.html
Steps to Reproduce the Bug or Issue

Run the library locally with pnpm dev
On the local example hold down the click on an item without dragging it

Expected behavior
Visually nothing should change as we are just clicking an item without actually dragging it
Instead the placeholder gets rendered over the item
react-grid-layout library version
1.4.4
Operating System Version
macOS
Browser
Chrome
Additional context
No response
Screenshots or Videos
Current issue v1.4.4 (overlap on holding click without dragging)
https://github.com/react-grid-layout/react-grid-layout/assets/113924919/18fd8fc3-c110-4f21-8c45-bb5bba395844
Previous issue v1.4.2. (overlap on tiny drag only)
https://github.com/react-grid-layout/react-grid-layout/assets/113924919/ee98d75d-0307-4ed5-915c-8689c6cc6e6d

I am wondering if this could be the reason, one of my bottom right widget buttons will not function on a stationary click, only if I slightly move the mouse...