TypeError: a.use is not a function in VueDraggableResizable.umd.min.js

When used together with
https://dev.to/tuandm/laravel--vuejs--laravue---a-beautiful-dashboard-for-laravel-3h11
I'm not very experienced, please help me figure it out.
Error
https://imgur.com/RuSSLAw
package.json
{
"name": "vp",
"version": "1.0.0",
"description": "vp desc",
"author": "arhontsl<EMAIL_ADDRESS>"private": true,
"scripts": {
"dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js",
"start": "npm run dev",
"build": "node build/build.js"
},
"dependencies": {
"ajv": "^6.10.0",
"vue": "^2.5.2",
"vue-draggable-resizable": "^2.0.0-rc2",
"vue-router": "^3.0.1"
},
"devDependencies": {
"autoprefixer": "^7.1.2",
"babel-core": "^6.22.1",
"babel-helper-vue-jsx-merge-props": "^2.0.3",
"babel-loader": "^7.1.1",
"babel-plugin-syntax-jsx": "^6.18.0",
"babel-plugin-transform-runtime": "^6.22.0",
"babel-plugin-transform-vue-jsx": "^3.5.0",
"babel-preset-env": "^1.3.2",
"babel-preset-stage-2": "^6.22.0",
"chalk": "^2.0.1",
"copy-webpack-plugin": "^4.0.1",
"css-loader": "^0.28.0",
"extract-text-webpack-plugin": "^3.0.0",
"file-loader": "^1.1.4",
"friendly-errors-webpack-plugin": "^1.6.1",
"html-webpack-plugin": "^2.30.1",
"node-notifier": "^5.1.2",
"optimize-css-assets-webpack-plugin": "^3.2.0",
"ora": "^1.2.0",
"portfinder": "^1.0.13",
"postcss-import": "^11.0.0",
"postcss-loader": "^2.0.8",
"postcss-url": "^7.2.1",
"rimraf": "^2.6.0",
"semver": "^5.3.0",
"shelljs": "^0.7.6",
"uglifyjs-webpack-plugin": "^1.1.1",
"url-loader": "^0.5.8",
"vue-loader": "^13.3.0",
"vue-style-loader": "^3.0.1",
"vue-template-compiler": "^2.5.2",
"webpack": "^3.6.0",
"webpack-bundle-analyzer": "^2.9.0",
"webpack-dev-server": "^2.9.1",
"webpack-merge": "^4.1.0"
},
"engines": {
"node": ">= 6.0.0",
"npm": ">= 3.0.0"
},
"browserslist": [
"> 1%",
"last 2 versions",
"not ie <= 8"
]
}

It's hard to tell what it is without looking at the actual source code. Try to follow the documentation carefully on how to install the component https://github.com/mauricius/vue-draggable-resizable/#install-and-basic-usage

I do experience the same. I was able to locate the issue the marked lines https://github.com/mauricius/vue-draggable-resizable/blob/master/src/index.js#L15-L23
The problem comes in if the page around this extension has a Vue defined and tries to call .use().
I removed the lines locally and everything is working as expected. I would like to understand why the lines exist and run the specs. but having serious issues getting the thing set up and running at all.
The error message I get is
To install them, you can run: npm install --save core-js/modules/es6.array.filter core-js/modules/es6.array.find core-js/modules/es6.array.for-each core-js/modules/es6.array.iterator core-js/modules/es6.date.to-string core-js/modules/es6.number.constructor core-js/modules/es6.object.define-properties core-js/modules/es6.object.define-property core-js/modules/es6.object.keys core-js/modules/es6.regexp.constructor core-js/modules/es6.regexp.to-string core-js/modules/es6.set core-js/modules/es6.string.includes core-js/modules/es6.string.iterator core-js/modules/es7.array.includes core-js/modules/es7.object.get-own-property-descriptors core-js/modules/web.dom.iterable

but I already added corejs to the deps. which didn't worked out at all.
Can you advise here?
Thanks
Jan


not support chinese character

Pre-flight checklist

[X] I have read the contribution documentation for this project.
[X] I agree to follow the code of conduct that this project uses.
[X] I have searched the issue tracker for a bug that matches the one I want to file, without success.

Electron Forge version
6.0.5
Electron version
23.1.0
Operating system
Windows Server 2016 DataCenter
Last known working Electron Forge version
No response
Expected behavior
support chinese character
Actual behavior
chinese character incorrect

Steps to reproduce
Clone this repository
git clone https://github.com/electron/electron-quick-start
Go into the repository
cd electron-quick-start
Install dependencies
npm install
#config forge
npm install --save-dev @electron-forge/cli
npx electron-forge import
change forge config

# build
npm run make
# click setup.exe and install
Additional information
No response

@BlackHole1
@MarshallOfSound

Windows Server 2016 DataCenter

Will it be stable on windows 10/11 as well?

BTW. we are able to receive your messages without<EMAIL_ADDRESS>

Windows Server 2016 DataCenter

Will it be stable on windows 10/11 as well?

BTW. we are able to receive your messages without<EMAIL_ADDRESS>

yep

any suggestion ??

Please don't be pushy, we will try to reproduce, locate, and fix this issue. But we all have our own work and priorities of tasks that cannot be immediately focused on this issue.

Results of building on Windows 10:

Results of building on macOS:

relationship
I mean's squirrels.window installer, after install the setup.exe, the chinese character wrong

could you reproduce the bug?

@lockiechen Yes, I have successfully reproduced it locally

I have found a solution, the cause is caused by the windows character set. You can set the windows default character set to solve this problem. You can check the link below to set it.

https://www.youtube.com/watch?v=aIpOzlenG0U
https://www.quora.com/Why-doesnt-Microsoft-use-UTF-8-on-Windows-10

BTW. Squirrel.Windows should be capable of doing this, you can create an issue for Squirrel.Windows and point the current issues link to Squirrel.Windows.

like this???

It looks like your system doesn't support this and we have to wait for Squirrel.Windows to fix it.
I checked the code and the problem should be in ZipArchive: https://github.com/Squirrel/Squirrel.Windows/blob/0ee9447d0f70744ad3624de953fc0eccf600990a/src/Squirrel/ReleasePackage.cs#L202
Because the ZipArchive default encoding is: ZipArchiveEntry.DefaultCodePage. i.e., the encoding is selected according to the current system locale.

my fault, thx!

hi，I change the windows code page to utf-8, but it doesn't wok

I have attempted this approach myself to no avail. My hypothesis is that these modifications only apply to cmd / powershell. They do not seem to have any effect on ZipArchiveEntry.DefaultCodePage.

it's possible to change the default OEM code page of the system by modifying the registry that contains the key value of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\OEMCP. If the key value is set to UTF-8, then the system's default OEM code page will be changed to UTF-8 encoding. In other words, this will affect the DefaultCodePage property of the ZipArchiveEntry class and set it to UTF-8 encoding.

https://superuser.com/a/927575
https://learn.microsoft.com/en-us/answers/questions/587680/where-can-i-find-beta-use-unicode-utf-8-for-worldw?orderby=oldest

Please note that modifying the registry in this manner may potentially cause the system to fail to start.


[Enhancement]: error code

Is there an existing issue about this enhancement?

[X] I have checked the existing issues.

Describe the enhancement.
https://docs.matrixorigin.io/0.6.0/MatrixOne/Troubleshooting/error-code/
The current error code is a reference-like document. We need at least add some descriptions about what are they, where and how they are used.

https://github.com/matrixorigin/matrixorigin.io/pull/279


streamlining travis

Couple changes to streamline travis.

Kube has moved up to 1.8.3 so probably don't need 1.7 any more.
Added stages, to allow both 1.8.x and tip to be tested in parallel, and to test integration only against 1.8.x

Should cut the overall test time down considerably.
Cheers, Mike
Signed-off-by: Mike Brown<EMAIL_ADDRESS>

[retest]

LGTM

LGTM
I will merge, If @cevich or @mrunalp find a reason to not do this, we can revisit it later.
@mikebrow Thanks.


OOB Spfx version 1.13.1 break while using react-router-dom

Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
not applicable
Developer environment
Windows
What browser(s) / client(s) have you tested

[ ] 💥 Internet Explorer
[ ] 💥 Microsoft Edge
[X] 💥 Google Chrome
[ ] 💥 FireFox
[ ] 💥 Safari
[ ] mobile (iOS/iPadOS)
[ ] mobile (Android)
[ ] not applicable
[ ] other (enter in the "Additional environment details" area below)

Additional environment details

browser version
SPFx version : 1.13.1
Node.js version : 14.17.5
react-router-dom : 6.2.1
etc

Describe the bug / error
upon running gulp buld the following error comes up
[16:04:24] Error - [tsc] node_modules/react-router/index.d.ts(151,74): error TS1110: Type expected. [16:04:24] Error - [tsc] node_modules/react-router/index.d.ts(151,83): error TS1005: '}' expected. [16:04:24] Error - [tsc] node_modules/react-router/index.d.ts(151,94): error TS1128: Declaration or statement expected. [16:04:24] Error - [tsc] node_modules/react-router/index.d.ts(151,96): error TS1161: Unterminated regular expression literal. [16:04:24] Error - 'tsc' sub task errored after 3.85 s
Steps to reproduce

create oob spfx webpart project with yo
npm i react-router-dom
add  import { HashRouter, Route  } from "react-router-dom" to the tsx file
run gulp build and it breaks with the above mentioned errror

Expected behavior
it should build and routing should work
Here is package-lock file in case you need to debug it
C:\code\route
pkgLock.txt

Hi @techakki81 - thank you for reporting this one!
As I can see from the react-router repo, v6 is based on TypeScript v4 with target set to ES2020 and React v17. Both of those are not supported by SPFx yet.
I would recommend to try v5 instead.


Update mhk ssc_equation link for PySAM

-Closes https://github.com/NREL/ssc/issues/1197
-See https://github.com/NREL/ssc/issues/1198 for discussion from patch

Are the inputs / outputs up to date for the docstrings, e.g. me_array_cable_length_doc?
I see 5 inputs in the doc but 10 in the function itself

Updated equation docstrings. No longer linking mhk equations to PySAM modules at this time.


Bump to node.js 16

I'm using this action for Circe and ran into the following warning today:

Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16: conao3/setup-cask@master, actions/checkout@v2

Bumping to node.js 16 shouldn't be hard, but I'm far from a JS expert to tell what the effects of it would be.

@wasamasa
Thanks for reporting this!
#27 from @jcs090218 is merged, so please try again and check this action work as expected.

Thanks, the warning is gone now. Builds work as usual.


Add ElasticSearch as s-c-s sink

From @sabbyanandan on May 6, 2016 17:9
From @sabbyanandan on January 19, 2016 17:58
As a user, I'd like to have an option to write to elasticsearch sink, so I can aggregate, search and analyze data insights in real-time. This can be adapted from @mbogoevici's POC here.
Acceptance:

elasticsearch as sink module is available in spring-cloud-stream-modules repo
maven repo includes elasticsearch module with respective group/artifact/version detail
documentation included in SCSM reference guide

Copied from original issue: spring-cloud/spring-cloud-stream-modules#159
Copied from original issue: spring-cloud/spring-cloud-stream-app-starters#70

Now, elasticsearch has been used for log storage and retrieval in many scenarios. Suggest to add Slink support for elasticsearch? Or should we use SpingDataFlow as the middleware for log processing.


Customizing device hostname

How people can change their auto-generated device hostname. Possibly also add docs on how the hostnames are generated for the devices at the moment?
 Front conversations

Documented here: https://docs.resin.io/understanding/understanding-devices/2.0.0/#dev-vs-prod-images, but probably belongs somewhere else

All these solution have to manually run on the host os or in a container. Is there a configuration variable that could be set per application or device? That seems like the simplest solution.

Changing hostname through config.json and some information about hostnames are generated
https://www.balena.io/docs/reference/OS/overview/2.x/#development-vs-production-images
https://www.balena.io/docs/reference/OS/configuration/#sample-configjson
Changing Hostname through supervisor API
https://www.balena.io/docs/reference/supervisor/supervisor-api/#patch-v1devicehost-config
If there is a need to add the information above in a better place, then I think FAQ could be a good spot. Closing.


pygmentize requires eggy install

(Original issue 381 created by None on 2008-12-18T18:41:59+00:00)
We currently have a python setup that is egg-free (This due to the fact that eggs are inefficient and uncontrollable for a tightly controlled python environment).  We are attempting to use another python tool (Sphinx) that requires the use of Pygments.  Unfortunately we are currently unable to use Pygments because the pygmentize script has explicit dependencies on being an egg.
Since not everyone uses eggs is there any way that this dependency can be made optional?
Reported by guest

(Original issue was assigned to gbrandl)
(Original issue 381 last updated on 2009-06-21T22:28:42+00:00)
(Issue automaticaly closed due to status in Bitbucket: resolved)

(Original comment by thatch on 2009-06-21T22:28:42+00:00)
If you extract the Pygments tarball, add it to your PYTHONPATH, and use the pygmentize script that it comes with you should be fine.  This way does not use setuptools, and does not use load_entry_point either.

(Original comment by None on 2008-12-29T19:25:07+00:00)
I realize that the installation requires setuptools and in our setup we can deal with that for installing packages (although a more standard mechanism would be preferred :) ).  When dealing with other packages that have dependencies on setuptools the end packages can be extracted from the egg and used in a correct and standard python manner compliant with our run-time setup.
In the case of the pygmentize executable the first thing it does is import pkg_resources from setuptools, this creates a dependency on setuptools beyond actual installation of the product.  Additionally the 'load_entry_point' function, originally intended to be used for "plugin hooks" of add-on modules, performs a dictionary look-up of data contained in the egg-specific metadata that is lost when turning pygmentize into a real, stand-alone python module.
Is it possible to make pygmentize not depend on setuptools for anything other than installation?

(Original comment by gbrandl on 2008-12-27T18:58:12+00:00)
It's not the pygmentize script that depends on being installed as an egg.  Rather, the setup.py depends on setuptools and installs a "pygmentize" script via setuptools' console_scripts facility.
Do you need not to use setuptools at all?


Addition of 11 new projects to Defects4J

This PR adds 11 projects to Defects4J:

All bugs are Java 8 compatible
All bugs have been minimized by two or more Defects4J contributors
Metadata has been recomputed for all bugs

I've realized there is one more thing I need to do before we merge. Regeneration of metadata did not regenerate the stack traces on the triggering tests, so line numbers may not match between Java 7 and 8. I will recompute the stack traces as well, and report back when that is done.

Ok - all stack traces have been recomputed. As long as CI passes, this should be ready to merge.

I am running the verify-bugs script for all bugs, using all tests right now. Once this successfully completed, I'll take another look at changes, and then this is good to go.

We should address issue #292 before merging this in -- otherwise, travis will fail most of the time for no reason.

Just pushed a commit that fixes #292.


Product checkboxes remove all results from a search

In the Trustification UI at trustification.dev, search for kernel
This returns a list of advisories
Select any of the product checkboxes such as RHEL 7, 8, or 9

Result: "No results" is shown in the UI
Expected results: The advisory list should be restricted to the selected product(s)

@alanfx Fix is deployed to staging.trustification.dev

JIRA: https://issues.redhat.com/browse/TC-521


Seamless tabs

Just FYI: Tabs now have a data-type attribute. For example text editor tabs have data-type="TextEditor".
This way only <atom-text-editor> tabs could use a Syntax theme's background color when active, but other panes, like settings could have a different active color to make them more seamless.


NaiveProxy, Gost

A couple of other Network tunnels are:
NaiveProxy https://github.com/klzgrad/naiveproxy
Gost https://github.com/ginuerzh/gost

added @davepalm  thanks!

added


"Singleton"-Widgets

Would it be possible to create Widgets that only can be put on the Dashboard once? Or is that not in the sense of Widgets?

This is not possible at the moment, but i will keep this is mind.

if (angular.isFunction(widgetFilter)){
  widgets = {};
  angular.forEach(dashboard.widgets, function(widget, type){
    if (widgetFilter(widget, type)){
      widgets[type] = widget;
    }
  });
} else {
  widgets = dashboard.widgets;
}

This code is at line 442 of angular-dashboard-framework.js. It fills the object widgets that is used in the addWidgetDialog, you'll be able to add every widget that is in that object.
Is there a way to set the widgetFilter function to check if it is in the model? This is in the adfDashboard directive, where you have access to the model.

The widget filter get now the model as third parameter. You should now be able to search, if a widget already exists in the model.

Thanks a lot.


UI Updated

I have updated the UI of the hotel management website to enhance its visual appeal and attract customers. The main focus of my update was to incorporate shades of colors that create an inviting and aesthetically pleasing atmosphere. By introducing carefully selected color schemes and incorporating them into various elements of the website, such as headers, buttons, and backgrounds, I aimed to create a visually engaging experience that captures the attention of potential customers. These color shades add vibrancy and evoke positive emotions, making the website more appealing and enticing to explore

#992

Do not create PR before the issue is assigned to you

Resolve merge conflicts and create a fresh PR

Resolve merge conflicts and create a fresh PR

ok sir


Use consistent line endings in grammar files

This helps prevent inconstant line endings in the generated content.
Previously there was a mix of Unix, Windows and even Mac line endings. We came across this because we were seeing strange behavior when reducing test cases.
I only updated grammar files with the exception of vbscript.

Actually I think I have a better solution. Let me create another PR with a patch set.


dask_ml.decomposition.PCA: ValueError with data > 1 TB

When I do dask_ml.decomposition.PCA().fit(x), where the array x has a size > 1 TB, I get the error ValueError: output array is read-only.
I use
dask-ml                   1.1.1
distributed               2.9.0

The script
from dask_jobqueue import SLURMCluster
from dask.distributed import Client
from dask_ml.decomposition import PCA
import dask.array as da

cluster = SLURMCluster()
nb_workers = 58
cluster.scale(nb_workers)
client = Client(cluster)
client.wait_for_workers(nb_workers)

x = da.random.random((1000000, 140000), chunks=(100000, 2000))
pca = PCA(n_components=64)
pca.fit(x)

gives the error
Traceback (most recent call last):
  File "value_error.py", line 48, in <module>
    pca.fit(x)
  File "/home/dheim/miniconda3/lib/python3.7/site-packages/dask_ml/decomposition/pca.py", line 190, in fit
    self._fit(X)
  File "/home/dheim/miniconda3/lib/python3.7/site-packages/dask_ml/decomposition/pca.py", line 338, in _fit
    raise e
  File "/home/dheim/miniconda3/lib/python3.7/site-packages/dask_ml/decomposition/pca.py", line 325, in _fit
    singular_values,
  File "/home/dheim/miniconda3/lib/python3.7/site-packages/dask/base.py", line 436, in compute
    results = schedule(dsk, keys, **kwargs)
  File "/home/dheim/miniconda3/lib/python3.7/site-packages/distributed/client.py", line 2573, in get
    results = self.gather(packed, asynchronous=asynchronous, direct=direct)
  File "/home/dheim/miniconda3/lib/python3.7/site-packages/distributed/client.py", line 1873, in gather
    asynchronous=asynchronous,
  File "/home/dheim/miniconda3/lib/python3.7/site-packages/distributed/client.py", line 768, in sync
    self.loop, func, *args, callback_timeout=callback_timeout, **kwargs
  File "/home/dheim/miniconda3/lib/python3.7/site-packages/distributed/utils.py", line 334, in sync
    raise exc.with_traceback(tb)
  File "/home/dheim/miniconda3/lib/python3.7/site-packages/distributed/utils.py", line 318, in f
    result[0] = yield future
  File "/home/dheim/miniconda3/lib/python3.7/site-packages/tornado/gen.py", line 735, in run
    value = future.result()
  File "/home/dheim/miniconda3/lib/python3.7/site-packages/distributed/client.py", line 1729, in _gather
    raise exception.with_traceback(traceback)
  File "/home/dheim/miniconda3/lib/python3.7/site-packages/sklearn/utils/extmath.py", line 516, in svd_flip
    v *= signs[:, np.newaxis]
ValueError: output array is read-only

Note that

If I use x = da.random.random((1000000, 130000), chunks=(100000, 2000)) (1.0 TB), the error does not appear.
When I look at the dashboard, the PCA seems to run fine and the error appears at the very end of the computation.
I temporarily fixed the error in extmath.py by changing

def svd_flip(u, v, u_based_decision=True):
    if u_based_decision:
        # columns of u, rows of v
        max_abs_cols = np.argmax(np.abs(u), axis=0)
        signs = np.sign(u[max_abs_cols, range(u.shape[1])])
        u *= signs
-        v *= signs[:, np.newaxis]
+        v_copy = np.copy(v)
+        v_copy *= signs[:, np.newaxis]
+        return u, v_copy
    else:

I think this is not a good fix because I assume that the array v is blocked by another function.
Is there another way to fix the error?

Do you know why the array is readonly? I don't immediately see a reason why the size of the data would matter, but I may be missing something.

There may have been some Cython thing at some point.  I can't remember who brought this up originally.  @jakirkham were you involved in this?

I also don't understand why the array is readonly.
Can you reproduce the error on your HPC?
Is this maybe related to https://github.com/dask/distributed/issues/1978?

Can you reproduce the error on your HPC?

I don't have access to an HPC machine.
https://github.com/dask/distributed/issues/1978 does sound related. Does ensuring that all your dependencies are built against Cython 0.28 or newer fix things?
https://github.com/dask/distributed/issues/1978#issuecomment-448209604 is using PCA as well. Let's continue the discussion over there.

@jakirkham were you involved in this?

IDK about involved. 😉 We did discuss a similar issue before that Tom has referenced.

I also don't understand why the array is readonly.

Because we send bytes over the wire and bytes are immutable.
In [1]: memoryview(b"abc").readonly
Out[1]: True


usb mass storage : config waits for Vendor ID and Product ID from user during building

While building application for usb mass storage, config is expecting user to pass Vendor ID and Product id. Build keeps waiting until provided with IDs. This creates blockage for automation.
=================================
Below logs appear during building:
Merging prj.conf
#
# configuration written to .config
#
make[1]: Entering directory 'ZEPHYR_BASE'
make[2]: Entering directory 'ZEPHYR_BASE/samples/subsys/usb/mass/outdir/quark_se_c1000_devboard'
  GEN     ./Makefile
scripts/kconfig/conf --silentoldconfig Kconfig
.config:434:warning: symbol value '' invalid for USB_DEVICE_VID
.config:435:warning: symbol value '' invalid for USB_DEVICE_PID
*
* Restart config...
*
*
* USB device stack
*
USB device stack (USB_DEVICE_STACK) [Y/n/?] y
  Sets log level for the USB device stack (SYS_LOG_USB_LEVEL) [1] 1
  USB Vendor ID (USB_DEVICE_VID) [] (NEW)

Steps to reproduce:

cd   $ZEPHYR_BASE
source  zephyr-env.sh
cd   $ZEPHYR_BASE/samples/subsys/usb/mass
make  BOARD=quark_se_c1000_devboard

Work around:
Pass USB_DEVICE_VID and USB_DEVICE_PID to boards/x86/quark_se_c1000_devboard/Kconfig.defconfig

We do not have VENDOR_ID and PRODUCT_ID assigned for this board, however if you know uark_se_c1000_devboard default values we can put them to this defconfig. BTW, do not you use sanitycheck for automatic build?

@finikorg this is breaking sanitycheck and we do need to have some default values added in this case, same as with tinyTILE.

ok, I mixed this up with another issue we had with IDs, but in this case for the arduino 101, they all share the same ID like the tinyTILE, so this needs to be set somewhere, in this case probably in the test framework testing the usb

I consider this not a bug but feature. Until we get proper Vendor ID we cannot invent those values and put to the project configuration files. Automation issues are resolved in sample.yaml configurations.

currently it is desired behavior

As discussed above, Now VID & PID values are being provided from test framework only. Specific VID & PID will be profided by user, if any.
We can close this issue as FIXED.

Closed as fixed


Doc requirements for platform api expectations

Ready for review!

Platforms affected
What does this PR do?
Document requirements for platform api expectations
What testing has been done on this change?
Checklist

[ ] Reported an issue in the JIRA database
[ ] Commit message follows the format: "CB-3232: (android) Fix bug with resolving file paths", where CB-xxxx is the JIRA ID & "android" is the platform affected.
[ ] Added automated test coverage as appropriate for this change.

Another thing to note is that the tests that are in this repo could be used to verify the platformAPI for anyone attempting to implement it.

This seems almost ready to merge.
What about those last two comments @filmaj @purplecabbage? Do you have suggestions what the text should be replaced with so this can be taken care of and merged?

Went through the review comments and resolved the ones that were definitely taken care of before merging, left the ones that are not 100% explained or done yet and might need a new PR to fix.


Regarding VAE architecture.

Hello,
In the code for VAE the input is 32x32 (CIFAR 10/100) and after the 4 conv layers it reduces to 4x4 (This is also mentioned in comments in the code).
However, in the very next line while flattening the tensor for the fully-connected layer you use View(-1, 102422), whereas it should be View(-1, 102444).
https://github.com/sinhasam/vaal/blob/67263f32665990a9408430a86df5b6ecd96a812d/model.py#L35
Can you kindly look into this?

32/(2^4)=2. So View((-1, 1024*2*2)) is right

Hello,
In the code for VAE the input is 32x32 (CIFAR 10/100) and after the 4 conv layers it reduces to 4x4 (This is also mentioned in comments in the code).
However, in the very next line while flattening the tensor for the fully-connected layer you use View(-1, 1024_2_2), whereas it should be View(-1, 1024_4_4).
https://github.com/sinhasam/vaal/blob/67263f32665990a9408430a86df5b6ecd96a812d/model.py#L35
Can you kindly look into this?

32/(2^4)=2. So View((-1, 1024*2*2)) is right

Ah. I was incorrectly considering those to be output sizes for the conv layers. You are right for 1024x4x4 the input would have to be 64x64. Thank you. I am closing this issue.


Fix typos in README.md

Motivation
This pull request fixes minor typos in the README to improve clarity and professionalism:

"substantialy" → "substantially"
"comile" → "compile"
"intial" → "initial"

These changes enhance the documentation quality and readability for contributors and users alike.
Hi @DJViau, I noticed your contributions to this repository. I'd love to chat with you about your work on the Deadpool NFT you helped create in 2019. This is the only way I've figured out how to directly contact you. If you're willing, you can contact me via GitHub Discussions. I know this is unorthodox but hopefully my tiny contribution to fixing some typos makes up for it.
Solution
The README has been updated with the corrected spelling. No code changes were required.

Note: The Discussions link mentioned above is not currently enabled for this repository. Please feel free to reach out via email<EMAIL_ADDRESS>


Login failed, token is not initialized. Terminating

I got this error
Login failed, token is not initialized. Terminating

Was it working before? This means your address or signature or message are not matching


What are the reasons we don't support Django 1.8?

I can't find any reasons in prior issues or PRs.
1.8 is one of the LTS releases.  It would make installation on Ubuntu far easier for me personally, since my environment prefers to use the OS packages.

It slipped out between releases - too old for 1.0.x but too new for 0.9.x.
I'm totally 👍 for supporting it but have no idea TBH what need to be done.
Maybe @brutasse knows?

I'm the Fedora/EPEL Graphite package maintainer. If not too much trouble I would be quite happy with 1.8 support in Graphite. Django packaging is a bit of a pain in EPEL. Supporting 1.8 would make it easier to get Graphite 1.x in EPEL 7.

Support for Django 1.8 was added to 1.0.x and master branches.  Next release(s) will contain support unless some major issue is found.


DONOTMEGE test: Verify secrets

Provide a description of what has been changed
Checklist

[ ] Commits are signed with Developer Certificate of Origin (DCO - learn more)
[ ] Tests have been added
[ ] A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
[ ] A PR is opened to update the documentation on (repo) (if applicable)
[ ] Changelog has been updated and is aligned with our changelog requirements

Fixes #

Works as expected 👌


Add docker build

This change adds a basic Dockerfile that includes the c-for-go
dependency to allow the generation of bindings without installing
this dependency.
A generic make target docker-% is added to run any of the recognised
make targets in the container.
$ make \t\t
all                    clean                  docker-all             docker-clean           docker-test            image                  test-bindings
bindings               clean-bindings         docker-bindings        docker-clean-bindings  docker-test-bindings   test

Note that this pins:

The GO version to 1.14.4
The c-for-go commit to 8eeee8c3b71f9c3c90c4a73db54ed08b0bba971d

To ensure that this does not introduce any changes when generating
the bindings.

Looks great now. Thanks.

Looks great now. Thanks.


Needs a "Can't find .env" warning dialog

Thought this was completely broken.  I edited the default.env, but didn't see the readme about renaming it to .env.  Would save some time if at least you console.log('No env found').

@sgehrman I'd recommend something before we load env variables and console errors if a setting is missing.

Fixed in PR #76


Update skywalking-ui submodule version

Please answer these questions before submitting pull request

Why submit this pull request?

[ ] Bug fix

[x] New feature provided

[ ] Improve performance

Related issues

Add the icon that RESTEasy displays under the topology map.
Ref to apache/skywalking#2665, https://github.com/apache/skywalking-rocketbot-ui/pull/113

Coverage decreased (-0.08%) to 16.78% when pulling 12b4d27999cc885b89af33deedd1d196850f10da on yanfch:update-version/skywalking-ui into bb4c8c0475c86e8316f35dc4f94ce6d5bcb26b33 on apache:master.


How to import vendor library to use in Stimulus controller, Asset Pipeline version

I'm using Stimulus in Rails 6 via the Asset Pipeline and want to use either momentjs or dayjs library within my controller. How do I import those?
I've tried saving the dayjs.min.js file to vendors/assets/javascripts/dayjs/dayjs.min.js, but do I need to add anything to app/assets/config/manifest.js? or maybe app/assets/javascripts/importmap.json.erb
manifest.js looks like this:
//= link_tree ../javascripts
//= link_tree ../images
//= link_directory ../javascripts .js

importmap.json.erb looks like this:
{
  "imports": {
    "turbo": "<%= asset_path "turbo" %>",
    <%= importmap_list_with_stimulus_from "app/assets/javascripts/controllers", "app/assets/javascripts/libraries" %>
  }
}

This is the bit where I'm stuck. I get the same error:
Failed to autoload controller: timepicker
Error: Unable to resolve specifier 'dayjs' from
http://my.<IP_ADDRESS>.xip.io/assets/controllers/timepicker_controller-b2e267b01d1aad58218fa00a049e456870db49eda347728b16443be29c59682f.js

I think then once the library is "available", I should be import it to be available in my Stimulus controller with :pray: :
  import { Controller } from "stimulus"
+ import dayjs from 'dayjs'
  export default class extends Controller {
  ...

If I try the following with importmap.json.erb:
  {
    "imports": {
      "turbo": "<%= asset_path "turbo" %>",
+    "dayjs": "<%= asset_path "dayjs/dayjs.min.js" %>",
      <%= importmap_list_with_stimulus_from "app/assets/javascripts/controllers", "app/assets/javascripts/libraries" %>
    }
  }

The error changes to the following when I reload the page:
Failed to autoload controller: timepicker SyntaxError: import not found: default

This engine is built to leverage ECMAScript Modules.
If your project has an external dependency, you have several options.
First, declare the import statement in the module that needs it: import day from "dayjs".
Next, configure your server so that it knows how to resolve the dayjs package name. You have several options, including:

downloading the source as a vendored package or a gem that bundles its assets, configuring how to resolve the name in your import map.json with a project-relative path (e.g. "dayjs": asset_path("dayjs/dayjs.min.js")), then serving it from the Rails application
downloading the source as a node_modules package, configuring how to resolve the name in your import map.json with a project-relative Webpacker path (e.g. "dayjs": pack_path("dayjs/dayjs.min.js")), then serving it from the Rails application
configuring how to resolve the name in your import map.json with an absolute URL (e.g. "dayjs": "https://cdn.skypack.dev/dayjs")
declaring the import statement directly in your module with an absolute URL (e.g. import day from "https://cdn.skypack.dev/dayjs")

Have you tried any of these other alternatives?

Ok i've finally figured out :clap: how to import a library. Maybe this is common knowledge for others but ES6 is a brave new world for me. I'm generally stuck back in Year 2000 Javascript.
I didn't want to use a gem that bundled the library for the asset pipeline, and I didn't want to call skypack or a remote CDN. I wanted to serve it locally.

I went to Skypack to get their browser-optimized packaged version of Dayjs: https://cdn.skypack.dev/dayjs and saved the content of that to /app/assets/javascripts/libraries/dayjs/dayjs.js.erb (note .erb). That file looked like this on Skypack.
export * from '/-/dayjs@v1.10.4-MoS2QVkxh1TZYPgJA5zq/dist=es2020,mode=imports/optimized/dayjs.js';
export {default} from '/-/dayjs@v1.10.4-MoS2QVkxh1TZYPgJA5zq/dist=es2020,mode=imports/optimized/dayjs.js';

which I changed to the following, using asset_path:
export * from '<%= asset_path "libraries/dayjs/dayjs.export.js" %>';
export {default} from '<%= asset_path "libraries/dayjs/dayjs.export.js" %>';

That originally referenced https://cdn.skypack.dev//-/dayjs@v1.10.4-MoS2QVkxh1TZYPgJA5zq/dist=es2020,mode=imports/optimized/dayjs.js file, I saved unchanged to /app/assets/javascripts/libraries/dayjs/dayjs.export.js

In my importmap.json.erb I added:
 {
   "imports": {
     "turbo": "<%= asset_path "turbo" %>",
     <%= importmap_list_with_stimulus_from "app/assets/javascripts/controllers", "app/assets/javascripts/libraries" %>,
+    "dayjs": "<%= asset_path "libraries/dayjs/dayjs.js" %>"
   }
 }

In my Stimulus controller, I added:
  import { Controller } from "stimulus"
+ import dayjs from 'dayjs';

Thanks for a prod that led me in the right direction :partying_face:

Better yet, I've just realised that I don't need to do this required "date logic" and calculations in javascript anymore, because I should now be able to use a turbo frame and keep the logic in Rails :tada:


Exception when trying to debug an application

Hi,
I have a .NET application running on an virtual machine with Debian 9.
For app requirements, it needs to start with "sudo mono MyApp.exe", so I log-in via SSH with root.
The plugin can deploy the app, and from the vm, I can start the app with sudo, as described above, without any problem.
If I try to attach to a running process, or I deploy&debug via SSH, I get the exception: "Unhandled Exception: System.TypeInitializationException: The type initializer for 'System.Windows.Forms.WindowsFormsSynchronizationContext' threw an exception. occurred".
I would like to underline, the app starts perfectly when running it from command line, so it must be something related to the debugger.
Can you please help me?

I would like to expand: on another very simple WinForm application (that again runs ok on Mono in Linux) I get an exception as soon as there is any call to WinForms.
Then I've developed a console application (again running ok on Mono on Linux) and the debugger works and is attached, but there is no UI on the Linux VM.
I have tried to set Redirect Output to None, but again I don't see any screen appearing.
So I definitely suppose that there are problems with the interaction with the screen, for both console and WinForms application.
Could you please give me some hints about how to deal with this?

Also may I susgest you switch to Avalonia? I only used Mono WinForms on my project because when I started it Avalonia didn't exist. Mono WinForms is legacy-ware at this point is and not well maintained.
https://github.com/AvaloniaUI/Avalonia

Hi,
thank you for your help.
Currently Avalonia is not an option because the app is very big and already implemented with WinForms.
I'll try the scripts in issue #3 .

Solved:

use DISPLAY=:0 before running the mono command
don't use the root login, as it doens't have X access)

Great! using DISPLAY=:0 run !
Thank you


Tilde (~) character not available in integrated terminal

VSCode Version: Code 1.3.1 (e6b4afa53e9c0f54edef1673de9001e9f0f547ae, 2016-07-12T13:31:10.994Z)
OS Version: Darwin x64 15.5.0

Steps to Reproduce:

Open integrated terminal
Press alt+n
no tilde character is produced in terminal

BUT
if you press alt+n in the normal editor pane the character can be entered.

Duplicate of #9008


shadcn React 19

Update shadcn components to use React 19 (removed forwardRefs) and clean up.

This should merge after #1233


Use Mustache.java for template rendering

This brings possibility to do more advanced templating, rather than just arguments replacement.
Use this enhanced templating to simplify generated SpringLiquibaseUtilTest

@swarajsaaj: If you want to take a look, since you work on #9332 inspired me for these changes. I don't know why, but I can't add you to reviewers :/

@swarajsaaj: If you want to take a look, since you work on #9332 inspired me for these changes. I don't know why, but I can't add you to reviewers :/

Awesome work @murdos 👍 , SpringLiquibaseUtilTest looks much better now, the way it should be.

Adding a bounty as it seems advanced work

Bounty claimed: https://opencollective.com/generator-jhipster/expenses/208286

@murdos : approved


@FeignClient with decode404 set doesn't return Optional.empty on 404

For a method which returns something of type Optional, when decode404 is set to true and you receive a 2xx response, then the type is correctly wrapped into an Optional. If you receive a 404 response, then null is returned rather than Optional.empty().
I would expect Optional.empty() to be returned if 404 is returned and decode404 is set.
Example:
@FeignClient(decode404 = true)
public interface SecondService {
    @RequestMapping(method = RequestMethod.GET, value = "/foo/{id}")
    Optional<Foo> getFoo(@PathVariable("id") String id);
}

Can you provide an example?  I am not seeing null being returned.

Example of the problem can be found at https://github.com/wjam/spring-cloud-netflix-1590 (`com.example.SecondServiceTest#feignClientShouldReturnEmptyWhenReceiving404)

I can't remember for sure, but I don't think there is any specific support for Optional. I think it works quite by accident.

Stepping through the test, when it does work, it's via com.fasterxml.jackson.datatype.jdk8.OptionalDeserializer. Looks like you opened this issue with jackson alread https://github.com/FasterXML/jackson-datatype-jdk8/issues/2

I'm having the same problem, does anyone have a solution?

@PauloJorgeJunior if you are having this problem please open an issue in Spring Cloud OpenFeign and include a sample that reproduces the problem


Local dev environment shows correct file structure, but prod has a duplicate

Have you read the Contributing Guidelines on issues?

[X] I have read the Contributing Guidelines on issues.

Prerequisites

[X] I'm using the latest version of Docusaurus.
[X] I have tried the npm run clear or yarn clear command.
[X] I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
[X] I have tried creating a repro with https://new.docusaurus.io.
[X] I have read the console error message carefully (if applicable).

Description
Duplicate folder showing on nav on left hand side on production. This does not show within the local dev environment.
What we've tried: clearing the cache and redeploying, but still same error.
Dev environment

On netlify/docasaurus

Reproducible demo
https://github.com/LIT-Protocol/docs
Steps to reproduce

Pull repo and do a fresh install
yarn; yarn start; yarn build -> check localhost:3000, dev build shows the correct format
If you open a pull requests on the Lit docs, the netlify preview will show the incorrect format on the left hand side

Expected behavior
Expectation:

Actual behavior
Actual behavior

Your environment

Public source code: https://github.com/LIT-Protocol/docs
Public site URL: https://developer.litprotocol.com/
Docusaurus version used<EMAIL_ADDRESS>Environment name and version (e.g. Chrome 89, Node.js 16.4): Chrome
Operating system and version (e.g. Ubuntu 20.04.2 LTS): macOS Big Sur

Self-service

[ ] I'd be willing to fix this bug myself.

Hi! Your docs folder have two Ecosystem folders:  docs/Ecosystem and docs/ecosystem. Whether they are treated as the same directory is system-dependent. Linux is case-sensitive, so these become two distinct categories on your CI environment. However, locally, Windows and macOS both see them as the same directory because these file systems are case-insensitive. Therefore when we query the FS API, we get the information that only one folder called Ecosystem exists, and there's no way for us to align the behavior here. See also: https://github.com/facebook/docusaurus/issues/7896


[HELP] Converting exported YoLov5 annotations to pascal VOC

Hi, thanks for this great repo!
I know this is technically not related to FiftyOne, but I am having some trouble converting the Yolov5 annotations generated by FO to pascal VOC style 😫
This exporter here write annotations in the normalized, Yolo format. What I am attempting to do, is convert those annotations generated by a model (specifically Yolo-R) to --> Pascal Voc.
So far, I have been unsuccessful in understanding how FiftyOne accomplishes this - if someone has an idea of how such a function would look like, it would be really great 🤗
This is a sample of how the Yolo annotations generated by my model looks like = [0.436523, 0.535156, 0.587891, 0.484375]. I assume normalization is done by dividing by image_height or image_width perhaps? my image_width == image_height as images are square.
Again, many many thanks in advance
Cheers! ❤

If I understand correctly, you have a model that generates predictions in YOLO format, and you want to convert these predictions to VOC format. You can do that by:

First import the YOLO predictions into a FiftyOne dataset
Then export the dataset in VOC format

The links I provided show a variety of syntaxes for each step depending on your exact needs.

Thanks for such a quick reply 🤗
Indeed, but I would want to use bboxes for further real-time processing, so was looking for a simple distilled function that converts it to VOC so I wouldn't have to modify my pipeline too heavily; converting back and forth between datasets would be pretty complicated :(

Here I populate a directory of YOLO-formatted labels to work with:
import os

import fiftyone as fo
import fiftyone.zoo as foz

dataset = foz.load_zoo_dataset("quickstart")

# The list of classes
classes = dataset.distinct("predictions.detections.label")

# A directory of images
data_path = os.path.dirname(dataset.first().filepath)

# A directory of YOLO predictions
dataset.export(
    labels_path="/tmp/yolo",
    dataset_type=fo.types.YOLOv4Dataset,
    label_field="predictions",
    classes=classes,
)

And here's how to convert to a directory of VOC-formatted labels:
fo.Dataset.from_dir(
    data_path=data_path,
    labels_path="/tmp/yolo",
    dataset_type=fo.types.YOLOv4Dataset,
    classes=classes,
).export(
    labels_path="/tmp/voc",
    dataset_type=fo.types.VOCDetectionDataset,
)

Not too bad :)

Sorry for the confusion 😓 I think I may have communicated poorly there.
I can't really re-convert b/w datasets since that would require a huge amount of logging, like writing images to files and lots of back and forth conversions. The aim is to write all the boxes to a csv and its a real-time application so that would be very slow whereas a csv would be decent as it can be updated quite fast.
What I meant was a simple function, which provided a bounding box that converts it to a pascal annotation - I don't require the extra baggage of an entire dataset, simply the bounding box :)
Hope that clears things up!

The code I shared doesn't create copies of the source media; it only reads/writes labels.
It does convert YOLO -> FiftyOne -> VOC and therefore temporarily creates a representation of the labels in our format rather than a direct YOLO -> VOC conversion, but that's the way we do things in this project. Supporting X -> Y direct would require O(n^2) utilities, while X -> FiftyOne -> Y requires only O(2n) utilities to support all possible conversions.
In the case of YOLO -> VOC, since YOLO uses relative coordinates and VOC uses absolute, the conversion also requires retrieving the dimensions of each image, which the code I shared implicitly does for you.
So, if I were you, I wouldn't be too keen on cutting FiftyOne out of the process. Also, I'd recommend storing all your data in FiftyOne format :)

Alright, I'll try and figure how to integrate everything. Thanks a ton! 🍰


HTML5 Video Tag Problem

Hi, I'm facing an issue with html5 video tag and play() method. It seems jsdom doesn't support it:
> jsdom.env("<video src=test.mp4>", ["http://code.jquery.com/jquery.js"], function (err, window) { window.$('video')[0].play(); } );
undefined
>
repl:1
uery.com/jquery.js"], function (err, window) { window.$('video')[0].play(); }
                                                                    ^
TypeError: Object [ VIDEO ] has no method 'play'
    at repl:1:146
    at /Users/flavio.barbosa/Development/player/node_modules/jsdom/lib/jsdom.js:255:9
    at process._tickCallback (node.js:415:13)

This call is a side effect of another test I'm writing, and I imagine that jsdom shouldn't break. At least for me, it would be better to just silence play/pause/stop method calls to video tag.

Any update on this?

I'm also interested on this for testing purposses. Is there any update?

Also interested on this feature

A reasonable stub was added in 6.1.0. Let's open new issues for anything in particular that needs to be added.


set the following authors to "Sling Staff" in import

Mark Schiff supplied the list of authors who are not authoring the blogs , so we have to set them to "Sling Staff" while importing the content

Alex Castle
Ben Macaluso
Brad Koch
Chase Cambria
Emma Dell
Joseph Berman
Michele Drohan
Oscar Enrqie Lorandi
Scott Ross
Tasha Shayne
Wayne Mitchel

Implemented this into import script


Add precommit hooks and all checks

We need to add these dependencies and configure them:

mypy
isort
black
yesqa

Also we need to setup a pre-commit config flie.
And setup CI\CD checks.

You can use #taskiq-aio-pika as a reference.

This issue was closed by #6.


Use std::sync::atomic::hint_core_should_pause in SpinWait

Now that Rust (nightly) has std::sync::atomic::hint_core_should_pause, parking_lot_core::SpinWait should probably use that function directly instead of using asm!("" ::: "memory" : "volatile") in cpu_relax. Probably won't make a difference in terms of performance (I assume they basically do the same thing), but may ease portability.

I really like this, however I would like to at least wait until it is stabilized before using it.

Tracked in https://github.com/rust-lang/rust/issues/41196

I have a concern with the current implementation of Spinwait::spin:
#[inline]
pub fn spin(&mut self) -> bool {
    if self.counter >= 20 {
        return false;
    }
    self.counter += 1;
    if self.counter <= 10 {
        cpu_relax(4 << self.counter);
    } else {
        thread_yield();
    }
    true
}

The pause instruction will be executed 8184 times before calling thread_yield().
However, take a look at to Intel's manual (section 8.4.7 Pause Latency in Skylake Microarchitecture):

Such short wait loops tend to last between tens and a few hundreds of cycles, so performance-wise it is more beneficial to wait while occupying the CPU than yielding to the OS. When the wait loop is expected to last for thousands of cycles or more, it is preferable to yield to the operating system...

The latency of PAUSE instruction in prior generation microarchitecture is about 10 cycles, whereas on Skylake microarchitecture it has been extended to as many as 140 cycles.

This indicates that executing the instruction 8184 times is way too many. Since one instruction takes 10-140 cycles, and yielding to the OS should happen after several thousands of cycles, then perhaps a better number would be between 10 and 100?
Perhaps the following would be a more reasonable implementation that doesn't burn CPU time as much:
#[inline]
pub fn spin(&mut self) -> bool {
    if self.counter >= 120 {
        return false;
    }
    self.counter += 1;
    if self.counter <= 100 {
        cpu_relax(1);
    } else {
        thread_yield();
    }
    true
}

I want to keep the exponential backoff since it helps improve throughput. How about simply reducing the counter thresholds:
#[inline]
pub fn spin(&mut self) -> bool {
    if self.counter >= 10 {
        return false;
    }
    self.counter += 1;
    if self.counter <= 6 {
        cpu_relax(1 << self.counter);
    } else {
        thread_yield();
    }
    true
}

This will call the pause instruction 127 times, after which it will try yielding to the OS 3 times, before finally just blocking on a futex.

To be precise, it's 126 pauses and 4 yields. :) But sounds good to me!

Related to @stjepang 's comments, a performance issue in dotnet on Skylake processors has been traced to a similar loop:

https://aloiskraus.wordpress.com/2018/06/16/why-skylakex-cpus-are-sometimes-50-slower-how-intel-has-broken-existing-code/
https://github.com/dotnet/coreclr/issues/13388
https://news.ycombinator.com/item?id=17336853

The pause instruction sleeps 14x longer on Skylake, so these loops will take 14x longer.

FYI, this was put into use in bf0fa8680fc so this should probably be closed. Any discussion about the number of times it should be called (which doesn't appear to have changed) would perhaps make sense as a separate issue.

The code currently uses spin_loop_hint, so this issue can be closed.


Relax faraday version range constraint to allow newer Rubies

Closes https://github.com/librato/librato-metrics/issues/142.

This pull request relaxes the faraday version constraint so that consumers of this gem can use newer versions of faraday that support Ruby 2.7.
Please note that this pull request targets the librato-metrics 1.x branch, as some Librato customers cannot upgrade to 2.x.
Because faraday 1.0 introduces a breaking change regarding the namespacing of its error classes, this pull request updates the Faraday::Error::ConnectionFailed reference to use Faraday::ConnectionFailed instead. This change is backwards compatible with older versions of faraday. Without that change, you see the following failure when running the test suite with faraday 1.0.0:
$ bundle exec rake
bin/ruby -S bundle exec rspec --color spec/unit/metrics/aggregator_spec.rb spec/unit/metrics/client_spec.rb spec/unit/metrics/connection_spec.rb spec/unit/metrics/queue/autosubmission_spec.rb spec/unit/metrics/queue_spec.rb spec/unit/metrics_spec.rb
........................................F.....................................................

Failures:

  1) Librato::Metrics::Connection network operations with 400 class errors should not retry
     Failure/Error: lambda {
       expected Librato::Metrics::NotFound, got #<NameError: uninitialized constant Faraday::Error::ConnectionFailed
       Did you mean?  Faraday::ConnectionFailed>
     # ./spec/unit/metrics/connection_spec.rb:70:in `block (5 levels) in <module:Metrics>'
     # ./spec/unit/metrics/connection_spec.rb:69:in `block (4 levels) in <module:Metrics>'

Finished in 4.03 seconds
94 examples, 1 failure

Failed examples:

rspec ./spec/unit/metrics/connection_spec.rb:67 # Librato::Metrics::Connection network operations with 400 class errors should not retry
rake aborted!
ruby -S bundle exec rspec --color spec/unit/metrics/aggregator_spec.rb spec/unit/metrics/client_spec.rb spec/unit/metrics/connection_spec.rb spec/unit/metrics/queue/autosubmission_spec.rb spec/unit/metrics/queue_spec.rb spec/unit/metrics_spec.rb failed
/private/tmp/librato-metrics/Rakefile:28:in `block in <top (required)>'
bin/bundle:23:in `load'
bin/bundle:23:in `<main>'
Command failed with status (1): [bin/ruby -S...]
/private/tmp/librato-metrics/Rakefile:28:in `block in <top (required)>'
bin/bundle:23:in `load'
bin/bundle:23:in `<main>'
Tasks: TOP => default => spec
(See full trace by running task with --trace)

Can you and @magni- and @irphilli try this out in production applications and report back on how it goes for you?

@akahn We've been using a fork of the 1.x branch with the relaxed constraint (with faraday v0.17.3) on our main app at @rainforestapp for three months now, no issues.


standards records: data cleaning on cds

Change the  migration rule:

084__c -> Subjects classification / Scheme: ICS / Subject value
962: Relation "other
962__b: record id of related field
962__k: relation "other" "is chapter of the book"


Ignore files

I am trying to run the program on a local directory and it is enumerating the ".venv" directory which is a Python virtual environment.
Or maybe a way to limit which directories to recurse into.

Also I can add that this adds some exceptions on some files which are not caught.


Fix decoupled batch statistics to account for implicit batch size

Previous PRs:

https://github.com/triton-inference-server/server/pull/7257
https://github.com/triton-inference-server/python_backend/pull/360

The decoupled metrics reporting should consider implicit batch size when reporting batch statistics. Previously, the batch statistics uses the number of requests as batch size, which does not account for batched request(s). Now, it is modified to take the number of requests multiplied by its respective implicit batch size.
Next PRs:

https://github.com/triton-inference-server/server/pull/7258
https://github.com/triton-inference-server/python_backend/pull/362

Rebase onto https://github.com/triton-inference-server/python_backend/tree/jacky-res-sender-main for merging.


[mempool] add v0 of peer manager

Motivation

Add peer manager for mempool that implements basic k-policy (k = min # broadcast recipients, and there are two classes of upstream peers: preferred (defined as upstream in config) and fallback (most likely from discovery set networks). If there are less than k preferred peers, pick more fallback peers)
add UpstreamConfig to better handle logic for determining whether a peer of a node is upstream or not

Notes/TODOs on top of this PR:

need to deprecate upstream_peers defined in state sync config, and refactor state sync peer manager to use UpstreamConfig
both mempool and state sync assume that peer_id of a node is a unique identifier. This is a false assumption - so we need to refactor mempool and state sync to uniquely identify a peer using (network_id, peer_id).
Add peer scoring schema for mempool

@bors-libra: r+

:pushpin: Commit 54ecb88 has been approved by phoenix-antigravity

:hourglass: Testing commit 54ecb8826b28e663c1f9b60297e8467ecfc6854a with merge c5bfa4e68f4274e756daf15e4a227beb5ab59b13...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: phoenix-antigravity
Pushing c5bfa4e68f4274e756daf15e4a227beb5ab59b13 to master...


Install doesn't work

I'm getting this error when I try to add it to a rails5 project.

There was a LoadError while loading administrate-field-nested_has_many.gemspec:
cannot load such file -- administrate/field/has_many from
/home/vagrant/.bundle/ruby/2.3.0/administrate-field-nested_has_many-a10b525ecdce/administrate-field-nested_has_many.gemspec:3:in `'
Does it try to require a relative path? That's been removed in Ruby 1.9.

Gemfile:
gem 'administrate', github: 'greetpoint/administrate', branch: 'rails5'
gem "administrate-field-nested_has_many", github: 'phaza/administrate-field-nested_has_many'

Reason for using forks is to get rails5 support.
I got nested_has_many to work by hardcoding the version in the gemspec (so it doesn't need to require anything to resolve dependencies), I assume the reason it barfs is because administrate isn't loaded at this time in bundler.

@phaza Were you able to work around this issue? I can develop with this gem just fine if I have administrate loaded on my system, but haven't found a clean way of deploying without resorting to hacks.

@phaza @bryanwoods  Do you still have this problem? The last version on master (1.0.0) has not been released on rubygems yet was tested on the last rails and administrate versions.

@bryanwoods @badosu Nah sorry, not doing rails dev anymore.

@badosu I migrated the project off administrate, sorry

@nickcharlton This can be closed as well


add possibility of using a config-drive for the cloud-init

Hi,
i think it would be very beneficial, if it was possible to use a config-drive (like with coreos), which mounts the cloud-config.yml to a default location.
E.g.: https://coreos.com/os/docs/latest/config-drive.html
regards,
strowi

RancherOS will currently use a config-drive if it detects it. It should work much in the same way as in the CoreOS docs, though we should really have docs of our own for this.

Thx for the answer.
Can you elaborate on how the drive will be detected and how/where it will be mounted?
I tried adding a drive with the mount_tag=config-2 but that didn't work..

I'm also curious how this works. I've built an iso with my cloud-config.yml in /openstack/latest/user_data. The iso is labeled config-2, so blkid -L config-2 returns /dev/sr1, but nothing appears to be mounted or utilized.
Running in kvm/qemu via libvirt.

@Klowner : i don't know what changed, but i got it working for my docker-kvm images.. take at the rancher-specific options here https://github.com/strowi/docker-kvm/blob/master/src/docker-entrypoint.sh


MenuItem conflict with specifity of Menu sub selector

https://github.com/tablecheck/tablekit/blob/464aefb265eb5b967b4376c5db90b081109be012/system/react/src/components/MenuList.ts#L24-L27
In the above-linked code the specificity of this selector means that the MenuItem cannot be overwritten in styles. We need to move this style to the MenuItem styles specifically.

Hi @SimeonC
I think the has been changed and this issue is not applicable now
https://github.com/tablecheck/tablekit/blob/next/system/react/src/components/MenuList.tsx


docs(advanced): Improve the Testing Form section

Hi!
eslint-plugin-testing-library author here. I've found many people following the wrong advice from the react-hook-form docs about how to fix the React Testing Library act() warning.
I've updated the docs and the examples, so it's on the same page as the official Testing Library best practices.

That was quick, thanks!

thank you @Belco90 🙏


[RFC] I3C Controller API

This introduces a basic API for I3C controller, and sample usage. This is developed using i.MX RT685 Evaluation Board (part number MIMXRT685-EVK) and the X-NUCLEO-IKS01A3 add-on board (especially the LSM6DSO sensor onboard).
Requires https://github.com/zephyrproject-rtos/hal_nxp/pull/171
Here are a few things that have been working with LSM6DSO:

Broadcast RSTDAA works.
SETDASA works for LSM6DSO with address 0x6B.
GETBCR/GETDCR works.
Able to get chip ID (0x6C) from the sensor.

There are still a few things to be done:

[x] Make LPH22HH sample app work via I3C

[x] lps22hh_init_chip finishes without error

[x] Polling mode working

[x] Trigger mode working

[x] DAA works (with LSM6DSO0)
[x] IBI for the MCUX driver.
[x] IBI for LPS22HH
[x] #define for register value (shift, mask, etc.)
[x] More helpers functions for CCC.
[x] Reconsider the I2C portion of the API => Using a virtual controller as a bridge.

I think this is awesome that i3c could come to Zephyr!!! 🥳 I've been working a lot with i3c myself, and have maintained zephyr drivers for i3c devices internally (within our company) and controllers, but as none of these are "off-the-shelf" IPs for microcontrollers like that NXP you've got there, this has made upstreaming our work somewhat useless for the meantime...
Overall, I think this is a really great start and I have a lot of comments about this work.

AspeedTech zephyr I3C: https://github.com/AspeedTech-BMC/zephyr/tree/aspeed-main-v2.6.0/drivers/i3c

Do you happen to have a link to the publicly available datasheet?

I only know that the controller ip they use isDesignWare MIPI I3C Controller IP

Added a translation layer between I2C and I3C, the I2C virtual controller, so that I2C device drivers can be used without any modifications.

Added a translation layer between I2C and I3C, the I2C virtual controller, so that I2C device drivers can be used without any modifications.

yeah, that looks like another good option :+1:  ... but with all the possible solutions that don't require any driver modifications, I see minor pros and cons between them all and could go any way with them...

While I think the virtual controller as a bridge is good for the device tree with binding. I think it would still be good to have the i2c_driver_api within the i3c_driver_api rather than reinventing the wheel here with new i2c function apis (and defines) within the i3c api. My concern is about maintainability. All i3c devices support i2c (to an extent..) and controllers should all support the existing i2c functionality within the zephyr i2c, as well as if any future defines or apis are added to the i2c layer, that will carry in to the i3c.  For example, I got to get an i3c controller working as an i2c target for me, and there already is an existing i2c api for targets. It would make sense for an i3c controller driver to just extend in to the i2c_driver_api for the target functions.
The only exception would the i2c attaching function for adding it into the slist required by i3c for bus mode and DEFTGTS which you've already got figured out...
It also would make the virtual layer much more straight forward with calling it's parent's i2c api functions.
__subsystem struct i3c_driver_api {
    struct i2c_driver_api i2c_api;
    /* rest of the i3c api */

Finally enabled LPS22HH IBI. This is now ready to be reviewed.
Note that I dropped the changes to LSM6DSO as I can unable to get IBI to work. LSM6DSO reports IBI payload length to be 9 bytes. The MCUX controller sometimes gets back 7 bytes, sometimes 8 bytes, and then the SCL stops pulsing even though RX FIFO has space (and no pending bytes too). This may be due to the hardware FIFO being 8 bytes on RT685, and auto IBI doesn't know how to deal with this situation.
Another thing is that the controller driver was re-written to not use the NXP HAL. There were some instances where the HAL would call the IBI callback multiple times with smaller chunks of the whole IBI payload. There were usually a callback storm after that, sometimes non-stop. So it would be great if someone from NXP can enhancement the driver down the road.

API meeting:

Overall there are no objections to this with the exception of the virtual I2C controller approach
@galak is concerned about the requirement to add Devicetree nodes for the virtual controller
@bjarki-trackunit suggests to use the multi-API work ongoing in #48817 instead of having a separate instance of struct device

@dcpleung I suggest we try to find an approach for the virtual controller DT bindings that @galak can be happy with, while @bjarki-trackunit's work progresses. Depending on what gets merged first then, we decide on which approach to use

What was the resolution to this comment:
https://github.com/zephyrproject-rtos/zephyr/pull/46087#discussion_r885023910
Seems to be a solution that would NOT require the virtual bridge

@galak https://github.com/zephyrproject-rtos/zephyr/issues/29986 contains another proposal.
Note that for I2C devices on I3C bus, the reg property needs to have three elements (matching what the Linux kernel has). If DT_REG_ADDR() is used, the value would be combination of all three (resulting in a 96-bit integer), which cannot be used with I2C_DT_SPEC_GET() (as addr is uint16_t), and any drivers using DT_REG_ADDR() for device address. Without the virtual controller, we will need to change the I2C_DT_SPEC_GET() macro and those drivers to only get the first element of reg. We could also deviate from what the Linux kernel on the DTS binding, but we will need to store the LVR (Legacy Virtual Register) separately.

What was the resolution to this comment:
#46087 (comment)
Seems to be a solution that would NOT require the virtual bridge

Though the issue with DT_REG_ADDR() is still there. (See above comment)

I have given it more thoughts and I believe there might be some misunderstandings on the API. On the I2C side, the introduction of the LVR (Legacy Virtual Register, associated with the device which describes the characteristic of the I2C device, e.g. if it can tolerate high SCL rate) requires I2C devices to be registered with the I3C controller so the controller can be initialized accordingly (for example, if a I2C device cannot do more than fast mode and not tolerant of high SCL rate, the whole bus is limited to fast mode speed). The virtual controller is there to facilitate I2C registration with the I3C controller. This is why the I3C controller does not provide the exact I2C API to I2C devices (by declaring the I2C api first in the I3C API struct) to (kind of) force developers to be aware of capabilities of all devices on the bus (and not simply blindly mixing I2C and I3C devices).
Hopefully this clarifies a bit on why the virtual controller is there. Even with using multi-API interface, the device registration step should not be skipped for I2C devices.

@galak #29986 contains another proposal.
Note that for I2C devices on I3C bus, the reg property needs to have three elements (matching what the Linux kernel has). If DT_REG_ADDR() is used, the value would be combination of all three (resulting in a 96-bit integer), which cannot be used with I2C_DT_SPEC_GET() (as addr is uint16_t), and any drivers using DT_REG_ADDR() for device address. Without the virtual controller, we will need to change the I2C_DT_SPEC_GET() macro and those drivers to only get the first element of reg. We could also deviate from what the Linux kernel on the DTS binding, but we will need to store the LVR (Legacy Virtual Register) separately.

I think this its reasonable to introduce I2C_DT_REG_ADDR that handles give you back a sane value based on being on a I2C or I3C bus.

I have given it more thoughts and I believe there might be some misunderstandings on the API. On the I2C side, the introduction of the LVR (Legacy Virtual Register, associated with the device which describes the characteristic of the I2C device, e.g. if it can tolerate high SCL rate) requires I2C devices to be registered with the I3C controller so the controller can be initialized accordingly (for example, if a I2C device cannot do more than fast mode and not tolerant of high SCL rate, the whole bus is limited to fast mode speed). The virtual controller is there to facilitate I2C registration with the I3C controller. This is why the I3C controller does not provide the exact I2C API to I2C devices (by declaring the I2C api first in the I3C API struct) to (kind of) force developers to be aware of capabilities of all devices on the bus (and not simply blindly mixing I2C and I3C devices).
Hopefully this clarifies a bit on why the virtual controller is there. Even with using multi-API interface, the device registration step should not be skipped for I2C devices.

so who is responsible for defining these limitations?  Are they properties of the virtual controller?  Are we missing APIs in I2C to convey what devices are capable of on the bus?  Not sure I quite understand how your example of a I2C device being limited to 'fast mode' would actually work.

I have given it more thoughts and I believe there might be some misunderstandings on the API. On the I2C side, the introduction of the LVR (Legacy Virtual Register, associated with the device which describes the characteristic of the I2C device, e.g. if it can tolerate high SCL rate) requires I2C devices to be registered with the I3C controller so the controller can be initialized accordingly (for example, if a I2C device cannot do more than fast mode and not tolerant of high SCL rate, the whole bus is limited to fast mode speed). The virtual controller is there to facilitate I2C registration with the I3C controller. This is why the I3C controller does not provide the exact I2C API to I2C devices (by declaring the I2C api first in the I3C API struct) to (kind of) force developers to be aware of capabilities of all devices on the bus (and not simply blindly mixing I2C and I3C devices).
Hopefully this clarifies a bit on why the virtual controller is there. Even with using multi-API interface, the device registration step should not be skipped for I2C devices.

so who is responsible for defining these limitations? Are they properties of the virtual controller? Are we missing APIs in I2C to convey what devices are capable of on the bus? Not sure I quite understand how your example of a I2C device being limited to 'fast mode' would actually work.

The capability is encoded in the LVR, which is the 3rd element in reg. LVR is for I2C devices under I3C bus (and is introduced along with the I3C spec). This needs to be populated by the developers in devicetree.
According to the spec, I3C devices can do 12MHz. However, the spec says that only fast mode and fast mode plus are supported for I2C devices (at least officially). In addition to this, if the I2C device has a 50ns spike filter on SCL, the controller hardware can generate SCL so SCL pulses are short enough for the I2C devices to ignore them. In this case, I3C devices can still go up to 12MHz (as I2C devices do not see pulsing SCL). However, if any I2C devices on bus does not have the spike filter, the bus is then limited to the highest speed this I2C device can support (which is fast or fast+). Whether the I2C device has spike filter, and its highest supported speed are encoded in the LVR (and thus in the devicetree).

@galak #29986 contains another proposal.
Note that for I2C devices on I3C bus, the reg property needs to have three elements (matching what the Linux kernel has). If DT_REG_ADDR() is used, the value would be combination of all three (resulting in a 96-bit integer), which cannot be used with I2C_DT_SPEC_GET() (as addr is uint16_t), and any drivers using DT_REG_ADDR() for device address. Without the virtual controller, we will need to change the I2C_DT_SPEC_GET() macro and those drivers to only get the first element of reg. We could also deviate from what the Linux kernel on the DTS binding, but we will need to store the LVR (Legacy Virtual Register) separately.

I think this its reasonable to introduce I2C_DT_REG_ADDR that handles give you back a sane value based on being on a I2C or I3C bus.

This will probably depend on controller implementation. The current i3c_i2c_device_desc struct has a field for controller to store private information. If we use macro to produce a static struct, the private data is not going to be there. The controller may not be able to function correctly without this data.
I know of a controller where you need to program the registers to specify what devices are on the bus (... think lookup table in hardware). The index to the entries in the table is then used for data transfer operations. In other word, the driver does not tell the hardware which device address to use, but instead an index in the lookup table. So the private data field described above can be used to store the index. Or else every transaction requires looping through the table to find the index.

The capability is encoded in the LVR, which is the 3rd element in reg. LVR is for I2C devices under I3C bus (and is introduced along with the I3C spec). This needs to be populated by the developers in devicetree.
According to the spec, I3C devices can do 12MHz. However, the spec says that only fast mode and fast mode plus are supported for I2C devices (at least officially). In addition to this, if the I2C device has a 50ns spike filter on SCL, the controller hardware can generate SCL so SCL pulses are short enough for the I2C devices to ignore them. In this case, I3C devices can still go up to 12MHz (as I2C devices do not see pulsing SCL). However, if any I2C devices on bus does not have the spike filter, the bus is then limited to the highest speed this I2C device can support (which is fast or fast+). Whether the I2C device has spike filter, and its highest supported speed are encoded in the LVR (and thus in the devicetree).

So we need to make some change to I2C than to pass the LVR value to the controller?

I get that, but seems like you'd than need to have an associate for each I2C device with an LVR value for that device (rather than on general LVR value).  So that feels like a mess to encode in devicetree.  I think its better to work with @teburd and figure out what minor tweaks we make to the I2C layer to handle this.

I get that, but seems like you'd than need to have an associate for each I2C device with an LVR value for that device (rather than on general LVR value). So that feels like a mess to encode in devicetree. I think its better to work with @teburd and figure out what minor tweaks we make to the I2C layer to handle this.

If I may say I really like that the implementation enables backwards compatibility with existing I2C devices through the virtual controller without requiring device drivers to be updated. It's a fantastic feature of this PR, and something @XenuIsWatching made a strong point to push for.
That said I get the concerns about applying the term and information for LVR to all I2C devices on the virtual controller as the spec describes it as a per device register.
LVR however is a lowest common denominator description of device capabilities. If even one device doesn't have the 50ns spike filter, its as if none of them have it. If even one device doesn't tolerate high data rates then its as if none of them do. So while the spec says LVR is a per device attribute for the purposes of Zephyr and ease of compatibility I actually agree with @dcpleung's approach here in making it a bus property that applies to all devices under it. It's closer, in that regard, to being akin to the i2c bus speed property.
That said, it might be sensible (as there are reserved bits in LVR) to more explicitly break out the properties of LVR into named bus attributes in device tree for the virtual i2c controller to avoid the confusion with the spec. Something along the lines of "hdr_tolerant" and reusing the existing speed property. Properties that would directly tie into the LVR indexes noted in the spec for describing device compatibility with higher data rates.

So what happens when someone wants to use a devicetree from linux that supports I3C and has LVR specified per device?

@teburd So what happens when someone wants to use a devicetree from linux that supports I3C and has LVR specified per device - for I2C devices?

In this case, the driver will need to be changed so it can instantiate an instance under I3C bus.
I understand that on Linux, you can have both I2C and I3C devices under I3C bus. The driver layer takes care of device registration. However, that depends on dynamic memory allocation (for bus-related device structs) at runtime which we are trying to avoid here. Moreover, we don't have binary devicetree in memory to grab info at runtime, which is also required for automatic device registration.
On Zephyr, all active devices declared under the I3C bus need to register themselves with the controller. And their drivers need to call the corresponding functions, and to declare the bus-related device structs themselves. Therefore, if you want to declare an I2C device directly under I3C bus in devicetree, the driver needs to be modified to work under I3C bus. The virtual controller is there for developers who wants to use the drivers as-is, and the virtual controller also takes care of device registration. This requires minimum work to be done to enable using I2C devices under I3C bus.

In this case, the driver will need to be changed so it can instantiate an instance under I3C bus.

which driver?  The bus or client?

I understand that on Linux, you can have both I2C and I3C devices under I3C bus. The driver layer takes care of device registration. However, that depends on dynamic memory allocation (for bus-related device structs) at runtime which we are trying to avoid here. Moreover, we don't have binary devicetree in memory to grab info at runtime, which is also required for automatic device registration.
On Zephyr, all active devices declared under the I3C bus need to register themselves with the controller. And their drivers need to call the corresponding functions, and to declare the bus-related device structs themselves. Therefore, if you want to declare an I2C device directly under I3C bus in devicetree, the driver needs to be modified to work under I3C bus. The virtual controller is there for developers who wants to use the drivers as-is, and the virtual controller also takes care of device registration. This requires minimum work to be done to enable using I2C devices under I3C bus.

What would this code look like to modify a driver to support this?  I'm asking we look at doing that NOW as proper and full I3C support.  I'm fully aware of the static driver model and devicetree support in Zephyr.  I'd like to understand what is required to modify a driver to utilize I2C but be directly on the I3C bus.

The driver for the target device (client) will need to be modified.
As for modification, you can take a look at the changes in LPS22HH, commit https://github.com/zephyrproject-rtos/zephyr/pull/46087/commits/110ee1dd421e9f50aa58d1794cf869dc40add8ec. The changes required are in:

lps22hh.c, line 291 - 355 (where i3c_device_register() would be i3c_i2c_device_register()). Most of the lines would simply be a straight copy from the I2C version (or even can be re-used without copying).
lps22hh.c, line 26 - 28, and line 74 - 76 (where struct i3c_device_desc would be struct i3c_i2c_device_desc).
Kconfig, line 11.
Other changes in the files are related to operating the sensor in I3C mode.

For for the desc/spec, seems like we can easily modify the existing i2c_dt_spec as follows to support either I2C or I3C:
struct i2c_dt_spec {
        const struct device *bus;
        uint16_t addr;
#ifdef CONFIG_I3C
        uint8_t lvr;
#endif
};

#define I2C_DT_SPEC_GET_ON_I3C(node_id) \
        .bus = DEVICE_DT_GET(DT_BUS(node_id)),  \
        .addr = DT_PROP_BY_IDX(node_id, reg, 0),\
        .lvr = DT_PROP_BY_IDX(node_id, reg, 2), \

#define I2C_DT_SPEC_GET_ON_I2C(node_id) \
        .bus = DEVICE_DT_GET(DT_BUS(node_id)),  \
        .addr = DT_REG_ADDR(node_id),\

#define I2C_DT_SPEC_GET(node_id)                                \
        {                                                       \
                COND_CODE_1(DT_INST_ON_BUS(inst, i3c),          \
                            (I2C_DT_SPEC_GET_ON_I3C(inst)),     \
                            (I2C_DT_SPEC_GET_ON_I2C(inst)))     \
        }

As for what i3c_i2c_device_register is doing, seems like we can easily walk all the children of the I3C controller and build whatever table/lists: DT_FOREACH_CHILD_STATUS_OKAY(I3C_CTRL, INIT_I2C_LIST).
#define INIT_I2C_LIST(node) IF_ENABLED(DT_IS_NODE_I2C(node), INIT_I2C(node))

#define INIT_I2C(node)  i3c_dev_list_i2c_devce_add(dev_list, DT_REG_ADDR(node))

If we are okay with changing the I2C subsys.
Note that struct i3c_i2c_device_desc has an extra element to store controller private data. As I have mentioned above, some controllers do not use target device address for transfers, instead, they use an index to a hardware lookup table. This can be stored in this private data field. If we are to create a static struct every time we call I2C transfer functions, the I3C controller driver will need to go through some lookup table to grab the index for every call to transfer functions (not just once per transaction, since we have no way of passing the index around between function calls). Of course, if everyeone is okay with the I3C API interface embedding the I2C API in addition to all the i3c_i2c_*() APIs. So that the driver can decide whether they want to incur the penalty of going through the lookup data. (Though, if we are not using this type of controllers, then we don't need to pay the speed penalty, but simply space penalty for extra code.)

For the HW lookup table case -- is there any difference between the virtual i2c bus case and what I'm suggesting.  Since it seems like in both cases you have to maintain a software table to associate the struct device with the index.

If we want to maintain straight compatibility to I2C, we will need to accommodate the use case where i2c_transfer() will be called with I2C_DT_SPEC_GET(). And everytime I2C_DT_SPEC_GET() is used, a new struct is created (mostly in stack). If we totally throw out this use case, then the only difference is the extra private data field. Every new struct would not have the private data, and would mostly be zero. And now the controller needs logic to distinguish between some private data (which could be zero), and an uninitialized field of zero. Or we can totally skip the private data and use the I2C device address all the time, with index lookup if necessary. However, if we do away with the private data, it will go out of sync with the equivalent I3C device desc struct which (also) has the private data field.
Let me elaborate a bit more on the lookup table. The controller I described has the lookup table in hardware (whether in its SRAM or a larger register file). The index stored in the struct is the entry index to this hardware table. Without this being stored, looking up the index needs to go through the hardware/SoC bus (e.g. MMIO) to the controller hardware.

I'm not sure I follow what it matters about how the compiler is dealing with I2C_DT_SPEC_GET.  The point is you need somewhere to associate the 'client device' with the 'HW table index'.  That is either:
A. some kinda of software lookup table that maps struct device to HW table index
B. its kept with the struct device in a common way.
A. means NO change to existing I2C client drivers, but cost in doing the mapping in software for every transaction.  (This would need to be done for virtual bus or solution in which I2C drivers end up calling directly on a I3C struct device).
B. means changing the existing I2C client drivers to maintain some common data.

With I2C_DT_SPEC_GET() and the I2C API, it is possible for application to init transfers without the driver. So this would be a real concern.
I have given it more thoughts on your proposal. This would require some re-architecturing of the whole subsys. Since the FOREACH macro will go through every child node and add I2C devices into the list, modified drivers will not need to register themselves anymore. To be consistent, the I3C side will also need to be converted to this model of auto registration. The I3C and modified I2C drivers will need a way to get the auto-generated device descriptor struct back for their own use.
And another issue is that it still requires implementing I3C specific stuff in the I2C layer. This will be up to the I2C maintainer to decide. I wish to get a go-ahead on this before spending time into re-writing this PR.

And another issue is that it still requires implementing I3C specific stuff in the I2C layer. This will be up to the I2C maintainer to decide. I wish to get a go-ahead on this before spending time into re-writing this PR.

Total understand and agree.  Lets see if we can bring this up again on Tue (8/23) in the Arch meeting if you and @teburd can join.  I think it would be good to get input from others as well.

@dcpleung Just curious, does the NXP hardware use a HW lookup table, or is that some other hardware you are looking at?

API meeting:

@galak has proposed alternatives to the virtual bridge, which has a clear downside in terms of Devicetree layout incompatibilities
@dcpleung sees a path forward to implementing I2C support without the virtual bridge
@galak suggests dropping I2C support in I3C buses for now so that the PR can be merged, and solve the I2C in I3C problem later
@dcpleung decide whether to drop I2C or implement it without a virtual bridge

@dcpleung Just curious, does the NXP hardware use a HW lookup table, or is that some other hardware you are looking at?

Not the NXP. The one with hardware lookup table is from another vendor. I don't know of any public hardware with that IP block yet (and thus no publicly available datasheet).

Updated the PR so that I2C devices can function without modifications on I3C bus without the virtual controller:

Has to modify DTS bindings and macro generations to support lists in bus:.
Added the native I2C API struct in the beginning of I3C API so I2C devices can call I2C API directly.
Modified I2C_DT_SPEC_GET() so that it can work on both I2C and I3C buses.
The device descriptors are now created by the controller drivers. So downstream devices will need to grab their corresponding device descriptors during their init functions and store the pointer for future I3C API calls.
** This eliminates the need for downstream devices to register themselves to the controller. Therefore there is no need to have multiple init priorities to accommodate device registration, and now combined as one init priotiry.

CI failure is due to tests/subsys/logging/log_stack/logging.log_stack_immediate which is unrelated to this PR.

Unrelated failing test: tests/net/tcp/net.tcp.no_recv_queue on mps2_an385.

@galak could you take a look and see if this addresses your issue?

@dcpleung thanks.  In general the approach now looks a lot better.  I do have some comments, at a high level:

Would like @mbolivar-nordic to comment on the the edtlib changes (would ask maybe to pull those out into their own PR) and add some testcases to edtlib
The nxp I3C controller is actually a silvaco IP based controller, so we should look at renaming it a little for any future SoCs that might use that same controller to just have one driver.  Also should look to use the binding for silvaco (in addition to nxp... https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/i3c/silvaco,i3c-master.yaml
Wonder what thoughts are on splitting up include/zephyr/drivers/i3c.h further.  Maybe pulling the devicetree stuff into include/zephyr/drivers/i3c/devicetree.h.  Moving 'target' mode support into its own header (if we should even support it right now).
Do we need to support i3c targets right now?  Would suggest we maybe drop this for right now until we have a need / have an implementation of target support.
The whole device tracking  / device_find bits feel like we need more work.  Is this related to the controllers that need to build a lookup table?

@dcpleung I have other coding related comments, but will provide them later this week when I have better connectivity/back from vacation.

The nxp I3C controller is actually a silvaco IP based controller, so we should look at renaming it a little for any future SoCs that might use that same controller to just have one driver.  Also should look to use the binding for silvaco (in addition to nxp... https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/i3c/silvaco,i3c-master.yaml

Could you be certain that there is no customization of this IP in NXP SoC? I am worried that there might be some differences which require vendor-specific code down the line.

Wonder what thoughts are on splitting up include/zephyr/drivers/i3c.h further.  Maybe pulling the devicetree stuff into include/zephyr/drivers/i3c/devicetree.h.  Moving 'target' mode support into its own header (if we should even support it right now).

I simply modeled this after i2c.h as everything is cramped into i2c.h.

The whole device tracking  / device_find bits feel like we need more work.  Is this related to the controllers that need to build a lookup table?

Those functions are needed since the controller driver is now responsible for creating the device descriptors (instead of each target device driver doing this on its own, and registering the struct with the controller). So that each target device driver needs to grab a reference to its own device descriptor from the controller. I3C devices need to match the PID (which should be unique for all devices on a board) as addresses are dynamically assigned (so they can't be used for matching). I2C devices are easy as their addresses are static so these can be used to match 1-to-1. The device descriptors for I3C devices are a must to store runtime information, and for I2C devices, they are indeed there to aid with the hardware lookup table (if needed).

The nxp I3C controller is actually a silvaco IP based controller, so we should look at renaming it a little for any future SoCs that might use that same controller to just have one driver.  Also should look to use the binding for silvaco (in addition to nxp... https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/i3c/silvaco,i3c-master.yaml

Could you be certain that there is no customization of this IP in NXP SoC? I am worried that there might be some differences which require vendor-specific code down the line.

I think when those show up we can refactor things a bit.  I don't want to get into a situation where we have multiple drivers for the same exact IP.  So I think it makes sense to at least acknowledge the silvaco via devicetree and maybe filename/Kconfig names right now.

Wonder what thoughts are on splitting up include/zephyr/drivers/i3c.h further.  Maybe pulling the devicetree stuff into include/zephyr/drivers/i3c/devicetree.h.  Moving 'target' mode support into its own header (if we should even support it right now).

I simply modeled this after i2c.h as everything is cramped into i2c.h.

Just because i2c.h does it doesn't make it a good idea ;).

The whole device tracking  / device_find bits feel like we need more work.  Is this related to the controllers that need to build a lookup table?

Those functions are needed since the controller driver is now responsible for creating the device descriptors (instead of each target device driver doing this on its own, and registering the struct with the controller). So that each target device driver needs to grab a reference to its own device descriptor from the controller. I3C devices need to match the PID (which should be unique for all devices on a board) as addresses are dynamically assigned (so they can't be used for matching). I2C devices are easy as their addresses are static so these can be used to match 1-to-1. The device descriptors for I3C devices are a must to store runtime information, and for I2C devices, they are indeed there to aid with the hardware lookup table (if needed).

when are the i3c_i2c_* functions needed now?

The nxp I3C controller is actually a silvaco IP based controller, so we should look at renaming it a little for any future SoCs that might use that same controller to just have one driver.  Also should look to use the binding for silvaco (in addition to nxp... https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/i3c/silvaco,i3c-master.yaml

Could you be certain that there is no customization of this IP in NXP SoC? I am worried that there might be some differences which require vendor-specific code down the line.

I think when those show up we can refactor things a bit. I don't want to get into a situation where we have multiple drivers for the same exact IP. So I think it makes sense to at least acknowledge the silvaco via devicetree and maybe filename/Kconfig names right now.

I am a bit reluctant to make this change, as this is something that I cannot verify on my own (that it is IP from Silvaco), and yet my name is behind the commit.
If you insist, I can make the change. Though I will need to mention you in the commit message as the one asserting it is a Silvaco IP.
Please let me know what you want me to do.

when are the i3c_i2c_* functions needed now?

If the downstream driver decides to use native I3C API for I2C operations. They can still use the native I2C API, but every call will incur an additional cost of needing to walk the descriptor table.

I am a bit reluctant to make this change, as this is something that I cannot verify on my own (that it is IP from Silvaco), and yet my name is behind the commit.
If you insist, I can make the change. Though I will need to mention you in the commit message as the one asserting it is a Silvaco IP.
Please let me know what you want me to do.

Let's ask one of the NXP guys to chime in on this.  @dleach02 @danieldegrasse @yvanderv can you confirm that the I3C controller on the MCU devices is based on the Silvaco IP.  [ https://silvaco.com/news/silvaco-launches-mipi-i3c℠-sensor-connectivity-ip-family/ ]

New changes:

Devicetree:
** Updated in edtlib.py where the Node class to have 'buses' and 'on-buses' so they are both lists. For Binding node, added 'buses' to return a list of bus(es), though there is no 'on-buses' as this is supposed to be a single string.
** Added to the devicetree API to make sure multi-bus is working correctly.
Factored out the devicetree macros and target device API from i3c.h into their respective headers.

when are the i3c_i2c_* functions needed now?

If the downstream driver decides to use native I3C API for I2C operations. They can still use the native I2C API, but every call will incur an additional cost of needing to walk the descriptor table.

Seems like an I2C device should use the I2C API, I don't think we want drivers that will not work with I2C controllers because they happen to use the i3c_i2c_* api.

when are the i3c_i2c_* functions needed now?

If the downstream driver decides to use native I3C API for I2C operations. They can still use the native I2C API, but every call will incur an additional cost of needing to walk the descriptor table.

Seems like an I2C device should use the I2C API, I don't think we want drivers that will not work with I2C controllers because they happen to use the i3c_i2c_* api.

Removed all those APIs.

@mbolivar-nordic  can you please take another look?

@galak @dcpleung  Trying to catch up with my time here... but it looks like the conversation lead to somewhere I don't think i3c is built for. The i3c and i2c device list is now fixed with no run-time way of having this now. (What was wrong with the way it was originally done in an earlier review a did??)
The issue this can lead to is that i3c is hot-pluggable (unlike i2c). While Hotplug support is not in the zephyr i3c... yet. This will become an issue in the future. Where devices will need to be registered (and unregistered) at run time. I also see the slist nodes are left over in the i3c_device_desc and i3c_i2c_device_desc struct.
While having i2c devices listed at compile time makes 'some' sense with how i2c devices are defined to be fixed.... this can not work with i3c. For i2c, this could hamper an application if it needs to write to a 'specific' address that's not defined in the device tree, and there's no way to register the i2c address.... so i3c_i2c_device_find will always return an error for the i2c transaction.
I see a reference to i3c_device_register in the comments, but that api got removed. It would be better if those were brought back.