Add small example blog

Any chance that you could add a small example blog directory to help newbies get going? Many thanks in advance!

It's literally just an org file in a posts directory. The magic is not the blog directory, but your init.el configuration.
Does anyone want to take a stab at this?

If an example is being worked on, I just want to chime in and say that it would be nice to have examples of generating HTML tables and more importantly how to handle both local and linked images. It would be a big help.

I just added a minimal configuration to the README. Is this sufficient for your needs? (Does it work?)


Update Level 2 workflow scripts for Stack v12_1

See https://github.com/DarkEnergyScienceCollaboration/Twinkles/issues/369#issuecomment-256235767

Good catch, Jim.

I guess since we are running v12_0 at NERSC, this change probably doesn't need to be made, but we should double check.

This has been done.


CHANGELOG.md in packages have no links to commits

Is your feature request related to a problem? Please describe.
CHANGELOG.md in packages have no links to commits.
https://github.com/sveltejs/kit/blob/master/packages/kit/CHANGELOG.md

I think we should change the format with https://github.com/atlassian/changesets/blob/main/docs/modifying-changelog-format.md
@pngwn might have more tips

Yeah we can either use the GitHub changelog formatter that is provided or we can write a custom one.
@Conduitry has some reservations about the provided formatter so we may want to look into a custom one that meets our requirements.

Changes in CHANGELOG now links to its original PR, which aligns with how the core Svelte repository writes its changes


Fix IllegalArgumentException in Replayer logging

Description
This change fixes illegal argument exception in a few places where the replayer logs messages contain "{}".

Category: Enhancement/Bug Fix
Why these changes are required? Reduce log injection attacks and log formatting exceptions
What is the old behavior before changes and new behavior after changes? Before this change, some logs contained errors around missing arguments. Now that is removed

Issues Resolved
Progress towards Bug #633
Is this a backport? If so, please add backport PR # and/or commits #
Testing
Ran some end to end testing locally with various log levels and checking for errors.
Check List

[ x] New functionality includes testing

[ x] All tests pass, including unit test, integration test and doctest

[ x] New functionality has been documented
[ x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@AndreKurait Could you look into the CI failures before merging?


Amazon audiobooks causing trouble again

https://www.amazon.fr/gp/product/207055998X (an audiobook on CD) fulfills both the PHYSICAL_AUDIOBOOK_PAGE_QUERY and the AUDIBLE_PAGE_QUERY (because a digital media version is also available on Audible). Since the AUDIBLE_PAGE_QUERY condition comes first, the extraction of the cover images fails: The Audible release has a different ASIN, so the attempt to find the non-existing /hz/audible/mlp/mfpdp/ page of the CD leads to a redirect to the product page, where the AUDIBLE_FRONT_IMAGE_QUERY does not work of course.
Changing the order of the conditions fixes this case but breaks our existing Audible unit test.
I don't have time to look into it right now, but we need better page queries if we don't want to introduce a fallback mechanism again.

Perhaps #productLogo > img[alt="Audible Logo"] or just #audibleProductTitle? The former matches the Audible logo next to the product title, the latter matches the product title itself. Neither are present present on your product but matches the one from the tests and the audiobook version of your example. Alternatively, we could reuse the existing query but change it to .a-button-selected .audible_mm_title so we only match if the Audible button is the highlighted one.


Milestone 1: Prepare data architecture documentation

Milestone 1: Prepare data architecture documentation

Add ERD for facebook clone model

Diagram Link

Hi @bolah2009 and @Torres-ssf,
Everything's cool on the ERD end! Let's move on to Milestone 2!


Missing files warning  - Alamofire 4.0 Xcode 8

When I build my project, I get multiple warnings stating that I am missing the following files (in the Alamofire/Source directory) from working copy: Stream.swift, Manager.swift, Download.swift, Upload.swift, and Error.swift; however, they are not included in the 4.0 release. Anyone else come across this issue? I've tried reinstalling the pod multiple times and I'm up-to-date on the latest CocoaPods version FYI.
EDIT: Oddly enough, I copied my Xcode project and didn't get the error in that project...

I just replaced my project with a copied version and it removed the missing file warnings. Not sure why it fixed the issue but at least there is some record of it here.


Button locale not handling color codes (&)

Example of items that do not parse colors:
edit_warp_teleport_button: '[Teleport]'
edit_warp_teleport_button_tooltip: Teleport to this warp
edit_warp_delete_button: '[Delete]'
edit_warp_delete_button_tooltip: Delete this warp
edit_warp_relocate_button: '[Relocate]'
edit_warp_relocate_button_tooltip: Update this warp's location
edit_warp_rename_button: '[Rename]'
edit_warp_rename_button_tooltip: Change the name of this warp
edit_warp_description_button: '[Edit Description]'
edit_warp_description_button_tooltip: Update this warp's description
edit_home_teleport_button: '[Teleport]'
edit_home_teleport_button_tooltip: Teleport to your home
edit_home_delete_button: '[Delete]'
edit_home_delete_button_tooltip: Delete your home
edit_home_relocate_button: '[Relocate]'
edit_home_relocate_button_tooltip: Update your home's location
edit_home_rename_button: '[Rename]'
edit_home_rename_button_tooltip: Change the &aname&7 of your home
edit_home_description_button: '[Edit Description]'
edit_home_description_button_tooltip: Update the &adescription&7 of your home
edit_home_make_public_button: '[Make Public]'
edit_home_make_public_button_tooltip: Open your home to the public
edit_home_make_private_button: '[Make Private]'
edit_home_make_private_button_tooltip: Make your home private
home_default_description: '&a%1%''s&7 home'
warp_default_description: A &apublicly&7 accessible warp

This is intended currently but should definitely be fixed. In HH 2.5 I began transitioning the locale to fully format the chat interfaces with customisable MineDown rather than manually doing it with clickable chat components, this needs expanding to the rest of the buttons.


Fix security vulnerabilities by using Go 1.19

What happened?

Security vulnerability scanners like Twistlock and Snyk are reporting security vulnerabilities as terrajet uses <= Go 1.17 to build images. These security vulnerabilities are classified as critical and high severity and are preventing us from using the built images. Some of the CVEs are:
CVE-2021-44716
CVE-2021-41771
CVE-2022-28327
CVE-2022-24675
CVE-2022-24921
CVE-2022-23773
CVE-2022-23772
How can we reproduce it?

Point the Snyk to the Git repository to run scurity scan (eg: https://github.com/crossplane-contrib/provider-jet-datadog, https://github.com/crossplane/terrajet). The report points out the security vulnerabilities.
Potential fix?
These CVEs can be resolved by using the Go 1.19.

From my reading, seems like the minimum Go version that'd remove these CVEs is v1.18.1 , right @nimish22 ?

@muvaf Thank you for your quick reply and apologies for the confusion!
Twistlock scan has revealed 18 high vulnerabilities. I have updated the complete list above.
The lowest version where these CVEs are resolved is Go 1.18.4 and Go 1.17.12.


Null displaying for some news

Hey  @devansh016    please assign me this issue , i am interested  in it

Hey @devansh016  i have given a PR  please  review


oem-ibm: Fixing DMA length issue

When HOST read/write data to BMC using DMA then BMC checks the length of the data to be read/write and devide into chunks if data length is more than DMA max size.
This change will fix the issue in PLDM when it send data transfer status to the HOST and sending left over length as response which is wrong and now PLDM sends correct response with length.
Defect: https://jazz07.rchland.ibm.com:13443/jazz/web/projects/CSSD#action=com.ibm.team.workitem.viewWorkItem&id=612662
Tested:
IPL flow tested and PHYP reaches till standby which include all type of file transfer from BMC to PHYP.

Can you add the defect and slack thread reference to the commit message for future reference?

changes look okay to me. But can you also push this upstream please before we merge this downstream ? i don't think this is a downstream only solution right ?


Updated No1atAll HIP PR

this closes #1084 right?

I don't know if it does or not.  I updated #1084 with this, so both are the same now.  but I have no access to this one

Let's just merge your original one and close this one then.

ok for me


nixos/manual: fix build

Motivation for this change
NixOS manual doesn't build.
Things done
Built the NixOS manual, rendered option description below:

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Thanks.


Improve zh-cn and zh-tw diagnostic messages

Fix typo and ambiguous diagnostic messages in zh-cn and zh-tw.

These are generated (as the names imply) but @Pdostalek might be able to help bring in this work. @PDostalek, can these suggestions be recommended to the appropriate translators?

@DanielRosenwasser Sorry for the inconvenience, but I couldn't find the proper place to submit these translation and submitted a PR instead. It would be helpful if you can suggest these changes to the translators.

It is true that translation change only can be made in loc platform, then export to repo. Change outside this process will be overwritten.
The suggested change has been implemented in loc platform and exported. For example, https://github.com/microsoft/TypeScript/blob/master/src/loc/lcl/chs/diagnosticMessages/diagnosticMessages.generated.json.lcl#L6805
Thank you for your feedback. This PR can be closed.

Thanks @danyeh!


Comments on Saxon 12.5

Comments on Saxon 12.5
This covers points introduced by the release of Saxon 12.5.
It starts with a number of issues raised by @galtm and @birdya22 on Saxon 12.4 which related to XSpec, which have been fixed in Saxon 12.5. They are:

6448 Saxon-HE 12.4J has wrong column number in trace, unlike Saxon-EE
6428 Output of xsl:on-non-empty changes when using TraceListener
6415 Improved results for trace of an unreferenced XSLT variables
6407 Tree Model option -tree seems to be ignored for initial source documents
6405 Improve saxon:column-number() for text nodes not inside xsl:text

6448 Saxon-HE 12.4J has wrong column number in trace, unlike Saxon-EE
Needs to be checked by @galtm.
6428 Output of xsl:on-non-empty changes when using TraceListener
This had an impact on XSpec because xsl:on-non-empty was being invoked when the parent output no data if trace was turned on. This meant that the sequence constructor of xsl:on-non-empty was also traced and shown as 'hit' in XSpec when it should have been shown as 'missed'. The issue has been fixed in 12.5 after re-running the test case.
Part of the fix was to stop tracing the xsl:on-non-empty element and its sequence constructor whether it was invoked or not and the impact on XSpec is that it there is no trace data for xsl:on-non-empty elements and their sequence constructors.
6415 Improved results for trace of an unreferenced XSLT variables
This had an impact on which xsl:variable elements were being traced. It is fixed in 12.5 after re-running the test case.
I would like to do further checks on the coverage cases in XSpec.
6407 Tree Model option -tree seems to be ignored for initial source documents
This has no impact on XSpec but caused issues trying to diagnose other issues. The problem was that Saxon always used the Tiny tree when parsing the source document, but used the configured tree for other XML document read via doc() etc. It is fixed in 12.5.
6405 Improve saxon:column-number() for text nodes not inside xsl:text
This had an impact on XSpec because text nodes were not being marked as 'hit' because the column number of the node retrieved by the XSpec x:column-number function got the wrong value.
I don't have Saxon EE to replicate the problem and check the solution but when I tried it with Saxon HE and the XSpec line-number and column-number extension functions I got a different result in 12.4 using the Tiny tree compared to the description in the text stylesheet and Michael Kay's comments (line number/column number).
10/51 14/53 13/13 16/27 - Michael Kay in number 5 comment
10/53 14/53 13/13 16/27 - I got this for 12.4 - different column on first result by +2

For 12.5 it looks like the column number is the end of the test node asthe fix indicated.
10/51 14/61 13/13 19/17 - Michael Kay in number 8 comment, which is what I expected 12.5 to produce (the end of the text node)
10/53 14/63 13/13 19/19 - I got this in 12.5 - different columns for results 1, 2 and 4 by +2

For the linked tree I got the same values in 12.4 and 12.5 as indicated in Michael Kay's number 6 comment.
The output with the Tiny tree in 12.5 is no good for XSpec because the column number of the text node cannot be used.
A current change has changed XSpec to use the Linked Tree because of issues with column numbers retrieved in coverage-report.xsl. This change should be kept for now.
I am intending to add more to this issue.

6448 Saxon-HE 12.4J has wrong column number in trace, unlike Saxon-EE
Needs to be checked by @galtm.

With Saxon-HE 12.5, I checked the original reproduction steps in the bug report and I get the correct column number.
In our cases-coverage/xsl-on-non-empty-01.xsl file, Saxon 12.5 correctly leads to line 30 (<xsl:text>400</xsl:text>) being marked as missed.

Code Coverage Issues Introduced with Saxon 12.5
This is a list of issues introduced by the recent Saxon 12.5 release.
The impact on XSpec is that the trace produced by Saxon has changed since version 12.4 and this impacts code coverage.
@galtm has raised Saxonica issue 6463 about the omission of xsl:copy and literal result elements in the trace of 12.5.
xsl:break with a select attribute is no longer traced in 12.5, but I don't have a test case at the moment.
@birdya22 has raised Saxonica issue 6467 about an error related to xsl:merge when running with Tlevel:high, but not with other Tlevel values.
This is not currently related to XSpec because the XSpec XSLTCoverageTraceListener does not get notified of Tlevel values and uses the default level of 'normal'.
However part of the reason for writing about it here is because it is possible to write a TraceListener which is notified of Tlevel values. I came across this bit of code in Saxon HE Transform.java:
                value = options.getOptionValue("Tlevel");
                if (value != null && traceListener instanceof AbstractTraceListener) {
                    CompilerInfo info = compiler.getUnderlyingCompilerInfo();
                    TraceCodeInjector injector = (TraceCodeInjector)info.getCodeInjector();

A TraceListener needs to extends AbstractTraceListener rather than implements TraceListener to take advantage of Tlevels.
The code has changed in 12.5 so that the TraceCodeInjector is notified of the Tlevel value, which didn't happen in 12.4. This seems to have resulted in a lot more trace being generated when Tlevel:high is set (around 2.5 times based on file size).
Running a test with an amended XSLTCoverageTraceListener and setting Tlevel:high allowed 14 elements to be marked as 'hit' in the xsl-*-0n.xsl tests, including xsl:copy and some others. To do this I had to add catch="yes" in the xsl:merge-01.xspec file to catch the Saxon error, meaning that the results for that were not complete.
However, given the current issue that using Tlevel:high can cause Saxon to fail, means this doesn't seem to be a viable option at the moment.
A couple of general comments on 12.5:

where 12.4 produced trace with column numbers that were wrong (generally 0), 12.5 does not trace the nodes.
12.5 has introduced some new classes in the trace file, net.sf.saxon.expr.AtomicSequenceConverter and net.sf.saxon.expr.StringLiteral. The column numbers sometimes appear to be wrong but I think they refer to the column number within an attribute value and not within the line.
12.5 now has a class net.sf.saxon.expr.instruct.UseAttributeSet in the trace output. This corresponds to the attribute use-attribute-sets.
12.5 now has a qname of xsl:message rather than xsl:assert in the trace file for the xsl:message element.

xslt-code-coverage-by-element.md Changes
The information in the xslt-code-coverage-by-element.md file is affected by 12.5 and the following xslt element sections cover the changes that are needed.
Add a new Rule called 'Unknown' because there are now some cases where elements are not traced and their state cannot be determined by their parent or children. The description is 'The element is not in the trace data and other elements cannot be used to determine this elements status.
xsl:assert
The xslt-code-coverage-by-element.md file says xsl:assert is not traced and rule is Use Child Data.
I hadn't noticed in Saxon 12.4, but it was traced on the first child, however in Saxon 12.5 it is NOT traced and neither are the children.
The TRACE row should be changed to 'No'.
The RULE row should be changed to 'Element Specific - set to 'unknown', including all descendants.
xsl:break
The xslt-code-coverage-by-element.md file says xsl:break is traced and rule is Use Trace Data.
There is one instance in xsl-iterate-01.xsl line 104 where xsl:break is not traced and this is the only occurrence where it uses a select attribute.
The TRACE row should be changed to 'Sometimes' and a Comment added that it is not traced when it has a select attribute.
The RULE row should be changed to 'Element Specific - Use Trace Data unless select attribute is present, then mark as 'unknown'.
xsl:copy
The xslt-code-coverage-by-element.md file says xsl:copy is traced and rule is Use Trace Data.
In Saxon 12.5 xsl:copy is no longer traced if it has a select attribute and no sequence constructor.
The TRACE row should be changed to 'Sometimes' and a Comment added that it is not traced when it has a select attribute.
The RULE row should be changed to 'Element Specific - Use Trace Data unless select attribute is present, then mark as 'unknown'.
xsl:evaluate
The xslt-code-coverage-by-element.md file says xsl:evaluate is traced with a column number of 0 with the rule TBD.
In Saxon 12.5 it is not traced so the rule should be 'Unknown'.
The TRACE row should be changed to 'No'.
The RULE row should be changed to 'Unknown'.
xsl:for-each
The xslt-code-coverage-by-element.md file says xsl:for-each is traced and rule is Use Trace Data.
In Saxon 12.5 there is an example of xsl:for-each not being traced when it is a child of a xsl:map - see xsl-map-01.xsl line 050. But the same element construct is successfully traced in the xsl-for-each-01.xsl test.
Because of the general lacking of tracing in xsl:map and the fact it is marked as 'unknown' I'm inclined to say no change for xsl:for-each.
xsl:next-match
The xslt-code-coverage-by-element.md file says xsl:next-match is traced and rule is Use Trace Data.
In Saxon 12.5 in xsl-next-match-01A.xsl line 10 the xsl:next-match is not traced. It has no sequence constructor, but there is an example with no sequence constructor that is traced in xsl-next-match-01.xsl line 26.
The one that is not traced is using a built-in template.
Needs more investigation.
xsl:on-non-empty
The xslt-code-coverage-by-element.md file says xsl:on-non-empty is partly traced with a column number of 0 with the rule TBD.
In Saxon 12.5 this is no longer traced due to the Saxon fix for issue 6428.
The TRACE row should be changed to 'No'.
The RULE row should be changed to 'Unknown, including all descendants'.
The Comment should be removed.
xsl:param
The xslt-code-coverage-by-element.md file says xsl:on-param is sometimes traced with a rule TBD.
In Saxon 12.5 xsl:param is no longer traced in the cases where it had a column number of 0 in 12.4. These are when it is the child of a xsl:template and has a select attribute.
Change the Comment from 'xsl:template xsl:param with select attribute - trace with column 0.' to 'xsl:template xsl:param with select attribute - not traced.'
xsl:perform-sort
The xslt-code-coverage-by-element.md file says xsl:perform-sort is sometimes traced with a rule TBD.
In Saxon 12.5 it is no longer traced when it has a select attribute. In 12.4 it was traced but with a column number of 4, which was wrong.
Change the Comment from 'With a select attribute, the column number is 4 in the trace output.' to 'With a select attribute it is not traced.'.
xsl:sequence
The xslt-code-coverage-by-element.md file says xsl:sequence is not traced and rule is Use Child Data.
In Saxon 12.5 there are examples of it being traced when it has a select attribute but the column numbers are inconsistent.
Change the Comment from 'With a select attribute, there is no trace information.' to 'With a select attribute, there is some trace information but the column numbers are wrong.'.
xsl:try
The xslt-code-coverage-by-element.md file says xsl:try is partly traced with a rule TBD.
In Saxon 12.5 with a select attribute xsl:try is not longer traced. In 12.4 it was traced but with wrong column numbers (0 and 7).
Change the Comment from 'With a select attribute, this element is traced, but the column number is wrong (7 and 0 occur in the xsl-try-01.xsl trace output). In all cases, the class is net.sf.saxon.expr.TryCatch.' to 'With a select attribute it is not traced.'.
xsl:variable
The xslt-code-coverage-by-element.md file says xsl:variable is sometimes traced with a rule TBD.
In Saxon 12.5 xsl:variable is no longer traced in some cases but is traced in other cases compared to 12.4.
The general conclusion is that xsl:variable elements have less 'hit' elements in 12.5 compared to 12.4. In some cases that is correct and in others it is not.
The statement 'With Non-global variables, it is difficult to assess and the best approach is probably to rely on the Saxon results.' is still true.

Because Saxon 12.5 compared to 12.4 has both pros and cons as far as code coverage is concerned, there could be a long period in which users need to weigh tradeoffs before deciding which version to use to generate their coverage reports. I'm inclined to add version 12.5 information to the xslt-code-coverage-by-element.md file alongside the 12.4 information, instead of replacing 12.4 information with 12.5 information. That seems less cumbersome than having separate .md files or having to dig up a 12.4-specific version of the file from Git history.
@birdya22 : Do you agree with the dual-version documentation approach for this .md file? I can work on the updates (unless you want to). Thanks for doing the research and writing it up here.

@birdya22 : Do you agree with the dual-version documentation approach for this .md file?

I'm not sure at the moment, and need to understand how you see it being used.
Can you clarify:

who will use the xslt-code-coverage-by-element.md file?
what information you think users will use to weigh tradeoffs:

the xslt-code-coverage-by-element.md file, which is part of the code base and not the Wiki currently
a new 12.4/12.5 code coverage comparison document for the Wiki based on the xslt-code-coverage-by-element.md
something else

what software will the users choose between:

a choice between XSpec 3.0.3/Saxon 12.4 and XSpec x.x.x/Saxon 12.5 (where x.x.x is the next version)
a choice between XSpec x.x.x/Saxon 12.4 and XSpec x.x.x/Saxon 12.5 (where x.x.x is the next version)
or some other combinations?

At the moment, "insiders" like us might be the only people actively using xslt-code-coverage-by-element.md. The Wiki doesn't link to it or mention it.
Suppose a user creates a GitHub issue in the near future, describing problems with the coverage reports they get from whatever XSpec and Saxon versions they have tried and asking for information or advice. If they'd like to see some improvement sooner rather than later, they might consider a choice between XSpec master branch + Saxon 12.4 and XSpec master branch + Saxon 12.5. If xslt-code-coverage-by-element.md has information about 12.4 and 12.5, that document could help them decide.
The Wiki page about code coverage is currently pretty high-level. Maybe it should point to xslt-code-coverage-by-element.md, or maybe the Wiki page itself should grow to become more detailed after the code coverage feature stabilizes at a higher quality state. If improving the Wiki is something you're interested in, let me know. For what it's worth, modifying the Wiki pages can be done in a web browser, not with pull requests.

xsl:perform-sort
The xslt-code-coverage-by-element.md file says xsl:perform-sort is sometimes traced with a rule TBD. In Saxon 12.5 it is no longer traced when it has a select attribute. In 12.4 it was traced but with a column number of 4, which was wrong. Change the Comment from 'With a select attribute, the column number is 4 in the trace output.' to 'With a select attribute it is not traced.'.

From the coverage test for xsl:perform-sort, it looks like xsl:perform-sort with a sequence constructor is not traced in Saxon 12.4 or 12.5. The trace file with 12.4 shows no hit on line 22, and I see the same locally when I use 12.5.
If I'm mistaken, please let me know. Otherwise, the changes could be like this:

The TRACE row should be changed to 'No'.
The RULE row should be changed to 'Use Child Data' (as updated with #1974).
Replace comments with something like, 'The sequence constructor, if present, is traced. The xsl:sort child is not traced.'

By the way, the developers of the Oxygen debugger also rely on Saxon trace data and noticed that xsl:message and xsl:value-of aren't traced with Saxon 12.5 in a certain example.
https://saxonica.plan.io/issues/6492

So I see.
I'm sure that's not the only issue they'll come across.
It is not mentioned in the announcement for Saxon 12.5, but -Tlevel:high gives a lot more trace than -Tlevel:normal where as in 11.6 and 12.4 you used to get the same amount of trace for both. Using -Tlevel:high might help with their problem (from someone who's never seen Oxygen, let alone its debugger).

Thinking about it a bit, I got slightly worried there there might be a test case where elements are not traced, so I had a look at the test case more closely.
Note: The trace from Saxon 12.4 is the same as from 11.6.
xsl:message
The column numbers in the trace are difficult to interpret because it looks like the indentation in the stylesheet has been lost.
XSpec treats the xsl:message line as a hit because of the following trace line, so although the xsl:message element isn't traced directly, the line below allows XSpec to declare a 'hit':
<xsl:text text="mes" line="8" column="22" module="personal.xsl">
</xsl:text>

Having said that, I did notice that there isn't a test case which is just <xsl:message>text() node</xsl:message>.
xsl:value-of
The xslt-code-coverage-by-element.md file has TRACE = Yes and there's nothing in this issue that says xsl:variable isn't traced in Saxon 12.5.
There is no trace for the 2 xsl:value-of elements in the test case in Saxon 12.5, so this introduces a new scenario that the XSpec test cases don't currently cover.
Although there is a test case in theSAxonica issue  I'm not sure what the exact circumstances are that causes this lack of trace. I will have a play to see if I can identify the circumstances and then raise a new issue.
NOTE: in the Saxon 11.6 trace I notice that the column umbers are 0 for the xsl:value-of elements.

there isn't a test case which is just <xsl:message>text() node</xsl:message>

So far, I've added such a test case locally but not made a pull request just yet. I'll be interested to see whether the bug report has any comments that suggest what the scope of the issue is. Most of the Saxonica engineers are busy with the Balisage conference this week, so there could be a delay in their response.

Great sleuthing, and your last paragraph sounds wise.

I see that Michael Kay has replied and fixed the Oxygen issue https://saxonica.plan.io/issues/6492
From my own test, I disagree with his statement (although I doubt that affects his fix):

In the past a LocalParam was always part of a LocalParamBlock, but we now get rid of that extra layer if there's only one parameter, which is probably why the regresssion occurred.

because when I add 2 xsl:param elements with select attributes I still get the same result where nodes are not being traced.
If the first xsl:param has a default value via a select attribute or a sequence constructor then following elements are not traced.
If the first xsl:param has no default value then following elements ARE traced.
I haven't given much thought to the XSpec solution for this, but here are some initial thoughts:

test all elements in the scenario where xsl:param with a default value is the first child of xsl:template  and update the design and all test cases where elements are no longer traced 100% of the time - an awful lot of work
accept that this is an issue with xsl:param having a default value when it is the first element in a xsl:template and do updates on that basis e.g. add some overarching statement in the design about the issue and add a new test case and rule
???

In addition to the above, test if the same thing happens when a xsl:param is a child of other nodes, which probably should be the first step, as it could influence the way forward.
As a starting point, I'll create a test case that covers the issue and includes all the different parents of xsl:param.

I am not in favor of option 1. Working around that bug seems different from accepting that Saxon doesn't trace certain elements at all or certain simple patterns (like certain elements when they have @select). I am concerned that marking a lot of nodes as "unknown" as a result of this less-simple pattern might mask other bugs. It's better if those bugs can be reported and fixed.
To make sure I understand what your option 2 means:

Does "overarching statement in the design" refer not only to the .md design document but also the user-facing wiki eventually?
Does "do updates on that basis" mean documentation and testing, while leaving the logic in coverage-compute-status.xsl as is?

Does "overarching statement in the design" refer not only to the .md design document but also the user-facing wiki eventually?

Yes. If this is a serious issue for users would you suggest a work around of adding in a dummy first xsl:param or  potentially re-arranging existing xsl:param elements so that the first one doesn't have a select attribute if thats possible.

Does "do updates on that basis" mean documentation and testing, while leaving the logic in coverage-compute-status.xsl as is?

When I wrote it I was thinking of a new rule in coverage-compute-status.xsl but see below.
I've attached a test case which is still a work in progress (the x:expect data is not set yet). There are quite a lot of comments at the start.
An issue is that a xsl:param with a sequence constructor and no value supplied by the caller is also affected by the Saxon issue. That makes it very difficult to decide what the solution should be.
xsl-param-03.xspec.txt
xsl-param-03.xsl.txt

Thanks for the additional test case, which I played with a little.
I clarified option 2 based on your reply above and also added options 3 and 4.

Test all elements in the scenario where xsl:param with a default value is the first child of xsl:template and update the design and all test cases where elements are no longer traced 100% of the time - an awful lot of work
Accept that this is an issue with xsl:param having a default value when it is the first element in a xsl:template and do updates on that basis e.g. add some overarching statement in the design (.md + wiki) about the issue, add a new test case, and add a new rule
Add some overarching statement in the design (.md + wiki) about the issue but do not make XSpec work around the issue. XSpec users can decide whether to use Saxon 12.4 or 12.5 for generating their code coverage reports -- and if 12.5, whether to apply a workaround to their XSLT code, such as a dummy template parameter in the first position or changing the order of template parameters.
Same as 3, but instead of documenting version 12.5 issues for XSpec users in detail, recommend using Saxon 12.4 for generating code coverage reports.

I am thinking about how to bring XSpec 3.1 to fruition. The scheduled date of v3.1 was chosen to make it likely that the next Oxygen release will bundle XSpec 3.1 instead of 3.0. I'd like to try sticking to the date -- especially since we've improved the (Saxon 12.4-based) code coverage reports since XSpec 3.0.3, and it would be good to deliver those fixes to users. The release schedule is supposed to include buffer time for users to try out a pre-release version and give feedback.
This issue really worries me. Template parameters with default values are common in XSLT, so the issue could affect many users and many lines of their code for which they generate reports. Any workaround is potentially fragile: Does it also work with Saxon-EE, which could have different optimizations compared to Saxon-HE? Will it work with a future Saxon 12.x, or will users need to redo their workarounds? It could be that the best advice to XSpec users is to use Saxon 12.4 for now. Instead of spending a lot of time weighing the pros and cons of 12.5 vs. 12.4, it might be more productive to try obtaining a pre-release of Saxon 13 and spend time making XSpec work as well as possible with Saxon 13 for an XSpec release beyond 3.1. Michael Kay has said he made more substantive changes on the 13.x branch than on the 12.x branch. That suggests that 13.x will probably be a better foundation for XSpec code coverage reporting than 12.x and also that the XSpec code base might need to adapt to the changes in 13.x.
I haven't reached a firm opinion, but my current leaning is toward option 3 or 4.
I plan to make a pull request soon with a rule for text nodes and then decrease the amount of time I spend on code coverage for the next few weeks.

pull request soon with a rule for text nodes

Created #1990

Instead of spending a lot of time weighing the pros and cons of 12.5 vs. 12.4, it might be more productive to try obtaining a pre-release of Saxon 13 and spend time making XSpec work as well as possible with Saxon 13 for an XSpec release beyond 3.1

A couple of Saxon issues have mentioned a 12.6 -  6487 and 6462.
I'm not sure you'll get a pre-release - it might be worth asking for a definition/design of the changes in 13 that are related to tracing, possibly with some examples.

I haven't reached a firm opinion, but my current leaning is toward option 3 or 4.

My suggestion would be a combination of 3 and 4.
Recommend 12.4 but provide details of why 12.5 isn't the recommended option, but without details of the work arounds (users can decide what they want to do and if they want to do their own work around).
You could also provide a link to the 12.5 Release Announcement so that they can see if there is anything in 12.5 they really need.

I hope 12.6 will be unambiguously better than 12.4 or 12.5 for code coverage! Thanks for your suggestions. I was going to say that when I draft release notes for XSpec 3.1 later this month, I'll invite you to review them. Then I realized that before the release is public, the release notes are visible only to members/collaborators of this repo in GitHub. I can try adding you to that list, if it's OK with you.

@birdya22 : I added you to the list, and you should have received an invitation email from GitHub. If you accept the invitation and then view the page https://github.com/xspec/xspec/releases (while you're logged into GitHub), do you see "v3.1.1" at the top with a Draft icon? If that worked, then I'll Cc: you on #1912 when I draft the release notes summary.

I see "v3.0.3" at the top but not "v3.1.1".

I have created 2 new Saxonica issues related to the transform() function. They are

SaxonJ-HE 12.5 trace not well-formed when XSLT uses transform function to call template 6497 - this is related to a previous issue 6302 where there was invalid XML produced when calling a function via transform(). That was fixed in 12.5. but there was a regression when calling a template via transform() in 12.5 because that now produces invalid XML when using the Saxon TraceListener. I don't believe this affects XSpec.
SaxonJ-HE 12.5 Normal Level of Trace output when using fn:transform() with -Tlevel:high 6498 - the trace output isn't at the 'high' level when using transform(). This doesn't affect XSpec currently, but is a blocker to using -Tlevel:high in XSpec because run-as="external" make use of the transform() function. Trace level of 'high' would provide better code coverage results (See XSpec issue 1982). For completeness I have also added these details to that XSpec issue.

I see "v3.0.3" at the top but not "v3.1.1".

I changed your permission level today. I don't think that should make a difference, but can you try again just in case?
Thanks for creating the Saxonica issues and adding notes about them in this repo.

I can see "v3.1.1" now.
@galtm - have a look at Michael Kay's response to 6497. I'll let you respond.

I don't know how these things work, but did you get Michael Kay's update via email at about 16:48 (my time):

Let's try and schedule a Zoom call next week. Tuesday 15:00 UTC perhaps?. I think it would be useful to include Norm from our side.

I don't know how these things work, but did you get Michael Kay's update via email at about 16:48 (my time):

Let's try and schedule a Zoom call next week. Tuesday 15:00 UTC perhaps?. I think it would be useful to include Norm from our side.

I didn't get it from Saxonica by email, so thanks for your comment here, causing GitHub to send me an email. The date and time he suggested works for me. How about you?

I can make it if you would like me to.

I'd like that. Thank you!

there isn't a test case which is just <xsl:message>text() node</xsl:message>

So far, I've added such a test case locally but not made a pull request just yet.

Created #1997


Grpc gen validator

merging this PR because need theses changes in main, but this branch will kepp as live to continue work for grpc validation plugin


Remove fast node cache and benchmark

Background
We suspect that fastNodeCache in nodeDb may not be very useful. We should attempt to remove it and benchmark the results
Acceptance Criteria

remove fastNodeCache from nodeDb
benchmark
merge the change depending on whether an improvement is observed

cache.log:
iavl:
git commit:
git branch:
go version go1.17.3 linux/amd64

Init Tree took 66.88 MB
goos: linux
goarch: amd64
pkg: github.com/cosmos/iavl/benchmarks
cpu: AMD Ryzen 7 3700X 8-Core Processor
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-fast-16             409921              2952 ns/op             814 B/op      16 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-fast-16             413432              3032 ns/op             814 B/op      16 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-fast-16             437080              2921 ns/op             814 B/op      16 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-fast-16             450187              2984 ns/op             814 B/op      16 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-fast-16             415393              3005 ns/op             814 B/op      16 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-slow-16             116660              9018 ns/op            1404 B/op      24 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-slow-16             126883              9616 ns/op            1412 B/op      24 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-slow-16             109087              9539 ns/op            1408 B/op      24 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-slow-16             105081              9530 ns/op            1410 B/op      24 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-slow-16             107452              9870 ns/op            1422 B/op      25 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-fast-16                            2281778               512.9 ns/op            22 B/op       0 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-fast-16                            2415718               467.0 ns/op            13 B/op       0 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-fast-16                            2850028               409.7 ns/op             9 B/op       0 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-fast-16                            2650272               400.4 ns/op             7 B/op       0 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-fast-16                            3019638               401.9 ns/op             5 B/op       0 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-slow-16                              83739             13331 ns/op            1989 B/op      34 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-slow-16                              82207             13414 ns/op            1997 B/op      34 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-slow-16                              87763             13213 ns/op            1997 B/op      34 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-slow-16                              85336             13063 ns/op            1994 B/op      34 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-slow-16                              88747             13510 ns/op            1994 B/op      34 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16                                  21          65798802 ns/op        29327116 B/op  522985 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
        ... [output truncated]
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16                                  24          65081808 ns/op        29327085 B/op  522985 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
        ... [output truncated]
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16                                  19          63440390 ns/op        29327105 B/op  522984 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
        ... [output truncated]
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16                                  16          70851619 ns/op        29327165 B/op  522986 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
        ... [output truncated]
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16                                  24          63981203 ns/op        29327077 B/op  522984 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
        ... [output truncated]
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16                                   1<PHONE_NUMBER> ns/op        234506024 B/op        3990789 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16
    bench_test.go:143: completed 100000 iterations
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16                                   1<PHONE_NUMBER> ns/op        276163048 B/op        4705768 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16
    bench_test.go:143: completed 100000 iterations
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16                                   1<PHONE_NUMBER> ns/op        276107952 B/op        4705548 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16
    bench_test.go:143: completed 100000 iterations
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16                                   1<PHONE_NUMBER> ns/op        276114160 B/op        4705554 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16
    bench_test.go:143: completed 100000 iterations
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16                                   1<PHONE_NUMBER> ns/op        276119104 B/op        4705556 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16
    bench_test.go:143: completed 100000 iterations
BenchmarkMedium/goleveldb-100000-100-16-40/update-16                                        8560            138764 ns/op           48101 B/op     481 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/update-16                                        7516            182969 ns/op           51551 B/op     545 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/update-16                                        7371            178423 ns/op           51944 B/op     595 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/update-16                                        6032            182461 ns/op           52321 B/op     598 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/update-16                                        6693            180266 ns/op           51656 B/op     592 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/block-16                                           55          22694269 ns/op         6382976 B/op   71897 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/block-16                                           70          22618362 ns/op         6422396 B/op   72678 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/block-16                                           55          24569598 ns/op         6588177 B/op   73777 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/block-16                                           49          22197088 ns/op         6183273 B/op   71091 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/block-16                                           46          23527320 ns/op         6564015 B/op   74866 allocs/op
PASS
ok      github.com/cosmos/iavl/benchmarks       72.810s

nocache.log:
iavl:
git commit:
git branch:
go version go1.17.3 linux/amd64

Init Tree took 48.34 MB
goos: linux
goarch: amd64
pkg: github.com/cosmos/iavl/benchmarks
cpu: AMD Ryzen 7 3700X 8-Core Processor
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-fast-16         	  390157	      2903 ns/op	     814 B/op	      16 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-fast-16         	  399000	      2963 ns/op	     814 B/op	      16 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-fast-16         	  402136	      3179 ns/op	     814 B/op	      16 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-fast-16         	  420476	      2937 ns/op	     814 B/op	      16 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-fast-16         	  417190	      3076 ns/op	     814 B/op	      16 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-slow-16         	  113926	      9762 ns/op	    1409 B/op	      24 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-slow-16         	  105357	      9851 ns/op	    1406 B/op	      24 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-slow-16         	  109642	      9834 ns/op	    1405 B/op	      24 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-slow-16         	  103359	      9763 ns/op	    1406 B/op	      24 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-slow-16         	  125224	     10063 ns/op	    1409 B/op	      24 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-fast-16                         	  345147	      3447 ns/op	     886 B/op	      16 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-fast-16                         	  353240	      3364 ns/op	     886 B/op	      16 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-fast-16                         	  350920	      3338 ns/op	     886 B/op	      16 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-fast-16                         	  372626	      3307 ns/op	     886 B/op	      16 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-fast-16                         	  367660	      3294 ns/op	     886 B/op	      16 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-slow-16                         	   86119	     12926 ns/op	    1990 B/op	      34 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-slow-16                         	   83398	     12708 ns/op	    1990 B/op	      34 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-slow-16                         	   86103	     14252 ns/op	    2003 B/op	      34 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-slow-16                         	   90589	     13302 ns/op	    1989 B/op	      34 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/query-hits-slow-16                         	   85428	     13497 ns/op	    2000 B/op	      34 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16                          	      21	  68717304 ns/op	29327113 B/op	  522985 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
	... [output truncated]
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16                          	      15	  70264586 ns/op	29327162 B/op	  522985 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
	... [output truncated]
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16                          	      18	  70958463 ns/op	29327138 B/op	  522985 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
	... [output truncated]
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16                          	      15	  72209305 ns/op	29327158 B/op	  522985 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
	... [output truncated]
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16                          	      22	  73218143 ns/op	29327098 B/op	  522985 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-fast-16
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
    bench_test.go:143: completed 100000 iterations
	... [output truncated]
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16                          	       1<PHONE_NUMBER> ns/op	234491104 B/op	 3991442 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16
    bench_test.go:143: completed 100000 iterations
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16                          	       1<PHONE_NUMBER> ns/op	276134112 B/op	 4705557 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16
    bench_test.go:143: completed 100000 iterations
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16                          	       1<PHONE_NUMBER> ns/op	276095808 B/op	 4705374 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16
    bench_test.go:143: completed 100000 iterations
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16                          	       1<PHONE_NUMBER> ns/op	276080216 B/op	 4705371 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16
    bench_test.go:143: completed 100000 iterations
BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16                          	       1<PHONE_NUMBER> ns/op	276095856 B/op	 4705377 allocs/op
--- BENCH: BenchmarkMedium/goleveldb-100000-100-16-40/iteration-slow-16
    bench_test.go:143: completed 100000 iterations
BenchmarkMedium/goleveldb-100000-100-16-40/update-16                                  	    9696	    146592 ns/op	   47615 B/op	     475 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/update-16                                  	    6853	    181887 ns/op	   51788 B/op	     542 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/update-16                                  	    7207	    181912 ns/op	   54073 B/op	     614 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/update-16                                  	    6890	    183622 ns/op	   54070 B/op	     604 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/update-16                                  	    6342	    194800 ns/op	   55598 B/op	     597 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/block-16                                   	      39	  26758858 ns/op	 7043085 B/op	   77740 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/block-16                                   	      55	  23525001 ns/op	 6802199 B/op	   73821 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/block-16                                   	      46	  23722432 ns/op	 6539204 B/op	   72672 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/block-16                                   	      70	  23866420 ns/op	 6759421 B/op	   74000 allocs/op
BenchmarkMedium/goleveldb-100000-100-16-40/block-16                                   	      48	  27214536 ns/op	 7338237 B/op	   76913 allocs/op
PASS
ok  	github.com/cosmos/iavl/benchmarks	69.591s

Comparison:
name                                                                  old time/op    new time/op    delta
Medium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-fast-16    2.98µs ± 2%    3.01µs ± 6%       ~     (p=1.000 n=5+5)
Medium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-slow-16    9.51µs ± 5%    9.85µs ± 2%       ~     (p=0.095 n=5+5)
Medium/goleveldb-100000-100-16-40/query-hits-fast-16                     438ns ±17%    3350ns ± 3%   +664.18%  (p=0.008 n=5+5)
Medium/goleveldb-100000-100-16-40/query-hits-slow-16                    13.3µs ± 2%    13.3µs ± 7%       ~     (p=0.841 n=5+5)
Medium/goleveldb-100000-100-16-40/iteration-fast-16                     65.8ms ± 8%    71.1ms ± 3%     +7.96%  (p=0.032 n=5+5)
Medium/goleveldb-100000-100-16-40/iteration-slow-16                      1.24s ±14%     1.24s ±11%       ~     (p=1.000 n=5+5)
Medium/goleveldb-100000-100-16-40/update-16                              181µs ± 1%     178µs ±18%       ~     (p=0.730 n=4+5)
Medium/goleveldb-100000-100-16-40/block-16                              23.1ms ± 6%    25.0ms ± 9%       ~     (p=0.095 n=5+5)

name                                                                  old alloc/op   new alloc/op   delta
Medium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-fast-16      814B ± 0%      814B ± 0%       ~     (all equal)
Medium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-slow-16    1.41kB ± 1%    1.41kB ± 0%       ~     (p=0.286 n=5+5)
Medium/goleveldb-100000-100-16-40/query-hits-fast-16                     11.2B ±96%    886.0B ± 0%  +7810.71%  (p=0.008 n=5+5)
Medium/goleveldb-100000-100-16-40/query-hits-slow-16                    1.99kB ± 0%    1.99kB ± 0%       ~     (p=1.000 n=5+5)
Medium/goleveldb-100000-100-16-40/iteration-fast-16                     29.3MB ± 0%    29.3MB ± 0%       ~     (p=0.421 n=5+5)
Medium/goleveldb-100000-100-16-40/iteration-slow-16                      276MB ± 0%     276MB ± 0%       ~     (p=0.200 n=4+4)
Medium/goleveldb-100000-100-16-40/update-16                             51.1kB ± 6%    52.6kB ±10%       ~     (p=0.310 n=5+5)
Medium/goleveldb-100000-100-16-40/block-16                              6.43MB ± 4%    6.90MB ± 6%     +7.28%  (p=0.032 n=5+5)

name                                                                  old allocs/op  new allocs/op  delta
Medium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-fast-16      16.0 ± 0%      16.0 ± 0%       ~     (all equal)
Medium/goleveldb-100000-100-16-40/query-no-in-tree-guarantee-slow-16      24.0 ± 0%      24.0 ± 0%       ~     (all equal)
Medium/goleveldb-100000-100-16-40/query-hits-fast-16                      0.00          16.00 ± 0%      +Inf%  (p=0.008 n=5+5)
Medium/goleveldb-100000-100-16-40/query-hits-slow-16                      34.0 ± 0%      34.0 ± 0%       ~     (all equal)
Medium/goleveldb-100000-100-16-40/iteration-fast-16                       523k ± 0%      523k ± 0%       ~     (p=0.444 n=5+5)
Medium/goleveldb-100000-100-16-40/iteration-slow-16                      4.71M ± 0%     4.71M ± 0%       ~     (p=0.200 n=4+4)
Medium/goleveldb-100000-100-16-40/update-16                                562 ±14%       566 ±16%       ~     (p=0.690 n=5+5)
Medium/goleveldb-100000-100-16-40/block-16                               72.9k ± 3%     75.0k ± 4%       ~     (p=0.151 n=5+5)

Clearly, having cache in nodedb does make a big difference

science!  that is why it's called a lab <3
Btw, nice benchmarks sir

It is surprising to me that the decrease in performance affected only query-hits-fast-16, not iterations or "not in tree queries". query-hits-fast-16 are the queries that guarantee for the keys we are querying for to be present in the tree. The reduced performance with no cache implies that there is no substitute cache in goleveldb.
Our initial guess was that the cache in nodedb might be redundant since, from my understanding, there are 2 "in-memory" features in goleveldb:

first, we write to memdb, and when it fills up we flush it to disk

I was surprised to see that Get() did not go to membdb. On the other hand, it went to disk directly

There should be an 8 MB default LRU cache in goleveldb.

I did the pprof of queries-hits-fast-16. The relevant path is the rightmost in light red:

According to pprof, Get() does not indeed go to memdb and, instead, directly to disk. This can be seen in this call to get() where the provided as a parameter auxm *memdb.DB is nil. It is not nil only when transactions are used.
From pprof, we also see that there are calls to Cache.get() at the bottom of the graph. I investigated that call and found out that there is a configuration option DontFillCache. It seems to be false by default (what we need).
At this point, it is unclear to me why I can't observe cache being utilized in golebeldb
I am going to pause the work on this issue since the scope has changed. I will come back to it when I'm working on https://github.com/osmosis-labs/iavl/issues/32 which is about investigating goleveldb configs. Once I understand some goleveldb configs, I will see if it makes removing fast node cache from nodedb.
My branch with no fast cache in node db: roman/remove-fast-cache
The goleveldb settings that get enabled by default are:
{
   "AltFilters":"nil",
   "BlockCacher":"nil",
   "BlockCacheCapacity":0,
   "BlockCacheEvictRemoved":false,
   "BlockRestartInterval":0,
   "BlockSize":0,
   "CompactionExpandLimitFactor":0,
   "CompactionGPOverlapsFactor":0,
   "CompactionL0Trigger":0,
   "CompactionSourceLimitFactor":0,
   "CompactionTableSize":0,
   "CompactionTableSizeMultiplier":0,
   "CompactionTableSizeMultiplierPerLevel":"nil",
   "CompactionTotalSize":0,
   "CompactionTotalSizeMultiplier":0,
   "CompactionTotalSizeMultiplierPerLevel":"nil",
   "Comparer":"nil",
   "Compression":0,
   "DisableBufferPool":false,
   "DisableBlockCache":false,
   "DisableCompactionBackoff":false,
   "DisableLargeBatchTransaction":false,
   "DisableSeeksCompaction":false,
   "ErrorIfExist":false,
   "ErrorIfMissing":false,
   "Filter":"nil",
   "IteratorSamplingRate":0,
   "NoSync":false,
   "NoWriteMerge":false,
   "OpenFilesCacher":"nil",
   "OpenFilesCacheCapacity":0,
   "ReadOnly":false,
   "Strict":58,
   "WriteBuffer":0,
   "WriteL0PauseTrigger":0,
   "WriteL0SlowdownTrigger":0,
   "FilterBaseLg":0
}

I created a manual test where I set only 2 keys i.e.:
d.Set([]byte("key1"), []byte("value1"))
d.Set([]byte("key2"), []byte("value2"))

Then, to simulate the query-hits-fast-16 bench I attempted to retrieve "key1":
_, err = d.Get([]byte("key1"))
require.NoError(t, err)

Contrary to the pprof results from the benchmark, it went to the in-memory db within goleveldb .
We might need to configure this in-memory db to work with more data (or key-value pairs)

This issue is resolved, reconfigured fast cache to a smaller value


colors on output

Add colors on output (maybe with possibility to switch on/off)

First part's in library 👍

4e485e0

I think, mostly all is done here 😃  You can specific color on each line/word and set some simple formating.
Included:

colors
formating

bold
underline
dim


Generate dependencies licenses in CI job

What does this gen make for? Usually dependencies LICENSE should be hosted on git, and re-gen to compare diff for forcing update when dependency lib changed.

What does this gen make for? Usually dependencies LICENSE should be hosted on git, and re-gen to compare diff for forcing update when dependency lib changed.

It's for the same purpose, but it's absent in the check job.


fix(fscomponents): add additional safety check for ProductItemImage

Component returns null if an image source lacks a uri

This seems like a case where the image shouldn't be defined if it isn't a valid source, so it's fixing a symptom to the problem instead of the problem itself, and it also makes it so we only support the source format where it uses uri.


HADOOP-17795. Provide fallback properties for callqueue.impl and scheduler.impl

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 35s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
31m  4s

trunk passed

+1 :green_heart:
compile
21m  6s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
18m 10s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
1m 10s

trunk passed

+1 :green_heart:
mvnsite
1m 38s

trunk passed

+1 :green_heart:
javadoc
1m  9s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 40s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
2m 23s

trunk passed

+1 :green_heart:
shadedclient
15m 40s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 54s

the patch passed

+1 :green_heart:
compile
20m 11s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javac
20m 11s

the patch passed

+1 :green_heart:
compile
18m 11s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
javac
18m 11s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m  9s

the patch passed

+1 :green_heart:
mvnsite
1m 34s

the patch passed

+1 :green_heart:
javadoc
1m  6s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 40s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
2m 33s

the patch passed

+1 :green_heart:
shadedclient
15m 58s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
17m  1s

hadoop-common in the patch passed.

+1 :green_heart:
asflicense
1m  0s

The patch does not generate ASF License warnings.

176m 34s

Subsystem
Report/Notes

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

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

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

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

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 6bec36fbb7175519043abbd396e5df185fa9cff9

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

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

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

modules
C: hadoop-common-project/hadoop-common U: hadoop-common-project/hadoop-common

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

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

@aajisaka @ayushtkn @tasanuma Could you please review? Thanks

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 37s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
30m 56s

trunk passed

+1 :green_heart:
compile
21m  1s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
18m 17s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
1m  9s

trunk passed

+1 :green_heart:
mvnsite
1m 36s

trunk passed

+1 :green_heart:
javadoc
1m 10s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 41s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
2m 26s

trunk passed

+1 :green_heart:
shadedclient
15m 52s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 57s

the patch passed

+1 :green_heart:
compile
20m 11s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javac
20m 11s

the patch passed

+1 :green_heart:
compile
18m 12s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
javac
18m 12s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m  9s

the patch passed

+1 :green_heart:
mvnsite
1m 34s

the patch passed

+1 :green_heart:
xml
0m  2s

The patch has no ill-formed XML file.

+1 :green_heart:
javadoc
1m  9s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 41s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
2m 38s

the patch passed

+1 :green_heart:
shadedclient
15m 57s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
17m  5s
/patch-unit-hadoop-common-project_hadoop-common.txt
hadoop-common in the patch passed.

+1 :green_heart:
asflicense
0m 59s

The patch does not generate ASF License warnings.

176m 35s

Reason
Tests

Failed junit tests
hadoop.conf.TestCommonConfigurationFields

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell xml

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

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / db4828f254723476dd31940d2dfe34e58f8a0d4b

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

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

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

modules
C: hadoop-common-project/hadoop-common U: hadoop-common-project/hadoop-common

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

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 33s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
30m 42s

trunk passed

+1 :green_heart:
compile
21m  0s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
18m 16s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
1m 10s

trunk passed

+1 :green_heart:
mvnsite
1m 37s

trunk passed

+1 :green_heart:
javadoc
1m 10s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 38s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
2m 27s

trunk passed

+1 :green_heart:
shadedclient
15m 42s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 55s

the patch passed

+1 :green_heart:
compile
20m 19s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javac
20m 19s

the patch passed

+1 :green_heart:
compile
18m 12s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
javac
18m 12s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m  8s

the patch passed

+1 :green_heart:
mvnsite
1m 33s

the patch passed

+1 :green_heart:
xml
0m  2s

The patch has no ill-formed XML file.

+1 :green_heart:
javadoc
1m  8s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 37s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
2m 33s

the patch passed

+1 :green_heart:
shadedclient
16m  4s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
17m  0s

hadoop-common in the patch passed.

+1 :green_heart:
asflicense
0m 58s

The patch does not generate ASF License warnings.

176m  3s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3192/3/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell xml

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

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 86f9522dce7e674283028a2d0774390246d201fa

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3192/3/testReport/

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

modules
C: hadoop-common-project/hadoop-common U: hadoop-common-project/hadoop-common

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3192/3/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

Merged it. Thanks for your contribution, @virajjasani. Thanks for your review, @jojochuang.


Forking plan given upstream license changes?

The current FAQ says:

Are you forking Elasticsearch?
No. Open Distro for Elasticsearch is not a fork. In fact, we intend to continue making contributions to the Apache 2.0-licensed Elasticsearch code.

In light of Elastic's recent license change, core ES code will no longer be Apache 2.0 licensed from 7.11 onwards.
My guess is the text of the FAQ needs to be updated now – it would be good to hear what Open Distro's plan is going forward w/ regards to a fork (I assume one will be needed now?) and what goals it has for feature parity w/ Elastic's project as new versions are rolled out.

Also interested in this topic. Especially if you plan to produce Maven Central artifacts for client libraries, and if so, under which groupID this will happen. We would prefer to have a dedicated group (even when this is much more work) so in order to whitelist only the groupid which is known to stay FOSS.

Also interested in this topic. Especially if you plan to produce Maven Central artifacts for client libraries, and if so, under which groupID this will happen. We would prefer to have a dedicated group (even when this is much more work) so in order to whitelist only the groupid which is known to stay FOSS.

Thanks for asking, and great point about Maven Central. We're working on this very plan now - more to come shortly.

Thanks for asking, and great point about Maven Central. We're working on this very plan now - more to come shortly.

Hi - following up on this question. You can read about the plan on the AWS Open Source blog here: https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/

Hi - following up on this question. You can read about the plan on the AWS Open Source blog here: https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/

Great, thanks for that @jcgraybill – I think once the Open Distro FAQ is updated to reflect that plan we can close this out.

Great, thanks for that @jcgraybill – I think once the Open Distro FAQ is updated to reflect that plan we can close this out.

We're working on that very thing. In the meantime, feel free to ask any follow-up questions in this thread in the forums: https://discuss.opendistrocommunity.dev/t/recent-elastic-co-licensing-change-announcment/4583/46

We're working on that very thing. In the meantime, feel free to ask any follow-up questions in this thread in the forums: https://discuss.opendistrocommunity.dev/t/recent-elastic-co-licensing-change-announcment/4583/46

Amazing news!

Amazing news!

FYI we've added several questions about the fork plan to the Open Distro FAQ. There will also be updates on the Open Distro blog, and discussion in the forums.
Thanks for all the interest! I'm going to close this issue, and we can keep the conversation going in the forums and blog.


Upgrade dependency

Upgrade<EMAIL_ADDRESS>to version

Please ignore this PR and close it. Generated by TestIM


Bug in network check

On this line:
https://github.com/DataDog/integrations-core/blob/master/network/check.py#L438
This should be self.log rather than self.logger.  As it is, this raises
AttributeError: 'Network' object has no attribute 'logger'

Thank you @alertedsnake! Good eye, we'll try to get that fixed ASAP.


Add five new CI services

Add Bitrise, Magnum CI, Ship.io, Snap CI, and Visual Studio Online.

LGTM


Intercore messaging Quality-of-Life improvements

Provide friendly names for intercore messages.
Use the same standard technique in all locations
for intercore messaging (at least two different
methods were used before).
Validate that the confirmation response for each
message corresponds to the one sent.
Debugging cross-core synchronization issues is ... not fun.  With nearly zero overhead, this update
provides the ability to catch most synchronization errors between cores via the insertion of a counter for each message.

Merged into single PR https://github.com/DangerousPrototypes/BusPirate5-firmware/pull/70


HADOOP-16682. ABFS: Removing unnecessary toString() invocations

Removing unnecessary toString() invokations.
Driver test results using accounts in Central India
mvn -T 1C -Dparallel-tests=abfs -Dscale -DtestsThreadCount=8 clean verify
Account with HNS Support
[INFO] Tests run: 63, Failures: 0, Errors: 0, Skipped: 0
[WARNING] Tests run: 436, Failures: 0, Errors: 0, Skipped: 74
[WARNING] Tests run: 206, Failures: 0, Errors: 0, Skipped: 24
Account without HNS support
[INFO] Tests run: 63, Failures: 0, Errors: 0, Skipped: 0
[WARNING] Tests run: 436, Failures: 0, Errors: 0, Skipped: 248
[WARNING] Tests run: 206, Failures: 0, Errors: 0, Skipped: 24

: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.

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

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
19m  6s
trunk passed

+1 :green_heart:
compile
0m 36s
trunk passed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04

+1 :green_heart:
compile
0m 33s
trunk passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

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

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

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

-1 :x:
javadoc
0m 30s
hadoop-azure in trunk failed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.

+1 :green_heart:
javadoc
0m 28s
trunk passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

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

+1 :green_heart:
findbugs
0m 52s
trunk passed

-0 :warning:
patch
1m 10s
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

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

+1 :green_heart:
compile
0m 28s
the patch passed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04

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

+1 :green_heart:
compile
0m 25s
the patch passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

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

+1 :green_heart:
checkstyle
0m 16s
the patch passed

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

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

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

-1 :x:
javadoc
0m 24s
hadoop-azure in the patch failed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.

+1 :green_heart:
javadoc
0m 24s
the patch passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

+1 :green_heart:
findbugs
0m 55s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 28s
hadoop-azure in the patch passed.

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

60m 17s

Subsystem
Report/Notes

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

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

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

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

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 1f71c4ae714

Default Java
Private Build-1.8.0_252-8u252-b09-1~18.04-b09

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_252-8u252-b09-1~18.04-b09

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-2144/1/artifact/out/branch-javadoc-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-2144/1/artifact/out/patch-javadoc-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-2144/1/testReport/

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

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-2144/1/console

versions
git=2.17.1 maven=3.6.0 findbugs=3.1.0-RC1

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

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

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

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
19m 44s
trunk passed

+1 :green_heart:
compile
0m 41s
trunk passed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04

+1 :green_heart:
compile
0m 33s
trunk passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

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

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

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

-1 :x:
javadoc
0m 30s
hadoop-azure in trunk failed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.

+1 :green_heart:
javadoc
0m 28s
trunk passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

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

+1 :green_heart:
findbugs
0m 57s
trunk passed

-0 :warning:
patch
1m 15s
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

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

+1 :green_heart:
compile
0m 29s
the patch passed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04

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

+1 :green_heart:
compile
0m 26s
the patch passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

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

+1 :green_heart:
checkstyle
0m 16s
the patch passed

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

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

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

-1 :x:
javadoc
0m 25s
hadoop-azure in the patch failed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.

+1 :green_heart:
javadoc
0m 25s
the patch passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

+1 :green_heart:
findbugs
0m 56s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 30s
hadoop-azure in the patch passed.

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

61m 27s

Subsystem
Report/Notes

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

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

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

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

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 2ba44a73bf2

Default Java
Private Build-1.8.0_252-8u252-b09-1~18.04-b09

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_252-8u252-b09-1~18.04-b09

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-2144/2/artifact/out/branch-javadoc-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-2144/2/artifact/out/patch-javadoc-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-2144/2/testReport/

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

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-2144/2/console

versions
git=2.17.1 maven=3.6.0 findbugs=4.0.6

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

This message was automatically generated.


Image layer doesn't turn on when the image load is slow

Context:
Repro:

Visit https://cellxgene.dev.single-cell.czi.technology/e/spatial-4.cxg/?spatial=true
After the embedding is loaded, we expect the image layer to be automatically turned on, but it's not

Private Zenhub Video
DoD:

After the embedding is loaded, we expect the image layer to be automatically turned on
Add E2E test for this please

@seve I'm thinking maybe a 2 points for both fix and e2e test? Thanks!


feat: Add support for SSL enforcement modes

Providing support for SSL while deploying primary and read instances.

@rajc242 thx for the PR. Can u plz fix lint issues.

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun


[Bug] An error when trying to install forge during import

Preflight Checklist

[X] I have read the Contributing Guidelines for this project.
[X] I agree to follow the Code of Conduct that this project adheres to.
[X] I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version
29.2.0
What operating system are you using?
Windows
Operating System Version
Windows 11
What arch are you using?
x64
Last Known Working Electron version
No response
Expected Behavior
When trying to run this command
npx electron-forge import
from the get started page, I got this error:
An unhandled rejection has occurred inside Forge:
Error: Failed to install modules: ["electron-squirrel-startup"]

With output: Command failed with a non-zero return code (1):
npm install electron-squirrel-startup --save

npm ERR! Cannot read properties of null (reading 'matches')

Some error text are reducted due to privacy, if you need this for debugging, I'll post it as soon as possible.
Actual Behavior
Should just install the library that are necessary to compile the files.
Testcase Gist URL
No response
Additional Information
No response

@Fyphen1223 Are you able to npm install electron-squirrel-startup --save outside of the context of the import script?

I actually have tried to install electron-squirrel-startup but I couldn't because of an error.
If you need the error log, I'll put that later (sry, I'm currently away with my PC)