RFC for redirecting stdio of child processes to open file handles

Rendered

cc @alexcrichton

Isn't this what InheritFd did in old_io? Was that also implemented on Windows?

Overall I like the direction that this is going in, but I'm hesitant with how it interacts with other aspects of the system. For example this interface should largely boil down to "just passing a file descriptor" on unix and something like "just passing a HANDLE" on windows. Right now the restriction of using a File itself may be too limiting, and I'm not quite so sure about borrowed-vs-owned aspect of the argument just yet, I think I'll need to ponder this a bit more.
Regardless though thanks for the RFC!

@rschmitt Yeah InheritFd allowed redirection of arbitrary file descriptors, even on Windows, except the caller would have to manually convert the HANDLE as an fd via libc calls themselves. Not to mention the unsafety of the file descriptor getting closed at some point before the command was actually spawned (or worse a different file opened under that same descriptor). This RFC seeks to make things a bit easier and safer when redirecting stdio!
@alexcrichton I agree that using a File is too limiting, so I've updated my design to create a new handle for pipes.

For example this interface should largely boil down to "just passing a file descriptor" on unix and something like "just passing a HANDLE" on windows.

I think this would be a good approach for the future, but I wanted to avoid Unix/Windows discrepancies in the API around sockets (they aren't quite HANDLES on Windows and I'm not sure if they can be substituted for each other) so I thought about using a "white list" of accepted types for redirection. Although not as flexible as accepting the raw OS handle type it seems like a decent compromise for now.

I've updated and simplified the design to work with ChildStd{in, out, err} which are already using OS pipes to talk with the child process.
I've left out a public interface for safely creating OS pipes out of this version because it doesn't seem as necessary any more. It would be pretty trivial to expose a public wrapper over AnonPipe either now or in the future should this become a requested feature.

This looks great to me @ipetkov, thanks!
I'm a tad bit uncertain about whether unsafe is the right way to go here, but I think that it's the best course of action. Right now we're providing the guarantee that a File is the sole and unique owner of that file descriptor/handle, hence why from_raw_fd is now unsafe. If we were to make Stdio::redirect safe, then you could create the redirection, drop the source handle, open a new handle, and then spawn the child. This newly opened handle would then be used by the child process, violating the unique ownership semantics of File. As a result I think it's fine to call the API unsafe.
cc @nagisa, @retep998, @carllerche, @aturon

:+1: We definitely need this features to replace the lost std::old_io::pipe::PipeStream and StdioContainer::InheritFd.
The Redirect(RawFd) could be replaced with something like Redirect<T: AsRawFd>(&mut T) to be able to not need unsafe code: exclusive use of the file descriptor/handle during all it's lifetime.
StdioExt::redirect<T: AsRawFd>(t: &'a mut T) should return a Stdio with the 'a lifetime.
We should be able to connect the stdio/pipes before spawning any command.
Agree with @alexcrichton to no use File but something lighter. I previously proposed to expose something like FileDesc but common between UNIX and Windows (e.g. IoHandle, cf rust-lang/rust#15643) to keep a common function signature whatever OS is used. However, &mut As{RawFd,Handle} could do the job.

@l0kod the recommended unsafety here derives from the fact that there's no lifetime associated with the return value (see the section about backwards compatibility and my prior comment). It also already does take T: AsRawFd as Stdio::Redirect is not an expose enum variant (it's only exposed through an extension trait).

We should be able to connect the stdio/pipes before spawning any command.

@l0kod That's one argument for exposing a public Pipe interface which wraps over AnonPipe and would allow setting that all up before spawning, which would be pretty easy to add

the recommended unsafety here derives from the fact that there's no lifetime associated with the return value

Well, I suggest to add a lifetime to the return value: https://github.com/rust-lang/rust/pull/24251#issuecomment-96191536

@l0kod I think @alexcrichton is referring to Stdio as the return value, and not the raw handle type. Stdio is stored by Command, so if it was to get a lifetime parameter due to AsRaw{Fd, Handle}, so would Command. At this point this would be a breaking change of a stabilized API.

I didn't realize this was so impacting. I know Rust has a big part stabilized but I understood that some (rare) breaking changes could happen before the final 1.0.0
@alexcrichton Is it really too late to fix this objects' lifetimes?

The lifetime issue could be bypassed with a FileDesc/Io type instead using AsRawFd trait.

@l0kod yes it is too late at this point to retroactively add lifetime annotations to Command and its internals.

@ipetkov I discussed this with @aturon today, and I thought that he had a great idea which was to leverage the existing FromRawFd and FromRawHandle traits. For example an alternative to adding this API surface area could be:

Implement FromRaw{Fd,Handle} for Stdio (note that the inherits the unsafe by default)
Implement AsRaw{Handle,Fd} for Child{Stdin,Stdout,Stderr}

This approach should give the same amount of flexibility while holding off on new API additions today. What do you think?

Also note that if this is just adding trait implementations to the standard library's existing types then it likely doesn't need to go through the RFC process.

@alexcrichton This approach will definitely work, and it is the most lightweight solution. I do find two shortcomings with this solution, however:

Converting to Stdio via the AsRaw{Fd, Handle} traits will require use of cfg! or any user of the API to make their own platform agnostic wrapper all over the place
Searching the docs for how to perform a redirection will be more difficult since you'd have to realize you are looking for an OS io-handle conversion to Stdio rather than a redirect method of some sorts.

Personally I can live with either of these shortcomings for the time, but I feel like if not now, we'd need a (more ergonomic) public API at some time in the future (unless of course this proves to be an obscure feature not many people use).
I'll try to see if I can elicit feedback from a wider audience, and if not we can go with @aturon lighter approach.

@ipetkov yeah that's definitely a drawback of only using AsRaw{Fd, Handle} for now. I personally, however, think that we will always want these trait implementations, regardless of any high-level and/or cross-platform abstraction we may wish to add.
In terms of a higher-level API @aturon and I were considering something like:
impl Stdio {
    pub unsafe fn from_io<T: ToStdio>(t: &T) -> Stdio {
        t.to_stdio()
    }
}

pub trait ToStdio {
    unsafe fn to_stdio(&self) -> Stdio;
}

impl ToStdio for File {
    #[cfg(unix)]
    unsafe fn to_stdio(&self) { ... }

    #[cfg(windows)]
    unsafe fn to_stdio(&self) { ... }
}

The exact design of this API is a little iffy, however. For example the unsafe is somewhat unclear if it's necessary (or if it can be avoided), and the naming is a little odd as well (e.g. why not To<Stdio>?). I'd be fine discussing this as well, but to me it seems best to provide the tools necessary to build an abstraction like this, and then see if common patterns start emerging in crates.io. If we see a clear pattern emerge then we can conform to that when designing a cross-platform abstraction, but right now it's not super clear to me how to have a cross-platform abstraction in a super-nice way.

@alexcrichton I think a higher-level API like your example (or StdioExt from the RFC) are both quite acceptable for the time. The exact naming and cross-platform abstractions definitely have many different possibilities, but maybe there is a compromise we can find for now (especially with keeping things unstable so that they aren't locked in).

@ipetkov I wonder, perhaps this RFC could be re-worded with the assumption of the FromRawFd impl blocks exist, and then go from there? That way we could discuss a higher-level and/or cross-platform concept here, and you can also feel free to make a PR for the bare-bones soon as well.

@alexcrichton Sounds reasonable to me, I'll try to get an updated draft written over the next few days!

I like the ToStdio trait but what do you think about using an Into<Stdio> trait? This would take the (File) ownership and could get ride of the unsafe.

This would take the (File) ownership and could get ride of the unsafe.

What about redirecting multiple child processes to the same File? Then either Stdio would have to implement Clone, or anything else that holds a file descriptor/HANDLE.

What about redirecting multiple child processes to the same File? Then either Stdio would have to implement Clone, or anything else that holds a file descriptor/HANDLE.

A Stdio::tee(&self) -> Stdio could be in charge of handling the multiple file descriptor writing (in the same time). It seems appropriate to use tee(2) in the Stdio implementation for that.
This way, we can control and handle potentially unsafe operations in only one implementation.

I've updated the proposal to consider FromRaw* as an implementation and proposed several approaches for a higher level API. After thinking about the tradeoffs for each approach, I'm still a fan of using StdioExt (because I find it cleaner than using an intermediary trait), however, I am open to other ideas!
@l0kod Is tee(2) available across platforms (e.g. Windows)?

In the meantime, is there a workaround we can use on nightly and/or stable? Heatseeker has only been usable on Windows ever since old_io was removed (relevant code).

@ipetkov I cannot find tee(2) or equivalent on Windows.

@rschmitt there are two workarounds that come to mind:

Spawn a thread to buffer data from the given descriptor to the child's stdin, but probably won't scale very well
dup2 the given descriptor to the parent's stdin fd and have the child inherit that

@ipetkov Your second suggestion is exactly what I needed. Works great for what I need, sure beats doing the ioctls by hand. Thanks!

Is tee(2) available across platforms (e.g. Windows)?

Even if tee(2) is not available, the Stdio could implement a tee() -> Stdio and use something similar to tee(2) internally (e.g. DuplicateHandle or manual copy).

@ipetkov could you update this RFC with specific signatures for the functions you have in mind? I've found it useful to have the signatures in mind ahead of time as it makes it easier to discuss portions of the API in terms of generics and ownership.

@l0kod To my understanding of the tee syscall on Linux it doesn't quite behave like simply duplicating a descriptor, so it may prove difficult to emulate that functionality on other systems (lest we introduce confusion by using the same name).
Internal duplication of the OS handle is definitely a possibility, however, I personally lean towards allowing the caller to choose if they want duplication (and expecting them to use dup themselves) rather than forcing it on them.
@alexcrichton Updated the RFC!

Updated the RFC to recognize the FromRaw* implementations on Stdio and to reflect @alexcrichton 's suggestions of the previously offered design alternatives

Based on @alexcrichton's feedback I've written up RFC #1174 to discuss adding new traits such as IntoRaw{Fd, Socket, Handle}.
This RFC still retains its cross-platform benefits over using IntoRaw*, however, if there is no strong desire for a cross-platform redirection API at the time, we can close this RFC in favor of #1174.

This RFC is now entering its week long final comment period.

#[cfg(unix)] use std::os::unix::process::StdioExt;
#[cfg(windows)] use std::os::windows::process::StdioExt;

If some form of StdioExt::redirect is available on all supported platforms, the above is just noise IMO. I’d much prefer redirect being in inherent method of Stdio, as proposed in Alternatives.
I’d go even further: rather than have redirect itself have a platform-specific signature, it could use a new trait (AsStdioRedirect?) that internally uses eiher AsRawFd or AsRawHandle.

@SimonSapin a given type may not implement both AsRawFd on Unix and AsRawHandle on Windows (e.g. TcpStream which implements AsRawSocket instead of AsRawHandle). Having to import the StdioExt traits makes people opt into potential platform specific breakage.
Taking an AsRaw* by value and then storing it away seems a bit weird - particularly since it's not unreasonable to have non-owning types that implement AsRaw*. I'd be in favor of accepting #1174 and using that instead.

The consensus of the libs team on this RFC is to close this in favor of the IntoRawFd RFC, so I'm going to close this in favor of that. Thanks regardless though for the RFC @ipetkov!

Thanks for all the feedback on this RFC anyway @alexcrichton!


Mydata: add url routes for tabs and localize slugs to FI, SV, ENG

This includes index (/mydata). Landing page has these translations for /mydata at the moment:

Omat tietosi
Dina uppgifte
My data

Note to future: this might be complicated with Wagtail, url translations have to be checked against Wagtail (landing page) translations.

The url needs to contain the selected language.
https://omahelsinki.test.hel.ninja/en/mydata
https://omahelsinki.test.hel.ninja/fi/tietoni

I would use

Omat tietoni
Mina uppgifter
My data

Instead of Sinun.., Dina..., Your...

Currently we are going with these:
Omat tiedot / /fi/omat-tiedot
Mina uppgifter / /sv/mina-uppgifter
My data / /en/my-data

Wagtail parts of this are implemented in translated-urls branch.


powershell console support

Describe the solution you'd like
i would like to have nightowl schema for powershell color scheme.
i could set nightowl for windows terminal but it do nothing to powershell color scheme.
i mean ex: variable color, command color and ...
get-psreadlineoption

@khoshroomahdi hey 👋🏻 this is a repository for the VS Code theme. Have you tried this one? - https://github.com/edurojasr/Windows-Terminal-Theme-Night-Owl

Yes. I tried.

Hey there! As @ivansvlv mentioned, this project is scoped for VS Code not Windows Terminal. The palette is in the theme's JSON if you want to create one and you don't like that existing one, though. Thanks!


Typing/pasting & into elvish returns parse error - unexpected rune

I tried adding Sublime Text 3 Pacman repository and I encountered the following issue:
First, after pasting into the terminal:
~> curl -O https://download.sublimetext.com/sublimehq-pub.gpg && sudo pacman-key --add sublimehq-pub.gpg && sudo pacman-key --lsign-key 8A8F901A && rm sublimehq-pub.gpg
parse error: 60-61 in [interactive]: unexpected rune

After pressing enter:
~> curl -O https://download.sublimetext.com/sublimehq-pub.gpg && sudo pacman-key --add sublimehq-pub.gpg && sudo pacman-key --lsign-key 8A8F901A && rm sublimehq-pub.gpg
Parse error: unexpected rune
  [interactive], line 1:
    curl -O https://download.sublimetext.com/sublimehq-pub.gpg && sudo pacman-key --add sublimehq-pub.gpg && sudo pacman-key --lsign-key 8A8F901A && rm sublimehq-pub.gpg
~>

Also, if I try to type & character into terminal, I get this:
~> &
parse error: 0-1 in [interactive]: unexpected rune

Pacman elvish info:
~> pacman -Qi elvish
Name            : elvish
Version         : 0.9-2
Description     : A friendly and expressive Unix shell.
 Use a semicolon instead.

@muesli Thanks, didn't know that! But I still find it strange that it shows the error after pressing & (I understand why it should fail after pressing the enter key). Perhaps it could use a more helpful error message for people coming to elvish?

It shows me that parse error while I type that out. Is it not doing that for you?

@amarsahinovic Elvish does on-the-fly parsing, which is why it flags errors as you type. As you continue typing and correct the syntax, the error will disappear.
Elvish is very powerful, but it's different enough from other shells that it's worth your time to read through some of the documentation when you start. I would recommend the "Some Unique Semantics" page, which assumes you know other shells already. From there you can move to some of the other tutorials and reference documentation.

@muesli Yeah, I thought it was weird, but after @zzamboni explanation that elvish parses as I type, it makes sense (although I still think better error message could be shown, "unexpected rune" means nothing to me in this context as I have never heard of it before, and I can't find anything about it on the page @zzamboni linked for example)
@zzamboni Thanks for the info.
I think I'll close the issue, thanks everyone!


markdown: Remove border colour on inline code links

The visual noise from the blue border has bothered me forever and I
finally decided to do something about it. I don't know if this is the
best solution, but I do think it's a lot better than the status quo!
Testing plan:
Tested this out via browser devtools.
GIFs or screenshots:

Current
Changed

Merged, thanks @kamalmarhubi!  I think that CSS was actually a relic from when we had a black border around code blocks not with a link, and we neglected to change the link behavior when we removed the black border.
(I hope you're doing well!)

Yay! Doing ok over here. :-)
I hope you're keeping well too.


Make a generic configuration UI

Create a function that generates UI from a definition of configuration elements.
CONFIG_DEF = List[CONFIG_BLOCKS]
CONFIG_BLOCK = Tuple[Block_header, List[CONFIG_LINE]]
CONFIG_LINE = Tuple[Element_name, Widget, Secret_store_key]

Review planned by @Shmuma


max payload length

Hello @ all,
thanks for this great library. After fixing own foolish default errors, I got your library running.
My problem: I want to stream 128 Byte in 1 Mqtt-Frame.
Your library sets this to the maximum. If my publisher sends more than 100 Bytes the callback-routine won't be called and executed.
My questions:

why is it alltogether limited? ( i know my space is not endless, but isn't this my problem?)
why do I have troubles at 100 bytes payload and not the defined 128 bytes?

Thanks in advance.
Fabian
p.s.:
my source code is here
A directory above is the same script written in lua, working with mqtt and a payload = 128 bytes

It is limited because the library reserves an internal buffer in memory that can contain the packet.
If your device has sufficient memory, you can modify the max size (as described in the docs) in PubSubClient.h.
The value is the max MQTT packet length - not the max payload size. The MQTT Publish packet includes both the payload and topic, along with some additional header bytes. So you need to take into account the length of the topic.

thanks for your quick reply and sorry for not reading enough (your documentary)


read/write support for date und datetime fields

This PR adds read and write support for Date and Datetime fields in the OGR API. An example is provided.
This also brings in the chrono crate as an additional dependency.

That looks great! Thank you for this contribution.
Could you make the feature and therefore the chrono dependency optional? Like for ndarray.

Sure, I added one more commit containing the feature gate.


⚠ Spryr has degraded performance

In dc0ef10, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 200
Response time: 4010 ms

Resolved: Spryr performance has improved in 53002ac after 53 minutes.


'Test Explorer > Group By > Class' groups by test name

Expected Behavior
Right click on 'Test Explorer' and select 'Group By > Class'.
I'd expect the tests to be grouped by the file they appear in (which is the rough equivalent to a 'Class').
Alternatively I'd expect the option to group by 'Test File' or maybe 'Script File'.
Actual Behavior
Tests are grouped by test name (i.e. one test per group).
This is probably the last thing you would want to group by.
Node.js Tools   1.2.40329.01
Visual Studio 2015 Update 2
Node.js v6.1.0
Steps to Reproduce
Right click on 'Test Explorer' and select 'Group By > Class'.
Tests are grouped by test name.

Thanks for the report. I can confirm this is the current behavior, but sorting by filename as you propose sounds more logical.
Feel free to look in fixing this. I think this file may be a good starting point: https://github.com/Microsoft/nodejstools/blob/master/Nodejs/Product/TestAdapter/TestDiscoverer.cs

I had a quick look, but it isn't obvious where the Visual Studio test runner gets the 'Class' name for a test. Is it implicitly part of the FullyQualifiedName?
I'm giving up for now.


Unable to load model: 'minecraft:block' referenced from: betterend:flavolite_flower

I was looking at the minecraft startup log to check for problems, found this error on the console:
[Worker-Main-11/WARN]: Unable to load model: 'minecraft:block' referenced from: betterend:flavolite_flower_pot#plant_id=0,pot_light=0,soil_id=0: java.io.FileNotFoundException: minecraft:models/block.json

I found no other problems.
Mod list:

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>

Looks like one of patterns have wrong path, will be fixed


Tweak error message, actually test it

Before: Could not find module: `isolated-container` imported from: foo'
After: 'Could not find module `isolated-container` imported from `foo`'
Also, you need to use a regular expression for QUnit.throws otherwise it assumes it is the test's display message. See http://api.qunitjs.com/throws/.

:+1:


testing testing 123

this is an issue yayayayayyayaya

please don’t use public repos to learn github, @Eugeny please close this


Webpart and Extension in one solution / package - SPFx 1.4.1 - SharePoint 2019 / Subscription Editon

Target SharePoint environment
SharePoint Server 2019 (on-premise)
What SharePoint development model, framework, SDK or API is this about?
💥 SharePoint Framework
Developer environment
Windows
What browser(s) / client(s) have you tested

[X] 💥 Internet Explorer
[X] 💥 Microsoft Edge
[X] 💥 Google Chrome
[ ] 💥 FireFox
[ ] 💥 Safari
[ ] mobile (iOS/iPadOS)
[ ] mobile (Android)
[ ] not applicable
[ ] other (enter in the "Additional environment details" area below)

Additional environment details

browser version: Edge (100.0.1185.29), Chrome (99.0.4844.84), IE 11
SPFx version: 1.4.1
Node.js version: 10.24.1

Describe the bug / error
In SPFx 1.4.1 it is not possible to have a webpart and an extension (field customizer) in one solution and package.
After package and deployment only the extension is working.
It must be somehow connected to the package-solution.json.
If I remove all features (so the extension) only the webpart is working.
I also tried it with the componentId, which is also not working http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2019/01/08/how-to-properly-add-an-application-customizer-to-an-existing-spfx-web-part-project.aspx?CommentPosted=true#commentmessage
And I tried to create an own feature for the webpart. The feature is also showing up in the browser, but the webpart is still missing.
Is this a SPFx 1.4.1 bug? Is there no way to have an extension and a webpart in SPFx 1.4.1? Does it need to be two separate solutions?
Steps to reproduce

yo @microsoft/sharepoint (add webpart SharePoint 2019, no javascript framework)
yo @microsoft/sharepoint (add extension - field customizer, no javascript framework)
package and deploy the solution

Expected behavior
Both components  of the solution get published and are available.

@Pronizius - thanks for reporting this one.
It is an issue and has been addressed for the latest versions of SPFx.
Unfortunately, for v1.4.1 you would need to update things manually.
You will need to modify package-solution.json.
You can also try to scaffold items in the opposite direction.
https://github.com/SharePoint/sp-dev-docs/issues/7725#issuecomment-1042998319

Hello @AJIXuMuK
Thanks for your response, opposite direction, does not work either, it generates the same package-solution.json.
What is the correct package-solution.json? Can you give me an example with a webpart and an extension in one solution?
Like described above I tried with componentIds here but it still does not work either.
Looks like the only solution for 1.4.1 is to separate webparts and extensions. Can you confirm this?

@Pronizius - yes, seems like you are correct.
Especially if you're using the solution for on-prem
I believe the approach you mentioned in your comment should still work for SharePoint Online.
But if you're developing for SP Online, I'd update to the latest version of SPFx.

@AJIXuMuK Thanks again for your time and information.


disable various override paths based on the associated env vars == false

Fixes https://github.com/openshift/jenkins/issues/693
@openshift/sig-developer-experience ptal

Thanks.  The documentation in the README needs to change as well.


Nicky Boom and Nicky II should be PAL, not PAL60

Nicky Boom and Nicky II are French games, and should run in 50 Hz. They run way too fast with 60 Hz. The music is too fast, and therefore the calm atmosphere is lost. Faster is not better with such explorative games.
There's already a workaround, because the user can manually force PAL in the menu. But it is easy to forget this step.

Fixed in https://github.com/amigavision/AmigaVision/commit/ecc9499321734cc51c6c9ad64e0c22f18549b4f0


ci: remove submodule builds

Submodules are difficult to support, and probably not a best practice,
as the target names must remain different from all the targets that the
user might define (CMake has a global namespace for targets).
Fixes #3229

This change is

Rebased to resolve conflicts. PTAL.


Add a property whether case-sensitive matching is performed when logi…

…n names are compared
Modifications:

Add loginNameCaseSensitive property to dogma.json.

Codecov Report

Merging #167 into master will increase coverage by 0.02%.
The diff coverage is 47.82%.

@@            Coverage Diff            @@
##           master    #167      +/-   ##
=========================================
+ Coverage   63.47%   63.5%   +0.02%
=========================================
  Files         273     273
  Lines        9449    9458       +9
  Branches     1064    1065       +1
=========================================
+ Hits         5998    6006       +8
  Misses       2829    2829
- Partials      622     623       +1

Impacted Files
Coverage Δ

...necorp/centraldogma/server/CentralDogmaConfig.java
64.7% <100%> (+0.7%)
:arrow_up:

...er/internal/admin/authentication/LoginService.java
77.77% <100%> (+0.5%)
:arrow_up:

...ldogma/server/internal/api/MetadataApiService.java
7.5% <18.18%> (+1.08%)
:arrow_up:

...ecorp/centraldogma/server/CentralDogmaBuilder.java
55.42% <33.33%> (-1.37%)
:arrow_down:

...com/linecorp/centraldogma/server/CentralDogma.java
72.6% <66.66%> (-0.16%)
:arrow_down:

...erver/internal/mirror/DefaultMirroringService.java
65.82% <0%> (+3.79%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9ee6c0b...7189151. Read the comment docs.

Thanks, @hyangtack


Bug fixes for SampleSet Releng

[x] I incremented the version in the VERSION file
[x] I updated CHANGELOG.md
[ ] I added test coverage for any changes

Can you try setting your WORKSPACE_TOKEN env var under https://github.com/slebras/index_runner and rerunning the tests?

Can you try setting your WORKSPACE_TOKEN env var under https://github.com/slebras/index_runner and rerunning the tests?


Added textarea component

Fixes issue #178

@Rajdip019 is this ok?

Just change the file name to textarea-v2.html


"Too many element types registered", probably registering them multiple times?

After a few hours of messing with GLSL files with this plugin installed, the following error will occur:
java.lang.Throwable: Too many element types registered. Out of (short) range. Most of element types (12794) were registered for 'Language: Glsl': FILE, FILE, FILE, ADD_EXPR, AND_EXPR, ARRAY_SPECIFIER, ASSIGNMENT_EXPR, ASSIGNMENT_OPERATOR, ATTRIBUTE, BLOCK_STRUCTURE, BLOCK_STRUCTURE_WRAPPER, CASE_LABEL, COMPOUND_STATEMENT, COMPOUND_STATEMENT_NO_NEW_SCOPE, CONDITION, CONDITIONAL_EXPR, CONSTANT_EXPR, DECLARATION, DECLARATION_IDENTIFIER_WRAPPER, ...
	at com.intellij.openapi.diagnostic.Logger.error(Logger.java:184)
	at com.intellij.psi.tree.IElementType.<init>(IElementType.java:121)
	at com.intellij.psi.tree.IElementType.<init>(IElementType.java:99)
	at com.intellij.psi.tree.ILazyParseableElementType.<init>(ILazyParseableElementType.java:29)
	at com.intellij.psi.tree.IFileElementType.<init>(IFileElementType.java:30)
	at glsl.plugin.language.GlslParserDefinition.getFileNodeType(GlslLanguage.kt:69)
	at com.intellij.extapi.psi.PsiFileBase.<init>(PsiFileBase.java:29)
	at glsl.plugin.language.GlslFile.<init>(GlslFile.kt:14)
	at glsl.plugin.language.GlslParserDefinition.createFile(GlslLanguage.kt:104)
	at com.intellij.psi.AbstractFileViewProvider.createFile(AbstractFileViewProvider.java:144)
	at com.intellij.psi.AbstractFileViewProvider.createFile(AbstractFileViewProvider.java:128)
	at com.intellij.psi.AbstractFileViewProvider.createFile(AbstractFileViewProvider.java:117)
	at com.intellij.psi.SingleRootFileViewProvider.createFile(SingleRootFileViewProvider.java:144)
	at com.intellij.psi.SingleRootFileViewProvider.getPsiInner(SingleRootFileViewProvider.java:100)
	at com.intellij.psi.AbstractFileViewProvider.getPsi(AbstractFileViewProvider.java:194)
	at com.intellij.psi.impl.BlockSupportImpl.getFileCopy(BlockSupportImpl.java:307)
	at com.intellij.psi.impl.BlockSupportImpl.makeFullParse(BlockSupportImpl.java:289)
	at com.intellij.psi.impl.BlockSupportImpl.reparse(BlockSupportImpl.java:92)
	at com.intellij.psi.impl.DocumentCommitThread.doCommit(DocumentCommitThread.java:261)
	at com.intellij.psi.impl.DocumentCommitThread.commitUnderProgress(DocumentCommitThread.java:128)
	at com.intellij.psi.impl.DocumentCommitThread.lambda$commitAsynchronously$0(DocumentCommitThread.java:78)
	at com.intellij.openapi.application.impl.NonBlockingReadActionImpl$Submission.insideReadAction(NonBlockingReadActionImpl.java:536)
	at com.intellij.openapi.application.impl.NonBlockingReadActionImpl$Submission.lambda$attemptComputation$3(NonBlockingReadActionImpl.java:501)
	at com.intellij.openapi.application.impl.ApplicationImpl.tryRunReadAction(ApplicationImpl.java:1154)
	at com.intellij.openapi.progress.util.ProgressIndicatorUtils.lambda$runInReadActionWithWriteActionPriority$0(ProgressIndicatorUtils.java:75)
	at com.intellij.openapi.progress.util.ProgressIndicatorUtils.runActionAndCancelBeforeWrite(ProgressIndicatorUtils.java:158)
	at com.intellij.openapi.progress.util.ProgressIndicatorUtils.lambda$runWithWriteActionPriority$1(ProgressIndicatorUtils.java:115)
	at com.intellij.openapi.progress.ProgressManager.lambda$runProcess$0(ProgressManager.java:66)
	at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:188)
	at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$12(CoreProgressManager.java:608)
	at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:683)
	at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:639)
	at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:607)
	at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:60)
	at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:175)
	at com.intellij.openapi.progress.ProgressManager.runProcess(ProgressManager.java:66)
	at com.intellij.openapi.progress.util.ProgressIndicatorUtils.runWithWriteActionPriority(ProgressIndicatorUtils.java:112)
	at com.intellij.openapi.progress.util.ProgressIndicatorUtils.runInReadActionWithWriteActionPriority(ProgressIndicatorUtils.java:75)
	at com.intellij.openapi.application.impl.NonBlockingReadActionImpl$Submission.attemptComputation(NonBlockingReadActionImpl.java:501)
	at com.intellij.openapi.application.impl.NonBlockingReadActionImpl$Submission.lambda$transferToBgThread$1(NonBlockingReadActionImpl.java:408)
	at com.intellij.util.concurrency.BoundedTaskExecutor.doRun(BoundedTaskExecutor.java:241)
	at com.intellij.util.concurrency.BoundedTaskExecutor.access$200(BoundedTaskExecutor.java:31)
	at com.intellij.util.concurrency.BoundedTaskExecutor$1.execute(BoundedTaskExecutor.java:214)
	at com.intellij.util.ConcurrencyUtil.runUnderThreadName(ConcurrencyUtil.java:212)
	at com.intellij.util.concurrency.BoundedTaskExecutor$1.run(BoundedTaskExecutor.java:203)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:668)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:665)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:665)
	at java.base/java.lang.Thread.run(Thread.java:829)

How can I reproduce the bug?

There doesn't seem to be any trigger in particular. Just using the IDE for a while, editing GLSL scripts with the plugin installed, seems to be enough. I don't really keep track of time very well but it's probably after a couple of hours of active use.

I don't understand why this is closed.  Even if you are unwilling to edit a file for long enough to reproduce the error, the stack trace seems to be pretty clear in indicating that when you create new instances of IFileElementType in getFileNodeType they are being stored permanently, until eventually too many get registered.
I don't have any experience with Intellij plugin development, but I see here that there's a constructor that takes a parameter register to disable registering of the element type.  That might be an option to fix this bug if there really is a valid reason for creating new instances all the time.  Alternatively, I see in this example FILE element type is defined as a static variable returned by getFileNodeType instead of being constructed each time.  That seems like the better option if you can do it.
As for why the file node types seem to be created for every edit in the first place, my guess is that it is due to this, which seems rather odd.  Is there really no better way to change the name of an identifier?


Add serialization

I would like to add support for writing graphs to files. At first, I would focus on the following formats:

[x] dot (handled by @bobluppes)
[ ] graphml
[ ] json (handled by @misarb)

Each of these could be implemented as a free function. Implementations should go under src/graaflib/io.

Hey bob I'd like to help out

Hi @JayPankajPatel, thanks, that would be great!
Currently you can choose between adding serialization to graphml and to json, so feel free to pick whichever sounds more interesting to you.

hey bob on second thought could you unassign this issue to me, I'm pretty busy with a personal project of mine.

hey bob on second thought could you unassign this issue to me, I'm pretty busy with a personal project of mine.

Of course, no problem

hey @bobluppes can you assigne to me the Json format i would like to start working on it

hey @bobluppes can you assigne to me the Json format i would like to start working on it

Hi @misarb, of course! I have assigned you to it

Hi @misarb, are you still working on this? I would close this issue for now as I want to focus on more algorithmic tickets. However, if you are up for it a PR is still welcome :)
Let me know and we can reopen the issue.

Hey @bobluppes, I apologize for the late response. I've been really busy these past few days. I started implementing the serialization but encountered some problems during the build, as I mentioned on Discord. I'll try to complete it and send a PR.

Hi @misarb no worries. If you have time for it it will always be welcome, but no stress


How to get rock solid readings and avoid the 85°C and the -127°C problems

Hello everybody!
I am sorry if this is not be the correct place to share my experience. I think this could help others.
I was searching for a way to get around the problems with the DS18B20 giving wrong readings on dodgy wire connections and stumbled about this page with some info on how to distinguish between good an bad readings. After all I was not very satisfied with the information I found about these problems. After some testing I got my own solution, which seems to work quite good for my needs.
My final solution was to evaluate the conversion time for the temperature conversion of the sensor. The reading is only processed if the conversion time is higher than a given minimum.  This seems to be a good way to determinate if the reading was correctly processed by the sensor. Here is my example code. I hope this helps. The limit has to be changed according to the sensor's resolution.
#include <OneWire.h>
#include <DallasTemperature.h>

#define ONE_WIRE_BUS D3

OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
DeviceAddress address;

void setup(void)
{
  Serial.begin(115200);
  sensors.begin();

  if (!sensors.getAddress(address, 0)) Serial.println("Unable to find address for Device 0");
  sensors.setResolution(address, 12);//set to 12 bit
  sensors.setWaitForConversion(true);

  Serial.print("Device 0 Resolution: ");
  Serial.print(sensors.getResolution(address), DEC);
  Serial.println();
}

void loop(void) {
  unsigned long start;
  unsigned long duration;
  float temp;

  start = millis();
  sensors.requestTemperatures();
  duration = millis() - start;
  if (duration >= 550) //Conversion should at least take this long. Experimental Values are 9-bit: 70; 10-bit: 140; 11-bit: 300; 12-bit: 550
  {
    temp = sensors.getTempCByIndex(0);
    if(temp == DEVICE_DISCONNECTED_C) {
      Serial.println("Error: Could not read temperature data");
    }
    else //We have a valid conversion
    {
      Serial.print(duration);
      Serial.print(": ");
      Serial.println(temp);
    }
  }
}

Thanks. Just meant to share a couple of observations in this regard.
To get this out of the way: I'm actually not familiar with the DallasTemperature.h but meant to point out that the value of "-127 °C" looks like a quirk of the library rather than a reading produced by the chip itself. Not that it matters to the point you're making.
As for undocumented behavior, in my experience, genuine DS18B20 with bad power supply may produce valid readings, incorrect readings, 0x0550 (+85 °C) "start-up" readings, or undocumented 0x07ff (+127.9375 °C) or 0xffff (-0.0625 °C) readings. The details are complicated by the fact that they depend on (a) the number of sensors on the bus and (b) whether the data line is being polled during temperature conversion (i.e., whether conversion time is measured) (--> temperature measurements with slightly poor power may still be doable if the sensor is not polled for completion but rather read after a default time of, say, 630 ms). But basically, if power is bad, a 0x07ff is likely and if power is really bad the reading will probably be a 0x0550.
I can support and add to your observation regarding the timing: we measure the conversion time of the sensors in our probes routinely to determine whether the chip gets insufficient power (typically the result of a poor connection at the Vcc pin).  With a slightly bad power supply the reported conversion time increases, even going past 1000 ms (12 bit conversion), but if it gets really bad the reported conversion time is actually 0 ms. I.e., in addition to your test against a lower limit we're also testing against an upper limit. I would call everything outside the 570-630 ms bracket suspect at "normal" temperatures.
Anyways, our use case is different from yours: we want to identify problems before deploying a string of sensors while you want to quality control readings from an already deployed string of sensors.
All of the above applies to genuine sensors with time measured by polling the data line and default 12 bit conversion.

Thank you for your answer!
You are totally right about the value of "-127°C". You would get this reading from the DallasTemperature library if the device's scratch pad could not be read successfully. The problem with dodgy wiring often is, that the scratchpad can be read nicely but it did not contain a new or an incorrect value due to the delivered power being not good enough to process the temperature conversion. Therefore simply checking against this value does not really work in most cases.
I have never experienced bad reading with conversion times to be higher than the maximum of 750 ms, but that might also be caused by the used library which simply reads out after "MAX_CONVERSION_TIMEOUT" of 750 ms . A check against higher times seems to be easy to integrate and would probably deliver even less bad readings. Thank you for pointing that out!

for future reference, in case anybody would like to reproduce increased timing, this is what I did (I do not mean to imply that this is representing a failure mode commonly observed, and in particular not the failure mode you are referring to):
5 V   ---o----[ R_test ]--------- DS18B20 Vcc
         |
         -----[ 1.2 kOhm ]---o--- DS18B20 data
                             |
data  ------------------------

GND   --------------------------- DS18B20 GND

With a single sensor on the data bus (results differ when multiple sensors are connected at the same time):

With R_test <= 4.7 kOhm, apparently no problems.
At R_test = 8.2 kOhm polling indicates around 800 ms conversion time and temperature reading is bogus. However, the temperature reading is correct if the temperature is read without polling after like 620+ ms.
Increasing R_test from 12 kOhm toward 33 kOhm increases conversion time further but the result is 0x07ff or 0x0550.
Beyond 33 kOhm the conversion time is 0 ms and the result is 0x0550.


Error while trying to enumerate devices

When I try enumerate all devices it throws an error:

Error Object reference not set to an instance of an object

Also when enumerating subscriptions it gives and Error 403 Error calling ListSubscriptions

Everything else is working, but devices are the key ones

Error is coming from line 32 of devices.cs

if (STClient.GetAllDevices().Items?.Count > 0)

It looks like Items is null, the underlying SmartThingsNet library isn't able to enumerate

Updated SDK, this should now be resolved

Yes that fixes one issue, but noticed another one causing a crash. Not all devices have rooms which is causing a crash in devices.cs line 153

roomName = STClient.GetAllRooms(device.LocationId).Items.Where(r => r.RoomId.ToString().Equals(device.RoomId))?.FirstOrDefault().Name;

Fix here:
https://github.com/daltskin/SmartThingsTerminal/pull/33

It works fine with your SDK update and the patch above. Will you be releasing a new version?

Your fixes are merged!


fix: add src folder to npm in order to make codegen work

@mkuczera could you please restore src folder to npm package and release new version with it? This folder is needed in order for codegen to work correctly since it looks for this folder while parsing specs. Also, what is the reason for not including it anyways?

Sorry, the intention was to exclude development files and just publish with the build result.

I think it is expected to add the source code to the package when releasing it so people can check and maybe change it if they need to. Could you make a quick patch release with this change so it is possible to use new arch in the library?

Sure. The Version 2.0.3 is just released @WoLewicki


Please use standard GH based tests

This adapter does not (yet) use standard GitHub based tests. Please replace test-and-release workflow by standard workflow (see https://github.com/ioBroker/ioBroker.example)
Of course its ok to implement additional tests. Please consider placing them into a seperated workflow to ease checks during stable review.
Standard GitHub tests must be executed and succeed for all supported node versions on all supported platforms.
Currently the named tests only empty shells incorrectly indicating that a test is executed. But

package test ist missing
lint is missing (not required but recommended)
integration test is missing

So please replace test-and-release workflow by standard workflow. I can provide a PR, please ask if  desider.

Ok, it seems that there are some legacy tests from mqtt adapter copied in test dir which are not executed ... so yes adding standard testing should be easy

Tst will be added by PR https://github.com/ioBroker/ioBroker.opcua/pull/42

@Apollon77
see pending PR


Run diff_tool in CI before offering prod deployment

We should provide the diff tool view on stage/prod APIs before offering the option to deploy in pipeline.deploy.yml.
This is in order to eliminate this check as a manual step and enforce it for good practise.

@kenoir I guess this can be closed now?


HADOOP-19143. Upgrade commons-cli to 1.9.0

Description of PR
JIRA: HADOOP-19143. Upgrade commons-cli to 1.9.0.
We will upgrade commons-cli to 1.9.0
How was this patch tested?
Local Compilation.
For code changes:
Upgrade commons-cli to 1.9.0.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 30s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
xmllint
0m  1s

xmllint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  1s

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
43m 22s

trunk passed

+1 :green_heart:
compile
0m 21s

trunk passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
compile
0m 21s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
mvnsite
0m 25s

trunk passed

+1 :green_heart:
javadoc
0m 25s

trunk passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
0m 21s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
shadedclient
78m  5s

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

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 14s

the patch passed

+1 :green_heart:
compile
0m 13s

the patch passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javac
0m 13s

the patch passed

+1 :green_heart:
compile
0m 12s

the patch passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
javac
0m 12s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
0m 15s

the patch passed

+1 :green_heart:
javadoc
0m 14s

the patch passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
0m 14s

the patch passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
shadedclient
33m 59s

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

_ Other Tests _

+1 :green_heart:
unit
0m 17s

hadoop-project in the patch passed.

+1 :green_heart:
asflicense
0m 36s

The patch does not generate ASF License warnings.

115m 49s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient codespell detsecrets xmllint

uname
Linux bc25ae391d94 5.15.0-117-generic #127-Ubuntu SMP Fri Jul 5 20:13:28 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 3dfffb7aa6225193dfbcfdf358c5ec799a5ab13d

Default Java
Private Build-1.8.0_422-8u422-b05-1~20.04-b05

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_422-8u422-b05-1~20.04-b05

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

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

modules
C: hadoop-project U: hadoop-project

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

versions
git=2.25.1 maven=3.6.3

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 31s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
xmllint
0m  1s

xmllint was not available.

+0 :ok:
shelldocs
0m  1s

Shelldocs was not available.

+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 _

+0 :ok:
mvndep
14m 50s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
30m 48s

trunk passed

-1 :x:
compile
0m 25s
/branch-compile-root-jdkUbuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04.txt
root in trunk failed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04.

+1 :green_heart:
compile
15m 52s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
mvnsite
22m 11s

trunk passed

+1 :green_heart:
javadoc
9m 38s

trunk passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
7m 40s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
shadedclient
50m 38s

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

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 34s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
29m 54s

the patch passed

-1 :x:
compile
0m 25s
/patch-compile-root-jdkUbuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04.txt
root in the patch failed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04.

-1 :x:
javac
0m 25s
/patch-compile-root-jdkUbuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04.txt
root in the patch failed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04.

+1 :green_heart:
compile
16m 33s

the patch passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
javac
16m 33s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
18m 56s

the patch passed

+1 :green_heart:
shellcheck
0m  0s

No new issues.

+1 :green_heart:
javadoc
9m 30s

the patch passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
7m 46s

the patch passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
shadedclient
51m 24s

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

_ Other Tests _

+1 :green_heart:
unit
750m 54s

root in the patch passed.

+1 :green_heart:
asflicense
1m 30s

The patch does not generate ASF License warnings.

1008m 27s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient codespell detsecrets xmllint shellcheck shelldocs

uname
Linux 8b405bd379d3 5.15.0-117-generic #127-Ubuntu SMP Fri Jul 5 20:13:28 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 7af79a4e60d01fa4ec3e6a3de07b02f69722daa8

Default Java
Private Build-1.8.0_422-8u422-b05-1~20.04-b05

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_422-8u422-b05-1~20.04-b05

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

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

modules
C: hadoop-project . U: .

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

versions
git=2.25.1 maven=3.6.3 shellcheck=0.7.0

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

This message was automatically generated.

Why not 1.9.0? https://mvnrepository.com/artifact/commons-cli/commons-cli/1.9.0

Thanks for your reply.
Version 1.6.0 was the latest release at the time this Jira was created.
Perhaps we can upgrade to 1.9.0 after it becomes more stable.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 31s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
xmllint
0m  1s

xmllint was not available.

+0 :ok:
shelldocs
0m  1s

Shelldocs was not available.

+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 _

+0 :ok:
mvndep
14m 50s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
31m 49s

trunk passed

+1 :green_heart:
compile
17m 15s

trunk passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
compile
16m 15s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
mvnsite
24m 43s

trunk passed

+1 :green_heart:
javadoc
9m 49s

trunk passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
8m  5s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
shadedclient
51m 59s

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

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 34s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
30m 37s

the patch passed

+1 :green_heart:
compile
16m 48s

the patch passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javac
16m 48s

the patch passed

+1 :green_heart:
compile
16m  7s

the patch passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
javac
16m  7s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
18m 51s

the patch passed

+1 :green_heart:
shellcheck
0m  0s

No new issues.

+1 :green_heart:
javadoc
9m 42s

the patch passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
8m  6s

the patch passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
shadedclient
53m 22s

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

_ Other Tests _

-1 :x:
unit
764m 47s
/patch-unit-root.txt
root in the patch passed.

+1 :green_heart:
asflicense
1m 35s

The patch does not generate ASF License warnings.

1063m 15s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.federation.router.TestRouterRPCMultipleDestinationMountTableResolver

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7126/4/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient codespell detsecrets xmllint shellcheck shelldocs

uname
Linux 2d588eb7bb55 5.15.0-124-generic #134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / dd9b80b068d8780c9076357766a9e32af4b3b051

Default Java
Private Build-1.8.0_422-8u422-b05-1~20.04-b05

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_422-8u422-b05-1~20.04-b05

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7126/4/testReport/

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

modules
C: hadoop-project . U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7126/4/console

versions
git=2.25.1 maven=3.6.3 shellcheck=0.7.0

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
7m 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.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
xmllint
0m  0s

xmllint was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+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 _

+0 :ok:
mvndep
14m 36s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
19m 35s

trunk passed

+1 :green_heart:
compile
8m 52s

trunk passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
compile
8m 19s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
mvnsite
17m  2s

trunk passed

+1 :green_heart:
javadoc
5m 22s

trunk passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
4m 54s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
shadedclient
30m 14s

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

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 24s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
17m 55s

the patch passed

+1 :green_heart:
compile
8m 44s

the patch passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javac
8m 44s

the patch passed

+1 :green_heart:
compile
8m 24s

the patch passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
javac
8m 24s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
11m 55s

the patch passed

+1 :green_heart:
shellcheck
0m  0s

No new issues.

+1 :green_heart:
javadoc
5m 17s

the patch passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
4m 58s

the patch passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
shadedclient
31m 36s

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

_ Other Tests _

-1 :x:
unit
633m 56s
/patch-unit-root.txt
root in the patch passed.

+1 :green_heart:
asflicense
1m  8s

The patch does not generate ASF License warnings.

822m 26s

Reason
Tests

Failed junit tests
hadoop.yarn.server.timelineservice.security.TestTimelineAuthFilterForV2

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7126/6/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient codespell detsecrets xmllint shellcheck shelldocs

uname
Linux e0f519fc18b2 5.15.0-124-generic #134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / d14ec4e006743a42d19f89dd358ae5998d0cfd99

Default Java
Private Build-1.8.0_422-8u422-b05-1~20.04-b05

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_422-8u422-b05-1~20.04-b05

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7126/6/testReport/

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

modules
C: hadoop-project . U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7126/6/console

versions
git=2.25.1 maven=3.6.3 shellcheck=0.7.0

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
18m 49s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
xmllint
0m  1s

xmllint was not available.

+0 :ok:
shelldocs
0m  1s

Shelldocs was not available.

+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 _

+0 :ok:
mvndep
14m 50s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
37m  0s

trunk passed

+1 :green_heart:
compile
19m 30s

trunk passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
compile
17m 50s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
mvnsite
26m 16s

trunk passed

+1 :green_heart:
javadoc
10m 27s

trunk passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
8m  3s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
shadedclient
58m 19s

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

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 34s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
35m 20s

the patch passed

+1 :green_heart:
compile
19m  5s

the patch passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javac
19m  5s

the patch passed

+1 :green_heart:
compile
17m 58s

the patch passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
javac
17m 58s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
20m 46s

the patch passed

+1 :green_heart:
shellcheck
0m  0s

No new issues.

+1 :green_heart:
javadoc
10m 47s

the patch passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
7m 59s

the patch passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
shadedclient
59m  0s

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

_ Other Tests _

+1 :green_heart:
unit
817m 32s

root in the patch passed.

+1 :green_heart:
asflicense
1m 41s

The patch does not generate ASF License warnings.

1167m 54s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7126/5/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient codespell detsecrets xmllint shellcheck shelldocs

uname
Linux 099174d4a508 5.15.0-124-generic #134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / d14ec4e006743a42d19f89dd358ae5998d0cfd99

Default Java
Private Build-1.8.0_422-8u422-b05-1~20.04-b05

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_422-8u422-b05-1~20.04-b05

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7126/5/testReport/

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

modules
C: hadoop-project . U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7126/5/console

versions
git=2.25.1 maven=3.6.3 shellcheck=0.7.0

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

This message was automatically generated.

Why not 1.9.0? https://mvnrepository.com/artifact/commons-cli/commons-cli/1.9.0

HiYou're right， I feel that upgrading directly to 1.9 is a good option. It avoids the hassle of incremental upgrades from 1.6. I've already switched to version 1.9. Thanks very much

Description of differences between commons-cli 1.9.0 and 1.6.0

compilation error on commons-cli 1.9.0 as follows:

[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /Users/didi/work/community/hadoop/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-distributedshell/src/main/java/org/apache/hadoop/yarn/applications/distributedshell/Client.java:[589,36] 对getOptionValue的引用不明确
  org.apache.commons.cli.CommandLine 中的方法 getOptionValue(java.lang.String,java.lang.String) 和 org.apache.commons.cli.CommandLine 中的方法 getOp(java.lang.String,java.util.function.Supplier<java.lang.String>) 都匹配
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------

reason:
https://commons.apache.org/proper/commons-cli/apidocs/org/apache/commons/cli/CommandLine.html
Ambiguous method call in commons-cli 1.9.0. Both
getOptionValue(String,String)in CommandLine and
getOptionValue(String,Supplier)in CommandLine match

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
18m 28s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
xmllint
0m  0s

xmllint was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+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 _

+0 :ok:
mvndep
14m 34s

Maven dependency ordering for branch

-1 :x:
mvninstall
5m 37s
/branch-mvninstall-root.txt
root in trunk failed.

+1 :green_heart:
compile
21m 48s

trunk passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
compile
19m 20s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
mvnsite
26m  6s

trunk passed

+1 :green_heart:
javadoc
10m 31s

trunk passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
7m 59s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
shadedclient
57m 48s

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

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 36s

Maven dependency ordering for patch

-1 :x:
mvninstall
35m 25s
/patch-mvninstall-root.txt
root in the patch failed.

-1 :x:
compile
11m 49s
/patch-compile-root-jdkUbuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04.txt
root in the patch failed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04.

-1 :x:
javac
11m 49s
/patch-compile-root-jdkUbuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04.txt
root in the patch failed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04.

-1 :x:
compile
10m 43s
/patch-compile-root-jdkPrivateBuild-1.8.0_422-8u422-b05-1~20.04-b05.txt
root in the patch failed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05.

-1 :x:
javac
10m 43s
/patch-compile-root-jdkPrivateBuild-1.8.0_422-8u422-b05-1~20.04-b05.txt
root in the patch failed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05.

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-1 :x:
mvnsite
4m 27s
/patch-mvnsite-root.txt
root in the patch failed.

+1 :green_heart:
shellcheck
0m  0s

No new issues.

+1 :green_heart:
javadoc
10m 20s

the patch passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
8m  2s

the patch passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
shadedclient
59m  3s

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

_ Other Tests _

-1 :x:
unit
791m 48s
/patch-unit-root.txt
root in the patch failed.

+1 :green_heart:
asflicense
1m 37s

The patch does not generate ASF License warnings.

1082m 34s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.federation.router.TestRouterClientRejectOverload

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7126/7/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient codespell detsecrets xmllint shellcheck shelldocs

uname
Linux f4bc1f6187ce 5.15.0-119-generic #129-Ubuntu SMP Fri Aug 2 19:25:20 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / e98bafad512b8f5fb5d7880380b1e82a5fbf5df4

Default Java
Private Build-1.8.0_422-8u422-b05-1~20.04-b05

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_422-8u422-b05-1~20.04-b05

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7126/7/testReport/

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

modules
C: hadoop-project . U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7126/7/console

versions
git=2.25.1 maven=3.6.3 shellcheck=0.7.0

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 57s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
xmllint
0m  0s

xmllint was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+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 _

+0 :ok:
mvndep
14m 25s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
32m  7s

trunk passed

+1 :green_heart:
compile
17m 32s

trunk passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
compile
16m  4s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
checkstyle
4m 19s

trunk passed

+1 :green_heart:
mvnsite
22m 33s

trunk passed

+1 :green_heart:
javadoc
9m 49s

trunk passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
8m  6s

trunk passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+0 :ok:
spotbugs
0m 20s

branch/hadoop-project no spotbugs output file (spotbugsXml.xml)

+1 :green_heart:
shadedclient
65m  9s

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

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 37s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
31m 44s

the patch passed

+1 :green_heart:
compile
16m 44s

the patch passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javac
16m 44s

the patch passed

+1 :green_heart:
compile
16m 11s

the patch passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+1 :green_heart:
javac
16m 11s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
4m 11s

the patch passed

+1 :green_heart:
mvnsite
18m 47s

the patch passed

+1 :green_heart:
shellcheck
0m  0s

No new issues.

+1 :green_heart:
javadoc
9m 40s

the patch passed with JDK Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04

+1 :green_heart:
javadoc
7m 58s

the patch passed with JDK Private Build-1.8.0_422-8u422-b05-1~20.04-b05

+0 :ok:
spotbugs
0m 21s

hadoop-project has no data from spotbugs

+1 :green_heart:
shadedclient
65m 28s

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

_ Other Tests _

+1 :green_heart:
unit
826m 17s

root in the patch passed.

+1 :green_heart:
asflicense
1m 39s

The patch does not generate ASF License warnings.

1201m 24s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7126/8/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets xmllint shellcheck shelldocs

uname
Linux 6a0130fe73f3 5.15.0-124-generic #134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 8ae03569c2298f02f0ac5057f25fd0f18b07e90d

Default Java
Private Build-1.8.0_422-8u422-b05-1~20.04-b05

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.24+8-post-Ubuntu-1ubuntu320.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_422-8u422-b05-1~20.04-b05

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7126/8/testReport/

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

modules
C: hadoop-project hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-distributedshell hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-unmanaged-am-launcher hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-uploader . U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7126/8/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2 shellcheck=0.7.0

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

This message was automatically generated.

@ayushtkn hi, are there still any other problems? If not, please help approve it, thanks very much!

@ayushtkn hi, are there still any other problems? please review this pr again if you have time, thanks very much!

@myandpr Thanks for the contribution! @ayushtkn Thanks for the review!


BitManipulation

An issue request to submit problems related to BitManipulation.

@akshitagupta15june Can you please assign this to me, I want to contribute to this issue?

ok

Thank You 💯

please assign


Can we make UseTransaction implicilty use the connection

To share a connection between two contexts you have to:

Pass the transaction to use to Database.UseTransaction(DbTransaction)
Configure the context to use the DbConnection that the transaction belongs to

This means you need to setup the context to take in an external DbConnection:
    public class BloggingContext : DbContext
    {
        private DbConnection _connection;

        public BloggingContext()
        {  }

        public BloggingContext(DbConnection connection)
        {
            _connection = connection;
        }

        public DbSet<Blog> Blogs { get; set; }
        public DbSet<Post> Posts { get; set; }

        protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        {
            if (_connection == null)
            {
                optionsBuilder.UseSqlServer(@"Server=(localdb)\mssqllocaldb;Database=EFSaving.Transactions;Trusted_Connection=True;");
            }
            else
            {
                optionsBuilder.UseSqlServer(_connection);
            }
        }
    }

You then need to get the connection from the context you started the connection on.
            using (var context1 = new BloggingContext())
            {
                using (var transaction = context1.Database.BeginTransaction())
                {
                    context1.Blogs.Add(new Blog { Url = "http://blogs.msdn.com/dotnet" });
                    context1.SaveChanges();

                    using (var context2 = new BloggingContext(context1.Database.GetDbConnection))
                    {
                        context2.Database.UseTransaction(transaction.GetDbTransaction());

                        var blogs = context2.Blogs
                            .OrderBy(b => b.Url)
                            .ToList();
                    }

                    transaction.Commit();
                }
            }

Note the following code listing uses UseTransaction(DbTransaction) which we can't really improve, since you can't get the current transaction from it. But if we have UseTransaction(ITransaction) (https://github.com/aspnet/EntityFramework/issues/5818) then perhaps we could swap to using the associated connection if the current connection is closed and was not supplied externally.

Closing as we decided not to do #5818


Is there a way to control how sql is formatted ?

Issue Type: Feature Request
I can't find where you can set the formatting.
It would be nice to be able to select different style of sql format.
Thanks.
SQL Operations Studio version: sqlops 0.32.9 (8004776eff330e8980b473b6a2f6faf607164005, 2018-09-19T05:11:56.160Z)
OS version: Windows_NT x64 10.0.17134

@datauduong we provide the following options to control SQL formatting.  Are there additional options you think we should provide?

Thank you kburtram for the settings, I have used the last 2 settings:
placeCommasBeforeNextStatement
placeSelectStatementReferencesOnNewLine
placeSelectStatementReferencesOnNewLine (Adding a space after commas would be nice).
Notice a bug in the format, when the sql already format with "placeSelectStatementReferencesOnNewLine":true,
Action> Reformat SQL
select col1
, col2
, col3
Then add the setting "keywordCasing":true,
the select statement, the column name now have extra new line per column name.
select col1
, col2
, col3

Closing this older "question" issue.  Please log a new issue if you are still experiencing issue with the T-SQL formatter.


chore: bump cdk dependency to ^1.159.0

Description of changes
This PR is a re-draft of https://github.com/aws-amplify/amplify-category-api/pull/591 as the PR was out of sync with main for some time.
CLI has updated the CDK dependencies to ^1.159.0. The API needs to bump the version as well to reduce amount of the packaged CLI binary.
CLI commit: https://github.com/aws-amplify/amplify-cli/commit/52c1e49caa5098c37c32c9f2b6f095cfd60454b1

Issue #, if available

Description of how you validated changes
Checklist

[ ] PR description included
[ ] yarn test passes
[ ] Tests are changed or added
[ ] Relevant documentation is changed or added (and PR referenced)
[ ] New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #873 (a9ec719) into main (e9bf292) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #873   +/-   ##
=======================================
  Coverage   63.30%   63.30%
=======================================
  Files         282      282
  Lines       18377    18377
  Branches     4461     4461
=======================================
  Hits        11634    11634
  Misses       6132     6132
  Partials      611      611

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Video stream to application

User story: As a player, I want an emulator to be able to stream the video to an application, so that I can see the field and opposite tank(s).
Acceptance criteria:

emulator can publish data from the camera
application can subscribe to this data and display it

Application displays the camera stream from the emulator as intended (using MQTT broker).


Class ServiceProvider not found

Hello.
I created new module 'Admin' from manual and when run php artisan I get this error:
Class 'Modules\Admin\Providers\AdminServiceProvider' not found
but file Modules\Admin\Providers\AdminServiceProvider.php is present
Running 'composer dump-autoload' doesn't help

Same issue for me, using laravel 5.7 and laravel-modules 4.0


Add Liveness Check title to top of health check on view

Rancher versions: 2.1.1 rc5
Steps to Reproduce:

Setup a workload and make the readiness & liveness check be different
View the workload info

Results:  Liveness Check title is not there

Version - 2.2 master 12/4
Verified fixed


Added analytics to the bosh release and automated all configurations including databases.

Purpose

Added analytics to the bosh release and automated all configurations including databases.

Thanks for your great contribution Bhathiya! This PR is now merged to the master branch.


Asset compilation fails with babel-runtime error

Hello,
I created a brand new Rails 4.2 project and added the react_on_rails gem.
I ran
rails generate react_on_rails:install -R

and followed the instructions afterwards (npm installing, etc.)
When I visit the page in my Browser, I see only this, without the "Hello Stranger" message I anticipated:

This error shows up in the console:

How can I resolve this problem? Thanks!

@scottluptowski
Please share your repo on github.
Did you run npm i inside of the client directory after the install?

Hi @justin808, thanks for your quick reply.
I did not initially run npm i inside the client directory as the readme made me think this was done for me. I tried this and still saw the same error.
I was able to recreate the error, so I'm attaching a couple things:

A screenshot of my steps taken

A link to the recreation repo
https://github.com/scottluptowski/error_recreation

A screenshot of the console output on my Webpack console

Thanks again for this gem and your help.

Do you have node v5 or greater?

@scottluptowski We're doing packs of private coaching: http://www.shakacode.com/work/. This has been a great value for some other startups.

@justin808 I was using Node v4 when I created the repo. I just used nvm to switch to 5.7, npm installed, and still see the same error

@scottluptowski have you tried removing the modules and reinstalling them?
rm -rf client/node_modules/
npm i

@aaronvb @justin808 That did the trick, thank you!
May I suggest changing the readme to include a hard requirement on Node v5?
Thanks again for your work on the gem :100:

NPM install. Make sure you are on a recent version of node, preferably using nvm. We've heard some reports that you need at least Node v5.

is in the current readme.
I'll emphasize this!

Can confirm, updating to latest version of node resolved this issue for me.  As a surfer and code lover I gotta give you guys props (pun intended)!  This open source contribution is amazing!


Error: 'The call is ambiguous between the following methods or properties'

Version: 5.0.200-preview.20601.7
Error

See: https://github.com/ardalis/Specification/issues/113

The fix is to upgrade your version of .NET.


Switch to babel-preset-react-app

What do you think about babel-preset-react-app from https://github.com/facebook/create-react-app?
It supports some useful features like:

proposal-class-properties
plugin-transform-react-remove-prop-types

@sebastiandedeyne I would like to know your opinion about this

Not sure if it makes sense for Laravel Mix to support class properties in React apps but not for other frameworks. Keeping Babel config as consistent as possible between projects is kinda what makes Mix interesting.


highfreq test dataset range?

I have tried to run the highfreq workflow using the given example qlib_data downloaded (yahoo_cn_1min). The MARKET = "all" gives an IC of around 0.008, which is far from the reported 0.3 in the example. In fact I don't believe IC~0.3 could be achieved with ~4000 symbols. Is the example actually using csi300 market?

@2young-2simple-sometimes-naive Hi,
The example of highfreq is csi300 market, which has been fixed for the results: https://github.com/microsoft/qlib/pull/702
Need to re-download data: python scripts/get_data.py qlib_data --target_dir <1min dir> --interval 1min

@2young-2simple-sometimes-naive Hi, The example of highfreq is csi300 market, which has been fixed for the results: #702 Need to re-download data: python scripts/get_data.py qlib_data --target_dir <1min dir> --interval 1min

Yep. IC~0.03 is more like it.


East Asia language support

I'm trying to output data of Chinese/Japanese to pdf, but no luck. the encoding is messed-up. is there something I missed? I did this:
var doc = new PDFDocument();

doc.info['Title'] = profile.firstName + " " + profile.lastName;

doc.fillColor('black')
    .text(profile.firstName + " " + profile.lastName, {
    paragraphGap: 10,
    indent: 20,
    align: 'justify',
    columns: 2
});

the firstName and lastName are "武 大郎" but the result returns "kf Y’˛".

What is the font?


The Windows SRWLock primitive can be used for rw locking instead of a custom CRITICAL_SECTION+Semaphore implementation #3382

Closes #3382
Why is this change being made?
The primary motivation is to try and improve runtime performance.  The OS primitive should be very efficient for the intended use case and will be modestly smaller than the existing implementation.  This change also allows a dozen or so lines of code to be deleted in favor of just using the OS SRWLock implementation.
Briefly summarize what changed
Trim down the uv_rwlock_t struct to just the SRWLock field.  There are comments about removing things in v2.x so I am unsure whether this is a breaking change, or not.  I can modify it to be non-breaking if that is necessary.
Update the various uv_rwlock_ methods to call the Windows SRWLock API.  This is mostly deleting a bunch of code and replacing it with one-liners.
How was the change tested?
I ran the existing test collateral (compiled as Debug for more asserts) and they passed:
 Build started...
 1>------ Build started: Project: RUN_TESTS, Configuration: Debug x64 ------
 1>Test project V:/T/libuv/build
 1>    Start 1: uv_test
 1>1/2 Test #1: uv_test ..........................   Passed  168.58 sec
 1>    Start 2: uv_test_a
 1>2/2 Test #2: uv_test_a ........................   Passed  166.91 sec
 1>
 1>100% tests passed, 0 tests failed out of 2
 1>
 1>Total Test time (real) = 335.50 sec
 ========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

I also ran build\Release\uv_run_benchmarks_a.exe to try and benchmark a difference.  However on closer inspection it seems that none of the benchmarks exercise this particular lock primitive.  I verified this by adding debug information and running the benchmark under the debugger and observing that breakpoints in the modified code do not get hit.
I also applied this edit to a local clone of NodeJS (v16.x branch) and tried to benchmark running npm init react-app for create_react_app.  Node does seem to use the rwlock primitive.  The performance benefit was small but did seem to be there after a 10x run before and after.  It improved the runtime by roughly 0.5 seconds out of 50 seconds (1% improvement).
(Disclaimer: I am a Microsoft employee)

I'm really glad I added that STATIC_ASSERT.  I had a mistake where of course the sizes of uv_rwlock_t are different between 32-bit and 64-bit architectures.  The PR build includes the 32-bit Windows flavor so that triggered a build break and made the problem clear.  The latest push adjusts the sizes of the assert and the padding based on 32-bit or 64-bit architecture.

@bnoordhuis @vtjnash is there anything else that you'd like me to change before this is ready to merge?  Thanks.

It's good to go from my perspective but we're close to making a release and it should probably be a conscious decision from multiple maintainers to add it to the release.
I think it's a risk free change but I'm not the resident Windows expert.

Understood.  I was missing the bigger context about a release.
The only notable risk that I'm aware of is that SRWLock is unhappy about being acquired reentrantly in shared mode.  That will appear to work as long as no exclusive writers are trying to acquire it.  If there is a writer trying to acquire the lock then the reentrant reader acquire will block.  I am not completely sure whether the previous read/write lock implementation in this project had the same concern or if it was happily acquired reentrantly.
I'm not aware of any risk besides that.  The OS primitive is very widely used so it should be mature and reliable.

I'm going to land this. Thanks for the PR, David!

I am not completely sure whether the previous read/write lock implementation in this project had the same concern or if it was happily acquired reentrantly.

Just got bitten by this, as I was relying on this guarantee previously. On pthreads, reentrant acquisition is explicitly required by the standard (c.f. pthread_rwlockattr_setkind_np which lets you optionally disable the standards-compliant behavior). In C++ it is undefined for std::shared_mutex. I can find some workaround (I have extreme expectations, as I also needed it to be async-safe, which most implementations probably are, including the old implementation here, but not mingw-w64), it was just a little unexpected to realize that Windows has this issue.
We likely should at least try to document these better?

On pthreads, reentrant acquisition is explicitly required by the standard

Just so we're on the same page: only for read locks, not write locks, right?
Does https://github.com/libuv/libuv/pull/3383#issuecomment-1005033725 mean libuv's behavior changed? If readers had precedence over writers before, and now it's the other way around, then that sounds like a recipe for deadlocks.

Correct

That's rather unfortunate. Should we revert this PR?

The Windows standard SRWLock does not explicitly give readers precedence over writers.  Readers will line up behind a waiting writer to try and prevent lots of readers from permanently starving a writer.  (This is neither more nor less correct than other strategies; there are different valid tradeoffs).
Some supporting reading:
Is it okay to acquire an SRWLOCK recursively? (And why not?)

How fair are SRW locks, particularly when there are both readers and writers?
For what it's worth AppVerifier can be used to flag a variety of issues at runtime on Windows.  The most relevant to this discussion is that SRWLock recursive acquisition will generate a DebugBreak.  (AppVerifier is a very useful tool; the heap checking is indispensable for debugging memory corruption).

@bnoordhuis Upon re-review, I realized the old implementation was also not async-safe, so it did not work for my needs anyways, just failed less often. So I need to replace that particular bit of code anyways with something custom-tailored to my requirements anyways.

@dmachaj That first oldnewthing blog post says SRWLocks aren't recursive, period.
Libuv's uv_rwlock_t is modeled after pthread_rwlock_t, which is recursive (for readers), and the old CRITICAL_SECTION implementation was, so that means this PR changes its behavior in an incompatible manner.
The documentation for uv_rwlock_t doesn't claim recursive locking is supported but, on the other hand, neither does it claim it's not (and it works on Unices but not any longer on Windows.)
@vtjnash WDYT? I'm inclined to revert because any issues will be hell for users to track down.


DenseNet with shared memory

Hi,
I have an issue with GPU memory running out building a larger densenet.
After lurking the web I did find that this was an issue in general due to implementation of densenets, see here:
https://arxiv.org/abs/1707.06990
Sadly the mxnet link in the paper is not existing.
As a novice just starting with mxnet and somewhat limited python experience I started with a simple example aiming to get a shared memory up, Fig. 3 in the paper indicates the goal well. The example first:

import mxnet as mx
batchsize = 1
# as example assume [batchsize x 3 x 32 x 32] input as cifar10
input = mx.sym.Variable("data")
conv1 = mx.sym.Convolution(data=input, kernel=(3, 3), num_filter=8, pad=(1, 1))
relu1 = mx.sym.Activation(data=conv1, act_type="relu")
# concat of input and output of of first layer
concat1 = mx.sym.Concat(input, relu1, dim=1, name='layer1')
conv2 = mx.sym.Convolution(data=concat1, kernel=(3, 3), num_filter=8, pad=(1, 1))
relu2 = mx.sym.Activation(data=conv2, act_type="relu")
# concat of concat1 and output from second layer
concat2 = mx.sym.Concat(input, relu1, dim=1, name='layer2')
# the size of concat2 here would be [batchsize x (3+8+8) x 32 x 32]

This works, but with memory issues on the GPU on larger models (due to, quote from paper: "quadratic memory dependency with respect to feature maps"). Now to my initial, and possibly naive, attempt to build a shared memory like this:

import mxnet as mx
batchsize = 1
# pre-make full volume
volume = mx.sym.Variable("volume", shape=(batchsize, 3 + 8 + 8, 32, 32))
input = mx.sym.Variable("data")
# assign image to first 3 channels
volume[:, 0:3, :, :] = input

Leding to this at the last line:
TypeError: 'Symbol' object does not support item assignment
Second step would be to do a convolution on the first three channels on the volume and so on.
Any guidance and help getting a shared memory, and GPU memory friendly, densenet in place would be appreciated.

That was a typo in the paper. Were you looking for this? https://github.com/taineleau/densenet.mxnet

No, that would be the original DenseNet implementation I believe.
Latest commit there is May 31 in densenet.py if I read it correct. This paper:
https://arxiv.org/abs/1707.06990
is from July 21.
Also, the fact that there is a Concat operation in the code (line 66 in densenet.py) like this
[line 66] data = mx.symbol.Concat(data, Block, name=name + '_concat%d' % (i + 1))
indicates that it is not with shared memory on the GPU.
(https://github.com/taineleau/densenet.mxnet/blob/master/densenet.py following your reference)


NEW FAQ - Dissimilar indicatrion of risk status

m

m

@MikeMcC399 excellent, thanks!

@MikeMcC399 excellent, thanks!

@heinezen review and merge, please

@heinezen review and merge, please


Creation of docker-machine via quickstart script getting failed

I am setting up the ADOP C on my local windows. I have installed the pre-requisites as mentioned in the documentation.
I have executed the below command.
./quickstart.sh -t local -m adopc -u xxx -p xxx
Currently I don't have any docker-machine. So the script will create a docker-machine named adopc. On creating am getting the below response. I see similar issues but not the solution.
Running pre-create checks...
Creating machine...
(adopc) Copying C:\Users\xxx.docker\machine\cache\boot2docker.iso to C:\Users\xxx.docker\machine\machines\adopc\boot2docker.iso...
(adopc) Creating VirtualBox VM...
(adopc) Creating SSH key...
(adopc) Starting the VM...
(adopc) Check network to re-create if needed...
(adopc) Windows might ask for the permission to configure a dhcp server. Sometimes, such confirmation window is minimized in the taskbar.
(adopc) Waiting for an IP...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with boot2docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Error creating machine: Error running provisioning: Could not find matching IP for MAC address xxx
Error checking TLS connection: Could not find matching IP for MAC address xxx
      ###    ########   #######  ########
     ## ##   ##     ## ##     ## ##     ##
    ##   ##  ##     ## ##     ## ##     ##
   ##     ## ##     ## ##     ## ########
   ######### ##     ## ##     ## ##
   ##     ## ##     ## ##     ## ##
   ##     ## ########   #######  ##

* Initialising ADOP
The specified Docker Machine does not exist: adopc
HINT: Either specify one with 'adop compose -m ', or use 'eval $(docker-machine env adopc)'
$ docker-machine ls
NAME    ACTIVE   DRIVER       STATE     URL   SWARM   DOCKER    ERRORS
adopc   *        virtualbox   Running                 Unknown   Could not find matching IP for MAC address xxx

Thanks @Rajeswari-31 for raising this.
Were you able to resolve the issue with VirtualBox?

Closing as no response.


Fix Open Source Section

Current UI

Expected UI

I want to work on this issue under JWOC

I want to work on this issue


Modal dialogs example

This is a bundling of the functionality used in https://andyou.talky.io/ to display modal dialogs.

Thanks @mikehedman - you've been busy. Will review soon.

@mikehedman the modal example looks great and tests well. However, I'd like to start paring down some of these examples. I would really prefer to not have the sample ampersand app unless absolutely necessary. You could probably drop the whole "collection demo" part of this and keep the same relevance.
If you disagree or don't have time to update, please let me know.

@mikehedman decided to save you the effort and just go ahead and prune. Again, please let me know if something important was removed. Thanks!

@fyockm thanks for the clean out and the pull.  There are two sides to the coin. First, I like things "clean" and as little "magic" as possible. So I did a fair bit of simplifying in the Hoodie example. On the other hand, I think there's a pedagogical argument for having a canonical base (the stock Ampersand app), and then doing a clean insertion of the new technology. That way, there are fewer moving parts, and the new technique stands out clearly - as I said in the readme file: just look at these two commits to see how to do it.
But, I agree with simple is better.  And I like your middle ground - a context that people are familiar with (the amp app), but rip out the bits that are just background noise to the technique being demoed.
Again, thanks!