Use  tags to register apps without using layout?

I need a recommendation:
One of the things I like about this demo project is how react-mf-root-config.js generates the app registration from the <route> tags in the layout template. I suppose this is hard-coding either way, but it strikes me as easier to read, and as others on my team are learning the ropes, I'm seeing that it makes more sense to anyone who is accustomed to this style of route declaration.
I'm trying to work out the best way to do the same thing without the use of layout, though. The off-the-shelf non-layout root-config project is pretty bare-bones.
Or alternately, maybe it makes more sense to use layout with a "flat" structure to take advantage of the construct methods, rather than re-inventing the wheel? I see that constructRoutes in layout is pretty involved...

single-spa-layout uses pathToActiveWhen to generate activity functions for the routes. Here's some documentation that might be helpful:
https://single-spa.js.org/docs/api#pathtoactivewhen
https://single-spa.js.org/docs/api#configuration-object
https://single-spa.js.org/docs/configuration#activity-function
We suggest using single-spa-layout, as there aren't really any downsides to doing so. Attempting to get the same functionality as single-spa-layout without using it will result in just a reimplementation of what already exists. However, if you'd like to so anyway, here is how you could:
When not using single-spa-layout, generally routes are defined per application. If you'd like the inverse (defining the applications for each route), you could try something like this. I'm writing this code withot
const routes = {
  "/": ["@org/navbar"]
  "/clients": ["@org/client-list", "@org/sidebar"],
}

registerApplication({
  name: "@org/navbar",
  app: () => System.import("@org/navbar"),
  activeWhen: routesToActiveWhen("@org/navbar")
})

registerApplication({
  name: "@org/client-list",
  app: () => System.import("@org/client-list"),
  activeWhen: routesToActiveWhen("@org/client-list")
})

registerApplication({
  name: "@org/sidebar",
  app: () => System.import("@org/sidebar"),
  activeWhen: routesToActiveWhen("@org/sidebar")
})

function routesToActiveWhen(appName) {
  return Object.keys(routes).filter(route => routes[route].includes(appName);
}

single-spa-layout uses pathToActiveWhen to generate activity functions for the routes. Here's some documentation that might be helpful:
https://single-spa.js.org/docs/api#pathtoactivewhen
https://single-spa.js.org/docs/api#configuration-object
https://single-spa.js.org/docs/configuration#activity-function
We suggest using single-spa-layout, as there aren't really any downsides to doing so. Attempting to get the same functionality as single-spa-layout without using it will result in just a reimplementation of what already exists. However, if you'd like to so anyway, here is how you could:
When not using single-spa-layout, generally routes are defined per application. If you'd like the inverse (defining the applications for each route), you could try something like this. I'm writing this code withot
const routes = {
  "/": ["@org/navbar"]
  "/clients": ["@org/client-list", "@org/sidebar"],
}

registerApplication({
  name: "@org/navbar",
  app: () => System.import("@org/navbar"),
  activeWhen: routesToActiveWhen("@org/navbar")
})

registerApplication({
  name: "@org/client-list",
  app: () => System.import("@org/client-list"),
  activeWhen: routesToActiveWhen("@org/client-list")
})

registerApplication({
  name: "@org/sidebar",
  app: () => System.import("@org/sidebar"),
  activeWhen: routesToActiveWhen("@org/sidebar")
})

function routesToActiveWhen(appName) {
  return Object.keys(routes).filter(route => routes[route].includes(appName);
}


CI: have a step that prevents regressions wrt passing tests

Once we have some tests passing, we don't want to lose them after some changes. Hence, it makes sense to introduce a CI step that prevents regressions, i.e. rejects a PR that makes some tests which were previously passing fail.

Considering, that currently some tests pass because of datastax driver code, I don't thing it's a good idea to add this (for now)

Considering, that currently some tests pass because of datastax driver code, I don't thing it's a good idea to add this (for now)

Agreed. Let's keep it in mind, though, to take advantage of regressions detection as soon as possible.

Ref: #43

@adespawn What's the status of this?

Coming back to that, I don't see how it would differ from ensuring there is green tick on GitHub actions status (aka. all tests have passed)
Either way, if I understand how GH works, this should be done as branch ruleset, as repo admin (and I don't have such permissions)

The way I understand our current approach to integration tests is that we only have those tests enabled that are expected to pass. So this is essentially resolved.


Docs related issues from Ark v0.10 Testing

[ ] This section has a reference to Config, which no longer exists https://github.com/heptio/ark/blob/master/docs/build-from-scratch.md#prerequisites-1
[ ] This section instructs to setup multiple backets, but should we instruct to use the prefix instead? https://github.com/heptio/ark/blob/master/docs/aws-config.md#create-iam-user

Fixed in PR #1004


consumer group can not stop refresh meta data after context canceled.

Description

consumer group can not stop refresh meta data after context canceled.
function func (c *consumerGroup) Consume(ctx context.Context, topics []string, handler ConsumerGroupHandler) error  in consumer_group.go file, after ctx's cancel function exec,  the function c.client.RefreshMetadata(topics...) in consumer_group.go file line 201, still working, can not stop.

Versions

Sarama
Kafka
Go

1.38.1
kafka_2.11-1.1.1
1.19

Configuration

Logs

logs: CLICK ME

Additional Context

the above happened when a broker is down

Hm… yeah. We even have the context available to plumb through that function. It seems that it’s relying on client.conf.Metadata.Timeout to provide a timeout/deadline rather than a context.WithDeadline or context.WithTimeout. It seems like plumbing a context through would even then simplify the deadline handling, since we wouldn’t have to do it all manually.


[SPARK-23004][SS] Ensure StateStore.commit is called only once in a streaming aggregation task

What changes were proposed in this pull request?
A structured streaming query with a streaming aggregation can throw the following error in rare cases.
java.lang.IllegalStateException: Cannot commit after already committed or aborted
	at org.apache.spark.sql.execution.streaming.state.HDFSBackedStateStoreProvider.org$apache$spark$sql$execution$streaming$state$HDFSBackedStateStoreProvider$$verify(HDFSBackedStateStoreProvider.scala:643)
	at org.apache.spark.sql.execution.streaming.state.HDFSBackedStateStoreProvider$HDFSBackedStateStore.commit(HDFSBackedStateStoreProvider.scala:135)
	at org.apache.spark.sql.execution.streaming.StateStoreSaveExec$$anonfun$doExecute$3$$anon$2$$anonfun$hasNext$2.apply$mcV$sp(statefulOperators.scala:359)
	at org.apache.spark.sql.execution.streaming.StateStoreWriter$class.timeTakenMs(statefulOperators.scala:102)
	at org.apache.spark.sql.execution.streaming.StateStoreSaveExec.timeTakenMs(statefulOperators.scala:251)
	at org.apache.spark.sql.execution.streaming.StateStoreSaveExec$$anonfun$doExecute$3$$anon$2.hasNext(statefulOperators.scala:359)
	at org.apache.spark.sql.execution.aggregate.ObjectAggregationIterator.processInputs(ObjectAggregationIterator.scala:188)
	at org.apache.spark.sql.execution.aggregate.ObjectAggregationIterator.<init>(ObjectAggregationIterator.scala:78)
	at org.apache.spark.sql.execution.aggregate.ObjectHashAggregateExec$$anonfun$doExecute$1$$anonfun$2.apply(ObjectHashAggregateExec.scala:114)
	at org.apache.spark.sql.execution.aggregate.ObjectHashAggregateExec$$anonfun$doExecute$1$$anonfun$2.apply(ObjectHashAggregateExec.scala:105)
	at org.apache.spark.rdd.RDD$$anonfun$mapPartitionsWithIndexInternal$1$$anonfun$apply$24.apply(RDD.scala:830)
	at org.apache.spark.rdd.RDD$$anonfun$mapPartitionsWithIndexInternal$1$$anonfun$apply$24.apply(RDD.scala:830)
	at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:42)
	at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:336)

This can happen when the following conditions are accidentally hit.

Streaming aggregation with aggregation function that is a subset of TypedImperativeAggregation (for example, collect_set, collect_list, percentile, etc.).
Query running in update} mode
After the shuffle, a partition has exactly 128 records.

This causes StateStore.commit to be called twice. See the JIRA for a more detailed explanation. The solution is to use NextIterator or CompletionIterator, each of which has a flag to prevent the "onCompletion" task from being called more than once. In this PR, I chose to implement using NextIterator.
How was this patch tested?
Added unit test that I have confirm will fail without the fix.

Test build #89694 has started for PR 21124 at commit 304498e.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/2569/
Test PASSed.

@brkyvz PTAL.

+1

+1

Test build #89694 has finished for PR 21124 at commit 304498e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/89694/
Test PASSed.

LGTM!


Logging & Monitoring Upgrade

Upgrades all logging and monitoring images to the latest version, pinning to specific version where we were previously using latest.  Also, splits logstash filters from the the input/output, which can be quite different depending on where the stack is running.

We should be good-to-go for merge here.  A couple things to note, though:

I am using the default UDP syslog:// connection from  logspout to logstash, instead of syslog+tcp:// as is required in our test env.  TCP doesn't work well in the Compose setup since logstash is never completely started by the time logspout tries to write to it, which closes the connection.
You'll notice an empty Kibana Dockerfile.  At one point I was adding some configs to the default Kibana setup.  I suspect I will be doing so again, so I think its worth keeping it in there for now.


[Task]: Support recover single wallet profile from stronghold

Task description
TBD

Blocked by waiting for response from sdk


stack: large the size

MultiCore test in XiangShan will failed with origin small stack size. So there larges the stack size.

It seems Verilator also checks the stack size (at least for latest versions). Do you check whether there's any public method to get the stack size from verilator build files? Then, we can use the public API to do this instead of always enlarging it every time xiangshan goes to bigger. For example, we cannot set the stack size to a very very big number just to simulate a 64-core xiangshan, even if we are only simulating a single-core xiangshan.

@poemonsense Thank you for your reminder. I checked it out. On the Verilator official website, the only parameter related to adjusting the stack size that I could find is --no-unlimited-stack, which is used to disable the behavior of Verilator trying to disable the stack size limit using the ulimit -s unlimited command; it doesn't allow for adjusting the stack size. However, when compiling emu, we can add a --stack-size parameter just like --seed and --max-instr, to dynamically set the stack size which is used by emu. But I need to confirm the feasibility of the latter method. If you have any other more effective methods, please let me know. Thank you again.

Looks good.
I remember when I run verilator, it warns me the stack size is too smaller. I will have a double check.
If you have free time, it's good if you can add the runtime argument. Thanks for your work

Yes, there indeed was a warning when the stack size is too small.
The image below is a screenshot of emu crashing due to a small stack size while debugging with gdb. However, I currently do not know how this was implemented. I need to check this further.

@poemonsense Thank you for your reminder. I checked it out. On the Verilator official website, the only parameter related to adjusting the stack size that I could find is --no-unlimited-stack, which is used to disable the behavior of Verilator trying to disable the stack size limit using the ulimit -s unlimited command; it doesn't allow for adjusting the stack size. However, when compiling emu, we can add a --stack-size parameter just like --seed and --max-instr, to dynamically set the stack size which is used by emu. But I need to confirm the feasibility of the latter method. If you have any other more effective methods, please let me know. Thank you again.

The latter method is implemented at the PR 355.


[wasmtime-wasi] StdinStream and StdoutStream are not publically accessible

I'm updating some code from Wasmtime 13 to the main branch, and noticed that it does not appear to be possible to implement StdinStream or StdoutStream outside of wasmtime-wasi given that the stdio module is private and those traits are not re-exported anywhere.  Is this intentional?  If so, is there some other way to e.g. connect stdin to an arbitrary AsyncReadStream?
If it's not intentional, I'd be happy to open a PR to make those traits public.

Oops indeed that's a bug, a PR sounds good!


Update C examples to use universal signature hash.

This also includes some refactoring subsequent to https://github.com/ElementsProject/simplicity/commit/9d720b147720f6960d844e150fe076c0bfd94c4d which moved the CMR calculation into the dag_node structure.  Now we can optimize the dag_node structure further.

Ack elements sihash Test b89fd04162bcdc73afafc9e21520cd1e91550371.


Handle redirect for ChromeTab Auth Code flow.

Description:  Parses Auth Code or AccessToken from activity redirect.
Related issue(s):  Fixes #159

I'm going to abandon this PR.
The existing auth code flow is deprecated and slated to be removed with 1.x release.  Auth code exchange should be done with a redirect to a web uri that can securely exchange the auth code for an access token.
The 1.x milestone should include support for PKCE which will replace these auth code flows.


make some text localizable

there are some text can't be translated when switch languages, make them localizable.

Codecov Report

Merging #5608 into master will increase coverage by 0.03%.
The diff coverage is 88%.

@@            Coverage Diff             @@
##           master    #5608      +/-   ##
==========================================
+ Coverage   63.59%   63.62%   +0.03%
==========================================
  Files         359      359
  Lines       22799    22821      +22
  Branches     2533     2533
==========================================
+ Hits        14499    14521      +22
  Misses       8285     8285
  Partials       15       15

Impacted Files
Coverage Δ

superset/assets/src/explore/visTypes.jsx
57.14% <ø> (ø)
:arrow_up:

...sets/src/explore/components/DisplayQueryButton.jsx
73.84% <ø> (ø)
:arrow_up:

superset/connectors/sqla/views.py
64.34% <ø> (ø)
:arrow_up:

superset/connectors/druid/views.py
68.24% <ø> (ø)
:arrow_up:

...ore/components/controls/AnnotationLayerControl.jsx
38.46% <0%> (ø)
:arrow_up:

superset/views/annotations.py
75.55% <100%> (+7.9%)
:arrow_up:

...nents/gridComponents/new/DraggableNewComponent.jsx
100% <100%> (ø)
:arrow_up:

...set/assets/src/dashboard/components/SliceAdder.jsx
86.04% <100%> (+0.16%)
:arrow_up:

superset/views/core.py
73.99% <100%> (+0.15%)
:arrow_up:

...rc/explore/components/controls/AnnotationLayer.jsx
23.03% <33.33%> (+0.37%)
: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 d1ef81f...bd02680. Read the comment docs.

Minor comment on one line, otherwise LGTM

@hitdemo FYI you don't need to close your PRs at every edit... you can just add a commit and push to the same branch and the PR will update. Also you probably shouldn't work on the master branch of your fork.


Android build with SDL2MIXER_FLAC=ON can't find libFLAC.so

The build can't find libFLAC.so with SDL2MIXER_FLAC=ON on an Android build, causing the build to fail:
$ ./gradlew build

...

> Task :buildCMakeDebug FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':buildCMakeDebug'.
> Expected output file at /project-name/android/build/intermediates/cxx/Debug/6w2m3w14/obj/arm64-v8a/libFLAC.so for target FLAC but there was none

...

CMakeLists.txt:
cmake_minimum_required( VERSION 3.18.0 )
cmake_policy( SET CMP0091 NEW )
project( appname )

set( SDL_LIBC ON CACHE BOOL "" FORCE )
set( SDL_TEST OFF CACHE BOOL "" FORCE )
# https://github.com/libsdl-org/SDL.git
# release-2.24.1
add_subdirectory( external/sdl )

set( BUILD_SHARED_LIBS OFF CACHE BOOL "" FORCE )
set( SDL2MIXER_FLAC ON CACHE BOOL "" FORCE )
set( SDL2MIXER_OPUS OFF CACHE BOOL "" FORCE )
set( SDL2MIXER_SAMPLES OFF CACHE BOOL "" FORCE )
set( SDL2MIXER_VENDORED ON CACHE BOOL "" FORCE )
# https://github.com/libsdl-org/SDL_mixer.git
# HEAD of 'main' branch as of today: db9da3d416077195a2f84403b2fb40955518b4ab
add_subdirectory( external/sdl-mixer )

set( SRCS "src/main.cpp" )

set( LIBS
    SDL2::SDL2main
    SDL2::SDL2-static
    SDL2_mixer::SDL2_mixer-static
    )

if( ${CMAKE_SYSTEM_NAME} MATCHES "Android")
    add_library( main SHARED ${SRCS} )
    target_link_libraries( main ${LIBS} )
else()
    add_executable( ${CMAKE_PROJECT_NAME} ${SRCS} )
    target_link_libraries( ${CMAKE_PROJECT_NAME} ${LIBS} )
endif()

src/main.cpp:
#include <SDL.h>
#include <SDL_mixer.h>

int main( int argc, char** argv )
{
    SDL_Init( SDL_INIT_EVERYTHING );
    SDL_Quit();
    return 0;
}

The same CMakeLists.txt builds successfully with SDL2MIXER_FLAC=OFF, as well as on the host Debian 11 system with:
cmake -B build -G "Ninja Multi-Config" .
cmake --build build --config Release --parallel $(nproc)

Is this with the last release or the latest from GitHub?

I see the following error when building FLAC for x86 targeting Android:
[1/5] Building ASM_NASM object external/flac/src/libFLAC/ia32/CMakeFiles/FLAC-asm.dir/cpu_asm.nasm.o
FAILED: external/flac/src/libFLAC/ia32/CMakeFiles/FLAC-asm.dir/cpu_asm.nasm.o
/opt/android/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin/yasm -DFLAC__HAS_NASM -DHAVE_CONFIG_H -D_DARWIN_C_SOURCE -D_POSIX_PTHREAD_SEMANTICS -D_TANDEM_SOURCE -D__STDC_WANT_IEC_60559_BFP_EXT__ -D__STDC_WANT_IEC_60559_DFP_EXT__ -D__STDC_WANT_IEC_60559_FUNCS_EXT__ -D__STDC_WANT_IEC_60559_TYPES_EXT__ -D__STDC_WANT_LIB_EXT2__ -D__STDC_WANT_MATH_SPEC_FUNCS__ -I/sdl_mixer/external/flac/include -I/sdl_mixer/build-android-prefab/build_x86/shared_ON/external/flac -I/sdl_mixer/external/flac/src/libFLAC/ia32 -mstackrealign -I/sdl_mixer/external/flac/src/libFLAC/ia32/ -dOBJ_FORMAT_elf -f elf -o external/flac/src/libFLAC/ia32/CMakeFiles/FLAC-asm.dir/cpu_asm.nasm.o /sdl_mixer/external/flac/src/libFLAC/ia32/cpu_asm.nasm
yasm: FATAL: `stackrealign' is not a valid machine for architecture `x86'
[2/5] Building ASM_NASM object external/flac/src/libFLAC/ia32/CMakeFiles/FLAC-asm.dir/fixed_asm.nasm.o
FAILED: external/flac/src/libFLAC/ia32/CMakeFiles/FLAC-asm.dir/fixed_asm.nasm.o
/opt/android/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin/yasm -DFLAC__HAS_NASM -DHAVE_CONFIG_H -D_DARWIN_C_SOURCE -D_POSIX_PTHREAD_SEMANTICS -D_TANDEM_SOURCE -D__STDC_WANT_IEC_60559_BFP_EXT__ -D__STDC_WANT_IEC_60559_DFP_EXT__ -D__STDC_WANT_IEC_60559_FUNCS_EXT__ -D__STDC_WANT_IEC_60559_TYPES_EXT__ -D__STDC_WANT_LIB_EXT2__ -D__STDC_WANT_MATH_SPEC_FUNCS__ -I/sdl_mixer/external/flac/include -I/sdl_mixer/build-android-prefab/build_x86/shared_ON/external/flac -I/sdl_mixer/external/flac/src/libFLAC/ia32 -mstackrealign -I/sdl_mixer/external/flac/src/libFLAC/ia32/ -dOBJ_FORMAT_elf -f elf -o external/flac/src/libFLAC/ia32/CMakeFiles/FLAC-asm.dir/fixed_asm.nasm.o /sdl_mixer/external/flac/src/libFLAC/ia32/fixed_asm.nasm
yasm: FATAL: `stackrealign' is not a valid machine for architecture `x86'
[3/5] Building ASM_NASM object external/flac/src/libFLAC/ia32/CMakeFiles/FLAC-asm.dir/lpc_asm.nasm.o
FAILED: external/flac/src/libFLAC/ia32/CMakeFiles/FLAC-asm.dir/lpc_asm.nasm.o
/opt/android/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin/yasm -DFLAC__HAS_NASM -DHAVE_CONFIG_H -D_DARWIN_C_SOURCE -D_POSIX_PTHREAD_SEMANTICS -D_TANDEM_SOURCE -D__STDC_WANT_IEC_60559_BFP_EXT__ -D__STDC_WANT_IEC_60559_DFP_EXT__ -D__STDC_WANT_IEC_60559_FUNCS_EXT__ -D__STDC_WANT_IEC_60559_TYPES_EXT__ -D__STDC_WANT_LIB_EXT2__ -D__STDC_WANT_MATH_SPEC_FUNCS__ -I/sdl_mixer/external/flac/include -I/sdl_mixer/build-android-prefab/build_x86/shared_ON/external/flac -I/sdl_mixer/external/flac/src/libFLAC/ia32 -mstackrealign -I/sdl_mixer/external/flac/src/libFLAC/ia32/ -dOBJ_FORMAT_elf -f elf -o external/flac/src/libFLAC/ia32/CMakeFiles/FLAC-asm.dir/lpc_asm.nasm.o /sdl_mixer/external/flac/src/libFLAC/ia32/lpc_asm.nasm
yasm: FATAL: `stackrealign' is not a valid machine for architecture `x86'
ninja: build stopped: subcommand failed.

Getting rid of -mstackrealign gives the following errors:
[1/153] Building ASM_NASM object external/flac/src/libFLAC/ia32/CMakeFiles/FLAC-asm.dir/cpu_asm.nasm.o
FAILED: external/flac/src/libFLAC/ia32/CMakeFiles/FLAC-asm.dir/cpu_asm.nasm.o
/opt/android/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin/yasm -DFLAC__HAS_NASM -DHAVE_CONFIG_H -D_DARWIN_C_SOURCE -D_POSIX_PTHREAD_SEMANTICS -D_TANDEM_SOURCE -D__STDC_WANT_IEC_60559_BFP_EXT__ -D__STDC_WANT_IEC_60559_DFP_EXT__ -D__STDC_WANT_IEC_60559_FUNCS_EXT__ -D__STDC_WANT_IEC_60559_TYPES_EXT__ -D__STDC_WANT_LIB_EXT2__ -D__STDC_WANT_MATH_SPEC_FUNCS__ -I/sdl_mixer/external/flac/include -I/sdl_mixer/build-android-prefab/build_x86/shared_ON/external/flac -I/sdl_mixer/external/flac/src/libFLAC/ia32 -I/sdl_mixer/external/flac/src/libFLAC/ia32/ -dOBJ_FORMAT_elf -f elf -o external/flac/src/libFLAC/ia32/CMakeFiles/FLAC-asm.dir/cpu_asm.nasm.o /sdl_mixer/external/flac/src/libFLAC/ia32/cpu_asm.nasm
/sdl_mixer/external/flac/src/libFLAC/ia32/cpu_asm.nasm:38: error: (cglobal:4) undefined symbol `__NASM_MAJOR__' in preprocessor
/sdl_mixer/external/flac/src/libFLAC/ia32/cpu_asm.nasm:39: error: (cglobal:4) undefined symbol `__NASM_MAJOR__' in preprocessor

Weird.
When configuring the project with -DWITH_ASM=OFF, I was able to build SDL_mixer successfully for all 4 Android platforms.

Why is it using yasm instead of nasm itself?

android.toolchain.cmake contains:
if(ANDROID_ABI STREQUAL "x86" OR ANDROID_ABI STREQUAL "x86_64")
  set(CMAKE_ASM_NASM_COMPILER
    "${ANDROID_TOOLCHAIN_ROOT}/bin/yasm${ANDROID_TOOLCHAIN_SUFFIX}")
  set(CMAKE_ASM_NASM_COMPILER_ARG1 "-DELF")
endif()

android.toolchain.cmake contains:

Huh.. And that thing comes with the toolchain? Then, for flac, we should add a
check for nasm being nasm.
Or, we can report this to flac mainstream, although they intend to remove asm
code, not sure how soon.

android.toolchain.cmake contains:

Huh.. And that thing comes with the toolchain? Then, for flac, we should add a check for nasm being nasm.

Yes, I'm using an (older) 21.4.7075529 though, for compatibility with later ndk releases.

Or, we can report this to flac mainstream, although they intend to remove asm code, not sure how soon.

Reporting upstream would not hurt. If they already intend to remove asm code, then this might accelerate that decision.

Reported asm build issue to mainstream at https://github.com/xiph/flac/issues/475

Getting rid of -mstackrealign

Is that -mstackrealign issue there if we upgrade our embedded flac to v1.4.1?

Just bumped to 1.4.1, and they got rid of -mstackrealign in a similar way as I did.
The __NASM_MAJOR__ preprocessor error remains.

Just bumped to 1.4.1, and they got rid of -mstackrealign in a similar way as I did. The __NASM_MAJOR__ preprocessor error remains.

Then let's upgrade officially in SDL_mixer main branch if there are no complications.

Is this with the last release or the latest from GitHub?

It was with the (then-)latest from Github, db9da3d416077195a2f84403b2fb40955518b4ab

@madebr:

Can you try building the project with flac enabled, and with -DWITH_ASM=OFF?

With a set( WITH_ASM OFF CACHE BOOL "" FORCE ) before the add_subdirectory( external/sdl-mixer ) and today's main (58497bdb6ae7dee132bc538072ea3ce12a6e7c50) it still can't find libFLAC.so.
Not sure how to convince Gradle to cough up CMake configure output; grepping around in .cxx/Debug/<...>/arm64-v8a/ didn't turn up anything useful.
Best I'm seeing is the confiugreCMakeDebug task output:
> Task :configureCMakeDebug
C/C++: debug|arm64-v8a :CMake Warning (dev) at external/sdl-mixer/external/ogg/CMakeLists.txt:2 (project):
C/C++: debug|arm64-v8a :  Policy CMP0048 is not set: project() command manages VERSION variables.
C/C++: debug|arm64-v8a :  Run "cmake --help-policy CMP0048" for policy details.  Use the cmake_policy
C/C++: debug|arm64-v8a :  command to set the policy and suppress this warning.
C/C++: debug|arm64-v8a :  The following variable(s) would be set to empty:
C/C++: debug|arm64-v8a :    PROJECT_VERSION
C/C++: debug|arm64-v8a :    PROJECT_VERSION_MAJOR
C/C++: debug|arm64-v8a :    PROJECT_VERSION_MINOR
C/C++: debug|arm64-v8a :    PROJECT_VERSION_PATCH
C/C++: debug|arm64-v8a :This warning is for project developers.  Use -Wno-dev to suppress it.
C/C++: debug|arm64-v8a :-- Check for working linker: /android-sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-ld
C/C++: debug|arm64-v8a :CMake Warning (dev) at external/sdl-mixer/external/libxmp/CMakeLists.txt:25 (option):
C/C++: debug|arm64-v8a :  Policy CMP0077 is not set: option() honors normal variables.  Run "cmake
C/C++: debug|arm64-v8a :  --help-policy CMP0077" for policy details.  Use the cmake_policy command to
C/C++: debug|arm64-v8a :  set the policy and suppress this warning.
C/C++: debug|arm64-v8a :  For compatibility with older versions of CMake, option is clearing the
C/C++: debug|arm64-v8a :  normal variable 'BUILD_STATIC'.
C/C++: debug|arm64-v8a :This warning is for project developers.  Use -Wno-dev to suppress it.
C/C++: debug|arm64-v8a :CMake Warning (dev) at external/sdl-mixer/external/libxmp/CMakeLists.txt:26 (option):
C/C++: debug|arm64-v8a :  Policy CMP0077 is not set: option() honors normal variables.  Run "cmake
C/C++: debug|arm64-v8a :  --help-policy CMP0077" for policy details.  Use the cmake_policy command to
C/C++: debug|arm64-v8a :  set the policy and suppress this warning.
C/C++: debug|arm64-v8a :  For compatibility with older versions of CMake, option is clearing the
C/C++: debug|arm64-v8a :  normal variable 'BUILD_SHARED'.
C/C++: debug|arm64-v8a :This warning is for project developers.  Use -Wno-dev to suppress it.
C/C++: debug|arm64-v8a :CMake Warning:
C/C++: debug|arm64-v8a :  Manually-specified variables were not used by the project:
C/C++: debug|arm64-v8a :    ANDROID_APP_PLATFORM

Setting SDL2MIXER_DEPS_SHARED=OFF lets the build complete though, even without WITH_ASM=OFF.

Setting SDL2MIXER_DEPS_SHARED=OFF lets the build complete though, even without WITH_ASM=OFF.

I can't reproduce this with (latest) Android Studio 2021.3.1.
I pushed some commits to reduce the number of unneeded libraries/executables being built, and also avoid libFLAC++.so being added to the .apk.
I tested this with re-using the android project of SDL, changing the c++ stl to c++_shared and making sure a cmake project is being built.

Setting SDL2MIXER_DEPS_SHARED=OFF lets the build complete though, even without WITH_ASM=OFF.

I also didn't see any issues with WITH_ASM when building with android studio. I noticed my Android Studio uses the legacy cmake toolchain. Not sure why that is.
The main difference between SDL2MIXER_DEPS_SHARED enabled or disabled is that the dependencies are dynamically loaded (at run time) instead of dynamically linked (at build time). In the CMake script, there is only a build dependency when it is enabled.
I can only theorize your toolchain does not pick these up.
About the logs, these are written as .txt files in a build and .cxx folder.
As reference, here are my logs.
The zip is the result of running the following command inside the app directory:
find . -iname "*.txt" -exec zip logs.zip {} +

While trying out things, I also occasionally removed the .cxx and build directories to make sure nothing was cached. Android Studio will then rebuild everything.

bug-457.zip contains the Git repo I've been testing on, with submodules for SDL & SDL_mixer and an adaptation of the SDL Android build guide in android/.
 Expected elements are <{}codename>,<{}layoutlib>,<{}api-level>

> Task :configureCMakeDebug
C/C++: debug|arm64-v8a :CMake Warning (dev) at external/sdl-mixer/external/ogg/CMakeLists.txt:2 (project):
C/C++: debug|arm64-v8a :  Policy CMP0048 is not set: project() command manages VERSION variables.
C/C++: debug|arm64-v8a :  Run "cmake --help-policy CMP0048" for policy details.  Use the cmake_policy
C/C++: debug|arm64-v8a :  command to set the policy and suppress this warning.
C/C++: debug|arm64-v8a :  The following variable(s) would be set to empty:
C/C++: debug|arm64-v8a :    PROJECT_VERSION
C/C++: debug|arm64-v8a :    PROJECT_VERSION_MAJOR
C/C++: debug|arm64-v8a :    PROJECT_VERSION_MINOR
C/C++: debug|arm64-v8a :    PROJECT_VERSION_PATCH
C/C++: debug|arm64-v8a :This warning is for project developers.  Use -Wno-dev to suppress it.
C/C++: debug|arm64-v8a :-- Check for working linker: /home/genpfault/Workspace/android-sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-ld
C/C++: debug|arm64-v8a :CMake Warning (dev) at external/sdl-mixer/external/libxmp/CMakeLists.txt:25 (option):
C/C++: debug|arm64-v8a :  Policy CMP0077 is not set: option() honors normal variables.  Run "cmake
C/C++: debug|arm64-v8a :  --help-policy CMP0077" for policy details.  Use the cmake_policy command to
C/C++: debug|arm64-v8a :  set the policy and suppress this warning.
C/C++: debug|arm64-v8a :  For compatibility with older versions of CMake, option is clearing the
C/C++: debug|arm64-v8a :  normal variable 'BUILD_STATIC'.
C/C++: debug|arm64-v8a :This warning is for project developers.  Use -Wno-dev to suppress it.
C/C++: debug|arm64-v8a :CMake Warning (dev) at external/sdl-mixer/external/libxmp/CMakeLists.txt:26 (option):
C/C++: debug|arm64-v8a :  Policy CMP0077 is not set: option() honors normal variables.  Run "cmake
C/C++: debug|arm64-v8a :  --help-policy CMP0077" for policy details.  Use the cmake_policy command to
C/C++: debug|arm64-v8a :  set the policy and suppress this warning.
C/C++: debug|arm64-v8a :  For compatibility with older versions of CMake, option is clearing the
C/C++: debug|arm64-v8a :  normal variable 'BUILD_SHARED'.
C/C++: debug|arm64-v8a :This warning is for project developers.  Use -Wno-dev to suppress it.
C/C++: debug|arm64-v8a :CMake Warning:
C/C++: debug|arm64-v8a :  Manually-specified variables were not used by the project:
C/C++: debug|arm64-v8a :    ANDROID_APP_PLATFORM

> Task :buildCMakeDebug
C/C++: ninja: Entering directory `/tmp/bug-457/android/.cxx/Debug/3l3k51t6/arm64-v8a'
C/C++: clang: warning: argument unused during compilation: '-marm' [-Wunused-command-line-argument]
C/C++: clang: warning: argument unused during compilation: '-marm' [-Wunused-command-line-argument]
C/C++: ../../../../../external/sdl-mixer/external/libxmp/src/depackers/depacker.c:144:12: warning: unused function 'execute_command' [-Wunused-function]

> Task :buildCMakeDebug FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':buildCMakeDebug'.
> Expected output file at /tmp/bug-457/android/build/intermediates/cxx/Debug/3l3k51t6/obj/arm64-v8a/libFLAC.so for target FLAC but there was none
...

logs.zip: Output from find . -iname "*.txt" -exec zip logs.zip {} + from inside android/ after the above repro steps fail on my end.
No Android Studio on my end, installed the command-line tools + whatever other Android SDK/NDK parts Gradle automagically installed via sdkmanager.

Thanks. I can reproduce in a docker container.
It's really weird.
Running gradle build --info shows the build command that is used.
$ ./gradlew build --info
...
Starting process 'command '/opt/android/cmake/3.18.1/bin/ninja''. Working directory: /src/android Command: /opt/android/cmake/3.18.1/bin/ninja -C /src/android/.cxx/Debug/2my5f214/arm64-v8a FLAC SDL2 benchmark_residual main xmp_shared
...
Execution failed for task ':buildCMakeDebug'.
...
$ find . -iname "*.so"
./build/intermediates/cxx/Debug/2my5f214/obj/arm64-v8a/libmain.so
./build/intermediates/cxx/Debug/2my5f214/obj/arm64-v8a/libSDL2.so
./build/intermediates/cxx/Debug/2my5f214/obj/arm64-v8a/libxmp.so

Let's try running the build command manually:
$ /opt/android/cmake/3.18.1/bin/ninja -C /src/android/.cxx/Debug/2my5f214/arm64-v8a FLAC SDL2 benchmark_residual main xmp_shared
$ find . -iname "*.so"
./build/intermediates/cxx/Debug/2my5f214/obj/arm64-v8a/libFLAC.so
./build/intermediates/cxx/Debug/2my5f214/obj/arm64-v8a/libmain.so
./build/intermediates/cxx/Debug/2my5f214/obj/arm64-v8a/libSDL2.so
./build/intermediates/cxx/Debug/2my5f214/obj/arm64-v8a/libxmp.so

Now libFLAC.so is there.
But running ./gradlew build will remove it again.
So it looks like something is removing libFLAC.so, and I have no idea why.

Dropping back to CMake 3.10.2 at the project level and in SDL_mixer seems to fix it.
Unfortunately external/flac needs modification:
/tmp/bug-457/external/sdl-mixer/external/flac$ git diff
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 5cac6be1..9bcb1076 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -93,7 +93,7 @@ add_compile_options(
     $<$<AND:$<COMPILE_LANGUAGE:C>,$<BOOL:${HAVE_DECL_AFTER_STMT_FLAG}>>:-Wdeclaration-after-statement>)

 if(HAVE_STACK_PROTECTOR_FLAG)
-    add_compile_options($<$<COMPILE_LANGUAGE:C,CXX>:-fstack-protector-strong>)
+    add_compile_options(-fstack-protector-strong)
 endif()

 if(CMAKE_SYSTEM_PROCESSOR STREQUAL "i686" AND HAVE_STACKREALIGN_FLAG)
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index bde3647b..1abab494 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -1,4 +1,4 @@
-cmake_minimum_required(VERSION 3.11)
+cmake_minimum_required(VERSION 3.10.2)

 option(ENABLE_64_BIT_WORDS "Set FLAC__BYTES_PER_WORD to 8 (4 is the default)" OFF)
 option(WITH_XMMS "Build XMMS plugin" OFF)
diff --git a/src/share/utf8/CMakeLists.txt b/src/share/utf8/CMakeLists.txt
index 389b09e2..12a082a6 100644
--- a/src/share/utf8/CMakeLists.txt
+++ b/src/share/utf8/CMakeLists.txt
@@ -1,8 +1,12 @@
-cmake_minimum_required(VERSION 3.12)
+cmake_minimum_required(VERSION 3.10.2)

 add_library(utf8 STATIC
     charset.c
     iconvert.c
     utf8.c)

-target_link_libraries(utf8 PUBLIC grabbag $<TARGET_NAME_IF_EXISTS:Iconv::Iconv>)
+if(TARGET Iconv::Iconv)
+    target_link_libraries(utf8 PUBLIC grabbag Iconv::Iconv)
+else()
+    target_link_libraries(utf8 PUBLIC grabbag)
+endif()

Sadly CMake 3.22.1 doesn't seem to exist in the Gradle/Android magic binaries list, just 3.10.2 and 3.18.1:
/tmp/bug-457/android$ ./gradlew build

> Configure project :
[CXX1300] CMake '3.22.1' was not found in SDK, PATH, or by cmake.dir property.
[CXX1301] - CMake '3.18.4' found in PATH did not satisfy requested version.
[CXX1301] - CMake '3.10.2' found in SDK did not satisfy requested version.
[CXX1301] - CMake '3.18.1' found in SDK did not satisfy requested version.
[CXX1300] CMake '3.22.1' was not found in SDK, PATH, or by cmake.dir property.
[CXX1301] - CMake '3.18.4' found in PATH did not satisfy requested version.
[CXX1301] - CMake '3.10.2' found in SDK did not satisfy requested version.
[CXX1301] - CMake '3.18.1' found in SDK did not satisfy requested version.

...

Though I can confirm that manually downloading the CMake 3.22.1 binaries & putting them in the PATH does fix it on my end.  SDL_SHARED=OFF doesn't seem to be needed.

I'll go with sdkmanager --install "cmake;3.22.1" then, thank you for all your patience and help!


Atlasssian Confluence Cloud: Returns 400 Bad Request: Content body cannot be converted to new editor format

We get a 400 bad request, when we have an   in our main document.
Without the include, there are no issues and the update succeeds in confluence.
To reproduce a simple hello world document and add and remove the include.
README.md:

# Hello World

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.

disclaimer.md:
**NOTE**: this document is generated, do not edit manually.

ERROR:
{
  "statusCode": 400,
  "data": {
    "authorized": false,
    "valid": true,
    "errors": [],
    "successful": false
  },
  "message": "com.atlassian.confluence.api.service.exceptions.BadRequestException: Content body cannot be converted to new editor format"
}
'''

Apologies I forgot to include the
 in the example initially.  Once I change the  to  the document updates without issue.


Add CONTRIBUTING.md doc

This explains how to get up and running to debug rango. Including adding web-ext as an explicit dev dependency.
This is mostly for my own convenience as it took me a while to realise how easy it was and I forgot how to do this after having done it the first time. I thought others may also find this useful. Also, this may not be totally right so please correct me if not, I figured this out from reading the package.json and some googling.
NOTE: this also includes what seems to be a lot of changes to the package-lock.json, I am not sure if main is missing these changes or if my local set up isn't quite right.

I've made those changes now @david-tejada
I was thinking of reaching out to to Nicholas Riley on Slack and see if he would consider adding steps here for Safri, and maybe packaging steps too.

I already asked @nriley to do a PR with Safari installation instructions. He said he'll do it on the weekend

Done in #57.


Fix x509: certificate signed by unknown authority using container image v1.3.0

Input
After the update to v1.3.0 the exporter crashes with the error:
time="2022-12-..." level=fatal msg="Could not retrieve quotas and limits: failed to list quotas: WebIdentityErr: failed to retrieve credentials\ncaused by: RequestError: send request failed\ncaused by:

Post "https://sts.amazonaws.com/": x509: certificate signed by unknown authority"

Expected
No crashes
Suggested Fix
The latest Dockerfile uses now FROM scratch as base image, which is missing the certs files.
Adding the OS ca-certificates to the container image fixed this issue on our side.
Verification

Checkout this branch and build the container image via:

docker build -t local/aws-service-quotas-exporter:v0 -f build/Dockerfile .

Run the container via:

docker run --rm\
 -e AWS_ACCESS_KEY_ID=$(aws configure get aws_access_key_id)\
 -e AWS_SECRET_ACCESS_KEY=$(aws configure get aws_secret_access_key)\
 -e AWS_SESSION_TOKEN=$(aws configure get aws_session_token)\
 local/aws-service-quotas-exporter:v0 --region=us-east-1

Output:

time="2022-12-..." level=info msg="Serving on port: 9090"
time="2022-12-..." level=info msg="Serving Prometheus metrics on /metrics"

Will there be a new release with this fix soon ?

Will there be a new release with this fix soon ?

It's available as part of v1.3.1 now 🙂


jax.numpy: put_along_axis

Hi :),
I am using jax.numpy to define a NumPyro model. To do so it would be very useful to have a function doing essentially the same as numpy's put_along_axis. In fact, for now I modified numpy's code slightly to output a jax object. But I was wondering, if it is planned to add this feature to jax.numpy in the future?

We haven't implemented this because the semantics of np.put_along_axis are to modify the array in-place, and this is not possible in JAX because JAX arrays are immutable. I suspect you could accomplish what you want to do using some combination of index update operators; see https://jax.readthedocs.io/en/latest/_autosummary/jax.numpy.ndarray.at.html#jax.numpy.ndarray.at

I see - thanks a lot for the explanation :) I was able to implement a custom version of np.put_along_axis using the index update operators as you suggested. Thanks again!

As there is some interest in this custom version that I am using for my problem, I am sharing the code here:
(Happy to any suggestions on how to solve this better)
"""
Defining put_along_axis() from numpy for jax.numpy.
Essentially copied the code from
https://github.com/numpy/numpy/blob/4adc87dff15a247e417d50f10cc4def8e1c17a03/numpy/lib/shape_base.py#L29

"""

import numpy.core.numeric as _nx
import jax

def _make_along_axis_idx(arr_shape, indices, axis):
    # compute dimensions to iterate over
    if not _nx.issubdtype(indices.dtype, _nx.integer):
        raise IndexError("`indices` must be an integer array")
    if len(arr_shape) != indices.ndim:
        raise ValueError("`indices` and `arr` must have the same number of dimensions")
    shape_ones = (1,) * indices.ndim
    dest_dims = list(range(axis)) + [None] + list(range(axis + 1, indices.ndim))

    # build a fancy index, consisting of orthogonal aranges, with the
    # requested index inserted at the right location
    fancy_index = []
    for dim, n in zip(dest_dims, arr_shape):
        if dim is None:
            fancy_index.append(indices)
        else:
            ind_shape = shape_ones[:dim] + (-1,) + shape_ones[dim + 1 :]
            fancy_index.append(_nx.arange(n).reshape(ind_shape))

    return tuple(fancy_index)

def custom_put_along_axis(arr, indices, values, axis):
    """
    Parameters
    ----------
    arr : ndarray (Ni..., M, Nk...)
        Destination array.
    indices : ndarray (Ni..., J, Nk...)
        Indices to change along each 1d slice of `arr`. This must match the
        dimension of arr, but dimensions in Ni and Nj may be 1 to broadcast
        against `arr`.
    values : array_like (Ni..., J, Nk...)
        values to insert at those indices. Its shape and dimension are
        broadcast to match that of `indices`.
    axis : int
        The axis to take 1d slices along. If axis is None, the destination
        array is treated as if a flattened 1d view had been created of it.

    """

    # normalize inputs
    if axis is None:
        arr = arr.flat
        axis = 0
        arr_shape = (len(arr),)  # flatiter has no .shape
    else:
        # axis = normalize_axis_index(axis, arr.ndim)
        arr_shape = arr.shape

    # use the fancy index
    arr = arr.at[tuple(_make_along_axis_idx(arr_shape, indices, axis))].set(values)
    return arr

One idea may be to define jax.numpy.put_along_axis, but add an extra inplace keyword that defaults to True, such that the function errors with the default value. Users could set inplace=False and then have a version of the function that returns the updated array. What do you think?
I suspect we could refactor things to share much of the index processing with take_along_axis.

Hi @jakevdp
I would like to contribute to this ticket.
I will break down this ticket by the following, see if it makes sense:

refactor some helper functions from take_along_axis that can be shared with put_along_axis
implement put_along_axis in JAX
default its argument inplace to True and raise an error for changing array in place)

Any update regarding this ?

Assuming I have an implementation functionally equivalent to the numpy version, not in place, but returning a new array, would you be interesting in me making a PR ? I know it is doable with only at but sometimes it is convenient to have such a function directly 🥲

Sure, I'd review a put_along_axis PR

I am interested in taking a crack at this if this is something you'd still want. It seems the work for this PR is already well-scoped, but given it's been almost 2 years since I figure no one is working on this.
Btw I am a Googler so CLA is already signed, I am just not on a Jax team so doing this as some volunteer work :)

Sounds good - feel free to take a look!


🐛 Fix payments recognition during advances

The verified status of an Atomical relies on the reveal window. The height in the query is the latest advanced block height rather than the processing height, which leads to an incorrect verified status for the container and realm.
The issue used to produce incorrect block hashes, probably incorrect Atomicals assets.
See height:tx records below for more details on the testnet:

2532818: b756276cdd06cc188c0266010c9fbf3e416089967a898275ca2909b93081f3ce
2569512: a98015464f0859b5f56011b4c0fb8911a83cac61cd77730744447919c79471a0

Verified with random start heights reindexing on the testnet.

Per offline discussion, op record should indicate if the payment is failed, for example, payment-dmitem-failed instead of payment-dmitem.


⚠ Barchessa Loredan has degraded performance

In f1db8df, Barchessa Loredan ($SITE_BRKLRD) experienced degraded performance:

HTTP code: 200
Response time: 8186 ms

Resolved: Barchessa Loredan performance has improved in 59089bd.


fix(mutationCache): export MutationCacheNotifyEvent type

Export MutationCacheNotifyEvent type to make it consistent with QueryCacheNotifyEvent (which is exported) and make it easier to write listener functions.
https://github.com/TanStack/query/blob/a320b4301078ea0bbf190e3f5c0e032f1c602e1b/packages/query-core/src/queryCache.ts#L71
We could even think about exporting QueryCacheListener and MutationCacheListener as well to give the correct type to the entire listener function.
https://github.com/TanStack/query/blob/a320b4301078ea0bbf190e3f5c0e032f1c602e1b/packages/query-core/src/queryCache.ts#L80
https://github.com/TanStack/query/blob/a320b4301078ea0bbf190e3f5c0e032f1c602e1b/packages/query-core/src/mutationCache.ts#L80

We're currently processing your upload.  This comment will be updated when the results are available.


Initialize Hutch::Config right after loading

Fixes #240.

Line 270 in Config in master now does this, right?
https://github.com/gocardless/hutch/blob/master/lib/hutch/config.rb#L270

Yes, this is now obsolete thanks to the merged PR from @olleolleolle.


fix: error: the item TryFrom is imported redundantly #317

This should fix #317 for Rust nightly.
How Has This Been Tested?
cargo build --release

Thanks!


[Docs] Wrong links on network/nodes/validator-node/deploy-nodes

Aptos Documentation Issue
Location
https://aptos.dev/en/network/nodes/validator-node/deploy-nodes
Description
Some links in this page are wrong ( should point to validator-node not full-node

Using Source Code
Using Docker
Using GCP

Audience

Additional context

this is fixed now!


"file reference member of multiple groups" warning in Xcode 10

After upgrading to Xcode 10, I'm getting the following warning when building my project:
2018-09-19 13:29:32.267 xcodebuild[17317:5682171] warning:  The file reference for "Sources/Components" is a member of multiple groups ("Sources" and ""); this indicates a malformed project.  Only the membership in one of the groups will be preserved (but membership in targets will be unaffected).  If you want a reference to the same file in more than one group, please add another reference to the same path.
2018-09-19 13:29:32.267 xcodebuild[17317:5682171] warning:  The file reference for "Sources/Coordinators" is a member of multiple groups ("Sources" and ""); this indicates a malformed project.  Only the membership in one of the groups will be preserved (but membership in targets will be unaffected).  If you want a reference to the same file in more than one group, please add another reference to the same path.
2018-09-19 13:29:32.267 xcodebuild[17317:5682171] warning:  The file reference for "Sources/Extensions" is a member of multiple groups ("Sources" and ""); this indicates a malformed project.  Only the membership in one of the groups will be preserved (but membership in targets will be unaffected).  If you want a reference to the same file in more than one group, please add another reference to the same path.
2018-09-19 13:29:32.287 xcodebuild[17317:5682171] warning:  The file reference for "Sources/Pages" is a member of multiple groups ("Sources" and ""); this indicates a malformed project.  Only the membership in one of the groups will be preserved (but membership in targets will be unaffected).  If you want a reference to the same file in more than one group, please add another reference to the same path.
2018-09-19 13:29:32.287 xcodebuild[17317:5682171] warning:  The file reference for "Sources/Stores" is a member of multiple groups ("Sources" and ""); this indicates a malformed project.  Only the membership in one of the groups will be preserved (but membership in targets will be unaffected).  If you want a reference to the same file in more than one group, please add another reference to the same path.

My directory structure looks like this:
Sources/
  Components/
    *.swift
  Coordinators/
    *.swift
  Extensions/
    *.swift
  Pages/
    *.swift
  Stores/
    *.swift
  *.swift
project.yml

I got the warning both on a version compiled with an older version (I guess Swift 4.1, XcodeGen version 1.7.0), and with the newer version 1.11.2 compiled with Swift 4.2.

Could you share some more details of your spec? Do multiple targets use the same source paths?
Better yet if you could submit a PR to the TestProject fixture that highlighted the issue, even better 😄👍

@LinusU is this still an issue for you?

Yes, sorry for not providing more info 😓
Still an issue in 2.0.0

Hmm, I tried to reproduce it here, but haven't been able to yet 🤔
https://github.com/yonaskolb/XcodeGen/compare/master...LinusU:warning-test-case

Really went down the rabbit hole on this one. The bug is only triggered with certain app names 😂
e.g. Ctrlpanel and Ctrlalala triggers the behaviour, but AppWithExtension and BiBaBo doesn't 😮

@yonaskolb okay, I've added a test case here: master...LinusU:warning-test-case
I did the following to see it:
cd Tests/Fixtures/TestProject
mint run yonaskolb/xcodegen
xcodebuild -project Project.xcodeproj -target Zapp -quiet CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO

The first line of the output is the warning

I was able to workaround this by adding createIntermediateGroups: true option to the (root) options section of .yml.

Just have this issue.
In my case, it is caused by typo.
e.g. some place is Sources/Components and some place is Sources/components


replace shared connection with tasks

NOTE: With the addition of Tasks, use of shared connections directly is no longer necessary. It is recommended that you use Tasks instead, as they are much easier to use.

https://github.com/vitaly-t/pg-promise#shared-connections
https://github.com/vitaly-t/pg-promise#tasks

I have divided my queries into individual promises.
It looks like tasks manage queries but not promises, similar to transactions.
It is not obvious how to make use of my promises within the task/tx structure.

This might be a larger project of restructuring my basic assumptions of division of labor that the promises handle, for example, maybe they don't all return db.query(...) or something.

Actually, transactions might work quite well. Each "promise" is returning db.query where db is actually a passed in parameter representing the pg-promise database "thing" (SCO or whatever).
Transactions pass in a parameter (called t in the docs) which acts just like a pg-promise database "thing". The transaction isn't executed as a promise until t.batch is called.
Rather than returning the t.query from my promise code, each then could return t itself, which is filtered across my promise code adding queries, ending with a final then with t.batch. Something like that.

No, I actually need query results to come back so I can filter them in Node code and then move on to the next query.

I'm not convinced we need this: the standard connection pooling in the PG library is good enough IMO. If we come across performance issues we can look at this again.


initial handler fired twice

Hello there!
I've created an strategy to always redirect users to home, and them open the desired uri via ajax and director.
When users try entering example.com/page1, they are redirected to example.com/#/page1.
I'm using pushState and director automatically corrects the route, removing the hash. That's cool!
The problem: sometimes director fires the route callback twice.
Why is that?

I think the only robust solution is to refuse firing the same route twice in a row. The router instance should track the current route.


[207] update/remove case category

Changes in this PR

specs to ensure that the OR categories are rendered on the change page “not yet known” & “no applicable category”
specs that the category correctly updates (likely already exist though)
custom update action for selecting the default category of “not applicable”

Resources

See #207 in Lucid spark for an overview of removing category from a case
main trello ticket

Video of UI changes
https://user-images.githubusercontent.com/6339025/152400326-18e9b3d0-0fd5-4d78-b57e-e22e39d7ae33.mov

 #207 update case journey

LGTM!


Changes for 0.3.0 release

Tidy up readme, update version numbers

Thanks for checking, and reminding me which tag I need to make! Will add the GitHub sponsors link and squash.

@mikeage so close! Looks like it didn't pull the full changelog since 0.2?

Hmmm... did you update the changelog? What's there now looks perfect... I can check the logs from the action

Yes, I've brought in from all the other changelogs manually, it just had the single most recent change before

Gotcha. It looks like this test wasn't correct:
if [ $(git describe --tags --abbrev=0) == $(git describe --tags) ]
then
    PREV=$(git describe --tags --abbrev=0 HEAD^)
else
    PREV=$(git describe --tags --abbrev=0)
fi

I'll check why in a little bit (going home now). Sorry about that!

Oh, duh, of course. I copy pasted the wrong thing when I finally merge this. Will fix soon.

Fixed in https://github.com/icosa-gallery/open-brush/pull/101 (along with a bit of duplicate code removed)


ENOSPC Error. Fails to watch when not superuser

Sorry for the noob question. I'm certain this is just some simple permission issue. When I run my app as super user it works great but if I try to run it as my default user it fails. I set the permissions to chmod 777 -R   and chown : -R .  The brackets are just to show that is the place that I put my username and path to the project respectively. It didn't fix it.

I'm using Linux Mint 18. I've run apt-get update and apt-get upgrade. I've also uninstalled node and reinstalled it. I can't seem to get this fixed and it seems like such a simple issue. Thanks!

Solved!!!
echo fs.inotify.max_user_watches=582222 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p


fix(bug): prevent website down if flags are not available

What this PR does / why we need it:
Which issue(s) does this PR fixes?:

Fixes #3969
Additional comments?:
Developer Checklist:

[ ] Read your code changes at least once
[ ] Tested on iOS/Android device (e.g, No crashes, library supported etc.)
[ ] No console errors on web
[ ] Tested on Light mode and Dark mode*
[ ] Your UI implementation visually matched the rendered design*
[ ] Unit tests*
[ ] Added e2e tests*
[ ] Added translations*

Codecov Report

Merging #3976 (d112925) into main (a513774) will decrease coverage by 16.37%.
The diff coverage is 0.00%.

@@             Coverage Diff             @@
##             main    #3976       +/-   ##
===========================================
- Coverage   32.69%   16.33%   -16.37%
===========================================
  Files         459      448       -11
  Lines       12347    12172      -175
  Branches     4082     4060       -22
===========================================
- Hits         4037     1988     -2049
- Misses       8259    10144     +1885
+ Partials       51       40       -11

Impacted Files
Coverage Δ

mobile-app/app/contexts/FeatureFlagContext.tsx
2.70% <0.00%> (-66.22%)
:arrow_down:

... and 127 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


[Star Wars Saga Edition] Fixing attributes which had been set by sheetworkers

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[x] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[x] The pull request makes changes to files in only one sub-folder.
[x] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

Changes / Description

There are still plenty of unused attributes which were created on sheets which were used during the patches of December 2023, but I think this is the last of the attributes which are in use by the sheet which need to be reset.

Character Sheet Info Roll20 Internal Use only.


Want to add functionality for the following scenarios

Want to add functionality for the following scenarios:
Sometimes the server set access to non-existent path is in the access home page, HTTP status code is also returned 200, which causes a lot of false positives.
My solution: For example, when scanning a path, it is found that a large number of responses are of the same length or the response length of the path is the same.  When the threshold is exceeded, the next path scan is switched, even if the HTTP status code is 200.

howdy!
can you include the exact command you ran? This functionality already exists, for the most part, so we can try and figure out why it didn't trigger in your case

Closing this due to inactivity. Please feel free to reopen


Return client ID

Bugfix for clientContext.getClientId()

This change is

Coverage increased (+0.06%) to 59.269% when pulling 9c1f713c318b986defabd58683d62c243f96a6f8 on getClientId-in-public-API into 9aee91982ecd5711555b2dff2f1dfcad95149c2a on master.


Fix an incorrect autocorrect for Style/SpecialGlobalVars

This PR fixes the following incorrect autocorrect for Style/SpecialGlobalVars when global variable as Perl name is used multiple times.
Example:
% cat example.rb
$*[0]
$*[1]

% bundle exec rubocop --only Style/SpecialGlobalVars -A
Inspecting 3 files
.C.

Offenses:

example.rb:1:1: C: [Corrected] Style/SpecialGlobalVars: Prefer $ARGV
from the stdlib 'English' module (don't forget to require it) or ARGV
over $*.
$*[0]
^^
example.rb:2:1: C: [Corrected] Style/SpecialGlobalVars: Prefer $ARGV
from the stdlib 'English' module (don't forget to require it) or ARGV
over $*.
$*[1]
^^

3 files inspected, 2 offenses detected, 2 offenses corrected

This auto-correction will add require 'English' twice:
% cat example.rb
require 'English'
require 'English'
$ARGV[0]
$ARGV[1]

This PR ensures that require 'English' is added only once:
% cat example.rb
require 'English'
$ARGV[0]
$ARGV[1]

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Thanks!


JSON Schema: Ignore fields via comment

This patch enables having fields ignored in the JSON Schema generation via a comment containing jsonschema:ignore (in either a leading or trailing comment).
A comment here is expedient, but not ideal as a long-term strategy. Would be much better as a custom option. This also has no impact on PubSub generation, though could presumably be extended to support that as well.
Part of this required changes to the golden tests as source location info (read: comments) aren't preserved in the reflection descriptors by the Go protobuf library (or any of the official ones for that matter). As a result, comments have now appeared in the input.json and impacted golden tests.
Holding off documenting until this strategy is approved.

should the fields really be ignored? Or somehow less prominent in the json schema. I am pretty sure it will show you an error if you try to use a field that is not listed in the json schema.

@Alfus are you thinking of something more explicit like https://json-schema.org/understanding-json-schema/reference/combining#not  where you can exclude specific keys?
but also, this seems like a nice property in general where you want the jsonschema to be a subset of the protos?

I am suggesting the field get listed in the schema, but not have docs, or maybe json schema has a 'hid' option so it doen't suggest the field, but will still validate it, if present.

The goal here is for a config file that supports some internal-only (mostly testing or experimental) properties, but hides them from end users. Some options:

Set additionalProperties to allow extra undefined fields. This aligns well with unknown proto fields, fwiw.

We could generate a wildcard property that will apply to any unknown fields. I'm not familiar enough with JSON Schema or IDE plugins to say if they're good at handling specialization/specificity in this context.

Move these rules out of the comments (or field options) and up to the protoc plugin as options there. That way the caller can choose what to generate by usecase (as opposed to having it fixed in the proto source itself).

Leave this as-is and allow the JSON schema to be an explicit subset of the actual proto definition.

My vote would be option 4 (current implementation), followed closely by a plugin option to get this out of the proto definitions, something like ignore_type. I personally don't mind the extra annotations, but I can see how that's a slippery slope towards littering proto files with unrelated things.
In terms of additionalProperties or simply omitting, not sure which is better. I'd defer to the person who is actually generating and working with this. It also sounds like we could support both in due time and they don't have to be mutually exclusive?

Kept it as-is for now. We can revisit with a more robust solution after we see where this all lands.


Handle XREFs with missing startxref after trailer

I have some PDF documents that look like:
  %PDF

  %objects
  xref
  %table
  trailer
  <</Root ..>

  %objects
  xref
  %table
  trailer
  <</Root /Prev ..>

  %objects
  xref
  %table
  trailer
  <</Root /Prev ..>

  %objects
  xref
  %table
  trailer
  <</Root /Prev ..>
  startxref
  %pointer
  %%EOF

So it looks kind of like its incrementally saved buts its missing
'startxref' and EOF after each table. Also, the early xref objects
reference objects later in the file so it is not due to incrementally
saving. The current code fails to parse the <</Root>> dictionary
because it assumes it is terminated with 'startxref'. So the last
two xref tables would be parsed but the first two tables would not
be found. The Fallback XREF parser would then find the first XREF
table, but it would stop after hitting the 'trailer' keyword and
would not find the second XREF table.
The end result is only the last two pages are visible.
Steps to reproduce:
python3 tools/pdf2txt.py samples/missing_xref_trailer.pdf

Page3

Page4

Expected:
python3 tools/pdf2txt.py samples/missing_xref_trailer.pdf
Page1

Page2

Page3

Page4

missing_xref_trailer.pdf
I'm opening a PR with a fix.

Hi @bmteller,
Thanks for opening the issue. I'm not yet sure what to do with it. It seems like your PDF's are obviously broken. At this point I don't know yet how far pdfminer.six should go in supporting "broken" PDF's. That's why I attached the type:anomaly label to this issue. If you filter the issues you can see that this is not the only anomaly PDF. In fact, PDF is kind of known for its variance.
I prefer to keep this issue open but don't fix it yet. And come up with a strategy on how to handle anomaly PDF's first.


[CP Staging] Revert "[Composer] Add logs in Composer-related logic to track bug with disappearing text"

Reverts Expensify/App#44106
Discussing here: https://expensify.slack.com/archives/C05LX9D6E07/p1719231886406529?thread_ts=1719084949.691449&cid=C05LX9D6E07

Straight revert

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Cherry-picked to staging by https://github.com/mountiny in version: 9.0.1-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
failure ❌

🍎 iOS 🍎
success ✅

🕸 web 🕸
failure ❌

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

🚀 Deployed to production by https://github.com/yuwenmemon in version: 9.0.1-19 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Release 2018-19-02

Codecov Report

Merging #164 into 0 will increase coverage by 0.01%.
The diff coverage is 20.16%.

@@            Coverage Diff             @@
##                0     #164      +/-   ##
==========================================
+ Coverage   30.67%   30.68%   +0.01%
==========================================
  Files         114      114
  Lines        4245     4276      +31
==========================================
+ Hits         1302     1312      +10
- Misses       2943     2964      +21


chore(main): release 0.34.4

:robot: I have created a release beep boop
0.34.4 (2024-12-20)
Bug Fixes

Improve error handling. Improve file watcher. (a9a3ae2)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v0.34.4
:sunflower:


Xe/feat/split admin

Closes #13

[ ] move api things into lokahi
[ ] define pseudoservices
[ ] implement them with nats
[ ] test them
[ ] reimplement minutely cron
[ ] put response status code in lokahi.CheckStatus for outgoing webhooks

Taking another approach to this


Replace SimpleITK's eigenvalue decomposition with a python one

The eigenvalue decomposition calculation does not account for non-consecutive voxels in a line (along x dimension), causing the calculated values for the principal moments to be erroneous when a lesion has 'holes' in it. Furthermore, it assumes that all voxels on line x = i have identical y and z coordinates, but this is not necessarily the case.

This looks like a serious problem with the ITK implementation.
cc: @thewtex @blowekamp

Do you have a minimal example of the problem?

For additional reference here is the Insight Journal article which describes how the principle moments calculation is done: http://hdl.handle.net/1926/584 There was also a follow up article which describes how the surface/perimeter computation is done: http://hdl.handle.net/10380/3342
I have made heavy use out of the principle axis computed with label maps. I recently extended the use of the principle axis with a computed oriented bounding boxes. And this is in the process of being added to SimpleITK SimpleITK/SimpleITK#189.
In my use cases and testing this computation has behavior correctly.  My experience has been that the computation takes into account the physical location of the pixels, and "gaps" in the labels. I would be very interested in a simple test case where the results are not correct.

@blowekamp As soon as I can find the time, I'll prepare some examples and a detailed description for you. My statements are currently based on how the computation is done in ITK's shapelabelobject. And of course the examples that led me to investigate this issue (some of the eigenvalues were negative).
I'll also take a look at the documents you sent and I will get back to you as soon as I can (currently at a congres though)

@blowekamp, as a first thought, do your testcase included angled aquisitions? I believe this may be a larger influence and can even be the case if the algortihm takes gaps into account

Here is a trivial test case, which seems to operate properly:
In [1]: import math

In [2]: import SimpleITK as sitk

In [3]: img = sitk.Image(5,5, sitk.sitkUInt8)

In [4]: img[1,2] = img[1,1] = 1

In [5]: stats = sitk.LabelShapeStatisticsImageFilter()

In [6]: stats.Execute(img); print stats.GetPrincipalAxes(1)
(1.0, 0.0, 0.0, 1.0)

In [7]: r = 0.78539816339

In [8]: img.SetDirection([math.cos(r), -math.sin(r), math.sin(r), math.cos(r)])

In [9]: stats.Execute(img); print stats.GetPrincipalAxes(1)
(0.7071067811918147, 0.7071067811812801, -0.70710678118128, 0.7071067811918146)

@blowekamp, sorry for the late reply.
I created a segmentation (for the brain1 testcase in PyRadiomics) with discontious segmentation, which seems to output meaningful values. However, when I change the direction to the direction I extracted from one of the cases where it failed. It also failed for the generated segmentation (i.e. produces negative eigenvalues).
Moreover, even when I use the original segmentation of breast1 testcase, it also fails when I change the direction.
I will prepare a representative example (main difference will be that this concerns a 3D volume, as opposed of a 2D one).

@blowekamp, here are two examples. If rotated along one axis, values are still correct:
import math
import SimpleITK as sitk
import numpy as np

im_path = r'E:\Git-Repos\pyradiomics\data\breast1_image.nrrd'
ma_path = r'E:\Git-Repos\pyradiomics\data\breast1_label.nrrd'
image = sitk.ReadImage(im_path)
mask = sitk.ReadImage(ma_path)

r = math.radians(45.0)

image.SetDirection([1.0, 0, 0, 0, math.cos(r), -math.sin(r), 0, math.sin(r), math.cos(r)])
mask.SetDirection([1.0, 0, 0, 0, math.cos(r), -math.sin(r), 0, math.sin(r), math.cos(r)])

lssif = sitk.LabelShapeStatisticsImageFilter()
lssif.Execute(mask)
print("Moments")
print(lssif.GetPrincipalMoments(1))
print("Axes")
print(lssif.GetPrincipalAxes(1))

OUT:
Moments
(1.7488174696549337, 1.8303030713532475, 3.735485178452522)
Axes
(0.7950707161543119, -0.44533237368675166, 0.41175433605536305, -0.6065167008084678, -0.5840224148057925, 0.5394954222649374, 0.00021898465942798317, -0.6786728931900383, -0.7344406416415056)
However, if the volume is rotated along 2 axis:

Direction is set to
image.SetDirection([0.7950707161543119, -0.44533237368675166, 0.41175433605536305, -0.6065167008084678, -0.5840224148057925, 0.5394954222649374, 0.00021898465942798317, -0.6786728931900383, -0.7344406416415056])
mask.SetDirection([0.7950707161543119, -0.44533237368675166, 0.41175433605536305, -0.6065167008084678, -0.5840224148057925, 0.5394954222649374, 0.00021898465942798317, -0.6786728931900383, -0.7344406416415056])

The output is:
Moments
(-254.61798391950742, 2.3911148490070246, 37.51723418381529)
Axes
(-0.6046568621057752, -0.7855033610930207, -0.1318125518301098, 0.37210010069808835, -0.1322641840296495, -0.9187206869791511, 0.7042241079151375, -0.6045582315497318, 0.3722603262457488)
The output from the numpy implementation in this PR is still correct (though not sorted yet. In PyRadiomics, results are sorted):
[ 3.73548518  1.74881747  1.83030307]
[[ 0.42892307  0.89225555  0.1410852 ]
[ 0.56216099 -0.14139489 -0.81485122]
[ 0.7071068  -0.42882108  0.5622388 ]]

Thank you for demonstrating the problem. I was able to reproduce and have created a patch to address the issue here:
http://review.source.kitware.com/#/c/22472/1

@blowekamp, going over the examples, if found out one last thing. It does not matter if it's rotated around just one or multiple axis, but whether it is rotated around the y and/or z axis (causing the x-part of the direction matrix to be different from "1, 0, 0" (as it is in the first example)). This is also logical if you look at the code and your fix; when not rotated or rotated around just the x-axis, the assumption that all voxels on the x-line have the same coordinates in y and z holds true.


Reoccurring null in LockableResourcesManager resources

Jenkins and plugins versions report

Environment

Jenkins: 2.426.2
OS: Linux - 5.15.0-1064-azure
Java: 17.0.9 - Eclipse Adoptium (OpenJDK 64-Bit Server VM)
lockable-resources:1218.va_3dd45e2b_fa_7

What Operating System are you using (both controller, and any agents involved in the problem)?
Jenkins is running in a container on Ubuntu 22
Reproduction steps
Unfortunately I do not have exact steps to reproduce the issue. I have a number of jobs that use lockable resources, so resources are locked/unlocked continuously minimum few times a minute. I've observed that every few days somehow a null is added to LockableResourcesManager resources list. This breaks not only the plugin (any call to step lock throws exception), but also global Jenkins configuration and the only option to fix it, is to directly  replace resources list in LockableResourcesManager.
I'm not using any advanced features of this plugin, only simple step lock('lock-name') { }
I was tryin to find any logs from when this null was added, but I didn't find any.
I doubt it matters, but in my case  job name is often used as resource name.
Expected Results
I don't know how is that even possible that a null resource is added to the LockableResourcesManager.resources, but I would expect that LockableResourcesManager should be able to remove it as clearly invalid entry.
Actual Results
I've observed two logs in case of failure (but I'm not sure why there are two variants) - both often appear mixed in log of the same job, that attempts to lock always the same resource.
Trying to acquire lock on [<lock name>]
[Pipeline] // lock
[Pipeline] End of Pipeline
java.lang.NullPointerException
Finished: FAILURE

and longer one:
[Pipeline] lock
Trying to acquire lock on [<lock name>]
[Pipeline] // lock
[Pipeline] End of Pipeline
Also:   org.jenkinsci.plugins.workflow.actions.ErrorAction$ErrorId: a326e53e-1b63-49e1-9293-60b260f97d14
java.lang.NullPointerException: Cannot invoke "org.jenkins.plugins.lockableresources.LockableResource.getName()" because "r" is null
	at org.jenkins.plugins.lockableresources.LockableResourcesManager.fromName(LockableResourcesManager.java:272)
	at org.jenkins.plugins.lockableresources.LockableResourcesManager.resourceExist(LockableResourcesManager.java:292)
	at org.jenkins.plugins.lockableresources.LockableResourcesManager.addResource(LockableResourcesManager.java:803)
	at org.jenkins.plugins.lockableresources.LockableResourcesManager.createResource(LockableResourcesManager.java:753)
	at org.jenkins.plugins.lockableresources.LockStepExecution.start(LockStepExecution.java:55)
	at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:323)
	at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:196)
	at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:124)
	at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:47)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
	at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:20)
	at org.jenkinsci.plugins.workflow.cps.LoggingInvoker.methodCall(LoggingInvoker.java:105)
	at discardOtherConcurrent.call(discardOtherConcurrent.groovy:6)
	at discardOtherConcurrent.call(discardOtherConcurrent.groovy)
	at WorkflowScript.run(WorkflowScript:32)
	at ___cps.transform___(Native Method)
	at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:90)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:116)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:85)
	at jdk.internal.reflect.GeneratedMethodAccessor247.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
	at com.cloudbees.groovy.cps.impl.ClosureBlock.eval(ClosureBlock.java:46)
	at com.cloudbees.groovy.cps.Next.step(Next.java:83)
	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:152)
	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:146)
	at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:136)
	at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:275)
	at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:146)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51)
	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:187)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:423)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:331)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:295)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:97)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:139)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
	at jenkins.util.ErrorLoggingExecutorService.lambda$wrap$0(ErrorLoggingExecutorService.java:51)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:840)
Finished: FAILURE

Anything else?
No response
Are you interested in contributing a fix?
No response

May you pls install last version. 1218 a little bit old.

Same problem with Jenkins 2.426.2.
Message
( java.lang.NullPointerException Cannot invoke "org.jenkins.plugins.lockableresources.LockableResource.getName()" because "r" is null)
seemingly at the exit from  steps.lock() pipeline block.
This occurred for the second time in a few days.
Before that the same Jenkins installation worked smoothly for several months.
Recently have added some agent but it seems to work well...

Same problem with Jenkins 2.426.2. Message ( java.lang.NullPointerException Cannot invoke "org.jenkins.plugins.lockableresources.LockableResource.getName()" because "r" is null) seemingly at the exit from steps.lock() pipeline block. This occurred for the second time in a few days. Before that the same Jenkins installation worked smoothly for several months. Recently have added some agent but it seems to work well...

which plugin version do you used?

Lockable Resources  1218.va_3dd45e2b_fa_7

1218

may you pls update the plugin to the last one version. There was many fixes and this issue is porbably fixed.
thx

This plugin update probably requires total Jenkins update. Not so easy in our working environment. Will try when I can...


Helm chart to install Drone in kubernetes

I've improved the README file and made the suggested changes. I've also moved GitHub credentials to secrets.

Please @rporres have a look at the changes whenever it suits you.
I have finally enabled non-secure HTTP again, because of reason stated here: https://github.com/src-d/backlog/issues/851#issuecomment-324883686


🐛 [firebase_analytics] No events are registered on Android, only iOS

Bug report
Describe the bug
For some reason suddenly events to Android have stopped working, works on iOS.
Steps to reproduce
Steps to reproduce the behavior:
Create a Flutter project with

firebase_analytics: ^10.2.1
firebase_core: ^2.14.0

Expected behavior
Events on Android should be registered as well.
Sample project
Providing a minimal example project which demonstrates the bug in isolation from your main App greatly enhances the chance of a timely fix.
Please link to the public repository URL.

Additional context
It seems that more people have this issue from Stackoverflow: https://stackoverflow.com/questions/77135584/firebase-analytics-android-not-working-in-android-flutter-app
Flutter doctor
Run flutter doctor and paste the output below:
Click To Expand
[!] Flutter (Channel [user-branch], 3.13.8, on macOS 13.4 22F2063 darwin-arm64, locale en-SE)
    ! Flutter version 3.13.8 on channel [user-branch] at /Users/development/flutter
      Currently on an unknown channel. Run `flutter channel` to switch to an official channel.
      If that doesn't fix the issue, reinstall Flutter by following instructions at https://flutter.dev/docs/get-started/install.
    ! Upstream repository unknown source is not a standard remote.
      Set environment variable "FLUTTER_GIT_URL" to unknown source to dismiss this error.
    • Framework revision 6c4930c4ac (2 months ago), 2023-10-18 10:57:55 -0500
    • Engine revision 767d8c75e8
    • Dart version 3.1.4
    • DevTools version 2.25.0
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/Library/Android/sdk
    • Platform android-33, build-tools 34.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.3.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14E300c
    • CocoaPods version 1.12.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.79.2)
    • VS Code at /Users/jetonmustini/Downloads/Visual Studio Code.app/Contents
    • Flutter extension version 3.78.0

[✓] Connected device (2 available)
    • macOS (desktop) • macos  • darwin-arm64   • macOS 13.4 22F2063 darwin-arm64
    • Chrome (web)    • chrome • web-javascript • Google Chrome 120.0.6099.129

[✓] Network resources
    • All expected network resources are available.```

</details>

---

### Flutter dependencies

Run `flutter pub deps -- --style=compact` and paste the output below:

<details><summary>Click To Expand</summary>

Resolving dependencies...
Got dependencies.

I even tried to manually initialize the analytics instance in the main()
  FirebaseAnalytics analytics = FirebaseAnalytics.instance;
  analytics.setAnalyticsCollectionEnabled(true);

and added the following to app level build.gradle dependencies
implementation("com.google.firebase:firebase-analytics")

@abbjetmus
Can you confirm if the events are being sent from client side or not ? If they are being sent but not reported in the console, then it may not be an issue with the plugin.

@darshankawar I think this is the same issue as this one:

@abbjetmus
Can you try https://github.com/firebase/flutterfire/issues/11912#issuecomment-1838251829 and also check https://github.com/firebase/flutterfire/issues/10399#issuecomment-1431319352 for your case helps or not.

I am having the same issue
its been 10 days working on it
I literally tried every single combination of the
classpath 'com.android.tools.build:gradle'
classpath 'com.google.gms:google-services'
but the problem still exists
the analytics works fine on iOS devices
while for the Android the problem is no event is registered to the analytics dashboard till I uninstall the app, only after that the data shows on the dashboard magically

I have the same issue, it started after changing version com.google.gms:google-services from 4.3.15 to 4.4.0.
After reverting to 4.3.15 it seems to working fine.
Kotlin version: 1.9.10
gradle: 7.3.1
firebase_core: 2.24.2
firebase_analytics: 10.8.0

This is still happening for Android using google-services 4.4.1


Update JDK used in release workflows

Goal

Testing

Release Notes

WHAT:
WHY:
WHO:

Current dependencies on/for this PR:

#465  👈
master

This stack of pull requests is managed by Graphite.


[Feature] Support for DragonBones

It would be great if polycode had support for DragonBones. It is a free and OpenSource Spine Alternative that will allow people to animate with bones instead of having to make sprite sheets if they wish.

Please don't post feature requests as issues. If you would like to discuss this, post on the polycode site forum.


SDK for hooks in Go

Hooks can be written in Go.

Create simple cli program that satisfies a shell agreement: prints config, if --config flag is passed and does work if executes without flags.

Compile hooks in a Shell-operator binary.

First one is easy, but second requires an SDK. It can be a thin layer between a Shell-operator code and a hook’s code. A handy framework can be implemented later on top of this SDK.

Implemented in addon-operator, used by deckhouse. Can be closed now.


Add navigation support

Need to be able to check various navigation scenarios, for example:

Is this there root screen? - yes/no
(Mainly) for inner screens: get navigation bar info (e.g. title text) and nav buttons captions.
Same for modals...
Get the app name of current screen (e.g. Safari)

Also, need to be able to perform a 'back' navigation action.

This is an issue of RN navigation. Need to provide testID for these elements.
CC @DanielZlotin

@d4vidi open an issue in Navigation please


Visual Studio minimum version and settings support

Conan 2.0 will implement Visual Studio compiler support via the msvc compiler setting, that will use the compiler version instead of the IDE version. The legacy Visual Studio compiler setting will be dropped.
The built-in build system integration to Visual Studio, provided by from conan.tools.microsoft (MSBuildDeps, etc), will provide full support down to Visual Studio 2017 (15, toolset v150), and partial support to Visual Studio toolset v140 from Visual Studio 2017 and above (but not from the Visual Studio 2015 IDE).

Upvote 👍  or downvote 👎  to show acceptance or not to the proposal (other reactions will be ignored)

Please, use 👀  to acknowledge you've read it, but it doesn't affect your workflow

Comment and reviews to suggest changes to all (or part) of the proposal.

We will be broken by this change.  Big ships take a while to turn...

Hi @michaelmaguire Can you please be a bit more specific about this:

We will be broken by this change

What will exactly be broken? All the tools to migrate are already available in Conan 1.45, and the path to update is defined in the proposal, what would be the main blockers?

Hi @michaelmaguire Can you please be a bit more specific about this:

We will be broken by this change

What will exactly be broken? All the tools to migrate are already available in Conan 1.45, and the path to update is defined in the proposal, what would be the main blockers?

Researching and applying migration will require scheduling work items across multiple teams.

Researching and applying migration will require scheduling work items across multiple teams.

Ok, I understand that, but that doesn't mean this will be a 2.0 breaking change, just that it will require a considerable effort to migrate to that.
I believe that with the Conan 1.X binary compatibility fallback msvc -> Visual Studio, the major effort to be done is to move to the new build system integrations (CMakeDeps, MSBuildDeps, etc). Once that happen, starting to build with msvc profiles can be done gradually, because if binaries not existing, it will fallback to previous Visual Studio binaries. All of this can happen in Conan 1.X, and from there, the upgrade to 2.0 should be smooth and not breaking.

CMake still supports everything using (Visual Studio 2012+), and also Visual Studio 10 2010 (though this was recently deprecated in 3.20) and even .vcproj (Visual Studio 9 2008).

Support via CMake wouldn't be a big issue, but we also need to support the native MSBuildDeps, MSBuildToolchain integrations, that are provided via xml .props properties files, and that might have subtle differences that we would need to take into account.
The minimum CMake supported is 3.15, which is from 2019, using a time based approach, it seems supporting VS from 2015 would be a reasonable time frame. In any case, this is the reason this proposal is here, if there are people stuck in older VS versions, it is expected that they would raise their concerns, and this could be changed. From what we are seeing talking to users is that since the community editions and when Msft started to really catch up on the standards, the upgrades to recent VS versions has been much faster than it used to be.

And toolset multi-targeting supports back to Visual studio v90 toolset (Visual Studio 2008). So if CMake supports cmake --build with these generators, and msbuild supports multi-targeting for

Yes, with toolsets is possible to go to previous versions, easier than using previous IDE versions. This is the reason we are proposing support for v140, but not for VS2015 IDE.

Just "not supported" in the sense that nobody is testing them, and maybe not listed in the settings.yml?

Yes, that is the idea. Testing with even older versions is a lot of effort too. It is possible that things work with previous versions, and maybe by adding older settings.yml things might work. It won't be a problem to add fixes provided by users for previous versions as long as they don't suppose a risk for the modern versions and it is not a big liability of future development and maintenance.

Hi,
For me this could be a showstopper for 2.0. Right now I need to support VS 2012, 2015 and 2017. Hopefully I can drop support this year for at least VS 2012. The main problem is that me and my team need to integrate into a lot of big applications which are closed source and require often older compiler versions.
I tried toolset multi-targeting in the past. I could not remember every detail but it was very painful to get things to work.

Yes, with toolsets is possible to go to previous versions, easier than using previous IDE versions. This is the reason we are proposing support for v140, but not for VS2015 IDE.

So defining a older toolset would search for the older compiler? Do I need VS 2017 always to get back to 2012 and 2015 corresponding toolset?

So defining a older toolset would search for the older compiler? Do I need VS 2017 always to get back to 2012 and 2015 corresponding toolset?

@tonka3000 yes, this is the idea, but if it is going to be a blocker, lets talk.

For me this could be a showstopper for 2.0. Right now I need to support VS 2012, 2015 and 2017. Hopefully I can drop support this year for at least VS 2012. The main problem is that me and my team need to integrate into a lot of big applications which are closed source and require often older compiler versions.

I think VS 2015 might be more doable, up to my knowledge, VS2015 is relatively similar to VS2017, while VS 2012 might be a bit more challenging.
Can you clarify if you are using native VS, or are you using CMake generated solutions? Also, as the tooling is already there in 1.45, we have time to experiment with it. Have you already tried the new integrations? Maybe it is worth to open a parallel thread to try things, to not pollute this thread too much with experiment details, and then come back here with our findings. Do you want to file an issue (for the Conan repo, we can assign a look-into for next 1.46 release) and we can check there?

Hi @memsharded ,

Can you clarify if you are using native VS, or are you using CMake generated solutions?

All is done via cmake. Conan itself is triggered via your awesome cmake-conan project. So maybe the wrapper can set the correct toolset version, which would help (but I guess it makes the cmake wrapper more complicated). Users use mostly the VSCode-cmake integrations where only the cmake generator names are available. Setting the toolset is possible but make the DX worse (but technical possible of course).

Have you already tried the new integrations?

Sadly no.

Maybe it is worth to open a parallel thread to try things, to not pollute this thread too much with experiment details, and then come back here with our findings. Do you want to file an issue (for the Conan repo, we can assign a look-into for next 1.46 release) and we can check there?

Ok. I just copy your text as the description of the new issue.

We have a cluster of projects that will need to support compiler.version=12, which is Visual Studio 2013. Because this is a product that we build for external consumption, it's unlikely that we will be able to change the compiler version.
We don't actually use Conan to run the build for that project, but we do consume Conan-generated .props files for part of it, and the SCons generator for other parts.

I'm fine with dropping old versions, but what blocks me from using the msvc compiler for everything is that non-default toolsets, like v141_xp, v141_clang_c2, and ClangCL, are not supported anymore.

I'm fine with dropping old versions, but what blocks me from using the msvc compiler for everything is that non-default toolsets, like v141_xp, v141_clang_c2, and ClangCL, are not supported anymore.

that is fair @MarcelRaad, it is very likely that some of these needs to be added to the new msvc compiler. They are not there because they have not been requested so far, but it makes sense to add them. The xp one would probably totally make sense, though the clang ones we need to check. It is possible that they are implemented via a compiler=clang setting, with something like a tools.cmake.cmaketoolchain:generator="Visual Studio 16", you can see this snippet from the CMakeToolchain:
        elif compiler == "clang":
            if generator and "Visual" in generator:
                if "Visual Studio 16" in generator:
                    return "ClangCL"
                else:
                    raise ConanException("CMakeToolchain compiler=clang only supported VS 16")

If you can report specifically which toolsets you need, and a bit of context (as a regular issue for Conan 1.X releases, this needs to be implemented before 2.0, so you can change in 1.X scope)

We are working in conan-io/conan#10808 to provide better support for msvc missing pieces, including older versions and toolsets.
Lets update the proposal, I'd like to suggest the following:

Having tested support down for VS2017, both for CMake and native MSBuild
Implementing "best-effort" support down to VS2015 for native MSBuild and down to VS2012 via CMake. This support won't be possible to be tested in CI, and will rely on contributors and external testers for validation, but it will be built-in, documented, and "stable" (as it won't be removed/dropped).
Integration will support toolsets too. Though some of the clang/llvm might be treated as a clang compiler setting, that needs to be investigated.

With these considerations, will anyone of the above change the vote?
Regarding the migration effort from "Visual Studio" => "msvc", we know it can take time and work. But keeping both settings in 2.0 we strongly believe that it will only add confusion and issues (bugs, inconsistencies), and with the above considerations there aren't apparently real blockers to not remove Visual Studio setting in 2.0.

This would be much appreciated.  I've changed my vote to thumbs up.

I checked 2d67de9a089716e18b6a1c7054a2b807f41af074 of the conan develop branch and it worked (details see https://github.com/conan-io/conan/issues/10610#issuecomment-1074363019)
I've remove my downvote. Also conan-cmake script can be adopted to match the old behavior with the msvc generator in my opinion.

Regarding the migration effort from "Visual Studio" => "msvc", we know it can take time and work. But keeping both settings in 2.0 we strongly believe that it will only add confusion and issues (bugs, inconsistencies), and with the above considerations there aren't apparently real blockers to not remove Visual Studio setting in 2.0.

I agree on that point.

The proposal has been updated according to the reviews. Please check https://github.com/conan-io/tribe/pull/32/commits/962cf7533c375d1ebe0a4231de8bba838a3e97e4.
https://github.com/conan-io/conan/pull/10808 has been merged and seems to be working fine, so apparently there shouldn't be blockers for this proposal. If there is no other major concerns, we will finally approve it and merge it soon.

I believe I have support for updating the version of Visual Studio we use on some older projects if/when it comes to that, so I changed my vote to "Approve."

Information about VS 2022 seems to be missing from the doc

Information about VS 2022 seems to be missing from the doc

The document is only talking about "minimum" requirement, it is assumed that support for newer versions will continuously be added as usual.

Thanks for all the feedback, and specially to the members testing things and older VS versions in their systems.
Seems this is fine to be merged.