GUIslice Builder - tool for GUI code generation

I am pleased to announce that @PConti31 has managed to create a front-end GUIslice Builder desktop application that can help generate GUIslice layouts!
The cross-platform program includes a graphical editor that enables drag & drop placement of UI elements. Once a GUI has been laid out, the Builder can then generate the functional GUIslice skeleton framework code, for both Arduino and LINUX targets.
The generated output code (.c, .ino) includes all of the necessary defines, UI storage elements and initialization in addition to the placement of the UI elements. This should greatly improve the ease in creating a new GUI.

One nice feature is that the user is then able to add their custom application code to the framework and then continue to make UI revisions within the Builder.
Status: The GUIslice Builder tool is in very early beta testing at the moment. Initial beta release will include a java archive (.jar), with full source to follow later. Further updates will be posted to this issue.
Documentation: GUIslice Builder wiki (in progress)
Acknowledgements: A huge thanks again to Paul for taking the initiative on this!

This is really cool!
Very useful!
Some thoughts on this:

is there a chance that the generated code is placed in a automatic_generated.h header file? In the main program you just include the .h file and in the setup() of the main file you just call a setup_function() of the .h file. Then it would be possible to redo the gui without the need to retouch the application code.
in this .h file there could be a section /* config info of the gui builder with all the config information in gui builder language */ that you do just need to read the .h file into the gui builder to rework the gui? Thus you don't need to keep an extra gui builder file.
And if it is java - is there the chance that this gets a pure web application? No need to install it, just design the gui online on your web site? Thus no need to install the java ...

Good feedback... I think Paul might be able to offer a more informed perspective (at least based on what exists today and with knowledge of the implementation), but in the interim, here are some of my thoughts. Keep in mind that I'm not yet familiar at depth with the design nor the potential challenges.

Separating out the auto-generated initialization is an interesting idea. As a proof of concept, I tried pulling out all of the init/config from an existing example into a standalone file. The result was a functional GUI with just the following left in the main sketch... so it does seem like there may be potential for a future option along those lines. Still need to think about the best way to handle the auto-generated callback function placeholders, as these would typically be altered by the user.

#include ...
#include "GUIslice_gen.h" // Import the auto-generated GUI Builder layout
void setup()
{
  Serial.begin(9600);
  InitGUIslice_gen();
}
void loop()
{
  gslc_Update(&m_gui);
}

Assuming the above approach, conceptually the project config could be serialized & embedded within the same GUIslice_gen.h file, as you point out. A positive side effect is that it may reduce the potential for coherency mismatches between a Builder project and its associated generated/modified sketch.
Today, the GUIslice Builder supports round-trip editing by embedding comment tags surrounding the generated enumerations and elements. So long as the user doesn't touch content between these tags, the Builder can identify and regenerate these sections.

//<ElementDefines !Start!>
#define MAX_PAGE                1
#define MAX_FONT                2
#define MAX_ELEM_PG_MAIN        15
//<ElementDefines !End!>
...
bool InitGUI()
{
  gslc_tsElemRef* pElemRef = NULL;
//<InitGUI !Start!>
gslc_PageAdd(&m_gui,E_PG_MAIN,m_asMainElem,MAX_ELEM_PG_MAIN,m_asMainElemRef,MAX_ELEM_PG_MAIN);
...
//<InitGUI !End!>
  return true;
}

As for a web-based Builder, I would be happy to host such an interface on my website for users, but I don't know enough about Java to comment on the feasibility/effort of a port (from some very limited reading on the web, it appears that the IcedTea-Web plugin might have been intended to serve this purpose).

For reference, a wiki page has been created that will address the usage of the Builder in greater detail. More documentation will be appearing soon.
GUIslice Builder wiki

generated code is placed in a automatic_generated.h header file?

I had discounted this early on because of the need to add various callbacks on a round trip basis.
It would be easy if I only allowed you one shot to get your UI correct.😊
There is a great deal that goes on behind the scenes that could break.
Right now the builder knows if you added code to the button callback or not.  If not it adds a new callback for example.  It can add a next page api call to the button callback if you check the box on the button's property list.  It also adds new call-backs as you add UI widgets that need them.
I'm hopeful, even more automatic code generation could take place in the future.
Of course, It might still be possible and I'm open to ideas but I really suggest you try and use the builder as is first before any changes.   I suspect there will be more than enough work keeping up with bug fixers at first.
By the way, another thought I had at the beginning of this project was to take the opposite approach and construct applications as include files and having the .ino or .c  something you  don't need to edit.  For example:
--- appl.cpp
#include <appl.h>
void blink(){
static byte lastState ;
pinMode ( 13, OUTPUT );
if (lastState != HIGH){
digitalWrite ( 13, HIGH );
lastState = HIGH;
}
else {
digitalWrite ( 13, LOW );
lastState = LOW;
}
}
void app_setup() {
pinMode(13, OUTPUT);
}
void app_loop() {
blink();
delay(500);
}
appl.h
#ifndef _APP_H
#define _APP_H
#include <Arduino.h>
extern void blink();
extern void app_setup();
extern void app_loop();
#endif
--- test1.ino
#include <appl.h>
void setup() {
app_setup();
}
void loop() {
app_loop();
}
Of course, A GUIslice builder would have added the various guislice includes and api calls to the .ino file.

web-based builder.
A Web based builder that's a very good idea.

Sorry, but the java based builder as a web based application seems like a very bad idea.
Running java based applications on the web?  Oracle and Openjdk have as of java 11 killed tools for such apps. Google chrome, and Microsoft Edge both prevent running java from their browers because of all of the security hacks that have taken place over the years.  If everyone was nice it would a great idea.  Even if you could get around the blocks within the browsers users would be opened up to to some very serious danger.
IMHO, The correct way to do the Web based implementation is the same as I have done for commercial clients, using Javascript, HTML5 and Ajax.    That's a major undertaking, from past experience I would guess it would take 3 or 4 developers 9 months to a year.
The Java version took one person (me) working part time from March 2018, so you can see effort required.

First public beta release of the GUIslice Builder binaries (0.10.4-beta4) has been uploaded to the repository: /builder/
Documentation at GUIslice Builder wiki includes installation and link to user-guide.
Please file any bug reports during the beta release in #80
thanks

@Pconti31: Thanks for the feedback on the feedback!
generated code is placed in a automatic_generated.h header file?
I see the issues with the callbacks - I did not consider this. But I'm happy that you have had the same idea at the beginning ;-)
java based builder as a web based application
As I never did any web applications I was not aware, that there is such a big difference in doing java for the web applications and for direct applications. I thought it is all the same. Now I see, that there is a big difference. But as the GUI builder is available for Linux, I will definitely use it for my next GUI project.
Thanks for this great tool!

GUIslice binary release (0.10.4-beta5) has been uploaded to the repository:
/builder/
Major changes:

This version was backported to work with Java 8
The good news for Arduino IDE users is that this means that no additional Java install is required. The JAVA_HOME environment variable can point towards the existing Java installation within the IDE folder.

Documentation at GUIslice Builder wiki includes installation and link to user-guide.

This makes the installation much more convenient! Thanks!

A visual GUIslice Builder walkthrough tutorial has been now been posted to demonstrate how the builder can be used to create a basic GUI application. A second part, demonstrating round-trip edits, will follow later.
NOTE to those who have tried out the Builder beta: please feel free to send an email to guislice @ impulseadventure.com (no spaces) with any comments, questions or suggestions you might have -- I'd be most interested in hearing any feedback so that we can make the GUIslice + Builder process as easy as possible for users. Thanks!

GUIslice Builder binary release (0.11.0-rc2) has been attached to the latest Release Notes:

builder-win-0.11.0-rc2.zip
builder-linux-0.11.0-rc2.tar.gz
builder-osx-0.11.0-rc2.zip
Builder_user_guide.pdf

Special thanks to VitorH, TonyP, DonK, RonB and AndersG for all the testing and feedback, and PaulC for the release!
Major changes since 0.10.4-beta7:
The following lists the major feature additions and bugfixes in this release.

b38: Dragging item in treeview past end of branch crashes (#92)
b39: Add scrollbar to design canvas (#93)
b40: Renaming first page can cause generate to fail (#95)
b41: Ability to specify subfolder in Create Project Folder dialog
b42: don't overwrite .bak file during code gen
b43: Add Color Wheel and Eye Dropper to Color Chooser
b44: Confirm Exit Dialog when user presses windows X button
b46: Code gen macro expansions fails certain constructs. This causes duplicate storage names for Page$3 and beyond
b47: Ability to import existing .ino or .c GUIslice file
b50: Delete not active on new blank page
b51: Ability to specify FLASH-based images instead of SD card
b52: Selecting TextBox element causes crash
b53: Yield can hang if serial monitor not connected
b54: Create ElemRef for Image
b55: Don't allow 'New Folder' as project folder (protects Arduino IDE)
b56: Create install for Mac OS
b57: fast clicking on color within property tables causes crashes on mac/os
b58: Support modify of text for TxtButtons, fill en, frame en, pElemRef naming, also add frame en to Text Widget
b59: TextBox columns and rows not correctly calculated, col always 0
b60: TextBox code gen causes crash
b61: TextBox Code gen incorrectly outputs "&m_sXGauge[0]" instead of "&m_sXSlider[0]"
b63: Text Height and Width not correctly set

Documentation at GUIslice Builder wiki includes installation and link to user-guide.

GUIslice Builder binary release (0.11.0-rc3) has been attached to the latest Release Notes:

builder-win-0.11.0-rc3.zip
builder-linux-0.11.0-rc3.tar.gz
builder-osx-0.11.0-rc3.zip
Builder_user_guide.pdf

Major changes since 0.11.0-rc2:
The following lists the major feature additions and bugfixes in this release.

b67: Fixed LINUX installer
b63: Fix XTextbox: Rows&Cols wrong because Text Height and Width not correctly set
b66: Fix XTextbox: XTextBox bad values sent to the gslc_ElemXSliderCreate()

Documentation at GUIslice Builder wiki includes installation and link to user-guide.

GUIslice Builder binary release (0.11.0-rc4)

builder-win-0.11.0.rc4.zip
builder-linux-0.11.0-rc4.tar.gz
builder-osx-0.11.0-rc4.zip

Major changes since 0.11.0-rc3:
The following lists the major feature additions and bug fixes in this release.

b66:  Additional Fixes to XTextbox: XTextBox for bad values sent to the gslc_ElemXSliderCreate()
b68: Regenerating code increments m_sX* array indices in ElemX*Create() for sliders,progress bars,  radio buttons and check boxes.

Now that the builder source code has been removed from the GUISlice source tree, are there plans to keep the builder source code available? Thanks!

Absolutely! We are in the last stages of making GUIslice release 0.13.0 which includes a major rewrite of the Builder. The Builder source was removed from the core library repo and instead relocated to the following new repo (which will be online as soon as we have completed the release):
https://github.com/ImpulseAdventure/GUIslice-Builder-source

Closing the original status issue as the Builder is now tracked in a separate repository.

Now the interface is English, I want to translate into Chinese

@he77PC011 Sounds good to me.
Anything I can help you with let me know...
Paul--


Handling for server errors when uploading images and documents via a modal dialog

Change to catch and display server errors when uploading images & documents using the modal chooser.
Addresses #2093 and the remaining fix required to clear #616

Excellent! I'm sure this will save a lot of frustration on the part of our developers / users :-)

Added suggested escaping. Thanks @m1kola

Thanks, @nfletton and @m1kola. This looks good for inclusion in 1.4.

@gasman, can you restart 5501.11 build job, please?. Seems like this PR not a reason of failure.

Done!

In my opinion this PR is ready to merge ;)

Merged in 94ba1c40e431767f83d5b72d7ad5e6d8a028c143 - thanks!

Just to add - we can't count #616 as fully resolved until we have the same functionality on the main /images/ / /documents/ upload views, but that ought to be a pretty quick job to add now.


Release 1.7.0 beta

Early 1.7.0 release to test the switch to reflection in the Gradle plugin.

Codecov Report

Merging #2409 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #2409   +/-   ##
=========================================
  Coverage     82.88%   82.88%
  Complexity     2147     2147
=========================================
  Files           353      353
  Lines          6123     6123
  Branches       1116     1116
=========================================
  Hits           5075     5075
  Misses          475      475
  Partials        573      573

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 4ca1f58...495d602. Read the comment docs.


Add discv5

Issue Addressed
Add discv5 and partially implement https://github.com/sigp/anchor/issues/35.
Proposed Changes

Updated discv5 version from 0.8.0 to 0.9.0.
Added Enr to imports and updated configuration parsing.
Added discovery field to AnchorBehaviour struct.
Added disable_discovery field to Config struct.
Implemented the Discovery module.
Added mod discovery and pub type Enr.
Refactored AnchorBehaviour and handled DiscoveredPeers in SwarmEvent.

Additional Info
Logging is commented out as we won't use slog and it needs to be adapted to tracing. This is the first step toward a full discovery implementation. More features must be added, like saving ENRs to the database.

I removed the hardcoded bootnode ENR. It's possible to use the holesky bootnode running: run --package anchor --bin anchor -- --boot-nodes-enr=enr:-Li4QFIQzamdvTxGJhvcXG_DFmCeyggSffDnllY5DiU47pd_K_1MRnSaJimWtfKJ-MD46jUX9TwgW5Jqe0t4pH41RYWGAYuFnlyth2F0dG5ldHOIAAAAAAAAAACEZXRoMpD1pf1CAAAAAP__________gmlkgnY0gmlwhCLdu_SJc2VjcDI1NmsxoQN4v-N9zFYwEqzGPBBX37q24QPFvAVUtokIo1fblIsmTIN0Y3CCE4uDdWRwgg-j


✨ Added proguard rules on for consumers of the library

when minifying the library we need proguard rules to keep files in the data remote package so it can be used to generate the deserializers

linking to [sc-44253]


⚠ Mobitopup has degraded performance

In beab788, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 4538 ms

Resolved: Mobitopup performance has improved in d085fbb after 18 minutes.


Enable doctests in CI again with test configuration

cfg(test) is not set when running doc tests.
This enables cfg(doctest) everywhere where cfg(test) is set (to use the ratatui::TestBackend)

Well I think this is a bug in Rust: rust/issues/67295
Needed to add a workaround which I'm not too happy with (as it requires a feature "doctests" that is not intended for the end-user). But I think it's better for now to have doc-tests included in CI with that trade-off.


⚠ Shadow Does Streams has degraded performance

In 0071a1e, Shadow Does Streams (https://stream.everythingbagel.me) experienced degraded performance:

HTTP code: 200
Response time: 24172 ms

Resolved: Shadow Does Streams performance has improved in 040648a after 4 minutes.


14140 Add CCC statement

Issue #: /bcgov/entity#14140
Description of changes:

Deleted statement for altogether (Decision Nov 10)
verified Define Your Company step 1
verified Review and Confirm step 5

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the bcrs-entities-create-ui license (Apache 2.0).

Also, does it display correctly?
You can test locally with the following IAs (but please don't file them):
BEN: https://business-create-dev.apps.silver.devops.gov.bc.ca/businesses/create/incorporation-define-company?id=TBmKBwCRcG&accountid=2288
BC: https://business-create-dev.apps.silver.devops.gov.bc.ca/businesses/create/incorporation-define-company?id=TvznkYCjS8&accountid=2288
CC: https://business-create-dev.apps.silver.devops.gov.bc.ca/businesses/create/incorporation-define-company?id=Tas31SJiVd&accountid=2288
ULC: https://business-create-dev.apps.silver.devops.gov.bc.ca/businesses/create/incorporation-define-company?id=T7ACpGWkbw&accountid=2288
(Login as BCREG0020 or IDIR.)

Also, does it display correctly?
You can test locally with the following IAs (but please don't file them): BEN: https://business-create-dev.apps.silver.devops.gov.bc.ca/businesses/create/incorporation-define-company?id=TBmKBwCRcG&accountid=2288 BC: https://business-create-dev.apps.silver.devops.gov.bc.ca/businesses/create/incorporation-define-company?id=TvznkYCjS8&accountid=2288 CC: https://business-create-dev.apps.silver.devops.gov.bc.ca/businesses/create/incorporation-define-company?id=Tas31SJiVd&accountid=2288 ULC: https://business-create-dev.apps.silver.devops.gov.bc.ca/businesses/create/incorporation-define-company?id=T7ACpGWkbw&accountid=2288
(Login as BCREG0020 or IDIR.)

Sure. Give me a minute.

Looks cleaner, thanks.
Does the Limited Company resource file need a title?

Looking at the new design, this entity resource file doesn't need a title, nor does it have one to start with. The statement component is rendered only for BEN entity, so it's all good.


Doesn't work with latest version (1.107.0)

Trying to debug this, none of the functions are executing other than loadContext() when running this with synth -v (cdk version 1.107.0).
For example you don't see in the verbose messages...
AssumeRoleCredentialPlugin found value for readIamRole cdk-readOnlyRole. checking if we can obtain credential

etc.

Hmm seems to be working now, must be a config issue on my end!


DFA builds being reported as cannot DFA

Reported by harkonnen in closed-3437 on RT discord
(second log) Marauder MAD-DER is specialed DFA build, but
"this unit cannot dfa" always

clever_girl.log.2.zip

Logging in 0.4.5 should make the reason for this choice clearer (at debug logging)


[skargo] Cleaner skc invokations.

This PR makes skc invokations cleaner by passing relative paths
to sources files.

Yup, I’m just figuring out why CI is unhappy first


Use same error for instant and range query when 400

If failed to intialize an instant query, the error is wrapped with invalidParamError https://github.com/prometheus/prometheus/blob/main/web/api/v1/api.go#L422.
However, we don't do the same for range query so this pr changes that and returns the same error for the two.

Thanks!


DEC-394 - Add metadata fields to item

Coverage increased (+0.0%) to 94.36% when pulling a6fcacb04824387ae41f52248b40e3be5c893d4e on add-metadata-fields-to-item into 5aa7eb70692b7959f42f91ce4de62166a8f9772b on master.

Coverage increased (+0.0%) to 94.36% when pulling 7aaf9c1ebd6c905e620426eb53d82b7fe24db453 on add-metadata-fields-to-item into 5aa7eb70692b7959f42f91ce4de62166a8f9772b on master.

Coverage increased (+0.0%) to 94.36% when pulling<PHONE_NUMBER>0f03ed7f093cd75df906394b1de1bb on add-metadata-fields-to-item into 5aa7eb70692b7959f42f91ce4de62166a8f9772b on master.

Coverage increased (+0.0%) to 94.36% when pulling 28c0781147c685f926073f0f54103a548af81f15 on add-metadata-fields-to-item into 5aa7eb70692b7959f42f91ce4de62166a8f9772b on master.

:+1:

:-1: :+1:


{composer1, composer2}: bumps

Security releases!
Changelogs in commit log messages.

@jtojnar ?


HBASE-28311 Few ITs (using MiniMRYarnCluster on hadoop-2) are failing…

… due to NCDFE: com/sun/jersey/core/util/FeaturesAndProperties

Add hbase-testing-util in hadoop-2 profile with no exclusion of com.sun.jersey:jersey-core dependency
Move hbase-testing-util, which has exclusion of  com.sun.jersey:jersey-core dependency, to hadoop-3 profile from default dependency list

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

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

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
3m 34s
branch-2 passed

+1 :green_heart:
compile
0m 39s
branch-2 passed

+1 :green_heart:
spotless
0m 56s
branch has no errors when running spotless:check.

_ Patch Compile Tests _

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

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

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

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

+1 :green_heart:
xml
0m  2s
The patch has no ill-formed XML file.

+1 :green_heart:
hadoopcheck
10m 40s
Patch does not cause any errors with Hadoop 2.10.2 or 3.3.6.

+1 :green_heart:
spotless
0m 53s
patch has no errors when running spotless:check.

_ Other Tests _

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

23m 34s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5625

Optional Tests
dupname asflicense javac hadoopcheck spotless xml compile

uname
Linux 93fcacf9e57e 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / a419b390cf

Default Java
Eclipse Adoptium-11.0.17+8

Max. process+thread count
79 (vs. ulimit of 30000)

modules
C: hbase-it U: hbase-it

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/1/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  6s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m  0s
branch-2 passed

+1 :green_heart:
compile
0m 30s
branch-2 passed

+1 :green_heart:
shadedjars
7m  8s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 17s
branch-2 passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 23s
the patch passed

+1 :green_heart:
compile
0m 28s
the patch passed

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

+1 :green_heart:
shadedjars
7m 13s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 12s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m  7s
hbase-it in the patch passed.

26m 41s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/1/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5625

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 8c882642e2b2 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / a419b390cf

Default Java
Temurin-1.8.0_352-b08

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/1/testReport/

Max. process+thread count
821 (vs. ulimit of 30000)

modules
C: hbase-it U: hbase-it

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/1/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  8s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m 45s
branch-2 passed

+1 :green_heart:
compile
0m 34s
branch-2 passed

+1 :green_heart:
shadedjars
7m 49s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 26s
branch-2 passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
4m 20s
the patch passed

+1 :green_heart:
compile
0m 30s
the patch passed

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

+1 :green_heart:
shadedjars
7m 44s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 17s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 19s
hbase-it in the patch passed.

29m 34s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5625

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 07713b04b360 5.4.0-166-generic #183-Ubuntu SMP Mon Oct 2 11:28:33 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / a419b390cf

Default Java
Eclipse Adoptium-11.0.17+8

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/1/testReport/

Max. process+thread count
880 (vs. ulimit of 30000)

modules
C: hbase-it U: hbase-it

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/1/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

com.sun.jersey:jersey-core is missing as it is being excluded in pom.xml. Also hbase-testing-util  is already a dependency to this project and it excludes com.sun.jersey:jersey-core which is what this PR is trying to override by defining the hbase-testing-util  w/o exclusion on com.sun.jersey:jersey-core. See https://github.com/apache/hbase/blob/7016c640960dd875f2daf78601dc68bfe14a1219/hbase-it/pom.xml#L96

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

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

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
3m  2s
branch-2 passed

+1 :green_heart:
compile
0m 30s
branch-2 passed

-1 :x:
spotless
0m 45s
branch has 1 errors when running spotless:check, run spotless:apply to fix.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 45s
the patch passed

+1 :green_heart:
compile
0m 30s
the patch passed

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

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

+1 :green_heart:
xml
0m  1s
The patch has no ill-formed XML file.

+1 :green_heart:
hadoopcheck
9m  7s
Patch does not cause any errors with Hadoop 2.10.2 or 3.3.6.

+1 :green_heart:
spotless
0m 42s
patch has no errors when running spotless:check.

_ Other Tests _

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

19m 18s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5625

Optional Tests
dupname asflicense javac hadoopcheck spotless xml compile

uname
Linux 4238590fddfa 5.4.0-169-generic #187-Ubuntu SMP Thu Nov 23 14:52:28 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 6721863af1

Default Java
Eclipse Adoptium-11.0.17+8

spotless
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/2/artifact/yetus-general-check/output/branch-spotless.txt

Max. process+thread count
79 (vs. ulimit of 30000)

modules
C: hbase-it U: hbase-it

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/2/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  4s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
3m  5s
branch-2 passed

+1 :green_heart:
compile
0m 21s
branch-2 passed

+1 :green_heart:
shadedjars
6m  8s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 11s
branch-2 passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 29s
the patch passed

+1 :green_heart:
compile
0m 15s
the patch passed

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

+1 :green_heart:
shadedjars
5m 28s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 13s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 56s
hbase-it in the patch passed.

20m 51s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/2/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5625

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 3c70cf588fdb 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 6721863af1

Default Java
Temurin-1.8.0_352-b08

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/2/testReport/

Max. process+thread count
807 (vs. ulimit of 30000)

modules
C: hbase-it U: hbase-it

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/2/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  5s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
3m 54s
branch-2 passed

+1 :green_heart:
compile
0m 38s
branch-2 passed

+1 :green_heart:
shadedjars
7m 39s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 18s
branch-2 passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
4m 22s
the patch passed

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

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

+1 :green_heart:
shadedjars
8m 28s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 21s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 27s
hbase-it in the patch passed.

28m 56s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5625

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 70508827dde7 5.4.0-166-generic #183-Ubuntu SMP Mon Oct 2 11:28:33 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 6721863af1

Default Java
Eclipse Adoptium-11.0.17+8

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/2/testReport/

Max. process+thread count
869 (vs. ulimit of 30000)

modules
C: hbase-it U: hbase-it

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/2/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

💔 -1 overall
.
.
-1 ❌	spotless	0m 45s	branch has 1 errors when running spotless:check, run spotless:apply to fix.
.
.
spotless	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/2/artifact/yetus-general-check/output/branch-spotless.txt

Failure was due to some jenkins issue:
[ERROR] An internal error occurred during: "Periodic workspace save.".
java.lang.IllegalStateException: Job manager has been shut down.
    at org.eclipse.core.internal.jobs.JobManager.schedule (JobManager.java:1295)
    at org.eclipse.core.internal.jobs.InternalJob.schedule (InternalJob.java:385)
    at org.eclipse.core.runtime.jobs.Job.schedule (Job.java:684)
    at org.eclipse.core.internal.events.AutoBuildJob.build (AutoBuildJob.java:110)
    at org.eclipse.core.internal.events.BuildManager.endTopLevel (BuildManager.java:604)
    at org.eclipse.core.internal.resources.Workspace.endOperation (Workspace.java:1518)
    at org.eclipse.core.internal.resources.SaveManager.save (SaveManager.java:1246)

at org.eclipse.core.internal.resources.SaveManager.save (SaveManager.java:1143)
at org.eclipse.core.internal.resources.DelayedSnapshotJob.run (DelayedSnapshotJob.java:55)
at org.eclipse.core.internal.jobs.Worker.run (Worker.java:63)

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  5s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
2m 29s
branch-2 passed

+1 :green_heart:
compile
0m 15s
branch-2 passed

+1 :green_heart:
shadedjars
4m 54s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 12s
branch-2 passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 16s
the patch passed

+1 :green_heart:
compile
0m 15s
the patch passed

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

+1 :green_heart:
shadedjars
4m 52s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m  9s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 48s
hbase-it in the patch passed.

17m 54s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/3/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5625

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 9469f27925ba 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 9ab0c45955

Default Java
Temurin-1.8.0_352-b08

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/3/testReport/

Max. process+thread count
795 (vs. ulimit of 30000)

modules
C: hbase-it U: hbase-it

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/3/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

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

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
2m 46s
branch-2 passed

+1 :green_heart:
compile
0m 28s
branch-2 passed

+1 :green_heart:
spotless
0m 42s
branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 46s
the patch passed

+1 :green_heart:
compile
0m 29s
the patch passed

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

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

+1 :green_heart:
xml
0m  1s
The patch has no ill-formed XML file.

+1 :green_heart:
hadoopcheck
8m 54s
Patch does not cause any errors with Hadoop 2.10.2 or 3.3.6.

+1 :green_heart:
spotless
0m 43s
patch has no errors when running spotless:check.

_ Other Tests _

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

18m 49s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/3/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5625

Optional Tests
dupname asflicense javac hadoopcheck spotless xml compile

uname
Linux 4765e6ade981 5.4.0-169-generic #187-Ubuntu SMP Thu Nov 23 14:52:28 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 9ab0c45955

Default Java
Eclipse Adoptium-11.0.17+8

Max. process+thread count
79 (vs. ulimit of 30000)

modules
C: hbase-it U: hbase-it

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/3/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  5s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
3m  3s
branch-2 passed

+1 :green_heart:
compile
0m 21s
branch-2 passed

+1 :green_heart:
shadedjars
5m 12s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 16s
branch-2 passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 53s
the patch passed

+1 :green_heart:
compile
0m 21s
the patch passed

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

+1 :green_heart:
shadedjars
5m 14s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 14s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 56s
hbase-it in the patch passed.

19m 58s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5625

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 4f9ab2189988 5.4.0-169-generic #187-Ubuntu SMP Thu Nov 23 14:52:28 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 9ab0c45955

Default Java
Eclipse Adoptium-11.0.17+8

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/3/testReport/

Max. process+thread count
892 (vs. ulimit of 30000)

modules
C: hbase-it U: hbase-it

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5625/3/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

Hi @Apache9, I have updated the PR. did you have a chance to have a look at the change?


Fix source mode to not trigger go modules

Fixes https://github.com/jmhodges/bazel_gomock/issues/17. Investigating a bit, golang's module mode seems to trigger when using source mode with a fake  module file, resulting in downloading modules  while doing codegen. This can be avoided by prefixing the path passed  to -source with $GOPATH, so go/packages recognizes the source file as being in the GOPATH.
This pr removes the _go_tool_run_shell_stdout, which  was only  called from one place. Seemed better to remove the passthrough as compared having to fiddle gopath around to prefix the source flag. Seems like _go_tool_run_shell_stdout  used to be  used in  more than one place but isn't anymore

Thanks!


Issue/reference configuration reference

Description
The first page you land on when searching for the configuration documentation is https://docs.inmanta.com/inmanta-service-orchestrator/7/administrators/configuration.html#configuration
And it doesn't refer to the actual config options documentation.  This PR adds the missing link.
Self Check:
Strike through any lines that are not applicable (~~line~~) then check the box

[ ] Attached issue to pull request
[ ] Changelog entry
[ ] Type annotations are present
[ ] Code is clear and sufficiently documented
[ ] No (preventable) type errors (check using make mypy or make mypy-diff)
[ ] Sufficient test cases (reproduces the bug/tests the requested feature)
[ ] Correct, in line with design
[ ] End user documentation is included or an issue is created for end-user documentation (add ref to issue here: )
[ ] If this PR fixes a race condition in the test suite, also push the fix to the relevant stable branche(s) (see test-fixes for more info)

Processing this pull request

Processing #7538.

Processing #7537.


Errors seem to be occurring on A02s and A11s messages.

@kardianos When I try to parse this message with v2.5 I got this error: invalid characters in date: "10005218^^^default^default"
MSH|^~\&|PATIENTPING_ADT|272605^Regional Medical CPID|1|p-d507c951-96f3-11ed-96e0-39b4d2a37a61^^^PP^PP|10005218^^^default^default||JOE^DOE^||19541129|F|||31 MOZFA|272605|UNC Regional Medical|HOS|300 W 27th St^^Hometown^NC^28358|1790152668210992.
Did you have any idea why on messages A02s and A11s is a problem?

Here is the Go Playground example: https://go.dev/play/p/7b-xGO9A9Xo

The issue is that the TS data type should technically be a struct where the first field is a time stamp, but I've simplified it to type TS = time.Time. Thus it is attempting to parse the entire field of 10005218^^^default^default as a time, not just the first part. An easy fix would be for the parser to first use `strings.Cut(field, "^") and take the first part of the message. I'll see if I can update that logic.

I think not it is ok, but the date was not changed by myself, it is exactly how I got it from Bamboo. I will check with Bamboo this problem.


Resource limit handling for pods using VPA

What would you like to be added:
Currently, we are using the VPA for several components, e.g. kube-controller-manager, kube-scheduler, and may more.
In its current implementation the VPA - if set to policy Auto - does only set the pod's resource requests. It doesn't touch the limits. According to @georgekuruvillak this is planned for a future release of VPA, however, it might still take some time.
As a consequence, even with having VPA adapting the resource requests, our statically computed limits are still the upper bound, and a cluster under pressure can not scale beyond them.
Can we improve the situation? @georgekuruvillak suggested to either remove the limits entirely from the pods using VPA or having a separate mutating webhook that adjusts the limits (e.g., based on the VPA's recommendations). Maybe there are even other options.
Why is this needed:
We don't want to statically compute resource limits for the various pods in our clusters because their load can differ and, thus, the limits need to be determined dynamically.
/cc @georgekuruvillak @amshuman-kr @ggaurav10 @PadmaB

Seems to be already covered by VPA admission plugin in #2005. We might have to wait till 0.6.0 release or even better 0.5.2 according to #2105.

Awesome, so nothing to do on our side other than updating to the new version, right? Great, thank you.

Yes. Then limits will be scaled in the same proportion as the requests are scaled.

Just to clarify @rfranzke: Is there anything that needs to be done right now (like statically increasing the limits for certain now failing components) until the new version will become available?

I don't think so, @georgekuruvillak just explained that the limits will scale proportional to requests with https://github.com/kubernetes/autoscaler/pull/2005/. It should be OK to only wait for the new release.

VPA 0.6.1 is out with the "Preserve limit / request ratio, don't cap recommendations to limit" change.

We are evaluating it as part of the performance test run with HVPA.

👍

Fixed with https://github.com/gardener/gardener/pull/1512


Update tax-document.md 4.0 GA

@laujan
Can you review the proposed changes?
@Additi - all the broken links surfaced by validation will need to be fixed before we can merge.
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Hi @Jak-MS, Thank you for reaching out. I cannot review this content from an FTE PM because it is intended for the following release branch: release-ignite-document-intelligence-v4 and should not be published until Ignite. 😊

@Additi - see @laujan's comment.
@laujan - do you want @Additi to resubmit this through the private repo azure-ai-docs-pr ?  or should we close this PR?


User resolvers

Upgraded Apollo Server to ^2., graphql-tools to ^3.
Pulled out schema generation into separate modules
Fixed mol_db role provisioning in Ansible
New provisioning steps for the graphql project (database schema and extension)
User and Group models and resolvers

@LachlanStuart this PR is getting huge so we should finally merge it.


Create "Get Involved" requirement and associated Involvement model

Depends on #2420.
Fixes #2408, fixes #2414.
What this PR does:

Adds Involvement model and links it to TrainingProgress
adds seeding for Involvements
adds API serializers for Involvements
renames "Lesson Contribution" TrainingRequirement to "Get Involved"
adds date, involvement_type, trainee_notes fields and validation to TrainingProgressForm
migrates all Lesson Contributions to GitHub Contribution involvements
tests new validation and migrations
updates faking of training progress data

What this PR does not do (but future PRs will):

remove all references to Lesson Contribution TrainingRequirement (mostly in tests)
update the trainee dashboard/lesson contribution form
update the view of lesson contributions awaiting evaluation
update instructor badge eligibility criteria*
update the bulk add progress functions (unsure if this will be necessary)
update documentation and training application

*this is causing 1 test failure. I'd prefer to ignore that test for this PR.

@elichad Do you think the changes in this PR will be more visible once #2420 is merged? I think I'm going to wait until this is smaller :)

@pbanaszkiewicz yes, this PR should become more manageable after the other one is merged

@pbanaszkiewicz now ready for your review.
Note one failing unit test is expected:
"/home/eli/amy/amy/dashboard/tests/test_instructor_dashboard.py", line 72, in test_eligible_but_not_awarded
...
workshops.models.TrainingRequirement.DoesNotExist: TrainingRequirement matching query does not exist.

This test will be fixed as part of a later PR addressing #2440.

@pbanaszkiewicz I think I addressed or responded to all of your comments, let me know what you think.

@elichad Thanks for addressing all my comments. I posted an alternative approach to the strategy pattern / current validation (https://github.com/carpentries/amy/pull/2431#discussion_r1244179622). Please take a look and consider if it could be a benefit for us.


CodeSage Base, Large, and Small

https://github.com/amazon-science/CodeSage
https://huggingface.co/codesage/codesage-base
https://huggingface.co/codesage/codesage-large
https://huggingface.co/codesage/codesage-small

unsupported by GGML


Hotfix for log4j issue not released in 1.22 snap package

Steps to reproduce:
Look at output from snap build
(https://github.com/ubuntu/microk8s/actions/runs/1664501450)
Expected outcome: a published snap package for 1.22 (1.22.5) on the stable channel
Actual outcome: a failed build

Hi @watzo, indeed at the time the log4j fix was merged the build of 1.22 was failing and that was addressed in a more recent commit. See https://github.com/ubuntu/microk8s/commits/1.22

Hi @watzo we are working on releasing the fixes to the beta, candidate and stable.

That is great news. Thanks again!


[FEATURE] Automate bumping versions after releases

Is your feature request related to a problem?
Coming from https://github.com/opensearch-project/opensearch-clients/issues/34. The version should be bumped each time a release is made so that builds happen for new changes with appropriate versioning.
What solution would you like?
Implement workflow similar to https://github.com/opensearch-project/OpenSearch/blob/main/.github/workflows/version.yml

Closing this issue since opensearch-dsl-py is being merged into opensearch-py as part of https://github.com/opensearch-project/opensearch-dsl-py/issues/93


GDC viral contamination estimates and umi

Version info

bcbio version (bcbio_nextgen.py --version): 1.2.0
OS name and version: ubuntu 16.04

To Reproduce
Run a umi workflow and view the gdc viral content statistics in multiqc: There is never a hit.
Observed behavior
It appears that bcbio uses the BAM file with collapsed reads to calculate viral content. However, this BAM file has been stripped of all unmapped reads.
Expected behavior
Viral content estimation should be calculated from the BAM file that contains all reads present in the raw data.
Log files
samtools view -u -f 4 /bioinf-data/bcbio/work/align/1005_S3/1005_S3-sort-cumi.bam | bamtofastq collate=0 | bwa mem -t 16 /usr/local/share/bcbio-nextgen/genomes/Hsapiens/GRCh37/viral/gdc-viral.fa - | bamsort tmpfile=/bioinf-data/bcbio/work/bcbiotx/tmp35olurk3/1005_S3-gdc-viral-tmp inputthreads=16 outputthreads=16 inputformat=sam index=1 indexfilename=/bioinf-data/bcbio/work/bcbiotx/tmp35olurk3/1005_S3-gdc-viral.bam.bai O=/bioinf-data/bcbio/work/bcbiotx/tmp35olurk3/1005_S3-gdc-viral.bam

Thanks Ben, that is a good catch-- do you think we need to do the collapsing and what not or should the estimates be reasonable if we ignore that there are UMIs?

Hi Rory,
I would not go through all the pain regarding UMI for viral contamination. I think it would be fine to simply take the first BAM file (as described here) and align the unmapped reads to the viral sequences without using UMI. It's not about the sequence anyhow, just dosage.
I have to admit that the bam file naming is a little confusing. The temp file *-cumi.bam is a file with collapsed reads, the final *-umi.bam is a file with un-collapsed reads and *-ready.bam it the final file with collapsed reads.


Problem with Huawei

Hello,
I found a problem with Huawei devices (API level 23) and the FullscreenVideoView in a ScrollView. When scrolling down and the FullscreenVideoView disappears, the complete display turns black. This only happens when a video is playing. When the video is paused, everything works fine.

Hi @Fred117
Well, probably that is because of SurfaceView.
I'll try to test using a device because I only have Genymotion here now.
I'm making some improvements for Api 16+ but it is not ready yet.


Feature: Support encrypt

As said in the title, could you create a feature that encrypts data before syncing it to the remote server?
I believe this is a natural thing for a locally prioritized application.

Hey @aquarius-wing. Thanks for bringing it up!
We have this feature on our internal roadmap. No comment on the timeline for now.

Hey @aquarius-wing. Thanks for bringing it up!
We have this feature on our internal roadmap. No comment on the timeline for now.

Nice to hear that!

Turning this into a feature request discussion


Handle rank sometimes being sent as empty string

Checklist

[ ] tests added
[ ] commits conform to the Commit message format
[ ] documentation updated

Squash commit message
Handle rank sometimes being sent as empty string.
Info
Optional informative text (not to be included in commit message) relevant to reviewers.

Not objectively for better or worse, I would probably have done the cast at the time of Unmarshal.

I would normally too, but the type SheetListcurrently doesn't have an unmarshal interface implemented, and didn't want to add one just for this.

Not objectively for better or worse, I would probably have done the cast at the time of Unmarshal.

The rank-value comes from raw json Unmarshaled to SheetListLayout, so it doesn't seem to be to much work. Adding a custom float64 type and implement Unmarshal.

true a custom float64 might have looked a little better,


Improve wording of certificate QR code scanner (Community)

Description
This PR improves the wording of "HealthCertificate_QRScanner_instruction".
Link to Jira
n/a
Screenshots

Before
Afterwards

The milestone is 2.6 but this PR goes against 2.7, did you want to get it in 2.6 instead? I think we could still get it into the 2.6 release if you branch off of 2.6 instead of 2.7

@nickguendling
I intended to merge into release/2.7.x but if there's a way to get this into release/2.6.x that would be great! I'll change the branch.

@nickguendling
New PR: #3197
I failed to rebase this PR, I'm still a newbie with Git, sorry 😅


Missing keyboard input functionality

There currently doesn't appear to be a way to properly detect some keys for keyboard typing input.
The Keyboard.KeyChar provides the characters typed, and keys such as Enter, Backspace, Tab, Delete can be detected via KeyDown. However, if the user is pressing down on the backspace key, the only thing we can register with this system is a single backspace press, and no repeats.
Looking at the GLFW input guide, there aren't just "key down" and "key up" actions, but there's also a "key repeat" action which we're probably ignoring.
We should try to present all these parameters in our KeyChar, KeyDown and KeyUp events.

I'm not that familiarized with SILK but it seems that the event is being purposely ignored in GlfwKeyboard.cs, line 49
        _handle = events.Handle;
        events.Char += _char = (_, c) => KeyChar?.Invoke(this, (char) c);
        events.Key += _key = (_, key, code, action, mods) =>
            (action switch
            {
                InputAction.Press => KeyDown,
                InputAction.Release => KeyUp,
                InputAction.Repeat => null,
                _ => null
            })?.Invoke(this, ConvertKey(key), code);`

I'm not that familiarized with SILK but it seems that the event is being purposely ignored in GlfwKeyboard.cs, line 49
        _handle = events.Handle;
        events.Char += _char = (_, c) => KeyChar?.Invoke(this, (char) c);
        events.Key += _key = (_, key, code, action, mods) =>
            (action switch
            {
                InputAction.Press => KeyDown,
                InputAction.Release => KeyUp,
                InputAction.Repeat => null,
                _ => null
            })?.Invoke(this, ConvertKey(key), code);`

I think it's a good idea to propose some changes to the input events so we can pass all these parameters to the user of the library.
We'll have to add more parameters to the KeyDown & other events, which will mean everyone will have to add them to their event handlers as well. It might be a good idea to do as OpenTK and aggregate all these parameters into a single struct called KeyEventArgs or something like that, which will be the sole parameter of these events:
public readonly struct KeyEventArgs
{
    public Key Key { get; }
    public int KeyCode { get; }
    public bool IsRepeat { get; }
    public ModifierKeys ModifiersKeys { get; }
    // And any other param which we might want to add now or in the future
}

This way we can also add more parameters in the future without making breaking changes.
We can invoke the "repeated" keys with the KeyDown event.
The other option would be to replace KeyDown and KeyUp with a single key event which reports all three up down and repeat, in which case instead of a bool IsRepeat the struct would have a KeyAction Action { get; }, but I like the previous approach more.

I think it's a good idea to propose some changes to the input events so we can pass all these parameters to the user of the library.
We'll have to add more parameters to the KeyDown & other events, which will mean everyone will have to add them to their event handlers as well. It might be a good idea to do as OpenTK and aggregate all these parameters into a single struct called KeyEventArgs or something like that, which will be the sole parameter of these events:
public readonly struct KeyEventArgs
{
    public Key Key { get; }
    public int KeyCode { get; }
    public bool IsRepeat { get; }
    public ModifierKeys ModifiersKeys { get; }
    // And any other param which we might want to add now or in the future
}

This way we can also add more parameters in the future without making breaking changes.
We can invoke the "repeated" keys with the KeyDown event.
The other option would be to replace KeyDown and KeyUp with a single key event which reports all three up down and repeat, in which case instead of a bool IsRepeat the struct would have a KeyAction Action { get; }, but I like the previous approach more.

Sounds like a good idea to me - but not something we can do right now, this would have to be 3.0 work, which is faaar off.
For now, we could simply expose a new event Repeat that triggers when a repeat is triggered.
This isn't ideal from the user code side, but at least works.

Sounds like a good idea to me - but not something we can do right now, this would have to be 3.0 work, which is faaar off.
For now, we could simply expose a new event Repeat that triggers when a repeat is triggered.
This isn't ideal from the user code side, but at least works.

We could just have a catch-all Key event.
event Action<KeyEvent> Key;

We could just have a catch-all Key event.
event Action<KeyEvent> Key;

Just adding the Key event is an easy solution, but not a good solution.
What I suggest is a breaking change but previous code will be easy to adapt- All you have to do is change the event handler's parameters to a single one and then get the parameters from there. And it solves all these problems.
I think we should make these changes, if not for Silk 2.X then for Silk 3.0 and optionally, until then, we can add the Key event Perksey suggested.

Just adding the Key event is an easy solution, but not a good solution.
What I suggest is a breaking change but previous code will be easy to adapt- All you have to do is change the event handler's parameters to a single one and then get the parameters from there. And it solves all these problems.
I think we should make these changes, if not for Silk 2.X then for Silk 3.0 and optionally, until then, we can add the Key event Perksey suggested.

We can't do breaking changes for 2.X so it'll have to be 3.X.
Silk.NET 3.0 has an official release date of December 31st 9999 but realistically won't be any time before 2022 (I'm not dedicating any time to new massive features for 3.0, only minor improvements, bug fixes, and the monthly updates).

We can't do breaking changes for 2.X so it'll have to be 3.X.
Silk.NET 3.0 has an official release date of December 31st 9999 but realistically won't be any time before 2022 (I'm not dedicating any time to new massive features for 3.0, only minor improvements, bug fixes, and the monthly updates).

We can't do breaking changes for 2.X so it'll have to be 3.0.
Silk.NET 3.0 has an official release date of December 31st 9999 but realistically won't be any time before 2022 (I'm not dedicating any time to new massive features for 3.0, only minor improvements, bug fixes, and the monthly updates).

So 3.0 will be more like a big maintenance release?

We can't do breaking changes for 2.X so it'll have to be 3.0.
Silk.NET 3.0 has an official release date of December 31st 9999 but realistically won't be any time before 2022 (I'm not dedicating any time to new massive features for 3.0, only minor improvements, bug fixes, and the monthly updates).

So 3.0 will be more like a big maintenance release?

I created a proposal for these changes. You can find it here.

I created a proposal for these changes. You can find it here.

So 3.0 will be more like a big maintenance release?

@FrostByteGER 3.0 has a tracker here: #209. It'll be added to as we further realise 3.0 but we haven't even started thinking about 3.0 yet.

So 3.0 will be more like a big maintenance release?

@FrostByteGER 3.0 has a tracker here: #209. It'll be added to as we further realise 3.0 but we haven't even started thinking about 3.0 yet.

@ThomasMiz if you can pull request this in like #397 we'll review it next working group meeting.

@ThomasMiz if you can pull request this in like #397 we'll review it next working group meeting.

There currently doesn't appear to be a way to properly detect some keys for keyboard typing input.
The Keyboard.KeyChar provides the characters typed, and keys such as Enter, Backspace, Tab, Delete can be detected via KeyDown. However, if the user is pressing down on the backspace key, the only thing we can register with this system is a single backspace press, and no repeats.
Looking at the GLFW input guide, there aren't just "key down" and "key up" actions, but there's also a "key repeat" action which we're probably ignoring.
We should try to present all these parameters in our KeyChar, KeyDown and KeyUp events.

If you want to do text input, you should use the char callback not the keydown event, according to GLFW. This also automatically handles key modifiers like AltGr+Q=@ and so on. Doesn't fix the backspace problem though.

There currently doesn't appear to be a way to properly detect some keys for keyboard typing input.
The Keyboard.KeyChar provides the characters typed, and keys such as Enter, Backspace, Tab, Delete can be detected via KeyDown. However, if the user is pressing down on the backspace key, the only thing we can register with this system is a single backspace press, and no repeats.
Looking at the GLFW input guide, there aren't just "key down" and "key up" actions, but there's also a "key repeat" action which we're probably ignoring.
We should try to present all these parameters in our KeyChar, KeyDown and KeyUp events.

If you want to do text input, you should use the char callback not the keydown event, according to GLFW. This also automatically handles key modifiers like AltGr+Q=@ and so on. Doesn't fix the backspace problem though.

This has been resolved in the 3.0 proposals #539

btw this is still a problem

btw this is still a problem

if you have an issue with the solution provided by the 3.0 proposals, please open a separate issue regarding any missing features from there

no, I mean it's an issue right now, not in 3.0 when trying to use the library:) I'm literally repackaging Silk.NET.Input to add this functionality rn

Yes we’re aware it’s an issue right now, however the work specific to this issue is deemed complete for 3.0. Everything else will be tackled as part of normal 3.0 development. Very similar to how we treat issues in 2.X where we don’t close the issue until the work specific to the issue is in a core branch. We don’t keep it open until shipment because that would create a lot of maintenance overhead.

Is it not possible to just add a repeat event as a kludge, like right now? That won't break anything in terms of backward compatibility.

Any modification of the API contract will be breaking.

How does adding an event break the API? I don't understand

Any third party implementation of IKeyboard would be incompatible with the update unless it also adjusts its code.


Create adr document to track LeJOS changes

It is necessary to create this ADR document and fill with changes in LeJOS interfaces.

This issue is part of #608 and previously exist.
Duplicated


[Loom] +DoJVMTIVirtualThreadTransitions scalability issue

JDK version:
JDK 20.0.1, Java HotSpot(TM) 64-Bit Server VM, 20.0.1+9-29

Reproducer:
package red.hat.puzzles.concurrent;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.Executor;
import java.util.concurrent.Executors;

@State(Scope.Benchmark)
@Measurement(iterations = 5, time = 1)
@Warmup(iterations = 10, time = 1)
@Fork(value = 2, jvmArgsAppend = "--enable-preview")
public class VirtualThreadCreation {

    @Param("10")
    int work;

    @Param("1024")
    int tasks;

    Executor executor;

    @Setup
    public void init() {
        executor = Executors.newVirtualThreadPerTaskExecutor();
    }

    @Benchmark
    public void submitWork() throws InterruptedException {
        var done = new CountDownLatch(tasks);
        for (int i = 0; i < tasks; i++) {
            executor.execute(() -> {
                Blackhole.consumeCPU(work);
                done.countDown();
            });
        }
        done.await();
    }
}

Running it with
 --jvmArgs="--enable-preview -XX:+UnlockExperimentalVMOptions -XX:+DoJVMTIVirtualThreadTransitions"

And attaching async profiler e3b7bfca227ae5c916f00abfacf0e61291df3a67 as JMH profiler, report these numbers on my Ryzen<EMAIL_ADDRESS>GHz
Benchmark                                (tasks)  (work)   Mode  Cnt    Score    Error  Units
VirtualThreadCreation.submitWork            1024      10  thrpt   10  607.376 ± 11.031  ops/s

With flamegraphs:

Which both show:

wrong_method deopt handling (due to some race? Some JDK comment report "We might end up in handle_wrong_method if the callee is deoptimized as we race thru here")
JVMTI VT transitions being super costy and highly contending on few mutexes (on thread state)

Disabling ap on JMH instead, report:
Benchmark                         (tasks)  (work)   Mode  Cnt     Score     Error  Units
VirtualThreadCreation.submitWork     1024      10  thrpt   10  2586.494 ± 223.166  ops/s

Adding -prof perfasm to the async profiler run shows
....[Hottest Regions]...............................................................................
 73.61%     [kernel.kallsyms]  native_queued_spin_lock_slowpath (76 bytes)
  1.90%     [kernel.kallsyms]  native_queued_spin_lock_slowpath (82 bytes)
  1.22%     [kernel.kallsyms]  _raw_spin_lock (41 bytes)
  0.83%     [kernel.kallsyms]  __get_user_nocheck_4 (10 bytes)
  0.83%             libjvm.so  update_register_map1 (150 bytes)
  0.77%     [kernel.kallsyms]  try_to_wake_up (154 bytes)
  0.68%             libc.so.6  pthread_mutex_trylock@@GLIBC_2.34 (116 bytes)
  0.51%             libc.so.6  __GI___pthread_mutex_unlock_usercnt (112 bytes)
  0.48%     [kernel.kallsyms]  futex_wake (91 bytes)
  0.46%             libc.so.6  __GI___lll_lock_wait (54 bytes)
  0.45%             libc.so.6  pthread_mutex_lock@@GLIBC_2.2.5 (125 bytes)
  0.34%             libjvm.so  vframeStream::vframeStream (164 bytes)
  0.34%     [kernel.kallsyms]  futex_wake_mark (59 bytes)
  0.34%     [kernel.kallsyms]  __futex_unqueue (46 bytes)
  0.33%     [kernel.kallsyms]  futex_wait (90 bytes)
  0.32%             libc.so.6  __GI___lll_lock_wake (19 bytes)
  0.32%     [kernel.kallsyms]  futex_q_unlock (25 bytes)
  0.31%     [kernel.kallsyms]  psi_group_change (355 bytes)
  0.30%             libjvm.so  OopMapStream::find_next (66 bytes)
  0.29%     [kernel.kallsyms]  _raw_spin_lock_irqsave (45 bytes)
 15.36%  <...other 898 warm regions...>
....................................................................................................
100.00%  <totals>

which is indeed related high contention in the mutex(ex) in the JVMTI methods.
perf lock indeed reports that avg time to enter the thread_state lock at https://github.com/openjdk/jdk19/blob/967a28c3d85fdde6d5eb48aa0edd8f7597772469/src/hotspot/share/prims/jvm.cpp#L3964C20-L3964C41 has increased from 3.19 us to 26.76 us (!!!) for each of the FJ threads running the V Threads.
Running the same benchmark using a single thread, obviously, report a negligible performance impact, because no contention is involved.
The wild guess here is that after aquiring the lock on the thread state ap cause the lock to be held from longer time making the other threads to experiment more contention; but I didn't yet dug what's going on there, TBH.

Note:
re

wrong_method deopt handling (due to some race? Some JDK comment report "We might end up in handle_wrong_method if the callee is deoptimized as we race thru here")

This part doesn't change when async profiler is in, probably, but I have yet to investigate

I've further investigated and the wrong_method handling is still there, regardless async profiler is attached or not: update_register_map1(ImmutableOopMap const*, frame const*, RegisterMap*) is reported by perf (and AMD u prof) as a very hot method, and it's indeed used in the call-chain to handle wrong_method:

This seems a Loom issue, instead.

And perf, while running the JMH bench without async profiler and jvmArgs="--enable-preview -XX:+UnlockExperimentalVMOptions -XX:-DoJVMTIVirtualThreadTransitions"
agree that handle_wrong_method isn't happening due to async profiler:

With limited understanding: This seems like an inappropriate location for a global lock and can probably lead to serious performance degradation when having many virtual threads.

Yep, I see that DoJVMTIVirtualThreadTransitions it's true by default :"(
To summarize, loom seems to have 2 perf issues here:

handle_wrong_method
highly contended vmti thread state global lock

ap is somehow making the contention worse by triggering allocation of thread state while holding the global lock (what I have discovered so far, tomorrow will perform a perf diff and  malloc profiling to be sure of this)

@franz1981 Thank you for reporting the issue and looking into it.
Since the flame graph shows only generic JVM TI stuff with no evidence of async-profiler, I did a simple sanity test and ran the benchmark with async-profiler loaded but not enabled. The performance was still bad. Then I created a trivial JVM TI agent that does nothing and verified that the JVM goes crazy with the agent loaded, but runs fine without it. Here is this agent:
#include <jvmti.h>

static void JNICALL ClassLoad(jvmtiEnv* jvmti, JNIEnv* jni, jthread thread, jclass klass) {}

int Agent_OnLoad(JavaVM* vm, char* options, void* reserved) {
    jvmtiEnv* jvmti;
    (*vm)->GetEnv(vm, (void**)&jvmti, JVMTI_VERSION_1_0);

    jvmtiEventCallbacks callbacks = {0};
    callbacks.ClassLoad = ClassLoad;
    (*jvmti)->SetEventCallbacks(jvmti, &callbacks, sizeof(callbacks));
    (*jvmti)->SetEventNotificationMode(jvmti, JVMTI_ENABLE, JVMTI_EVENT_CLASS_LOAD, NULL);

    return 0;
}

So, the issue has nothing to do with async-profiler - it's the ridiculously inefficient support for virtual threads in JVM TI. Each time a virtual thread is started/finished/mounted/unmounted, JvmtiThreadState is updated under the global JvmtiThreadState_lock mutex.
The reason is, many JVM TI notifications can be enabled/disabled on per-thread basis, even though the feature is almost never used. All notifications are typically enabled/disabled globally, but HotSpot chooses to maintain per-thread state anyway. This approach obviously does not scale with virtual threads.
There is an "optimization" to skip creating a per-thread JvmtiState if none of the "thread filtered" events are enabled. However, the list of "thread filtered" events is pretty wide:
static const jlong  THREAD_FILTERED_EVENT_BITS = INTERP_EVENT_BITS | EXCEPTION_BITS | MONITOR_BITS | VTHREAD_BITS |
                                        BREAKPOINT_BIT | CLASS_LOAD_BIT | CLASS_PREPARE_BIT | THREAD_END_BIT |
                                        SAMPLED_OBJECT_ALLOC_BIT;

In my trivial example, enabling a global ClassLoad callback is enough to trigger this condition, acquire a JvmtiThreadState_lock and create a new state for the virtual thread.

FYI.
-XX:-DoJVMTIVirtualThreadTransitions option was made to suppress the high overhead when profiling with JVMTI.
Please, turn off JVMTIVirtualThreadTransitions always when you collect profiles.
A better solution is on the way, but not ready yet.

Thanks @kuksenko to have looked into this issue!
I've noticed that option was enabled by default, but I'm pretty happy to disable it; while, related the IC patching or itable issue which cause wrong_method handle to be issued?
There's already a JDK issue I can link here (for the future myself/others)?
Sadly I have no power to fill JDK issues or I would do it myself :"/

Oh! Stop.
I missed that: "JDK 20.0.1"
throw new TooOldJavaVersionException();
;)

It's a bunch of issues for this area
https://bugs.openjdk.org/issues/?jql=text ~ "JVMTI VTMS transitions" ORDER BY created DESC

@kuksenko
I've tried running the benchmark with JDK 21-ea, OpenJDK 64-Bit Server VM, 21-ea+32-2482 but getting both the same problems - I can try mainline too in a sec (time to compile it)

Uh thanks go Shipilev exist, I've used JDK 22-testing, OpenJDK 64-Bit Server VM, 22-testing-builds.shipilev.net-openjdk-jdk-b499-20230725 on https://builds.shipilev.net/openjdk-jdk/ getting both the same errors (JVMTI was expected while I was hoping the one re wrong_method to not be there

Disabling all assertions manually and running a fastdebug build with -XX:-DoJVMTIVirtualThreadTransitions causes a segfault:
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fe96402907f, pid=291970, tid=291995
#
# JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-adhoc.i560383.jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-adhoc.i560383.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  [libasyncProfiler.so+0x1c07f]  Profiler::getJavaTraceAsync(void*, ASGCT_CallFrame*, int, StackContext*)+0x64f

So this isn't really a solution.

The JVM TI capability can_support_virtual_threads is enabled. You can use -XX:-DoJVMTIVirtualThreadTransitions option or enable can_support_virtual_threads capability but not both. They conflict.

The JVM TI capability can_support_virtual_threads is enabled

@sspitsyn The thing is - nobody enabled can_support_virtual_threads.
It's enough to just add an empty set of capabilities to trigger the above assertion:
    jvmtiCapabilities capabilities = {0};
    (*jvmti)->AddCapabilities(jvmti, &capabilities);

@apangin I'm interested to know if disabling (not enabling) this capability helps in this particular case.
The experimental flag -XX:-DoJVMTIVirtualThreadTransitions is just a temporary work around.
We still have a plan/task to support virtual threads in JVM TI in a scalable way. It will take some time though.

@sspitsyn and what about the  wrong_method_handle behaviour? is it expected (a bit OT, sorry @apangin )

@sspitsyn and what about the wrong_method_handle behaviour? is it expected (a bit OT, sorry @apangin )

Do you meant handle_wrong_method not  wrong_method_handle, right?
I have no idea yet.

yep @sspitsyn :"/
Looking how the continuation's enterVirtual is natively compiled seems an expected path, while usually it happens due to some deopt or race during IC patching (and i'm not getting any weird compilation logs re Continuation::enter either..) but anyway, I won't go to much OT: re this issue (for ap and any profiler running as an agent, at this point) we have already said the most that's needed.

I created JDK-8313656 to track the assertion failure.
Also found JDK-8308614 related to the very same scalability issue.

As we have relevant JBS issues filed, I think we can resolve this one.


Add BA high gamble count chat command

Aimed at fixing issue #7691

I think this should be part of kill count command

At the very least, it could internally use the /kc endpoint to save some code.

If !kc penance queen is already a thing I would just pick some other "boss name" like ba high gamble or something.

We do not track penance queen kills with !kc, for whatever reason. Gamble count is commonly used by the ba community as well, I think the separate command like this would be a good fit?

!kc chat command is registered to use killCountLookup() then killCountSubmit(), how could killCountSubmit() be used to submit the Gamble count considering it's just a varbit (similar to quest points)?

@Jacoblairm have you confirmed this works outside of ba?

Alex on Discord checked it so we should be good.


i18n should not assume 1-1 matching between translated locale routes

Have you read the Contributing Guidelines on issues?

[X] I have read the Contributing Guidelines on issues.

Motivation
Hi,
First of all I want to thank you all for providing such an awesome open-source tool. I've been using it for 2.5 years in different companies, Docusaurus has been stable and extremely easy to use and maintain.
I started using the i18n feature to implement multi-language blogs about half year ago. It works fine since then. But as our team grows and kind of diverges, we figure out that simply putting blogs in two languages is barely enough. Then we are discussing about publishing blogs in 2 languages, English and Chinese, separately.
So then I tried to verify the feasibility of this thought, and it kind of failed from several aspects.
Case 1: Publish an English blog only. Everything works well (i.e. yarn start local preview, online previews), except when clicking on the language switch button and redirects to the default 404 response page.
Case 2: Publish a Chinese blog only. This is where the nightmares come in. The yarn start -- --locale zh local preview works. But when generating online preview, this somewhat becomes a 'ghost page'. More specific, this page is unreachable by any means.
Then I went through Docusaurus's documents and learned some basic ideas about it. The i18n feature works when the 1-to-1 relationship is established for a blog in 2 languages, which totally makes sense in most cases. But when we need blogs only presented in one language, it partially failed.
So I am wondering if there is a work-around to this issue, or some kinds of feature flags/vars that I could use to avoid it? I know this is a very rare corner-case, and this might be too much to ask for, but could you consider fixing it in future releases?
Thanks,
Yilin
Self-service

[ ] I'd be willing to do some initial work on this proposal myself.

Hi, I'm not too sure I understand. You have two blogs: Chinese and English, and they are generated using Docusaurus i18n, with English as base locale. Now, you want to publish them on different domains, so the language switcher doesn't work, correct?

Hi, I'm not too sure I understand. You have two blogs: Chinese and English, and they are generated using Docusaurus i18n, with English as base locale.

Yes.

Now, you want to publish them on different domains, so the language switcher doesn't work, correct?

No, they are currently under the https://apisix.apache.org/ domain, with English blog https://apisix.apache.org/blog/ and Chinese blog https://apisix.apache.org/zh/blog/.
The problem I encountered is the i18n feature requires 1-to-1 binding of blogs in each language. For example, I have a blog in English called A, then there must be a blog in Chinese called A' to serve the i18n purpose.
As our team grows and diverges, our demand for the i18n feature also changes. We want some blogs published in one language only. Then I tried Case1 and Case2, and the i18n feature could not meet our demand.

Oh, I see. I remember we have an issue somewhere related to that, but I can't find one. We also get lots of questions about that.
We do expect the site's route structure to be isomorphic across locales: if /blog/foo exists, /zh/blog/foo must also exist, and vice versa. I don't know if breaking that contract would be very sensible—what kind of UX do you expect when the translated counterpart doesn't exist?

what kind of UX do you expect when the translated counterpart doesn't exist?

For Case 1 with English blog only, I think clicking on the language switch button and redirect to the summary page of Chinese blog, or the other language's blog summary page in general. This basically says "we don't have a corresponding blog in the other language and here is the list of the blogs we have." I think this UX is better than a default 404 page.
For Case 2 with Chinese blog only, it is similar to case 1. But before getting into the scenes in Case 1, we need some kinds of work-arounds to make it show up in in local preview, online preview, and the production.
I read through #7040 , and think maybe the i18n can be default 1-to-1, but with some flexibilities on the users' end, let them decide whether 1-to-1 is always necessary as team grows and demand changes.

I've triaged a few i18n-related issues. You can look through https://github.com/facebook/docusaurus/labels/domain%3A i18n since a lot of them look related to your use-case.

@yzeng25 I understand this use-case, but we don't currently support it.
We expect both blog posts to exist in both languages. We also expect those 2 pages to have the same slug:

This is something we could work on, but it's not easy, due to the historical way we sandbox each localized site as a totally different SPA. (ie 3 locales = 3 SPA built one after the other)
To be able to switch from one locale to another, now one localized site would have to know about the existence/non-existence of pages in other localized sites. The language switcher would be more complex, requiring more global data about all your localized sites, leading to a performance penalty.
Similarly, we would have to handle this in SEO metadata, so that we don't output broken links in those metadata:

I don't think it's worth or easy to solve these problems.
However a workaround could work fine for your use-case: if a blog post does not exist in a given language, you can still create a MDX file for that language, but instead of displaying markdown content, you can just add a Redirect:
---
id: my-chinese-only-blog-post
description: will redirect to blog home
---

import {Redirect} from '@docusaurus/router';

<Redirect to="/blog" />;

https://docusaurus.io/docs/docusaurus-core#redirect

OK got it. We did a similar workarounds as well. We modified the language switch button, when click on it, it jumps back to the blog summary page.
Thanks @slorber for your detail explanation, really appreciate it!


Provide example connection string for VS 2017

Add in the web.config of simpleBlog the correct connection string for VS 2017 (commented out)

Thanks! We'll take a look.

Thanks for the comment!