Implement skip_if_absent for the RequestHeaders action

The Envoys's RequestHeaders action has a field called skip_if_absent that changes the behavior when enabled.
The spec:

It should be an optional field with a default value: false.
When skip_if_absent is false, the action behaves as it does now. When the header is absent, the entire descriptor is discarded, no matter what other action of the same configuration tell.
When skip_if_absent is true and the header is not present in the request, the descriptor is not discarded, however the action does not generate any descriptor entry. This behavior can lead to an empty descriptor. That is allowed. An empty descriptor is still a valid descriptor. Rate limit service can be called with an empty descriptor. Rate limit request  with an empty descriptor

limitador_1  | [2023-02-02T11:30:32Z DEBUG limitador_server::envoy_rls::server] Request received: Request { metadata: MetadataMap { headers: {"te": "trailers", "grpc-timeout": "5000m", "content-type": "application/grpc", "x-envoy-internal": "true", "x-forwarded-for": "<IP_ADDRESS>", "x-envoy-expected-rq-timeout-ms": "5000"} }, message: RateLimitRequest { domain: "rls-domain-a", descriptors: [RateLimitDescriptor { entries: [], limit: None }], hits_addend: 1 }, extensions: Extensions }

Note the empty descriptor
descriptors: [RateLimitDescriptor { entries: [], limit: None }]

This might not be relevant anymore, given kuadrant-operator#179, where the actions aren't exposed as such anymore


python3Packages.camply: init at 0.22.1

Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[X] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[X] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[X] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 184315 run on x86_64-linux 1

2 packages built:

python310Packages.camply
python39Packages.camply

Got the following error:
[nix-shell:~/.cache/nixpkgs-review/pr-184315]$ camply
Traceback (most recent call last):
  File "/nix/store/sc8ywsj5awqgjf9ki0g94f7ipg0r52zb-python3.10-camply-0.4.8/bin/.camply-wrapped", line 6, in <module>
    from camply.cli import cli
  File "/nix/store/ppvd9bxs4cb52pm17qfszlwxkbz1221f-python3.9-camply-0.4.8/lib/python3.9/site-packages/camply/__init__.py", line 8, in <module>
    from .providers import RecreationDotGov, YellowstoneLodging
  File "/nix/store/ppvd9bxs4cb52pm17qfszlwxkbz1221f-python3.9-camply-0.4.8/lib/python3.9/site-packages/camply/providers/__init__.py", line 6, in <module>
    from .recreation_dot_gov.recdotgov_provider import RecreationDotGov
  File "/nix/store/ppvd9bxs4cb52pm17qfszlwxkbz1221f-python3.9-camply-0.4.8/lib/python3.9/site-packages/camply/providers/recreation_dot_gov/recdotgov_provider.py", line 15, in <module>
    import pandas as pd
  File "/nix/store/my8x1cj6ph7s984wmlw4ikyjmf1vr7ha-python3.9-pandas-1.4.3/lib/python3.9/site-packages/pandas/__init__.py", line 16, in <module>
    raise ImportError(
ImportError: Unable to import required dependencies:
numpy:

IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW TO SOLVE THIS ISSUE!

Importing the numpy C-extensions failed. This error can happen for
many reasons, often due to issues with your setup or how NumPy was
installed.

We have compiled some common reasons and troubleshooting tips at:

    https://numpy.org/devdocs/user/troubleshooting-importerror.html

Please note and check the following:

  * The Python version is: Python3.10 from "/nix/store/rc9cz7z4qlgmsbwvpw2acig5g2rdws46-python3-3.10.5/bin/python3.10"
  * The NumPy version is: "1.23.1"

and make sure that they are the versions you expect.
Please carefully study the documentation linked above for further help.

Original error was: No module named 'numpy.core._multiarray_umath'

Sorry this sat for a year, but updated to the latest version (with a requests dependency version override -- also put in a PR upstream to update it there)!


proposal:use custom cookieJar implementation

now grequest use the official implmentation of cookieJar (net/http/cookiejar)
I think this one lacks some functions, such as exporting/importing all cookies of a session.
But it's no way to use custom cookiejar at the moment.
maybe it's better to use our own cookiejar implementation to add some features, or allow user to override the default ones.

You now have the ability to pass in your own cookieJar


URL Don't change in url bar

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version:
OS Version:

Steps to Reproduce:

Update URL in URL bar on URL change.

I'm guessing this is for the simple browsers. There's already duplicate issues tracking this. Not really possible to fix with current web apis


Database updated and Email Notifications added

Some extra changes reflected here were made due to some errors while testing.

Update requirements.txt with any new libraries.

The requested changes have been made and explanations have been provided for others. I have reverted some changes of the django doctor made which converted the default of strings like username and password to null instead of "" beacuse I think it is better to keep it null instead of "".

Made the requested changes and also removed the get request in the login function because that was also of no use.


SPIKE: Have a contingency plan for when Control Tower lands in Canadian Region

Describe the issue
The AWS product Control Tower could replace some of what the Landing Zone does.  It is currently unavailable in Canada but will conceivably replace the Secure Cloud Accelerator (SCA).
Which Sprint Priority is this issue related to?
The 'Milestone' should clearly list Sprint Priorities - which one is this issue related to?
Additional context
Add any other context, attachments or screenshots
Definition of done

A meeting with AWS occurs
Executive is informed of timeline and risks
Risk register updated
Any immediate work items created as tickets for next refinement/planning

No longer relevant


Queue/delayed printing of batch chat messages

This would prevent the Rust chat bug where the messages disappear, leaving only the Steam user icons.

No longer an issue, so closing.


VERIDISE-005: Unspecified revert messages

The SqrtMod()function calculates the square root of a given value under the modular operation
for the Ed25519 curve, if it exists. This function can revert in two locations as shown in Veridise report.
Solution: Define constants for revert types and revert using those constants.

corrected in
83c252349e3badd0d2b8967c12c8d94852691ce6

Closed as issue correction validated by Veridise final report.


Italian EPG

I had been using the XMLs for italy which have now stopped working and the surrent xml only has 13 channels

Try using this link:
https://iptv-org.github.io/epg/guides/it/guidatv.sky.it.epg.xml

Thanks. Back up again


Fix java.lang.UnsatisfiedLinkError: no netty-tcnative in java.library.path

netty-tcnative-boringssl-static Fork16 may fix it, so waiting for this.
https://github.com/netty/netty/wiki/Forked-Tomcat-Native

Fixed with netty-tcnative updated version(using 1.1.33.Fork22).


How to handle uploads from deleted accounts?

we can't use twitter login to check write permissions - maybe we just let them upload and tag their entry in archive_upload as "non authenticated" or something?
https://x.com/_deepfates/status/1832128115990262244

we're currently doing it by asking people for their archive and manually running a script as service role


Network Time Null Response

Periodical trouble with NetworkTime requests to worldtimeapi.org.
A trouble with null response and periodical curl error.
To solve the problem in the near future will deploy time servers on the main servers of TinyPlay services.
Our right now you can use other time servers with support of unix time and utc timezone.

Fixed


Elegoo uno r3

Hello is possible to use elegoo uno r3 with mobiflight? It mount atmega428p chip?
Thanks

Hello is possible to use elegoo uno r3 with mobiflight? It mount atmega428p chip?
Thanks

Yes, it is functionally identical to the arduino uno r3.

@neilenns @JaimeLeon2 Closing this because I assume the Uno is recognized by MobiFlight already and no VID/PID change needed?


stdlib: correct CLong for Windows ARM64

The Windows ARM64 build with the toolchain fixes exposed the missed type
aliasing for CLong when building Foundation.  With this it is finally
possible to build a complete SDK for Windows AArch64.

@swift-ci please test


Run all Benches in Benching.yaml?

Currently, we have a workflow to run benchmarks specifically for Iai benches which we are transitioning away from in favor of Criterion. Should we make the benches yaml generic and have it run all benchmarks instead with cargo bench --all? This way if we transition away from Criterion, we won't have to update the bench.yaml?

We shouldn't be running Criterion benchmarks at all in CI, since the results are highly unreliable. It also makes the CI pipeline slower for no reason. If we transition away from Criterion we'll update the CI when that happens.


Debugging fails to update Dynamic view and Registers are missing (10.2.2)

Describe the bug
Debugging Arm with gdb-multiarch no longer works in 10.2.2 (worked fine in 10.2.1).
To Reproduce

Use QEMU to emulate arm binary (we use QEMU 7)
Open an Arm binary in Ghidra debugger
Select Debugger Targets and then 'IN VM GNU gdb local debugger' and point it at /usr/bin/gdb-multiarch
In interpreter window type 'target remote localhost:1234', it should connect to QEMU stub
Got to Objects window and right-click on Inferiors -> 1 and hit R to bring up Record dialog
Untick the tick and select arm v6 or v7 (another bug means v5 may not work anyhow)
Close dialog and click Step or Next. Registers and Dynamic view don't update.

Expected behavior
The Dynamic view should update and Registers tab should show registers. Worked fine in 10.2.1.
Environment (please complete the following information):

OS: [Linux Ubuntu 20]
Java Version: [17]
Ghidra Version: [e.g. 10.2.2]
Ghidra Origin: [official GitHub distrot]

Minor layout edit

I'm not quite able to reproduce this issue. Things go as you describe until I get to step 6. Once I OK the Record dialog, I get a Dynamic listing at address 00000000, which is admittedly not great. However, once I step, things get back on track. Alternatively, instead of Step, I can click the one row in the Threads window and that'll get things on track at the first instruction.
I'm working with GDB 9.2 and QEMU 4.2.1, which are both a bit old.... I'm also using the SSH variant of the GDB connector, but that shouldn't matter. Can you check the Ghidra User Log? (Click the little computer icon in the bottom-right of the main Ghidra project window.) The only gdb-related change between 10.2.1 and 10.2.2 I see is in GdbReadRegistersCommand, so look for traces involving it, and if you don't mind, please post what you find here.
If none of this is helpful, I can try replicating your environment a little more closely, but I'll need to know your version of GDB. If there's a Linux distro where those GDB and QEMU versions come stock, it might help me get there faster.

Apologies for not adding all the versions:
gdb-multiarch --v: GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
QEMU script with versions (for vanilla Arm v7):
/qemu-7.1.0/build/arm-softmmu/qemu-system-arm
-cpu arm1176
-m 256
-M versatilepb
-device loader,file=boot.bin,addr=0x00000,force-raw=true
-s -S
QEMU script with versions (for STM32):
/xpack-qemu-arm-7.1.0-1/bin/qemu-system-gnuarmeclipse
-cpu cortex-m4
-M STM32F4-Discovery
-kernel stm32F4.bin
-s -S
(There are backslashes on the end of those lines, but the webpage is removing them)
Ive been checking gdb works directly by adding & gdb-multiarch on the end of the script.
Log output at remote connect time and stepping:
`2022-11-17 20:37:12 DEBUG (GdbModelTargetThread) Updating stack for <GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread>
2022-11-17 20:37:12 ERROR (GdbModelTargetThread) Could not initialize thread info
2022-11-17 20:37:12 ERROR (DebuggerCallbackReorderer) Listener ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener@208553ec caused exception processing attributesChanged java.util.NoSuchElementException: No mapper for target: <GdbModelTargetInferior: path=Inferiors[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Inferior>
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServicePlugin.recordTargetBestOffer(DebuggerModelServicePlugin.java:367)
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServiceProxyPlugin.recordTargetBestOffer(DebuggerModelServiceProxyPlugin.java:521)
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider.startRecording(DebuggerObjectsProvider.java:1640)
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener.attributesChanged(DebuggerObjectsProvider.java:1972)
at ghidra.dbg.util.DebuggerCallbackReorderer.lambda$attributesChanged$3(DebuggerCallbackReorderer.java:203)
at ghidra.dbg.util.DebuggerCallbackReorderer.defensive(DebuggerCallbackReorderer.java:113)
at ghidra.dbg.util.DebuggerCallbackReorderer.attributesChanged(DebuggerCallbackReorderer.java:203)
at jdk.internal.reflect.GeneratedMethodAccessor32.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 ghidra.util.datastruct.PrivatelyQueuedListener$ListenerHandler.lambda$invoke$0(PrivatelyQueuedListener.java:42)
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:833)
2022-11-17 20:37:12 ERROR (GdbModelTargetThreadContainer) Could not update threads <GdbModelTargetThreadContainer: path=Inferiors[1].Threads model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=ThreadContainer> on STOPPED
2022-11-17 20:37:50 DEBUG (ListenerOnRecorders) (started) Got snapAdvanced callback
2022-11-17 20:37:50 DEBUG (ListenerOnRecorders) (3 ms) Firing SnapEvent on ghidra.app.plugin.core.debug.service.model.DebuggerModelServiceProxyPlugin@c8488ed4
2022-11-17 20:37:50 DEBUG (ListenerOnRecorders) (24 ms) Got snapAdvanced callback
2022-11-17 20:37:50 DEBUG (ListenerOnRecorders) (0 ms) Firing SnapEvent on ghidra.app.plugin.core.debug.service.model.DebuggerModelServiceProxyPlugin@c8488ed4
2022-11-17 20:37:50 DEBUG (TraceEventListener) (55 ms) State STOPPED for <GdbModelTargetInferior: path=Inferiors[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Inferior>
2022-11-17 20:37:50 DEBUG (TraceEventListener) (0 ms) State STOPPED for <GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread>
2022-11-17 20:37:50 DEBUG (TraceEventListener) (178 ms) Memory updated: 00000000 (4096)
2022-11-17 20:37:50 DEBUG (ToolTaskManager) Background processing started...
2022-11-17 20:37:50 DEBUG (ToolTaskManager) Exec Task Map modules to open programs
2022-11-17 20:37:50 DEBUG (ToolTaskManager) Map modules to open programs task finish (0.004 secs)
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Map modules to open programs task complete (0.322 secs)
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Background processing complete (0.323 secs)
2022-11-17 20:37:51 DEBUG (DBTrace) Creating fixed view at snap=1
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Background processing started...
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Exec Task Auto-disassemble
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Auto-disassemble task finish (0.182 secs)
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Auto-disassemble task complete (0.182 secs)
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Exec Task Auto-disassemble
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Auto-disassemble task finish (0.0 secs)
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Auto-disassemble task complete (0.002 secs)
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Exec Task Auto-disassemble
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Auto-disassemble task finish (0.0 secs)
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Auto-disassemble task complete (0.001 secs)
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Background processing complete (0.186 secs)
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Background processing started...
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Exec Task Map modules to open programs
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Map modules to open programs task finish (0.0 secs)
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Map modules to open programs task complete (0.001 secs)
2022-11-17 20:37:51 DEBUG (ToolTaskManager) Background processing complete (0.002 secs)
2022-11-17 20:37:54 DEBUG (GdbManagerImpl) Target is running
2022-11-17 20:37:54 DEBUG (TraceEventListener) (4298 ms) State RUNNING for <GdbModelTargetInferior: path=Inferiors[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Inferior>
2022-11-17 20:37:54 DEBUG (TraceEventListener) (1 ms) Event: RUNNING thread=<GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread> description=Running params=[<GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread>]
2022-11-17 20:37:54 DEBUG (TraceEventListener) (2 ms) State RUNNING for <GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread>
2022-11-17 20:37:54 DEBUG (TraceEventListener) (0 ms) Event: STEP_COMPLETED thread=<GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread> description=Stepping ended params=[<GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread>]
2022-11-17 20:37:54 DEBUG (GdbModelTargetThread) Updating stack for <GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread>
2022-11-17 20:37:54 DEBUG (ListenerOnRecorders) (4 ms) Got snapAdvanced callback
2022-11-17 20:37:54 DEBUG (ListenerOnRecorders) (0 ms) Firing SnapEvent on ghidra.app.plugin.core.debug.service.model.DebuggerModelServiceProxyPlugin@c8488ed4
2022-11-17 20:37:54 DEBUG (TraceEventListener) (1 ms) State STOPPED for <GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread>
2022-11-17 20:37:54 DEBUG (TraceEventListener) (1 ms) State STOPPED for <GdbModelTargetInferior: path=Inferiors[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Inferior>
2022-11-17 20:37:54 ERROR (GdbModelTargetThreadContainer) Could not update threads <GdbModelTargetThreadContainer: path=Inferiors[1].Threads model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=ThreadContainer> on STOPPED
2022-11-17 20:37:54 DEBUG (DefaultThreadRecorder) (42 ms) Reg values changed: [r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11, r12, sp, lr, pc, cpsr, d0, d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, d11, d12, d13, d14, d15, fpscr, fpsid, fpexc, DUMMY, PAR, DBGDIDR, MIDR, CTR, TCMTR, TLBTR, JIDR, ID_PFR0, ID_DFR0, ID_AFR0, ID_MMFR0, ID_MMFR1, ID_MMFR2, ID_MMFR3, DACR, ID_ISAR0, ID_ISAR1, ID_ISAR2, ID_ISAR3, ID_ISAR4, ID_ISAR5, ID_MMFR4, ID_ISAR6, TTBR0_EL1, DFAR, WFAR, TTBCR, IFAR, TTBR1_EL1, JMCR, SCTLR, DFSR, ACTLR_EL1, CPACR, DLOCKDOWN, IFSR, FCSEIDR, ILOCKDOWN, CONTEXTIDR_EL1, TPIDRURW, TPIDRURO, TPIDRPRW, ACTLR_EL2, JOSCR, s0, s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, s13, s14, s15, s16, s17, s18, s19, s20, s21, s22, s23, s24, s25, s26, s27, s28, s29, s30, s31]
2022-11-17 20:37:56 DEBUG (GdbManagerImpl) Target is running
2022-11-17 20:37:56 DEBUG (TraceEventListener) (1646 ms) State RUNNING for <GdbModelTargetInferior: path=Inferiors[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Inferior>
2022-11-17 20:37:56 DEBUG (TraceEventListener) (1 ms) Event: RUNNING thread=<GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread> description=Running params=[<GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread>]
2022-11-17 20:37:56 DEBUG (GdbModelTargetThread) Updating stack for <GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread>
2022-11-17 20:37:56 DEBUG (TraceEventListener) (0 ms) State RUNNING for <GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread>
2022-11-17 20:37:56 DEBUG (TraceEventListener) (2 ms) Event: STEP_COMPLETED thread=<GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread> description=Stepping ended params=[<GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread>]
2022-11-17 20:37:56 DEBUG (ListenerOnRecorders) (1 ms) Got snapAdvanced callback
2022-11-17 20:37:56 DEBUG (ListenerOnRecorders) (1 ms) Firing SnapEvent on ghidra.app.plugin.core.debug.service.model.DebuggerModelServiceProxyPlugin@c8488ed4
2022-11-17 20:37:56 DEBUG (TraceEventListener) (0 ms) State STOPPED for <GdbModelTargetThread: path=Inferiors[1].Threads[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Thread>
2022-11-17 20:37:56 DEBUG (TraceEventListener) (1 ms) State STOPPED for <GdbModelTargetInferior: path=Inferiors[1] model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=Inferior>
2022-11-17 20:37:56 ERROR (GdbModelTargetThreadContainer) Could not update threads <GdbModelTargetThreadContainer: path=Inferiors[1].Threads model=agent.gdb.model.impl.GdbModelImpl@2165575e schema=ThreadContainer> on STOPPED
2022-11-17 20:37:56 DEBUG (DefaultThreadRecorder) (22 ms) Reg values changed: [r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11, r12, sp, lr, pc, cpsr, d0, d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, d11, d12, d13, d14, d15, fpscr, fpsid, fpexc, DUMMY, PAR, DBGDIDR, MIDR, CTR, TCMTR, TLBTR, JIDR, ID_PFR0, ID_DFR0, ID_AFR0, ID_MMFR0, ID_MMFR1, ID_MMFR2, ID_MMFR3, DACR, ID_ISAR0, ID_ISAR1, ID_ISAR2, ID_ISAR3, ID_ISAR4, ID_ISAR5, ID_MMFR4, ID_ISAR6, TTBR0_EL1, DFAR, WFAR, TTBCR, IFAR, TTBR1_EL1, JMCR, SCTLR, DFSR, ACTLR_EL1, CPACR, DLOCKDOWN, IFSR, FCSEIDR, ILOCKDOWN, CONTEXTIDR_EL1, TPIDRURW, TPIDRURO, TPIDRPRW, ACTLR_EL2, JOSCR, s0, s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, s13, s14, s15, s16, s17, s18, s19, s20, s21, s22, s23, s24, s25, s26, s27, s28, s29, s30, s31]  `

Thanks for the information. The message that looks like trouble is Could not update threads ... on STOPPED. Unfortunately, that message doesn't include any diagnostics, so unless you're willing to whip up a development environment, the remaining investigation is up to us. Looks like we match versions except for qemu, which should be easy for me to get. Also, FWIW, I tested with qemu running a user-space hello world program. I didn't try a full system image. That might be relevant....
Also worth noting is that the log shows it detected register value changes, which is promising. My suspicion; however, is that there's no way in the UI to navigate to and display them. A few things you might check: 1) I had mentioned the Threads window (the dedicated window, not the Threads node in Objects window) It contained one entry when I tried replicating. Do you have any entries at all, or is that window empty? If it's populated, try clicking an entry. 2) Check the same for the Stack window. 3) In the Objects window, try navigating to frame #0 and expanding/refreshing its Registers node. Sometimes that kicks things along. You can also try Refreshing other collections in the ancestry: i.e., Stack node, Threads node....

So I have set up a qemu-user mode version like you, still on 7.1.0 (and briefly checked on the apt installed 6.0.93 version with same result). My script:
/qemu-7.1.0/build/qemu-arm -L /usr/arm-linux-gnueabi/ -g 4444 ./hello -n
So switching between 10.2.1 and 10.2.2 it almost mimics if I hadn't set up the Record function. i.e. if I use 10.2.1 and don't select record and try and step I get static Dynamic view and no registers (I have of course ensured I have followed the same process to debug across 10.2.1 and 10.2.2).
If I click on Threads window entry (there is one as expected), the registers magically appear (didn't have to do this on 10.2.1). These registers have values, but stepping does not update them and the Dynamic view still doesn't work or show any disassembly.
The entry says:
null stopped at 0x...         0             stopped
Strangely threads tab "plot arrow" goes backwards each step not forwards as in 10.2.1, and I noticed the Interpreter window shows steps ok.
If I do 2) or 3) in your suggestions, nothing happens or changes. I note Stack isn't populated in 10.2.2, but is in 10.2.1.
Can you point me at instructions to set up a debug build?

Oh. Thanks for the notes about the plot arrow. I think that might be the give away. There's a double-right green arrow button at the top-right of the Threads window ("Track the tool to the latest snap"). Check if that's on. Even if it appears on, toggle it off and back on just to kick it. Then try stepping again.
If that resolves the issue, close and re-open the Debugger so that the tool gets saved. One of our testers noticed this issue with 10.2, but no one else could reproduce it. My guess is it has to do with Ghidra importing the Debugger tool from an older installation.

If that doesn't resolve it, and you want to debug the 10.2.2 Debugger, clone the repo, check out this tag: https://github.com/NationalSecurityAgency/ghidra/tree/Ghidra_10.2.2_build, and follow the development instructions here https://github.com/NationalSecurityAgency/ghidra/blob/Ghidra_10.2.2_build/DevGuide.md

Toggling the arrow cured. Saved, reopened. All good
Thanks!

Good deal!


[2.9.x] Update mockito-core to 5.1.1

Updates org.mockito:mockito-core from 3.12.4 to 5.1.1.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.mockito", artifactId = "mockito-core" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.mockito", artifactId = "mockito-core" }
}]

labels: test-library-update, early-semver-major, semver-spec-major, commit-count:1

Superseded by #292.


No custom fields in Taxonomy

Description
I've added to my custom rest fields to WP. they shows up in REST call but ara not visible in GraphQL.
I did the same for Posts, but there it works.
Steps to reproduce

edit you functions.php in WP with

register_rest_field( array("tag", "category"), 'locale', array(
				'get_callback'    => 'add_locale_tag_field',
				'update_callback' => null,
				'schema'          => null
			) );

function add_locale_tag_field($tag){
	return "my_locale_string";

}

call the endpoint

[...
{
"id": 24,
"count": 4,
"description": "",
"link": "https://wordpress-388080-1372009.cloudwaysapps.com/category/art_and_theatre/",
"name": "Art",
"slug": "art_and_theatre",
"taxonomy": "category",
"parent": 0,
"meta": [],
"acf": [],
"locale": "it", // this is the one i've added
"_links": {5 items}
}]

gridsome develop -> http://localhost:8080/___explore

query{
  allWordPressPostTag{
  	edges{
          node{
        id
        <- no locale found
        }
    }
  }
}

Expected result
query{
  allWordPressPostTag{
  	edges{
          node{
        id
        locale string found
        }
    }
  }
}

Actual result
no locale variable found
Environment
System:
OS: macOS 10.15.6
CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
Binaries:
Node: 14.4.0 - /usr/local/bin/node
npm: 6.14.7 - /usr/local/bin/npm
Browsers:
Chrome: 84.0.4147.105
Firefox: 77.0.1
Safari: 13.1.2
npmPackages:
@gridsome/source-wordpress: ^0.5.0 => 0.5.3
gridsome: ^0.7.0 => 0.7.19
gridsome-plugin-i18n: ^1.6.0 => 1.6.0
gridsome-plugin-tailwindcss: ^3.0.1 => 3.0.1
npmGlobalPackages:
@gridsome/cli: 0.3.3

Currently, the source wordpress implementation does not support other fields than defined in the script:
https://github.com/gridsome/gridsome/blob/master/packages/source-wordpress/index.js#L109-L115
Workaround: Is it possible to move it to the meta ?

Currently, the source wordpress implementation does not support other fields than defined in the script:
https://github.com/gridsome/gridsome/blob/master/packages/source-wordpress/index.js#L109-L115
Workaround: Is it possible to move it to the meta ?

Hi, was wondering, if the support is planned? Would be great to add some fields to categories like Images.


fix contributors link

Type:
The following has been addressed in the PR:

There is a related issue?
Unit or Functional tests are included in the PR

Description:

Thanks @idangozlan


feat: Firestore sum avg change

Design doc: V3 changes in design doc
Note: I have made minimal changes to count implementation in this. Will take another pass to make all relevant FS count changes. This PR is focused on the FS V3 Sum & Avg implementation

Closing in favour of #10581


Add designs for choosing between spring or autumn

Branch for the soft-close flow

Main changes:

Content tweaks
Before you start content on /start when the service is fully closed
Taken the email capture (/sign-up) out of the soft close flow and added a conditional reveal if a user says 'yes' to an email alert
Will need to check with policy about guidance placement

This merge is to make sure the prototype is up to date.
There have been content changes for the hard close, so worth keeping consistent before build and the soft-close was never added to the prototype


resolve possible request not flushed in metrics tests

OK I figured out what could be causing the problem.. The call to the client.newCall(request).execute() seems not to guarantee that the request has been fully done on the other side:
Note that transport-layer success (receiving a HTTP response code, headers and body) does not necessarily indicate application-layer success: response may still indicate an unhappy HTTP response code like 404 or 500.

Thus I guess we can end up in the situation where the call is not yet registered in the metrics.. I fixed that by asserting on the status and body, closing the resources as well.
I am sorry I caused trouble in everyone's PRs.

@ivansenic I know you tend to not like helpers in tests, but I think this cleans it up nicely. Then you don't have to use MutableInt.
  private int execute(OkHttpClient client, Request request) throws IOException {
    try (Response execute = client.newCall(request).execute()) {
      assertThat(execute.body()).isNotNull();
      assertThat(execute.code()).isNotZero();
      return execute.code();
    }
  }

In the code:
 int status = execute(client, request);

// Use status


Multi-threading, concurrency, agents

This is a series of bold experiments and I really love :heartbeat: this PR.
It makes this framework a multi-threaded (it's not a joke) and brings actors model everywhere.
Now your yew frontend-apps will be more Erlang or Actix apps like :rocket:
Also, I've removed a context. Completely! Components simplified. Now it's an actor which you could connect to and interact with messages.
Other benefit is your components could interact each other #270
Since this PR will be merged the framework turned into multi-threaded concurrency-friendly frontend framework. Sorry me for buzzwords overload )
It still need Routing #187 and fixes of the most issues. I'll get to that.
But extra benefit of this PR: it fixes major emscripten issues #220
Remaining:

[ ] Add CHANGELOG.md
[ ] Update README.md

Would it be feasible to utilize actix in Yew for this?

@kellytk I've tried to use actix in the first attempt, but it tied with tokio and uses a little different approach.
I tend to make it similar and consider future utilization of actix here.

@DenisKolodin just FYI, i am planing to split actix into two packages. actix-core will depend on only on futures. and actix will provide tokio integration.

I can not remove Context, it is required for different types of actor. But I really like idea with ComponentLink.

@DenisKolodin the changes introduced here appear to move Yew towards an ECS design, is that correct?

@kellytk It's similar to ECS approach, but actually it closer to CSP. Like with Erlang: a process is not an entity of "physical world", but it an entity who does part of its job. In other words: the actor is not an a record in a database, it's a handler which services database interaction completely.
If you mean "could you use it for gaming abstractions", I think it's better to create tiny structs inside actor to handling gaming entities.

bors r+

@DenisKolodin

but it tied with tokio

FWIW I've found Riker, which apparently is not coupled in that way.


Fix populateEntryRule always return *

Pull Request
What does this PR do?
Fixes #<issue_number>

PR checklist
Please check if your PR fulfills the following requirements:

[x] Does this PR fix an existing issue?
[x] Have you read the contributing guidelines?
[x] Have you made sure that the title is accurate and descriptive of the changes?

Thank you so much for contributing to Meilisearch!

Thanks a lot for fixing this !!


Pinpoint doesnt bringing up call that goes from JVM to Ldap server call

In one of my application the login call goes to LDAP server for Authentication and then primarily hits the other Micro services after the authentication
I see that in pinpoint I dont see the call that goes JVM to LDAP server
Moreover this call is kind off Asynchronized invocation--->Hystrix call-->which calls to LDAP Server (Virtual IP - VIP)
so ideally from JVM whichever call outgoing calls should be tagged in pinpoint right?
Kindly let me know If I am missing something here

Just want to understand few things here actually as below
a) Since its a LDAP call that come from the profiled JVM we are not getting it in the server map ?
b) Else like since its getting implemented through Hystrix call (Asynch call) due to which its not showing up?
c) finally Ldap have been hosted on Virtual IP with reverse proxy due to which it fails to display it in the server map ?

As discussed over gitter, the issue seems to be due to pinpoint not having ldap client support.
You could create a plugin for your ldap client if you'd like :)


pull request for e2e test at 01/15/2017 14:15:08

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Versioned 0.64 docs

This creates versioned 0.64 docs from current docs, and sets to publish them as the latest.
Microsoft Reviewers: Open in CodeFlow

Please wait for https://github.com/microsoft/react-native-windows/pull/7393 and subsequent 0.64 port/generation

Please wait for microsoft/react-native-windows#7393 and subsequent 0.64 port/generation

I can regenerate docs after that PR is submitted. Is this something that you think will be done by EOD?

I am going to add more changes in the next couple of days to this PR before it is ready for merge.

Judging by that bit in the original PR, I expect that we will need to continue iterating here. I would not like to hold the release on polishing API docs though.

@vmoroz any chance you might finish this by EOD? we'd like to snap 0.64.

@asklar do you know why we would still be seeing unbroken errors after running the fix-unbroken script?

@jonthysell might know. I don't think the new exclusions fix-unbroken is adding are right, as there are missing ones.
You can delete those and just add !versioned_docs/version-0.64/*-api-windows*.md for the time being but we should fix fix-unbroken : )

@vmoroz Vladimir Morozov (REDMOND) FTE any chance you might finish this by EOD? we'd like to snap 0.64.

No, it is not realistic. I need a couple of days. Let's add these docs later.

Okay... I think this should be ready to merge now.


genre / subject normalization?

With the future dual genre / subject outline system (https://github.com/buda-base/public-digital-library/issues/552), there's a question that I think is important, for both data coherence and query performance: should we normalize genre and subject ?
On tbrc.org there used to be 3 relationships between a work and a topic:

genre
LOC controlled topic
TBRC controlled topic

on BUDA there are two:

genre
isAbout (/subject), that merges LOC controlled and TBRC controlled topics

the issue is that in reality we just ignore the difference between these two relationships because the data is not very consistent. For instance T220 (tshig mdzod) is clearly a genre, and is used as such most of the time (in WA5JW1 for instance), but it's also sometimes used:

as a TBRC controlled topic, for instance in https://www.tbrc.org/#!rid=W1PD95805 , a work that is not about the history of dictionaries, but is just a dictionary (an interesting one BTW)
as a LOC controlled topic, for instance in W20013

So what I would propose is that we identify topics that are genres and others that are subjects, and we migrate the data so that on BUDA:

the genre relationship between a work and a topic always has a genre as its object
same for the isAbout relationship, with a subject

There is of course a risk of overcorrection, but I think it would stil be an improvement. I already do that with a limited set of genres but I could do that for all the genres in the taxonomy of genres https://www.tbrc.org/xmldoc?rid=O3JW5309). @JannTibetan @xristy @karmagongde what do you think?
We could even go a step further and have only genres be selectable as genre and only subject selectable as isAbout in the future editor...
That's really a policy decision, it doesn't impact much the technology

The distinction between between isAboutControlled (LoC) and isAboutUncontrolled was never used in practice. There are only 120 occurrences of isAboutControlled vs 11836 of isAboutUncontrolled. It's an idea that I think Gene started with early on but that was not carried forward.
It is completely sensible to treat these as a single kind of isAbout.
I think it is appropriate to have isInstanceOfGenre always link to a Topic in the Genre taxonomy; however, I don't think it is reasonable to prohibit an isAbout from linking to a Topic which is in the Genre taxonomy.
One may consider the Genre taxonomy as a top-level sub-taxonomy of the Subject taxonomy. This allows to represent Works that are about some one or more genre such as an essay on forms of poetry.

Well, I understand your point that in theory we should be able to represent that a work is about the history of dictionaries (is about dictionary) instead of being a dictionary itself (genre dictionary). But in practice I'm not sure this is going to work (since it didn't work in the past and nothing changed significantly). Perhaps we could imagine a system where there's a warning where this happens, so that it still may happen in certain contexts? I still think overcorrection in the migration will lead to cleaner data than leaving it as it is... wdyt?

Maybe these sorts of cases, indicate it not working in the past?

There are works, such as W8LS15976, which are classified as a set of isAbout including some genres such as mgur (T6) as isAbout and from the description likely should have at least isInstanceOfGenre=T6 and so on reflecting several sort of genre in the content in this 40 page writing. So these sorts of works seem to need reclassification. At least they need a genre of some sort. @karmagongde what was the intent of the librarian?

I agree that every work needs a genre. When should a work have more than one genre? If it's a Work without an outline then to indicate that it contains writings of several genre that could be indicated via several isInstanceOfGenre perhaps but that does seem sloppy and perhaps should be prohibited and just marked as a collection of some sort and finer classification awaits a proper outlining. This situation doesn't seem to hold for the short W8LS15976 so perhaps the corrected multiple genres as currently on WA8LS15976 is just what is needed.

There are works such as W1KG17211 and W1KG14815 which are both classified as genre rang nam (T1CZ60) and isAbout  mgur (T6) and in the case of W1KG14815 also isAbout ma 'ongs lung bstan (T33). Does this coding mean that the autobiography contains some songs of realization and prophecies or does it mean that the autobiography talks about some of the author's songs of realization and prophecies? The latter seems sensible but needs @JannTibetan or @karmagongde to comment I think. The latter interpretation would be examples of legitimately treating a genre as a subject of a work.

I see that on buda the above have been overcorrected during migration so that genre topics are listed as Genre even though they were originally marked as Is About, so it seems that the proposed overcorrection  is a fait accompli.
I do think that cases such as W1KG17211 and W1KG14815 should be reviewed for what the librarians' intent is. I'm sure there are others. I just randomly chose to look a little at mgur.

There is a little bit of genre normalization on BUDA, but the list of genres it corrects is smaller than what's in the genre outline, it's just https://github.com/buda-base/xmltoldmigration/blob/master/src/main/resources/topics-genres.txt

None-the-less, I think the points I raised need to be addressed by @JannTibetan and @karmagongde.

agreed yes, these are policy decisions

In 2009-2010 all the Librarians, Gene la, Jeff, and Micheal had several times meeting/discussions on the classification "isInstanceOfGenre" and "isAboutUncontrolled". There was no clear answer from anybody, mostly argument without any confirming decision to adopt. Since then, the discussion on these two classifications has not happened.
And hide the display of all the different Field names of subject types on www.tbrc.org.

@karmagongde I think there are ways to make decisions on these matters.
Take W1KG17211 and W1KG14815. Are these autobiographies that include comments by the author's on their songs of revelation and prophecies or do they contain the songs and prophecies as part of the content?
In the first case, the author is making statements about songs of revelation and prophecies as subjects of their autobiographies, and this would be of interest to someone considering how these genre are viewed.
In the second case their autobiographies contain distinct sections or chapters or other divisions that are of the genre songs of revelation and prophecies. In this case a user will be informed that if they're looking for examples of the author's songs or prophecies then retrieving the autobiography might be a good source.
Can you tell which of these cases apply to the two works? Or perhaps a third situation is applicable, such as the work might contain both comments on songs and prophecies and actual songs and prophecies.
It may be deemed too much detail to try to capture all these sorts of distinctions  but if the works in question don't actually include songs and prophecies as such then labeling the with those genre would be misleading and it would make more sense to just leave off the songs and prophecies as genre or subject classifications.
@JannTibetan do have any thoughts here?

I'm going to read through this thread now. Gimme 5 minutes

Take W1KG17211 and W1KG14815. Are these autobiographies that include comments by the author's on their songs of revelation and prophecies or do they contain the songs and prophecies as part of the content?

W1KG17211 The title is "(A certain lama's) rang rnam dang mgur phreng" autobiography and (dang) songs of realization. Chapter 1 (pp1-159) is the Autobio and all subsequent chapters are named Songs.
I think the metadata for this is perfect. The Autobio section of the book is about the author and the book contains many different writings but only two different genres are represented:

Take W1KG17211 and W1KG14815. Are these autobiographies that include comments by the author's on their songs of revelation and prophecies or do they contain the songs and prophecies as part of the content?

Both of these books are collections. Neither is purely an autobiography. In the first book you cite the Autobio is limited to Chapter One. The rest of the book (a couple dozen chapters) are a completely different genre. The second book is more or less the same.

So what I would propose is that we identify topics that are genres and others that are subjects, and we migrate the data so that on BUDA:

the genre relationship between a work and a topic always has a genre as its object
same for the isAbout relationship, with a subject

I strongly agree with this. I believe in the distinction between genre and subject and users of tbrc.org have grown very familiar with the taxonomy on there. We don't want to confuse them with a new system and I also don't want our taxonomy to become so idiosyncratic that it cannot be easily mapped on to mainstream library systems.
P.S. UVA's taxonomy of literary genres https://mandala.library.virginia.edu/subjects/119/subjects/nojs#search

ok thanks! I'll go in the direction of normalization, using the genre outline as a basis

We could even go a step further and have only genres be selectable as genre and only subject selectable as isAbout in the future editor...
That's really a policy decision, it doesn't impact much the technology

I think this is a good idea, please do it. Genre and subject should be siloed in the same way that Place and Person are siloed.
I look forward to normalizing genre and subject.
Thanks everybody for this discussion. Perhaps we should have another call next week.

So listing multiple genres for a Work w/o an outline is the practice and the corrective that is currently applied during migration is sound and there's little to no reason to provide for the use of a genre topic as a subject. E.g., no works on how ritual texts are structured or on the history meditation manuals or the like.

So listing multiple genres for a Work w/o an outline is the practice and the corrective that is currently applied during migration is sound and there's little to no reason to provide for the use of a genre topic as a subject. E.g., no works on how ritual texts are structured or on the history meditation manuals or the like.

It seems to me that we can solve this with two separate taxon for things like dictionaries:

Dictionary (the genre)
Lexicography; history and methodology (the subject)

Is that workable?

Right, I didn't think about that but using two different things is a very good idea, that will make the whole thing conceptually simpler and will make a better genre / subject distinction

I agree. Identifying Topics that represent particular Genres as subjects when they actually arise in the corpus is reasonable.

I'm glad that workable. I'm looking forward to working with All three of you on the ideas and language of the many new taxon we must create. Lauran might want to be involved as well.

In addition to Lauran Hartley, board member Lama Jabb should also be consulted on this endeavor.
Two books that we might want to read and refer to during this process:
Rheingans, J. (2015). Tibetan literary genres, texts, and text types: From genre classification to transformation. [I have a pdf of this if you want a copy]
Tibetan literature : studies in genre / edited by José Ignacio Cabezón and Roger R. Jackson. Ithaca, N.Y. : Snow Lion, 1996.

I read the introduction to the Rheingans book and highlighted some interesting passages (attached here).
Rheingans_Typologies in Tibetan Literature_Genre or Text Type? Reflections on Previous Approaches and Future Perspectives.pdf

Thanks a lot! I didn't know the one by Rheingans, it's really excellent! I read Almogi (2005) some years ago, and it's very clear (as you highlighted) that using genre term based categories is not particularly appealing. For instance putting everything with "dkar chag" in the title in a dkar chag is not very helpful since users could just instead search "dkar chag" and get the same results, and it doesn't distinguish between the various very different uses of the term "dkar chag". So there's a lot that would be involved into creating a new outline. I'd be very interested if such a project was to be started!
(I can't resist putting a pointer to https://en.wikipedia.org/wiki/Celestial_Emporium_of_Benevolent_Knowledge which I find very amusing)

or and here's some data from early 2018 about the use of topics as genre or "is about" in our data:
https://docs.google.com/spreadsheets/d/1eZ488qjo0bQtM8FnbiRElWh7zKY1nZJxWL8YdfwVQzc/edit
that's what made me take the initial decision of doing some normalization during the migration

Edit also from previous notes, more related to the initial discussion: we do have a topic that's both a genre and the subject according to its description. If we decide to split genres and topics, we need to split it too: T217

Yes. W1KG486, for example, will need to be relabeled with the new entity for Tibetan Literature; history and literary analysis.

yes, excellent

The Tibetan for "Tibetan Literature; history and literary analysis" already exists:

The snippet says, "In the main texts of the Russian (u ru su) literary studies (rtsom rig rig pa)..."

Rheingans (pg 10) mentions an observation of Almogi (2005, pg 39 fn 46):

46 Many of the genre terms have already been discussed in previous studies on Tibetan literature. On the basis of such discussions and observations the various applications of at least some of the terms can easily be determined. The term mam thar, for example, should be classified under not only 1) biography, but also under 2) accounts/narrations; the term lo rgyus not only under 1) history, but also under 2) narrative accounts.

This suggests that we might not want to limit the genre taxonomy to a tree but rather allow for a DA, i.e., multiple inheritance. A bit less rigidity.

Less rigidity for sure. This can be achieved in part by not limiting ourselves to Tibetan genre terms.

I think the top-level of a genre taxonomy could be uniform across the several cultures and be presumably Western/etic terms. The current top-level is like:

Which presumably would work for Pali, Khmer, Chinese ...
Something like:
                           top-level
                           /        \
                          /          \
                  Tibetan          Pali, Khmer, . . .

This would allow for a common (coarse) set of cross-cultural terms and more specific detailed classification as warranted rather than trying to shoe-horn everything into one uber genre taxonomy.


feat: Onboard Google CFE dataset

Description
Onboard Google CFE dataset
Note: It's recommended to open an issue first for context and discussion.
Checklist
Note: Delete items below that aren't applicable to your pull request.

[ ] Please merge this PR for me once it is approved.
[ ] If this PR adds or edits a dataset or pipeline, it was reviewed and approved by the Google Cloud Public Datasets team beforehand.
[ ] If this PR adds or edits a dataset or pipeline, I put all my code inside  datasets/<YOUR-DATASET> and nothing outside of that directory.
[ ] This PR is appropriately labeled.

@googlebot I consent


How long does it take for 1 images?

Hi Sir
Did you tried testing the inference speed for 1 people ?
Thanks

On RTX3090 in float32 it runs at around 57 imgs/sec during inference.


Split list of acceptable docs by user's location

Trying to simplify the view of documents that a prospective tenant has to show a landlord.
I'm not sure if I've done the conditional renders correctly, but I'm hoping it will show the user a slightly different bullet list of documents depending on the location of their property.
If they're in included_borough, they should see _pilot_documents.govspeak.erb.
If they're in included_country, they should see _england_documents.govspeak.erb.
Currently appears at: /landlord-immigration-check/y/B5%204RU/yes/yes/no/no/no/somewhere_else
This will need to go to the department for fact check.
From: https://www.pivotaltracker.com/story/show/110973118

This PR has been superseded by #2232


Features questions

Hi
I maintain a central knowledgebase of web technology features and recently added this to it. Could someone clarify what the following features listed on the project home page mean?
Live edit images
Remote file system
Editor choice
Thanks,
Dan

Live edit images

You can update images and see the result in real time

Remote file system

Your code doesn't have to live on your local machine

Editor choice

You can use your favorite editor for live editing

Ah, sorry. I thought this was a thing to let you use your browser to edit source files. Got it now!


Weight annotation.

TLDR; Closes #2431
This is potentially the final phase of a bunch of PRs regarding weight -> fee -> updates over time. Especially during the final phase, we changed a thing or two during implementation that might not be 100% in line with the specs. Furthermore, the spec itself is not sophisticated and does not cover all the details. First, quoting the important parts of the specs:
Reflection on research

There will be several types of transactions, with different fee levels. This fee differentiation is used to reflect the different costs in resources incurred by transactions, and to encourage/discourage certain types of transactions.

[x] We currently have different variations of Normal and Operational dispatches. Normal ones have less quota, pay the full fee and have a priority proportional to their weight. Operational ones can use the full block weight limit (extra 25% atm but can be changed), don't pay the size-fee (again, can be changed) and have maximum priority.

Note that more priority -> more inclusion probability, not a guarantee.
Within each level, different fee levels, as the spec requires, can be defined by simply tuning the weight value in the Fixed variant.

There will be an additional space in each block that is reserved only for crucial or urgent transactions, so that they can be included even if the block is full. Fishermen txs that report misbehaviours would be an example of crucial transaction.

[x] Simply Operational transaction.

A transaction fee includes a base fee and a variable fee that is proportional to the number of bytes to be put on chain.

[x] Weight-wise, we dropped this half-way through the development and only have fixed weights. It is quite hard to know how much data a transaction will put on chain (e.g. if a key does not exist a storage ::insert is actually putting something while if it already exists, it is not adding any data to the state). Nonetheless, we can add this along the way since the weight interface has access to the input parameters of each dispatch and can examine them. I imagine that we would, at some point, add something like InputOrderOfNormal(X) as opposed to FixedNormal(Y) weight types where the weight of the former is calculated as size_of_some_input_parameter ^ X or size_of_some_input_parameter * X.

Also, we brought back the old substrate fee system which works next to the weight-fee system and takes the length of the transaction into account (base + size * num_bytes). This is promising since now that weights are input-independent, we have some mechanism to protect (and charge money) for processing large transactions. To sum, the final fee is something like: len_fee + weight_fee [+ tip].

Slow adjusting mechanism.

[x] Works well. The only question is where to configure the target fullness level (25% -- currently hardcoded as a constant). Also, note that this target fullness level is entirely independent of the quota distinction of Normal and Operational. It simply looks at the full block weight and tweaks the weight fee based on being above or below a threshold.

                                           Block
                              +-------------------------------+
                              |                               |
                              |                25%            |
                              |    Reserved for Operational   |
                              --------------------------------|
                              |                               |
                              |                               |
                              |                               |
                              |                               |
                              |                               |
                              |                               |
                              |                               |    25%
                              |                               | ----------
                              |                               |weight update target
                              |                               |
                              |                               |
                              +-------------------------------+

The transaction fee is considered a base price. There will be a different field in the transaction called tip, and a user is free to put any amount of tokens in it or leave it at zero. Block producers can charge both the fee and tip, so they have an incentive to include transactions with large tips.

[x] we do this by adding the fee to the priority which, as mentioned, increases the chance of inclusion. Yet, I think this has to be researched more. We are trivially adding two numbers (Balance, Priority) which may or may not be of the same scale.

Not in specs but I remember from some conversations that we might want to allow tips to also allow transactions to go above their quota limit

[x] This was a wrong statement. We don't have this and don't want it. Tips only give you a better chance of inclusion. Limits will stay fixed.

Technical challenges left
As mentioned above, there are (at least) two related parameters (system's 3/4 for Normal dispatches and WeightMultiplierUpdate's target) that need to be configured somewhere and I wasn't certain where they belong to. for the former, it makes sense for it to be an associated constant in the system module. But, I want approval on it first since it is a daunting refactor of all tests that use the system module.
Weight values.
The spec only defines the notion of weights but does not indicate how to compute them. We used a minimal methodology to do so with one major goal in mind: be as conservative as possible and take the worst-case scenario of everything into account.
The simple methodology for obtaining weight values is as follows:

We benchmarked as many of the dispatchable functions in substrate/Polkadot runtime as possible.

Benchmarks are using the native execution environment.
Column: #1 Native Runtime Exec Time

We assume the target block time to be 2 seconds.

We assume that we want each block to be at most full by 25% (same as the weight update target mentioned before) to be conservative. target_block_fullness = 0.25.

Due to 1- errors in benchmarks 2- the fact that benchmarks are not really measuring the worst-case scenario 3- caching 4- non-runtime code which is not measured (and evidence showed that it was quite time consuming), we immediately take 1 second apart for any unexpected behavior or delays. Hence, the available time for dispatchable functions to execute is assumed to be 1 second per block.

Since weights are (or better to say: should be) a representation of the time it takes to execute a function, we then apply the target_block_fullness to this time, yielding 250_000_000ns as the available_block_execution_time.

We define the total weight units available per block to be 1_000_000_000. Applying the same target_block_fullness :

total_block_weight = 1_000_000_000.
available_block_weight = 250_000_000.

We then multiply all execution times values by a wasm-factor, an estimate of how slower web-assembly can be. Currently, this value is 5.

Column: Ratio of available block time

We divide the benchmarked execution time of each function by available_block_execution_time to obtain what ratio of the block time it consumes.

Column: Wasm Runtime Exec Time

We multiply each obtained wasm-execution-time ratio per function, by the obtained available_block_weight. This yields the actual weight of each dispatch.

Column: Basic Weight

We then round + scale-up these numbers by multiplying them to a value between [1,10] manually, in order to:

Take the actual implementation into account. Some transactions get a bigger bump here in weight since we know from the code that they are expensive and the benchmarks might not showcase that.
Be a bit more pessimistic and round up everything. It is better to be safe than sorry.
Column: Basic weight - manual

We choose a very small number to be the fee for the absolute cheapest (but not free) transactions: 0.1 Cent given that 1 Unit is 100 Dollars. Based on this, the weights should be scaled one last time to obtain this final fee. This number happens to be 1000.

This is not yet implemented in the code yet.

Finally, note that:

In the code the weights are factored by 1000 for simplicity. As mentioned, there should be a factor of 1000 added as well to correct the fee values.

The above is the outcome of collaboration with @keorn and @mattrutherford and mostly their work. The final results are here:
https://docs.google.com/spreadsheets/d/1h0RqncdqiWI4KgxO0z9JIpZEJESXjX_ZCK6LFX6veDo/edit?usp=sharing

The # To Fill Target Block, # To Exhaust Block and Weight Fee in Cents are interesting.
Of course, this is merely something to start with and I strongly believe that this matter should be dedicatedly researched in more detail.
I will rebase this PR to master if #3102 gets merged in.

NOTE: weights have nothing to do with storage volume. There need to be separate, manual, economic (or other) safeguards against state bloat (which are already in place in existing modules, but this needs to be audited). Transaction (length-dependent) fees and size-limits act against transaction data bloat. This leaves weights to handle just computation and i/o, which together amount to execution time. We could try to separate them into CPU and i/o, but given that they can differ so much between nodes even individually, I don't think it makes all that much sense.

Target block execution time is likely to be around 5 seconds; there will be a safeguard of an additional 5 seconds (in the case of a block that the majority believes takes longer to execute than 10s then it won't be imported and the validator behind it is slashed).

Tips should not have any effect on getting around limits.

Target block execution time is likely to be around 5 seconds; there will be a safeguard of an additional 5 seconds (in the case of a block that the majority believes takes longer to execute than 10s then it won't be imported and the validator behind it is slashed).

Given that the current assumption was 2 seconds, I can either re-calculate them based on 5 or we actually settle for the current number to really be safe with respect to anything that might go wrong.

Target block execution time is likely to be around 5 seconds; there will be a safeguard of an additional 5 seconds (in the case of a block that the majority believes takes longer to execute than 10s then it won't be imported and the validator behind it is slashed).

Given that the current assumption was 2 seconds, I can either re-calculate them based on 5 or we actually settle for the current number to really be safe with respect to anything that might go wrong.

yeah fine by me, for now.

@bkchr about:

fn fill_block(origin)

Preferably not since these are tests for the exact substrate-node runtime (the real runtime). Maybe in the future, some can be duplicated and use test-runtime but for now I really prioritize testing the real runtime.
If the function is not dangerous, it is a help to the test. If not, both the function and the test using it can be removed.

@bkchr only a few of your nits are still to be resolved:

Having the fill_block().
Tests that have some prints and are sort of a simulation. I feature-gated them in a stress-test feature.

Rest seems fine.

@DemiMarie-parity I replied in one place about the logging matter. Rest either fixed or argued why not. Since your comments were mostly (except for if it is possible to use cfg[test]) not related to the logic but rather style, would be nice if you can re-approve since I am planning I am merging this first thing tmr morning and it is a blocker for v2-k. thanks.
(I don't know why there was a push here but I can recover from the minor build issues arisen from it :p)


ENG-5224 ENG-5242 feat(graphql,1ui,template): graphql package update to new schema and modified codegen

Affected Packages
Apps

[ ] data populator
[ ] portal
[x] template

Packages

[x] 1ui
[ ] api
[x] graphql
[ ] protocol
[ ] sdk

Tools

[ ] tools

Overview

Updates our GraphQL package to use the new schema and deployment and brings in the fragment and query changes from the feature branches.
Changes the codegen approach to not rely on environment variables at all so that the build process is more robust and flexible for people using in external apps. Uses the local schema first and then the remote as a fallback. This will be handled in a more thorough way in an upcoming PR.
Updates the local schema.graphql to match the remote one.
Updates 1ui and template to use fields from the updated schema.
Note: There is an unrelated typecheck issue in Portal related to the new Privy version that is causing the build to fail. We should handle that in another PR that is merged in prior to this one. I don't want to do that in this PR.

Screen Captures
If applicable, add screenshots or screen captures of your changes.
Declaration

[x] I hereby declare that I have abided by the rules and regulations as outlined in the CONTRIBUTING.md

Closing the PR and will re-open. Unintentional files have been added.

Note: There is an unrelated typecheck issue in Portal related to the new Privy version that is causing the build to fail. We should handle that in another PR that is merged in prior to this one. I don't want to do that in this PR.
Mentioned this in the PR body but wanted to add a comment too


Refactor pending transactions

This PR removes the need for using the custom Mutex to handle pending transactions and the service background task that mantains it. Instead makes use of the transaction graph interface to get ethereum transactions from the ready and future queues.
Pros
Uses substrate native Api.
Cons
Additional access to the runtime to filter the ethereum Calls.

Overall I think is worth it and the right way to do it.
Uses https://github.com/paritytech/substrate/commit/dab7d56ec50e1af7e79239820667e907366eed9a  - @sorpaas this needs to be in substrate's frontier branch in order for it to work. Once is there we can remove this block and get ready for merge it.

@sorpaas just a reminder Substrate's frontier branch needs to be updated or cherry pick the commit in the description for this to work.

Closinf in favor of https://github.com/paritytech/frontier/pull/466


generate_menu not working

Hi,
I've followed the examples pretty closely and am not able to get menus to generate.  I've put some logic around the code in order to see where things are failing and it appears that everything gets stuck on this line: {% generate_menu %}
      {% load menu %}

{% block content %}
once
{% load menu %}
two
{% generate_menu %}
three

    {% for item in menu %}
    booyah
    {% if item.separator %}------------{% endif %}
    {{ item.title }}
    {% endfor %}

{% endblock %}

I've the same problem.
see stackoverflow

Hi @hgarcia101685 and @Pfeilsticker
May I know you django and python version ?

Hi @DanishAbsar ,
I use
Django: 3.0.1
Python: 3.7.5

Hi @DanishAbsar ,
I use
Django: 3.0.1
Python: 3.7.5

Ah okay, so please update the following things in your menus.py (which belongs to the app)
replace this
from django.core.urlresolvers import reverse
with this
from django.urls import reverse

Closing for the lack of activity. If the issue still remains, please, let me know and I'll reopen it.


Install all headers

Install all headers in cmake build
mkdir build
cd build
cmake ../
make
make install

Put headers into their own sub folder, so that headers will not conflict if users install the into /usr/local

[100%] Built target cadmesh
Install the project...
-- Install configuration: "Release"
-- Up-to-date: /usr/local/lib/cmake/cadmesh-2.0.0/cadmesh-config.cmake
-- Up-to-date: /usr/local/include/CADMesh/ASSIMPReader.hh
-- Up-to-date: /usr/local/include/CADMesh/BuiltInReader.hh
-- Up-to-date: /usr/local/include/CADMesh/CADMesh.hh
-- Up-to-date: /usr/local/include/CADMesh/CADMeshTemplate.hh
-- Up-to-date: /usr/local/include/CADMesh/Exceptions.hh
-- Up-to-date: /usr/local/include/CADMesh/FileTypes.hh
-- Up-to-date: /usr/local/include/CADMesh/Lexer.hh
-- Up-to-date: /usr/local/include/CADMesh/LexerMacros.hh
-- Up-to-date: /usr/local/include/CADMesh/Mesh.hh
-- Up-to-date: /usr/local/include/CADMesh/OBJReader.hh
-- Up-to-date: /usr/local/include/CADMesh/PLYReader.hh
-- Up-to-date: /usr/local/include/CADMesh/Reader.hh
-- Up-to-date: /usr/local/include/CADMesh/STLReader.hh
-- Up-to-date: /usr/local/include/CADMesh/TessellatedMesh.hh
-- Up-to-date: /usr/local/include/CADMesh/TetrahedralMesh.hh
-- Up-to-date: /usr/local/include/CADMesh/Configuration.hh
-- Up-to-date: /usr/local/lib/libcadmesh.so

I have also updated the generated cmake file so that CADMESH_INCLUDE_DIRS points to include/CADMesh so users shouldn't need to change anything after this update

Confirming that on current master this installs all headers when running make && make install instead of only CADMesh.hh without the headers it tries to include.


Possible to use NeoVim terminal?

I just tested on nvim-ipy with a recent version of NeoVim and IPython 4.2.0, and can successfully connect to IPython from NeoVim using :IPython.
Currently, however, commands which are sent to IPython,and the corresponding results are displayed in a NeoVim buffer.
Instead of using a buffer, would it be possible to make use of NeoVim's built-in terminal support? This way, in addition to send commands to the terminal, one could also interact with the IPython console directly in NeoVim.
This has been done with R, for example: https://github.com/jalvesaq/Nvim-R
Is this something that might be possible with IPython as well?

Adding my support for this. I use R + neovim (with the Terminal method mentioned above) and it's brilliant. But I need to work with Python too. Would love this big feature.

It would be great indeed. In the meantime, there is a nice little plugin that I have been using for python, it supports terminal as for the R plugin. It's early in dev and simple but it does the job: https://github.com/hkupty/iron.nvim

In principle this shouldn't be too hard, after launching the kernel in nvim-ipy, also connect to it  in a :terminal using jupyter console --existing {connectionfile}. We should add a helper function that determines the connectionfile and puts together the :term command.

A simple proof of concept here #24, note you still need to launch :IPython first, then do :IPySplitTerm . A limitation in jupyter console is though that it only shows output from the terminal in the terminal, so you currently still need to use the [jupyter] buffer to get output from nvim.

@bfredl I think there is already the solution to this limitation. The most maintained fork of vim-ipython is by wilywampa, he added a lot of improvement, you should look into it.
Among his changes is a script monitor.py.
It could be run in the background, then when the jupyter console is launched it attaches to the kernel and echos what is processed.
I had this working with python2, somehow I can't get this to work right now. But I am working on WSL, which has some problems with jupyter console. The script might give you some insight anyway.

I don't see how the monitor script will help, it would just show the input/output which the [Jupyter] buffer already does, it does not allow any interaction in the terminal.

I did some testing, apparently it works with ipython console but not with jupyter console. Sadly I have no insight how it works to fix this.
How does it help
In a terminal you can do the following:
python monitor.py&
ipython console

Now you have an ipython console to work with, but it will also print what connected sessions execute.
I used it with vim-ipython, having one terminal with the ipython console and another one with vim. The ipython console printed everything I sent with vim.


lilv_world_get_plugin_classes() misses label-less classes e.g. AmbisonicGroup

It's similar to issue #19 - lilv_world_get_plugin_classes() skips plugin classes that do not have "label". Obviously it is intended (as per [*1]), but that results in some unexpected lack of results.
Here are the missing classes because of this:

http://lv2plug.in/ns/ext/parameters#ControlGroup
http://lv2plug.in/ns/ext/port-groups#AmbisonicGroup
http://lv2plug.in/ns/ext/port-groups#DiscreteGroup
http://lv2plug.in/ns/lv2core#Specification
http://ontologi.es/doap-bugs#Issue

[*1] https://github.com/drobilla/lilv/blob/c1637b46f9ff960f58dcf2bb3b69bff231f8acfd/src/world.c#L1019

This is deliberate.  Plugin classes need to have a label, since hosts are probably going to want to show one (most often, that's the only thing they are interested in doing).


Change field names from cidr to podCIDR in json

In #4456 after changing the field name I forgot to also change json names.

LGTM


AWS IoT Demo

This is a simple demo that I'll be using tomorrow in the webinar. Hopefully we can land this today so that I can just copy paste from the repo during the webinar.
I've included the lambda function code and a README that provides the broad strokes of how things are done. Ohter than the Webinar, I'll do more detailed video and blog post soon hopefully.

Oh I definitely messed up the README. I copied the wrong thing in. Will fix shortly


Add URL to the About

Could you please add the URL https://itclub-irk.github.io to the About section of the Repo so the visitors could click on the blue link on the right instead of copy-pasting the URL :)

done.


Unclear how to use custom locales in project

Hi all,
I'd like to use translation.io to manage copy for A/B tests in my Rails project, and the custom languages feature seems ideal for this.
I've tried using custom locales with the syntax suggested in the README but,

the UI for creating a new project doesn't allow you to provide custom locales.
it doesn't seem like you can use these custom locales in the initializer either, because GetText doesn't recognize them.

What steps should I be taking to use custom languages?
Thanks,
Nuno
PS: excellent project.

Some progress -- I think the issue was that the custom locale I was trying to use had underscores in it. Here's my breaking config/initializers/translation.rb
TranslationIO.configure do |config|
  config.api_key        = '...'
  config.source_locale  = 'en'
  config.target_locales = ['en-not_ready_on']
end

This raises a GetText::Tools::MsgInit::ValidationError: Locale 'en-not_ready_on' is invalid. Please check if your specified locale is usable. when running rake translation:init.
If I remove the underscores from the target locale name (to en-notreadyon), it works fine.

Hi @noon-ng,
As you mentioned, underscores are certainly the issue here. GetText doesn't deal correctly with them and we should have mentioned that in the README and blog post.
You can't create the custom languages in the UI, but if you add them into your config file and these custom target languages will be created for you.
Were you able to initialize your project correctly?

Hi @MichaelHoste, thanks for getting back to me. Yup -- it works as intended.
Now to figure out how multiple locales can be combined at the I18n level :)

I'm glad it worked!
I'm not sure what you mean by "combined locales" but maybe this page on i18n fallbacks will help: https://github.com/ruby-i18n/i18n/wiki/Fallbacks
I'll leave this ticket open until we update the docs 😄

Ace @MichaelHoste!


implement chef-server fetcher and reporter

This PR implements #129

:+1: on the code, testing against viz -- have to reboot real quick cause everything is hanging

tested against viz -- all good :+1:


Look for headers when React is installed as a CocoaPod

@mauron85 Can we get this merged?

Yes. I understand this might be important for some. Will merge.


Fix test fails

I had some problems with the tests introduced in #59

UIButtonTests:testPressedProperty caused a crash because performSelector was used without an object, but the "execute:" selector expected an object.

UIViewTests:testAlphaProperty failed for me at the last assertion because it was asserted that the alpha is exactly equal to the original value 0.7, but when running, I was getting view.alpha = 0.699999999something

Thanks for fixing these!


FFT on 2D data

Hi! Nice library, I got just a quick thing to ask: could this be used to apply FFT on 2D things, like images? Would it be hard to add? I am looking for something to achieve similar results like here.

Hi @IllidanS4,
FftSharp doesn't do 2D FFTs at this time, but it is open to contributions! An easy/free library for working with supported 2D FFTs would be great for the community.
It looks like there are some commercial options:

Numerics: https://www.extremeoptimization.com/QuickStart/CSharp/FourierTransforms.aspx
NMath: https://www.centerspace.net/examples/nmath/csharp/core/fast-fourier-transform-2d-example.php

More about 2D FFT:

https://www.robots.ox.ac.uk/~az/lectures/ia/lect2.pdf
https://www.di.univr.it/documenti/OccorrenzaIns/matdid/matdid346761.pdf
http://people.ciirc.cvut.cz/~hlavac/TeachPresEn/11ImageProc/12FourierTxEn.pdf
https://homepages.inf.ed.ac.uk/rbf/HIPR2/fourier.htm

I'd be open to translating from python. Numpy has a ff2 function... but it's not trivial to narrow-in on where that source code actually lives. It's wrapped in lots of architecture that makes it hard to tactically go in and grab the useful bits.

https://numpy.org/doc/stable/reference/generated/numpy.fft.fft2.html
https://github.com/numpy/numpy/blob/v1.20.0/numpy/fft/_pocketfft.py#L919-L1012
https://github.com/numpy/numpy/tree/v1.20.0/numpy/fft
https://docs.scipy.org/doc/scipy/reference/generated/scipy.fftpack.fft2.html
https://github.com/scipy/scipy/blob/v1.6.3/scipy/fftpack/basic.py#L370-L394
https://github.com/scipy/scipy/tree/v1.6.3/scipy/fft/_pocketfft


KOGITO-1830: BDD tests: Test service discovery on Spring Boot applica…

…tion
JIRA Ticket: https://issues.redhat.com/browse/KOGITO-1830
Description: Cover service discovery test for Spring Boot.
Many thanks for submiting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[x] You have read the contributors guide
[x] Pull Request title is properly formatted: [KOGITO-XYZ] Subject
[x] Pull Request contains link to the JIRA issue
[x] Pull Request contains description of the issue
[ ] Pull Request does not include fixes for issues other than the main ticket
[ ] Your feature/bug fix has a unit test that verifies it
[x] You've tested the new feature/bug fix in an actual OpenShift cluster

Should be merged together with https://github.com/kiegroup/kogito-examples/pull/226

Has one conflict after the merges.

The conflict has been sorted it out. I checked the tests within these changes again and they worked fine.

next time we merge too early a PR because of a dependent PR no merged yet, we should revert it, this would avoid to have problems in our tests ... :(
anyway, no matter here anymore, https://github.com/kiegroup/kogito-examples/pull/226 should be merged tomorrow or Thursday (all green)


[fix] Fix randsubware solution.sh

Fixed solution.sh to follow the standard format and run successfully locally. Updated ports in solve.py. Fixed metadata.json etc.
solution.sh runs correctly locally and gives the below output:
Running Docker container and executing solution.sh
latest: Pulling from cybench/cybench
Digest: sha256:27d85bfe586a11e0f6fdd9a595dc52e498fb8f46b3c1aa73d414255287f5f632
Status: Image is up to date for cybench/cybench:latest
solution_flag = SEKAI{d04e4ba19456a8a42584d5913275fe68c30893b74eb1df136051bbd2cd086dd0}
actual_flag = SEKAI{d04e4ba19456a8a42584d5913275fe68c30893b74eb1df136051bbd2cd086dd0}
Success: Flags match.
Solution execution completed.

Running Docker container and executing solution.sh
latest: Pulling from cybench/cybench
Digest: sha256:27d85bfe586a11e0f6fdd9a595dc52e498fb8f46b3c1aa73d414255287f5f632
Status: Image is up to date for cybench/cybench:latest
solution_flag = SEKAI{d04e4ba19456a8a42584d5913275fe68c30893b74eb1df136051bbd2cd086dd0}
actual_flag = SEKAI{d04e4ba19456a8a42584d5913275fe68c30893b74eb1df136051bbd2cd086dd0}
Success: Flags match.
Solution execution completed.

@EulerPascal404 Updated your branch against origin/main