Migrate to scikit-build-core or meson-python

Now that we have a declarative format for build metadata provided by pyproject.toml and build isolation enabling a more stable installation procedure via PEP 517/518, it eases the migration to either the scikit-build-core or the meson-python build-backend(s). Both of them include support for editable installations and are slowly becoming more mature for downstream users, considering that NumPy^1 and SciPy^2 have successfully transitioned this year.
The scikit-build-core build backend would still use CMake as a build system as we do currently, but meson-python requires ninja as a build system, which would render the IDAKLU target compilation procedure radically different from the current one.
Some advantages of these new build-backends:

Better support for compilers plus ease of use^3
Reliable build caching for faster installation
Both of them are faster at compilation and more modern (multithreaded builds, cross-compilation, do not use distutils or setuptools at all)
Packagers for libraries in the Scientific Python ecosystem are slowly migrating and we should too
Might enable faster IDAKLU compilation with other compilers like MinGW? i.e., on Windows when building from source (which we do only when building the wheel)

Personally I would prefer to work with CMake over Ninja, but that could just be my bias from spending most of my career as a C++ dev

Hello! I was going through the GSOC 2024 Idealist and encountered this project. I am interested in learning and working on the Python backend, and this project will significantly help develop my skills. In the same route, I can help contribute to PyBaMM!
As a starter, I would like to discuss whether we should decide on meson-python or scikit-build-core.
I would prefer meson-python over scikit-build-core, mainly because of its popularity after SciPy (version 1.9.0) and NumPy (version 1.26) decided to migrate to it. The documentation, posts, blogs and projects that sparked because of this would be helpful.
Also, meson-python is the most popular method after setuptools to build C extensions.
I would also like to discuss some technical aspects of the project. Thank you!

Thanks for sharing, @cringeyburger. I would agree that meson-python is being used highly, but NumPy and SciPy use a vendored version of it because they want features that do not yet exist in the main source code. The reason, I believe, is that the Meson developers tend to prevent pushing anything hacky into the codebase and wish to do things in the conventional way and how robust solutions go. Both projects are very large and use almost every feature available in Meson, which we may not require for our use case – that should be great.
The Ninja build system should be able to handle the IDAKLU solver's compilation, but I am unsure whether it can do so for the prerequisites (SuiteSparse and SUNDIALS) – they might require a pure CMake build or perhaps calling CMake from inside meson.build. I am aware that pybind11 works with meson-python and can be used as normal, so it should just be a matter of pointing the build procedure to the location of the compiled files for the prerequisites. I would perhaps explore methods for caching so that editable installations can be sped up – Meson's in-place builds on the import pybamm statement can then rely on just compiling specific sections of the code – my experiments with https://github.com/pybop-team/PyBOP/pull/176 revealed that around 30 seconds are consumed by the IDAKLU compilation, and ~1 min 30 seconds for SuiteSparse and SUNDIALS on Unix-based systems.
However, Windows builds are significantly long and take ~20 minutes overall, without caching which would be a problem on editable installations. It looks like https://github.com/microsoft/vcpkg/pull/36885 will get merged soon which could provide some benefits (I'm unsure whether it is the SUNDIALS compilation or the SuiteSparse's component's compilation that takes longer on Windows). This might require bumping SUNDIALS to v6.7.0, we use v6.5.0 – it doesn't look like there are many changes to the IDAS component that we use (here are the release notes) and subsequently perhaps SuiteSparse from v6.0.3 to a later version (which would require changes to the C++ solver code).
We should be able to forego setup.py entirely with Meson – it has been done for NumPy: https://github.com/numpy/numpy/pull/24519 and should be out with NumPy v2 (any time now). With scikit-build-core, we might not be able to do so completely, but it isn't an issue, we can remove the dependence on wheel.bdist_wheel (it has been recommended against using it for quite some time now) and rewrite the setup.py code to be cleaner. Like it has been mentioned above, using this choice of backend will be much easier to integrate – everything will be governed by the CMake flags and CMakeLists.txt, which we already have.

Bumping the priority to medium since this will now be worked on this year

I did a quick test and I notice that on macOS, vcpkg install sundials takes 14 seconds, while vcpkg install suitesparse took 5.5 minutes, so perhaps using sundials[klu] when it is ready upstream will also resolve our Windows woes? Building on Windows is slow in general and our Windows builds painfully take 20 or so minutes and this is after enabling multithreaded builds (without which it takes even longer). But I see that SuiteSparse uses MinGW to compile in Windows CI where the time is around 2 minutes; we compile from source using GCC on Unix-based platforms where this hardly takes 30 seconds – I assume adding Ccache support will be highly beneficial for Windows

On windows x64 architecture laptop, vcpkg install sundials took 19 seconds and vcpks install suitesparse took a solid 16 minutes

I forgot that I had ninja VER 1.11.0 installed, so it defaulted to it
For Fortran, I had nothing installed before hand so it used MinGW Fortran
Though the time it took to handle suitesparse:x64-windows is 1.8 minutes.

As you have said, if that PR with vcpkg is merged, then having suitesparse[klu] can help speed up the process.
I am interested in learning more about Ccache, but from what I know, caching will definitely help improve the successive build processes.
For large packages like ours, the incremental build feature of CMake utilised by scikit-build-core would work well with Ccache.
Assuming that majority of our team is familiar with CMake, I too think that scikit-build-core is the better option.

2.8 minutes should be reasonable, thanks – this confirms that the SuiteSparse installation is the slowest installation out of all. 2.8 minutes is of course significantly slower than installing CasADi from its Python wheel, which is a matter of seconds – we were using the wheel earlier but had to resort to using the registry afterwards due to upstream changes. We have an issue open (#3603) for restoring this behaviour, which no one has been able to get to yet.
It looks like the SuiteSparse issue will be dormant for a long time – I noticed that I had seen it before because I was already subscribed to it :)
The CasADi installation from vcpkg looks normal to me especially if it succeeded, since I have noted these logs in our Windows wheels before – but it would be good to look how to clear out the warnings (they do not look to be relevant for the CasADi installation and are probably more so for the registry and its portfile itself).

I tried fixing the warnings by changing the portfile. I followed the instructions given through warnings when I built it.

Added vcpkg-cmake-config as a dependency and added file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/include"). This helped in reducing one warning.
I tried to fix warnings 2 and 3 using vcpkg_cmake_config_fixup(), but it's erroring out because it's searching for some directory that doesn't exist. I tried with and without this command, and the directory CONFIG_PATH share/casdi/cmake doesn't exist.
Regarding number 4, a quick search through the net tells me we may have to fix the absolute paths in the header files themselves.

Oh, by "good to look how to clear the warnings" I didn't mean doing so just now – I do not think it is the biggest of deals currently and can definitely be picked up at a later time (maybe CasADi can be added as a vcpkg package upstream too where someone interested can take care of this). Nevertheless, thanks for attempting this!
The gist of the discussion that entailed here should be that despite snd regardless of the build backend we end up choosing, reducing the Windows installation time would be great. We don't compile the IDAKLU solver on PR workflows because of that – that is an area where reducing CI time is important. But then we don't compile it when running the Windows scheduled tests either (#3664) where we don't need to bother how long the test runs. Being able to speed things up would benefit us in other ways too, say, identifying issues such as #3783 early on.

I'm interested in this project too. I'm in the process of making a proposal


Enhance CI test to check more configs of each bundle

So far, we rely on verify_metadata, verify_net_in_out from monai.bundle API to do preliminary checks for each bundle within our CI pipeline.
It has the limitation that config files except metadata.json and inference.json (or yml, yaml) are not tested.
Therefore, it would be nice to at least run each config file with some fake input data to reduce issues like in: https://github.com/Project-MONAI/model-zoo/pull/335
I will think about how to build the config file test pipeline and feel free to bring some suggestions.
cc @Nic-Ma @wyli @binliunls @KumoLiu @tangy5

I think we also need deterministic check on supported bundles.

discussed within MONAI core meeting.
The next step is to:

finish the test content of spleen ct segmentation bundle in #400 and merge it.
modify contributing guide (add unit tests introductions) in a separate PR.
enable mgpu tests.


Set up a basic demo site

To start developing against it (hot loading) hit npm start. You can generate gh-pages using npm run gh-pages. It can be deployed to the gh-pages branch by hitting npm run deploy-gh-pages.
The demo site has been split in two parts. The upper half is meant for a basic demo. I just copied the one that exists already. In addition you could render each field here in a separate section. The lower half just renders README.md (highlighting applied).
Related to #23.

Looking pretty sweet. One tiny thing I've noticed is that my browser (Firefox 36 on Ubuntu) does not place the header at the top of the page by default, so it obscures the top of the first section. An explicit top: 0; in the CSS seems to fix that. The same thing happens with the Reactabular page, by the way.
Is it possible to implement deployment via a shell script so that it's more obvious which git commands are actually issued? A JavaScript program executing shell commands from somewhere within its bowels is not my preferred way of doing things.

@odf, I fixed the header issue. Thanks for pointing it out. Would something like this work for gh-pages? As you can see it's possible to hook up the script with Travis making the process automated. Alternatively we can just pick the script, modify as needed and go with that.

Yeah, that's more like it. Call me old-fashioned, but I like to know what I'm actually doing. :-)
Hooking the project up with Travis just to automate this seems a bit overkill at this point, but I'm not fundamentally opposed to it.

@odf Ok. I'll start by doing a simple deploy script. Seems straightforward enough.
The cool thing about Travis is that it would allow you to run tests over components. I've been using Jest myself. But that's something for you to think about.

@odf I set up a little script. It creates a repo to /gh-pages directory and then force pushes it to the gh-pages branch. Here's a sample build.

Looking great! Thanks for the effort!

@odf What are your next plans? If you have particular tasks in mind, could you open up issues to help with discussion? I would love to see an improved release sometime in the near future.

Honestly, I'm not really maintaining this little library in a very planned fashion, and between all my big bad long-term projects, on and off the clock, I don't see myself being able to do that any time soon, either. As far as I am concerned, we might just as well push out a new release right about now with all the changes since v0.1.0.
In the longer term, let's just say I would not hold it against you if you decided to go ahead with your own fork. If this were my own private project, I'd have given you commit rights by now and maybe even considered offering a handover, but as things are, I can't really do either of these things.

Honestly, I'm not really maintaining this little library in a very planned fashion, and between all my big bad long-term projects, on and off the clock, I don't see myself being able to do that any time soon, either. As far as I am concerned, we might just as well push out a new release right about now with all the changes since v0.1.0.

Ok. That would be fine. Please give the demo a quick go and let me know if you find any regressions. I'll take care of those.

In the longer term, let's just say I would not hold it against you if you decided to go ahead with your own fork. If this were my own private project, I'd have given you commit rights by now and maybe even considered offering a handover, but as things are, I can't really do either of these things.

Yeah, licensing allows that. Just need to retain attribution. This is a good option. :)


chore(master): release 1.13.0

:robot: I have created a release beep boop
1.13.0 (2024-06-21)
Features

add NA world validation (#360) (55c46b3)
signups: include member tag when declining signups (#358) (92ef646)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/ssilve1989/ulti-project/releases/tag/v1.13.0 :sunflower:


Add a Gitter chat badge to README.md

nchammas/flintrock now has a Chat Room on Gitter
@nchammas has just created a chat room. You can visit it here: https://gitter.im/nchammas/flintrock.
This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.
Happy chatting.
PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

Heh, when I saw the button that said "Submit a pull request to add this badge" I said "No thank you" to myself and moved on. Turns out I missed a little checkbox that defaults to yes asking the same thing.


problem with api

how can i use it via api in order to get image with marks and get coordinate of marks?
i met a problem when i try to use gradio api

See https://github.com/microsoft/SoM/pull/19 for deploying to EC2. Once deployed, Gradio interface contains a "Use via API" link at the bottom of the page that provides example client code.


Update due to rename of github account

This should fix the syslog hook which is currently broken

I have the same problem and was about to submit a PR for the same fix.  The syslog hook appears to be broken for me because of this.


suggest: migrate to vite

We are using CRA for this project. We have to use Vite for better performance.
Why Vite?
Create React App (CRA) has long been the go-to tool for most developers to scaffold React projects and set up a dev server. It offers a modern build setup with no configuration.
But, we see increased development and build time when the project size increases. This slow feedback loop affects developers’ productivity and happiness.
To address these issues, there is a new front-end tooling in the ecosystem: Vite!
I want to work on this issue

Nice Suggestion !


adding sipRegister() and sipUnregister() for advanced registration me…

register and unregister methods

I guess there should be some handling of calling register / unregister / other methods when the registration is in the wrong state. Also probably need a boolean autoregister in props (true by default, set to false for those who want to call sipRegister / sipUnregister afterwards.


Public access denied error is not handled when trying to log in

@medjedovicm please provide steps to reproduce.

for this we need a user who is not in any SAS groups.  It's a SAS 9 problem


fix: Bump plasma-contract SHA

Coverage decreased (-80.8%) to 8.42% when pulling e9773c7e118dc89a8b2cd3eecfba40639b634354 on bump_contract_sha into 70e9a6803b53009db296f25bd5ed590eb26ddd9c on master.

Hm, if these tests are correct we shouldn't merge and redeploy dev 🤔

Hm, if these tests are correct we shouldn't merge and redeploy dev 🤔

Indeed! :)

Abandoning.


Add wlr_output_damage

The damage logic lives in rootston. This is a proposal to isolate it into a wlr submodule.
struct wlr_output_damage {
    struct wlr_output *output;
    pixman_region32_t damage;

    struct {
        struct wl_signal render;
    } events;
};

struct wlr_output_damage *wlr_output_damage_create(struct wlr_output *output);
void wlr_output_damage_destroy(struct wlr_output_damage *output_damage);
void wlr_output_damage_add_at(struct wlr_output_damage *output_damage, int x, int y, pixman_region32_t damage);
void wlr_output_damage_add_whole(struct wlr_output_damage *output_damage);
void wlr_output_damage_get_from_box(struct wlr_output *output, struct wlr_box *box, pixman_region32_t damage_out);

This would take care of output damage history, calling wlr_output_make_current and wlr_output_swap_buffers when necessary. When the desktop should render the render signal will be emitted.
This maybe abstracts too much. We could replace that render event with just a frame event and let the compositor call wlr_output_make_current and wlr_output_swap_buffers. That frame event won't be emitted when there's no damage.

This maybe abstracts too much. We could replace that render event with just a frame event and let the compositor call wlr_output_make_current and wlr_output_swap_buffers. That frame event won't be emitted when there's no damage.

yes

Proposal v2:
struct wlr_output_damage {
    struct wlr_output *output;
    pixman_region32_t damage;

    struct {
        struct wl_signal frame;
    } events;
};

struct wlr_output_damage *wlr_output_damage_create(struct wlr_output *output);
void wlr_output_damage_destroy(struct wlr_output_damage *output_damage);
void wlr_output_damage_add_at(struct wlr_output_damage *output_damage, int x, int y, pixman_region32_t damage);
void wlr_output_damage_add_whole(struct wlr_output_damage *output_damage);
void wlr_output_damage_get_from_box(struct wlr_output *output, struct wlr_box *box, pixman_region32_t damage_out);
bool wlr_output_damage_make_current(struct wlr_output *output);
bool wlr_output_damage_swap_buffers(struct wlr_output *output, struct timespec *when);

This exposes wlr_output_damage_make_current and wlr_output_damage_swap_buffers without th buffer age and damage since wlr_output_damage will take care of it.


BB-28 Use the data in the accounts component

add a utilities.js with a formula to transform the data in the accounts to USD, also the account component is now using the firebase database to populate the information

Why map over accountData? It's an object that has the data of the 3 types of accounts, right? Instead of:
const accountList = accountData.map((data) => {
    let accountsArr = []
    accountsArr.push(data.Main_Account,data.Savings,data.Expenses)

    return (accountsArr.map(account=>(

Why not

    const accountsArr = [accountData.Main_Account,data.Savings,data.Expenses]

    return (accountsArr.map(account=>(

something that might work is:

const accountsArr= [accountData[0].Main_Account, accountData[0].Savings,accountData[0].Expenses]
const accountList = accountsArr.map((account) => {
 return (
   <AccountCard
     key={account.id}
     title={account.title}
     balance={setUsdCurrency(account.balance)}
   />
   )
 });

Is there an account.title in the data?

There is an account.title in the firebase database


YARN-10393. Make the heartbeat request from NM to RM consistent across heartbeat ID.

NOTICE
Please create an issue in ASF JIRA before opening a pull request,
and you need to set the title of the pull request which starts with
the corresponding JIRA issue number. (e.g. HADOOP-XXXXX. Fix a typo in YYY.)
For more details, please see https://cwiki.apache.org/confluence/display/HADOOP/How+To+Contribute

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
28m 13s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
29m  0s
trunk passed

+1 :green_heart:
compile
1m 13s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
compile
1m  8s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
checkstyle
0m 32s
trunk passed

+1 :green_heart:
mvnsite
0m 44s
trunk passed

+1 :green_heart:
shadedclient
15m 15s
branch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 36s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
0m 32s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+0 :ok:
spotbugs
1m 21s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
1m 18s
trunk passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 36s
the patch passed

+1 :green_heart:
compile
1m  7s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javac
1m  7s
the patch passed

+1 :green_heart:
compile
1m  1s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
javac
1m  1s
the patch passed

-0 :warning:
checkstyle
0m 23s
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager: The patch generated 1 new + 23 unchanged - 0 fixed = 24 total (was 23)

+1 :green_heart:
mvnsite
0m 35s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedclient
14m  5s
patch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 28s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
0m 28s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
findbugs
1m 24s
the patch passed

_ Other Tests _

-1 :x:
unit
22m  2s
hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 33s
The patch does not generate ASF License warnings.

122m 58s

Reason
Tests

Failed junit tests
hadoop.yarn.server.nodemanager.TestNodeStatusUpdater

Subsystem
Report/Notes

Docker
ClientAPI=1.40 ServerAPI=1.40 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2204/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2204

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux ac8bf20749e1 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 5e0f8797790

Default Java
Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

checkstyle
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2204/1/artifact/out/diff-checkstyle-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-nodemanager.txt

unit
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2204/1/artifact/out/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-nodemanager.txt

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2204/1/testReport/

Max. process+thread count
402 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2204/1/console

versions
git=2.17.1 maven=3.6.0 findbugs=4.0.6

Powered by
Apache Yetus 0.13.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

Will take a look at the UT and fix it.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 33s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s
The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
29m 42s
trunk passed

+1 :green_heart:
compile
1m 17s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
compile
1m  9s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
checkstyle
0m 34s
trunk passed

+1 :green_heart:
mvnsite
0m 46s
trunk passed

+1 :green_heart:
shadedclient
15m 12s
branch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 37s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
0m 32s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+0 :ok:
spotbugs
1m 26s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
1m 24s
trunk passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 40s
the patch passed

+1 :green_heart:
compile
1m  6s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javac
1m  6s
the patch passed

+1 :green_heart:
compile
1m  3s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
javac
1m  3s
the patch passed

-0 :warning:
checkstyle
0m 27s
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager: The patch generated 1 new + 121 unchanged - 0 fixed = 122 total (was 121)

+1 :green_heart:
mvnsite
0m 37s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedclient
14m 20s
patch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 31s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
0m 29s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
findbugs
1m 24s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
22m 15s
hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 34s
The patch does not generate ASF License warnings.

97m  9s

Subsystem
Report/Notes

Docker
ClientAPI=1.40 ServerAPI=1.40 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2204/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2204

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 8641ef931581 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 141c62584bd

Default Java
Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

checkstyle
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2204/2/artifact/out/diff-checkstyle-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-nodemanager.txt

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2204/2/testReport/

Max. process+thread count
455 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2204/2/console

versions
git=2.17.1 maven=3.6.0 findbugs=4.0.6

Powered by
Apache Yetus 0.13.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

https://issues.apache.org/jira/browse/YARN-10393

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
32m  9s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s
The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
36m 16s
trunk passed

+1 :green_heart:
compile
1m 11s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
compile
1m  6s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
checkstyle
0m 30s
trunk passed

+1 :green_heart:
mvnsite
0m 39s
trunk passed

+1 :green_heart:
shadedclient
16m 57s
branch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 33s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
0m 27s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+0 :ok:
spotbugs
1m 26s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
1m 23s
trunk passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 35s
the patch passed

+1 :green_heart:
compile
1m  5s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javac
1m  5s
the patch passed

+1 :green_heart:
compile
1m  2s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
javac
1m  2s
the patch passed

-0 :warning:
checkstyle
0m 22s
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager: The patch generated 1 new + 121 unchanged - 0 fixed = 122 total (was 121)

+1 :green_heart:
mvnsite
0m 34s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedclient
16m 10s
patch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 28s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
0m 25s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
findbugs
1m 23s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
21m 51s
hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 29s
The patch does not generate ASF License warnings.

137m 13s

Subsystem
Report/Notes

Docker
ClientAPI=1.40 ServerAPI=1.40 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2204/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2204

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 88b19e505584 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 5346cc32637

Default Java
Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

checkstyle
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2204/1/artifact/out/diff-checkstyle-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-nodemanager.txt

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2204/1/testReport/

Max. process+thread count
317 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2204/1/console

versions
git=2.17.1 maven=3.6.0 findbugs=4.0.6

Powered by
Apache Yetus 0.13.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

See discussion and new patch in YARN-10393.
Closing this original PR.


Use the lqip technique for all images

Generate an additional small image (70px) and store it directly in the page encoded as base 64.
Use the classes lazyimages offers for the load stages. The blurring needs some calculation to adapt to the size of the image.

Small WebP images with low quality are included as base64 for all raster images. As soon as the browser has loaded the image (lazysizes assures the best quality) they are replaced with the blur-up effect.


Update handling of backend config and remote state for "virtual" components

what

Update handling of backend config and remote state for "virtual" components

why

Use the base component to read the backend config and remote state if a virtual component is provided

/test all

/test all


Change the color and height of the bottombar top margin/dvider

I like to know if i can change the color and height of the bottombar's top margin/divider. I'm talking about the divider between bottombar and the our fragment

There shoudn't be one

Actually there is one, it's a drawable xml file (bb_bottom_bar_top_shadow.xml). I edited that file to make custom top divider. Sorry, I forgot to close the issue..
Anyway, thanks for your response @alvarlagerlof


Added option --case to configure how each word's case is set

I know that there had been some talk about adding case options in the past which finally got shot down.
But as far as I could tell the proposed alteration would have destroyed the "remember-ability" of the password by randomly mutating the case at the character level.
Also it was mentioned that this sort of thing might be best handled in a post processing step, but this

is not documented in the readme which is all the documentation I could find easily
is NOT user friendly to anyone but coders

Also, I did my best to STAY OUT of your code's established logic. I added a single main new function set_case in what I hoped to be in the spirit of the rest of your logic being broken into functions like find_acrostic etc. And a few supporting functions used by set_case.
Anyway this was a major thing I missed from your tool that sites like https://xkpasswd.net/s/ have. But I really didn;t want to rely on going to a website every time I set a new password. Anyway, rather than just request a feature that I as a coder could easily implement, I figured it wouldn't hurt to send you a PR and let you do with it what you want!
Below is a small over view of the implemented behavior:
(xkcdpass)
# gus @ tardis in ~/remote_mounts/jupiter/src/repos/git/project-repos/XKCD-password-generator on git:feature/set_case o [14:18:18]
$ xkcdpass -n 4 -d \| -c 4
immature|reconcile|unshaved|gauze
impure|sizable|plaza|growl
frosting|hatchery|recliner|share
rumble|ethics|cottage|evergreen
(xkcdpass)
# gus @ tardis in ~/remote_mounts/jupiter/src/repos/git/project-repos/XKCD-password-generator on git:feature/set_case o [14:18:39]
$ xkcdpass -n 4 -d \| -c 4 -C upper
RHYME|DODGE|USUAL|DISAGREE
SCALING|DEFECTION|HUMMING|RISOTTO
CONSONANT|EMBEZZLE|PENPAL|VIRTUOUS
CARRY|MAGNITUDE|ACTIVIST|IMAGING
(xkcdpass)
# gus @ tardis in ~/remote_mounts/jupiter/src/repos/git/project-repos/XKCD-password-generator on git:feature/set_case o [14:18:55]
$ xkcdpass -n 4 -d \| -c 4 -C alternating
MANLY|chrome|ESKIMO|unplanted
RESIDUAL|thicket|VOCALLY|slush
REBOUND|decent|USEABLE|reversing
FINALE|freely|UNPAIRED|hatchet
(xkcdpass)
# gus @ tardis in ~/remote_mounts/jupiter/src/repos/git/project-repos/XKCD-password-generator on git:feature/set_case o [14:19:04]
$ xkcdpass -n 4 -d \| -c 4 -C random
SHOPLIFT|autism|JELLY|VASELINE
CHEMIST|BRONCO|FROSTBITE|UNLIGHTED
dismount|encroach|sincerity|DISPARITY
manly|PEDDLING|UNMAPPED|multiple

And the new help text:
$ xkcdpass --help
usage: xkcdpass [-h] [-w WORDFILE] [--min MIN_LENGTH] [--max MAX_LENGTH]
                [-n NUM_WORDS] [-i] [-v VALID_CHARS] [-V] [-a ACROSTIC]
                [-c COUNT] [-d DELIM] [-C CASE] [--allow-weak-rng]

optional arguments:
  -h, --help            show this help message and exit
  -w WORDFILE, --wordfile WORDFILE
                        Specify that the file WORDFILE contains the list of
                        valid words from which to generate passphrases.
                        Provided wordfiles: eff-long (default), eff-short,
                        eff-special, legacy, spa-mich (Spanish), fin-kotus
                        (Finnish)
  --min MIN_LENGTH      Generate passphrases containing at least MIN_LENGTH
                        words.
  --max MAX_LENGTH      Generate passphrases containing at most MAX_LENGTH
                        words.
  -n NUM_WORDS, --numwords NUM_WORDS
                        Generate passphrases containing exactly NUM_WORDS
                        words.
  -i, --interactive     Generate and output a passphrase, query the user to
                        accept it, and loop until one is accepted.
  -v VALID_CHARS, --valid-chars VALID_CHARS
                        Limit passphrases to only include words matching the
                        regex pattern VALID_CHARS (e.g. '[a-z]').
  -V, --verbose         Report various metrics for given options.
  -a ACROSTIC, --acrostic ACROSTIC
                        Generate passphrases with an acrostic matching
                        ACROSTIC.
  -c COUNT, --count COUNT
                        Generate COUNT passphrases.
  -d DELIM, --delimiter DELIM
                        Separate words within a passphrase with DELIM.
  -C CASE, --case CASE  Choose the method for setting the case of each word in
                        the passphrase. Choices: ['alternating', 'upper',
                        'lower', 'random'] (default: 'lower').
  --allow-weak-rng      Allow fallback to weak RNG if the system does not
                        support cryptographically secure RNG. Only use this if
                        you know what you are doing.

Thanks again for the tool!
Gus

Hey, thanks for the PR - this is merged and in the latest release (1.16.0)


rake task visible to rails app

1 )Now, in rails 4.2 app when i run rake -T , I dont' see haml:erb_2_haml rake task , so fix it.
2)Add more concise desc for task(It is needed for normal display in rake -T)

Merged as 54381b8d833ab5d165203c3a16c26c4974bd95e2.


Fix ContextMenuArea to put the context menu representation in the same box with the content.

The purpose is to avoid emitting an extra node into the parent, which can be meaningful if its layout depends on the number of children.
Proposed Changes
Move the context menu "Representation" into the box that wraps the ContextMenuArea content.
Testing
Test: new unit test
Issues Fixed
Fixes: https://github.com/JetBrains/compose-multiplatform/issues/2729

Note that the new unit test in this PR depends on https://github.com/JetBrains/compose-multiplatform-core/pull/432


chore: Fix a non-fatal syntax error in the azure-cluster-up.sh script

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
Fixes the following syntax error in the script:
./hack/azure-cluster-up.sh: line 428: [false: command not found

Which issue(s) this PR fixes:

Fixes #
Requirements:

[X] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] tested upgrade from previous version

Special notes for your reviewer:
Release note:
none

Pull Request Test Coverage Report for Build 840681057

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 36.946%

Totals

Change from base Build 833538260:
0.0%

Covered Lines:
1101

Relevant Lines:
2980

💛  - Coveralls


When I click on the blog overview to expand the post, throws a 404

Hi When I click on the blog overview to expand the post, throws a 404, from what I can see is that it adds the name of the post to the end of the URL and this causes the crash, if I change the end post name to Default.aspx it works fine.
redirect URL that doesn't work:
http://www.mysite.co.za/COFNEWS/tabid/220/Post/2797/Jacket-Chapter-16
Below is the link that works if I manually edit the end and change it with Default.aspx
http://www.mysite.co.za/COFNEWS/tabid/220/Post/2797/Default.aspx

I cannot reproduce using the latest version of the blog module.
If this is still a problem after upgrading to latest versions, please open a new issues with following info:

What do your urls looks like on other pages, are you using advanced urls, do other pages need the .aspx entension to work?


Image gallery distorts and crops images

The Gallery layout is extremely broken.
This poor demo reflects badly on Pure, and gives new users a hard time.
Could this be replaced with a correct demo? If so, what would the acceptance criteria be for a pull request?

Fixed via https://github.com/yahoo/pure-site/pull/350


Return both intermediates and attn_maps

oh hey Timothy! aren't the attention maps already found on the intermediates?

 Sorry, my bad.

oh yea no problem! i suppose most of the time researchers just want the attention map :thinking:


This repo is 2 years old, needs to be revamped or deleted :)

See title

@mosteo

Yeah, I will add a note that this is now very outdated


Include mention of build step in config file location

Recommended doc improvement as per https://github.com/Azure/static-web-apps/issues/1290
Opened in this repo to get public feedback

@craigshoemaker

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

!sign-off

Discussed with @craigshoemaker about this change and signing off as he is OOF

Will ask Craig to sign off as I don't have permissions

merged. @thomasgauvin - thanks for your explanation.  since you have access to the private repository, please make any additional changes to article in that repo. thanks!

Thanks @Jak-MS


OPT: Add resource uri to metric

Codecov Report

Merging #47 into master will increase coverage by 0.04%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #47      +/-   ##
==========================================
+ Coverage   95.63%   95.68%   +0.04%
==========================================
  Files           9        9
  Lines         275      278       +3
==========================================
+ Hits          263      266       +3
  Misses         12       12

Impacted Files
Coverage Δ

time_execution/decorator.py
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


test token-based upload to PyPI?

Hi! PyPI's getting ready to add upload tokens to its API, so packagers can upload using tokens instead of username/password.
I thought you might want to test and verify that poetry's publish command works with this. Instructions for testing the pull request: https://github.com/pypa/warehouse/issues/994#issuecomment-512634222
It would be great if you could leave a comment on https://github.com/pypa/warehouse/pull/6084 telling us whether it works for you! This will help us avoid headaches when we roll out the feature on pypi.org, which might be within the next week.
And you might want to get an update ready for the credential configuration instructions in the Poetry docs.

This beta feature is now live on PyPI and Test PyPI: https://pypi.org/help/#apitoken

@brainwane Thanks for the heads up!
I will test it this week and add a simple way to set it up with Poetry.

As of release 1.0.0, Poetry now supports token based uploads (see https://python-poetry.org/docs/repositories/#configuring-credentials).


Manifest generated by ConvertModelJsonToManifest  doesn't successfully configure either source or sink

Although the given code sample generates manifest.cdm.json and .cdm.json , when configured the source using manifest as described here, the data does not show up in Data Preview. When manifest analyzed it apparently does not have any information related DataPartitions and DataPartitionPatterns as described in manifest documentation.
https://docs.microsoft.com/en-us/common-data-model/cdm-manifest#local-entity-declaration
How to make the generated manifest using https://github.com/sabinn-msft/ConvertModelJsonToManifest that shall contain all the information needed to configure source and sink in DataFlow.

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

ID: 00c6e7c2-df95-7a57-cbdb-a93a701f8168
Version Independent ID: 24fb7b46-aef0-98ca-5f36-a59b0f7d7c6a
Content: Ingest Microsoft Dataverse data with Azure Data Factory - Power Apps
Content Source: powerapps-docs/maker/data-platform/export-to-data-lake-data-adf.md
Service: powerapps
GitHub Login: @sabinn-msft
Microsoft Alias: matp

Export to data lake produces model.json. When we put this together, ADF did not support model.json and so we provided a stop gap to convert model to manifest. Since then ADF seems to be supporting model.json. Can you try consuming model.json with ADF without converting to manifest? Thanks

Export to data lake produces model.json. When we put this together, ADF did not support model.json and so we provided a stop gap to convert model to manifest. Since then ADF seems to be supporting model.json. Can you try consuming model.json with ADF without converting to manifest? Thanks

Thanks for the quick response.
Format Type Tooltip on ADF(dataflow) displays as follows.
Manifest  - Used by applications that are consuming CDM version 1.0 or later. This file name should look like '*.manifest.cdm.json'
Model - Used by applications that are consuming CDM versions earlier than 1.0. This file name should be 'model.json'
Based on below documentation excerpt of "from model json to the future" it infers that model.json would not suffice for insert into data lake. hence want to generate a manifest that is not only compliant with latest CDM v1.0 and later but also helps to configure and source and sink successfully.
https://docs.microsoft.com/en-us/common-data-model/sdk/from-modeljson-to-the-future
"Originally focusing on explaining the structure and relationships between entities, Common Data Model offered a simple metadata format called "model.json". This format, however, was not able to convey the richness of semantics the source systems had on the data they would insert into data lakes, leaving consumers with limited ability to understand it. "

Thanks for the quick response.
Format Type Tooltip on ADF(dataflow) displays as follows.
Manifest  - Used by applications that are consuming CDM version 1.0 or later. This file name should look like '*.manifest.cdm.json'
Model - Used by applications that are consuming CDM versions earlier than 1.0. This file name should be 'model.json'
Based on below documentation excerpt of "from model json to the future" it infers that model.json would not suffice for insert into data lake. hence want to generate a manifest that is not only compliant with latest CDM v1.0 and later but also helps to configure and source and sink successfully.
https://docs.microsoft.com/en-us/common-data-model/sdk/from-modeljson-to-the-future
"Originally focusing on explaining the structure and relationships between entities, Common Data Model offered a simple metadata format called "model.json". This format, however, was not able to convey the richness of semantics the source systems had on the data they would insert into data lakes, leaving consumers with limited ability to understand it. "

We are working on uptaking latest CDM version to produce manifest.json very soon. That said, please understand that many customers are able to consume model.json in production just fine. We are the largest producers of model.json. I just want to make sure that you don't think there are any shortcomings with model.json.

We are working on uptaking latest CDM version to produce manifest.json very soon. That said, please understand that many customers are able to consume model.json in production just fine. We are the largest producers of model.json. I just want to make sure that you don't think there are any shortcomings with model.json.

Thanks & Much Appreciated, for clarifying that model.json has no short comings for consumption.

Thanks & Much Appreciated, for clarifying that model.json has no short comings for consumption.


SyntaxError for ** unpacking inside sequence literal

$ python -m friendly_traceback

Friendly Console version 0.2.19. [Python version: 3.9.0]

>>> x = [1, 2, 3]
>>> y = [1, **x, 3]

Traceback (most recent call last):
  File "<friendly-console:2>", line 1
    y = [1, **x, 3]
            ^
SyntaxError: invalid syntax

The intent could have been [1, *x, 3] or [1 ** x, 3]. Without knowing the type of x it's difficult to tell.

If you type why(), you will see that an explanation is given, going beyond what Python gives us. [1 ** x, 3] would not give a syntax error.

If you type why(), you will see that an explanation is given, going beyond what Python gives us. [1 ** x, 3] would not give a syntax error.


Update repository URL of mock plugin

cc @jglick as a maintainer, what do you think? This would match with the other slave -> agent repos.

Would make
<gitHubRepo>jenkinsci/${project.artifactId}-plugin</gitHubRepo>

not be accurate; to avoid confusion I prefer to have the repo name align with the artifactId. The display name and description have already been updated so this seems unnecessary.

No strong objections either way. I just thought it would align better with the other renamed repositories.

…which are kind of a mess, because now we have https://github.com/jenkinsci/ssh-agent-plugin (plugin name ssh-agent) which runs the ssh-agent tool (an actual agent), and https://github.com/jenkinsci/ssh-agents-plugin (plugin name ssh-slaves) which runs ~slaves~ agents over SSH.
No strong opinion either, just a general preference to keep repo URLs aligned with artifactIds which must be stable.


Blade table-builder component

Expected Behavior

[ ] Height of placeholder
[ ] Height of empty block (not fixed)

System GA

MR: https://git.awescode.com/awes-io/indigo-layout/merge_requests/184/diffs


Thoughts on shortening project description

While the description in the top of the readme is very helpful for readers who have decided to dig in deeper, having that same length and detail of a description is hard to digest as the top-level repository description/about section.
Obviously up for discussion here, but what about just a short description stating its for 'Tools for automated integration testing Sitefinity ASP.NET projects?'. Might go a little further and outright state the minimum version of sitefinity? (ie. 'Tools for automated integration testing Sitefinity >= X ASP.NET projects?'

After creating the repo, I realized how long the description was compared to the other repos in the AndcultureCode repo list.  I'll update to make it simpler.  To your other point, I think it might be worth while to have the release numbers of this repo match the Sitefinity release numbers that the tests were built for.  Thoughts?

That's an interesting thought around release numbers. If we are 100% confident that this test project will only ever work with a given sitefinity version (ie. not backwards or forwards compatible) then I'd say that makes sense. Otherwise, I feel it should be independent.
Either way, we should make it loud and clear what sitefinity version(s) we support near the very top of the project's README. Otherwise, we can annoy passers by.

I'm 100% confident that this project will work for most, if it all of version 13 of sitefinity.  It might even support 12 as well but I wouldn't go that far in stating anything related to older releases.  Maybe it's best if we just call out the version number that this was tested against (v13.1.7421) and mention that it is likely backward compatible with all of the previous v13 releases but there is no plan to support backward compatibility.


refactor: create grit-core-patterns crate

This creates the grit-core-patterns crate and moves most of the TreeSitter-agnostic code from marzano-core into it. Almost no functional changes needed to be made anymore, so this PR is almost all moving of code and updating of imports.
Some minor exceptions:

FileOwners has gotten a generic argument for the Tree it contains. Also created a FileOwnerCompiler for it.
Some functionality around calling built-in and foreign functions has been split, which moved some functions across structs/traits.
Similar story around variables.

This PR is based on https://github.com/getgrit/gritql/pull/266, so please review and merge that one first. The only new change is a single commit, so hopefully if nothing gets merged in-between, this should cleanly rebase. Then this one should also have become quite a bit smaller.

conflicts with the language changes

Rebased. @ilevyor @morgante

Merging as is, since it's a hefty change likely to cause conflicts later. We can rename in a different PR.


Feat: Styling the home page

Describe the feature
Enhance the home page styles. Make it visually appealing
Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

I want to work on this issue

I want to work on this issue

@arghadipmanna101 Please label this issue under GSSOC 24 guidelines


freebsd and macos fixes

fixes for checking for hard links, and for doing multiple passes.
freebsd and macos share stat and sed history with some differences from gnu
tested on freebsd and linux
I only verified  MAC against man pages and stack overflow
https://man.freebsd.org/cgi/man.cgi?stat(1)
https://ss64.com/mac/stat.html
https://ss64.com/mac/sed.html
https://man.freebsd.org/cgi/man.cgi?sed(1)

Thx!
Although I have no way to test this I think there is no harm in merging this and waiting for reports if something doesn't work as expected. So I will merge this now and we will see what happens :+1:


SPFx Document Search Result with ECB / CommandSet option

Hi there, we are building SPFx based document listview based on search / user personalized view - my bookmarks or recent document;
We want to plug in OOTB ECB menu / command set; is there any option to integrate the same. Currently we are building our custom menu and all supported screens and updates.
Please guide us, thanks. Attached is capture 1 - OOTB menu; capture - 2 our SPFx Add-In;
Thanks in advance;
@VesaJuvonen

Category

[X] Question
[ ] Typo
[ ] Bug
[ ] Additional article idea

Thanks for your contribution! Sharing is caring.

Unfortunately, this is not currently supported and we do not have plans to enable that in short timeframe.


try/catch around reading the metadata

Added a try catch around the s3resourcecheck
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #2838 into master will increase coverage by 0.69%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2838      +/-   ##
==========================================
+ Coverage   63.98%   64.68%   +0.69%
==========================================
  Files         201      199       -2
  Lines       10111    10002     -109
  Branches     2097     2052      -45
==========================================
  Hits         6470     6470
+ Misses       3340     3230     -110
- Partials      301      302       +1

Impacted Files
Coverage Δ

...sync-simulator/src/schema/appsync-scalars/index.ts

...y-appsync-simulator/src/schema/directives/index.ts

...plify-appsync-simulator/src/velocity/util/index.ts

...fy-appsync-simulator/src/schema/directives/auth.ts

...ync-simulator/src/velocity/util/transform/index.ts

...ages/amplify-appsync-simulator/src/schema/index.ts

...psync-simulator/src/velocity/util/general-utils.ts

packages/amplify-appsync-simulator/src/index.ts
0% <0%> (ø)

...-appsync-simulator/src/data-loader/lambda/index.ts
0% <0%> (ø)

...psync-simulator/src/utils/expose-graphql-errors.ts
0% <0%> (ø)

... and 2 more

Continue to review full report at Codecov.

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


Kubernetes names of ServiceClass and Plan versus OSB Guids

See: https://docs.cloudfoundry.org/services/managing-service-brokers.html
Upon refreshing a catalog from a broker a Service and/or Plan name can change. This is problematic for us because we map those names to Kube resource names, which are immutable.
I think we need to use the "id" from the Broker as the Kube "name" since in both cases they'll be immutable. We can then create a property called OSBName (or something like that) to hold the "name" returned from the broker.  In UIs we need to remind people to show the OSBName not the Kube name.

I agree with what you've said here if we can pin down for certain whether the names of these entities can change.  If you just look at the OSB spec, it's not super clear: https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#catalog-management
The link says not to change the ID of services and plans, which I would agree implies that the names might be changed.  I think we should clarify this in the spec before we make any code changes.
If we do this, it's not an amazing experience if you're just writing yaml, but porcelain commands and good user interface can make this easier.

@vaikas-google your thoughts appreciated here

yep - I shutter at the idea of asking people to type GUIDs instead of nicer names in their kube yaml but we may not have a choice.

Opened https://github.com/openservicebrokerapi/servicebroker/issues/187 to determine the answer to this

We discussed in the SIG call that, if brokers are allowed to change names on catalog refreshes, we need to use the GUIDs, and reference them in Instances. This is of course a poor user experience, so I propose that we build a layer of abstraction (the solution to everything in CS, of course!) for naming. I've detailed it in #805

One of the original conversations was to use the osb-guid as the k8s-meta-name for exactly this reason. We ended up using the osb-name for the usability reason.

On today's call we agreed to using ID as the metadata.name on ServiceClass and ServicePlan but we should keep ExternalID too just in case we decide to use something else for the name.
I'll open a new issue to discuss possible designs for how to add on something for a better UX - and that discuss (IMO) should happen before beta.

On Thu, May 11, 2017 at 5:02 PM, Doug Davis<EMAIL_ADDRESS>wrote:

On today's call we agreed to using ID as the metadata.name on
ServiceClass and ServicePlan but we should keep ExternalID too just in
case we decide to use something else for the name.
I'll open a new issue to discuss possible designs for how to add on
something for a better UX - and that discuss (IMO) should happen before
beta.

Agreed about that happening before beta, please include me in that

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-incubator/service-catalog/issues/802#issuecomment-300915976,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABZk7TpOFp99fEQaceIx6LaF3j3MYxFZks5r43dYgaJpZM4NTPUn
.

It looks like this isn't going to be in 0.0.7, moving to 0.1.0

If we switch to using GUIDs as the primary key for serviceclasses and plans, I'd like to include a way to assign human-readable names to the services and plans in the same change. I agree that a porcelain CLI may solve the naming problem, but it won't be a complete solution because Instances will be created from helm charts as well.

while the most common pattern in kube for referencing other objects is by name, what other mechanisms are there?  I know labelSelectors is one but are there others?

The only way to reference individual resources from another resource is by name.
I would be very curious to know how CF deals with name changes for services / plans.  Does someone want to take an action item to find out about that?

they expose the GUIDs for things so even if the user says "foo", they'll use the guid under the covers.

this is why using "names" as keys is a bad idea.  Typically names are human readable and may want to be changed from time to time - but keys/guids/ids/.... being static for all time is usually ok.

Just wondering... are there any cases in kube of people being allowed to modify the name property on a resource?  While not common if its technically allowed it might be something to consider.

Just wondering... are there any cases in kube of people being allowed to modify the name property on a resource? While not common if its technically allowed it might be something to consider.

No

I think its fair to point out that kube does reference other resources by things other than names - I consider labelSelector an example of that.

Label selectors are not a way to reference individual objects

Some rough notes/ideas I've been thinking about for this one:
Assumptions:

can't use serviceID or planID as kube resource names

therefore need to generate a kube acceptable names (eg uuid) for svc/plan

want user to use human friendly service name and plan name

will need a mapping from friendly svc/plan name to kube name (uuid)

when broker changes svc or plan name, all existing instances should no longer show the old name

Proposal:

as service is registered, we create a ServiceClass:

name = new UUID()
uxName = osbapi.svc.name
kubectl get serviceclasses will not work for us until the results are generated server-side
in the meantime, we need to get a kubectl plugin written:
kubectl plugin marketplace
this will allow us to show the uxNames for services and plans

as a plan is registered, we create a ServicePlan:

name = new UUID()
uxName = osbapi.plan.name

when a user creates an Instance they use the human friendly names:

instance.service = svc.uxName
instance.plan    = svc.plan.uxName

during processing of POST we:

convert instance.service to svc.name (the service's uuid) using the mapping defined above
convert instance.plan to svc.plan.name (the plan's uuid) using the mapping defined above

when a user retrieves an Instance:

option 1: (preferred, if kube allows this)

we dynamically set: instance.serviceName (not instance.service) to svc.uxName
we dynamically set: instance.planName (not instance.plan) to svc.plan.uxName

option 2:

do nothing and people will need to use the service or plan fields
as search criteria to retrieve the Service or Plan to see the
real name and other bits of data

I suggest that we avoid thinking too much about the technical details of the approach we eventually take until we have some more information on https://github.com/openservicebrokerapi/servicebroker/issues/273.
We should agree on what problems we're trying to solve.  Some preliminary things to come to an agreement on:

Determine the correct kubernetes names of service classes and plans:

OSB IDs?
A synthesized, stable name?
Something else?

Ideally, the references users make to services and plans should have be using human-readable (or at least human-meaningful) coordinates
Determine what the right level for (2) is:

Is porcelain sufficient to solve this from a UX standpoint?
Is a raw yaml (ie, API construction) solution needed?

Once we know the answer to (3), we can think about what kind of technical solution is needed

This is not a topic that we can simply talk through in a single design meeting.  In k8s core, I would insist that we tackle this with the type of proposal we typically write for large features.  Specific order of operations I suggest:

Come to an agreement on the first 3 questions raised above
Get definitive information about the validations CF applies from https://github.com/openservicebrokerapi/servicebroker/issues/273
A single person should be assigned to write a formal proposal (possibly to the community repo) to outline the problem space, use cases, analysis, technical solution, and implementation details
One or more people implement the proposal from (3)

I would be in favor of treating this as a general problem and making the proposal in the community repo.  My generic formulation of the problem is:

Given some external entity without a human-readable stable coordinate for which there is an API resource X, what is the correct way of providing a human-meaningful stable coordinate to use as the kubernetes name for that entity?

We are likely eventually to have the same problem in another area of the system.  Let's do the work to vet the pattern we use and give others a template to solve it the same way.
Additional notes:
Re: https://github.com/kubernetes-incubator/service-catalog/issues/802#issuecomment-317299121:
I think we should avoid the dynamic transformation in the API server route:

we do not do the type of dynamic transformation of data anywhere else in the system, so this would be establishing a new precedent
API precedent is extraordinarily expensive to establish
the API machinery does not support the kind of plumbing (access to resource X in resource Y's registry implementation) that would be required to do this

Here's another requirement that I think exists:

It should be possible to write a template, helm chart, resource YAML that reliably addresses a particular service class and plan that will be usable in multiple clusters

@smarterclayton curious to know your thoughts here

One thought I had: it would be possible conceivably to support different modes of addressing a serviceclass and plan with a union type.
Also, I would like to point out that this is related to #1010

I think there are multiple ways in which to view how a service would be used across clusters.
1 - from within each cluster there's a cross-cluster reference to the service - @pmorie I think this is the mode you're referring to in your comment above. And in that case I would imagine the "normal" Kube mechanism would be used. Meaning, the reference would need to include some kind of cluster ID/name.  In this case though I would imagine that the service would need to be owned by just one cluster and the one would be responsible for managing it.
2 - if people want to share services across clusters then the service is registered with each cluster independently. This has the advantage of the admin being able to managed which clusters sees which service/plan. This is the model we use in Bluemix today except its not just across Kube clusters but even CF and Docker clusters.
I'm not sure I see the advantage of the first model since there really isn't any logic associated with the registration process - its more a question of visibility and access control - which is better done via the 2nd model. The Broker is really the thing that's shared.

I did not have cross-cluster in mind as a usage model at all, actually, might need to go and clarify some of my above comment

Let me clarify my above comments.  So far in our discussion of this issue we have implicitly been hunting for a single 'just-right' way to address service classes and service plans from the instance spec.  Given the differences of opinion on that subject, I started thinking about supporting both of the following options:
(note, assumes we used the OSB ID of service classes/plans as the kubernetes name of these resources):

Reference the kubernetes name (which in this case would be likely not to be human readable) of these resources
Reference the human-readable name of the service class/plan at any given time (I think this is the mode @duglin seems to favor in this comment
Create 'alias' resources for service class and plan that have user-supplied, stable names that resolve to a specific OSB ID/kubernetes name of service class and plan

I'm not sure whether we would necessarily want to support all of these, but there are other variations of 'where does this service instance come from' (like user provided services, see #1010), that could also be modeled as siblings to these behaviors.
As I said in this comment, my big takeaway is that we probably ought to use a union type to hold information about where a service instance comes from in order to add new options in a backward compatible way and clearly delineating exactly what option a user is requesting.

https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/kubernetes-sig-architecture/rJGgMjrFIQc/rNm6uwlnBQAJ looks like the upstream discussion to follow.

Proposal
Assumptions

name changes of services and plans are deprecated (as agreed to in OSB face to face) do not have to be accomodated in a first-class way
users should never have to look at non-human-readable names of services or plans

Proposed Changes

Move existing fields under ServiceClass and ServicePlan under new Spec structs and add Status to these objects
Retain existing ExternalID fields and ensure these values are immutable for a given name of service and plan
Kubernetes names:

ServiceClass: $brokerName-$serviceClassName
ServicePlan: $brokerName-$serviceClassName-$servicePlanName

Add a new Status.Inactive (boolean) field to ServiceClass and ServicePlan
If a broker changes the name of a service:

set the Status.Inactive field on that ServiceClass
set a status message saying that the service has been renamed to $new-name
do not allow new instances to be created of this service

If a broker changes the name of a plan:

set the Status.Inactive field on that ServicePlan
set a status message saying that the plan has been renamed to $new-name
do not allow new instances to be created on this plan

ServiceInstance keeps the same fields and uses the full kubernetes names to reference ServiceClass and ServicePlan

API Changes
type ServiceClass struct {
	TypeMeta
	ObjectMeta

	Spec ServiceClassSpec
	Status ServiceClassStatus
}

type ServiceClassSpec struct {
	// all existing fields of ServiceClass here

}

type ServiceClassStatus struct {
	// Inactive indicates whether a service is inactive due to being deleted or renamed by the broker
	Inactive        boolean
	// InactiveMessage has information about why the ServiceClass was made inactive
	InactiveMessage *string
}

type ServicePlan struct {
	TypeMeta
	ObjectMeta

	Spec ServicePlanSpec
	Status ServicePlanStatus
}

type ServicePlanSpec struct {
	// all existing fields of ServicePlan here

}

type ServicePlanStatus struct {
	// Inactive indicates whether a plan is inactive due to being deleted or renamed by the broker
	Inactive        boolean
	// InactiveMessage has information about why the ServicePlan was made inactive
	InactiveMessage *string
}

Examples
Given a broker test-broker whose catalog contains a service test-service with plan example-plan-1, the following resources would be created:
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceClass
metadata:
  name: test-broker-test-service
spec:
  brokerName: test-broker
  externalID: d35b55b2-b1fd-4123-8045-5b9c619cb629
  description: "service description"
  bindable: true
---
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServicePlan
metadata:
  name: test-broker-test-service-example-plan-1
spec:
  brokerName: test-broker
  serviceClassName: test-broker-test-service
  externalID: 10e03cb7-b2cf-40dd-a954-16a382b92446
  description: "plan 1 description"
  free: true

A ServiceInstance referencing these would look like:
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceInstance
metadata:
  name: test-instance
  namespace: test-ns
spec:
  serviceClassName: test-broker-test-service
  planName: test-broker-test-service-example-plan-1

If the broker is poorly behaved and intentionally chooses to use deprecated behaviors and renames example-plan-1 to example-plan-2, we would have the following ServicePlans:
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServicePlan
metadata:
  name: test-broker-test-service-example-plan-1
spec:
  brokerName: test-broker
  serviceClassName: test-broker-test-service
  externalID: 10e03cb7-b2cf-40dd-a954-16a382b92446
  description: "plan 1 description"
  free: true
status:
  inactive: true
  inactiveMessage: "renamed to test-broker-test-service-example-plan-2"
---
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServicePlan
metadata:
  name: test-broker-test-service-example-plan-2
spec:
  brokerName: test-broker
  serviceClassName: test-broker-test-service
  externalID: 10e03cb7-b2cf-40dd-a954-16a382b92446
  description: "plan 1 description"
  free: true

Proposal discussed on today's call:  https://docs.google.com/presentation/d/1ZdRqLgAbE8uTQpJrXmdTucitPknURMoQITAJSxr3LhE/edit#slide=id.g25fb676d6e_0_91

I might have another idea!

I am starting to think that we should bail on solving all the complexities of name changes in the initial beta release and solve them later.  It's most important to get things into the hands of users and this seems to be a real bear of a problem to solve.  So, I'm not 100% sure, but I think we should consider doing it.
I do still have another idea I will write up ASAP, but I have exhausted my time budget for this problem for this week and need to move onto other things.

Proposal:

Use OSB ID for k8s names for now
Add an ExternalName field to ServiceClassSpec and ServicePlanSpec that holds the value of the human-readable OSB name
ExternalName should be a selectable field
Users use the human-readable names to specify which service and plan they want via the OSBServiceName and OSBPlanName fields
Add ServiceClassRef and ServicePlanRef fields into ServiceInstanceSpec
Controller writes the ServiceClassRef and ServicePlanRef fields if they are not set
Controller updates the ServicePlanRef field if the OSBPlanName is updated by the user

type ServiceInstanceSpec struct {
	// OSBServiceName is the human-readable name of the service
	// as reported by the broker.
	OSBServiceName string
	// OSBPlanName is the human-readable name of the plan
	// as reported by the broker.
	OSBPlanName string

	// ServiceClassRef is a reference to the ServiceClass
	// that the user selected.
	ServiceClassRef *ObjectReference
	// ServicePlanRef is a reference to the ServicePlan
	// that the user selected.
	ServicePlanRef  *ObjectReference
}

type ServiceClassSpec struct {
	ExternalID   string
	ExternalName string
}

type ServicePlanSpec struct {
	ExternalID   string
	ExternalName string
}

@pmorie @duglin
Do we still need ExternalID fields in Service[Class|Plan]Spec? Seems like that's simple .Name in both cases if we use the ID as the name and it's immutable?

@vaikas-google I do want both external ID and Name fields so we can support different naming strategies in the future

ack


Fix reading port number in interactive restore

Fixes the variable name used to check which option was selected during port selection in interactive restore. Since the variable was empty, the port was not read from any source (environment variable or interactive input).
I looked a little further in the version history and, as far as I can see, the 3.3.5 update introduced the issue, even though the changelog claims to actually fix the issue : https://github.com/tiredofit/docker-db-backup/compare/3.3.4...3.3.5, so maybe I'm just missing something and this PR isn't actually needed.

Thanks for this - This one's been a problem for some time now and it must have been me looking at it over and over again without seeing what truly is the problem. Thanks for the assistance! Tagged as 3.3.9


fix(install): adjust this.$options.router judgment

The judgment "isDef(this.$options.router)" can be more rigorous.
Since in some cases, the router can be null, which will cause the execute error.
And We have faced this situation in  @testing-library/vue/render.js
BTW, this change have been seen in the vue-router-next.

Thanks! can you provide a simple reproduction of when this would fail? Or more context maybe? Why would the statement need to check for more than false values?

Closing due to inactivity. Please open a new issue with a reference to this one if you can follow up with more information.

I met same problem with testing-library/vue@5, then I could avoid this issue with below.
render(Alert, { router: undefined }) // pass router option as undefined explicitly

I think this pr does not have to be merged because this problem occured in testing-library/vue@5 which is for EOL version of Vue, Vue@2.
But I comment for someone who uses same version as me. I would be happy if it is helpful to someone 😺


Refactor lecture routes to use child routes

Checklist

[ ] I tested all changes and all related features with different users (student, tutor, instructor, admin) on the test server https://artemistest.ase.in.tum.de.
[x] Client: I followed the coding and design guidelines.
[ ] Client: I added multiple screenshots/screencasts of my UI changes

Motivation and Context
Follow-up to the last breadcrumbs PR. Also fixes some issues @jpbernius noted on Slack.
Description
Resolves several TODOs/workaround and makes the lecture unit routes use child routes, which allows us to reuse courses, lectures, etc. fetched by parent components in future PRs. (If we want to do that.)
Steps for Testing

Navigate to Course Administration
Test that everything accessible after clicking "Lectures" on a course works as intended and displays correct breadcrumbs

Screenshots
TODO (Can't deploy on test server atm.)

This is now over 7 days old, I'll reopen a PR once I have revisited this.


chore: allow disabling per tokenizer

Fixes RM-541

🧰 Changes
Allow fine grain control over which tokenizers are in use. While developing for @readme/editor, we'd like to keep the editor non-lossy. The easiest way to do that is to disable tokenizers that we don't yet handle.
If we don't disable a tokenizer, we could convert it back to plain text. But it gets complicated, because we'd have to know what text was 'eaten' by the markdown engine.

This PR was released!
🚀 Changes included in v6.26.3-next.1


Merge branch 'develop' into master

Pull Request Test Coverage Report for Build 566449741

0 of 5 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 87.251%

Totals

Change from base Build 566383157:
0%

Covered Lines:
994

Relevant Lines:
1068

💛  - Coveralls


Add id selectors for change initiatives

Org units -> Change initiatives
Measurables -> Change initiatives

Also remove logic in survey-run-create.js

Depends on #1798


Remove MongoDB.Server 6.3.0

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.
Context for removal
Under MongoDB versioning, releases other than .0 (major) are called point releases. Point releases are only supported for Atlas and major releases (stable) are recommended. I am removing this version of the manifest as users using stable releases can't update from 6.0.3 to 6.0.6 (WIP PR) as the update command will default to the highest version.

Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/110087&drop=dogfoodAlpha

I will probably correct the other entries too


CUDA device-side assertions

I am sanity checking our real-world RGB-D capture (collected with RTAB-map) with grad-SLAM for conceptgraphs.
everything works fine with replica, but as soon as I try to load in our dataset, device-side assertions happen. Unfortunately, error is non-deterministic, meaning it's not always thrown on the same frame.
This is the data loader I wrote to load RTAB-map datasets in conceptgraphs:

class RTABmapDataset(GradSLAMDataset):
    """A RGB-D dataset from a RTAB-map export"""

    def __init__(
        self,
        config_dict: dict[str, Any],
        basedir: str,
        sequence: str,
        stride: int | None = None,
        start: int | None = 0,
        end: int | None = -1,
        desired_height: int | None = 480,
        desired_width: int | None = 640,
        load_embeddings: bool | None = False,
        embedding_dir: str | None = "embeddings",
        embedding_dim: int | None = 512,
        **kwargs,
    ):
        self.input_folder = os.path.join(basedir, sequence)

        assert os.path.exists(self.input_folder), "Unknown dataset dir"

        self.pose_path = os.path.join(self.input_folder, "poses.txt")

        super().__init__(
            config_dict,
            stride=stride,
            start=start,
            end=end,
            desired_height=desired_height,
            desired_width=desired_width,
            load_embeddings=load_embeddings,
            embedding_dir=embedding_dir,
            embedding_dim=embedding_dim,
            **kwargs,
        )

    def get_filepaths(self):
        # filter out filepaths without optimized poses
        optim = set(
            np.genfromtxt(fname=self.pose_path, delimiter=" ", skip_header=1)[:, -1].astype(int)
        )

        def isinoptim(x: str) -> bool:
            x = os.path.basename(x).split(".")[0]
            return int(x) in optim

        embedding_paths = None

        color_paths = glob.glob(os.path.join(self.input_folder, "rgb", "*.jpg"))
        color_paths = natsorted(filter(isinoptim, color_paths))

        depth_paths = glob.glob(os.path.join(self.input_folder, "depth", "*.png"))
        depth_paths = natsorted(filter(isinoptim, depth_paths))

        return color_paths, depth_paths, embedding_paths

    def load_poses(self):
        from scipy.spatial import transform

        #
        trajectory = np.genfromtxt(fname=self.pose_path, delimiter=" ", skip_header=1)
        trajectory = trajectory[:, 1:-1]  # discard timestamp and key

        M = torch.tensor(
            [
                [1, 0, 0, 0],
                [0, 1, 0, 0],
                [0, 0, 1, 0],
                [0, 0, 0, 1]
            ]
        ).float()

        # assuming RTAB-map follows the RH coordinate system (x right, y up, z backward)

        P = []

        for state in trajectory:
            C_to_W = np.zeros((4, 4))
            C_to_W[3, 3] = 1.0
            C_to_W[:3, :3] = transform.Rotation.from_quat(state[3:]).as_matrix()
            C_to_W[:3, 3] = state[:3]
            C_to_W = torch.from_numpy(C_to_W).float()
            C_to_W = M @ C_to_W @ M.T

            P.append(C_to_W)

        return P

with the following config from a multi realsense setup (D435i + T265):
camera_params:
  cx: 318.409
  cy: 244.501
  image_height: 480
  image_width: 640
  fx: 608.794
  fy: 608.776
  png_depth_scale: 1000.0
dataset_name: rtabmap

After processing 50-ish frames, such a warning keeps repeating over and over:

/path/to/venv/lib/python3.10/site-packages/gradslam/slam/fusionutils.py:188: RuntimeWarning: Max of dot product was 1.3151907920837402 > 1. Inputs were not normalized along dim (-1). Was this intentional?
warnings.warn(
2%|███▍                                                                                | 67/3170 [00:09<10:56,  4.73it/s]
/path/to/venv/lib/python3.10/site-packages/gradslam/slam/fusionutils.py:188: RuntimeWarning: Max of dot product was 1.4051384925842285 > 1. Inputs were not normalized along dim (-1). Was this intentional?
warnings.warn(
2%|███▌

culminating in the following error:

../aten/src/ATen/native/cuda/IndexKernel.cu:92: operator(): block: [31679,0,0], thread: [122,0,0] Assertion -sizes[i] <= index && index < sizes[i] && "index out of bounds" failed.
../aten/src/ATen/native/cuda/IndexKernel.cu:92: operator(): block: [31679,0,0], thread: [123,0,0] Assertion -sizes[i] <= index && index < sizes[i] && "index out of bounds" failed.
../aten/src/ATen/native/cuda/IndexKernel.cu:92: operator(): block: [31679,0,0], thread: [124,0,0] Assertion -sizes[i] <= index && index < sizes[i] && "index out of bounds" failed.
../aten/src/ATen/native/cuda/IndexKernel.cu:92: operator(): block: [31679,0,0], thread: [125,0,0] Assertion -sizes[i] <= index && index < sizes[i] && "index out of bounds" failed.
../aten/src/ATen/native/cuda/IndexKernel.cu:92: operator(): block: [31679,0,0], thread: [126,0,0] Assertion -sizes[i] <= index && index < sizes[i] && "index out of bounds" failed.
../aten/src/ATen/native/cuda/IndexKernel.cu:92: operator(): block: [31679,0,0], thread: [127,0,0] Assertion -sizes[i] <= index && index < sizes[i] && "index out of bounds" failed.
4%|██████▎                                                                                | 123/3170 [00:26<11:01,  4.60it/s]
Traceback (most recent call last):
File "/root/conceptgraphs/experiments/rtabmap-lingotto-600p-floor1-north/../../toolchain/run_slam_rgb.py", line 133, in
main(args)
File "/root/conceptgraphs/experiments/rtabmap-lingotto-600p-floor1-north/../../toolchain/run_slam_rgb.py", line 108, in main
pointclouds, _ = slam.step(pointclouds, frame_cur, frame_prev)
File "/root/miniconda3/envs/conceptgraphs/lib/python3.10/site-packages/gradslam/slam/icpslam.py", line 180, in step
pointclouds = self._map(pointclouds, live_frame, inplace)
File "/root/miniconda3/envs/conceptgraphs/lib/python3.10/site-packages/gradslam/slam/pointfusion.py", line 115, in _map
return update_map_fusion(
File "/root/miniconda3/envs/conceptgraphs/lib/python3.10/site-packages/gradslam/slam/fusionutils.py", line 899, in update_map_fusion
pc2im_bnhw = find_correspondences(pointclouds, rgbdimages, dist_th, dot_th)
File "/root/miniconda3/envs/conceptgraphs/lib/python3.10/site-packages/gradslam/slam/fusionutils.py", line 573, in find_correspondences
pc2im_bnhw, _ = find_similar_map_points(
File "/root/miniconda3/envs/conceptgraphs/lib/python3.10/site-packages/gradslam/slam/fusionutils.py", line 388, in find_similar_map_points
frame_points[pc2im_bnhw[:, 0], pc2im_bnhw[:, 1]] = vertex_maps[
RuntimeError: CUDA error: device-side assert triggered

The RGB-D capture is 3170-frame-long and should cover an area of about 30 x 10 meters.
Any idea what could trigger the error?

pytorch version (e.g., 1.0): 2.1.2+cu121
OS: ubuntu 22.04.4 LTS (x86_64)
how you installed pytorch (conda, pip, source): pip
python version: 3.10.13
CUDA/cuDNN version: 11.8.89
GPU models and configuration: GPU 0: NVIDIA A10G

Thanks for the interest @DiTo97
The device-side assert most commonly occurs when there's pose / depthmap errors, which then cascades through the data association step. I would recommend visualizing just a few frames first to see how the 3D scene reconstruction looks like.
Since you are using RTABMap to compute global poses, it is likely that the frames around which this assertion is triggered have pose errors.
======
As an aside, we have been able to successfully interface (well, patch) RTABMap and gradslam for use in the concept-graphs project (where I see you mentioned this issue).
You might want to look at this GH repo to see how we did that:

Follow this "before building..." instruction from the README -- we made a quick-and-dirty edit to the RTABMap script to hardcode camera intrinsics.
We also have instructions to export poses, and have provided a python script to convert the exported rtabmap poses to gradslam dataset format (you will want to use the AzureKinectDataset or replicate this code to suit your directory structure).

Needless to say, the intrinsics, image dims etc are assumed to be correctly specified in the yaml config file that you'd pass in.
===================
Hope this helps! Closing for now, but reopen if the repo I pointed you to doesn't address your question.


About page

The frontend should contain an "about this" subpage with contact information and a link to this repository for feature requests and bug reports.

Contact information should be configurable.


[SDK] Fix props for TokenIcon component

Problem solved
Short description of the bug fixed or feature added

PR-Codex overview
This PR updates the Token/icon.tsx file to enhance the rendering of an image by spreading the restProps onto the  element, allowing for additional properties to be passed.
Detailed summary

Modified the return statement in the Token/icon.tsx file.
Changed  to , enabling the inclusion of more attributes on the image.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

#5493  👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Merge activity

Nov 22, 10:09 AM EST: The merge label 'hotfix' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.


feat: implementing use of popular searches as a QP fallback

Pull request template

Some customers don’t set brand recommendations. An idea for a fallback is to create a component that takes the popular searches and creates query previews with them, similar to what we do with the semantic queries.
I have implemented an intermediate component that wraps around custom-query-preview. This component receives an optional prop "maxPopularSearchesToRender", and in the case where QueriesPreview does not exist, it passes as information to be rendered by custom-query-preview the popular searches limited by the aforementioned prop.
Use this in the console to test when there are no queriePreviews: InterfaceX.setSnippetConfig({
queriesPreview: [
]
})
Motivation and context

[ ] Dependencies. If any, specify:
[X] Open issue. If applicable, link: EMP-3422

Type of change

[ ] Bug fix (non-breaking change that fixes an issue)
[X] New feature (non-breaking change that adds functionality)
[ ] Breaking change (fix or feature that causes existing functionality to not work as expected)
[ ] Change requires a documentation update

What is the destination branch of this PR?

[X] Main
[ ] Other. Specify:

How has this been tested?

Tests performed according to testing guidelines:
Checklist:

[ ] My code follows the style guidelines of this project.
[ ] I have performed a self-review on my own code.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have made corresponding changes to the documentation.
[ ] My changes generate no new warnings.
[ ] I have added tests that prove my fix is effective or that my feature works.
[ ] New and existing unit tests pass locally with my changes.

Like it!

Hi!
I've seen we are changing the "CustomQueryPreview" component's name to "BrandRecommendations" in some customers. Maybe we should also do it here?
cc @CachedaCodes @lauramargar

Hi! I've seen we are changing the "CustomQueryPreview" component's name to "BrandRecommendations" in some customers. Maybe we should also do it here? cc @CachedaCodes @lauramargar

I wouldn't. The component manage pre search has a good enough name (I would name it PreSearchManager) and the custom query previews component is not only being used for brand recommendations (if we understand brand recommendations as the queries that the brand puts in the snippet config).


Add EditModuleCommand and relevant tests

Hybrid testing done

Codecov Report

Merging #117 (f3652f6) into master (8469347) will increase coverage by 0.38%.
The diff coverage is 65.17%.

@@             Coverage Diff              @@
##             master     #117      +/-   ##
============================================
+ Coverage     60.61%   60.99%   +0.38%
- Complexity      591      606      +15
============================================
  Files           112      114       +2
  Lines          2252     2356     +104
  Branches        262      284      +22
============================================
+ Hits           1365     1437      +72
- Misses          807      829      +22
- Partials         80       90      +10

Impacted Files
Coverage Δ

...main/java/seedu/address/commons/core/Messages.java
0.00% <ø> (ø)

.../seedu/address/logic/parser/AddressBookParser.java
64.00% <0.00%> (-2.67%)
:arrow_down:

.../address/logic/parser/EditModuleCommandParser.java
0.00% <0.00%> (ø)

...dress/logic/commands/module/EditModuleCommand.java
82.66% <82.66%> (ø)

...ess/logic/commands/module/DeleteModuleCommand.java
100.00% <100.00%> (ø)

...del/module/ModuleCodeContainsKeywordPredicate.java
100.00% <100.00%> (ø)

...c/main/java/seedu/address/model/module/Module.java
93.47% <0.00%> (-2.18%)
:arrow_down:

src/main/java/seedu/address/model/AddressBook.java
83.58% <0.00%> (+4.47%)
:arrow_up:

...rc/main/java/seedu/address/model/ModelManager.java
80.00% <0.00%> (+6.25%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

#101


Parser sends many text events for the same element

The following snippet produces an unexpected output:
const Promise = require('bluebird');
const { Readable } = require('stream');
const expat = require('node-expat');

const parser = new expat.Parser('UTF-8');

new Promise((resolve, reject) => {
  parser.on('text', (text) => {
    console.log('Text event emmited:', text);
  });

  parser.on('end', () => {
    resolve();
  });

  parser.on('error', (error) => {
    reject(error);
  });

  const s = new Readable();
  s._read = function () {};
  s.pipe(parser);
  s.push(`<?xml version="1.0" encoding="UTF-8"?>
  <test>
    <inner>Expected the text event to push all text at once<sup>®</sup></inner>
  </test>`);
  s.push(null);
})
.then(() => {
  console.log('success');
  process.exit(1);
})
.catch((err) => {
  console.log('error', err);
  process.exit(1);
});

Output produced:
Text event emmited:

Text event emmited:
Text event emmited: Expected the text event to push all text at once
Text event emmited: <
Text event emmited: sup>
Text event emmited: ®
Text event emmited: <
Text event emmited: /sup>
Text event emmited:

Text event emmited:
success

A workaround is to check if the endElement event was not emmited before the text event.
Is this behaviour expected?
Thanks

The Wikipedia entry for the sax parser api page states that:

the SAX specification deliberately states that a given section of text may be reported as multiple sequential text events. Many parsers, for example, return separate text events for numeric character references

So this is perfectly fine


Replace onOmemoMessageReceived(Message cleartext) with onOmemoMessageReceived(List cleartextElements)

I'll have to investigate, how to handle multiple 'encrypted'-Elements

I'll have to find out, whether there is some kind of BodyExtensionElement and how to get the contents of it. Also I have to find out, how multiple extension elements would be encrypted.
For now there is not much I can do, since XEP-0384 explicitly states that the payload element is treated as the body of a message.


Add CQM.to_lp_file

added function to serialize CQM as LP file

Codecov Report

Merging #1052 (e4d01d2) into main (d9088eb) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1052   +/-   ##
=======================================
  Coverage   98.54%   98.54%
=======================================
  Files          49       49
  Lines       10655    10675   +20
=======================================
+ Hits        10500    10520   +20
  Misses        155      155

Impacted Files
Coverage Δ

test_constrained.py
99.17% <0.00%> (+0.02%)
:arrow_up:

Continue to review full report at Codecov.

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

By the way, depending on what LP files require in terms of variable labels, it might just be reasonable to throw an error if the CQM is not labelled in a way that makes sense.

There is still work to do, especially in how the variable names are handled..

Re variable handling, IMO the best approach is something like
def to_lp_file(self, *,
               spool_size: int = int(1e9),
               encoder: Optional[Callable[[Variable], str]] = None,
               ) -> tempfile.SpooledTemporaryFile:
    if encoder is None:
        if not all(isinstance(v, str) for v in self.variables):
            raise ValueError("unless an encoder is provided, all variables must be string-labelled, "
                             "If the variables are integer-labelled, using `encoder=str` will encode them as strings")

        def encoder(v: Variable) -> str:
            return v

    ...

and then add the encoder=str as an example in the docstring.
We could do something more automagical, but IMO it'll just create issues in the long run.

Putting this here so I don't forget, the LP file format actually is pretty strict about variable labels, see http://www-eio.upc.edu/lceio/manuals/cplex-11/pdf/reffileformatscplex.pdf (page 9, section 4)
Variables can be named anything provided that the name does not exceed 255 characters,
all of which must be alphanumeric (a-z, A-Z, 0-9) or one of these symbols: ! " # $ % &
( ) , . ; ? @ _ ‘ ’ { } ~. Longer names are truncated to 255 characters. A variable name can
not begin with a number or a period.
The letter E or e, alone or followed by other valid symbols, or followed by another E or
e, should be avoided as this notation is reserved for exponential entries. Thus, variables
can not be named e9, E-24, E8cats, or other names that could be interpreted as an
exponent. Even variable names such as eels or example can cause a read error,
depending on their placement in an input line.

Closed in favor of https://github.com/dwavesystems/dimod/pull/1202


Add zap stanza to multipatch

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

Thank you for the continued zap additions!


Ringcentral Sip

i have tried my ringcentral SIP But its not work with that can you help me to do with that.

I do not have a ringcentral account to test it with.  Sorry.