Some autotile layers not being imported

Hey.
I have been trying to get this great asset to work for today now. Everything else works great, but larger tilesets do not. From the image I attached below, you can see the tilemaps (16x16) working in both LDTK and Godot, but the Big_Props tilemap (64x64) does not get shown.

A Tileset is created for it:

I get the following errors when reimporting the .ldtk file:
core/variant/variant_utility.cpp:1112 - LDtk file version is newer than what is supported. Errors may occur.
  core/variant/variant_utility.cpp:1112 - TileSetSource creation failed!
  core/variant/variant_utility.cpp:1092 - TileSetAtlasSource missing
  core/variant/variant_utility.cpp:1092 - TileSetAtlasSource missing
  core/variant/variant_utility.cpp:1092 - TileSetAtlasSource missing
  core/variant/variant_utility.cpp:1092 - TileSetAtlasSource missing
  core/variant/variant_utility.cpp:1092 - TileSetAtlasSource missing
-- LDTK: Start Import --
LDTK VERSION OK
-- LDTK: Finished Import -- (108ms)

I also tried to do some debugging though the code was very complex for me :D
Seems that the layers.gd function create_layers() is not being called for the 64x64 tilemap, but I cannot really understand why.
Seems like a common thing to want bigger props such as trees in one's game. I'd be surprised if that was not possible, so I am guessing I am doing something wrong myself. Any help is very much appreciated, thanks!
For now I think I'll move to using entities for these larger props.

This was really annoying me yesterday so I did some digging. Here's the reason: the layer import script is trying to look for 64x64 tiles in the 16x16 TileSet. This is because the grid size of the LDTK world is always 16x16.
What I think would be the fix would be to use the grid size of the texture that is looked for to determine the TileSet to use, instead of the grid size of the tilemap. Because the grid size of an autotile layer cannot be changed, and will always be the same as the intgrid, even if the tiles are larger.
Hope this helps, if someone will try to tackle this issue in the future.

Hey! I have a potential fix for this issue I think. I'm not sure it's ready for a pull request yet because there are some changes I'm not really sure about. The example project seems work fine but I haven't done any other testing yet. I'm also still very new to LDtk so there may some obvious stuff that I'm missing. The commit with my fix is here though: https://github.com/Joeyrp/godot-ldtk-importer/commit/33d0cacac306f65872d934ebf0b31de408495e6e
The main thing I did was change the tileset Dictionary in Util.gd to make the tile set uid the key instead of the grid_size (the tileset res files are now saved with the uid instead of the grid_size as well). This allowed it to find the larger tiles on the auto-tile layer but they were offset incorrectly on the map. To fix this I changed an argument to use the tile_size instead of the grid_size and I marked that change with a big # HACK comment so it should be easy to see in the commit diff.
Without the hack solution the level looks like this:

The red boxes are the 64x64 tiles that I added for testing (the box at the top left is manually placed with a normal Tile layer and the rest are on the auto-tile layer). You can see the auto-tiled ones are off the map. With the hacky solution it seems to be fixed though:

Hopefully this will help! I can try to make more adjustments/corrections if requested or open a pull request if it seems good enough.

Fascinating! I spent a while looking into how things worked in the importer in regards to this issue and it prompted me to rewrite TileSets. I didn't know LDtk supported using tilesets that don't match the layer grid size.
Rather than using @Joeyrp's solution, I found it was possible to still keep TilesetAtlasSources grouped by grid size, but 'mismatched' sources are copied into the TileSet if they are used in that grid size. This now behaves as you'd expect it to!
Thanks for the report! Fixed in v2.0.1


docs(mashup): add a sn-table mashup example in saas with platform sdk

This is a decent implementation using webIntegrationId and seems like nothing wrong with it!
The only thing is that should we expose tenantUrl, our integration id and app id with it?
I would say in main.js in the connect({ ... }) you should do something like:
const app = await connect({
    url: 'https://xxxx.us.qlik.com', //  note: https:// is needed
    webIntegrationId: 'xxx-xxxxxxx-xxxxxxxx',
    appId: 'xxxx-xxx-xxx-xxx-xxxxxxx',
  });

because eventually that app and that tenant is not so much reliable to be open sourced as an example

Of course not. I forgot to remove them after testing. Thx!


Fix CMake TPLs ordering issue

In CMakeLists.txt, move STRUMPACK before METIS in the list MFEM_TPLS.
Issue reported in #3342.

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#3348
@v-dobrev
@tzanio
@cjvogl + @sebastiangrimberg
11/29/22
12/9/22
12/12/22

PR Checklist

[ ] Code builds.
[ ] Code passes make style.
[ ] Update CHANGELOG:

[ ] Is this a new feature users need to be aware of? New or updated example or miniapp?
[ ] Does it make sense to create a new section in the CHANGELOG to group with other related features?

[ ] Update INSTALL:

[ ] Had a new optional library been added? If so, what range of versions of this library are required? (Make sure the external library is compatible with our BSD license, e.g. it is not licensed under GPL!)
[ ] Have the version ranges for any required or optional libraries changed?
[ ] Does make or cmake have a new target?
[ ] Did the requirements or the installation process change? (rare)

[ ] Update continuous integration server configurations if necessary (e.g. with new version requirements for each of MFEM's dependencies)

[ ] .github
[ ] .appveyor.yml

[ ] Update .gitignore:

[ ] Check if make distclean; git status shows any files that were generated from the source by the project (not an IDE) but we don't want to track in the repository.
[ ] Add new patterns (just for the new files above) and re-run the above test.

[ ] New examples:

[ ] All sample runs at the top of the example source file work.
[ ] Update examples/makefile:

[ ] Add the example code to the appropriate SEQ_EXAMPLES and PAR_EXAMPLES variables.
[ ] Add any files generated by it to the clean target.
[ ] Add the example binary and any files generated by it to the top-level .gitignore file.

[ ] Update examples/CMakeLists.txt:

[ ] Add the example code to the ALL_EXE_SRCS variable.
[ ] Make sure THIS_TEST_OPTIONS is set correctly for the new example.

[ ] List the new example in doc/CodeDocumentation.dox.
[ ] If new examples directory (e.g.examples/pumi), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add example-specific documentation, see e.g. the src/examples.md.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] In examples.md, list the example under the appropriate categories, add new categories if necessary.
[ ] Add a short description of the example in the "Extensive Examples" section of features.md.

[ ] New miniapps:

[ ] All sample runs at the top of the miniapp source file work.
[ ] Update top-level makefile and makefile in corresponding miniapp directory.
[ ] Add the miniapp binary and any files generated by it to the top-level .gitignore file.
[ ] Update CMake build system:

[ ] Update the CMakeLists.txt file in the miniapps directory, if the new miniapp is in a new directory.
[ ] Add/update the CMakeLists.txt file in the new miniapp directory.
[ ] Consider adding a new test for the new miniapp.

[ ] List the new miniapp in doc/CodeDocumentation.dox
[ ] If new miniapps directory (e.g.miniapps/nurbs), add it to MINIAPP_SUBDIRS in the makefile.
[ ] If new miniapps directory (e.g.miniapps/nurbs), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add miniapp-specific documentation, see e.g. the src/meshing.md and src/electromagnetics.md files.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] The miniapps go at the end of the page, and are usually listed only under a specific "Application (PDE)" category.
[ ] Add a short description of the miniapp in the "Extensive Examples" section of features.md.

[ ] New capability:

[ ] All new public, protected, and private classes, methods, data members, and functions have full Doxygen-style documentation in source comments. Documentation should include descriptions of member data, function arguments and return values, template parameters, and prerequisites for calling new functions.
[ ] Pointer arguments and return values must specify whether ownership is being transferred or lent with the call.
[ ] Any new functions should include descriptions of their intended use e.g. for internal use only, user-facing, etc., along with references to example code whenever possible/appropriate.
[ ] Consider adding new sample runs in existing examples to highlight the new capability.
[ ] Consider saving cool simulation pictures with the new capability in the Confluence gallery (LLNL only) or submitting them, via pull request, to the gallery section of the mfem/web repo.
[ ] If this is a major new feature, consider mentioning it in the short summary inside README (rare).
[ ] List major new classes in doc/CodeDocumentation.dox (rare).

[ ] Update this checklist, if the new pull request affects it.
[ ] Run make unittest to make sure all unit tests pass.
[ ] Run the tests in tests/scripts.
[ ] (LLNL only) After merging:

[ ] Update internal tests to include the new features.

I apologize for chiming in here, but I had noticed this same issue when using static linkage in the past and worry if this is the right fix respect to the leading comment:
# List all possible libraries in order of dependencies.
# [METIS < SuiteSparse]:
#    With newer versions of SuiteSparse which include METIS header using 64-bit
#    integers, the METIS header (with 32-bit indices, as used by mfem) needs to
#    be before SuiteSparse.
set(MFEM_TPLS OPENMP HYPRE LAPACK BLAS SuperLUDist STRUMPACK METIS SuiteSparse
    SUNDIALS PETSC SLEPC MESQUITE MUMPS AXOM FMS CONDUIT Ginkgo GNUTLS GSLIB
    NETCDF MPFR PUMI HIOP POSIXCLOCKS MFEMBacktrace ZLIB OCCA CEED RAJA UMPIRE
    ADIOS2 CUBLAS CUSPARSE MKL_CPARDISO AMGX CALIPER CODIPACK BENCHMARK PARELAG
    MPI_CXX HIP HIPSPARSE MOONOLITH BLITZ ALGOIM ENZYME)

Namely, according to the comment, packages depending on METIS should only be listed after METIS. I think the real issue is a few lines down where duplicates are removed:
list(REMOVE_DUPLICATES TPL_LIBRARIES)
list(REMOVE_DUPLICATES TPL_INCLUDE_DIRS)

In this case the CMake behavior is to keep the first entry and remove all later ones. What you really want for a static link line is for the last duplicate to be kept and all prior ones removed, so I have found that using instead:
list(REVERSE TPL_LIBRARIES)
 list(REMOVE_DUPLICATES TPL_LIBRARIES)
list(REVERSE TPL_LIBRARIES)

works and allows the MFEM_TPLS list to be constructed in order of dependency as the comment suggests. Note that this would also apply to SuperLUDist which also has a METIS dependency. I think the correct ordering of the first line in order of dependency would probably be:
set(MFEM_TPLS OPENMP LAPACK BLAS  MPI_CXX HYPRE METIS SuperLUDist STRUMPACK SuiteSparse

Anyway, just thought I would voice my experience as this worked for me when building with MUMPS/STRUMPACK/SuperLUDist support and might be a preferred long-term solution. At the very least if this isn't preferred then the original comment should be ammended.

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

@sebastiangrimberg, thanks for the suggestion about TPL_LIBRARIES -- I added that to the PR.
Regarding your comment: " ... according to the comment, packages depending on METIS should only be listed after METIS." The case of METIS < SuiteSparse is an exception to the rule and concerns a special case where SuiteSparse is built and linked with its internal version of METIS (which is a slightly modified METIS-5.1.0 using 64-bit indices) and we are compiling and linking with another METIS build. In this case it is important to include metis.h NOT from the SuiteSparse directory but the one we want -- that's why METIS should come before SuiteSparse (because include dirs are searched in the order they appear on the command line, as far as I know).
In general, in the TPL_LIBRARIES we want A before B whenever A depends on B. This makes sense when A depends on B but A_LIBRARIES does not include B_LIBRARIES. However, when removing duplicates in TPL_LIBRARIES as before (i.e. keeping the first occurrence of a library), we can get undesired behavior, e.g. when two different libraries depend on the same library.
With the change you suggested (to keep the last occurrence), I think the ordering in MFEM_TPLS should only matter is the special case when A depends on B and A_LIBRARIES does not include B_LIBRARIES which is contrary to the expected behavior: A_LIBRARIES should include all libraries needed for linking with A.
I think the updated logic in CMakeLists.txt (as it is now in this PR) about the handling of MFEM_TPLS and TPL_LIBRARIES should be correct. Do you see any cases where there still may be problems?

@v-dobrev Thanks for explaining that, I kind of misread the comment about METIS and SuiteSparse thinking this was an example for how dependencies should be ordered. I agree with everything you've said, and especially that none of this becomes an issue when the user correctly is specifying the A_REQUIRED_PACKAGES and A_REQUIRED_LIBRARIES, with their correct ordering as well.
Looks good to me and works in my tests.

Hi again @v-dobrev, I had a couple more thoughts I wanted to share as they could be related to this PR.

CMake 3.8 (released April 2017) fixed the handling of CMAKE_CXX_STANDARD, etc. for try_compile, so it could be worth reverting your additions to config/cmake/modules/MfemCmakeUtilities.cmake and just bumping the minimum cmake_required_version to 3.8 in my opinion (see https://cmake.org/cmake/help/latest/policy/CMP0067.html).
Suggested change for C++14 requirements adding STRUMPACK (https://github.com/mfem/mfem/blob/master/CMakeLists.txt#L85):

# SUNDIALS, STRUMPACK, and Ginkgo require C++14:
if ((MFEM_USE_SUNDIALS OR MFEM_USE_STRUMPACK OR MFEM_USE_GINKGO) AND
    ("${CMAKE_CXX_STANDARD}" LESS "14"))
  set(CMAKE_CXX_STANDARD 14)
endif()

When building with OpenMP support, and using dependencies which use OpenMP, I have run into the following issue with CMake. Adding OpenMP to <PACKAGE>_REQUIRED_PACKAGES doesn't correctly add the compiler flags because it doesn't use an imported target and only adds the include directories and link libraries. This makes any test programs fail at link time due to unresolved symbols. Alternatively, the find_package(OpenMP) block here does not set the compiler flags, which are only set later on (after third-party library finding) here. If these blocks were earlier on in the CMakeLists.txt file, the flags would be automatically used by the try_compile statements and resolve the issue. Thus, I propose adding the below block to line 188 (at beginning of TPLs) or 201 (after HIP) so that the flags are set for any test builds later on:

# OpenMP
if (MFEM_USE_OPENMP OR MFEM_USE_LEGACY_OPENMP)
  if (NOT MFEM_THREAD_SAFE AND MFEM_USE_LEGACY_OPENMP)
    message(FATAL_ERROR " *** MFEM_USE_LEGACY_OPENMP requires MFEM_THREAD_SAFE=ON.")
  endif()
  find_package(OpenMP REQUIRED)
  set(OPENMP_LIBRARIES ${OpenMP_CXX_LIBRARIES})
  if(APPLE)
    # On macOS, the compiler needs additional help to find the <omp.h> header.
    # See issue #2642 for more information.
    set(OPENMP_INCLUDE_DIRS ${OpenMP_CXX_INCLUDE_DIRS})
  endif(APPLE)
  if (OPENMP_FOUND)
    message(STATUS "MFEM: using package OpenMP")
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
    if (MFEM_USE_CUDA)
      set(CMAKE_CUDA_FLAGS "${CMAKE_CUDA_FLAGS} -Xcompiler=${OpenMP_CXX_FLAGS}")
    endif()
  endif()
endif()

I realize I may not have done the best job explaining the change, so I'm attaching a diff of my proposed change.
diff.txt

@sebastiangrimberg, all your suggestions sound good to me. Why don't you go ahead and add them to this PR directly, if you don't mind?
I think the STRUMPACK headers actually work fine with just C++11 but I think STRUMPACK is being compiled with C++14 in recent versions, so bumping to C++14 seems reasonable, even though it does not seem to be strictly necessary at the moment.

Merged in next for testing...

Re-merged in next for testing...

One of the commits never made it in next (9a7f764a). Merge master in next?

One of the commits never made it in next (https://github.com/mfem/mfem/commit/9a7f764ac78ab23c51d30659d913f7080ae16b4a)

Sorry, I dropped the ball on this one.

Merge master in next?

Yes. I can do that if you want.

Merge master in next?

Yes. I can do that if you want.

Go for it.

Done


Newsletters: add 279 (2023-11-29)

[x] Lede, update releases/RCs, topic entries @harding
[x] Bitcoin SE @bitschmidty
[x] Rust Bitcoin 2213 @murchandamus

Took a couple of @LarryRuane's suggestions, squashed, and merged!
Thank you @harding and @murchandamus for authoring and @glozow @murchandamus @vostrnad @LarryRuane for the review! 🚀


fix: [M3-6001] - Fix notification menu displaying empty menu on secondary status click

Description 📝
What does this PR do?
Currently, when a linode has a secondary status (e.g. snapshot, migrating), clicking on the status opens up an empty notification menu. This happens on the entity detail page as well as the landing page. This PR fixes the above behavior so clicking on a status opens the notification menu with visible menu contents.
Bug Cause  🐛
Relying on two different booleans for the menu opening, one within notificationContext and the other based on whether the Menu isExpanded. Since the NotificationButton and NotificationMenu did not know about context, the menu was not actually considered open on secondary status click to render its contents.
Bug Fix ✅
Rather than rely on isExpanded, the visibility of the NotificationMenu is now toggled based on the value of notificationContext.menuOpen.
Notes:

This PR also refactors the notification menu from the ReachUI Menu components to MUI v5 Menu components. This allowed us to remove some workaround code like the handleAnyClick function, which was causing difficulties when trying to implement this fix with the Reach UI menu.
I removed the Storybook story for NotificationMenu, as it was somehow broken and not showing up in Storybook anyway. If the team prefers, I can create a follow up ticket for adding a story for the updated NotificationMenu component.

TODO:

[x] Fix menu failing to scroll when there are many events and menu not staying at the top of the screen -- this is a positioning/overflow issue and fixing one has resulted in causing the other
[ ] Fix failing unit test somehow caused by changes to Button.tsx

Preview 📷
🐛  Prod:
https://user-images.githubusercontent.com/114685994/226739521-8a4635e7-0cae-4d61-b25c-40146b773b06.mov
✅  Fix:
https://user-images.githubusercontent.com/114685994/226739544-0c742610-0c25-4c62-b3bd-340b4d0840d6.mov
How to test 🧪
What are the steps to reproduce the issue or verify the changes?
Test menu opening/closing:

Kick off a process with a secondary status like migrating or taking a backup of a linode. Powering off/on a linode also works, but you have to be quick.
Wait for that process to start and then click on the secondary status of that linode from the linode landing page.
Observe that the notification menu opens and displays contents.
View the linode details page of that same linode and click on the secondary status.
Observe that the notification menu opens and displays contents.
Click the notification button (bell icon) to open the notification menu and click the icon again to close it. Confirm that behavior has not changed from prod.
Use the keyboard to navigate to the bell icon and test opening the drawer via both Enter and Space (use Esc to close). Confirm that behavior has not changed from prod.
Test all the various ways to open and close the notification menu in succession and make sure that menu responds as expected.
Check that the notification icon badge is visible/hidden as expected when events are viewed.

Test the notification events view:

Notifications but a few (<5) events (turn on mocks)
No notifications and no events (comment out code inside of serverHandlers.ts)

Check for UI consistency:

Test smaller screen sizes to make sure there are no regressions from prod.
Check that notification menu button styling and notification menu styling look the same as prod.
Check that when the menu is open and the page scrolls, the menu stays in place at the top of the screen (no fixed position).
Check that when number of notifications/events exceeds the max menu height (turn on MSW and expand the notifications), the user can scroll in the menu. (TODO: fix)

How do I run relevant unit or e2e tests?
yarn cy:run -s "cypress/e2e/notificationsAndEvents/notifications.spec.ts"

Broke when modifying Button.tsx:
yarn test LinodePowerControl.test.tsx

This may be out of the scope of this PR, but can we make these links not cause the page to completely reload?

@bnussman-akamai I'm going to consider this out of scope for this PR, but I did submit it to our internal feedback form so we can look at addressing this in the future.


Model Theft - Security

From what I have read there is currently nothing build-in to prevent or AT LEAST make it more difficult to just steal the model.
Since quantizied TFlite models are already hard to train since weaker mobile phones require smaller models (and thus training with even bigger datasets to make them accurately enough) and people invest lots of time in development of models one should not be able to just copy the tflite file from the assets.
I know Google states on its page that model theft is "typically" not a big problem because the model alone without the other features and usage of the app make it less valuable but just think of a competitor which just lacks a compute vision feature another company has provided in its app via Flutter-Tflite.
Why not adding a way to load an encrypted model and providing it the private key just-in-time? That would be a great start.
When Flutter-Tflite one day will provide more security features to make it more tricky to just steal expensively trained models TF-Lite Adoption in Flutter would become a really cool thing!
Is anything like that planned? I cannot imagine I am the only one thinking about this.

From what I have read there is currently nothing build-in to prevent or AT LEAST make it more difficult to just steal the model.
Since quantizied TFlite models are already hard to train since weaker mobile phones require smaller models (and thus training with even bigger datasets to make them accurately enough) and people invest lots of time in development of models one should not be able to just copy the tflite file from the assets.
I know Google states on its page that model theft is "typically" not a big problem because the model alone without the other features and usage of the app make it less valuable but just think of a competitor which just lacks a compute vision feature another company has provided in its app via Flutter-Tflite.
Why not adding a way to load an encrypted model and providing it the private key just-in-time? That would be a great start. When Flutter-Tflite one day will provide more security features to make it more tricky to just steal expensively trained models TF-Lite Adoption in Flutter would become a really cool thing!
Is anything like that planned? I cannot imagine I am the only one thinking about this.

How did you make that model, did you take all those pictures, made all those images? Did you pay all those photographers or did you just get everything for free to make the model. My friend, this is a function that should be available to everyone and provided for free just like those images you got on the web. There are thousands of models out there for free anyway.

@PaulTR Thanks for replying. I understand. If I find time this year I will build this and contribute!
@Megatronicus I am not sure if I got you correctly. Yes I am taking pictures myself and also paying others to create a dataset and dont wish competitors of mine to get that for free. Yes there are thousands of free models (trained on public datasets) sure but way more are not public because creating annotations and training to realize a custom use-case can cost a fortune.

In that case I understand. Simple solution, put a watermark of your company logo in the layer above the image or video while it's scanning. That way even if someone does take it, it will still advertise your company.

@Megatronicus Yes thats an idea and I will do this of course. Still creating a fail prove watermark is incredibly difficult. I would like to use multiple security layers like Watermark plus Model Encryption plus Obfuscation. 100% Security is never guaranteed though. :)

Closing this issue out since it's more of a higher level TensorFlow issue than one specific to this plugin. Will keep an eye out for the PR though! I also sent the request up to eng.


Make recentMatches and matches return the same result?

Currently /recentMatches and /matches are almost the same. Is it possible to make them return the same JSON structure? Is there any reason for why they're different in the first place? They both return matches afterall.
Specifically I would like lane info to also appear in /matches/ and not only in /recentMatches.

I guess these endpoints could have been combined. The original goal was to make an endpoint that always returned a maximum of 20 matches and did not support any filtering for performance reasons.
If you're looking to make matches return any field though, you can use the project query param to specify that field (i believe this is in the docs)

I see, thanks. Does it say anywhere which fields are possible to project? And what is the syntax to project multiple fields?

You can project fields that appear in: https://github.com/odota/core/blob/master/sql/create_tables.cql#L124

Thanks, this helps a lot.
I wasn't able to find this in the docs, maybe you should consider adding it (or, if it's already there and I'm missing it - make it easier to find)


fix: fix cargo audit

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Fix CI failure due to
    Scanning Cargo.lock for vulnerabilities (970 crate dependencies)
Crate:     rsa
Version:   0.9.2
Title:     Marvin Attack: potential key recovery through timing sidechannels
Date:      2023-11-22
ID:        RUSTSEC-2023-0071
URL:       https://rustsec.org/advisories/RUSTSEC-2023-0071
Severity:  7.4 (high)
Solution:  No fixed upgrade is available!
Dependency tree:
....
error: 1 vulnerability found!
warning: 3 allowed warnings found

This is caused by advisory database we used added this new vulnerability yesterday.
https://github.com/rustsec/advisory-db/pulls?q=is%3Apr+is%3Aclosed+RUSTSEC-2023-0071+
Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

Oops. Conflicted with https://github.com/risingwavelabs/risingwave/pull/13704 but it seems better to maintain such list in the config file.

Included in https://github.com/risingwavelabs/risingwave/pull/13719


[WIP] Update/react lifecycle methods

This PR will be merged as is, thought there are still two remaining instances of componentWillReceiveProps. These will be addressed later with a breaking change


Runtime: Azure Functions support

Preview version of azure functions support. Runtime changes done as part of https://github.com/microsoft/BotFramework-Composer/issues/2471 allowed for code reuse and integration with azure functions.
This issue is to allow a first, simple integration based on allowing deployment to Functions of the current assets.

https://github.com/microsoft/BotFramework-Composer/pull/2923


pip install fail

Hi,
pip install failed with no matching installer found. As instructed I built from source with:
CUDA_VERSION=121 make cuda12x
and then ran the python -m bitsandbytes command. I pasted the output below.
I was wondering if cu 12.1 wa snot the issue as it is not listed on the git repo (but 120 is repetaed which may be a typo for 121). I tried to isntall on a container with cuda 12.0 and pip failed too.
-------------------------- output for python -m bitsandbytes ---------------------------
CUDA SETUP: Defaulting to libbitsandbytes_cpu.so...
================================================ERROR=====================================
CUDA SETUP: CUDA detection failed! Possible reasons:

You need to manually override the PyTorch CUDA version. Please see: "https://github.com/TimDettmers/bitsandbytes/blob/main/how_to_use_nonpytorch_cuda.md
CUDA driver not installed
CUDA not installed
You have multiple conflicting CUDA libraries
Required library not pre-compiled for this bitsandbytes release!
CUDA SETUP: If you compiled from source, try again with make CUDA_VERSION=DETECTED_CUDA_VERSION for example, make CUDA_VERSION=113.
CUDA SETUP: The CUDA version for the compile might depend on your conda install. Inspect CUDA version via conda list | grep cuda.
================================================================================

CUDA SETUP: Something unexpected happened. Please compile from source:
git clone https://github.com/TimDettmers/bitsandbytes.git
cd bitsandbytes
CUDA_VERSION=121_nomatmul
python setup.py install
CUDA SETUP: Setup Failed!
Traceback (most recent call last):
File "/usr/lib/python3.10/runpy.py", line 187, in _run_module_as_main
mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
File "/usr/lib/python3.10/runpy.py", line 146, in _get_module_details
return _get_module_details(pkg_main_name, error)
File "/usr/lib/python3.10/runpy.py", line 110, in _get_module_details
import(pkg_name)
File "/cpmp/LLM_Exam/bitsandbytes/bitsandbytes/init.py", line 6, in
from . import cuda_setup, utils, research
File "/cpmp/LLM_Exam/bitsandbytes/bitsandbytes/research/init.py", line 1, in
from . import nn
File "/cpmp/LLM_Exam/bitsandbytes/bitsandbytes/research/nn/init.py", line 1, in
from .modules import LinearFP8Mixed, LinearFP8Global
File "/cpmp/LLM_Exam/bitsandbytes/bitsandbytes/research/nn/modules.py", line 8, in
from bitsandbytes.optim import GlobalOptimManager
File "/cpmp/LLM_Exam/bitsandbytes/bitsandbytes/optim/init.py", line 6, in
from bitsandbytes.cextension import COMPILED_WITH_CUDA
File "/cpmp/LLM_Exam/bitsandbytes/bitsandbytes/cextension.py", line 20, in
raise RuntimeError('''
RuntimeError:
CUDA Setup failed despite GPU being available. Please run the following command to get more information:
    python -m bitsandbytes

    Inspect the output of the command and see if you can locate CUDA libraries. You might need to add them
    to your LD_LIBRARY_PATH. If you suspect a bug, please take the information from python -m bitsandbytes
    and open an issue at: https://github.com/TimDettmers/bitsandbytes/issues

root@5022776:/cpmp/LLM_Exam/bitsandbytes#

I had a typo in the pip command...
It runs fine now.
Not sure why the compile fomr source doe snot work, but it is not an issue for me, hence I'm closing the issue.


Bug Report: Scroll and Width Issues in Overview

Bug Report: Scroll and Width Issues in Overview
Description:
There are two main issues with the overview page:

Scroll Bug: Users can scroll the page when the overview is open, which should not be possible.
Width Issue: The overview does not extend to 100% width of the container, leaving a small gap on the right side.

Steps to Reproduce:

Scroll Bug:

Open the Pokedex-v2 app.
Navigate to the overview page of any Pokémon.
Try scrolling the page when the overview is open.

Width Issue:

Open the Pokedex-v2 app.
Navigate to the overview page of any Pokémon.
Observe that the overview does not fill the entire width of the container, leaving a small gap on the right.

Expected Behavior:

Scroll Bug:

The Mainpage should not be scrollable when the Overview is open. It should be fixed in place to prevent scrolling.

Width Issue:

The overview should extend to 100% of the container width with no gaps on the right side.

Actual Behavior:

Scroll Bug:

The user is able to scroll the overview page even when it should be fixed.

Width Issue:

There is a small gap on the right side of the overview, and it does not extend to the full width of the container.

Tested On:

Scroll Bug:

iOS Safari
iOS Chrome

Width Issue:

iOS Safari
iOS Chrome
Chrome
Edge
Firefox

Possible Cause:

The scroll issue may be related to CSS properties or overflow settings.
The width issue may be caused by margin, padding, or box-sizing CSS properties not being set correctly.

Follow-Up: Issues Resolved
Description:
The following issues have been resolved:

Scroll Bug: The overview page no longer allows scrolling when it should be fixed in place.
Width Issue: The overview now extends to 100% of the container width with no gaps on the right side.

Commit Reference:

Commit ea8c4c9 addresses both issues.

Testing Details:

Verified that scrolling is disabled when the overview is open.
Confirmed that the overview extends to the full width of the container on all tested browsers (iOS Safari, iOS Chrome, Chrome, Edge, Firefox).

Additional Notes:

If any further issues arise or additional adjustments are needed, please let me know!


Removing basic username/password auth from app

Coverage remained the same at 94.44% when pulling 856911691bc3080529d851990ce59e6b7084baaf on 75-remove-basic-auth into 86c58d24837ec782c2cc3b16515ca62fcea172ae on master.

:shipit:


Fix #5738 wrong selection on mouse click

The Crash looks partially resolved before this fix - it doesn't crash anymore.
But the wrong selection leads to wrong behaviour on backspace command and doesn't delete hr correctly if we try delete from the wrong selection state

Fix: Fix the wrong selection Resolved state due to Block Cursor element
closes #5738
Before ( delete command doesn't delete hr element)
https://github.com/facebook/lexical/assets/163521239/4534123b-fc24-4508-ad60-89b8c8262e62
After ( delete command deletes hr element correctly )
https://github.com/facebook/lexical/assets/163521239/6f072f90-cd1b-4e10-98bd-30de22aa5093

LGTM! You may want to update the description and add some test if possible

Lemme add the tests in a separate PR since this is already approved.


Using kibosh in production systems?

As a PCF operator I've had a growing number of teams come to me who are interested in getting PKS clusters just so they can run data services on kubernetes (neo4j, solr) and consume it in PAS. Most of these teams don't want (or should have) the responsibility of maintaining their own kubernetes cluster. My team has lead time to make a decision, but we're going to have to decide how we want to handle this.
I think kibosh could be a great solution for us. With that said:

What are the long-term goals of this project? Is it at risk of going away anytime soon?
Will this ever become an "official" Pivotal product where the bazaar tile is released on pivnet?
Should I be concerned about the frequency of releases and little release notes? (Sorry I genuinely don't mean that as a dig or anything)
In your own opinion, how closely do you respect semantic versioning? E.g., should I be worried about minor or patch versions breaking things?
In general, in your own opinion, with this being a totally non-binding, no-expectations question, with the current state of kibosh, do you think it could be a good idea to use kibosh in production with a small number of data services?

I appreciate any feedback 👍

With respect to frequency of releases & semantic versioning:
We currently have a pipelines that are taking every commit and bundling things into a Github release with a new patch version number, assuming they pass CI installing the BOSH release and building the integration tests.
We're bumping the minor component when we do a breaking change. It's early yet. We didn't want to release a 1.0, since that carries a bit of semantic meaning. So we're kind of treading patch like minor and minor like major.

Thanks for getting back to me on this, I appreciate it 👌


Implement API for populating context

All required layers for populating was prepared and now is important to implement populating context which represents the core of whole objects population.

API for poulating contexts was fully implemented. There is missing implementation of DependencyGraph and their usage but it will be done in separated issue.


data recovery from fram it-02

Name/Affiliation/Title
Kshitij Patil, no affiliation, VJTI Mumbai.
Purpose of the PR
To recover data from fram after power cut, This is not the complete solution as unit tests for fifo.c were not successful. This is just an approach i tried to solve this probelm.
Development Environment
OS: Windows 11, VS Code, Platformio version 3.3.3, Python 3.11.8
Test Procedure
Running the test_fifo.c and test_fram,c to check whether all the unit tests pass or not.
Additional Context

Unit tests written in test_fram.c were passed successfully.

Closing since implemented by #142


 A naive first thought implementation might be to output the <xbar.var> metadata as part of the plugin output. Have the parser expect those lines at the start of the output, parse them out, and set them up as variables. Tricky part would be how to then inject those variables into the already running plugin... API way for the plugin to grab the config JSON itself?

Would it be possible to just look to see if there is a .vars.json and use that to identify both the possible vars and the set value for all complied plugins? I've made a rust based plugin and would love to have the ability to use variables. If you just allowed the json without the need for the commented xbar.var tags in the code it would cover all complied plugins.

That's a neat idea. Would that be relative to the plugin?

Have read over the proposal a few times and want to see if my understanding of the flow lines up. It sounds like the flow would be:

You install the plugin, effectively enabling it.
The plugin itself would write out its configuration file with the environment variables with potential default values in it.
The xbar UI would both try to parse the script for variable metadata but also look for a configuration file for possible variables to present in the plugin browser.

If have the above correct, I think the main trade off to consider is the JSON isn't very descriptive. { "VAR_NAME": "BOB" } doesn't provide all the options the current metadata format allows -- descriptions, restricting a variable to set of values, etc. The plugin browser UI could read that in if present and no other metadata is found, but it wouldn't make for an ideal experience to a user trying to configure the plugin.
It also places a small burden on the plugin author to manage that initial startup of their plugin. "Is the config file there? No... write it out". xbar could provide some environment variables to help with that -- path, filename, etc. Still leaves the plugin author with a code path that wouldn't otherwise have to maintain.
Overall, I think I've encountered only one other plugin wanting to be compiled rather than interpreted. I'm likely an edge case. I'm also maintaining my own configuration file for my plugin already, where what I want to configure doesn't fit neatly into the xbar system.
I have larger ideas around plugins, metadata, and such, but I'm still thinking through the implications to xbar and the ecosystem before I present them. Probably worth just closing this out at this point.

I get the limitation of json. You could still do something like have a file like .plugin.5m.bin.vars file or something that was just a text file with the existing format for scripts/interpreted plugins and leave the json as is.
I also don't think you'd have to have the plugin emit the file. It could be packaged as part of the plugin install.
But I also understand that you might have other plans where this wouldn't fit.

Trying to be more pedantic for my proposal.
A complied plugin could optionally include a file that has all of the <xbar.var> stuff next to it in the plugin direction with a '.' pre-pended and a .vars post-pended to the plugin's original filename.
You could also optionally have plugins implement a specific flag that would output that file to stdout for xbar to run on install (creating the .plugin-filename.var file.
vars would be read from this dotfile and function just like they do in scripts.
xbar would use the .json files just like it does with scripts.
This would allow complied plugins to use the vars and have them passed into the plugin via the environment xbar executes them within.


Enhance the LSP server to support text document synchronization

Enhance the LSP server to support text document synchronization, so that other LSP features that depend on inter-file dependencies can be developed. The LSP server needs to not only synchronize with the client's text documents, but it also needs to manage a language context that incorporates those AaC text files.
AC:

[ ] The LSP server registers for text document synchronization
[ ] The text synchronization kind is defined as full text
[ ] When a new AaC file is opened, its contents are parsed and added to the active context
[ ] When an AaC file is updated by a save action

[ ] If the new file content is valid yaml content

[ ] Any altered definition is removed from the active context
[ ] Any altered text definition is parsed and added to the active context

Rolling to HIP 2022.1

Update the AC with issues that correctly to AC items that can't currently be completed.


Issue #1682 fix.

Fixes #1682 . Initial Commit. Not Yet Ready to Review.

@dwightguth @bmmoore @radumereuta Please Review.

looks okay but I'd prefer to see this change as part of a fix that can be tested by testing SIMPLE. Without that I don't really know for sure that this isn't going to break stuff.

Looks like an improvement, but why did you change lessThan to lessThanEq?

If you don't have a good reason, I'd rather not change the function.
For Dwight's request, rather than waiting any longer, how about testing that this doesn't break the other definitions which have been successfully translated to kore, currently IMP, IMP++, and lambda++.

@bmmoore I guess that IMP++ will fail on the current master for the sort lattice issue. The failure has not been seen, because ktest is disabled with those translated languages. Let me make a pull request to make ktest work with the new kore unparser output, so that we can see master doesn't break the translated languages as well.

You should add some regression tests with examples from the list parsing bug.

This breaks a few test cases, and isn't the right place to fix list terminators. I'm making a new pull request for this.


How can I achieve Mobile Emulation mode using Kite ?

Hi,
Could you please suggest me how can I achieve Mobile Emulation mode using Kite? I already tried in multiple ways but it seems no use and there is no inbuilt method in Kite for using Mobile Emulation mode.
Please find the below screenshot for your reference

Thank You,
Kavya Setty.

Hi,
We haven't implemented this because there hasn't been need for it.
However I just tried the example here : https://chromedriver.chromium.org/mobile-emulation

Is this the result you want?

Hi,
I used the same code which you have used but still browser is opening in normal way.
you are keeping the code in WebDriverFactory.java only?

Those were the only 3 lines I added.
I'm not sure if it changes anything, but I tested it only with chrome canary (v. 84).

Even I also used the same code in WebDriverFactory.java but still for me it is not changing into mobile emulation mode.
And I am testing in Chrome Browser  81.0.4044.138  version.

I have the same result with chrome 81

Are you using only the 3 new lines I added?

Now its working for me too. Yeah I am using the same code only.
I updated Kite and kept those 3 lines and its working for me
Thank You for your support!!

Np :)


fix: 修复exchange-time在select下没生效的问题

Types of changes
range-picker 文件下补全了对于exchange-time属性的判断逻辑

[ ] New feature
[x] Bug fix
[ ] Enhancement
[ ] Component style change
[ ] Typescript definition change
[ ] Documentation change
[ ] Coding style change
[ ] Refactoring
[ ] Test cases
[ ] Continuous integration
[ ] Breaking change
[ ] Others

Background and context
时间会错乱的问题
1850

Solution

How is the change tested?

Changelog

Component
Changelog(CN)
Changelog(EN)
Related issues

date-picker
修复 exchange-time 在选择时失效的问题
Fix the problem that exchange-time fails when selecting
Close #1850

Checklist:

[ ] Test suite passes (npm run test)
[ ] Provide changelog for relevant changes (e.g. bug fixes and new features) if applicable.
[ ] Changes are submitted to the appropriate branch (e.g. features should be submitted to feature branch and others
should be submitted to main branch)

Other information

这个问题依然存在哦~，我固定版本2.45.0，问题也依然存在。

这个问题依然存在哦~，我固定版本2.45.0，问题也依然存在。
添加 :exchange-time="false" 属性

已解决，谢谢大佬。


Enhancement: Implement Issue and PR Templates for a Neat workflow

As this project grows and more contributors join the team, it becomes crucial to establish a standardized workflow that ensures organization and systematic collaboration. By implementing dedicated issue and pull request (PR) templates, we can streamline the process and enhance efficiency.

+1

@shadcn

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.


Mobile Responsive

Ensure that the site is responsive

Using css, making the whole site responsive to any size


Use adonis-throttle as global middleware

Hello. Please add the feature to use adonis-throttle as global middleware and config file to define the necessary params. Thank you.

Hi @1001v
Can you elaborate on that?
Thanks!
Ron


Use Variables for simplify edits and enhance readability.

Ⅰ. Describe what this PR does
Refactor Makefile as part of #4297: use variables and rearrange for better readability and easier maintenance.
Ⅱ. Does this pull request fix one issue?

Part of  #4297
Ⅲ. List the added test cases (unit test/integration test) if any, please explain if no tests are needed.
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

@Syspretor, if valid Ill work on number 2 ( Phony Targets )

@omerap12 Thank you very much for this PR. The classification and organization of variable definitions is great, but there are some areas where we hope to improve. First of all, ensuring that all modules in the Makefile execute successfully is a priority in the optimization work for the Makefile. During my testing, I found some typos and syntax issues that broke this, such as the variable definition for DOCKER_PLATFORM on line 28, and a typo regarding the -f flag on line 231, among similar issues. So please try running the commands included in the Makefile to ensure they still work smoothly.

@omerap12 Thank you very much for this PR. The classification and organization of variable definitions is great, but there are some areas where we hope to improve. First of all, ensuring that all modules in the Makefile execute successfully is a priority in the optimization work for the Makefile. During my testing, I found some typos and syntax issues that broke this, such as the variable definition for DOCKER_PLATFORM on line 28, and a typo regarding the -f flag on line 231, among similar issues. So please try running the commands included in the Makefile to ensure they still work smoothly.

Got it. Ill test it myself then. Thanks for your review :)

@omerap12 I made some minor changes to make Github Actions work with the latest Makefile. The PR LGTM, thanks for making it much more clear. /lgtm

No worries, I’m planning to enhance it further :)


Lazy-loading fails when microfrontend port is hosted on different port

Lets say I'm hosting shell app on port 5500. And my app main bundle is available on port 4200. When a module  is lazy loaded (for app on port 4200), network request goes on Port 5500 instead of port 4200. Hence it fails as 404. Any suggestions on how to handle it ?

Yep, this is something missing from coexisting-angular-microfrontends. The solution is dynamic webpack public path. The easiest way is to use systemjs-webpack-interop to set the public path.
Would you be interested in creating a PR that adds systemjs-webpack-interop to each of the applications in this coexisting-angular-microfrontends repo?

Sure, I'll give it a try.


@react-native-community/eslint-config typescript 4.5 support

Description
@react-native-community/eslint-config has eslint-plugin-flowtype as dep which doesnt support typescript 4.5
Version
0.66.3
Output of npx react-native info
System:
OS: macOS 11.6
CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
Memory: 205.30 MB / 16.00 GB
Shell: 5.8 - /bin/zsh
Binaries:
Node: 14.18.1 - ~/.nvm/versions/node/v14.18.1/bin/node
Yarn: 1.22.17 - ~/.nvm/versions/node/v14.18.1/bin/yarn
npm: 6.14.15 - ~/.nvm/versions/node/v14.18.1/bin/npm
Watchman: Not Found
Managers:
CocoaPods: 1.11.2 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: iOS 14.2, DriverKit 20.0, macOS 11.0, tvOS 14.2, watchOS 7.1
Android SDK: Not Found
IDEs:
Android Studio: 2020.3 AI-203.7717.56.2031.7784292
Xcode: 12.2/12B45b - /usr/bin/xcodebuild
Languages:
Java: 11.0.7 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 17.0.2 => 17.0.2
react-native: 0.66.3 => 0.66.3
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found
Steps to reproduce
yarn add --dev eslint prettier @react-native-community/eslint-config

yarn run lint

Snack, code example, screenshot, or link to a repository
No response

I have a PR fixing this
#32800

Closing as this has been solved by https://github.com/facebook/react-native/pull/32800 and later issues


CORS Access-Control-Allow-Headers don't get set from 'allowHeaders[]' entries

Hi there!
It seems that the Header Types in the cors config don't get set from the allowHeaders array for Access-Control-Allow-Headers.
in cors.ts line 82-85 only the Header.AccessControlRequestHeaders get set and not Header.AccessControlAllowHeaders.
Therefore Headers like Content-Type on the Response Headers don't get recognized and the request gets blocked.
Maybe you could add
resp.headers.set(
  Header.AccessControlAllowHeaders,
  config.allowHeaders.join(",")
);

to the if-block starting in line 81.
If there is something I am missing in my cors config that fixes the problem, please let me know!
Have a nice weekend!

@Schoude Oops, my bad. And thanks for pointing it out.

@zhmushan No problem. Looking forward to v1.0.0.

Fixed in https://github.com/zhmushan/abc/commit/b8254950350555ff28279cc9798375e66fe49e1e


Added the left shift operator as the left contraction to match the ma…

…jority of existing implementations
This is a change of underlying operators and so might break things but I think it makes a lot more sense and matches clifford syntax to many other existing GA implementations

Pull Request Test Coverage Report for Build 221

2 of 3 (66.67%)  changed or added relevant lines in 1 file are covered.
13 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.1%) to 46.891%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

clifford/init.py
2
3
66.67%

Files with Coverage Reduction
New Missed Lines
%

clifford/tools/g3c/model_matching.py
1
37.32%

clifford/init.py
12
67.29%

Totals

Change from base Build 219:
-0.1%

Covered Lines:
1493

Relevant Lines:
3184

💛  - Coveralls


Song can't be deleted

Describe the bug
When i was playing a song, I decided to delete it and I tapped on the song to locate the delete icon. I then clicked on the delete icon and there was a pop up ordering me to drop the selected song to trash can, which I did by clicking on Sure, but the song wasn't deleted.
To Reproduce

Launch the app
Play the song you want to delete/ It will reflect below the app
Tap on it and look up on the app by the right side. You will see the delete icon
Click on it and click on sure
The song will keep playing and if you proceed to check whether it was deleted, you will still find it in the music list.

Expected behavior
After deleting the song, I expected it to stop playing and be totally deleted from the music list
Reproducing the behaviour
https://youtu.be/YZMAtub_avo
Smartphone (please complete the following information):

Device: [TECNO SPARK K7]
OS: [ANDROID 7.0]
Version [V.2.6.2]

Still cant delete song in the new version.

Still cant delete song in the new version.

Sorry, I have not fixed this issue yet. This bug is my next goal.

Alright. Good job

fixed, We will release the next version

try new version


A g:fzf_launcher possibly resulting in a more nicely-looking window

The following comes from my .vimrc and it works well for me. Note that I had never used xterm before installing fzf—I even didn’t know that it was installed on my system! So there is a risk that the following might conflict with a user’s xterm configuration. I don’t know.
let font = split(getfontname(), ' ')
let font_family = join(font[:-2], ' ')
let font_size = font[-1]
let bg = synIDattr(hlID("Normal"), "bg")
let fg = synIDattr(hlID("Normal"), "fg")
let g:fzf_launcher = 'xterm -T fzf'
    \ .' -bg "\'.bg.'" -fg "\'.fg.'"'
    \ .' -fa "'.font_family.'" -fs '.font_size
    \ .' -e bash -ic %s'

Sets the title to “fzf” instead of “bash”.
Uses the same background and foreground colors as your vim theme. (Default for me was black text on white background.)
Uses the same font family and font size as is used in vim. (On my system, by default xterm tries to load some non-existing font and falls back on a super ugly one, and the default font size is a bit too small to be useful.)

Even better, if this could be interpolated before each run we’d get a nice placement of it too (and if you change theme or font during the session that will be reflected as well):
    \ .' -geometry '.&columns.'x'.&lines/2.'+'.getwinposx().'+'.getwinposy()

Do you think any of this could be used by default in fzf? Since it is all very general and just mimics the user’s own vim customizations I think it could work out.
If not, I’d like to ask for support to pass a function to fzf to produce the launcher command. Then I’ll also add this to the wiki.
Edit: Here’s a more readable version:
let font = split(getfontname(), ' ')
let g:fzf_launcher = printf('xterm -T fzf'
      \ .' -bg "\%s" -fg "\%s"'
      \ .' -fa "%s" -fs %d'
      \ .' -geometry %dx%d+%d+%d -e bash -ic %%s',
      \ synIDattr(hlID("Normal"), "bg"), synIDattr(hlID("Normal"), "fg"),
      \ join(font[:-2], ' '), font[-1],
      \ &columns, &lines/2, getwinposx(), getwinposy())

Thanks, that looks pretty cool. Actually since I'm always on terminal, I haven't been able to pay enough attention to this "launcher" thing.
I tried your solution on MacVim and noticed that I had to change it a little to extract the right font size as on MacVim getfontname() returns something like Menlo Regular:h11. So I had to split it with [: ] and strip h from the last part. And even when the number is correctly extracted, the font on xterm looks larger than that on MacVim. I don't know why but since I don't use GVim, I didn't further look into it :)
Although I like what you did here, providing the right default that works on different platforms is a hard thing to do, so I think we should just allow function references as launcher option and put you solution on the wiki page.
However, there's an annoying issue with Funcrefs as g:fzf_launcher.
function! Foo()
  " ...
  return 'xxx'
endfunction
let g:fzf_launcher = function('Foo')

And we get E704: Funcref variable name must start with a capital: g:fzf_launcher. So we may have to add another variable g:Fzf_launcher. (We can pass a funcref directly to fzf#run() function as in call fzf#run({'launcher': function('Foo')}), but then we'll have to pass it to every call to fzf#run().) I'll let you know of the progress.
By the way, did you find a way to refocus Vim window after fzf is closed? On OS X, it is possible with AppleScript (a nice trick by @gleachkr), but I'm not sure if there's a similar trick that works on different platforms.

You can use g:Fzf_launcher now.

I had to change it a little to extract the right font size as on MacVim getfontname() returns something like Menlo Regular:h11. So I had to split it with [: ] and strip h from the last part.

:help getfontname() says that the function in question returns the font used by the hl-Normal highlighting group. :help highlight-font tells that this is platform dependent and that it is potentially very difficult to parse on X11.
Moreover, it seems like as long as I include -fa "$x" where $x is anything but the empty string, the system default monospace font is used, which is also the font I use in gvim. So that just happened to work for me.
There is also an -fn switch that seems to accept the name of a font family, but no matter what I pass in xterm always that it could not be found.

And even when the number is correctly extracted, the font on xterm looks larger than that on MacVim.

-fs 10 seems to work as expected for me though: A lower number makes the text smaller, and a larger number makes it bigger. -fs 10 makes it exactly the same size as in gvim. Don’t know why it didn’t work for you.

Although I like what you did here, providing the right default that works on different platforms is a hard thing to do, so I think we should just allow function references as launcher option and put you solution on the wiki page.

Yes, your tests in MacVim and the start of this comment clearly shows that—at least for the font stuff. But what about the -T fzf, the colors and the sizing?

-T fzf seems harmless, and actually helps when you have many terminal windows open.
Colors + sizing makes it feel like fzf was opened in a split at the top of vim, which many have requested.

In other words, I propose the following as a default g:Fzf_launcher:
function! Fzf_launcher()
  return printf('xterm -T fzf'
      \ .' -bg "\%s" -fg "\%s"'
      \ .' -geometry %dx%d+%d+%d -e bash -ic %%s',
      \ synIDattr(hlID("Normal"), "bg"), synIDattr(hlID("Normal"), "fg"),
      \ &columns, &lines/2, getwinposx(), getwinposy())
endfunction

When we have settled on this I’ll look into adding tips to the wiki.

By the way, did you find a way to refocus Vim window after fzf is closed?

On Ubuntu and Trisquel gvim is refocused automatically by default when fzf is closed.

You can use g:Fzf_launcher now.

Great! Thanks!

I updated the default launcher as you proposed. Thanks!


SICF: Remove special TADIR logic

Leveraging the new serializer interface. The change removes the special logic translating TADIR into ITEM for SICF and replaces it with an equivalent mapping between object and filenames.
The implementation of the serializer class is now much more straight forward. It's always using ms_item to refer to the object which is equivalent to the tadir entry like for other objects.
Ref #3453, #4187, #5064
Closes #6172
PS: Breaks zcl_abapgit_ci_repo (https://github.com/abapGit/CI/pull/228)

tested ok, no diffs


Dynamic version resolution behaves strangely with a base version and a qualifier

Current Behavior
Requesting a dynamic version of 1.21+ seems to prefer the version 1.21-12.0.0-RC1781 instead of the expected 1.21.1-12.0.0-RC1811. Debugging this seems to point to the StaticVersionComparator which seem to be used when sorting the list of available versions. This comparator documents that it only considers the parts of the version, and not the separators which are present in the version strings, so 1.1.1 == 1-1-1 == 1.1-1.
Our versioning is in the format of [Implementation Version]-[API Version].
The comparison now ends up looking like the following:

1.21-12.0.0-RC1781
1.21.1-12.0.0-RC1811
Result

1
1

21
21

12
1
We are comparing the major version of the API against the patch version of the implementation.

0
12

0
0

Expected Behavior
According to the documentation here the version resolution should separate the version to a base version and a qualifier. Respectively in this case I would expect the base version to be the 1.21 and the qualifier to being the 12.0.0-RC1781. In this case the version 1.21.1-12.0.0-RC1811 would correctly take the priority.
I would expect the comparison to first sort by the base version according to its rules:

1.21
1.21.1
Result

1
1

21
21

1
A version with an extra numeric part is considered higher than a version without (even when it’s zero).

Afterwards the qualifiers would be sorted with their corresponding parts:

12.0.0-RC1781
12.0.0-RC1811
Result

12
12
We are now comparing the second separator correctly with their respective version.

0
0

0
0

Context (optional)
We are filtering the versions by the API version first and then afterwards acquire the latest implementation of the said API.
Self-contained Reproducer Project
This can be easily preproduced with the following build.gradle.kts and running gradle dependencies.
repositories {
    maven(uri("https://repo.spongepowered.org/repository/maven-public/"))
}

dependencies {
    implementation("org.spongepowered:spongevanilla:1.21+")
}

Gradle version
8.10.2
Build scan URL (optional)
No response
Your Environment (optional)
No response

The issue is in the backlog of the relevant team and is prioritized by them.

Related:

https://github.com/gradle/gradle/issues/28805

I'm not sure we can support this directly.
Since 1.21 appears to be the Minecraft version, could you instead encode this in your group or artifact id?

We can certainly adjust the way we produce our artifacts if it comes to that, its just not retroactive.
The current behavior we are observing seems to go against the documentation. It states that the base version is compared first to discard any conflicting versions on the left. Shouldn't that also apply here as 1.21.1 is higher than 1.21?
If this isn't being consider as a bug, at least the documentation should be updated to reflect this or provide some clarifications on how the version resolution behaves.


Use .NET 8.0.100-rc.2

Remember to regenerate yaml by running build.cmd, 8 RTM is also tomorrow I believe 😉

Just running ./build.cmd does not change any files? Yeah I think we can also wait till tomorrow with that :-)


Hyperswarm topic security and peer filtering

related to #1:
We may decide to avoid S3 altogether, create a complimentary design with  many many cloud replicas for one corestore fronted by a Hyperswarm. Note that Bitfinex team worked with Hypercore on extending DHT to do filtering of peers before connecting to them


Pretrained Model

Hi,
How can I use this code just for inference only with your pretrained model/weights?

Hi, sorry I'm late, we were pretty busy. You can use the generate method of the avatar_generator_model class (https://github.com/IAmigos/avatar-image-generator/blob/f4f8c9809b2b6368849e5311b3629832016b298b/models/avatar_generator_model.py#L82) you have to specify the weights path in https://github.com/IAmigos/avatar-image-generator/blob/master/config.json. This works only for one image. Soon we will add a code to infer images that are in a folder. Let me know if this helps you.


Errors in compiling

Testing on gepard version <IP_ADDRESS>
gepard.zip
Severity	Code	Description	Project	File	Line	Suppression State Error	LNK2019	unresolved external symbol _main referenced in function "int __cdecl invoke_main(void)" (?invoke_main@@YAHXZ)	Gepard	C:\Users\w\Downloads\Gepard-master\MSVCRTD.lib(exe_main.obj)	1

This source is thought for learning purposes.

I've been on it for days and I still have no idea what I need to do. Can
you please give hints, or just say if it wont work for the current gepard?
On Sun, Apr 26, 2020 at 9:25 PM Hypercall<EMAIL_ADDRESS>wrote:

This source is thought for learning purposes.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Optcall/Gepard/issues/1#issuecomment-619549384, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACM7BPUMKF6IY7BSRCZZ5JLROQY47ANCNFSM4MRCZJYQ
.


[AVM Module Issue]: AKS Module should add output 'kubeletidentityClientId' and 'kubeletidentityResourceId'

Check for previous/existing GitHub issues

[X] I have checked for previous/existing GitHub issues

Issue Type?
Feature Request
Module Name
avm/res/container-service/managed-cluster
(Optional) Module Name if not listed above
avm/res/container-service/managed-cluster
(Optional) Module Version
No response
Description
Please add the output of the following two parameters:

kubeletidentityClientId: managedCluster.properties.identityProfile.kubeletidentity.clientId(The Client ID of the AKS identity).
kubeletidentityResourceId: managedCluster.properties.identityProfile.kubeletidentity.resourceId(The Resource ID of the AKS identity).

For example (azd): https://github.com/Azure/azure-dev/blob/main/templates/common/infra/bicep/core/host/aks-managed-cluster.bicep#L136
CC: @jongio
(Optional) Correlation Id
No response

Thanks for submitting this @Menghua1. I can work on adding this to the module soon

@JPEasier - Any questions about this? Do you have an ETA?

@jongio, @v-xuto,
from my side an update will come in may at the earliest, but i will check with @ilhaan and see what is possible.
if you need the feature very urgently, i welcome you to create a pull request.

@zedy-wj/@v-xuto, Can you please create a PR for this?

@jongio - We have done a PR for this issue.
PR link: https://github.com/Azure/bicep-registry-modules/pull/1464, please review it, thanks!


ActiveState.isActive issue

In ActiveState mixin (https://github.com/rackt/react-router/blob/master/docs/api/mixins/ActiveState.md) -
isActive function implementation currently checks truth for param and query values, but not their names. In my opinion, a param or query active means whether some value of those are available in the routes, that is given param or query have some valid values. As far as I think, most use cases for dynamic routes, require to check only the presence of the param or query, and not their values.
What's your opinion ?
If you see above as a valid issue, I can submit a fix for above. Please let me know.

I'm not sure I'm following completely, but sounds like you want to ignore param/query values in isActive? We don't want links to /users/123 and /users/234 to both be "active". Perhaps we've just named this poorly?
Trying to clean out the issues, and @gaearon has a great solution for checking if a route is active, I'm going to close, but I'll happily reopen with some noise :)


Set and Permit commands

Set command is for miscellaneous exit, room, and item settings. Permit command is similar, but for permissions.
Example: "permit room 3 enter 0" to prevent anyone except the owner from entering room 3.

I ended up doing this another way.


feat(sdk): custom plan change message support

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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 9.379%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
9560

Relevant Lines:
101934

💛  - Coveralls


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/26978

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/27070

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/27070

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/37139


Removing links to other obsidian notes in the output (PDF)

** removing markdown links**
your plugin is released with an awsome feature, the possibility in the settings to choose the way links will be processed.
When I use pandoc, the output contains links to other notes between brackets. I do not want these links to be active, but I would like the brackets to be removed as well. Do you know how this task is done in your plugin (which part of the command line is responsible for that?)
Regards,
Damien

by adding --from html --to pdf, one can convert a .md file from obsidian to a PDF. Every link to a side-note is converted into text.
the whole sequence is this one : pandoc 'document.md' --from html --to pdf --pdf-engine=xelatex --citeproc -f markdown+smart -o document.pdf
Please ignore my previous message.
Regards
Damien

All good, glad you've figured it out! This plugin actually works by converting the rendered HTML inside Obsidian to a PDF, rather than using the markdown file itself. That's why it's able to work (partially) with DataView and other plugins.


Kubernetes service discovery provider based on watch requests

New Feature
New "WatchKube" service discovery provider.
Kube api offers a 'watch' request for efficient detection of changes that can be used to keep in sync information about endpoints.
Motivation for New Feature
Ocelot currently has 'Kube' and 'PollKube' providers with tradeoffs: fetching endpoint per request with extra hop and pressure on kube api for 'Kube' strategy or possibly outdated endpoints info for 'PollKube'. Watch request looks like another option with changes coming more fast than polling and without extra hops/pressure.
I've already implemented custom service discovery provider based on KubernetesClient(not KubeClient) and solved this for myself, but it would be nice to have it out of the box.

Found that there was plans for extracting generic polling: https://github.com/ThreeMammals/Ocelot/issues/1708
Is it alive? Any chance that long polling mechanisms such as kube watch api or consul 'blocking queries' will be included?