pyrealsense2 Python3.8 support

This is related to #5777
Pyrealsense2 should support Python3.8+ without needing to build manually.

Thank you very much for your request.  I will label it as "Enhancement" (a Feature Request) so that it can be tracked by the RealSense team.

Any movement on this? Ubuntu 20.04 LTS shipped with Python 3.8 and currently it's not possible to install pyrealsense2 on it, building from source fails as well.

@Wallbraker   I have no update on this to provide, unfortunately.  I am on the Support team of the RealSense GitHub, and Feature Requests are tracked by the Developer team.

I confirm the urgent need for python 3.8 wheel file (cp38). Building from source fails, making Ubuntu 20 unsuitable for pyrealsense...

@progekta   I communicated with Intel internally yesterday about Pyrealsense2 installation issues.  I will add your message onto that communication.

The feature request for Python 3.8 support for pyrealsense2 pip installation has been officially logged with Intel via a similar case.
https://github.com/IntelRealSense/librealsense/issues/6126
I will therefore close this case, as the feature request can be processed via the case linked to above.  Thanks everyone for your input!

@MartyG-RealSense Sorry, I still cannot find the officially pyrealsense2 pip installation for python 3.8

@LivLee97   The file does not exist yet.  I have officially logged the 'feature request' with the developers for a pyrealsense2 wheel file for Python 3.8.   This is only a request though, and there is no timetable for when it might become available if the request is approved.   In the meantime, Python 3.8 users should compile pyrealsense2 from source code.

@MartyG-RealSense I tried to build from souce code. However, it does not fit Ubuntu 20.04. I want to know one solution to solve this problem.

Officially, Librealsense is only currently supported up to Ubuntu 18.04 LTS.  It is very usable on 20.04 if its source code is built with the RSUSB CMake installation method.
I wonder if you could build the Python bindings as part of the RSUSB build statement by including the -DBUILD_PYTHON_BINDINGS=true build flag.  For example, using this build statement in the Build folder of Librealsense:
cmake ../ -DFORCE_RSUSB_BACKEND=true -DBUILD_PYTHON_BINDINGS=true -DCMAKE_BUILD_TYPE=release -DBUILD_EXAMPLES=true -DBUILD_GRAPHICAL_EXAMPLES=true

pip install pyrealsense2 installs something that can not be loaded with python3, but python2; any advise? to build from source?

@AndreV84   pip install pyrealsense2 will not work with Arm based devices such as Raspberry Pi and Nvidia Jetson.
A Jetson Xavier user of pyrealsense2 shared his solution for adjusting CMake so that it would work with Python 3.
https://github.com/IntelRealSense/librealsense/issues/6980#issuecomment-666858977

@MartyG-RealSense
Thank you for folowing up!
I found that on x84_64 python3 pyrealsense can be installed with
python3 -m pip install pyrealsense2
it creates a file with a long name like cpython---36---pyrealsense.so or similar; that can be copied to anywhere in a way so that any python3 import will work from there

@AndreV84   Thanks very much for your own solution, I have made a note of it    :)

hi @MartyG-RealSense
is the library available for python3.8 now?

Hi @siddharthcb   The pyrealsense2 wrapper has always been usable on Python 3.8, but you have to build it from source code because there is not yet a pip package for 3.8 (only up to Python 3.7 at the time of writing this).

any clue when the pip package will be available for 3.8?

There is currently no information available about a timeline for a pip install package for 3.8.  An official feature request was filed this year for the creation of one though.

Can someone please clarify ( complete newbie here). I am currently running Visual Studio CODE ... is doing this whole wrapper thing for python 3.8 only possible with VS only?

Hi @karlita101   If you have a PC (that likely has a type of processor chip called x86 or x64) then you can install the Python wrapper using a method called pip install.
The Python wrapper can also be built from source code with the CMake tool..
These two methods are described in the installation section of the documentation for the Python wrapper.
https://github.com/IntelRealSense/librealsense/tree/master/wrappers/python#installation

@MartyG-RealSense: Any news or timeline available now?

Hi @maxstrobel   No sorry, no news to provide.

Python 3.9 and 3.8 have been released and yet pyrealsense2 on PyPi only offers Python 3.7.  Seems that Intel no longer supports RealSense for Python.   This ticket which is closed seems to have the most recent info, but there is another ticket #6126 that is open.

Hi @tomgoddard   Python support for RealSense has not been abandoned.
In the link below, an explanation is offered for the time taken to implement support for Python versions newer than 3.7.
https://github.com/IntelRealSense/librealsense/issues/8229#issuecomment-767348365
A method for hex-editing the Python 3.7 pip whl file was also suggested in that discussion by a RealSense community member.
https://github.com/IntelRealSense/librealsense/issues/8229#issuecomment-767115385

@MartyG-RealSense
Thanks for the response. Nevertheless, I think for most users it would be quite important to get access to packages for current Python releases via pip.
This would bring us a lot of benefits:

less error prone
simpler to use
simpler to integrate into existing software frameworks
less overall effort (packages built only once centrally, not by every user)

Thanks @maxstrobel   I hope that the explanation in the provided link demonstrates that Intel remains commited to RealSense support in Python.

Hi @MartyG-RealSense.  You have a strange notion of "support" when Intel is only providing pyrealsense2 for a 2019 version of Python (3.7) two behind the current Python version that almost no Python developers use, and provide complex build scripts using PyBind11 that have only been tested with Python 3.7.  I am sure I could build pyrealsense2 as I write Python and C++ code for a living, but it does not make sense to work on an abandoned product, I can't afford to take over maintenance of Intel's code.
Maybe MartyG and Intel don't realize but they have abandoned Python RealSense support.  You can be sure there are almost no developers using RealSense with Python when they impose such large burdens and costly burdens on the developer.
The proposal to hack the pyrealsense2 binary is just laughable.  Python 3.9 and 3.7 are not ABI compatible -- you can trick Python 3.9 to accept the 3.7 pyrealsense2 by hacking the binary and then send tens of thousands of dollars down the drain as you try to debug the unpredictable crashes your customers experience.

The hex editing method was provided by a RealSense community member to assist a RealSense user who required at least a temporary workaround for Python 3.9 due to project deadlines.  It was not an official Intel-provided solution.
In that particular case, building the pyrealsense2 wrapper from source (which can be used to install pyrealsense2 for Python versions newer than 3.7) was not compatible with the RealSense user's project needs as they required a pip-based solution.  Python continues to be strongly used by RealSense developers.

I would really need some kind of timeline, if and when we can expect support for newer Python releases.
If it is simple to generate bindings for newer versions as in #8229, it can also be easily packaged and distributed via pypi. If not, we have a fundamental problem.

Other than the update to pybind11 that has been merged into the SDK in pull request https://github.com/IntelRealSense/librealsense/pull/8176 I have no further information currently available about version updates to the pyrealsense2 wrapper's pip packages.

@maxstrobel
Python 3.8 was released in October 2019, and Python 3.9 was released in October 2020 while pyrealsense2 is only built for Python 3.7 (released June 2018) on PyPi.
In #6126 and #6296  a Python 3.8 PyPi package is requested and @MartyG-RealSense made an enhancement request in April 2020.  The  story after that is always the same "Nothing new to report", and "RealSense strongly supports Python".  It's a joke.  The strong support means you can try to compile it yourself although you are likely to run into problems since the RealSense team have apparently not tried to compile it for Python 3.8 or 3.9.  So you can try to update the RealSense build if you have the time.
Sadly this is a common fate of boutique hardware.  Intel puts lots of effort to making a nice piece of hardware and then does not provide usable software to control the device.  Then they are surprised when the product fails because few people developed for it.  It would be useful if @MartyG-RealSense would relay the problem to someone who can salvage this but it sounds like he does not have the power to do that.

Hi everyone,
I wanted to update you on progress.  SDK version 2.43.0 has just been released and has the following comment in its release notes:
[Python] Generate wheels for Python 3.8 + 3.9
Package classifiers updated to support python 3.8 + 3.9

Do you believe you could provide a classifier for python 3.10?

@MartyG-RealSense
any chance we could use realsense on wsl ubuntu?

@AndreV84  A RealSense user at https://github.com/IntelRealSense/librealsense/issues/10506#issuecomment-1125860744 had camera detection problems when using WSL2.  They managed to detect the camera with Windows 11 after adjusting some settings, but did not succeed with Windows 10.


Cleanup legacy code in the node

This is about cleaning up all legacy stuff in preparation of Rusk and UI integration

All issues related to this Epic have been solved, and so this can now be closed.

All issues related to this Epic have been solved, and so this can now be closed.


Revert "Auth: Always call prior handlers during Challenge"

#1044 @HaoK
@pranavkm When will the 1.1.1 branches be created?
/cc: @PinpointTownes @brockallen @leastprivilege @blowdart

Hi @Tratcher, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

@HaoK Updated

Cherry-picked into dev. I'll hold this one until I get confirmation of the branch from @pranavkm.

Moving to the rel/1.1.1 branch


Translation method

Hi there!
Does the package also support a scan for translations that are called by using the __() function?

@Donny5300, no it does not support this so far. I am considering adding it in the future.

This has been added in the master branch for Laravel 5.6


[Beta] Migrating projects from 1.2.1 to 2.0.0 makes Actor: Push Away from Player react differently to collisions

Describe the bug
I'm using the sample project to test this. In 2.0.0, a pushed actor using a migrated old project will only move 1 tile if it is within 2 tiles of hitting collision. This seems to be because the way that collision masks/actor origins work has been changed for 2.0.0 so the collision mask now makes more sense in relation to the background tile map.
Still, 2.0.0's migrated version of the 1.0 sample project makes pushed actors stop 1 space early from where they should be colliding, breaking most sliding puzzles such as the sample project's underground boulder puzzle.
To Reproduce
Steps to reproduce the behavior:

Create sample project in 1.2.1
Open 2.0.0 and load the project saved in 1.2.1
Click "migrate"
Run the project and try the boulder puzzle underground
The puzzle is incompletable, all boulders are trapped because they only move one tile before stopping.

Expected behavior
The boulder moves two tiles and then stops.
Here is what it looks like when all boulders are moved as far upwards as possible in 1.2.1's sample project:

And here's the editor window for underground in 1.2.1:

Here is what it looks like when all boulders are moved as far upwards as possible in 2.0.0 using the migrated sample project:

And here's the editor window for underground in 2.0.0 Beta. The collision mask has not changed, but the behaviour surrounding them has.

This does not apply to all Actors who use Push Away from Player, as this boulder works just fine in all directions:

It probably just has to do with how pushed actors see the collision mask.
Platform:

OS: Windows 10 64bit
App version 2.0.0 / 1.2.1

My suggested fix:
I notice that pushed actors and collision tiles are set up very differently in 2.0.0's native sample project, so I wonder if migrating should include bumping the collision masks up by one tile to compensate for the improved collision mask preview?

I think this was noted in the changelog, and is intended, though perhaps migration needs a clearer message that push events use a 2x2 tile collision now during migration.
Moving all collision will not fix the issue, they were 1x2 (same as player, very broken with other actors) and now 2x2.

Since we're in 3.0, I'll just close this issue about 1.0 to 2.0 migration


vmem OOM on TPU

Hi,
I tried to run your script on Cloud TPU v4-64, but failed with following error:
jaxlib.xla_extension.XlaRuntimeError: RESOURCE_EXHAUSTED: XLA:TPU compile permanent error. Ran out of memory in memory space vmem. Used 59.79M of 16.00M vmem. Exceeded vmem capacity by 43.79M.
I tried mesh dim of 1,1,1,32 and 1,1,4,8 all failed.
Any suggestion what caused the error? Thanks.

use 1,-1,1,1
that's the best sharding case or write custom sharding methods and use FSDP on every layer that's easier

Sorry for the delay. vmem OOM error is likely due to using large chunk size. I have tried v4-64 with chunk size 512, it worked well with fast computation and overlapped communication. Regarding sharding, you can refer to https://github.com/LargeWorldModel/LWM/blob/main/docs/sharding.md


A.04.IR13.4.topo

This issue has been extracted from the issue list on:https://ies-svn.jrc.ec.europa.eu/issues/2685
Comment
It is not clear from the TG how topological consistency is encoded.
It is not clear from the test case how it can be tested.

I do not know about this.

Clarified encoding to the extent covered by the TG, which is still vague. The TG should provide more guidance on how the different quality measures for topological consistency have to be encoded, and tested. As this is different per theme, this is unlikely to be testable based on just the data specification template.


DevTest Labs VM start/stop should support Azure Resource Manager using workload identity federation with openid connect

Azure DevOps Extensions
DevTest Labs
Is your feature request related to a problem? Please describe.
DevTest Labs VM start/stop should works with  Azure Resource Manager using Service Principles, but fails with null error if the service connection usesAzure Resource Manager using workload identity federation with openid connect
Describe the solution you'd like
Should support  workload identity federation with openid connect
Describe alternatives you've considered
No response
Additional context
Workaround is to use the older service principle model, but Microsoft are encouraging people to move away from this to  workload identity federation (with a single click to convert)

These tasks are based on Microsoft tasks to create VMs https://github.com/Azure/azure-devtestlab. Any change should be done using the same pattern these related tasks use i.e. swap to Node from PowerShell


Fused SelfAttention and Cross Attention Decoder

Context
What is the purpose of this PR? Is it to

[x] add a new feature
[ ] fix a bug
[ ] update tests and/or documentation
[ ] other (please add here)

This adds a prototype implementation of a flamingo model. This introduces fused layers and fused embeddings for combining cross attention layers with a decoder language model backbone. In the included component builders, this PR uses Llama3 as the reference.
Changelog

Flamingo component builders - llama3 based decoder component
modules/model_fusion - modules for fusing layers between pre-trained model, loosely follows peft design

Out of scope: flamingo encoder, utilities for manipulating fused model parameters
Test plan
This is a new experimental component builder, it will be tested once a model builder is put together.

[x] run pre-commit hooks and linters (make sure you've first installed via pre-commit install)
[ ] add unit tests for any new functionality
[x] update docstrings for any new or updated methods or classes
[x] run unit tests via pytest tests
[x] run recipe tests via pytest tests -m integration_test
[ ] manually run any new or modified recipes with sufficient proof of correctness

[ ] include relevant commands and any other artifacts in this summary (pastes of loss curves, eval results, etc.)

#1338 implements the fusion modules from here.


Pull requests are not triggered on comment triggers ( >= 1.32.4)

Having upgraded from 1.32.3 to .4 and .5, and having done a lot of extensive testing, I have found that the comment triggers no longer work. The logs clearly show that there is some difference in the paging of the comments. This behavior is observed irrespective of the value of "Only use trigger phrase for build triggering"
Here is a selected output from the log. I use the same trigger phrase for both. I have made sure that I make new comments too.
v1.32.3
Running trigger for arrayfire-linux/pr-build-tester
Jun 14, 2016 9:46:01 PM INFO org.jenkinsci.plugins.ghprb.GhprbPullRequest updatePR
Pull request #17 was updated/initialized on shehzan10/arrayfire at 6/14/16 9:44 PM by Shehzan Mohammed (PR update)
Jun 14, 2016 9:46:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Checking for comments after: 6/14/16 9:14 PM
Jun 14, 2016 9:46:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made at: 6/14/16 8:46 PM
Jun 14, 2016 9:46:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made at: 6/14/16 9:00 PM
Jun 14, 2016 9:46:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made at: 6/14/16 9:03 PM
Jun 14, 2016 9:46:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made at: 6/14/16 9:11 PM
Jun 14, 2016 9:46:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made at: 6/14/16 9:14 PM
Jun 14, 2016 9:46:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made at: 6/14/16 9:44 PM
Jun 14, 2016 9:46:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made after last update time, build arrayfire linux tester ci
Jun 14, 2016 9:46:02 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
[Shehzan Mohammed] Added comment: build arrayfire linux tester ci
Jun 14, 2016 9:46:02 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Trigger phrase
Jun 14, 2016 9:46:02 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Admin User:shehzan10 ran trigger phrase
Jun 14, 2016 9:46:02 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Running the build
Jun 14, 2016 9:46:02 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
PR is not null, checking if mergable
Jun 14, 2016 9:46:02 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Running build...

v1.32.5
Running trigger for arrayfire-linux/pr-build-tester
Jun 14, 2016 10:02:00 PM INFO org.jenkinsci.plugins.ghprb.GhprbPullRequest updatePR
Pull request #17 was updated/initialized on shehzan10/arrayfire at 6/14/16 10:01 PM by Shehzan Mohammed (PR update)
Jun 14, 2016 10:02:00 PM INFO org.jenkinsci.plugins.ghprb.GhprbPullRequest updatePR
Pull request #17 was updated on repo shehzan10/arrayfire but there aren't any new comments nor commits; that may mean that commit status was updated.
Jun 14, 2016 10:02:00 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Trigger only phrase but we are not triggered
Jun 14, 2016 10:02:00 PM FINE org.jenkinsci.plugins.ghprb.GhprbTrigger

Just to be extra sure, I downgraded again to 1.32.3 and added a new comment trigger, and it works. You can notice the timestamps of the comments too between the 3 logs.
Downgrade to v1.32.3
Running trigger for arrayfire-linux/pr-build-tester
Jun 14, 2016 10:16:01 PM INFO org.jenkinsci.plugins.ghprb.GhprbPullRequest updatePR
Pull request #17 was updated/initialized on shehzan10/arrayfire at 6/14/16 10:14 PM by Shehzan Mohammed (PR update)
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Checking for comments after: 6/14/16 10:01 PM
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made at: 6/14/16 8:46 PM
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made at: 6/14/16 9:00 PM
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made at: 6/14/16 9:03 PM
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made at: 6/14/16 9:11 PM
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made at: 6/14/16 9:14 PM
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made at: 6/14/16 9:44 PM
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made at: 6/14/16 10:01 PM
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made at: 6/14/16 10:14 PM
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Comment was made after last update time, build arrayfire linux tester ci
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
[Shehzan Mohammed] Added comment: build arrayfire linux tester ci
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Trigger phrase
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Admin User:shehzan10 ran trigger phrase
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Running the build
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
PR is not null, checking if mergable
Jun 14, 2016 10:16:01 PM FINEST org.jenkinsci.plugins.ghprb.GhprbPullRequest
Running build...

Same issue here. Appears to have broken in 1.32.4

I tried 1.32.6 and the trigger phrase was still not working for me. Rolling back to 1.32.3 fixed it.

I see no option to upgrade to 1.32.6 yet from plugin manager so I can not help to test.
For 1.32.5, job is not triggered with trigger phase.

I tried 1.32.6 today, issue still occur.

@DavidTanner Sorry to ask: where is the right place to post issue:
https://github.com/jenkinsci/ghprb-plugin/issues
or
https://github.com/janinko/ghprb/issues
Let us know. Thanks!

I prefer here.

@DavidTanner ok

@DavidTanner It works just great now.

@zelonght you mean v1.32.8?

yes @shehzan10

Installed 1.32.8, and comments work fine.

@shehzan10 can you check and close the issue if it's fixed.

Fixed in v1.32.8

I'm seeing this issue in 1.40.0, it sometimes takes multiple comments in order for a build to successfully start. This probably needs to be reopened.
Checking issue comment '/jenkins merge' for repo BobLobLaw/Blog
Mar 27, 2018 5:41:40 PM INFO org.jenkinsci.plugins.ghprb.GhprbGitHubAuth checkSignature
Signatures checking OK
Mar 27, 2018 5:41:40 PM INFO org.jenkinsci.plugins.ghprb.GhprbGitHubAuth checkSignature
Signatures checking OK
Mar 27, 2018 5:41:40 PM INFO org.jenkinsci.plugins.ghprb.GhprbTrigger handleComment
Checking comment on PR #2,350 for job BobLobLaw/Blog Pull Request Builder Pipeline
Mar 27, 2018 5:41:40 PM INFO org.jenkinsci.plugins.ghprb.GhprbPullRequest updatePR
Pull request #2,350 was updated/initialized on BobLobLaw/Blog at 3/27/18 5:41 PM by null (comment)
Mar 27, 2018 5:41:40 PM INFO org.jenkinsci.plugins.ghprb.GhprbTrigger handleComment
Checking comment on PR #2,350 for job BobLobLaw/Merge
Mar 27, 2018 5:41:40 PM INFO org.jenkinsci.plugins.ghprb.GhprbPullRequest updatePR
Pull request #2,350 was updated/initialized on BobLobLaw/Blog at 3/27/18 5:41 PM by null (comment)
Mar 27, 2018 5:41:41 PM INFO org.jenkinsci.plugins.ghprb.GhprbPullRequest updatePR
Pull request #2,350 was updated on repo BobLobLaw/Blog but there aren't any new comments nor commits; that may mean that commit status was updated.
Mar 27, 2018 5:41:41 PM INFO org.jenkinsci.plugins.ghprb.GhprbPullRequest updatePR
Pull request #2,350 was updated on repo BobLobLaw/Blog but there aren't any new comments nor commits; that may mean that commit status was updated.
Mar 27, 2018 5:42:01 PM INFO org.eclipse.jetty.server.session.Session beginInvalidate
Session node010xhtc8crevl21iahqjxygttct2792037 already being invalidated```

Also seeing a similar behavior as described as above.

Using 1.40.0 and not being able to trigger builds on every PR


Fix align in Fullscreen Preview (#37)

Sublime removed some whitespaces, too.
Fixes #37

dead project, closing

I fixed this anyways now that i revived it.


Conflict with Obsidian Properties rendering

With the BPMN plugin turned on, the rendering of Obsidian Properties is affected by the BPMN colors. The property name, signified by tags: renders as black on white regardless of theme, and regardless of light/dark mode. Even the "default force white background" option doesn't affect it if turned off. So there may be a special case needed for handling color when in the Properties block of a document.

Thank you!
It is fixed with the next version.


Switching between chats using LHN causes chats to get stuck offscreen

If you haven’t already, check out our contributing guidelines for onboarding!

Expected Result:
When switching between chats in mobile web for E.Cash, I expect the chat to load and display correctly
Actual Result:
When switching between chats in mobile web for E.cash in Chrome on iOS, the second chat you switch to is not displayed correctly, and is off-screen
Action Performed:

Sign in to Expensify.Cash on Chrome or Safari on iOS
Tap on the chat switcher, and switch to a chat with a user (or use the search function)
Tap back to the chat list
Tap on the chat switcher again, and switch to a chat with a different user
The chat should render mostly off-screen, with most of the chat content not visible (if it doesn't, switch back to the other chat - it is inconsistent!)

Workaround:
You are forced to reload the page.
Platform:
Web: No
iOS: No
Android: No
Desktop App: No
Mobile Web: iOS - Yes | Android - No
Version Number: v1.0.2-73
Notes/Photos/Videos: Any additional supporting documentation
Here's a short recording of this happening:

Here's how the chat renders:

https://www.upwork.com/jobs/~01a09bd14ffed37ba9
https://github.com/Expensify/Expensify/issues/157743

Hello @tylerkaraszewski, I would love to look into this.
Working on a proposal.

Hi,
This is Kaushik here. I would like to put a technical explanation for this,

It may be an animation interpolate issue, first we will deploy to our local system and check with a real device with debugging.

I'm not sure how to solve this yet but, it seems like it would be related to the DrawerNavigator implementation in react-navigation

I've found another way to recreate it:

From Home
Tap the FAB button
select New Chat

https://user-images.githubusercontent.com/12156624/113295396-d3f0f880-9300-11eb-8aaa-d5c258d1d67a.mp4
I think I found what's causing it:
https://github.com/Expensify/Expensify.cash/blob/68866790ce210cfb78c41e84cb079b6b192fa5b0/src/components/OptionsSelector.js#L89-L91
Removing this fixes the issue when you tap the search icon or when you open a new chat.
I don't know why (yet 😀) but this causes navigation transitions to stop
In summary the issue seems related to focusing, focusing quickly on a field during animation causes this, but it's perhaps something that should be addressed in React Navigation
...and (am I getting annoying with this 😄) removing autofocus navigation on mobile (mWeb as well, aka small screens) would fix this

You can use desktop safari for more debugging options

@marcaaron - what do you think about this analysis?

I'm not able to reproduce this. But if disabling the "auto focus" behavior will fix it then we are discussing this possibility here and if we do decide to remove the auto focus for inputs on mobile then this should be fixed by default. cc @trjExpensify since this is another potential issue related to auto focus.

I tested it. Autofocus has nothing to do with it. It still exists. Easier reproduction for this is to try to change the resolution in a responsive mode in the browser.
https://user-images.githubusercontent.com/24370807/113441370-c83e2880-940b-11eb-944e-584bda264f3f.mp4

Autofocus has nothing to do with it

That's a bit harsh ☹, In my attempts removing the focus in OptionsSelector.js fixed the issue when I open a New Chat and when I open Search. It did not fix the issue for switching between chats as the focusing handled by a different component there
Changing the size dynamically might be another way to cause this problem.

I've researched the handling of input fields in mobile Safari further.
When an input is focused mobile Safari would try to position it nicely in the middle for the user
In our case this happens while the drawer is still moving
Here is a good explanation:  https://gist.github.com/kiding/72721a0553fa93198ae2bb6eefaa3299

When an input element gets focused, iOS Safari tries to put it in the center by scrolling (and zooming.)
Zooming can be easily disabled using a meta tag, but the scrolling hasn't been quite easy.

And here's the same problem reported on stackoverflow: https://stackoverflow.com/a/6918582/4834103

I've had this problem before where a fixed size webapp (built for iPad) gets partially scrolled out of view by the browser because it tries to center the text-field in the view.

Changing the viewport dimensions might be causing the same issue, but I think it's a lot less likely to happen IRL

There's a ticket related to viewport size change on react navigation: https://github.com/react-navigation/react-navigation/issues/8551
Thought specifically for the autofocus cases:

an action is selected
content with a field is mounted outside the viewport (abs position?)
the field is focused during the transition and the transition stops

I've also recreated this on mobile Chrome

It does seem like perhaps the fix would be in react-navigation based on that issue. Curious what some debugging might reveal.
Not sure if react-navigation is using a CSS transition in this case, I believe it's using react-native-reanimated for the drawer and setting the translateX property. Not sure if it helps, but it doesn't seem to happen consistently which makes me wonder if some slow running JS is causing the translateX value to be incorrect.

Create a ticket about withWindowDimensions: #2326

Proposal
It seems you want this fixed, but dropping auto focus on mobile is not a suitable solution for you
You want this bug fixed and still retain the ability to auto focus even if you decide against auto focus at some point down the road, correct?
Here's a proposal in that direction:
Apply the autofocus after the nav/modal transition ends so that focusing does not interfere with the transition
I think the issue no longer occurs when switching chats - with the changes merge here #2221 the compose input is initially disabled. And I can no longer recreate the issue by simply switching chats. Only from the FAB.
A potential fix might be to encapsulate logic inside the TextInputFocusable that would query the navigation state like this
// from: import { useFocusEffect } from '@react-navigation/native';
useFocusEffect(() => {
  // This code would run when a screen containing a TextInputFocusable is focused
  if (props.autoFocus) {
    textInput.focus();

    // the uglier version (in case the above doesn't work) is to focus after a brief  `setTimeout`
    //  (hook logic should be added to clear pending timers)
  }
})

Actually disregard the setTimeout note here's what I found out:
Delaying effect until transition finishes
useFocusEffect(
  React.useCallback(() => {
    const task = InteractionManager.runAfterInteractions(() => {
      textInput.focus();
    });

    return () => task.cancel();
  }, [])
);

I'm using the hook syntax for simplicity this can be recreated with a HOC, though it was agreed that in situations like this one it might be for the best to just use hooks
TextInputFocusable is a class component so the hook code cannot go directly there, but you can easily wrap the TextInput used as an end result in a functional component wrapping
props.autoFocus Can serve to override this behavior if needed.

there is more than one input field on the screen, we want to make sure the focus is on the first field
you decide to drop autofocus on mobile

The ticket mentioned above #2326 could also be considered as when the keyboard appears all the dimension listeners from withWindowDimensions HOC are triggered all at once.

It seems you want this fixed, but dropping auto focus on mobile is not a suitable solution for you
You want this bug fixed and still retain the ability to auto focus even if you decide against auto focus at some point down the road, correct?

I'm not sure that's correct. Pretty sure we have unanimously come to the decision that we should stop auto focusing this input when we open up to a new chat.
I'm curious thought, after the ReportView changes is this issue still reproducible?

@marcaaron

I'm not sure that's correct. Pretty sure we have unanimously come to the decision that we should stop auto focusing this input when we open up to a new chat (on mobile and mobile web at least).

Then it would should be even easier.
If the behavior become platform specific. you could already use the existing autoFocus prop to disable this behavior on small screens. There are some tricks to detect whether the current device is touch only (software keyboard) or it has a dedicated keyboard but things become a bit hacky and need better research on the topic.

I'm curious though, after the ReportView changes is this issue still reproducible?

Yes, it doesn't happen 100% of the time, but it would still happen (mobile web Safari)

Since autofocus still happens on mobile web this issue still occurs:
Autofocus still happens when switching chats due to:
https://github.com/Expensify/Expensify.cash/blob/6db2ed04dcfd04aba495371dda93983f7691a058/src/components/TextInputFocusable/index.js#L94-L96
Autofocus still happens on FAB -> search, or FAB -> new chat because:
https://github.com/Expensify/Expensify.cash/blob/431b60d09f4e41c7532707454625dbe2c3c22c21/src/components/OptionsSelector.js#L89-L91
Earlier I've provided info on how autofocus is causing this issue. Since it is decided that on mobile and mWeb fields should not be focused automatically addressing the remaining input focus issues would fix this bug.
Proposal
Refactor TextInputFocusable so that the default value for autoFocus prop is based on this logic here:
https://github.com/Expensify/Expensify.cash/blob/6db2ed04dcfd04aba495371dda93983f7691a058/src/pages/home/report/ReportActionCompose.js#L99
Fix the on mount code to respect the autoFocus - simply removing the call to focus is enough as the autoFocus prop is applied as attribute on the DOM node and the browser will handle this
Since we modify the default props autoFocus can be overriden if necessary by the parent component using TextInputFocusable
Update the code in the OptionsSelector to use the TextInputFocusable component instead of TextInputWithFocusStyles
https://github.com/Expensify/Expensify.cash/blob/431b60d09f4e41c7532707454625dbe2c3c22c21/src/components/OptionsSelector.js#L170-L175
Or Update the TextInputWithFocusStyles to use a TextInputFocusable internally instead of TextInput:
https://github.com/Expensify/Expensify.cash/blob/431b60d09f4e41c7532707454625dbe2c3c22c21/src/components/TextInputWithFocusStyles.js#L64-L67
Whichever is easier and makes more sense
This would allow reuse and cut down repetitive code by defaulting field autoFocus to true for desktop/web and false for mobile
Remove the canFocusInputOnScreenFocus from ReportActionCompose since it will be applied by the TextInputFocusable

@kidroca It does seem to improve things quite a bit and also that behavior to focus on mount in TextInputFocusable is 100% wrong given the recent changes.
Anyways, I think this is a good improvement and just removing the this.focusInput() alone seems to do wonders for un-sticking the drawer. It is confusing to have TextInputWithFocusStyles and TextInputFocusable so I am in favor of refactoring that stuff. Maybe we can split some of the proposed changes into multiple PRs.
One thing I've also noticed is that when a new report is loaded this can also cause re-renders in the SidebarLinks (which are pretty expensive to re-render) so preventing re-render when the drawer is closed might also get us some minor improvements. The next version of react-navigation provides a useDrawerProgress hook that could be used to delay expensive operations, but we can probably worry about that another time.

I think this is a good improvement and just removing the this.focusInput()

@marcaaron  It's worth mentioning that it has been removed already. https://github.com/Expensify/Expensify.cash/pull/2528

It is confusing to have TextInputWithFocusStyles and TextInputFocusable so I am in favor of refactoring that stuff. Maybe we can split some of the proposed changes into multiple PRs.

Yes, I that was my initial thought but seeing that TextInputFocusable does not deal with styles - just the behavior. It would be easier to put it inside TextInputWithFocusStyles to verify the bug is fixed. And then we can arrange something better.
Because TextInputFocusable does not deal with styles itself it might be necessary to be wrapped by a "styling" component like TextInputWithFocusStyles otherwise the styles would go up to OptionsSelector ...

The next version of react-navigation provides a useDrawerProgress hook that could be used to delay expensive operations, but we can probably worry about that another time.

Couldn't the InteractionManager.runAfterInteractions be used as it's intended exactly for this. Or it doesn't work for some reason?

One thing I've also noticed is that when a new report is loaded this can also cause re-renders in the SidebarLinks (which are pretty expensive to re-render)

I'll take a look too

Sorry @kidroca let's actually hold since maybe there is not much more that needs to be done if this has already been fixed. InteractionManager.runAfterInteractions() doesn't seem as relevant to issues affecting web.

@marcaaron Only the code in TextInputFocusable was updated - The issue would be fixed when switching chats, but not for "Search", "New Chat", "New Group Chat", other options with an input field
The autofocus inside the OptionSelector is still a fact:
https://github.com/Expensify/Expensify.cash/blob/431b60d09f4e41c7532707454625dbe2c3c22c21/src/components/OptionsSelector.js#L89-L91
This needs to be updated so that autofocus happens only on desktop/web.
It would be better to have this behavior encapsulated in TextInputFocusable and reused for all the places (and future usages) that need focus on desktop/web but not on mobile

@kidroca This is has been taken care of by https://github.com/Expensify/Expensify.cash/pull/2505. Unless you have something new to add.

Ok so "no autofocus" on mobile is not 100% true
This will still auto focus on all platforms
       this.interactionHandle = InteractionManager.runAfterInteractions(() => {
            this.textInput.focus();
        });

As Marc pointed out

InteractionManager.runAfterInteractions() doesn't seem as relevant to issues affecting web.

The issue would probably still occur on mobile safari

Other than this I noticed is that we should debounce the dimension changes which is really causing a lot of calculations

I've added measurements on the effect of dimension changes in the ticket here: #2326
There are no dimension changes happening when the bug occurs "naturally" - the users aren't changing window size or anything they just switch screens and this does not trigger dimension changes

This needs to be updated so that autofocus happens only on desktop/web.

To clarify, I'm not sure this has actually been decided. The case that we are discussing here is switching between chats.

Yup for the modal screen we want autofocus.

Ok so this ticket is only about switching chats and the "Search", "New Chat", "New Group Chat" will be handled separately, or you mean focus handling for them is not decided yet?
Just want to point out that all the "discoveries" here are related to "Search", "New Chat", "New Group Chat" and the issue is the same - a transition that involves immediate focus causes the "stuck offscreen" bug

this ticket is only about switching chats and the "Search", "New Chat", "New Group Chat" will be handled separately, or you mean focus handling for them is not decided yet?

Both of those statements are correct. This issue is related to switching chats (seems to be fixed now). As for disabling input focus on other screens I think probably it would be best to get some other opinions.

Sorry, I'm not talking about that autofocus would necessarily need to be removed on those screens, but the same "stuck offscreen" bug would remain for them
The same issue occurs when you use the FAB, but I don't think there's a separate ticket about it. I've brought that up a couple of times: https://github.com/Expensify/Expensify.cash/issues/2051#issuecomment-811881242
https://user-images.githubusercontent.com/12156624/113295396-d3f0f880-9300-11eb-8aaa-d5c258d1d67a.mp4
Also if autofocus should stay for the "Search", "New Chat", "New Group Chat" ... I've made another proposal that can keep autofocus and still fix the bug: https://github.com/Expensify/Expensify.cash/issues/2051#issuecomment-818045780
Anyway I'll wait for things to get cleared out

Ok sorry for all the back and forth here, but I think what we should do at this point is close this issue and create a new one so we can:

Verify the new issue you've discovered and the severity
See what can be done about the input focusing there or if it should be disabled

I thought this ticket would address it as well. I've brought that up a couple of times

Apologies for the confusion here. I should have encouraged us to create a new issue for that earlier, but assumed they would have the same root cause. Given that the main issue here is fixed, but the other is not we should create a new one.

@kidroca do you want to create the new issue, propose a solution, then fix it? If so, you'll be eligible for the $150 bonus

Yeah, I'll open a new ticket next week.
We'd have to discuss this there before a proposal can be made:

See what can be done about the input focusing there or if it should be disabled


[Android] Angle rebasing bug fix

Save 147K
BUG=XWALK-4521

Add info for reducing size.

LGTM

Please add Reduced size = 147k in git log, then I will merge this PR.

@halton Updated.


New rule for "silent execution" of popen based on Pytorch attack. Some cleanup of processing whl files

On Dec 31 2022, pytorch maintainers published this post detailing a supply chain attack.
It primarily focused on using dependency confusion on how pip installs packages in a particular order. An internal package was used (triton), but someone registered triton on pypi.
It was a copypasta of triton with one additional __init__.py that dropped a binary and executed it.
Triage analysis here
This P/R adds a rule that "alerts" on this attack by looking for subprocess.FUNC(...,) with arguments that make it a "silent execution" to reduce false positives. I successfully tested this on the malicious package in the post and it found the malicious code!
I thought our code execution code would catch this, but we scoped it to setup.py to reduce false positives. I think /dev/nulling std* is a very specific pattern for malware, so I added it here.

Thanks for the PR, will

[ ] Slightly reword the description
[ ] Rebase the PR against the v1.0-rc branch

Closing in favor of #117 that will be merged in v1.0-rc


failing to run Goose on my system

Goose is failing to run on my system.
In the terminal I am initialising the key as an environment variable like so:
export OPENAI_API_KEY=xxxxxx
I am getting the following error every time I run the project:

The key is active and is being called. As you can see an update on OpenAi's side (The last time I tried using this key was for Goose today , the 12th of Sept 2024):

Noticed we are using pipx so my python version should not be affecting this. But to test outside of this ran it in a python 3.12 conda env too and via the vanilla terminal
It would be great to see what is actually going on under the hood here with a verbose output flag for Goose, perhaps something like: goose session start -v

I think most likely this is because the API key does not have access to the model. We have some updates in progress to catch that and similar cases more clearly! Verbose mode is also a good idea here.
To try to confirm this, if you have an openai with chatgpt enabled, you likely separately have to enable billing for the API at platform.openai.com. Do you see API credits remaining at https://platform.openai.com/settings/organization/billing/overview?

Did you have any luck with this? if you upgrade, square/exchange#48 should show a much more clear error message


Prevent phantom metadata from crashing queries

This is a partial fix for the issue reported by @ikarth on #57.

Coverage increased (+0.06%) to 94.607% when pulling a8e0c6a665a5c15b25b00befec5a2f86612580e7 on phantom-metadata-querying into 33500f26fff41ae2e43460032e50f67db6165eef on master.

Coverage increased (+0.06%) to 94.607% when pulling a8e0c6a665a5c15b25b00befec5a2f86612580e7 on phantom-metadata-querying into 33500f26fff41ae2e43460032e50f67db6165eef on master.

Coverage increased (+0.06%) to 94.607% when pulling a8e0c6a665a5c15b25b00befec5a2f86612580e7 on phantom-metadata-querying into 33500f26fff41ae2e43460032e50f67db6165eef on master.

Coverage increased (+0.06%) to 94.607% when pulling a8e0c6a665a5c15b25b00befec5a2f86612580e7 on phantom-metadata-querying into 33500f26fff41ae2e43460032e50f67db6165eef on master.

Coverage increased (+0.06%) to 94.607% when pulling a8e0c6a665a5c15b25b00befec5a2f86612580e7 on phantom-metadata-querying into 33500f26fff41ae2e43460032e50f67db6165eef on master.


Weblate Translation - Automatic suggestions error

Getting an error during translation for wavelog via weblate -

The request for machine translation using OpenAI has failed: InternalServerError: Error code: 502 - {'error': {'code': 502, 'message': 'Bad gateway.', 'param': None, 'type': 'cf_bad_gateway'}}

73 de CT7AJM / F4VSE
PS: This error seems to be random and doesn't happen all the time.

Which browser do you use?


add llava model support

Original llm-awq project support LlavaL model, hope this could be add too.
AWQ_CAUSAL_LM_MODEL_MAP = {
    "mpt": MptAWQForCausalLM,
    "llama": LlamaAWQForCausalLM,
    "opt": OptAWQForCausalLM,
    "RefinedWeb": FalconAWQForCausalLM,
    "RefinedWebModel": FalconAWQForCausalLM,
    "bloom": BloomAWQForCausalLM,
}

LLaVa is a LLaMa model and should be supported for quantizing the linear layers.

Yes, LLaVa is LLaMa model. Changes need to be done, since now, following code cannot load official llava model,
model = AutoAWQForCausalLM.from_pretrained(model_path)

Llava is now supported.


nvidia-gridd not available with built packages

Trying to use the method of
https://developer.nvidia.com/blog/streamlining-nvidia-driver-deployment-on-rhel-8-with-modularity-streams/
to use the pre-compiled packages with a virtual GPU.
that requires that nvidia-gridd[1] is available and running but this seems to normally be generated by
NVIDIA-Linux-x86_64-470.63.01-grid.run in  the non rpm world.
Should the nvidia-gridd service be included in the release?
[1] https://docs.nvidia.com/grid/4.3/grid-licensing-user-guide/index.html#licensing-grid-vgpu-linux
Details:
CentOS Stream 8

4.18.0-348.7.1.el8_5.x86_64

nvidia-modprobe-495.29.05-1.el8.x86_64
nvidia-settings-495.29.05-1.el8.x86_64
nvidia-driver-NVML-495.29.05-1.el8.x86_64
nvidia-driver-cuda-495.29.05-1.el8.x86_64
nvidia-libXNVCtrl-devel-495.29.05-1.el8.x86_64
nvidia-driver-cuda-libs-495.29.05-1.el8.x86_64
nvidia-libXNVCtrl-495.29.05-1.el8.x86_64
nvidia-driver-NvFBCOpenGL-495.29.05-1.el8.x86_64
nvidia-driver-devel-495.29.05-1.el8.x86_64
nvidia-driver-495.29.05-1.el8.x86_64
nvidia-persistenced-495.29.05-1.el8.x86_64
dnf-plugin-nvidia-2.0-1.el8.noarch
nvidia-driver-libs-495.29.05-1.el8.x86_64
nvidia-xconfig-495.29.05-1.el8.x86_64
kmod-nvidia-495.29.05-4.18.0-348.7.1-495.29.05-3.el8_5.x86_64
nvidia-kmod-common-495.29.05-1.el8.noarch

It looks like the GRID sub-package nvidia-grid-utils is present for RHEL7 .spec but not for RHEL8 .spec.
I will try to find the time to add those changes to the RHEL8 .spec file too.

Do I understand correct that packages are released then are not suitable for vGPUs I'd have to rebuild with the grid.run variant of the tar ball.


Fails to detect python installed through winget

Create issues related to the winget.exe client here

Brief description of your issue

Winget fails to detect Python 3.9.5, installed through winget.
Steps to reproduce

winget install Python.Python
winget export -o pkgs.json
winget list

Expected behavior
Export should detect and export Python as Python.Python.
List should list
Python 3.9.5 (64-bit)                               Python.Python                3.9.5150.0

Actual behavior
Export reports
Installed package is not available from any source: Python 3.9.5 (64-bit)

List outputs
Python 3.9.5 (64-bit)                                {f3d4ed4c-f434-41ef-8469-ffadd80c4ccf}                   3.9.5150.0

Environment
[winget --info]
Windows Package Manager v1.0.11451

Windows: Windows.Desktop v10.0.19043.1023
Package: Microsoft.DesktopAppInstaller v1.11.11451.0

Seems like #16392 and #16393 solved this
PS C:\Users\Esco> winget list
Name                                        Id                                            Version
-----------------------------------------------------------------------------------------------------------
Python 2                                    Python.Python.2                               2.7.18150
Python 3                                    Python.Python.3                               3.9.5150.0

PS C:\Users\Esco> winget upgrade
No installed package found matching input criteria.

That fixed it. Thank you!


specified roles don't seem sufficient

we setup basiton in one subscription and the vm in another and peered the vnets between the two.  We setup the roles as required:

Reader role on the virtual machine.
Reader role on the NIC with private IP of the virtual machine.
Reader role on the Azure Bastion resource.

but were met with the uanble to query bastion data error

found https://cloudstep.io/2020/11/12/azure-bastion-unable-to-query-bastion-data/ and for users who had read on the VM's subscription they could connect.  Sure enough adding read to the vnet the vm was part of was required.  please update documentation to reflect this requirement.

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

ID: 0c234d88-d9f6-f33e-c245-e307cc37394e
Version Independent ID: 7a7a2f04-d668-c395-51fb-fc240a1a30af
Content: Connect to a Windows VM using RDP - Azure Bastion
Content Source: articles/bastion/bastion-connect-vm-rdp-windows.md
Service: bastion
GitHub Login: @cherylmc
Microsoft Alias: cherylmc

Hello @drdamour, Thank you for your feedback.
Yes, Reader role on the virtual network is required if the VM is present in the peered VNET. This is currently documented here.

As per the prerequisites of this tutorial this information is not documented here.

Hope this helps answer your question! We will now proceed to close this issue out, please tag me in your response if you have any additional questions. Thank you!

looks like this got added with https://github.com/MicrosoftDocs/azure-docs/commit/ce48d8821584ab5d94b1017bdd7772069b47d84b


Register package v0.2.0

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/41212
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.2.0 -m "<description of version>" 04a441d3306a2d2ed00a5deedc72f609149812e5
git push origin v0.2.0

Also, note the warning: This looks like a new registration that registers version 0.2.0.
Ideally, you should register an initial release with 0.0.1, 0.1.0 or 1.0.0 version numbers
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/41216
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.2.0 -m "<description of version>" 72dcc888b1240da5d5dd206b7388e34d12130cfd
git push origin v0.2.0

Also, note the warning: This looks like a new registration that registers version 0.2.0.
Ideally, you should register an initial release with 0.0.1, 0.1.0 or 1.0.0 version numbers
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.

Registration pull request updated: JuliaRegistries/General/41216
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.2.0 -m "<description of version>" 72dcc888b1240da5d5dd206b7388e34d12130cfd
git push origin v0.2.0

Also, note the warning: This looks like a new registration that registers version 0.2.0.
Ideally, you should register an initial release with 0.0.1, 0.1.0 or 1.0.0 version numbers
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.


fix(secrets): keep the same type of secret field on json serialization

Change Summary
Change Secret (including SecretStr and SecretBytes) serialization to json to keep original type.
Also, add bool(secret) for convinience.
Before:
from pydantic import BaseModel, Secret
class Foo(BaseModel):
    secret_data: Secret[dict]
foo = Foo(secret_data={"bar": "bar_value"})
print(foo.model_dump(mode='json'))
#> {'secret_data': '**********'}

After:
from pydantic import BaseModel, Secret
class Foo(BaseModel):
    secret_data: Secret[dict]
foo = Foo(secret_data={"bar": "bar_value"})
print(foo.model_dump(mode='json'))
#> {'secret_data': '{}'}

Checklist

[x] The pull request title is a good summary of the changes - it will be used in the changelog
[x] Unit tests for the changes exist
[x] Tests pass on CI
[x] Documentation reflects the changes where applicable
[x] My PR is ready to review

Selected Reviewer: @sydney-runkle

please review
since #9240 was reviewed by @hramezani, I think it would be better if he's assigned

It seems some tests are failing. Will convert to draft for now

Now all tests are fixed and PR is ready to be reviewed.
I'm sorry for not reading PR rules in advance and not creating an issue, but I think keeping the same value type on serialization is an expected behavior and will be needed at least in some cases (we needed this in our project, and that's why I'm here).
If you choose to, I can keep original behavior of serialization for SecretStr and SecretBytes, but I changed their behavior so there's consistency among all types.

@sydney-runkle thank you very much for quick review!
Just wondering, if we keep current behavior for SecretStr and SecretBytes, is it still a big change for just Secret?
It seems to me that if people didn't have problems with Secret and json serialization, they won't have problems with new behavior, because it still serializes to string. And SecretStr and SecretBytes would be the same. Or if there's any chance this idea will be approved, it's better to open an issue?
And should I tag someone specific when\if I open an issue, or can I just tag you?

@Danipulok,
Happy to discuss further in an issue! Feel free to tag me :).
In general though, I think we won't want to change the default serialization behavior for these types, as folks are already dependent on them, and can easily customize the serialization behavior.


Aggregate relation statistics per database

The change will help to make base_query_all_rels_sample() more efficient for clusters with a lot of relations.

Hello @CyberDem0n
I'm wondering whether it's worth spending effort for that in v4.0.
How about merging this PR as-is in v4.0 if you still need it, and spend instead effort in v4.1 to drop entirely the powa_all_relation/powa_user_function thing and instead allow the collector to connect to other databases, and retrieve all the information that would be needed?
We'll have to go there anyway, so there's probably no need to delay v4 any further.

Ok, I updated the query which aggregates statistics per database. This is probably the best we can do right now without having access to pg_index.

Thanks a lot, merged!
I'll try to work on the UI part to use those new tables quickly so we can finally release v4 and start working on the 4.1 wish list.  FTR a new powa-archivist-git docker image should be pushed soon.
Also, feel free to add additional items for the V4.1 scope if you think about more data to aggregate

@CyberDem0n I just pushed https://github.com/powa-team/powa-web/commit/f48d4aa790c7edb7276979322fc5f5d94f3931da which should use this new infrastructure.  Let me know if that fixes your performance issue if you have a way to test that easily.


MB-10469: Pull in the net/http go opentelemetry implementation for improvements, standardize metric names

Description
We need additional instrumentation to net/http that existing open PRs would provide, but they aren't merged, apparently because the opentelemetry folks don't really want to maintain the code.
Reviewer Notes
I tried to import the existing code as verbatim as possible and then modify it to make it easier to bring in any improvements that they do make.
I deployed this to loadtesting environment and it seemed to work well

Messages

:book:
:link: MB-10469

  Generated by :no_entry_sign: dangerJS against 12eb2af880f6b6843d4fcf331088ecca8db36211

When we have the time should we fork the repo or is that not desirable?

When we have the time should we fork the repo or is that not desirable?

I couldn't decide! The thing is that the contrib repo has lots of other things in it to introspect packages we don't use, so it didn't seem like the right call.
We're also in a period of (I think) rapid iteration. Perhaps once things settle down we could open source just this bit?

Mostly LGTM! Just one thing, I think the version of semconv also needs to be updated in pkg/telemetry/init.go.

Done


He maketh victorious - Edim7 instead of E at the end

I believe JB Eckl plays Edim7 instead of E at the end of the song. Furthermore, although it looks like he plays a Bmin11 in the video and one would expect at least a Bmin, I believe it is just a B5 (X 2 4 4 0 X).
Should I correct it?

Yes, can you open a pull request?

Ok
--
Chad Smith
On 27. December 2018 at 20:33:33, Dayyan Smith (notifications@github.com(mailto:notifications@github.com)) wrote:

Yes, can you open a pull request?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub(https://github.com/bahaisongproject/bahai-songs/issues/4#issuecomment-450216060), or mute the thread(https://github.com/notifications/unsubscribe-auth/Ab1Cjq16afU5x2gSZ3cGR8P19O_eLgHVks5u9SCNgaJpZM4ZjFFY).

Will open a pull request


illegal base64 data at input byte 3

I searched online for this but couldn't solve it for quite long. After I successfully see the front page, I try to register a new user. But after I click the button, it returns this error: illegal base64 data at input byte 3 (and the screen capture is attached):

Not sure what is happened? Thank you!

I'll look into it thanks

This is caused by a missing key in the secrets file, which was omitted from bootstrapping. You should be able to add a "session_name" key (with any text value "my_session" for example), and then it will work.
I've improved error reporting so that it doesn't return such an inscrutable error.


feat: add second gallery

Contributes to #2884
Show gallery for codesandbox and stackblitz
What did you change?

Additional story added
Moved some paths from config builder script to gallery
Changed config url for directory hosting example
Corrected thumbnail for prefix-example
Corrected prefix example usage of about modal
Listed stackblitz in readme.

How did you test and verify your work?
Ran up storybook and viewed the example galleries for both codesandbox and stackblitz

@allcontributors add @lee-chase for examples


add fs expansion support to the csi driver

We use the CSI driver to expand the volume filesystem after the mount during NodeStageVolume
This is required to correctly support kubernetes cloned volumes, since NodeExpandVolume is not called after
a succesful clone of a volume with a requested bigger size.
ref: https://github.com/kubernetes/kubernetes/issues/94929
NodeExpandVolume is a mixed bag at this point probably the only reason it still exists, is for supporting online expansions
of already published volumes, which we do not support. So I left out the implementation of it in favor of the NodeStageVolume expansion pass.
ref: https://kubernetes-csi.github.io/docs/kubernetes-changelog.html#kubernetes-119
Besides the expansion I also removed the nfs/nsenter code from the csi driver instead I use a small shell script that gets called by the regular mounter, this is similiar to googles containerized mounter. And can easily be replaced with a small go program instead of my quick shell script.
https://github.com/kubernetes/kubernetes/tree/release-1.22/cluster/gce/gci/mounter
longhorn/longhorn#2794
longhorn/longhorn#2868

Remember to update the default image for the share manager.


chore: rename metrics packages to prevent lerna linking

This solves the issue where the WIP metrics API and SDK cause problems with existing packages by giving them a version number that does not match the dependencies of the existing packages. This means the released 0.27.0 versions will be used when bootstrapping those packages.

@vmarchaud @legendecas i ended up having to change the name instead of the version to get lerna to be happy and the tests to pass. Also had to temporarily move the metrics API to "real" dependencies for the same reason. Apparently the lerna cross-linking in node 16 for peer dependencies works slightly differently.


Grafana Dashboard Contains Soon-to-Be-Deprecated Panels

Overview
We are currently defining panels using the Graph (old) type in "examples/grafana/dashboard.json," but this plugin is soon to be deprecated. It's recommended to upgrade these panels to the Time Series type. More information about the deprecation can be found at this link: https://grafana.com/docs/grafana/latest/developers/angular_deprecation/
Screenshot

@tadeha, I think so that this fix is responsability from Grafana Labs maintainers, would be interesting report here

@tadeha, I think so that this fix is responsability from Grafana Labs maintainers, would be interesting report here

Created: https://github.com/grafana/helm-charts/issues/3056

I started skaffolding out the work to rework the dashboards and alerts: https://github.com/prometheus-community/elasticsearch_exporter/pull/885


feat(frontend): create research outputs

@fampinheiro not up to usual quality standards (UI not showing request progress, and esp. no test coverage), but maybe you can get this over the line next week

rebased, looking at design QA comments

Design QA comments implemented.
Tested the whole flow on the environment again, appears to work :tada:


[OTHER] IGNORE - will be deleted, testing something

What would you like to share?
testing
Additional information
No response

this was an issue to test a potential bug


Qt: Add GUI to set max connection count

I'm raising this for discussion and marking it as draft. In my manual testing, it works. It's not a lot of code. I'm looking for feedback on a few things:

there's a little bit of coupling between this dialog and net.h now; should that move?
I haven't put the GUI value in the related model; should I do that?
changes take effect on OK button click, rather than QComboBox changes; does anyone have strong feelings otherwise?

We talked about exposing some of these new values in other RPC commands and cleaning up the types (why is the number of max allowed connections a signed int after all?). Would doing that first make this cleaner or simpler?

Awesome!

there's a little bit of coupling between this dialog and net.h now; should that move?

imho, no. We also include validation.h there.

I haven't put the GUI value in the related model; should I do that?

I'm not sure what you mean by this

changes take effect on OK button click, rather than QComboBox changes; does anyone have strong feelings otherwise?

To me, this feels like it is the right way.

We talked about exposing some of these new values in other RPC commands and cleaning up the types (why is the number of max allowed connections a signed int after all?). Would doing that first make this cleaner or simpler?

It would make that change less impactful, so if you have any ideas already about how to clean it up, then it would be better to do that first, yes, as it basically removes debt.

I haven't put the GUI value in the related model; should I do that?

I'm not sure what you mean by this

In UpdateNetworkSettings(), I set the new max connection value by reading directly from the QComboBox widget:
         g_connman->SetMaxConnections(ui->maxConnectionCount->value());

We talked about exposing some of these new values in other RPC commands and cleaning up the types (why is the number of max allowed connections a signed int after all?). Would doing that first make this cleaner or simpler?
It would make that change less impactful, so if you have any ideas already about how to clean it up, then it would be better to do that first, yes, as it basically removes debt.

Let me see what I can do. I'm not sure what the end result will look like, but this code is small enough that it'll be easy enough to rebase.

I set the new max connection value by reading directly from the QComboBox widget

Currently, the UI user would not know about any changes to the value specified except for opening debug.log.
I think that for UI, it would be better to set the ::setMinimum correctly, and then defensively check that in ::updateNetworkSettings. If possible, it would be great if we refactor CConnman a little to provide the validation / min / max mechanism in separate methods?


Task restore blend shape support

Reduz left comments that fire should update the importers to use the blend shape changes for all scene importers.

Changes to fix were merged https://github.com/godotengine/godot/pull/59489.


Terraform Init Failed (Provider Plugin with SKG module 0.0.5

Initializing provider plugins...
- Finding hashicorp/aws versions matching "~> 3.3.0, >= 3.22.0"...
- Finding hashicorp/template versions matching ">= 2.1.0"...
- Finding hashicorp/random versions matching ">= 2.1.0"...
- Finding volterraedge/volterra versions matching "0.0.5"...
- Finding hashicorp/null versions matching ">= 2.1.0, >= 3.0.0"...
- Finding hashicorp/kubernetes versions matching "~> 1.9, >= 1.11.1"...
- Finding hashicorp/local versions matching ">= 1.4.0, >= 2.0.0"...
- Installing hashicorp/random v3.0.1...
- Installed hashicorp/random v3.0.1 (signed by HashiCorp)
- Installing volterraedge/volterra v0.0.5...
- Installed volterraedge/volterra v0.0.5 (signed by a HashiCorp partner, key ID D9A99FF2F2E29E35)
- Installing hashicorp/null v3.0.0...
- Installed hashicorp/null v3.0.0 (signed by HashiCorp)
- Installing hashicorp/kubernetes v1.13.3...
- Installed hashicorp/kubernetes v1.13.3 (signed by HashiCorp)
- Installing hashicorp/local v2.0.0...
- Installed hashicorp/local v2.0.0 (signed by HashiCorp)
- Installing hashicorp/template v2.2.0...
- Installed hashicorp/template v2.2.0 (signed by HashiCorp)

Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/plugins/signing.html

Error: Failed to query available provider packages

Could not retrieve the list of available versions for provider hashicorp/aws:
no available releases match the given constraints ~> 3.3.0, >= 3.22.0

main.tf:

terraform {
  required_providers {
    volterra = {
      source = "volterraedge/volterra"
      version = "0.0.5"
    }
  }
}

variable "api_url" {
  default = "https://tenant.console.ves.volterra.io/api"
}

variable "api_p12_file" {
  default = "tenant.console.api-creds.p12"
}

provider "volterra" {
  api_p12_file = var.api_p12_file
  url          = var.api_url
}

variable "aws_access_key" {}

variable "aws_secret_key" {}

module "skg" {
  source             = "volterraedge/secure-k8s-gateway/volterra"
  version            = "0.0.1"
  skg_name           = "marco-skg"
  volterra_namespace = "marco-skg"
  app_domain         = "skg.treino.helloclouds.app"
  aws_secret_key     = "BLANK"
  aws_access_key     = "BLANK"
  aws_region         = "us-east-2"
  aws_az             = "us-east-2a"
}

output "kubeconfig_filename" {
  value = module.skg.kubeconfig_filename
}

output "app_url" {
  value = module.skg.app_url
}

Should be fixed with https://github.com/volterraedge/terraform-volterra-secure-k8s-gateway/pull/6
Will test and publish a new release

Should be fixed with https://github.com/volterraedge/terraform-volterra-secure-k8s-gateway/pull/6
Will test and publish a new release

@madhukar32 one more change:
Original:
# export TF_VAR_aws_secret_key=<your aws secret key>
# export TF_VAR_aws_secret_key=<your aws access key>

New:
# export TF_VAR_aws_access_key=<your aws secret key>
# export TF_VAR_aws_secret_key=<your aws access key>

@madhukar32 one more change:
Original:
# export TF_VAR_aws_secret_key=<your aws secret key>
# export TF_VAR_aws_secret_key=<your aws access key>

New:
# export TF_VAR_aws_access_key=<your aws secret key>
# export TF_VAR_aws_secret_key=<your aws access key>

0.0.2 still has a duplicate:
provider "volterra" {
  api_p12_file = var.api_p12_file
  url          = var.api_url
}

0.0.2 still has a duplicate:
provider "volterra" {
  api_p12_file = var.api_p12_file
  url          = var.api_url
}


missing animations

flapping animation for chickens, sitting and jumping animations for foxes

yep

Implemented as of 66f8bc87f4cfb7a00c698ce86ba283b0bdb31c88 and ade19486ef97035daf969dced310d766bc0f08cb


Updated Chrome sample to new working sample

After testing the original sample we had a number of issues getting it working.
The following updates should be a out of the box working sample.
Signed-off-by: Orakel78<EMAIL_ADDRESS>

@Orakel78 - Thanks for updating this sample. Merging this request now.


sourmash not found

Description of the bug
When I ran the test dataset, I got the error below.
Aug-09 21:12:34.834 [Task monitor] ERROR nextflow.processor.TaskProcessor - Error executing process > 'NFCORE_PLANTPATHSURVEIL:PLANTPATHSURVEIL:ASSIGN_REFERENCES:SOURMASH_SKETCH_GENOME (22_331_assembly)'

Caused by:
  Process `NFCORE_PLANTPATHSURVEIL:PLANTPATHSURVEIL:ASSIGN_REFERENCES:SOURMASH_SKETCH_GENOME (22_331_assembly)` terminated with an error exit status (127)

Command executed:

  sourmash sketch \
      dna --param-string 'scaled=1000,k=21,k=31,k=51' \
      --merge '22_331_assembly' \
      --output '22_331_assembly.sig' \
      reference-22-331.fna

  cat <<-END_VERSIONS > versions.yml
  "NFCORE_PLANTPATHSURVEIL:PLANTPATHSURVEIL:ASSIGN_REFERENCES:SOURMASH_SKETCH_GENOME":
      sourmash: $(echo $(sourmash --version 2>&1) | sed 's/^sourmash //' )
  END_VERSIONS

Command exit status:
  127

Command output:
  (empty)

Command error:
  .command.sh: line 2: sourmash: command not found

Work dir:
  /nfs7/BPP/Chang_Lab/paradarc/nf_brady_N120/scripts/nf-core-plantpathsurveil/work/a2/480383e27aa8caca0e987eaf408c31

If I add the path to the sourmash executable installed in my conda env works no problem. So this maybe an issue with my conda installation or with the way the pipeline calls the sourmash conda.
Command used and terminal output
nextflow run main.nf -profile test,mamba --outdir test -resume

Relevant files
No response
System information
No response

probably a conda/mamba issue. Is this still an issue?


batch delete - deleting items from page 2 onwards processes only one

Hi, about  "batch delete" in the demo,
If you have turned on paging, batch delete would work properly on the first page,
But If you try to delete several items from second page onwards, a trigger set you back to page 1 and delete is applied only to the first item selected.

Great Staff! Thanks for your reply!👍
On 16 August 2016 at 07:00, Artem Tabalin<EMAIL_ADDRESS>wrote:

Closed #400 https://github.com/tabalinas/jsgrid/issues/400 via d7eef74
https://github.com/tabalinas/jsgrid/commit/d7eef74353f912754036e1d19b985181bc119b4d
.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/tabalinas/jsgrid/issues/400#event-756368939, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AUBrPC3mWoJtawufSdnOHDF6sLN75cPsks5qgP2MgaJpZM4JjdMU
.

Thank you for the report!


Improve scala to java exports

See: https://github.com/bazelbuild/rules_scala/pull/56#issuecomment-220453040
one idea could be to improve this:

https://github.com/bazelbuild/rules_scala/blob/master/scala/scala.bzl#L490

so it is a skylark rule, not a macro, that consumes targets and looks at their runtime and compile-time jars, and just exports them (right now it is not saving much effort).

Then, that could be used to test this feature. I'll add an issue.

the fix we added for #18 is still pretty mechanical: you pass output jar names. What we really want is to just list targets and get all their exports and runtime deps for use from java.
In this way, we can test that the runtime paths are correct without conflating with scala_binary.

/cc @colinmarc @jcoveney

What about adding a java provider to scala_library? Will the java rules pick that up automatically?

Also, if that doesn't work, we could generate the java_import rules preemptively as foo_javaimport.

There is a ticket for some API to make this work, but I think the java rules don't have a contract like this. I wouldn't want to add preemptively out of anxiety that it would slow down the build by doubling the number of targets, half of which would not be used in scala-only repos (even with mixed java-scala it is not that common to depend across languages).

I don't see how to do the java_import. We can only call native rules from macros, not other skylark rules. But we can't see in a macro all the dependencies we need to add to the java_import.
I think we may just have to wait until https://github.com/bazelbuild/bazel/issues/970 is solved. I can't see any non-manual way to work around this, but maybe I'm missing something.

What if we benchmarked preemptively creating java_import (assuming that actually works)? It may be that perf works fine with double the targets.

Sure, that would be fine. I actually don't know how to do it though.
Can you see a way?
On Wednesday, May 25, 2016, Colin Marc<EMAIL_ADDRESS>wrote:

What if we benchmarked preemptively creating java_import (assuming that
actually works)? It may be that perf works fine with double the targets.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/57#issuecomment-221806161

--
P. Oscar Boykin, Ph.D. | http://twitter.com/posco | http://pobox.com/~boykin

I think we'd have to give the java_import the specified name, and then build the library jar as a separate _scalajar rule or something. I can tool around with it later.

So, with the recent merge of correct deploy jars we can just do Java import
of deploy jars, bit that is not a great solution since it hides duplicate
classes on the class path, although they should be identical.
How urgent is this? What if we just hope bazel makes it possible to do Java
interoperability as is being discussed?
On Thursday, May 26, 2016, Colin Marc<EMAIL_ADDRESS>wrote:

I think we'd have to give the java_import the specified name, and then
build the library jar as a separate _scalajar rule or something. I can
tool around with it later.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/57#issuecomment-221922361

--
P. Oscar Boykin, Ph.D. | http://twitter.com/posco | http://pobox.com/~boykin

@sdtwigg at the risk of extending our conversation to yet another issue this one seems like the most relevant one about enabling java_* targets to depend on scala_* targets. Any update on that?
I thought issue 970 has a bit too much noise so maybe we should continue here for followup which doesn't require the Bazel people.

Sorry for the delay here. I was ill over the weekend and have been playing catch-up since then.
There was a slight confusion in getting the necessary reviews from the bazel team but things should be in sync now. Here is what I have so far:
Regarding critical bazel contributions:
https://bazel-review.googlesource.com/#/c/9671/ - This one is critical. Otherwise, you will find it somewhat arbitrary what arguments in a java native rule accept skylark rules. This would make it so that all of the java_library|import|binary accept skylark rules for deps|exports|runtime_deps.
Regarding rules_scala changes:
See https://github.com/sdtwigg/rules_scala/commit/8be3df58e84b53f41d1533b590733c7e45ef4ac0 as  the minimum viable product for this working. As-is, it does work and is how the main API will ultimately probably look. Preliminary tests indicate it is working fine (especially after the other cleanup PR I did which took care of most of the other oddities that used to be in that commit).
I have not been aggressively pushing to submit due to these two pending bazel contributions:
https://bazel-review.googlesource.com/#/c/9730/ - Changes java_common.create_provider to take depsets instead of lists. API-breaking (for an unpublished, experimental API) that would break my rules_scala changes until they are adjusted. It is a simple adjustment (involving removing the to_list calls!) but still technically breaking.
https://bazel-review.googlesource.com/#/c/9670/ - This cleans things up the implementation and better restricts compile jars. Internally, it means we can just use JavaProvider primarily just like the java rules are using our java provider. Also, cleans up a glitch in current implementation where it is getting transitive compile jars from java rules rather than just the 'local' compile jars.

Update with good news: All the referenced changes to bazel have been merged.

Awesome!!!
Do you have any estimate on when you'll be able to have a PR?
On Tue, 23 May 2017 at 0:28 Stephen Twigg<EMAIL_ADDRESS>wrote:

Update with good news: All the referenced changes to bazel have been
merged.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/57#issuecomment-303225095,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF_ijwcmp_dlckaXO-cbsmPYSQZS2ks5r8f4FgaJpZM4IirKL
.

Thank you so much for pushing those through!
On Mon, May 22, 2017 at 17:44 Ittai Zeidman<EMAIL_ADDRESS>wrote:

Awesome!!!
Do you have any estimate on when you'll be able to have a PR?
On Tue, 23 May 2017 at 0:28 Stephen Twigg<EMAIL_ADDRESS>wrote:

Update with good news: All the referenced changes to bazel have been
merged.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/bazelbuild/rules_scala/issues/57#issuecomment-303225095
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ABUIF_ijwcmp_dlckaXO-cbsmPYSQZS2ks5r8f4FgaJpZM4IirKL
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/57#issuecomment-303282512,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEJdms3wjZc6wob6tp1KkSJTBfjjEawks5r8lYBgaJpZM4IirKL
.

@sdtwigg
Any updates? I'm mainly asking since there are some changes I'm thinking about which will probably be easier when this lands

Hey,
@sdtwigg I'm sorry to be a nuisance but would you rather someone take https://github.com/sdtwigg/rules_scala/commit/8be3df58e84b53f41d1533b590733c7e45ef4ac0 and continue from there?
I don't want to stress you too much but on the other hand I think it would help with a few different issues (junit logs, javac default encoding not being UTF8 and maybe javac default debug symbols)

@johnynek this is solved, right?

I think so. yes!


Give information about reason to connection error!

It would be nice if if Mdsflutter could give som information for the connection error. Sometimes the sensor appears on scan but can't connect.

Good idea. Will be implemented shortly with another fix.

Fix is in 2.0.1-beta2. Will release 2.0.1 when tested more thoroughly.

Implemented in 2.1.0


Extracting keypoints for the pose estimation

Hi @rmbashirov ,
Thank you for your work here, its great! I would like to ask where in your code should i look into to find out how to extract the keypoints and other information required from the body pose estimation. (e.g: for 2D pose estimation models, it will be 2D keypoints (x,y). For 3D pose estimation models (SMPLX), how to extract the (x,y,z) information of the keypoints detected?)

Similar question I have. Did you find the solution?


basic help

I am very new to npm, webpack, tsd, etc.  I tried npm install npm -g, npm install tsd -g, npm install webpack-dev-server -g, and even threw in a npm init, and a npm install webpack. I get the error:  cannot find module 'webpack' when I try runing webpack-dev-server.  I've looked at documentation for all the above.  Please help.

The documentation isn't very clear.
webpack-dev-server is a development tool of webpack that is used to build the app and set up the development server. To run the webpack-dev-server command, please run the following code to install webpack and webpack-dev-server:
npm install webpack -g
npm install webpack-dev-server -g

Thanks for pointing out :)

I assume this issue was resolved.


First pass at exposing VR preview to partner users

This generates this view for user that has access to partner that generated the VR:

Still need to figure out how to add a spec that verifies it. Also for now if there are any other banners (might be the one about confirming user email) - those would just appear on top of each other.
But want to get feedback on the general approach here first.

And I'm adding a new dependency here. Forgot if I need to do an RFC here as well. Maybe somebody can remind me what our convention on that is?

And I'm adding a new dependency here. Forgot if I need to do an RFC here as well. Maybe somebody can remind me what our convention on that is?

That is a team process on the Mobile Experience team for new dependencies to Eigen, but we haven't made a call on this for Volt on the Galleries team.

Ok @iskounen - I think this might be ready to be tried on staging unless you have some other concerns here. Please let me know!


Account data: new field membership number

Description: The current status of the Accounts and how to adminstrate them on a clear one Account per user base is not optimal. It happens sometimes, that instances have several Accounts for the same person. The reason for this is manifold. The current status to use username and E-Mails doesn't solve the problems, because the username can be changed by the user and even the E-Mail can be different inside an organization depending on the hierarchy the user is added to the OpenSlides instance.
What should happen:
A new Account attribute is needed, which can't be changed by the user and has a clear connection to ONE person. An unambiguous identifier is a membership number. The number is always the same inside an organization, it doesn't change and all person with administration permissions have access to it.
Therefor we should implement a new Account attribute 'membership number'.
What is needed:

[ ] It should be part of the personal information of an Account
[ ] the attribute can only be changed by Admins NOT users
[ ] csv files for import/export should include it
[ ] (optional) Login: It should be possible to use this data for login just like the username.
[ ] Meeting > participant: No need to make it searchable. Same like usernames, which can't be searched in participant menu.
[ ] Account list: number should be searchable, like usernames. no filter or sort option needed.

[ ]  csv files for import/export should include it

Should the import match users based on the new attribute? If yes, this needs to be explicitly stated and we need to work out a priority order of the different possible matching attributes. This would requires much more work than simply adding the attribute.

[ ]  (optional) Login: It should be possible to use this data for login just like the username.

Not easily possible nor advisable. We would have to make the attribute unique organization-wide and in combination with the username, since otherwise if one user has a number which is the same as the username of another user, it is not possible to check which user currently wants to log in.

Also, this does not belong in the client. Either we move this to the main repo and open issues in each service or we move this to the backend, as the conceptual work and model changes need to be implemented there first.


write non-eager version so that random seed actually works

tried, but current optimization depends too much on tf.GradientTape
probably easier to just wait until this issue is fixed in 2.0


[Snyk] Upgrade leaflet from 1.6.0 to 1.7.1

Snyk has created this PR to upgrade leaflet from 1.6.0 to 1.7.1.
As this is a private repository, Snyk-bot does not have access. Therefore, this PR has been created automatically, but appears to have been created by a real user.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 2 versions ahead of your current version.
The recommended version was released 6 months ago, on 2020-09-03.

Release notes

Package name: leaflet

1.7.1 - 2020-09-031.7.1 (2020-09-04)
Bug fixes

Fix build toolchain to reflect uglifyjs upgrade from v2 to v3 (by @ ivansanchez)

1.7.0 (2020-09-03)
API changes

VideoOverlay now can take a muted option (#7071 by @ ronikar)
The featureGroup factory method now takes options, as the FeatureGroup constructor (#7160 by @ frogcat)

Improvements

Use passive event listeners for touchstart/touchend events (#7008 by @ yneet)
Better detection of PointerEvents-capable browsers in L.Browser, and related changes to Tap, Drag, and TouchZoom handlers (#7010, (#7033, (#7036, (#7068, (#7195 by @ johnd0e)
Add more browser profiles for the automated tests (#7115 by @ johnd0e)

Bug fixes

Fix canvas renderer not clearing the canvas on some zoom transformations, was affecting opacity of items (#6915 by @ chipta)
Fix detection of passive events in L.Browser (#6930 by @ Ivan-Perez)
Prefix MS-specific CSS style to prevent warnings (by @ ivansanchez, kudos to @ zachricha for #6960)
Clean up moveend listener from map.setMaxBounds (#6958 by @ simon04)
Fix wrong scope of bind call in ESM environments (#6970 by @ shintonik)
Check that closePopup exists before calling it automatically (#6962 by @ pke)
Fix exception when calling layerGroup.hasLayer() with wrong layerId (#6998 by @ johnd0e)
Remove click filter targeting Android 4.x browsers (#7013 by @ johnd0e)
Fix touch zoom handler context (#7036 by @ johnd0e)
Tests for Bounds.overlaps() and Bounds.intersects() (#7075 by @ mondeja)
Fix event propagation in a popup's container (#7091 by @ johnd0e)
Fix tile flickering when maxNativeZoom === maxZoom (#7094 by @ johnd0e)
Fix GridLayer's zoom-level loading algorithm (#7123 by @ johnd0e)
Fix tooltipAnchor behavior for different tooltip directions (#7155 by @ Istador)

Docs & Web Site

Updated examples to use non-legacy Mapbox tiles, and related changes (#6905 by @ riastrad) (#6922 by @ danswick) (#6995 by @ riastrad)
Fix documentation for Polyline.addLatLng() (#6924 by @ life777)
CRS tutorial: change link for UQM tool to an archived version (by @ ivansanchez)
Fixed minor spelling errors in documentation (#6850 by @ flopp) (#6944 by @ jieter)
Fixed typo in panes documentation (by #6939 by @ R4M80MrX)
Fixed broken URL in quick-start example (#6982 by @ ekbarber)
Fix documentation for map.setMaxBounds() (#7001 by @ johnd0e)
Fix tilt code in handler tutorial (#7014 by @ vncntcltt)
Fix instructions for using jekyll when building docs (#7014 by @ vncntcltt)
Update WMS servers in WMS tutorial (#7014 by @ vncntcltt)
Website constrast changes and minor cleanup (by @ mourner)
Fixed typo in WMS example (#7098 by @ andreasnuesslein)
Fix documentation for divOverlay.getElement() (#7111 by @ mondeja)
Fix documentation for Marker.shadowPane (#7135 by @ mi-v)
Update URL about NPM in developer docs (#7161 by @ iamtekson)
Fix documentation for Layer.removeFrom() regarding LayerGroups (by @ ivansanchez)
Fix documentation for LatLngBounds.overlaps() #7194 by @ DerZade)

1.7.0 - 2020-09-03v1.7.0

1.6.0 - 2019-11-17API changes

GeoJSON.resetStyle - allow invocation without an argument (#6663 by joukewitteveen)
Add new markersInheritOptions option to L.GeoJSON (#6866 by ghybs)

Improvements

Use passive event listeners (#6694 by danielkorte)
Add oldLatLng coordinates to L.CircleMarker move event (#6719 by errnesto)
Add tests (#6839, #6841 by ghybs)
Add test case to ensure scientific notation is formatted correctly (#6877 by desean1625)

Bug fixes

Fix performance issue with L.Util.formatNum (#6668 by cherniavskii)
Respect className option in SVGOverlay and VideoOverlay (#6679 by IvanSanchez)
Cancel the canvas mousehover throttle on mouseout (#6749 by IvanSanchez)
Check for style being passed in L.Path.setStyle (#6728 by TheRealTorreySmith)
Fix dblclick event when both Pointer Events and Touch Events are available (#6855 by filcab)
Properly unbind animation proxy events when removing map (#6867 by ghybs)
Fix race condition in Marker when icon is not present (#6794 by BenTalagan)

Docs & Web Site

Update SvgOverlay code example (#6658 by cherniavskii)
Fix mobile locate accuracy snippet (#6693 by ghybs)
Fix broken accordions (#6770 by mbachner)
Fix misleading L.Marker docs sections (#6871 by chloe-mc)

    from leaflet GitHub release notes

Commit messages

Package name: leaflet

bd88f73 v1.7.1
1ca2001 Tweak test for finger drag
bce1fb9 Changelog and blog post for 1.7.0
26410f6 updated Leaflet.BeautifyMarkers plugin github url (#7247)
dd83210 plugins: Add Leaflet.BigImage (#7214)
71f7378 plugins list: rm ⭐ from geoman description
9644fcf Get rid of some legacy IE-related pointer quirks. (#7195)
14b1985 docstrings: fix parameters for LatLngBounds.overlaps (#7194)
e8c28b9 docstrings: Layer's removeFrom works on LayerGroups too
25f7bbb docs: update URL about NPM in plugin developer guide (#7161)
1d09819 Update FeatureGroup's factory method (#7160)
5b30f7d fix tooltipAnchor behavior for different directions (#7155)
838587d L.Marker shadowPane doc fix (#7135)
9b0d7c2 Update dev dependencies, fix most of vulnerabilities (#7133)
ec35ab5 GridLayer: fix _updateLevels and _removeTilesAtZoom (#7123)
e7a5c6f Add more browser profiles and fix some tests (#7115)
19da013 Fix DivOverlay.getElement function documentation (#7111)
1ae785b Docs: Fix tiny typo - WMTS vs WTMS (#7098)
984fedd VideoOverlay feature: Enable to load muted video (#7071)
0fd2f43 Fix tiles flickering when maxNativeZoom === maxZoom (and same with min-) (#7094)
41706c0 Popup: fix event propagation to popup._container (#7091)
09da971 Update mocha to ^7 (#7082)
9be733e DomEvent: use passive for touchmove (instead of touchend) (#7060)
092070d Canvas events handling: do not block events on dragging (#7068)

Compare

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Discussion for dealing with spam registrations

A significant portion of new registrations share a pattern:

They sign up, confirm email, skip Onboarding
Go to profile, fill their bio with ad content that link to their sites
Never come back to the site

From the session details I can tell that these are mostly real people and not bots. They don't really affect the site from a usage standpoint, but they skew product analytics and the db gets bloated.
(Afaik, we disavow backlinks from profiles, so the spammers don't really get the benefit they're looking for - although they don't know that)
Potential next steps:

Go through new registrations every day (about 100) and manually remove spam accounts

Maybe utilize an LLM to do the heavy-lifting?

Disable markdown in user profiles in an attempt to disincentivize
Do nothing

Other ideas:

Upon registration, allow forecasting and commenting, but you can only edit your bio after a week.
Feed every bio to Claude, if it looks like an add send email to user that they have 24 hours to edit it or will be deactivated. Also give them email to appeal.
Feed first N comments of every user to Claude. If it looks like an add: make it private, send email to user telling them how to appeal.

Thanks for the clarification @draaglom I created an issue for adding the ugc attribute to all links in comments and user profiles.

Summary of chat we just had with @CodexVeritas:

Focus on Bios.
Everyday, run all bios that are less than a week old through LLM.
Ones that are marked spam get an email warning them. Also includes way to appeal.
If a bio is marked spam two days in a row: deactivate account, send email (with instructions to appeal again).

Agreed about comments, but let's focus on bios as an mvp, since comments should be caught by users reporting them.

Also as a heads up, I think I'm going to approach this in a slightly different way. Rather than checking bios daily for a week, Spam is rejected at bio edit.  This also reduces the number of checks we have to do (since most bios edits will happen once from non-spammers, and the early message will probably stop human spammers). If multiple spam edits are detected, then the account is deactivated.
One concern though would be whether this would give a faster feedback loop to overcoming the spam filter (since there will likely be edge cases they could exploit).
Let me know if there are any thoughts to this approach.

I'm putting the true false-positive rate around 2-7%

I think this is too high. I'd rather let some spam through (it doesn't have much overall effect) than convict even one innocent. I think this should be improved and instead sacrifice false negatives.

Spam detection is activated every profile update, and immediately deactivated if detected.

I'd prefer it to only activate on first profile update unless we later have good evidence to suggest it would be necessary. I can help implement that check since it might be subtle.

integration tests

Linking your branch for my own reference: https://github.com/Metaculus/metaculus/tree/feat/spam-detection
Nice work! But yeah we'll need to look at that. I'm not sure why
Would you turn your branch into a PR and we can have a technical discussion there with code-comments etc?

In the future, if I understand right, I normally shouldn't ask for approval at this step, but would just make a pull request to main (merge & squash style), and then mark this ticket as QA and @ someone for review?

So we've just shifted gears officially, and anything that isn't urgent needs a reviewer's approval now. I'd also suggest this being your first PR at Metaculus that it gets a good lookover.

I'm going to test that the email is sent after deactivation once the merge is in production, since I couldn't do that locally.

I'd have to check, but I think either dev or play actually can send emails, but they automatically get captured and go to<EMAIL_ADDRESS>or something.

@lsabor Awesome! Let's move the discussion to the Pull Request. I'll start with a pull request for my second ticket.

@aseckin Check out the flow description in the pull request (https://github.com/Metaculus/metaculus/pull/1484)

@SylvainChevalier Spam detection was just merged. You should be able to make a new account, test a valid bio, have it update (as per normal), test an invalid bio, have your account deactivated, get a message, get logged out, and get an email.

This has already reduced spam by ~4×. I was hoping for more, but this is already pretty good.
Some follow ups for improving record-keeping:

Let's save the spam bios. Will help with understanding what is and is not detected.
Let's record the spam detections. This can be a simple spam_autodetected field on the user.