Any guidance for using this in an Expo app?

This works perfectly in my react native app but I'm having trouble getting this to work in very basic Expo v48.0.15 application.
Steps to reproduce:

npx create-expo-app --template
Choose Navigation (TypeScript) from list of templates
cd app-name
run yarn add react-native-devsettings
Add import react-native-devsettings to top of root index.ts file
Open React Native Debugger -> Press CMD-T to open port config menu  -> Update port to 19000
Start expo app with yarn expo start from project root
Wait for menu screen and select i to open iOS simulator
When simulator is booted, open dev menu and select "Open JS Debugger"

This will open the debugger in the default browser.

Unfortunately, expo don't export NativeModules.DevSettings so this package only works with React Native and Expo Bare.


首页视频无法正常播放

Describe the bug
写备忘时上传了一个视频，提交之后，点击播放无法正常播放，一片黑色界面，有声音，在资源库点击预览下载后的视频可以正常播放
Steps to reproduce
点击视频播放组件
Screenshots or additional context
在首页播放时就是这样，一片黑

另外请求优化一下现在播放组件，播放功能太少了，不能全屏，首页显示效果也很差，希望能和这个模块尽量等宽

The black video is probably not a bug.
As memos doesn't convert file formats, videos must use a container and codecs compatible with HTML5 specification and optimized for streaming. Otherwise, your browser won't be able to play them.
Prefer mp4/webm containers with H264/H265 for video and AAC/Opus for audio, and use a sane file bitrate that fits the server upload bandwidth, so the video won't buffer all the time.
Use Handbrake, VidCoder or Staxrip if your media needs conversion.

But I agree that the small video player needs some attention, as it's not a pleasant experience. That suits a feature request.

Thanks. I get it, is there any ways to solve It.🥲

Any updates for this issue?

As memos doesn't convert file formats, videos must use a container and codecs compatible with HTML5 specification and optimized for streaming. Otherwise, your browser won't be able to play them.


[ISSUE ##1052] Support request code LOCK_BATCH_MQ(41)

Which Issue(s) This PR Fixes(Closes)

Fixes #1052
Brief Description

How Did You Test This Change?

🚀Thanks for your contribution🎉. CodeRabbit(AI) will review your code first🔥


fix: Make Activity header divider lighter

Resolves https://www.notion.so/artsy/All-grey-lines-are-the-same-light-grey-Currently-in-the-build-the-top-line-is-darker-should-be-ch-1f007c0745654e1ca995194a294db279?pvs=4

https://github.com/artsy/palette-mobile/pull/192

Description
Make Activity header divider lighter.
PR Checklist

[ ] I have tested my changes on iOS and Android.
[ ] I hid my changes behind a feature flag, or they don't need one.
[ ] I have included screenshots or videos, or I have not changed the UI.
[ ] I have added tests, or my changes don't require any.
[ ] I added an app state migration, or my changes do not require one.
[ ] I have documented any follow-up work that this PR will require, or it does not require any.
[ ] I have added a changelog entry below, or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

Need help with something? Have a look at our docs, or get in touch with us.

Warnings

:warning:

❌ An error occurred while validating your changelog, please make sure you provided a valid changelog.

  Generated by :no_entry_sign: dangerJS against 9c5ce6acc6629e537a2666c1a78e88b741d8715c


feat: add CI step to package and publish Helm chart

What this PR does / why we need it?
This PR adds a CI step in GitHub Actions to package and publish a Helm chart. It also includes ArtifactHub annotations in the Chart.yaml file to provide additional metadata for ArtifactHub listings.
PR Checklist

[ ] This PR adds K8s exceptions (false positives)
[ ] This PR adds new code
[ ] This PR includes tests for new/existing code
[ ] This PR adds docs
[X] This PR adds to a workflow

GitHub Issue
#285
Notes for your reviewers

The CI workflow relies on a branch gh-pages to be created first and in Settings/Pages the Source Branch should be gh-pages.
The gh-pages branch should be created before this PR is merged.
Created ArtifactHub annotations (artifacthub.io/license and artifacthub.io/links) in Chart.yaml.
To add the chart to ArtifactHub, we need to create an ArtifactHub repository and submit another PR to add an artifacthub-repo.yml file and a README.md to the gh-pages branch. (example: https://github.com/kubernetes-sigs/metrics-server/tree/gh-pages)

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

Project coverage is 40.87%. Comparing base (ea85ff7) to head (5c9654e).
Report is 2 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #306   +/-   ##
=======================================
  Coverage   40.87%   40.87%
=======================================
  Files          58       58
  Lines        2953     2953
=======================================
  Hits         1207     1207
  Misses       1545     1545
  Partials      201      201

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

Created the branch.
@Yuni-sa can you rebase?

@yonahd


feat(sdk): implement support for gear vr

This is the PR #944 by @CoderDawson updated to the latest VRTK version.
Tested on Android/GearVR only the headset.
This is here mostly for @CoderDawson, if still interested.

There were the following issues with your Pull Request

Commit: b1e28ff8a6c0d6dead1d025a12a074045f0844ba
Your subject line is longer than 72 characters

Guidelines are available at https://github.com/thestonefox/SteamVR_Unity_Toolkit

This message was auto-generated by https://gitcop.com

I need GearVR support, so I am already working on this (I looked at CoderDawson branch and I haven't found updates).
I will make a pull request as soon as I finish testing and documenting the GearVR support (for now succesfully tested only for UI pointer and teleport). To @CoderDawson: I will make a new commit, excluding your previous commits, otherwise GitCop rejects also newer commits (see above). Anyway I will mention in the commit that is derived from your work.

You can just modify the commit messaging by using interactive rebasing. You probably want to squash all commits into one, though.

Yes, it's the best choice, I suppose. Thank you for the hint.


Interpretation of SHAP Values away from the mean

Hello,
I have a question about using SHAP values if the threshold for usage (e.g., getting offered a loan based on a model score) is below the average value of default. Specifically, how do you interpret and use the Shapley values?  Patrick Hall at H2O  (@jphall663) suggested I contact you about this.
For example, suppose you have a really simple model:
Pr(D=1) = f(FICO, Income)
Average Pr(D=1) = 10%, but only 3% are approved.  This type of situation is extremely common in lending.
For person i: y-hat = 6%, where SHAP_FICO = -3%, and SHAP_Income = -1% (implying that person i's FICO and Income are both better than the average, but not good enough to get them below the 3% hurdle).
I think most people's intuition is to say that Income should be the "primary driver" because it is "less good", relative to the average than FICO.  But I don't think that is right: what drives person-i from 3% up to 6% (i.e., the threshold for acceptance) could be different than what drove him/her from 10% down to 6%.  For example, if the model is nonlinear, I think that you could have a situation where this person's FICO drove them up 2% relative to the average accepted person, and Income drove them up 1% relative to the average accepted person.  In that case, you would want to pick FICO as the primary driver, which is the opposite of what one would think based on ranking from the average percent of defaults.  Am I right about that?  Do you have any thoughts on the right approach?
I would really appreciate any guidance or thoughts you have about any of this.  Thanks!

Great questions! SHAP values measure the impact of features by how much they change conditional expectations. Features will impact the conditional expectation most if they have "surprising" (i.e. rare) values and are also used strongly by the model. "Surprising" is always relative to some prior reference population. In the example you gave the reference population is all applicants and has a default rate of 10%. For person-i I would say FICO was the most informative feature, informative in the sense that it differentiates person-i from the average applicant in the eyes of the model. But as a person applying for the loan perhaps you don't care how you differ from the average applicant, perhaps you care more about how you differ from the typical accepted applicant. If that's the case then the "background" distribution used to compute SHAP values should probably not be a training set of all applicants, but instead just the set of accepted applicants. For a linear model this would just shift all SHAP values by the difference in the means between accepted applicants and all applicants. But for non-linear models it could in theory have a more complex effect on the values.
I should note that changing the background set is only supported for the feature_dependence="independent" option at the moment due to some technical details.
I should also note that explanations that have a very specific purpose (like how do I change my application so that I will be accepted) can be tailored to that purpose. For example, I can just tell you a list of changes that get you accepted and also minimize the deviation from the reference population. Now for the case of lenders, maybe they don't actually want to be that specific so as to minimize the "gaming" of their algorithms.

Scott – thanks for getting back to me so quickly.  I’ve been thinking about what you wrote regarding training on the accepted/rejected dataset, but that it required the use the independent feature option.  Given that would likely be a big shortcoming, I think I have come up with a way around it.  I’d like to get your take on my idea.
What do you think of this:  Using the truly accepted/declined data (i.e., 3% get accepted in my example above), you build a new model on that data (the label is acceptance, the features are the same features in the base model).  This is essentially a surrogate model.  It can be an xgb, random forest, or whatever.  Second, you calculate SHAP values using the surrogate model.  The advantage is that since you are using a complex model and the right features as the surrogate, you should be able to get very good accuracy and capture the underlying process of the original model, but with the mean shifted down to 3%.  If my intuition is right then the resulting SHAP values should be very close to the right answer.  But I may be missing some important points, and your thoughts would really be appreciated.
Thanks again for getting back to me – and thanks for putting together some great software.

@nickpschmidt this is one reason why I use monotonic XGBoost always -- makes these things easier to reason about. Hopefully that's another helpful hint (maybe you were already doing this).

Thanks @jphall663 - If I could get everyone to use monotonic constraints I would die a happy man.  :)
Personally, I like Spearman correlation because it only tests for monotonicity, rather than linearity.  And given the number of observations I work with, Spearman is sufficiently powerful that I do not really have to worry about false negatives.  The other thing I'll do is just run a polynomial regression and chart the expected values over the range of X.  But then you get into the von Neumann territory of "With four parameters I can fit an elephant, and with five I can make him wiggle his trunk."
I was just pointed to an article, https://arxiv.org/pdf/1702.05471.pdf that uses a method to calculate correlations between variables that I did not know of, where you do not assume monotonicity (that's only one step of what looks like a cool paper, but the one I'm most interested in right now).  I'm working my way through the paper and the idea seems quite interesting.

Sorry @nickpschmidt ... kept editing after I made that comment. Bad habit. See above if any of this is helpful. Thanks!

The way I calculate non-linear, non-monotonic "correlation" (dependency?, association?) is very simple: I just train a non-linear model between the two variables and see if they can predict each other. You can do this for each pair of features in a dataset and then range-standardize between the highest and lowest RMSE so you get what looks like a typical correlation matrix.
You can even build such tables locally, on a row-by-row basis, by looking at raw, absolute, or deviance residuals for each of the models at each point.
(To me this is super important in fairness, and people fail to realize this: multiple different features can act as proxies for each other to varying degrees at different local points in a dataset!!! Again, constrain, constrain, constrain your model! B/c you really have very little hope of reasoning through a fully nonlinear scenario ... IMO anyway. I know I am preaching to the choir :) )
(Not sure if that makes smart people cringe or not ... again I'm rambling so I'll stop.)

Very interesting conversation :) ...I'll just comment on what @nickpschmidt suggested at first: Yes, that makes sense, and if the surrogate (mimic) model is good enough then you would get what you wanted. But I don't think the independent twiddling of features is something that is necessarily bad. It does potentially allow you to evaluate the model on unrealistic combinations of features (a downside), but it comes with the benefit of using an "intervention" to detect which features the model really depends on (a positive). It would take a lot of time to dig into the tradeoff of how/if to share credit among correlated inputs, but as it relates to this question, I would feel better using feature_dependence="independent" than I would using a mimic model.

@slundberg, is there a source that I could read about the feature_dependence option?  I read the bit in your code about it, but I don't think I followed it sufficiently.  It may be a flaw of mine, but every time I read the word "independent" I assume "unlikely condition to hold".  During my copious amounts of free time, I plan to run it both ways on some simulated data that I put together.  If the results are interesting then I'll post them.
@jphall663, one thought that I had is that you could run a SUR with all of the variables stacked on the left-hand side, with the non-linear versions of the variables on the right-hand side.  Then you could compare the joint F-Test from the groups of non-linearities to test the proxy condition.  The nice thing about that is that the joint F-tests are independent of scale, so if the variables are not standardized you still have a comparable statistic, which I don't think you do if you are using the RMSE index.  That would be helpful if you are using binary or categorical variables in the model.
The general issue that I think we face with proxies though is that they can be created through multiple interactions, whereas this method only captures a one-on-one variable relationship.  One way you can test if a model is proxying for a protected class is to create the model, get the predictions, and then run the predictions against protected class indicators (whether binary or proportional).  If you find that the class coefficients are not significant then you have an indication that the model is not proxying for protected class status.  The problem is that if you do find significance, you cannot disprove proxying, because the significance of the coefficients can indicate either (1) that you have a proxy, or (2) that there are still class-correlated elements for which you cannot control.  The latter is generally more likely since class-correlated relationships are very strong and hard to completely identify.
Yesterday I came up with another idea for measuring proxies that I think is novel and might just work (though my first pass at it turned out to be totally wrong).  I won't write it out here until I see if it works in order to save me from excess embarrassment if it is wrong.

@nickpschmidt Sorry for the slow reply. I lost a battle with email this last month during a deadline push. Unfortunately I don't have much written up on that front yet. I have some figures built, and I'll try and post/publish/share them when I get a chance.

This question was answered in march, but I was wondering if there was any new paper or article explaining more in details how to use the feature_dependence option?  I think it was renamed to feature_perturbation="interventional" in issue #882.
I would be really interested in understanding more what this option allows you to do.  Maybe with real life data scenarios and how to interpret the results.
Thank you!

We have a paper coming out in a month that discusses this a bit. But the summary is that feature_perturbation="path_dependent" allows us to use the coverage information in the model to not need a background training dataset. The feature_perturbation="interventional" exactly matches the type of perturbation you would get with interventional conditional expectations, but needs to run over a provided background dataset (of usually 100 random samples or so). In most cases you should use the interventional option since over time I have found it to be a bit better, and also a couple recent papers argue for it. The path_dependent is sometimes faster though so that makes it nice. See #882 for an more details.
In practice the takeaway is that insights from causal statistics suggest that the interventional option is the right choice in most situations. There are two reasons you might want to use path_dependent instead: (1) you can use the training dataset for the background distribution that is implicitly encoded in the model (instead of explicitly defining the background dataset) and (2) it runs faster in some cases.

Thank you for your quick response!  Will definitely read the paper when it comes out.
One thing I am having difficulty understanding is the background dataset and when you would use a different background dataset than your training set.  You mentioned previously in this thread an example where maybe you want to know what are the factors that differentiate an observation from the people who were accepted for a loan instead of comparing them to the whole population.  So instead of using the training set as a background dataset maybe you can use only the accepted people.  But then how do we interpret the SHAP values?
Instead of using a background dataset containing only the accepted observations, could we filter the calculated SHAP values (without a background dataset, so using path_dependent) to only the observations that were accepted, aggregate the SHAP values per columns and compare those with an individual to see what features differed on average?
I found this example notebook in your repo that helped me understand a bit more: Explaining a simple OR function which uses a background dataset.
One final question concerning feature_perturbation="interventional".  From what I understand, when using this option when you do feature permutations to calculate shapeley values, you remove certain features during permutations and you use causal graph rules from causal stats (the do operator) instead? A bit like the dowhy sampler library from Microsoft.  But this doesn't mean we can make causal claims about the effects the SHAP values represents right?
Thanks!


feat: anvil API

What :computer:
Added evm_setAccountNonce, anvil_setNonce, anvil_impersonateAccount, anvil_stopImpersonatingAccount, anvil_mine, anvil_reset, anvil_setBalance, anvil_setCode and anvil_setStorageAt as aliases to the corresponding hardhat_* methods.
Why :hand:
Implements https://github.com/matter-labs/era-test-node/issues/160 .
Evidence :camera:
Extended e2e tests, which pass.

@vbar  what about other endpoints?
I checked the endpoints list here - https://book.getfoundry.sh/reference/anvil/
There are many more methods.

@vbar what about other endpoints? I checked the endpoints list here - https://book.getfoundry.sh/reference/anvil/ There are many more methods.

Well, yes, but not all of them can be supported by the test node - so I wanted to start with the obvious aliases...

@vbar  what about other endpoints?
I checked the endpoints list here - https://book.getfoundry.sh/reference/anvil/
There are many more methods.

The point of having anvil endpoints is so tools like Rivet work with era-test-node. We shouldn't be adding anvil_ endpoints if they aren't being used upstream.
To that end, there's no need to implement every endpoint. I would spin up that chrome extension tool and see what's required

The point of having anvil endpoints is so tools like Rivet work with era-test-node. We shouldn't be adding anvil_ endpoints if they aren't being used upstream.
To that end, there's no need to implement every endpoint. I would spin up that chrome extension tool and see what's required

Err, do you have a cookbook? I tried that, and it didn't work at all...

The point of having anvil endpoints is so tools like Rivet work with era-test-node. We shouldn't be adding anvil_ endpoints if they aren't being used upstream.
To that end, there's no need to implement every endpoint. I would spin up that chrome extension tool and see what's required

Err, do you have a cookbook? I tried that, and it didn't work at all...

Nope. They've made a lot of changes since I last got it barely working, so this requires some exploratory investigation

that's are endpoints probably used by River, but I am not sure. @vbar we need to check.
anvil_getLogs
Where did you get that? Not even Google knows... :-)

anvil_dropTransaction
Ah yes, I remember discussing that - cannot be supported in the test node.

that's are endpoints probably used by River, but I am not sure. @vbar we need to check.
anvil_getLogs

Where did you get that? Not even Google knows... :-)

anvil_dropTransaction

Ah yes, I remember discussing that - cannot be supported in the test node.

cannot be supported in the test node.

why?

anvil_dropTransaction

Ah yes, I remember discussing that - cannot be supported in the test node.

cannot be supported in the test node.

why?

IIRC because it should remove a transaction from the pool, but the test node has no pool.

Trying the Rivet extension:

API
status
note

evm_setAccountNonce
not used

anvil_setNonce
needed

anvil_impersonateAccount
not found

anvil_stopImpersonatingAccount
not found
probably gated by anvil_impersonateAccount

anvil_mine
needed

anvil_reset
not called against test node (but is against anvil)
listed as "planned feature"

anvil_setBalance
needed

anvil_setCode
Deploy button found but all bytecode put into it fails (against both anvil and test node)
listed as "planned feature"

anvil_setStorageAt
not found
listed as "planned feature"

anvil_setStorageAt,  anvil_impersonateAccount ,  anvil_stopImpersonatingAccount  - are used by rivet.
JFYI.


Allow configuring the Amber server the client connects to

Add a field to the repository configuration.

It looks like this was supported in 0.1.0, but not documented.


Building on PR #61 with more text additions

Would love to see this merged in, we're using the library in our app and a lot of our users rely on LaTeX primitives for formatting @kostub

Thanks!


BetterNether traits ideas

Material compatibility request
BetterNether material traits ideas
Modifier request
(Every suggestion can be tweaked to be more fair/less op/more balanced)
Ruby (Tier 4 material)
Melt ruby material on the foundry (blazing blood fuel needed)
Part trait: Ruby's fire
Description: Every attack will deal 5% more damage, 2 knockback blocks or ignite the target for 3 seconds, each level scaling the impact
Detalied explanation: Every attack will always inflict one of the possibilities. 1/3 chance of dealing more damage, 1/3 of dealing more knockback, and 1/3 of ingiting the target. This way it will be similar to "Ruby's fire" enchantment from BetterNether
Can be applied to a bow: Yes
Cincinnasite (Tier 3 material)
Melt cincinnasite material on the forge (lava or blazing blood)
Part trait: Obsidian Breaker
Description: Mines obsidian blocks 10% faster each level
Can be applied to a bow: No
Blue obsidian (Tier 3 material)
Cast molten blue obsidian on wood parts
Part trait: Obsidian shield
Description: After an attack, you have a 5% chance per level of blocking all the damage from an attack during 5 seconds. If the effect is triggered, it resets until you attack again. (Probable addition: if the target or yourself it's on fire, the chance it's doubled).
Can be applied to a bow: Yes
Nether reed (Tier 3 Bowstring/Binding only material)
Made on the parts table with Nether reed
Part trait: Heat fever
Description (on tools): Boosts mining speed when on fire OR when on the Nether
Description (on bows): Boosts draw speed when on fire OR when on the Nether
Additional context
Tried to make every material closest to what the mod offers in game

Though maybe Ruby should be a modifier instead (since in TiC you can't cast tool parts from gems).
Look: Diamond and Emerald are modifiers that buff certain stuff.

It's a good way to implement it
Maybe the modifier could go on armor also, but I feel like would be a reusage of the already existing modifiers from armor (thorns, fiery, springy)


Bar Codes seem to be busted (Stock Items & Parts)

Please verify that this bug has NOT been raised before.

[X] I checked and didn't find similar issue

Describe the bug*
Linking bar codes doesn't seem to work no matter what I do. I tried different browsers, different devices all produce the same error.
On my installation just recently updated to the latest development version: I click on link bar code and the console shows this error:
Uncaught ReferenceError: QrScanner is not defined
    barcodeDialog en.barcode.js:271
    jQuery 7
    trigger event-handler.js:305
    _showElement modal.js:246
    _ index.js:251
    a index.js:273
    s index.js:100
    b index.js:279
    setTimeout handler*b index.js:277
    _queueCallback base-component.js:45
    _showElement modal.js:251
    show modal.js:143
    _ index.js:251
    show backdrop.js:54
    _ index.js:251
    a index.js:273
    b index.js:276
    _emulateAnimation backdrop.js:126
    show backdrop.js:53
    _showBackdrop modal.js:309
    show modal.js:143
    jQueryInterface modal.js:384
    jQuery 2
    jQueryInterface modal.js:373
    openModal en.modals.js:708
    beforeSend en.modals.js:1014
    ajax jQuery
    launchModalForm en.modals.js:1116
    inventreeDocReady inventree.js:120
    jQuery 2
[en.barcode.js:271:9](https://bbbbb.dyndns.org/static/i18n/en.barcode.js)
Uncaught ReferenceError: QrScanner is not defined
    barcodeDialog en.barcode.js:271
    jQuery 7
    trigger event-handler.js:305
    _showElement modal.js:246
    _ index.js:251
    a index.js:273
    s index.js:100
    b index.js:279

I can enter the bar code, but the modal does not have a submit button. When I press enter, I'm presented with the following error:

On your demo instance, the behaviour is different. The console does not show the error and the camera starts if I click the camera icon. But when I enter the bar code manually, the modal closes immediately after I enter the first character. After that, my only option is to unlink the bar code again and I'm were I started.
Steps to Reproduce

Go to any part
click on link bar code

Expected behavior
I should be able to link a barcode.
Deployment Method

[X] Docker
[ ] Bare metal

Version Information
Your demo instance:
Version Information:
InvenTree-Version: 0.10.0 dev
Django Version: 3.2.16
Commit Hash: cd2495c
Commit Date: 2022-12-22
Database: postgresql
Debug-Mode: False
Deployed using Docker: True
Active plugins: False
My installation:
Version Information:
InvenTree-Version: 0.10.0 dev
Django Version: 3.2.16
Database: mysql
Debug-Mode: False
Deployed using Docker: True
Active plugins: []
Relevant log output
No response

Regarding the issue on your server - have you tried clearing out your browser cache? It looks like the javascript files are out of sync.
On the demo server, there is a "configurable" delay after data-entry in the barcode boxes. These entry boxes are intended to be used with USB barcode scanners, and so have a pretty short timeout by default. If you are testing by manually entering data, you'll want to increase this timeout.

@SchrodingersGat thank you very much for getting back to me! I already tried resetting the browser cache so I dug a little deeper.
I think this is caused by the static folder living in the inventree docker volume. Running grep results in:
/data/inventree_data/static$ grep -lR "QrScanner" * i18n/it.barcode.js i18n/id.barcode.js i18n/en.barcode.js i18n/he.barcode.js i18n/es.barcode.js i18n/es_MX.barcode.js i18n/nl.barcode.js i18n/da.barcode.js i18n/fa.barcode.js i18n/pt.barcode.js i18n/ja.barcode.js i18n/de.barcode.js i18n/hu.barcode.js i18n/zh.barcode.js i18n/ru.barcode.js i18n/vi.barcode.js i18n/th.barcode.js i18n/ko.barcode.js i18n/tr.barcode.js i18n/pl.barcode.js i18n/fr.barcode.js i18n/no.barcode.js i18n/pt_br.barcode.js i18n/sv.barcode.js i18n/cs.barcode.js i18n/el.barcode.js script/qr-scanner.min.js.map script/qr-scanner.umd.min.js script/qr-scanner.umd.min.js.map
which doesn't look like the newest version of you source code.
Just to make sure I didn't mess up during the docker update, here is what I did:
`
» docker-compose down
» pull the HEAD of your Git Repo plus my small LDAP changes: https://github.com/inventree/InvenTree/compare/master...Rincewind34:InvenTree:master#diff-febf73fb8db0cab29b06e16438d535af8f6c15955ebc64f8a44d26d003f55cf0 (I'm happy to try it without my changes, but this is just some semi hardcoded LDAP add-on to the Django auth stuff)
» docker-compose run inventree-server invoke update
» docker-compose up --build -d inventree-server
MySQL and nginx are running in a separate container connected to more than just inventree, so omitted here.

Do you have the static root directory exposed to your local file system as an external volume? Otherwise, when the static files are "updated" they will be overridden the next time the container launches.

@SchrodingersGat
this is our inventree compose file:
version: "3.0"

x-inventree-common: &common
  build:
    context: ../images/inventree
    target: production
  env_file:
    - inventree.env
  volumes:
    - inventree_data:/home/inventree/data
  restart: unless-stopped

services:
  inventree-server:
    <<: *common
    depends_on:
      - mysql
    expose:
      - 8000

  inventree-worker:
    <<: *common
    command: invoke worker
    depends_on:
      - inventree-server

volumes:
  inventree_data:
    driver: local
    driver_opts:
      type: 'none'
      o: 'bind'
      device: '/data/inventree_data'

Other than that there is nothing else "crazy" setup with the static folder (or any other one). Should I try deleting it and wait for it to be repopulated?

To confirm that the static files are being regenerated, delete the "static" directory in the external volume, and then run:
docker compose run inventree-server invoke static

This should regenerate static files into the external directory.
Might be similar to this issue:
https://docs.inventree.org/en/latest/start/docker_prod/#common-issues

Thank you very much, this is now resolved!! Everything is working as expected. I really want to start contributing at some point but there is just so much other stuff to do that keeps getting in my way. Thanks anyway for your great work!!! Me and my team are very happy with this software.

@Rincewind34 is it ok if I close this as completed?
No hurries with contributing, if you need pointers feel free to ping us with @inventree/maintainer @inventree/triage

Yes, this can be closed. Unless you want to transform it into a documentation improvement? The fact that there is a setting for the barcode reader delay really got me off guard. Maybe a small hint about that would be helpful.

@Rincewind34 I am currently rewriting the UI, I will put an info-bubble for the settings somewhere in the dialogue.
Thank you for the suggestion. We have a lot of settings in general, well over a hundred.

Yeah, I noticed. I just scrolled through the settings also in the admin page :D


onChangePaymentMethod

Why is not implemented onChangePlan that is dispatched when an user change the plan on drop-in payment UI. Would be useful to avoid the extra click for the user to confirm/update the payment method.

Could you provide more information about what you are asking for? What do you mean by onChangePlan? Are you referring to when a user clicks the "Change Payment Method" link?

I'm sorry in my comment when I say Plan I wanted to say Payment Method. Let me explain myself better.
In this case, by default I have selected PayPal:

If I click on MasterCard for example, there is no event that tells developers another Payment Method it's been selected.
It would be great something like onChangePaymentMethod or onSelectedPaymentMethod.
Why is so useful? It tell us when we have to show the Update Payment Method button

I only would show Use this payment method button when the event onChangePaymentMethod is triggered.
And event better. I don't need to show that button if the event pass payload.nonce as argument. And then we avoid and extra click from the user.

Thanks for the explanation.
At this time we're not planning to add any new lifecycle hooks to the current version of Drop-In. However, we're currently working on Drop-In for version 3 (currently in beta) of braintree-web and we'll consider this suggestion while we work on it.

:+1: I agree, it would be helpful to have something like onChangePaymentMethod for the drop-in UI that could signal the nonce needs to be re-generated.
Any timeframe for the existing drop-in to be added to v3?

At the moment, there is no timeline for a full Drop-in UI to be available. It is actively in development and will have a beta available relatively soon.
However, it should be noted that we are doing a refresh of the Drop-in UI, which means it will have a new UI with revised features. The existing version of Drop-in will not be part of v3.

An update on this issue: with the new version of Drop-in, there are paymentMethodRequestable events fired when you can request a payment method and receive a new nonce. Check out the events section of our developer docs for more information.

I would argue that having an additional event for "payment method changed" would still be useful. Please see the issue I opened in the drop-in repo.


Fix issue where --enable-remote-node-identity=false was not respected

Review commit-by-commit.
First two patches are minor observability / refactoring changes to prepare for the third patch. Here's the third patch commit message:
bpf: Fix traffic drop due to remote node identity

Previously, it was possible for a remote node to set the remote-node
identity and transmit the packet through the tunnel to the destination,
which would make a policy check using this as the source, *even if
--enable-remote-node-identity was set to false*.

This patch aims to continue to transmit the remote-node identity on the
wire for source verification purposes, but if the user has configured
--enable-remote-node-identity to false, then when the traffic is
received with this identity as the source, it will replace it with the
host identity and run through policy for the host. This is expected to
be equivalent to the host identity logic in Cilium v1.6 or earlier.

Note that the decap debug message will continue to report the real
source identity originally seen in the packet, but subsequent debug,
policy, and drop notifications (and policy logic) will consider the
identity to be 'host'.

Fixes: #10702

test-me-please

Coverage increased (+0.05%) to 46.683% when pulling 6a101f466727a65e3d918e43e21c59d7af9916d5 on joestringer:submit/fix-remote-node-source into 2a210ca036f545a0c2bac5e64d0b4e664ad32309 on cilium:master.

While I believe this PR solves the bug as-is, I'm rethinking the approach.
More specifically, if instead of replacing the remote-node identity with host identity early in the receive path, we instead generate "allow-from-remote-node-id" BPF policymap entries in userspace when this feature is disabled, then from cilium-monitor (and hubble!) it should be possible to learn when you are using the remote-node identity and help users craft their policy to account for this.
With this approach, users could upgrade, setting the --enable-remote-node-identity flag to false, then investigate whether they use such remote nodes, then subsequently update their policies and set the flag to true. This would be overall a safer approach and provide a clear migration path for users who don't know that they are relying on the "implicit allow from host" behaviour of Cilium v1.6 and earlier.

I'm also investigating a e2e test to validate the behaviour more methodically.

Closed in favour of #11006.


Feature Request: Sync Audio Slider

Before Firefox Quantum I used a really great Add-On called 'YouTube Audio Sync Tool' it would be great to have this function again. And it would even be better if I could adjust the audio in frames instead of milliseconds.

https://imgur.com/nTPiPSN.png
Yes, it is very faded indeed. It needs an icon re-haul.

I'm pretty sure with Web Audio I can only add positive delay. There's this extension which is YouTube-specific, it seems to create a separate <audio> element, constructing an audio URL for the YouTube video.


E-OBS high resolution grid is too big for memory

see solution https://xarray.pydata.org/en/v0.9.2/dask.html

In #167 the multipoint read per nc file uses trivial amount of memory and takes about 3-15 seconds per file.


Refactor button CSS code

Signed-off-by: Jay Clark<EMAIL_ADDRESS>Fixes #27

Refactor style properties to live in mainpage.css
Refactor button click handling to allow additional language buttons to be added in the future with minimal effort. (Code the button into the html page, and then add an object in the format {id: 'newButtonId', lang: 'newLangforLocalStorage'} to the buttons array in mainpage.js.
An elements array and an event listener for each button element are automatically generated from buttons
A single handleClick function adds 'active' to the the classList of the clicked button, sets lang in local storage, and removes 'active' from the classList of the inactive language buttons.

Happy Hacktoberfest @Sickaada !
https://user-images.githubusercontent.com/84106309/137605660-0b86db47-13bc-4995-9b07-a29fa5f28783.mov

Amazing!


add exception for Aarc_g002_entitlement_Error

aarg_g002 raises errors, if something goes wrong.
Patch handles the exception

Would it be possible to update the requirements.txt in the same PR?

Would it be possible to update the requirements.txt in the same PR?

Upps. Those requirements contain "=="
I would not do that, because this creates problems: Imagine you install two packages, one depends on 0.2.1 the other on 0.2.2, while 0.3 is up-to-date. You'll only be able to install one at a time.
Is there a particular reason for this?
I've changed the one for g002 to >= 0.3

Upps. Those requirements contain "=="
I would not do that, because this creates problems: Imagine you install two packages, one depends on 0.2.1 the other on 0.2.2, while 0.3 is up-to-date. You'll only be able to install one at a time.
Is there a particular reason for this?
I've changed the one for g002 to >= 0.3

I don't believe there's a particular reason other than someone just ran pip freeze at one point and it never broke.

I don't believe there's a particular reason other than someone just ran pip freeze at one point and it never broke.

On the note of syntax, I may change it to ~=0.3.1 later, so it stays within compatible versions. Given 0.3 itself was a breaking change, I'd like to avoid accidentally installing a 0.4 that breaks something else.

On the note of syntax, I may change it to ~=0.3.1 later, so it stays within compatible versions. Given 0.3 itself was a breaking change, I'd like to avoid accidentally installing a 0.4 that breaks something else.


Walkable tile will break routing if not on startup grid but added later.

If you setup a grid were all tiles are 1 like [1,1,1,1,....], set tiles [1,2] as walkable and change the map during the game by setting one tile to 2 it will break the path finding. At first it will try to move around but if you keep recalculating the path it can't decide on one path and get stucked.
I am using the Phaser Plugin, I added a fix there: https://github.com/appsbu-de/phaser_plugin_pathfinding/pull/1
Maybe you like to add it to your setAcceptableTiles(), too.

I don't see how this is a problem with easystar.  The collision grid and the acceptable tiles are independent variables, and so it shouldn't matter in what order you change them.  Perhaps this was a problem specifiy to  phaser_plugin_pathfinding?

This seems like an issue with the expectations around state. Maybe @PiNotEqual3 expects that easystar will track his changes to his collisionGrid without explicitly having to call setGrid every time he updates it. It's an accidental side effect that this actually does kind of work. The part that doesn't work is the costMap which doesn't get properly initialized if the grid is changed to include a new tile.
Maybe it makes sense to deep copy the grid passed into setGrid. We would incur a performance cost, but it might save users from some nasty state issues like this one. I will have to think about this more.

I would suggest keeping easystar out of any state stuff, and require to call setGrid if you want to load a new grid (like a new level). I would like to have a counterpart to avoidAdditionalPoint, like allowAdditionalPoint for unlocked doors, new bridges, etc... Makes this utility a lot more useful in a bit more dynamic maps.


[FEATURE] Standard color of Buttons

Description
Change all the necessary button in all pages color to "#04307d" (do not change bootstrap css, make custom class in another css file)
Example
Previous

After frontend must be

if anyone wants to work on this issue , ping me

assign me i will make PR ASAP @apoorvaron

@Nishitbaria Assigned


poor result about mesh

I run your code use default config on new college dataset, but i can not get the same result as table 1 show. By the way, i use the link you provide to evaluate. Here are the evaluation config :
For NCD
down_sample_vox = 0.02
dist_thre = 0.2
truncation_dist_acc = 0.4
truncation_dist_com = 2.0
Here are my result:
{'MAE_accuracy (m)': 0.1600144107307643, 'MAE_completeness (m)': 0.19971273194331618, 'Chamfer_L1 (m)': 0.17986357133704023, 'Chamfer_L2 (m)': 0.26092833422825545, 'Precision [Accuracy] (%)': 64.36066911590589, 'Recall [Completeness] (%)': 61.93420844798163, 'F-score (%)': 63.12412939882961, 'Spacing (m)': 0.02, 'Inlier_threshold (m)': 0.2, 'Outlier_truncation_acc (m)': 0.4, 'Outlier_truncation_com (m)': 2.0}
I want upload the mesh i get ,but it seems too large to upload. So i want to know how can i get the same result as you

Thanks for your attention.
Is mesh that used to evaluate is the one after "key-scan refine"?

You could upload a screenshot instead of a mesh file so that I can provide more help.

Thanks for your attention.
Is mesh that used to evaluate is the one after "key-scan refine"?

I use the final_mesh.ply. Is the mesh that used to evaluate is the one after "key-scan refine

Yes, what is mesh looks like?

You could upload a screenshot instead of a mesh file so that I can provide more help.

here are my evaluation screenshot , config screenshoot and mesh screenshot

Yes, what is mesh looks like?

here are my evaluation screenshot , config screenshoot and mesh screenshot

Yes, what is mesh looks like?

By the way, i only change the parameter " read_offset" from  default 5 to1, does it will change mesh quality

Yes, it would decrese the mesh quality, newer college dataset is collected by handhold devices, which means the lidar is not only suffer from motion distortion but also too dense for the task of reconstruction. Basically, the shape of the mesh is good, but the ground is not flat, that may due to the dense lidar scan and motion distortion. You can try to set "read_offset" to 1 to see the results.

Yes, it would decrese the mesh quality, newer college dataset is collected by handhold devices, which means the lidar is not only suffer from motion distortion but also too dense for the task of reconstruction. Basically, the shape of the mesh is good, but the ground is not flat, that may due to the dense lidar scan and motion distortion. You can try to set "read_offset" to 1 to see the results.

the above result is from read_offset=1, and I will try read_offset=5 later,and thanks for your reply

Hope you get better results~

Hope you get better results~

This time i get better result same as table 1:
{'MAE_accuracy (m)': 0.12597577918410047, 'MAE_completeness (m)': 0.17532213101945665, 'Chamfer_L1 (m)': 0.15064895510177856, 'Chamfer_L2 (m)': 0.2505973745191964, 'Precision [Accuracy] (%)': 77.41172923137316, 'Recall [Completeness] (%)': 71.95672924778981, 'F-score (%)': 74.58461977342017, 'Spacing (m)': 0.02, 'Inlier_threshold (m)': 0.2, 'Outlier_truncation_acc (m)': 0.4, 'Outlier_truncation_com (m)': 2.0}
Thanks for your quick reply!!!!!

You even got better results than that in the paper, hahahah


[BUG] longhorn-csi-plugin stuck in CrashLoopBackOff after system crash

Describe the bug (🐛 if you encounter this issue)
I just had one of my system crash. After it came back up, the longhorn-csi-plugin ends up in a CrashLoopBackOff. Logs do not seem to hint at any particular reason.
To Reproduce
n/a
Expected behavior
longhorn-csi-plugin starts properly-
Log or Support bundle
longhorn-csi-plugin time="2023-02-03T15:10:56Z" level=info msg="CSI Driver: driver.longhorn.io version: v1.4.0, manager URL http://longhorn-backend:9500/v1"
longhorn-csi-plugin time="2023-02-03T15:10:56Z" level=info msg="Enabling node service capability: GET_VOLUME_STATS"
longhorn-csi-plugin time="2023-02-03T15:10:56Z" level=info msg="Enabling node service capability: STAGE_UNSTAGE_VOLUME"
longhorn-csi-plugin time="2023-02-03T15:10:56Z" level=info msg="Enabling node service capability: EXPAND_VOLUME"
longhorn-csi-plugin time="2023-02-03T15:10:56Z" level=info msg="Enabling controller service capability: CREATE_DELETE_VOLUME"
longhorn-csi-plugin time="2023-02-03T15:10:56Z" level=info msg="Enabling controller service capability: PUBLISH_UNPUBLISH_VOLUME"
longhorn-csi-plugin time="2023-02-03T15:10:56Z" level=info msg="Enabling controller service capability: EXPAND_VOLUME"
longhorn-csi-plugin time="2023-02-03T15:10:56Z" level=info msg="Enabling controller service capability: CREATE_DELETE_SNAPSHOT"
longhorn-csi-plugin time="2023-02-03T15:10:56Z" level=info msg="Enabling controller service capability: CLONE_VOLUME"
longhorn-csi-plugin time="2023-02-03T15:10:56Z" level=info msg="Enabling volume access mode: SINGLE_NODE_WRITER"
longhorn-csi-plugin time="2023-02-03T15:10:56Z" level=info msg="Enabling volume access mode: MULTI_NODE_MULTI_WRITER"
longhorn-csi-plugin time="2023-02-03T15:10:56Z" level=info msg="Listening for connections on address: &net.UnixAddr{Name:\"//csi/csi.sock\", Net:\"unix\"}"
Stream closed EOF for longhorn-system/longhorn-csi-plugin-46gwb (longhorn-csi-plugin)
longhorn-liveness-probe W0203 14:59:43.264724    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 14:59:53.264996    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:00:03.264512    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:00:13.264347    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:00:23.265398    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:00:33.265074    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:00:43.265280    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:00:53.265217    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:01:03.265147    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:01:13.265215    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:01:23.264284    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:01:33.264461    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:01:43.264858    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:01:53.264423    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:02:03.264472    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:02:13.264365    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:02:23.264418    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:02:33.264435    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:02:43.264424    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:02:53.264902    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:03:03.265168    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
node-driver-registrar I0203 15:09:39.136282   12242 main.go:166] Version: v2.5.0
node-driver-registrar I0203 15:09:39.136529   12242 main.go:167] Running node-driver-registrar in mode=registration
node-driver-registrar I0203 15:09:39.139643   12242 main.go:191] Attempting to open a gRPC connection with: "/csi/csi.sock"
longhorn-liveness-probe W0203 15:03:13.264639    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:03:23.264478    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:03:33.264803    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:03:43.265385    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:03:53.264407    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:04:03.264737    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:04:13.264446    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
node-driver-registrar I0203 15:09:40.147600   12242 main.go:198] Calling CSI driver to discover driver name
node-driver-registrar I0203 15:09:40.164554   12242 main.go:208] CSI driver name: "driver.longhorn.io"
longhorn-liveness-probe W0203 15:04:23.264419    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:04:33.264846    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:04:43.264923    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:04:53.264457    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:05:03.265267    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:05:13.264310    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:05:23.264378    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:05:33.264401    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:05:43.264423    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:05:53.264611    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:06:03.265027    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:06:13.264351    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:06:23.265314    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:06:33.264301    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:06:43.265092    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:06:53.264417    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:07:03.264349    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:07:13.265051    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:07:23.264404    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:07:33.264366    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
node-driver-registrar I0203 15:09:40.167502   12242 node_register.go:53] Starting Registration Server at: /registration/driver.longhorn.io-reg.sock
node-driver-registrar I0203 15:09:40.169473   12242 node_register.go:62] Registration Server started at: /registration/driver.longhorn.io-reg.sock
node-driver-registrar I0203 15:09:40.170916   12242 node_register.go:92] Skipping HTTP server because endpoint is set to: ""
node-driver-registrar I0203 15:09:40.835828   12242 main.go:102] Received GetInfo call: &InfoRequest{}
node-driver-registrar I0203 15:09:40.837650   12242 main.go:109] "Kubelet registration probe created" path="/var/lib/kubelet/plugins/driver.longhorn.io/registration"
node-driver-registrar I0203 15:09:41.861423   12242 main.go:120] Received NotifyRegistrationStatus call: &RegistrationStatus{PluginRegistered:true,Error:,}
node-driver-registrar E0203 15:09:55.061520   12242 connection.go:132] Lost connection to unix:///csi/csi.sock.
node-driver-registrar E0203 15:10:10.028389   12242 connection.go:132] Lost connection to unix:///csi/csi.sock.
node-driver-registrar E0203 15:10:55.045211   12242 connection.go:132] Lost connection to unix:///csi/csi.sock.
node-driver-registrar E0203 15:11:10.060312   12242 connection.go:132] Lost connection to unix:///csi/csi.sock.
longhorn-liveness-probe W0203 15:07:43.265142    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:07:53.264572    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:08:03.264568    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:08:13.264631    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:08:23.265188    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:08:33.264440    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:08:43.264419    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:08:53.265208    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:09:03.265084    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:09:13.264582    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:09:23.265354    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:09:33.265361    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:09:43.264915    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:09:53.264620    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:10:03.265242    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:10:13.264917    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:10:23.264697    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:10:33.264743    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:10:43.264954    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:10:53.264311    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:11:03.264342    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:11:13.264602    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:11:23.264777    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:11:33.264413    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:11:43.265103    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:11:53.264415    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:12:03.264900    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:12:13.264534    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:12:23.264423    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:12:33.295701    1893 connection.go:173] Still connecting to unix:///csi/csi.sock
longhorn-liveness-probe W0203 15:12:43.264362    1893 connection.go:173] Still connecting to unix:///csi/csi.sock

Environment

Longhorn version: 1.4.0
Installation method (e.g. Rancher Catalog App/Helm/Kubectl): helm
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: k3s 1.25.6+k3s1

Number of management node in the cluster: 3
Number of worker node in the cluster: 12

Node config

OS type and version: MicroOS
CPU per node: Depends
Memory per node: Depends
Disk type(e.g. SSD/NVMe): SSD & NVMe
Network bandwidth between the nodes: 1GBe

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): Baremetal
Number of Longhorn volumes in the cluster: 38

Additional context
Add any other context about the problem here.

Also, I have SELinux enabled and on the problematic node, I am seeing the following in the audit.log:
type=AVC msg=audit(1675438507.878:817): avc:  denied  { connectto } for  pid=15054 comm="livenessprobe" path="/csi/csi.sock" scontext=system_u:system_r:container_t:s0:c392,c936 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
type=AVC msg=audit(1675438508.698:818): avc:  denied  { connectto } for  pid=15054 comm="livenessprobe" path="/csi/csi.sock" scontext=system_u:system_r:container_t:s0:c392,c936 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
type=AVC msg=audit(1675438509.878:819): avc:  denied  { connectto } for  pid=15054 comm="livenessprobe" path="/csi/csi.sock" scontext=system_u:system_r:container_t:s0:c392,c936 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
type=AVC msg=audit(1675438510.798:820): avc:  denied  { connectto } for  pid=15054 comm="livenessprobe" path="/csi/csi.sock" scontext=system_u:system_r:container_t:s0:c392,c936 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
type=AVC msg=audit(1675438511.798:821): avc:  denied  { connectto } for  pid=15054 comm="livenessprobe" path="/csi/csi.sock" scontext=system_u:system_r:container_t:s0:c392,c936 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
type=AVC msg=audit(1675438512.868:822): avc:  denied  { connectto } for  pid=15054 comm="livenessprobe" path="/csi/csi.sock" scontext=system_u:system_r:container_t:s0:c392,c936 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
type=AVC msg=audit(1675438513.838:823): avc:  denied  { connectto } for  pid=15054 comm="livenessprobe" path="/csi/csi.sock" scontext=system_u:system_r:container_t:s0:c392,c936 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
type=AVC msg=audit(1675438514.998:824): avc:  denied  { connectto } for  pid=15054 comm="livenessprobe" path="/csi/csi.sock" scontext=system_u:system_r:container_t:s0:c392,c936 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
type=AVC msg=audit(1675438516.068:825): avc:  denied  { connectto } for  pid=15054 comm="livenessprobe" path="/csi/csi.sock" scontext=system_u:system_r:container_t:s0:c392,c936 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
type=AVC msg=audit(1675438517.108:826): avc:  denied  { connectto } for  pid=15054 comm="livenessprobe" path="/csi/csi.sock" scontext=system_u:system_r:container_t:s0:c392,c936 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0

Okay, I got this "fixed" with the following policy:
module local 1.0;

require {
	type container_t;
	type unconfined_service_t;
	class unix_stream_socket connectto;
}

#============= container_t ==============
allow container_t unconfined_service_t:unix_stream_socket connectto;

Why do I only have to do this in 1 of 12 systems?

I can confirm I have ran into this exact issue. This impacted only a portion of my nodes also for some unknown reason. However I would say this is less of a bug and more of "docs needed" situation.

Interesting! I'm also curious why this only needs to be done on subset of systems. I'm assuming the policies on the other systems were the same before the incident, so somehow the context of either the liveness probe process or the socket is now different?
Can you exec into a longhorn-csi-plugin container on an offending node and on a node in which you didn't have to make the change and execute commands like the following?
longhorn-csi-plugin-977mw:/ # ps -eZ | grep liveness
cri-containerd.apparmor.d (enforce) 795408 ?     00:01:23 livenessprobe

longhorn-csi-plugin-977mw:/ # ls -lZ /csi/csi.sock
srwxr-xr-x 1 root root ? 0 May 23 13:59 /csi/csi.sock

These were run on a non-SELinux system, so they don't give useful information, but hopefully yours do!

Sure thing I need to put them back into a broken state as I only temporarily disabled selinux, I can do that in a few hours and report back.

Pod with on selinux enabled node with working pod:
longhorn-csi-plugin-flcdq:/ # ps -eZ | grep liveness
system_u:system_r:container_t:s0:c395,c779 1039299 ? 00:00:00 livenessprobe

longhorn-csi-plugin-flcdq:/ # ls -lZ /csi/csi.sock
srwxr-xr-x. 1 root root system_u:object_r:container_file_t:s0 0 May 26 02:21 /csi/csi.sock

Pod with on selinux enabled node with non-functioning pod:
longhorn-csi-plugin-trj8p:/ # ps -eZ | grep liveness
system_u:system_r:container_t:s0:c580,c789 1620312 ? 00:00:00 livenessprobe

longhorn-csi-plugin-trj8p:/ #  ls -lZ /csi/csi.sock
srwxr-xr-x. 1 root root system_u:object_r:container_file_t:s0 0 May 26 02:23 /csi/csi.sock

@ejweber is this same as https://github.com/longhorn/longhorn/issues/5627? anything we still need to do?

Sorry for the delay @Daemonslayer2048 and @docbobo. This one fell off my radar. I'd like to try to get to the bottom of it, and I'm curious whether either of you can still easily reproduce it.
I've been doing some more digging on my side, and it's becoming clear that my previous understanding of SELinux was somewhat flawed where sockets are concerned. Even though the socket file has system_u:object_r:container_file_t:s0 in @Daemonslayer2048 's example, the denial is for connectto and context=system_u:system_r:unconfined_service_t:s0. unconfined_service_t is not a file context at all. It is the process context for the server process listening on the socket. The server process that creates the socket is the longhorn-manager -d csi ... running in the longhorn-csi-plugin container.
If we can still reproduce, it's more useful to have the context for the Longhorn CSI plugin's process (the server process) instead of the liveness probe (as @Daemonslayer2048 already provided in https://github.com/longhorn/longhorn/issues/5348#issuecomment-1563728668). Even better if we just capture all of the Longhorn related process contexts.
-> ps -eZf | grep "longhorn-manager -d csi"
system_u:system_r:spc_t:s0      root     2003249    6413  0 18:29 ?        00:00:03 longhorn-manager -d csi --nodeid=ip-192-168-211-77.ec2.internal --endpoint=unix:///csi/csi.sock --drivername=driver.longhorn.io --manager-url=http://longhorn-backend:9500/v1

# or

-> ps -eZf | grep "longhorn

The other thing that might be interesting is the versions of packages installed on nodes (especially SELinux related packages). A comparison of the package versions on a working node and a non-working node may help us to uncover changes in SELinux policy.
# for zypper
-> zypper search -si

Can you clarify exactly what distro and version you are using? I tried to get a recreate with those packages going in AWS, however, the closest approximation I could come up with was SUSE Linux Enterprise Micro 5.5, and all of those package versions are newer than I can easily pull down.
One thing that appears to be missing is k3s-selinux. I'm guessing this was just an oversite when you assembled that package list, but it's good to confirm that it is actually installed.

I am using MicroOS which is Tumbleweed-based. In the change described above, I was coming from 20231017 going to 20231101.
The list above only captures the packages that were differing in versions between the "good" and "bad" instances.  Here's the complete list of packages with selinux in the name, taken on the "bad" instance.
i  | container-selinux                          | package | 2.222.0-1.1                   | noarch  | openSUSE-Tumbleweed-Oss
i  | libselinux1                                | package | 3.5-5.1                       | aarch64 | openSUSE-Tumbleweed-Oss
i  | microos_selinux                            | pattern | 5.0-80.1                      | aarch64 | openSUSE-Tumbleweed-Oss
i  | selinux-policy                             | package | 20231030-1.1                  | noarch  | openSUSE-Tumbleweed-Oss
i  | selinux-policy-targeted                    | package | 20231030-1.1                  | noarch  | openSUSE-Tumbleweed-Oss
i  | selinux-tools                              | package | 3.5-5.1                       | aarch64 | openSUSE-Tumbleweed-Oss
i+ | k3s-selinux                                | package | 1.4.stable.1-1.1              | noarch  | openSUSE-Tumbleweed-Oss
i+ | patterns-microos-selinux                   | package | 5.0-80.1                      | aarch64 | openSUSE-Tumbleweed-Oss

Cool, I am able to run those package versions on Tumbleweed. I'll run a few experiments.

I have managed to make progress here, but not as much as I'd like. I can reproduce this behavior on a Tumbleweed node with slightly newer packages than the ones you have. This has made the IMMEDIATE problem clear:
Some components, most notably the longhorn process in the longhorn-csi-plugin container may run in the container_runtime_t domain instead of the spc_t domain as we would expect from a privileged container. You mentioned that this is the same on all of your nodes, but it's quite unexpected to me. I'm honestly not sure why your other nodes are able to function properly.
ip-192-168-217-136:/var/lib/kubelet/pods # ps -efZ | grep longhorn
...
system_u:system_r:container_runtime_t:s0 root 7585 5239  0 23:19 ?     00:00:00 longhorn-manager -d csi --nodeid=ip-192-168-217-136 --endpoint=unix:///csi/csi.sock --drivername=driver.longhorn.io --manager-url=http://longhorn-backend:9500/v1
...

There IS a rule that would allow container_t processes to connect to spc_t processes.
ip-192-168-217-136:/var/lib/kubelet/pods # sesearch -A -t spc_t -p connectto
allow container_domain spc_t:unix_stream_socket connectto;
allow domain spc_t:unix_stream_socket connectto;
allow kernel_t domain:unix_stream_socket { accept append bind connect connectto getattr getopt ioctl listen lock read setattr setopt shutdown write };
allow svirt_sandbox_domain spc_t:unix_stream_socket connectto;
allow unconfined_domain_type domain:tcp_socket { accept acceptfrom append bind connect connectto create getattr getopt ioctl listen lock map name_bind name_connect newconn node_bind read recv_msg recvfrom relabelfrom relabelto send_msg sendto setattr setopt shutdown write };
allow unconfined_domain_type domain:unix_stream_socket { accept acceptfrom append bind connect connectto create getattr getopt ioctl listen lock map name_bind newconn read recv_msg recvfrom relabelfrom relabelto send_msg sendto setattr setopt shutdown write };

ip-192-168-217-136:/var/lib/kubelet/pods # seinfo -x -a container_domain

Type Attributes: 1
   attribute container_domain;
        container_device_plugin_init_t
        container_device_plugin_t
        container_device_t
        container_engine_t
        container_init_t
        container_kvm_t
        container_logreader_t
        container_logwriter_t
        container_t
        container_userns_t

There is NOT a rule that would allow container_t processes to connect to container_runtime_t processes.
ip-192-168-217-136:/var/lib/kubelet/pods # sesearch -A -t container_runtime_t -p connectto
allow abrt_t container_runtime_t:unix_stream_socket connectto;
allow container_auth_t container_runtime_t:unix_stream_socket connectto;
allow container_kvm_t container_runtime_t:unix_stream_socket { accept append bind connect connectto getattr getopt ioctl listen lock read setattr setopt shutdown write };
allow container_runtime_t container_runtime_t:unix_stream_socket { accept append bind connect connectto create getattr getopt ioctl listen lock read setattr setopt shutdown write };
allow daemon daemon:unix_stream_socket connectto; [ daemons_enable_cluster_mode ]:True
allow kernel_t domain:unix_stream_socket { accept append bind connect connectto getattr getopt ioctl listen lock read setattr setopt shutdown write };
allow staff_t container_runtime_t:unix_stream_socket connectto;
allow sysadm_t container_runtime_t:unix_stream_socket connectto;
allow unconfined_domain_type domain:tcp_socket { accept acceptfrom append bind connect connectto create getattr getopt ioctl listen lock map name_bind name_connect newconn node_bind read recv_msg recvfrom relabelfrom relabelto send_msg sendto setattr setopt shutdown write };
allow unconfined_domain_type domain:unix_stream_socket { accept acceptfrom append bind connect connectto create getattr getopt ioctl listen lock map name_bind newconn read recv_msg recvfrom relabelfrom relabelto send_msg sendto setattr setopt shutdown write };

So, the question is, why is the process running as container_runtime_t?

As I was poking around later after writing that comment, I noticed all of my privileged containers are running as container_runtime_t. This seems quite incorrect to me.

Heads up @docbobo, I opened https://github.com/k3s-io/k3s-selinux/issues/53 in response to this issue. I think there's not much we can do from the Longhorn side if the SELinux integration for your Kubernetes distribution is broken. After a decent amount of investigating, I think that is the case.
If it is possible to roll back to selinux-policy-targetd 20231012-1.1, I suggest you try that. Otherwise you can disable SELinux or use an audit2allow approach.

Thanks, @ejweber. Let's see if that gets fixed anytime soon. In the meantime, I've unblocked myself by deploying a custom policy.

Closed this issue, because https://github.com/longhorn/website/pull/801 has been added and this is actually an upstream issue k3s, the corresponding issue was opened by @ejweber already. https://github.com/k3s-io/k3s-selinux/issues/53.


Add backward support for floor, round and div_no_nan

Where is the requirement from Moreh for the div_no_nan ?

Merged to main


Control Panel still use Semantic UI icon font - can't set all icons available

Yes, we should deprecate the use of semantic UI icon font in favor of the SVG one. The control panel overview are still using them. I will change the name of the issue, if you are fine with that. Any use case where we want to use the font? I think we should move all icons to SVGs.

I think this issue can be closed. Icons seem to be updated. 🙂


Update launcher to let the user choose between running the Depthai Demo or Depthai Viewer

After the launcher updates itself, the user will be prompted to choose between running depthai demo or depthai viewer (on every startup).

If the viewer is chosen and not installed, it will be installed.
If a new viewer version is available on pypi, a dialog will pop up showing what version is installed and which new version is available. The user can then confirm to update or keep using the currently installed version.

Choose app dialog

Depthai Viewer update dialog

Lets retain old logo on demo and old blue color on it.
And add New Beta on Viewer
Also, check to see if it works on all 3 major OSs

New look

Works on windows.
Will test on linux and macos now, it for sure won't work on arm macs without rosetta due to PyQt5, which is also used in the demo. I could port the launcher to use PyQt6 tho, should be a simple task. It may be worth it if we plan to keep the launcher even after the demo is deprecated, which we do afaik.  Thoughts @themarpe .

@zrezke
Lets keep it as is for the time being, as launcher is mainly used on windows.
Do you mind checking if launcher entry point is installed under install_depthai script? If so we can revisit for that after the fact

Sure!
Looks like it's present when installing depthai via: bash -c "$(curl -fL https://docs.luxonis.com/install_depthai.sh)" on macOS:
(x86) bash-3.2$ pwd
/Users/filipjeretina/Luxonis1/depthai
(x86) bash-3.2$ ls -la entrypoint/depthai_launcher
-rwxr-xr-x  1 filipjeretina  staff  2650 Jun 29 13:08 entrypoint/depthai_launcher

One thing to note is that the splash screen actually crashes on mac:
2023-06-29 13:13:50.864 python[48022:399898] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions should only be invalidated on the Main Thread!'
*** First throw call stack:
(
        0   CoreFoundation                      0x00007ff802f867fb __exceptionPreprocess + 242
        1   libobjc.A.dylib                     0x00007ff802ce7e58 objc_exception_throw + 48
        2   CoreFoundation                      0x00007ff802faf226 -[NSException raise] + 9
        3   AppKit                              0x00007ff80588f634 -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 321
        4   AppKit                              0x00007ff80587b5e4 -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1288
        5   AppKit                              0x00007ff80587b0d6 -[NSWindow initWithContentRect:styleMask:backing:defer:] + 42
        6   AppKit                              0x00007ff805c4caeb -[_NSOrderOutAnimationProxyWindow initWithSnapshotOfWindow:] + 611
        7   AppKit                              0x00007ff805ac4c62 -[_NSWindowTransformAnimation initWithWindow:type:interruptingAnimation:] + 690
        8   AppKit                              0x00007ff805ac499b +[_NSWindowTransformAnimation windowTransformAnimationWithWindow:type:interruptingAnimation:] + 49
        9   AppKit                              0x00007ff80599e31e -[NSWindow _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 595
        10  AppKit                              0x00007ff80599e069 -[NSWindow orderWindow:relativeTo:] + 152
        11  libqcocoa.dylib                     0x000000011868f24a _ZN12QCocoaWindow10setVisibleEb + 1050
        12  QtGui                               0x0000000115bcd758 _ZN14QWindowPrivate10setVisibleEb + 1112
        13  QtWidgets                           0x000000011780c665 _ZN14QWidgetPrivate8hide_sysEv + 229
        14  QtWidgets                           0x000000011780e3f7 _ZN14QWidgetPrivate11hide_helperEv + 167
        15  QtWidgets                           0x000000011780e8d5 _ZN14QWidgetPrivate10setVisibleEb + 373
        16  QtWidgets.abi3.so                   0x0000000116ba47bf _ZN16sipQSplashScreen10setVisibleEb + 111
        17  QtWidgets.abi3.so                   0x0000000116d90fcb _ZL17meth_QWidget_hideP7_objectS0_ + 75
        18  python3.11                          0x000000010411ef1a cfunction_call + 90
        19  python3.11                          0x0000000104211d09 _PyEval_EvalFrameDefault + 232441
        20  python3.11                          0x00000001040bae22 _PyFunction_Vectorcall + 514
        21  python3.11                          0x00000001042187af _PyEval_EvalFrameDefault + 259743
        22  python3.11                          0x00000001040bae22 _PyFunction_Vectorcall + 514
        23  python3.11                          0x00000001040c0ef1 method_vectorcall + 449
        24  python3.11                          0x000000010430c59b thread_run + 235
        25  python3.11                          0x0000000104297374 pythread_wrapper + 36
        26  libsystem_pthread.dylib             0x00007ff802e454e1 _pthread_start + 125
        27  libsystem_pthread.dylib             0x00007ff802e40f6b thread_start + 15
)
libc++abi: terminating with uncaught exception of type NSException

@themarpe this is ready - works on all platforms.
One UX issue is that the splash screen exits when the depthai-viewer is installing dependencies, so that might be a bit confusing for users. It should be handled on the viewer side tho. Since the viewer doesn't exit if the dependencies are not installed, one would have to parse the output to get a sense of "are we still installing dependencies?" - which is sketchy at best. I think just starting up the viewer window and then having a pop up like installing dependencies would be better. + It would be a better UX for people who pip installed it aswell...

I think just starting up the viewer window and then having a pop up like installing dependencies would be better.

I agree, if Viewer is installing those dependencies, lets have that handle the Viewer specific splash screen

TODO: also update Getting started with DepthAI to use the Viewer by default.

The dependency installer landed in depthai-viewer 0.1.4

This is fine to merge now.


Convert from named color doesn't work

Used "Convert color" from "Named"

I'm using vscode 1.3.1

Hi @MrLuje, thank you for the report.
Could you tell me more information, please?
That looks like strange behavior because "Convert Color" command can not show the dialog box.
So, which color notation (e.g. "HWB", "RGB / RGBA", etc.,) did you choose from a list at top of VS Code window (not in the dialog box), after you executed "Convert Color" command?
And, when was that error message shown?

No reply came, and I close this issue.


simpleschema for adding new documents fixes #278

:+1:  It would be really nice to have this working !


First unit test always slower than the others.

Prerequisites

[x] Checked that your issue isn't already filed by cross referencing issues with the common mistake label
[x] Checked next-gen ES issues and syntax problems by using the same environment and/or transpiler configuration without Mocha to ensure it isn't just a feature that actually isn't supported in the environment in question or a bug in your code.
[x] 'Smoke tested' the code to be tested by running it outside the real test suite to get a better sense of whether the problem is in the code under test, your usage of Mocha, or Mocha itself
[x] Ensured that there is no discrepancy between the locally and globally installed versions of Mocha. You can find them with:
node node_modules/.bin/mocha --version(Local) and mocha --version(Global). We recommend avoiding the use of globally installed Mocha.

Description
For some reason the first unit test of my test suit is always slower than the others. When executing the tests in my console I get something like:
 √ unit test A (483ms)
 √ unit test B
But in the code if I change the unit test B to above the unit test A, I get this:
 √ unit test B (470ms)
 √ unit test A
For some reason the first unit tests gets always slower and because of that I think, the reason of being slow in not my code, but something in Mocha. At the same time I have others tests suits that are testing other code and it works fine, so I'm confused. Maybe is not Mocha, but due to not being sure, I need to ask if you have an idea of what can be happening.
The test is something like this:
let target = require('...');

describe('Module of unit tests', function () {
  this.timeout(1000);
  before(function () {
    ...
    target = proxyquire('...', {
      'node-chartist': sinon.stub().resolves('...'),
      'ws': function(){
        return {
          'close': function(){ /*Do nothing*/ },
          'send': function(){ /*Do nothing*/ },
          'on': function(arg, callback){
            ...
          }
        };
      }
    });
  });

  //Warning happens here
  it('unit test A', function () {
    ...
    target();
    ...
  });

  //If this unit test goes above unit test A, this will be the one to get the warning.
  it('unit test B', function () {
    ...
    target();
    ...
  });
})

Steps to Reproduce
I tried to reproduce in other projects without success, so I doubt you will be able to do it, but what I'm doing is:

Execute tests suit with unit test A above.
Execute tests suit with unit test B above.

Expected behavior: [What you expect to happen]
Don't get any warning about the time in both cases.
Actual behavior: [What actually happens]
The first unit test gets always a warning about the time.
Reproduces how often: [What percentage of the time does it reproduce?]
Around 90% of the times.
Versions
node v6.11.4
npm 3.10.10
mocha 4.0.1
sinon 4.1.2
chai 3.5.0
proxyquire 1.8.0
Additional Information
I used fiddler to make sure that while executing the unit tests, none network request was being made for the outside, to make sure that the delay is not caused by any network request.
I also debugged the code that the unit test is testing and I really don't see any reason for the delay in any case.

One thing worth trying is copying everything that's common to the two tests, except for any assertions, into a before hook to see if simply running the same sort of stuff in another place makes the first place it runs of any sort slower, rather than the first test specifically.
It's possible that the code, even if it's not necessarily slow in general, is initializing something the first time that then gets saved in some way (e.g. Node's require cache, or filesystem-level caches of data from the disk, or a reuse optimization built into some library code), or that the JavaScript engine looks for optimizations in the code after it runs once, or something like that. You could also put it outside the testsuite altogether, although that's less likely to work -- for a few types of caches, that would have more chance of the cache running out somewhere in between loading the test files and actually running this particular file's tests (on the other hand, if a before hook worked and outside the testsuite didn't, that might narrow down what sort of caching or optimization is responsible...).
(And on a completely different note, more workaround than solution -- for anyone who just wants to suppress the time warning, there's the slow option to go with the timeout option.)

Hi ScottFreeCode,
Thanks for the response, it was very usefull. The problem was happening because I am making some stubs with proxyquire and by default the npm modules are loaded even when stubbed. In my case I have a module called node-chartist that was being loaded during the first unit test and that is why it was slower than the others.
To solve this problem I had to use the method noCallThru() of proxyquire which make proxyquire don't load any original dependencies.
Thanks for the help.
Kind regards,
Daniel Serrão

Glad I could help you get that figured out! Let us know if there's anything else you need.


Erroneous Unaccessible Property of Two Disjoint Union Types that are Intersections of Another Type

I'm not sure if that title makes any sense. But I have two scenarios in a React component. Both scenarios have some shared props and one or two props that are unique to either scenario A or B. Flow warns on all three of the unique properties of A and B that they are unaccessible. See:
https://flow.org/try/#0C4TwDgpgBAygFgQwE4QCZQLxQN5QPYB2EAXFAM7BICWBA5lAL4BQokUAgpjlMAO56kK1OoygAyWIhSoW4aACEuuYHBQlylGvQbjJyNLLYBhLpwA+UeUyYBjQhSgAzPHi4AKMEjxgypIwEpSAH4hLUwAPiYASFYIPEcoT28yADoVNUwMLAByULps6KigxK8fNNUICELiQtj4kuS0-kycvNoCqM7ipLK+PEKo0jqEntTCaCzWzXyBooay8dnSAgBXABs1piA

Also, Is https://goo.gl/CbYgV4 the same problem?

It was suggested in the numerous issues here to use ... over & - example
I don't know why, explanation of the behaviour would be highly appreciated (cc @calebmer), but I have indeed found that the proposed approach fixes my errors.

@Andarist it would be more safe to wrap Shared in $Exact in your example like this

Oh yeah, sure thing. I kinda wish flow type changing default behaviour to exact shapes everywhere - it just makes reasoning about things WAY easier for newcomers


Travis CI keeps failing.

Probably due to missing or invalid build configuration,
Optional: Move to GitLab.

Travis CI is free CI for public repositories on GitHub. However, it needs api keys(including google-services.json) which are private. This causes the build to fail and the only sensible solution is to use a private mirror, so the keys can be included.
Going for an automated workflow, this will probably not be a quick fix.
As such, this issue is delayed for an undetermined amount of time.

Build flavors could fix this. Alternatively, using Fastlane.


Idva6 496 userslist

new feature to fetch associations for user in session
JIRA Ticket Number
Type of change

[ ] Bug fix
[ ] New feature
[ ] Breaking change
[ ] Infrastructure change

Pull request checklist

[ ] I have added unit tests for new code that I have added
[ ] I have added/updated functional tests where appropriate
[ ] The code follows our coding standards

An exhaustive list of peer review checks can be read here

CI: No security warnings found

CI: No security warnings found

CI: No security warnings found

CI: No security warnings found

CI: No security warnings found


i can generate the openblas.lib ,but how to generate the openblasd.lib file?

i can generate the openblas.lib ,but how to generate the openblasd.lib file?what is the diffrent bettwen the two file

i can generate the openblas.lib ,but how to generate the openblasd.lib file?

There's no openblasd.lib file. What do you mean by openblasd.lib file?

the old version has the file name "libopenblasd.lib"

the version is openblas<IP_ADDRESS>

@mengpengfei, where did you get openblas<IP_ADDRESS> ?

http://www.zifuture.com/fs/3.build/3rd.rar
the file contains the compiled lib file of that version

that has a file libopenblas.dll.a,how can i replace the file

thanks very much

libopenblas.dll.a is an import library created when you build with MinGW and openblas.lib is when you build with MSVC. Both files should be interchangeable with a recent binutils version. If you want to generate libopenblas.dll.a, build OpenBLAS with MinGW.

thank you very much

you already have the binary package,oh!! i compile it step by step ,,,,,consume me one day

Old OpenBLAS versions on Windows build using only one CPU core, you might want to try cross-building DLL on Linux if you cannot get newer ones (like 0.3.5)

how money cores the version 0.2.19 uses

This is just limitation of Windows build process in old versions, no problem with resultant library.
If you look in Makefile.rule, it hints NUM_THREADS=256 should work without any risks, in practice it will use detected CPU count if it is less.

Let me make 2 guesses regarding openblasD.lib
If it is Double precision (half-)library - API is included in full version
If it is with .pdb Debug symbols - you will have more luck with clang-cl etc.

thank you,just use openblas.lib is suitable


[2.0-wip] Docs: Problem with Navbar search form & responsive layout

I found an issue with the docs to do with the search form in the navbar when combined with the responsive layout.
Referencing: http://markdotto.com/bs2/docs/components.html#navbar
The example given has .pull-right assigned on the input.
This in itself doesn't break the navbar, but when you combine it with the responsive layout, and the menu becomes stacked, the .pull-right makes the form have no height and therefore the bottom border goes beneath the input and the navbar butts up against the input.

Hi, using both chrome and safari I get the problem.  You are correct, the example does have .pull-left, I had changed it in my code and forgot.
Have thrown an example up at http://jsfiddle.net/MAjuh/ with the form copied and pasted from your docs.

Ahh, gotcha. You've got the .pull-left on the input instead of the form. Any reason for that? If not, move the class up to the form and you shouldn't have a problem.
Just in case though, I've added a clearfix to the .navbar-form which should help others avoid this same problem.

Yes, I have moved it up in my code, that .pull-left is on the input in the example in the docs, hence me reposting it.

Its not an issue with the code, its an issue with the docs.  I couldn't work out where to feed that back so put it in here.

Ahhh, gotcha. Resolved—thanks!


Feature: guess from audio file

All the pieces are in place but this doesn't yet work. See the test, I created a simple audio file of a piano Am@4 and the notes that are guessed are D♯3, C3, and G3. I'm not too familiar with the math behind this whole process, I'm wondering if I've selected the wrong sample rate, or I'm doing the transcoding wrong somehow?
Any thoughts?

All the pieces are in place but this doesn't yet work. See the test, I created a simple audio file of a piano Am@4 and the notes that are guessed are D♯3, C3, and G3. I'm not too familiar with the math behind this whole process, I'm wondering if I've selected the wrong sample rate, or I'm doing the transcoding wrong somehow?
Any thoughts?

Good question.  I can take a look at the mp3.  The sampling rate should not matter.

Are you sure that the sample rate of your file is 44.1 kHz?

I wasn't trying to assert that the sample rate of the input file is 44.1kHz, I was trying to convert any input to be 44.1kHz, so that we can calculate the length.
Based on your review, I think parsing the time at the CLI and then reconstructing the string before passing it to ffmpeg, which would negate the need to calculate the length from the count of samples received. I too suspected the sample rate being wrong may be what's causing the guesses to be wrong, so lets see if that fixes the problem before giving it too much more thought haha.

The consumer of the library can choose to use an actual logger to emit the logs to console / etc.

well, in this case we have both the library and the consumer. I was asking what you would prefer for the latter.

Closing in favor of #3


Replicated TT Lib Transpose into TTNN

Ticket
Link to Github Issue
Problem description
Migrating TTLib transpose to TTNN
What's changed
Replicated all TT Lib C++ code into TTNN, will delete in next PR along with bindings
Checklist

[ ] Post commit CI passes
[ ] Model regression CI testing passes (if applicable)
[ ] New/Existing tests provide coverage for changes

Can we just delete the old code in one shot? It should be straightforward

I can but then I'd need to run all pipelines that use it (t3k, models etc. )

Can we just delete the old code in one shot? It should be straightforward

I can but then I'd need to run all pipelines that use it (t3k, models etc. )

@TT-BrianLiu you're right though, even with the extra pipelines, if there is an intermediate state with two versions, there's a possibility of stale updates getting pushed through. I'll delete the old code to make sure there's no replication.


ENH: add method that creates new spline for a partial derivative of bivariate spline

This changeset addresses issue #2047 by adding a method partial_derivative to the base class BivariateSpline.
The major benefit is increased performance when evaluating derivatives with grid=False. The major benefit is increased performance from reduction of call overhead. A typical usage case where this benefit may show up is the repeated evaluation of a particular derivative of the same spline with scalar arguments, for example in the integrand function of numerical quadrature using scipy.integrate.dblquad or scipy.integrate.nquad. Coefficients for the new spline representing the derivative are evaluated once and reused for each subsequent evaluations.
In [1]: %paste
import numpy
import scipy.interpolate as spi

xs = numpy.linspace(0, numpy.pi, 100)
ys = xs.copy()
zs = numpy.sin(xs[:, None] + ys[None, :])

orig = spi.RectBivariateSpline(xs, ys, zs)
der = orig.partial_derivative(0, 1)
## -- End pasted text --

In [2]: %timeit orig(0.23, 0.23, 0, 1, grid=False)
28.9 µs ± 322 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [3]: %timeit der(0.23, 0.23, grid=False)
3.88 µs ± 45.6 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

The implementation uses a modified version of the FORTRAN code parder.f, named pardtc.f, to evaluate the new coefficients. The knot and coefficient arrays are then sliced in the Python code and passed to the _from_tck private classmethod to construct a new instance.
Things that I'm unsure of:

maintainability of duplicated FORTRAN code
better organization of unit tests for the bivariate splines (duplicated code; might want to do housekeeping in a separate changeset)
whether it will play nice with typical subclasses of BivariateSpline

and I'd like to hear your comments. Thanks!
edit: more accurate description for the usage case where this could be beneficial.

Current status of this branch:

Tests should now fully cover the changes introduced.
Re-factored the class inheritance hierarchy a bit for better accommodation of the partial_derivative method, without affecting the typical usage of all other classes under scipy.interpolate.fitpack2.
Docstrings have covered all the changes introduced.

I will leave the branch as it currently is for a while and welcome your attention & review. The last rebase and force-push were to resolve a problem with outdated master in my repo affecting the sphinx build on CircleCI.

Thanks @congma, this looks interesting. We're a bit light on reviewers for Fortran code at the moment, so this could take a little while to review - apologies in advance.

@rgommers, there's nothing to apologize for!

Continued in https://github.com/scipy/scipy/pull/16220


metajam has been remove from CRAN

Package ‘metajam’ was removed from the CRAN repository.

Formerly available versions can be obtained from the [archive](https://cran.r-project.org/src/contrib/Archive/metajam).

Archived on 2024-06-28 as maintainer's email address is no longer in use.

A summary of the most recent check results can be obtained from the [check results archive](https://cran-archive.r-project.org/web/checks/2024/2024-06-28_check_results_metajam.html).

Please use the canonical form https://cran.r-project.org/package=metajam to link to this page.

https://cran.r-project.org/web/packages/metajam/index.html
Need to update my email address, but technically the NCEAS one is still live, so not sure on what check it is based on

Might be the culprit
---------- Forwarded message ---------
From: Prof Brian Ripley<EMAIL_ADDRESS>Date: Thu, Jun 27, 2024 at 1:37 PM
Subject: CRAN packages depending on package 'pamr'
To: Karam Daka<EMAIL_ADDRESS>Zhu Wang<EMAIL_ADDRESS>Max Kuhn<EMAIL_ADDRESS>Sebastian Malkusch<EMAIL_ADDRESS>Jakub Szlek<EMAIL_ADDRESS>Zhu Wang<EMAIL_ADDRESS>Julien Brun<EMAIL_ADDRESS>Martin Binder<EMAIL_ADDRESS>Aditya Mishra<EMAIL_ADDRESS>Laure Cougnaud<EMAIL_ADDRESS>Maciej Eder<EMAIL_ADDRESS>Cc: CRAN<EMAIL_ADDRESS>Packages
    AutoPipe bujar caret flowml fscaret irboost metajam mlr
    mpath nbfar nlcv stylo

require package pamr directly or indirectly and it has now been
orphaned.  The CRAN policy
"Orphaned CRAN packages should not be strict requirements (in the
‘Depends’, ‘Imports’ or ‘LinkingTo’ fields, including indirectly).
They are allowed in ‘Suggests’ if used conditionally, although this is
discouraged."
now applies. Please adjust your packages to comply by 2024-07-27.
--
Brian D. Ripley<EMAIL_ADDRESS>Emeritus Professor of Applied Statistics, University of Oxford

see #150 for progress

metajam is back on CRAN