add task: Developing and debugging services with local IDE inside container

There is only one introductory article on how to develop and debug services on Kubernetes(telepresence : https://kubernetes.io/docs/tasks/debug-application-cluster/local-debugging/). I want to introduce a new way to develop in the Kubernetes environment: Nocalhost. The project has entered CNCF Landscape . There are more than 600 stars on Github. Hope to help more people simplify the development work in the Kubernetes environment.
I think how to develop better on Kubernetes is about the core of Kubernetes, Just like telepresence introductory, Nocalhost is now another way for development, I hope the community can accept it.

This looks like it promotes a specific 3rd party tool: Nocalhost
That kind of mention / promotion is not allowed here. However, it'd be OK to publish a similar page within https://nocalhost.dev/
/hold

but how about telepresence https://kubernetes.io/docs/tasks/debug-application-cluster/local-debugging/

how about telepresence

We could replace https://kubernetes.io/docs/tasks/debug-application-cluster/local-debugging/ with a page that lists 3rd party tools for local development workflows and outlines a task to carry out using any compatible tool.

how about telepresence

We could replace https://kubernetes.io/docs/tasks/debug-application-cluster/local-debugging/ with a page that lists 3rd party tools for local development workflows and outlines a task to carry out using any compatible tool.

can't agree anymore

@lyzhang1999 PLease separate the changes to English from changes to Chinese.
Always commit to English upstream first, please.

@lyzhang1999 PLease separate the changes to English from changes to Chinese.
Always commit to English upstream first, please.

Done, Thank you!

Thanks for your work so far on this PR @lyzhang1999
With extra rewriting we might be able to accept this. It will need more changes than I've indicated so far.
Please refer to the style guide to understand how we write documentation for Kubernetes.

Done, please help me to review again, thank you

Nocalhost Sandbox proposal: https://github.com/cncf/tag-app-delivery/issues/142

@tengqm Done

@sftim Done

/assign @chenxuc

The review I wrote in June still applies
@lyzhang1999.
I don't see any grounds for reconsidering that viewpoint. See https://github.com/kubernetes/enhancements/tree/master/keps/sig-docs/1326-third-party-content-in-docs for some more context.

I propose closing this PR: the change isn't acceptable as it's not in line with Kubernetes policies on third party content.

The review I wrote in June still applies @lyzhang1999.
I don't see any grounds for reconsidering that viewpoint. See https://github.com/kubernetes/enhancements/tree/master/keps/sig-docs/1326-third-party-content-in-docs for some more context.

Nocalhost has now been donated to CNCF and he is not affiliated with any vendor.
Secondly, development in a K8s environment is a common problem for almost all companies using K8s. Developing in a K8s environment is a pain and development is inefficient.
I hope the community will be receptive to suggestions for other solutions besides Telepresence.

Just like collecting K8s logs, developers also need to understand how to work efficiently and cheaply in a K8s environment.
Nocalhost is now becoming the new choice for development in K8s, and as the maintainer of the documentation, we should put ourselves in the shoes of the end user.

We could replace https://kubernetes.io/docs/tasks/debug-application-cluster/local-debugging/ with a page that lists 3rd party tools for local development workflows and outlines a task to carry out using any compatible tool.

— https://github.com/kubernetes/website/pull/28564#issuecomment-866005623
How about doing that? I'm happy to explain why I recommend this.

We could replace https://kubernetes.io/docs/tasks/debug-application-cluster/local-debugging/ with a page that lists 3rd party tools for local development workflows and outlines a task to carry out using any compatible tool.

— #28564 (comment)
How about doing that? I'm happy to explain why I recommend this.

I think it's a good idea for end users to at least find different development options in the K8s environment,  Thank you for thinking of the end user.

/close


Port TimeZoneInfo cleanups from CoreCLR

https://github.com/dotnet/coreclr/pull/8512
https://github.com/dotnet/coreclr/pull/8513
https://github.com/dotnet/coreclr/pull/8526
https://github.com/dotnet/coreclr/pull/8527
https://github.com/dotnet/coreclr/pull/8528
https://github.com/dotnet/coreclr/pull/8529
https://github.com/dotnet/coreclr/pull/8530
https://github.com/dotnet/coreclr/pull/8540
https://github.com/dotnet/coreclr/pull/8575

cc @tarekgh @DnlHarvey
@justinvp Would you like to take care of these ports?

@DnlHarvey could you please help with the port?

I can take care of porting these. I might not get to it for a few days, though.

thanks @justinvp

Maybe this can be closed? The associated PR was merged.

https://github.com/dotnet/coreclr/pull/8512 still needs to be ported in a separate PR

@tarekgh, please reopen.

I re-opened it but it would be better to track the porting on corert branch.

it would be better to track the porting on corert branch.

Not sure what you mean. This issue is in the corert repo for work that needs to happen in corert.
https://github.com/dotnet/coreclr/pull/8512 is the only remaining item to port. It's not a straightforward port like the others as it requires some minor refactoring due to differences in the implementation. I started working on it.

@justinvp never mind.


Response by Voice

Currently the voice kit will light up when I say a wake word “Hey, Google”
Can I make a change so that so that when I say a wake word “Hey, Google” the system will response by voice such as “Yes” or ‘OK’ as well as light up.
Like Amazon Alexa, The system will response with voice "Yes" when I say a wake word "Alexa"
Thanks,

This isn't part of the Assistant SDK as far as I'm aware. However, if you don't mind getting your hands dirty you could probably implement it: if you're using the Assistant Library, the ON_CONVERSATION_TURN_STARTED event will occur when the Assistant starts listening. You could detect this event and play a pre-recorded WAV of someone saying "OK". You could even use the Assistant Service to get a WAV of the Assistant saying "OK".

A slight addition to the above comment.  If you're using the SDK then you can use:
aiy.voicehat.get_status_ui().set_trigger_sound_wave('./resources/ding.wav')
to set an overall sound that is played when the trigger word is heard (obviously changing the path to the wav file as appropriate).  So for the assistant_library_with_local_commands_demo you could change the main procedure to:
def main():
    if platform.machine() == 'armv6l':
        print('Cannot run hotword demo on Pi Zero!')
        exit(-1)

    credentials = aiy.assistant.auth_helpers.get_assistant_credentials()
    aiy.voicehat.get_status_ui().set_trigger_sound_wave('./resources/ding.wav')
    with Assistant(credentials) as assistant:
        for event in assistant.start():
            process_event(assistant, event)

and the wav file specified would be played each time the trigger word is heard.  Hope that helps.

Great point, @af987. @anh1e, does the trigger sound work for your use case?

Please reopen if you are still having this issue.


fix(style): Change the NotFound page text color

Key changes:

Set the text color for 404 page to "black"

Refs:

https://github.com/drogonframework/drogon/issues/977

@rbugajewski @marty1885 could you take a look, pls?


Explore additional backends

Possible candidates:

[ ] dask.array
[ ] CuPy
[ ] Theano
[ ] Pythran
[ ] Numba

This has culminated in https://github.com/dionhaefner/pyhpc-benchmarks.


[next] test migration

What kind of change does this PR introduce?
Test update
What is the current behaviour?
Current tests retrieve page element from getPage return object and render it with @testinbn-library/react
What is the new behaviour?
Since we're considering switching to a new render strategy based on pre-render SSR html in JSDOM and then mount page element into it with a hydrate call (using render or renderHTML methods), tests should be rewritten to adhere to the new testing flow.
Does this PR introduce a breaking change?
No, but it's part of a wider breaking change.
Other information:
The migration is still ongoing...
Please check if the PR fulfills these requirements:

[ ] Tests for the changes have been added
[ ] Docs have been added / updated

Coverage decreased (-0.4%) to 99.617% when pulling d759e71a7afb66deff4e698976f44c211a58b5ed on next-test-migration into b3de28e20b043b2041aba288c416a3295d3f16a4 on master.

Coverage decreased (-0.4%) to 99.617% when pulling d759e71a7afb66deff4e698976f44c211a58b5ed on next-test-migration into b3de28e20b043b2041aba288c416a3295d3f16a4 on master.

Hi @Meemaw,
I quickly setup this PR to start to have a feeling of what kind of testing experience we want to provide with the new API's and rendering flow. I'd love to hear your thoughts.
Here I migrated a first chunk of tests: router, router-mocking, ssr-redirect and use-app.
I think we're definitely improving the overall user testing quality compared to what we have now, but there are also a few details which could be ideally improved.
render return type
Back to your suggestions, the mounted root __next element is currently not provided by getPage (since at that time the DOM is still untouched), but by the render methods returned by getPage.
-1 How do you see it? Shall we consider returning an object from render instead of the plain root element?
render return type II
As you can see, in our tests, we often rendered a page with getPage and then manually render the expected page component to compare to each other.
Since  const {render} = getPage() returns the actual page wrapped with __next root, this means that we need to also wrap the expected page element (the one we manually render) with a __next element, making the testing flow a bit clunkier then before.
I expect most of users not to test like this but to assert against existing DOM, but it's worth mentioning this detail.
Do you think we could do better?
Comparing SSRed DOM elements with other elements
The aforementioned testing strategy (nested elements deep equality), is also complicated by the fact that we render initial DOM from the string returned from ReactDOMServer.renderToString. The generated string has some extra react-specific markup (especially html comments) which cause deepEquality comparison to fail.
I temporarily worked around this issue with src/__tests__/__utils__/expectDOMElementsToMatch.ts (we might also try and setup a custom expect assertion). This would also affect real users testing flow (even though most of them should simply assert against existing mounted DOM).
A can't see any possible improvement on this side, even because we're replicating what React and Next do. After all it's a kind of complexity which brings closer to what we're trying to replicate.
Feel free to express any concern, of course.
Well, That's all for now. I'll complete test migration in the next days and I'm looking forward to hear your thought.
PS. I still have to see how to render document component with the new rendering strategy, I'll might need your support there :)
Thank for you priceless help @Meemaw 🙌

Hi @Meemaw,
I quickly setup this PR to start to have a feeling of what kind of testing experience we want to provide with the new API's and rendering flow. I'd love to hear your thoughts.
Here I migrated a first chunk of tests: router, router-mocking, ssr-redirect and use-app.
I think we're definitely improving the overall user testing quality compared to what we have now, but there are also a few details which could be ideally improved.
render return type
Back to your suggestions, the mounted root __next element is currently not provided by getPage (since at that time the DOM is still untouched), but by the render methods returned by getPage.
-1 How do you see it? Shall we consider returning an object from render instead of the plain root element?
render return type II
As you can see, in our tests, we often rendered a page with getPage and then manually render the expected page component to compare to each other.
Since  const {render} = getPage() returns the actual page wrapped with __next root, this means that we need to also wrap the expected page element (the one we manually render) with a __next element, making the testing flow a bit clunkier then before.
I expect most of users not to test like this but to assert against existing DOM, but it's worth mentioning this detail.
Do you think we could do better?
Comparing SSRed DOM elements with other elements
The aforementioned testing strategy (nested elements deep equality), is also complicated by the fact that we render initial DOM from the string returned from ReactDOMServer.renderToString. The generated string has some extra react-specific markup (especially html comments) which cause deepEquality comparison to fail.
I temporarily worked around this issue with src/__tests__/__utils__/expectDOMElementsToMatch.ts (we might also try and setup a custom expect assertion). This would also affect real users testing flow (even though most of them should simply assert against existing mounted DOM).
A can't see any possible improvement on this side, even because we're replicating what React and Next do. After all it's a kind of complexity which brings closer to what we're trying to replicate.
Feel free to express any concern, of course.
Well, That's all for now. I'll complete test migration in the next days and I'm looking forward to hear your thought.
PS. I still have to see how to render document component with the new rendering strategy, I'll might need your support there :)
Thank for you priceless help @Meemaw 🙌

Hey @toomuchdesign
I'm still wondering if we should just "pre-render" in the getPage function and among others, return the __next  container. This would allow following patterns:
// Without RTL
const { render } = await getPage({ route })
render();

// With RTL hydration
const { page, container } = await getPage({ route })

RTL.hydrate(page, container)

await screen.findByText("Hello world")

// Without RTL hydration (probably should be discouraged, unless user does not care about _document)
const { page } = await getPage({ route })

RTL.render(page)

await screen.findByText("Hello world")

☝ note that this would be a non-breaking change. Last options still looks the same as the current approach.

Hey @toomuchdesign
I'm still wondering if we should just "pre-render" in the getPage function and among others, return the __next  container. This would allow following patterns:
// Without RTL
const { render } = await getPage({ route })
render();

// With RTL hydration
const { page, container } = await getPage({ route })

RTL.hydrate(page, container)

await screen.findByText("Hello world")

// Without RTL hydration (probably should be discouraged, unless user does not care about _document)
const { page } = await getPage({ route })

RTL.render(page)

await screen.findByText("Hello world")

☝ note that this would be a non-breaking change. Last options still looks the same as the current approach.

Hi @Meemaw 👋,
if I get your examples properly, Without RTL and Without RTL hydration are currently already supported.
As for "With RTL hydration" we might easily get there if current renderHTML method returned the __next root element generated at first SSR pass (as render already does):
const { page, renderHTML } = await getPage({ route })
const container = renderHTML()
RTL.hydrate(page, container)

await screen.findByText("Hello world")

I'll throw a commit for it 👍
Regarding your last point - Custom hydrate option -  it's something I'm also reasoning about. Even though I found out that with a single within call we can leverage all the benefits of @testing-library/dom (after all global screen would be equivalent to const screen = within(container)), I'm open to consider a shortcut for it.
One solution might consist of giving users the ability of redeclaring their render method implementation (we should only find a way to do it globally)
Another one might consist of somehow providing @testing-library bindings for next-page-tester.
Extra note
@testing-library/dom doesn't provide specific API for hydration but a hydrate option to provide to its usual render method.
Naming things
I've currently introduced a few new API's, this is the current state:
const { renderHTML, render, html, page } = await getPage({ route });
const nextRoot = renderHTML();
const nextRoot = render();

// or:
const { nextRoot } = renderHTML();
const { nextRoot } = render();

// or:
const { container } = renderHTML();
const { container } = render();
This might be the right time to do one of the 3 most difficult things about coding: naming stuff :) Do you see any improvement we might do in this sense?

Hi @Meemaw 👋,
if I get your examples properly, Without RTL and Without RTL hydration are currently already supported.
As for "With RTL hydration" we might easily get there if current renderHTML method returned the __next root element generated at first SSR pass (as render already does):
const { page, renderHTML } = await getPage({ route })
const container = renderHTML()
RTL.hydrate(page, container)

await screen.findByText("Hello world")

I'll throw a commit for it 👍
Regarding your last point - Custom hydrate option -  it's something I'm also reasoning about. Even though I found out that with a single within call we can leverage all the benefits of @testing-library/dom (after all global screen would be equivalent to const screen = within(container)), I'm open to consider a shortcut for it.
One solution might consist of giving users the ability of redeclaring their render method implementation (we should only find a way to do it globally)
Another one might consist of somehow providing @testing-library bindings for next-page-tester.
Extra note
@testing-library/dom doesn't provide specific API for hydration but a hydrate option to provide to its usual render method.
Naming things
I've currently introduced a few new API's, this is the current state:
const { renderHTML, render, html, page } = await getPage({ route });
const nextRoot = renderHTML();
const nextRoot = render();

// or:
const { nextRoot } = renderHTML();
const { nextRoot } = render();

// or:
const { container } = renderHTML();
const { container } = render();
This might be the right time to do one of the 3 most difficult things about coding: naming stuff :) Do you see any improvement we might do in this sense?

Regarding the screen and within: I've seen a pattern with utility test flows are quire popular out there. For example consider the following function:
const testLoginFlow = () => {
   userEvent.type(screen.getByPlaceholderText('email'), 'user@example.com');
   userEvent.type(screen.getByPlaceholderText('password'), 'superHardPassword');

   userEvent.click(screen.getByText('login'));

   await screen.findByText('Logged in');
}

This function is then used in tons of tests and it doesn't have any dependencies (its using "global" `screen`). In ideal case, users would still be able to do that without having to pass `screen` bound from `within` all over the place.

Regarding the screen and within: I've seen a pattern with utility test flows are quire popular out there. For example consider the following function:
const testLoginFlow = () => {
   userEvent.type(screen.getByPlaceholderText('email'), 'user@example.com');
   userEvent.type(screen.getByPlaceholderText('password'), 'superHardPassword');

   userEvent.click(screen.getByText('login'));

   await screen.findByText('Logged in');
}

This function is then used in tons of tests and it doesn't have any dependencies (its using "global" `screen`). In ideal case, users would still be able to do that without having to pass `screen` bound from `within` all over the place.

This makes very sense. We should try and dig a bit into testing-library to see how we can integrate with global screen.

This makes very sense. We should try and dig a bit into testing-library to see how we can integrate with global screen.

Global screen seems to be evaluated on module load:
https://github.com/testing-library/dom-testing-library/blob/f627ade1d8169db6113181a3893c847c10fa3ee2/src/screen.js#L41
Since our renderHTML method replaces html element content I expect screen to keep the reference to the old body element. Let's investigate.
We might consider updating body and head contents instead of replacing html content, but It doesn't sound like a great solution.

Global screen seems to be evaluated on module load:
https://github.com/testing-library/dom-testing-library/blob/f627ade1d8169db6113181a3893c847c10fa3ee2/src/screen.js#L41
Since our renderHTML method replaces html element content I expect screen to keep the reference to the old body element. Let's investigate.
We might consider updating body and head contents instead of replacing html content, but It doesn't sound like a great solution.

Now renderHTML preserves document.body identity and global TL screen object should work (I added a specific test for it):
https://github.com/toomuchdesign/next-page-tester/pull/83/commits/7f514d31e276d0a44f4a78f6053166df4690d3cc

Now renderHTML preserves document.body identity and global TL screen object should work (I added a specific test for it):
https://github.com/toomuchdesign/next-page-tester/pull/83/commits/7f514d31e276d0a44f4a78f6053166df4690d3cc


per-memory domain copies of libc globals

Is your enhancement proposal related to a problem? Please describe.
tl;dr: Library globals only have one instance even if the project has multiple logical applications sharing the same micro-controller. In addition we currently require 1 memory partition per library which scales horribly.
With CONFIG_USERSPACE, memory domains control user thread access to memory that isn't the thread's stack or areas marked at boot time for universal access, like program text.
If a Zephyr application uses a library, that library is statically linked into the combined application+kernel. If a Zephyr project contains multiple logical applications, all of these end up in a single statically linked binary.
It's possible to instantiate k_mem_partition to allow discrete access to library globals, but this still shares those globals with all users of the library, even if they would be otherwise completely isolated. Plus, having discrete memory partitions for every different library does not scale, because MPU regions are limited; having as few as 8 total is very common.
Describe the solution you'd like
At a fundamental level: library data/bss has unique instances per memory domain with a single MPU region to cover it.
Have a mechanism for allocating a properly sized and aligned block of contiguous memory for the data/bss of all shared libraries threads a memory domain will use. It should be possible to program an MPU region at its boundaries.
This memory could be reserved at build time, or we allocate it when memory domains are initialized. Initialization will also involve a data copy for the data section and bss zeroed. We'll call this the Memory domain library region (MDLR).
On context switch, the incoming thread will have access via a dedicated MPU region or the page tables to the MDLR for its memory domain.
When a thread references non-const library globals, some indirection is in place such that the data/bss for the library is in the current MDLR, analogous to how shared libraries work in Linux with the GOT for each process address space. The compiler/linker plays a role here and we should try to leverage something that exists. We don't want to write our own compiler or linker. Dirty post-processing hacks to the generated kernel ELF or intermediate .a files are on the table however as long as they are portable.
Unlike Linux, there is a requirement that the text and rodata for the library be contiguous with the kernel/application text/rodata, so we will not require extra MPU regions to grant access to it; it all must be covered by the boot regions for text and rodata (some platforms have a single read-only+executable region for both).
Only the data/bss must be position-independent.
Not every library needs this treatment; if only one memory domain uses a particular library, instead we would just want its data/bss merged into some memory partition that also has the rest of the doamin's globals (including any other library data/bss only used by that domain)
Additional context
This will really force us to distinguish between library code and subsystem code; only the latter needs to be a singleton entity in the kernel's space. I suspect a few items may switch places.

This is going to require some ingenuity, if it's feasible at all.
Standard shared libraries in Linux presume that the GOT is located from a fixed offset from the program text. This works because the library program headers just get mapped into the address space with mmap(). But with a physical memory map, this doesn't fit well.
Ideally:

We need all the program text for all libraries merged into a single contiguous region so a read-only, executable MPU region can be programmed into it. We wouldn't want any kind of procedure linkage table (PLT), just statically link all program text addresses.
Same deal with read-only data. Either in another RO region or just part of the text region if we don't care about read-only data having an executable property.
What has to be position-independent is the data/bss. Any access to such data needs to be relative to some runtime value per memory domain indicating the starting address of that library's data for the domain. We need to support multiple libraries in this way.

Shared libraries just don't work in this way.
What this does look sort of like is how thread-local storage works, where a register (or a segment descriptor on x86) is maintained representing a base address for the TLS, per thread. I'm thinking something along the lines of:

Implement generic TLS https://github.com/zephyrproject-rtos/zephyr/issues/22185
For each thread, the TLS area is some RAM carved out of the thread's stack.
Part of the TLS area is an offset table for each library that is in use. The layout of this table is fixed for each thread and has an entry for every shared library in use. Each table entry has the base linear address of where the data for the library begins. These all point to the same memory for threads in the same memory domain. Other, actual thread-local data like errno is also in TLS along side it. But these offset tables are copies of each other for every thread in the same domain.

To reference a library global, there would be a lookup in TLS of the base address of the library data. Then add the offset within the library data for that global to get that global's address in our memory domain.
No linker supports this AFAIK. I don't know if others have needed to solve similar problems, and if so what they came up with. More research is needed.

One of the problems with using actual shared libraries is that the compiler assumes a fixed offset to the GOT from the library program text. All GOT lookups are IP-relative. This works fine in Linux because everything just gets mapped in the process address space.
In zephyr, we would need a GOT for every memory domain. In a physical memory map, the memory for each GOT would be at a different linear address, and the fixed offset guarantee doesn't hold.
One idea is to have a fixed GOT location which gets updated on context switch to the incoming memory domain, a copy is made. This would solve accessing the GOT, but have its own complications:

Extra memory partition for the fixed global GOT. Maybe not so bad, we're saving many memory partitions by doing this for nontrivial applications.
Extra context switching overhead, although at least it's predictable
We still want all the library text/rodata to be contiguous with kernel/app text/rodata, so that we don't need extra MPU regions for each library to enable access. Very unsure if this is feasible.
This approach falls over on SMP, where different memory domains can be active on different CPUs. Starting to think this might be a dealbreaker.

Given a choice of "break SMP" or "break TLS" my preference still for the latter.

There is a third option: link in multiple copies of libraries per memory domain.
Pluses:

No funny tricks to get separate library data/bss per domain
No extra indirection layers, PIC, etc
Regular .a static libraries work
Tighter control of what memory domains use what libraries, as they are more like separate applications
Separately built applications are something that has come up in discussions from time to time for other reasons.

Minuses:

Multiple copies of almost the same program text, using up either RAM or flash space (depending on XIP)
For XIP systems, multiple copies of the data section, using up flash space
Zephyr will need to be built and linked in a fundamentally different way, with each memory domain representing some different linking step
Memory domains will be closely associated with the build and not the runtime constructions they are now

Another complication: given that debugging sessions are system-wide, how do we handle the address of various shared library symbols if they change depending on what thread is scheduled?
For the TLS approach, these are all treated as thread-local and I expect this will not complicate GDB too much since AFAIK GDB already understands TLS, although this needs further investigation.
For using actual shared libraries, I am not sure how this will work from a debugger perspective.
For multiple copies of static libraries, this will result in naming collisions at final linking time of the combined kernel image.

My thinking on this is converging towards the TLS-based approach being the most promising, despite its drawbacks; at least enough to put together a proof-of-concept. Regardless of method chosen, this will be optional, we'll still always support the current scheme of using a k_mem_partition for libary globals as a fallback.

Further thoughts on this and a proposal:

The first proposal, abusing TLS, is interesting but has serious caveats. It may be worth a proof-of-concept once we have a proper TLS implementation in place, but this is not a priority.
The second proposal, using real .so files I think may be very complicated to implement and maintain.
The third proposal, having multiple copies linked, ties into something that comes up in conversations from time to time to generally support a modular Zephyr build, where multiple logical applications built/linked separately are assembled into a final image. If we supported this kind of build, having separate library copies should be a straightforward extension.

I thought about why I was so keen on solving this problem in the first place, and it really boils down to the C library, particularly the heap:

minimal libc is normally free of globals EXCEPT when the malloc() heap is enabled, in which case it is global and placed in a z_malloc_partition.
newlib/newlib_nano have a bunch of globals, it's why we had to route libc.a or libc_nano.a into the z_libc_partition, presenting an opportunity for every thread in the system to interfere with each other. it also has a single global malloc() heap.

Taking the C library out of the picture makes this much less of a concern.
So this is what I propose to do:

We should scope out and work on a mechanism for modular Zephyr builds where each Zephyr application is built separately as this is another thing that is generally useful. Add "each application can specify its own set of static libraries" as one of the requirements.
Restrict the scope of other, more involved solutions to the C library ONLY, such that for any C library used:

We don't have multiple copies of its program text/rodata
the malloc() arena and any other process-global libc data are managed on a per-memory domain basis
z_libc_partition and z_malloc_partition that everyone currently has to share cease to exist

The picolibc PR (#26545) provides support for TLS using the -ftls=local-exec model. That depends on static linking all objects defining TLS variables as the total size of the TLS space must be known at link time. Picolibc uses TLS for most global variables, including errno and signgam. It does not (currently) place variables controlling the heap in TLS as it is expected that the heap will be shared across threads. It sounds like what we need is a per-domain heap, which would require modifying the malloc code in picolibc and then providing some mechanism to identify the current heap.
Supporting TLS with the minimal C library included in Zephyr would require copying the picolibc TLS support functions that initialize the TLS segment from ROM and the code that sets the TLS base address for architectures not already in-lining that.
Supporting TLS from newlib would be challenging; the per-thread data resides in a rather large struct as it contains every possible per-thread value, rather than being limited to those related to APIs used in the application. I'd say that scoping this issue to require libc TLS support would be a reasonable approach, given that there would be two available.

Using TLS (with compiler and arch support) is the least invasive. So opt for TLS approach unless the need for others arises.


nixos/sudo: default rule should be first

In /etc/sudoers, the last-matched rule will override all
previously-matched rules. Thus, make the default rule show up first (but
still allow some wiggle room for a user to mkBefore it), before any
user-defined rules.

Motivation for this change
Addresses #87555. I'll backport this to 20.03 after this gets merged (or whoever merges this can take care of that for me; I don't mind either way, but that might be easier than waiting for me to follow up).
Things done

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

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

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

@grahamcofborg test sudo

Could something be added to the test for this, say by setting extraRules to something that overrides the default and checking that sudo(1) behaves accordingly?

If somebody more familiar with sudo and its configuration would like to write that test case in a follow-up, I'd be delighted. I tried my hand at it and failed, but I'd like to get this merged sooner rather than later so as to resolve the linked issue.
Sorry it took me so long to get back to this.


Issue #85

@jessesquires thanks🙌 I made updates

Redid some wording, will take a look at the rest tomorrow!

Thanks @BasThomas ! I'll review again in the morning as well

Thanks @BasThomas !


Added German translations

I've added new files for German translations and translated their content.

Danke!


Change default value of checkpoint_completion_target to 0.9 for better performance?

The Postgre official document recommends to set checkpoint_completion_target to 0.9, which is the more useful value and improves the performance.
"You can spread those writes out further, lowering the average write overhead, by increasing the checkpoint_completion_target parameter to its useful maximum of 0.9 (aim to finish by the time 90% of the next checkpoint is here) rather than the default of 0.5 (aim to finish when the next one is 50% done).  ".
I wonder if the default need to be changed for performance concern. Thanks.

This have nothing to do with postgres_exporter.

Indeed, postgres_exporter shouldn't be writing anything (which is interesting, because you could probably abuse queries.yml to have it do this - please don't).


Deprecated dependencies in the foam_iu

Hi, jejomath!
We continue exploring your solution. Would you mind updating dependencies in the foam_iu part? It looks like you're using deprecated packages with some vulnerabilities (7 high ones).  You can check them with the npm audit command.
We suggest doing at least these changes because of the Babel lib deprecation:

change the "babel": "^6.23.0" to "@babel/core": "^7.22.5"
add the "@babel/plugin-proposal-private-property-in-object": "^7.22.5" in devDependencies section
and upgrade the version of other @babel libs to the "^7.22.5" to avoid inconsistency

Thank you in advance!
Regards,
Liubov

And one more thing: the foam pages-code command asked for js-beautify. Sounds like it worth to be declared in the package.json file


publish Meshery Connections and thier Actions table in docs ( /architecture )

Notes for Reviewers
This PR fixes #7179
Here's how the table looks:
https://user-images.githubusercontent.com/110674407/223898859-3c36f1ae-6a6c-4f2b-97e5-ec607ebf4942.mp4
Signed commits
Signed-off-by: Vivek Vishal<EMAIL_ADDRESS>
[ ] Yes, I signed my commits.

🚀 Preview for commit e3431b9b63033696e4945a5871d7c3cede37f3a9 at: https://6409561167c7085a7168ef81--meshery-docs-preview.netlify.app

@Azanul an accurate depiction?


Switch label tag is briefly highlighted when toggling the switch on Safari iPad2

which materialize-css version ?
I checked the switch on the actuall http://materializecss.com/forms.html and i workes like it should - no special highlighning ..
can you add a screenshot ?

Are we referring to the following issue (see the screenshot)
If I am quick with the mouse, I can highlight the floating label within the input field. (I can easily recreate this in the demo site http://materializecss.com/forms.html. Once I get the label to highlight, it does not float up even when the keyboard focus in on that input field. Ideally, the label should not be highlightable.

If this issue is not about this defect, then I will open a new one.

Im getting this too

It looks like CSS issue. You can reproduce it on desktop. Open Chrome (ver. 56 in my case).
Open http://materializecss.com/forms.html
Activate Dev Tool (F12)
Activate device toolbar to emulate mobile (Ctrl + Shift + M)
Click a switch


Error installing - not finding correct version (SPT)

I installed tarkov fresh, installed SPT, ran SPT-server, ran SPT-launcher, ran game, created profile ingame, then exited game and ran installer....
What did I do wrong?

nevermind!
I didnt realize - SPT installs a completely separate EFT.... (thats cool!)
I didnt pass it the path for SPT install - I passed it the official EFT install path...
(Good info for anyone as blind as me!) :)


Parameter analytics.disable not sticking

Description
Currently when passing analytics.disable via command line or applied via custom yml file, analytics.disable set to true does not stick. Workaround was applying it via kubectl edit configmap botkube-analytics-config -n botkube.
Expected behavior
analytics.disable should be set to true
Actual behavior
analytics.disable is false the default value

Hi @AliHas78,
I was able to successfully disable analytics with the following commands:
helm install botkube --version v0.13.0 botkube/botkube --namespace botkube --create-namespace -f /tmp/values.yaml

Where:
analytics:
   disable: true

And also
helm install botkube --version v0.13.0 botkube/botkube --namespace botkube --create-namespace --set analytics.disable=true

In both cases the analytics were properly disabled. Could you please elaborate a bit more about the issue?

@pkosiec I just tested trying to enable it using below command,
helm upgrade -f botkube-preset.yml --version v0.13.0 botkube --namespace botkube --create-namespace.
Where botkube-preset.yml:
analytics:
   disable: false

log -
 time="2022-09-22T15:50:14Z" level=info msg="Analytics disabled via configuration settings."
configmap shows botkube-analytics-config (which I set before as workaround)
apiVersion: v1
data:
  analytics.yaml: |
    analytics:
      disable: true

@AliHas78 Oh, I understand, so you encounter this issue when doing helm upgrade with different value. Fresh Installation works properly, as I tested all disable/enable scenarios.
I've just tested doing install, and then upgrade with different values. The new value is not taken into account indeed, so I confirm the bug.
It's because we have in the Helm template:
  {{- $previous := lookup "v1" "ConfigMap" .Release.Namespace $cfgMapName }}
  {{- if $previous }}
  analytics.yaml: |
    {{- index $previous.data "analytics.yaml" | nindent 4 }}
  {{- else }}
  analytics.yaml: |
    analytics:
      disable: {{ .Values.analytics.disable }}
      # anonymous unique UUID generated during chart installation
      installationID: "{{- uuidv4 -}}"
  {{ end }}

We just wanted to preserve the anonymous installationID. I'm sorry, that's a bug - I will resolve that tomorrow.
Thank you for pointing that out 👍

Hey @AliHas78, we decided to get rid of the installation ID in #759. So your issue will be resolved in the upcoming release (in a couple of weeks). Cheers!


sample.json for Multi Mnist?

Hi. thanks for sharing.
what is the structure for sample.json and config.json when I want to use code for multiMnist dataset?

How did you design the jsons for mnist?

This is the hyperparameter set we used:
optimizer=SGD|batch_size=256|lr=0.05|normalization_type=none
Json structure is:
{
    "optimizer": "SGD",
    "batch_size": 256,
    "lr": 0.05,
    "dataset": "mnist",
    "tasks": ["L", "R"],
    "normalization_type": "none",
    "algorithm": "mgda",
    "use_approximation": true,
    "scales": {"L":0.5, "R":0.5}
}


Add Plain Email to the list

Just adding Plain Email to the list! App available here: http://www.plainemail.com

Thanks!


Work around wildcard subdomain filtering bug in linode API

This is a temporary fix for #146.
The Linode API should be able to be queried for data about a wildcard subdomain by using the Domain Records List endpoint with the header x-filter: {"name": "*"} to filter the list of subdomains for the wildcard subdomain as part of the API call.
The API has a bug, though, specifically for the wildcard subdomain. The above query returns an empty list even when the wildcard subdomain exists. For GoDNS, this means a new wildcard subdomain is created every time the IP changes or the program is restarted because it can't find the existing wildcard subdomain.
This PR makes a small change: instead of asking for the API to filter the response, GoDNS instead asks for all subdomains and filters them itself.
I have an open ticket with Linode support about this. When Linode fixes the bug in the API we can revert this.

Thanks for your contribution.


Webhooks tracing

I want to merge this change because it adds tracing for webhooks (both sync and async).

Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations
[ ] Documentation needs to be updated

Pull Request Checklist

[ ] Privileged queries and mutations are guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migration files are up to date
[ ] The changes are tested
[ ] GraphQL schema and type definitions are up to date
[ ] Changes are mentioned in the changelog

Task linked: SALEOR-4612 Missing tracing on sync webhooks


Allow formatting PromQL expressions in the UI

Signed-off-by: Julius Volz<EMAIL_ADDRESS>Note 1: To be 100% correct & safe I would have to also make the text editor read-only (and visually clearly so) while a format request is in-flight, but I thought that would be over-engineering it for a request that should normally finish instantaneously.
Note 2: In the video below, I introduced an artificial 1-second delay for the request so that it's possible to see the loading behavior:
https://user-images.githubusercontent.com/538008/179986435-a57a0d2d-5d93-4fc7-912d-da753003f4b4.mp4

I like the icon selected by Julius.

Can it be something like PP which means pretty print?

I haven't seen such an icon around yet, but let me know if you see a better one. We could of course theoretically also create our own, but that seems like a disproportionate amount of effort. However, not sure if I like "PP". That is also not understandable unless you hover over it.

Let's go with the current icon :)

It would be, kinda. Is it worth it the extra complexity though to get that state from CodeMirror (not sure how to do it)?

you can do it by using the method diagnosticCount. If it is more than 0 then you the button can be blocked.

if the button is blocked I would need to explain to the user why (maybe change the title property)

Totally yes. The message can be simply : "unable to format an incorrect expression"

an advantage to block the button if the expression is not valid would be to not handle the http error, based on the fact if codemirror doesn't yell at you, then your expression is correct and the server will be ok

you can do it by using the method diagnosticCount. If it is more than 0 then you the button can be blocked.

Thanks! I managed to do that now, but it's a bit laggy because the linter only responds within a few milliseconds (the linter update is not yet available in the same updateListener callback call as the actual docs changes that precede it).

an advantage to block the button if the expression is not valid would be to not handle the http error.

IMO we should still always check those errors. There are other reasons why an API call may fail other than an invalid parameter, and who knows if the client-side checks really cover 100% of what we have in Go :)

@juliusv I tested your branch locally and it seems there is an issue with the event. It appears that once it is formatted, the icon doesn't come back to the original state when you change the expression.
https://user-images.githubusercontent.com/4548045/180214744-ed497cc3-392f-4b0c-a817-5dd113ff4134.mov

I also just realised that the button Execute that runs the query is not blocked when the codemirror linter is showing some errors.
So I would say to be consistent: We blocked this button as well when it displayed an error, or we don't block it.
By looking at the number of states of the format button, I would tend in favor of not blocking the button (even if I was proposing it initially).

@Nexucis Ah drat, I broke that by wrapping the if (exprFormatted) around the setExprFormatted(false). I think it's because the surrounding function is a stale closure wrapping the exprFormatted value from the first render of the overall React component, so it always is false.
So I can easily fix it by just removing the if condition and I could easily disable the execute button as well. But yeah, maybe it's better in the interest of simplicity to not block these buttons depending on linter state. So I remove that, yeah?

@roidelapluie Yup, removed it again!

Eh sorry, meant to tag @Nexucis.


Fix test code lens

Closes #5217
The implementation is quite similar to #4821. Maybe we should somehow deal with duplicated code.
Also, both of these requests introduce some unclear behavior. I'm not sure how to process this, therefore asking for advice. Examples are below.

I think the stuff about NavigationTarget is correct -- NavigationTarget contains both the full range and the focus range, and it should give the client maximal flexibility in terms of how use those ranges. I've tried to clarify the API here:
https://github.com/rust-analyzer/rust-analyzer/commit/d7548a36a7e814a165b05ffcb9ec5b55e0b291da
So, I think we rather should applix fix here:
https://github.com/rust-analyzer/rust-analyzer/blob/6ae6c1460e1e0524664af39fd0dbe3b1af3fac50/crates/rust-analyzer/src/handlers.rs#L877
we need to place the lens on the first line of runnable.

@matklad thank you for the explanation!
As I understand, here we can just replace focus_or_full_range() with full_range to achieve the desired behavior.
I'm not sure how should we handle this when two code lens expected to appear in one place if there is any such case.
Current implementation:

bors r+


Video upload - date and time

If i upload a video there should be the actual date and time under "recording metadata - start date". This is only working if i refresh the page.

I didn't notice that and uploaded a few videos. Now they have all the same time:

We think what's wrong is that we just set the time once instead of every time we open the dialog.


[turborepo] Using turbo prune via Dockerfile doesn't generate turbo out folder

What version of Turborepo are you using?
1.9.3
What package manager are you using / does the bug impact?
pnpm
What operating system are you using?
Mac
Describe the Bug
Hello,
I am in the process of migrating from Yarn to PNPM and have written a generic Dockerfile to reuse for Next.js applications. I am facing an issue when running the project via Docker, where the turbo out folder is not being generated. Based on my understanding, this should happen when we run the following command:
RUN turbo prune ${APP_NAME} --docker

ARG NODE=bitnami/node:20.9.0

FROM ${NODE} as builder
WORKDIR /app
ARG APP_NAME
COPY . .
RUN npm install -g pnpm
RUN npm install -g turbo
RUN echo $(turbo --version)
RUN turbo prune ${APP_NAME} --docker

FROM builder as installer
ARG CACHE_CLEAN=true
ARG APP_NAME
WORKDIR /app/apps/${APP_NAME}
COPY --from=builder /app/out/json/ .
COPY --from=builder /app/out/pnpm-lock.yaml ./pnpm-lock.yaml
RUN pnpm install && \
    if [ "$CACHE_CLEAN" = "true" ]; then pnpm store prune; fi
ENV PATH /app/apps/${APP_NAME}/node_modules/.bin:$PATH

# Build the project and its dependencies
COPY --from=builder /app/out/full/ .
COPY turbo.json turbo.json
ENV NEXT_TELEMETRY_DISABLED 1
RUN turbo run build --filter=${APP_NAME}...

FROM installer as production
ARG APP_NAME
ARG PORT
ENV NEXT_TELEMETRY_DISABLED 1
WORKDIR /app
ENV NODE_ENV=production

RUN addgroup --system --gid 1001 nodejs && \
    adduser --system --uid 1001 nextjs

COPY --from=installer /app/apps/${APP_NAME}/ ./
USER nextjs
EXPOSE ${PORT}
ENV PORT ${PORT}

CMD node --max-old-space-size=200 --optimize_for_size --gc_interval=100 server.js

For local development, I run it via docker-compose and pass the APP_NAME variable like this:
app-1:
    container_name: app1
    build:
      context: .
      dockerfile: ./tools/docker/nextjs/Dockerfile
      target: installer
      args:
        APP_NAME: app1
        PORT: 3000
        CACHE_CLEAN: "false"
    working_dir: /app
    restart: always
    environment:
      - NODE_ENV=development
    volumes:
      - .:/app
    ports:
      - "3000:3000"
    command: pnpm --filter app1 run dev

Here is my turbo.json configuration:
{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      "outputs": ["dist/**", ".next/**", "!.next/cache/**", "public/dist/**"],
      "dependsOn": ["^build"]
    },
    "test": {
      "outputs": ["coverage/**"],
      "dependsOn": []
    },
    "lint": {
      "dependsOn": ["^build"]
    },
    "dev": {
      "cache": false,
      "persistent": true
    },
    "clean": {
      "cache": false
    }
  }
}

Any help or guidance on resolving this issue would be greatly appreciated.
Expected Behavior
out folder should be generated on the root of monorepo
To Reproduce
Build the docker image and run the container.
Reproduction Repo
No response

Hi @erkand-imeri, did the issue only pop up once you switched from Yarn to PNPM?
Can you verify that /app/out isn't being populated at all by just checking it's existence right after the RUN turbo prune ${APP_NAME} --docker? If we're failing to populate it we should be producing some error text which would also be helpful to have.

Hey @erkand-imeri I tried to isolate this using our create-turbo starter, and with the following docker details:
Dockerfile:
ARG NODE=bitnami/node:20.9.0

FROM ${NODE} as builder
WORKDIR /app
ARG APP_NAME
COPY . .
RUN npm install -g pnpm
RUN npm install -g turbo
RUN echo $(turbo --version)
RUN turbo prune ${APP_NAME} --docker

Build the container:
docker build --build-arg APP_NAME=docs -t prune-test .

Running the container:
docker run -i -t prune-test /bin/bash

I see the out directory as expected:
root@97ddab231bef /app/out git:(main) ±4
ls
full  json  pnpm-lock.yaml  pnpm-workspace.yaml

Can you share the error you are getting? That might shed some additional light on where the problem is.

Hey thanks for the comments, my current Dockerfile looks like this
ARG NODE=bitnami/node:20.9.0

# BUILDER STAGE, TURBO DOCKER PRUNE
FROM ${NODE} as builder
LABEL version="1.0" maintainer="Back Office Customer Service"
WORKDIR /app
ARG APP_NAME
RUN npm install -g pnpm && \
    npm install -g turbo
COPY . .
RUN turbo prune ${APP_NAME} --docker

# INSTALL DEPENDENCIES STAGE
FROM builder as installer
ARG CACHE_CLEAN=true
ARG APP_NAME
WORKDIR /app
COPY --from=builder /app/out/json/ .
COPY --from=builder /app/out/pnpm-lock.yaml ./pnpm-lock.yaml
RUN pnpm --filter ${APP_NAME} install
# Build the project and its dependencies
COPY --from=builder /app/out/full/ .
COPY turbo.json turbo.json
RUN turbo run build --filter=${APP_NAME}

# PRODUCTION DEPLOYMENT STAGE
FROM ${NODE} as production_runner
ARG APP_NAME
ARG PORT
ENV NEXT_TELEMETRY_DISABLED 1
WORKDIR /app
ENV NODE_ENV=production

RUN addgroup --system --gid 1001 nodejs && \
    adduser --system --uid 1001 nextjs

# Copy only the necessary app files for runtime
COPY --from=installer /app/apps/${APP_NAME}/next.config.js ./
COPY --from=installer /app/apps/${APP_NAME}/package.json ./package.json
COPY --from=installer /app/apps/${APP_NAME}/.next/standalone ./
COPY --from=installer /app/apps/${APP_NAME}/.next/static ./

USER nextjs
# When using sidecar/istio-proxy you need to tweak --max-old-space-size and --gc_interval for optimal memory management, usually at the moment
# one istio-proxy is taking 150Mi, when cloudops allow us to create sidecar objects we need to define namespaces from whom we use service mesh,
# that will reduce the memory footprint of istio-proxy, since currently one pod app starts with 20-25Mi while one istio-proxy pod starts with 100-150Mi
# That 100-150Mi should be taken in consideration when defining K8 resource limits.
# Usually in node.js you define 70-80% of what resource memory limit you define in Kubernetes,
# but that's not the golden rule (tweak lower or higher values for optimal management), also substract 150Mi (istio-proxy memory) from that 70-80%.
CMD node --max-old-space-size=200 --optimize_for_size --gc_interval=100 server.js

but i am facing this error
Error: Cannot find module 'next/dist/server/next-server'
Require stack:
- /app/server.js
 at Module._resolveFilename (node:internal/modules/cjs/loader:1048:15)
 at Module._load (node:internal/modules/cjs/loader:901:27)
 at Module.require (node:internal/modules/cjs/loader:1115:19)
at require (node:internal/modules/helpers:130:18)
 at Object.<anonymous> (/app/server.js:2:20)
at Module._compile (node:internal/modules/cjs/loader:1241:14)
 at Module._extensions..js (node:internal/modules/cjs/loader:1295:10)
at Module.load (node:internal/modules/cjs/loader:1091:32)
 at Module._load (node:internal/modules/cjs/loader:938:12)
 at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:83:12) {
code: 'MODULE_NOT_FOUND',
requireStack: [ '/app/server.js' ]

Trying to figure out why is this the case, am i missing something when i copy the folders.
My .dockerignore looks like this
# Dependency directories
node_modules

# Log files
yarn-error.log
*.log

# Version control
.git

# System files
.DS_Store
Thumbs.db

# Editor directories
.idea/
.vscode/
*.sublime-workspace

# Build outputs
dist/
build/
out/
.coverage/

# Documentation & Tests
*.md
LICENSE
test/
tests/
__tests__/

# Environment configs
.env*
!.env.production

.pnpm-store

AFAIK, .next/standalone doesn't require anything, it bundles the Next.js app and makes it ready for running.

Ok, so if i add in production_runner stage
FROM ${NODE} as production_runner
ARG APP_NAME
ARG PORT
ENV NEXT_TELEMETRY_DISABLED 1
WORKDIR /app
ENV NODE_ENV=production

RUN addgroup --system --gid 1001 nodejs && \
    adduser --system --uid 1001 nextjs

# Copy only the necessary app files for runtime
COPY --from=installer /app/apps/${APP_NAME}/next.config.js ./
COPY --from=installer /app/apps/${APP_NAME}/package.json ./package.json
COPY --from=installer /app/apps/${APP_NAME}/.next/standalone ./
COPY --from=installer /app/apps/${APP_NAME}/.next/static ./
RUN npm install -g pnpm && pnpm install --prod

USER nextjs

CMD node --max-old-space-size=200 --optimize_for_size --gc_interval=100 server.js

RUN npm install -g pnpm && pnpm install --prod

It doesn't show the error, but yet nothing is up and running. IDK, something is wrong with the way production_runner copies the folders from installer, it doesn't sum it up. I guess i am missing something, also pnpm install shouldn't be necessary at all, but i added just for debugging purposes.

I am having a similar issues when I try to install using yarn 4.0.1. But I am missing next, and you next-server. Not sure if it is related.
2023-11-07 12:52:00 node:internal/modules/cjs/loader:1051
2023-11-07 12:52:00   throw err;
2023-11-07 12:52:00   ^
2023-11-07 12:52:00
2023-11-07 12:52:00 Error: Cannot find module 'next'
2023-11-07 12:52:00 Require stack:
2023-11-07 12:52:00 - /app/apps/pio-app/server.js
2023-11-07 12:52:00     at Module._resolveFilename (node:internal/modules/cjs/loader:1048:15)
2023-11-07 12:52:00     at Module._load (node:internal/modules/cjs/loader:901:27)
2023-11-07 12:52:00     at Module.require (node:internal/modules/cjs/loader:1115:19)
2023-11-07 12:52:00     at require (node:internal/modules/helpers:130:18)
2023-11-07 12:52:00     at Object.<anonymous> (/app/apps/pio-app/server.js:23:1)
2023-11-07 12:52:00     at Module._compile (node:internal/modules/cjs/loader:1241:14)
2023-11-07 12:52:00     at Module._extensions..js (node:internal/modules/cjs/loader:1295:10)
2023-11-07 12:52:00     at Module.load (node:internal/modules/cjs/loader:1091:32)
2023-11-07 12:52:00     at Module._load (node:internal/modules/cjs/loader:938:12)
2023-11-07 12:52:00     at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:83:12) {
2023-11-07 12:52:00   code: 'MODULE_NOT_FOUND',
2023-11-07 12:52:00   requireStack: [ '/app/apps/pio-app/server.js' ]
2023-11-07 12:52:00 }
2023-11-07 12:52:00
2023-11-07 12:52:00 Node.js v20.9.0

I have gotten it to work with pnpm, this might help you:
FROM node:20-alpine AS base

RUN npm install -g pnpm
RUN npm install -g turbo

FROM base AS builder
RUN apk add --no-cache libc6-compat
RUN apk update

# Set working directory
WORKDIR /app
COPY . .
RUN turbo prune @pio/app --docker

FROM base AS installer
RUN apk add --no-cache libc6-compat
RUN apk update
WORKDIR /app

COPY turbo.json turbo.json
COPY --from=builder /app/out/json/ .
COPY --from=builder /app/out/pnpm-lock.yaml ./pnpm-lock.yaml
RUN pnpm install

COPY --from=builder /app/out/full/ .
RUN turbo run build<EMAIL_ADDRESS>
FROM base AS runner
WORKDIR /app

ENV NODE_ENV production

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
USER nextjs

COPY --from=installer /app/apps/pio-app/next.config.js .
COPY --from=installer /app/apps/pio-app/package.json .

COPY --from=installer --chown=nextjs:nodejs /app/apps/pio-app/.next/standalone ./
COPY --from=installer --chown=nextjs:nodejs /app/apps/pio-app/.next/static ./apps/pio-app/.next/static
COPY --from=installer --chown=nextjs:nodejs /app/apps/pio-app/public ./apps/pio-app/public

EXPOSE 3000

ENV NEXT_TELEMETRY_DISABLED 1

CMD ["node", "apps/pio-app/server.js"]

Feels like turbo is not made for yarn berry,

Hey @wigsnes i will try your pnpm Dockerfile, thanks.
A question, why you prune @pio/app like this when your app folder name is apps/pio-app. Is there any labeling being done in pnpm-workspace.yaml?

@pio/app is the name in our package.json. I assumed it did not matter if you use the folder name or workspace name. I will check.

So, tried it and it didn't work for me, i get CrashLoopBackOff in pods.

Well, i could not make it work.
I have this error
Error: Cannot find module '/app/apps/app1/server.js'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1048:15)
    at Module._load (node:internal/modules/cjs/loader:901:27)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:83:12)
    at node:internal/main/run_main_module:23:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

@wigsnes can you show me what do you have in .dockerignore, do you put node_modules or no there?

My .dockerignore
node_modules
**/node_modules
.git
.gitignore
*.md
dist
out

do you see server.js in your folder?

My folder structure:
monorepo
    apps
        pio-app
            package.json with name @pio/app
    packages
    Dockerfile
    package.json
    .dockerignore

My pnpm-workspace.yaml file:
packages:
  - 'packages/*'
  - 'apps/*'

Here is my Dockerfile mimicking yours.
ARG NODE=bitnami/node:20.9.0

# BUILDER STAGE, TURBO DOCKER PRUNE
FROM ${NODE} as builder
LABEL version="1.0" maintainer="Back Office Customer Service"
WORKDIR /app
ARG APP_NAME
RUN npm install -g pnpm && \
    npm install -g turbo
COPY . .
RUN turbo prune ${APP_NAME} --docker

# INSTALL DEPENDENCIES STAGE
FROM builder as installer
ARG CACHE_CLEAN=true
ARG APP_NAME
WORKDIR /app

COPY turbo.json turbo.json
COPY --from=builder /app/out/json/ .
COPY --from=builder /app/out/pnpm-lock.yaml ./pnpm-lock.yaml
RUN pnpm install

COPY --from=builder /app/out/full/ .
RUN turbo run build --filter=${APP_NAME}

# PRODUCTION DEPLOYMENT STAGE
FROM installer as production_runner
ARG APP_NAME
ENV NEXT_TELEMETRY_DISABLED 1
WORKDIR /app
ENV NODE_ENV=production

RUN addgroup --system --gid 1001 nodejs && \
    adduser --system --uid 1001 nextjs

# Copy only the necessary app files for runtime
COPY --from=installer /app/apps/${APP_NAME}/next.config.js .
COPY --from=installer /app/apps/${APP_NAME}/package.json .
COPY --from=installer /app/apps/${APP_NAME}/.next/standalone ./
COPY --from=installer /app/apps/${APP_NAME}/.next/static ./apps/${APP_NAME}/.next/static

USER nextjs

CMD node --max-old-space-size=200 --optimize_for_size --gc_interval=100 apps/${APP_NAME}/server.js

.dockerignore
# Dependency directories
node_modules
**/node_modules

# Log files
yarn-error.log
*.log

# Version control
.git

# System files
.DS_Store
Thumbs.db

# Editor directories
.idea/
.vscode/
*.sublime-workspace

# Build outputs
dist/
build/
out/
.coverage/

# Documentation & Tests
*.md
LICENSE
test/
tests/
__tests__/

# Environment configs
.env*
!.env.production

.pnpm-store

monorepo
    apps
        app1
            package.json with name app1
    packages
        ui/
        types/
   tools/docker/nextjs/Dockerfile
    package.json
    .dockerignore
   pnpm-workspace.yaml

So, technically the same, but it fails. Interesting.

Do you see server.js in your files on docker when you run the app?

ok, I am a bit lost then. At what line does it crash?
My versions are:
"turbo": "^1.10.16",
"next": "^13.5.6",

Do you still have this error?

Error: Cannot find module '/app/apps/app1/server.js'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1048:15)
    at Module._load (node:internal/modules/cjs/loader:901:27)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:83:12)
    at node:internal/main/run_main_module:23:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

So, my version is
"turbo": "^1.9.3",
"next": "13.1.5",
For now, i decided to use this Dockerfile which works perfectly fine for now, and not utilizing turbo for building the app
# This is a generic Dockerfile for all apps which uses variable names and based on the execution context it takes the context of the apps
# APP_NAME and PORT locally are taken from docker-compose.yaml and in pipeline it's passed via the yaml file
# of the repository host/DevSecOps like Giltab with .gitlab-ci.yaml
ARG NODE=bitnami/node:20.9.0

# BUILDER STAGE
FROM ${NODE} as installer
LABEL version="1.0" maintainer="Back Office Customer Service"
WORKDIR /app
ARG APP_NAME
COPY apps/${APP_NAME}/ ./

COPY --from=builder /app/package.json ./package.json
# https://nextjs.org/docs/advanced-features/output-file-tracing
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

EXPOSE ${PORT}

ENV PORT ${PORT}

USER nextjs
# When using sidecar/istio-proxy you need to tweak --max-old-space-size and --gc_interval for optimal memory management, usually at the moment
# one istio-proxy is taking 150Mi, when cloudops allow us to create sidecar objects we need to define namespaces from whom we use service mesh,
# that will reduce the memory footprint of istio-proxy, since currently one pod app starts with 20-25Mi while one istio-proxy pod starts with 100-150Mi
# That 100-150Mi should be taken in consideration when defining K8 resource limits.
# Usually in node.js you define 70-80% of what resource memory limit you define in Kubernetes,
# but that's not the golden rule (tweak lower or higher values for optimal management), also substract 150Mi (istio-proxy memory) from that 70-80%.
CMD node --max-old-space-size=200 --optimize_for_size --gc_interval=100 server.js

hi,I was also trying to use pnpm+turbo+Nextjs and I also ran into this problem (server.js not found). I built it using the official example (yarn+turbo) and found that yarn can generate both server.js and standalone folders. But using pnpm does not.😥

hi,I was also trying to use pnpm+turbo+Nextjs and I also ran into this problem (server.js not found). I built it using the official example (yarn+turbo) and found that yarn can generate both server.js and standalone folders. But using pnpm does not.😥嗨，我也在尝试使用 pnpm+turbo+Nextjs，我也遇到了这个问题（找不到服务器.js）。我使用官方示例（yarn+turbo）构建了它，发现 yarn 可以生成服务器.js和独立文件夹。但是使用 pnpm 则不然。 😥

I'm using ：windows10

We ended up going back to using yarn
Dockerfile:
# Install dependencies only when needed
FROM node:20-alpine AS deps
ENV YARN_VERSION 4.0.2

RUN corepack enable && corepack prepare yarn@${YARN_VERSION}
...

We ended up going back to using yarn
Dockerfile:
# Install dependencies only when needed
FROM node:20-alpine AS deps
ENV YARN_VERSION 4.0.2

RUN corepack enable && corepack prepare yarn@${YARN_VERSION}
...

Here is my dockerfile if you need it, it will run successfully on windows🥰, but there may be some issues on mac.😥
This file is located under ./apps/blog
FROM node:20-alpine AS base
RUN corepack enable && corepack prepare pnpm@latest --activate
RUN npm i -g turbo

# -------------------------- stage builder ---------------------------------
# Add c library and update version
FROM base AS builder
RUN apk add --no-cache libc6-compat
RUN apk update

# Set working directory /app
WORKDIR /app
COPY . .
RUN turbo prune blog --docker

# -------------------------- stage installer ---------------------------------
# Add lockfile and package.json's of isolated subworkspace
FROM base AS installer
RUN apk add --no-cache libc6-compat
RUN apk update

WORKDIR /app
# First install the dependencies (as they change less often)
COPY --from=builder /app/out/json/ .
COPY --from=builder /app/out/pnpm-lock.yaml ./pnpm-lock.yaml
COPY --from=builder /app/out/pnpm-workspace.yaml ./pnpm-workspace.yaml

# Build the project
COPY --from=builder /app/out/full/ .
COPY turbo.json turbo.json
RUN pnpm install
RUN pnpm turbo build --filter=blog...

# -------------------------- stage runner ---------------------------------
FROM base AS runner
WORKDIR /app

# Don't run production as root
# 添加一个名为 nodejs 的系统用户组，gid 为 1001
RUN addgroup --system --gid 1001 nodejs
# 添加一个名为 nextjs 的系统用户,uid 为 1001
RUN adduser --system --uid 1001 nextjs
# 切换用户为 nextjs
USER nextjs

COPY --from=installer /app/apps/blog/next.config.js .
COPY --from=installer /app/apps/blog/package.json .

# Automatically leverage output traces to reduce image size
# https://nextjs.org/docs/advanced-features/output-file-tracing
COPY --from=installer --chown=nextjs:nodejs /app/apps/blog/.next/standalone ./
COPY --from=installer --chown=nextjs:nodejs /app/apps/blog/.next/static ./apps/blog/.next/static
COPY --from=installer --chown=nextjs:nodejs /app/apps/blog/public ./apps/blog/public

CMD node apps/blog/server.js

The file is located in the root directory(docker-compose.yml)
version: "3"

services:
  blog:
    container_name: blog
    build:
      context: .
      dockerfile: ./apps/blog/Dockerfile
    restart: always
    ports:
      - 3000:3000

I am facing a similar issue.
turbo prune --scope web --docker works perfectly fine, but attempting to run the same in the Dockerfile leads it to say that turbo.json does not exist.
Reproduction

Thankfully, because of this thread, I now have a working Dockerfile for a Turborepo using PNPM.
I ran into a few issues on the way:

Missing packages.
First time running pnpm install I got a bunch of errors, this was due to some node dependencies depending on Python.

- RUN apk add --no-cache libc6-compat
+ RUN apk add --no-cache libc6-compat python3 py3-pip make g++

Not copying over pnpm-workspace.yaml

COPY --from=builder /app/out/pnpm-lock.yaml ./pnpm-lock.yaml
+ COPY --from=builder /app/out/pnpm-workspace.yaml ./pnpm-workspace.yaml

Move the install below /out/full copy.
I got an error that I was missing a dependecy from an internal package my web app is using.

- RUN pnpm install
-
- COPY --from=builder /app/out/full/ .

+ COPY --from=builder /app/out/full/ .
+
+ RUN pnpm install

Next.config configuration
Make sure your next.config includes the standalone output:

// filename: next.config.mjs

/** @type {import('next').NextConfig} */
import path from 'path';
import { fileURLToPath } from 'url';

const __dirname = path.dirname(fileURLToPath(import.meta.url));

const nextConfig = {
+  output: 'standalone',
+  experimental: {
+   outputFileTracingRoot: path.join(__dirname, '../../'),
+  },
};

export default nextConfig;

Working Dockerfile
FROM node:20-alpine AS base

RUN corepack enable && corepack prepare pnpm@latest --activate
ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"
RUN pnpm add -g turbo@^2

FROM base AS builder
WORKDIR /app
COPY . .

# Generate a partial monorepo with a pruned lockfile for a target workspace.
RUN turbo prune customer --docker

# Add lockfile and package.json's of isolated subworkspace
FROM base AS installer
RUN apk add --no-cache libc6-compat python3 py3-pip make g++
RUN apk update

WORKDIR /app

# First install the dependencies (as they change less often)
COPY --from=builder /app/out/json/ .
COPY --from=builder /app/out/pnpm-lock.yaml ./pnpm-lock.yaml
COPY --from=builder /app/out/pnpm-workspace.yaml ./pnpm-workspace.yaml
COPY --from=builder /app/out/full/ .

RUN pnpm install
RUN pnpm turbo run build --filter=customer...

FROM base AS runner
WORKDIR /app

# Don't run production as root
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
USER nextjs

COPY --from=installer /app/apps/customer/next.config.mjs . #NOTE: I'm using `.mjs`
COPY --from=installer /app/apps/customer/package.json .

# Automatically leverage output traces to reduce image size
# https://nextjs.org/docs/advanced-features/output-file-tracing
COPY --from=installer --chown=nextjs:nodejs /app/apps/customer/.next/standalone ./
COPY --from=installer --chown=nextjs:nodejs /app/apps/customer/.next/static ./apps/customer/.next/static
COPY --from=installer --chown=nextjs:nodejs /app/apps/customer/public ./apps/customer/public

EXPOSE 3000

ENV PORT 3000
CMD HOSTNAME="<IP_ADDRESS>" node apps/customer/server.js

docker build -f apps/customer/Dockerfile -t customer .
docker run -it -p 3000:3000 customer

@einaralex your Dockerfile made mine at least build successfully 🎉
But dependencies in node_modules point to broken symlinks

Those pnpm folders does not exists

I manage to make it run adding prop-deps
+FROM installer AS prod-deps
+WORKDIR /app
+RUN --mount=type=cache,id=pnpm,target=/pnpm/store pnpm install --prod --frozen-lockfile

Then
-FROM base AS runner
+FROM base AS prod-runner

+COPY --from=prod-deps --chown=nextjs:nodejs /app/node_modules ./node_modules
+COPY --from=prod-deps --chown=nextjs:nodejs /app/apps/web/package.json ./apps/web/package.json


fixes #42594

Details

Fixed Issues
https://github.com/Expensify/App/issues/42594
https://github.com/Expensify/App/issues/42594#issuecomment-2130764038
Tests

QA Steps

I have read the CLA Document and I hereby sign the CLA


Question: How to set background color of content(scroll area)

Hi,
When the snapPoint is larger than the height of content,
there's some remain area and that color is transparent.
How can I set background color of content area?

height: '100%' worked for me

Thanks. I just figured out the height does not work properly in a SafeAreaView. I had to switch to a normal view


Provide the option to save failed iOS screenshots to option with flagged name

Hi there,
we are using the snapshot library on our Azure Pipeline and want to get a failed comparison against an existing reference to be written out as Pipeline Artifact.
However, I haven't seen any option to do so. The newly taken screenshot is saved on that simulator device which in azure is not accessible after the job run. Therefore, we have no access to the newly taken screenshot and cannot analyze the differences. With the provided reference images it is no issue, as the worker's path is easily accessible and can be published to the Artifacts store.
Would you mind giving us a hint on how to get the comparison file/report out of the device, please? The assertion messages written to the azure CLI are also less informative than in XCode.
Best wishes,
Martin

You can use xcparse (https://github.com/ChargePoint/xcparse) to extract the image from the xcresult. I’ve used it to upload the diff as artifacts in gitlab ci if tests failed.

Would you mind providing me an example of your command for extracting the xcresults, please?

If someone is also wondering where the xcresults bundle is stored in an Azure Pipeline, please have a look at my comment here:
https://github.com/ChargePoint/xcparse/issues/71#issuecomment-995899727

Just wanted to share in case someone is using fastlane, just provide the parameter 'result_bundle: true' to the run_tests command (https://docs.fastlane.tools/actions/scan/) and then from a Makefile (or possibly a bash script) you can do something like this:
bundle exec fastlane test && \
		echo "success!" || \
		{ \
			echo "failure!"; \
			mint run ChargePoint/xcparse xcparse attachments test_output/TeufelStreaming\ iOS.xcresult test_output/artifacts --uti public.plain-text public.image; \
			exit 1; \
		}

(Using Mintfile with reference to ChargePoint/xcparse@2.2.1).


Support AD-UserStore

There should be a possibility to connect ArcGIS Enterprise with an Active Directory in an automated way.

Closed #42 via #45


dont hash timestamps

if you e.g. do the same merge twice on two separate machines, the hashes should match
basicalliy dont put timestamps in the graph

Where are the timestamps being kept?
On Jun 12, 2015 7:31 PM, "maxogden"<EMAIL_ADDRESS>wrote:

if you e.g. do the same merge twice on two separate machines, the hashes
should match
basicalliy dont put timestamps in the graph
—
Reply to this email directly or view it on GitHub
https://github.com/maxogden/dat-core/issues/24.

@ekg right now they are in the graph nodes but we're just gonna put them in a local meta sublevel so they don't break hashing.

Cool I get it. Funny how quickly decisions like that make themselves heard.
On Jun 12, 2015 11:04 PM, "Mathias Buus"<EMAIL_ADDRESS>wrote:

@ekg https://github.com/ekg right now they are in the graph nodes but
we're just gonna put them in a local meta sublevel so they don't break
hashing.
—
Reply to this email directly or view it on GitHub
https://github.com/maxogden/dat-core/issues/24#issuecomment-111629822.

nice catch

Fixing this raises an message, author, and timestamp seem like metadata of the commit

Fixing this reopens another issue. Now timestamps won't match at all and will become local, i.e., not part of the commit. This means:
user1: dat import on June 24, 2015
-- timestamp created at abcdef
user2: dat pull from user1 on December 1st, 2016
-- user2 will see user1's import with a timestamp of December 1st, 2016
This is confusing and we lose information about the original commit. By having timestamps local, however, that means that dat will create the same hash if the same data is imported on different machines (with no message or author data). I can imagine some use cases without messages/authors/timestamps in the graph, where they could take advantage of merge strategies on different machines creating the same hashes. But in the open gov and data science use cases, having bad timestamps would be a disaster.
Although not ideal, it seems like fields like message, author, and timestamp should be hashed along in the commit. These values would change with almost every operation every time, and so a fork would be created if the exact same merge or import operation is performed on two different machines.
I'd vote having all data in the graph, but if you want to be secret/privacy saavy you could not use those options. @mafintosh says it could just 0 all timestamps in the consistent hashing option. -- i.e. it would not have timestamps basically

OK we decided in IRC to revert this feature for now.
The reason is that we want to still support showing 'original timestamps' in the UI, and the graph isn't flexible enough at the moment to replicate metadata like that. it's easier if we just hash everything, replicate original timestamps, and deal with the extra merges that will happen as a result.


fix: description and hint of Learn Accessibility by Building a Quiz - Step 41

Checklist:

[x] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #49521

I have made the changes in all the hints, please verify.


Weekly update for 2015-08-14

https://github.com/nodejs/evangelism/pull/137/files

https://medium.com/node-js-javascript/io-js-and-node-js-news-august-14th-c712ff526488


Release 1.1.0

Tests and Travis!
Python 3!
CAS V3 support

This looks great. Can't wait to see it released. Is there anything I can do to help this move along?

My plan is for this week.  I've been testing this internally but could any additional testing would be appreciated!

I don't know if this matters or not, but the README seems to leave out a few steps on setup. There isn't a mention of the AUTHENTICATION_BACKEND settings being set or the urls.py file being updated. Unless I'm missing something, both of those seem to be required.

@chadgh Thanks.  I'll get the README updated and we should be good to release this week.


Does this model generalize to other scenarios?

Great work! Thanks to open source！
Does this model generalize to other scenarios? How does it work in third person perspective scenarios?
THX～

Thank you!
The model and scripts trained with COIN (third-person data) streaming dialogue is not allowed to release due to some company policies. Current model is only trained on ego data, thus I guess it may not work so well on third-person perspective.
But once you have third-person view data to train, I believe it can generalize.

Thank you! Data is a big problem. Are there any plans to open source COIN data or models? Are there any methods or suggestions on how to construct training data using the third person perspective?

Thank you. Data construction for 3rd view is the same as the method for first view. You can refer to Section 3.2 in our paper. The corresponding code is also open sourced: https://github.com/showlab/videollm-online/blob/main/data/livechat/ego4d_goalstep_livechat_generation.py. I will write an instruction for that recently.

Thank you. I'll read it.

Close this issue. Feel free to reopen.


Help user attempting to create account where an email address associated with a never activated account is used

At present if a user signs up for a HydroShare account, but never clicks on the link in confirmation email to activate their account, the email address used is blocked from being used to create an account.  If they attempt to create an account again with that email, they get the message “Email already in use“, with no option to do anything.  I think we need a more friendly way to help them create an account.
I suggest, when an account request is received, check if the email address matches an existing never activated account.  If it does match, instead give a message “An account with the email address [insert email address] is pending activation. To activate this account you should click on the link in the email entitled "Activate your account in HydroShare" you should have received.  If you did not receive this email check your spam folder”.  Also present a  link/button “ Resend activation email”.
Note that these suggestions only apply to the case where email addresses match.  There are three cases related to user name to consider

If a username matches an existing active account then the new account request should be blocked (as it now correctly is).
If a username matches an existing never activated account but with a different email address, then the never activated account should be regarded as being reserved for the different request with different email, so account creation should also be blocked.
If a username matches an existing never activated account and the email also matches, this is regarded as a request from the same user (email address is a verifiable identifier) so the behavior should be as described above for matching email.

Implementation that first checks for matching email address may be easiest to account for these cases.

Resolved in 1.15 release so closing.


Legacy Monsters Imported Twice

Describe the bug
When running the DDB Monster Muncher, the importer will import new instances of creatures appended with the (Legacy) trait when the muncher is run multiple times.
To Reproduce
Steps to reproduce the behavior:

Go to the DBB Muncher.
Apply the settings in the screenshots below.
Run the importer multiple times.

Screenshots

Environment:

Browser Chrome, Firefox
Foundry Version [e.g. 10.291]
5e System Version [e.g 2.1.2]
Module Version [e.g 3.3.2]
Does this behavior occur with other modules disabled: Yes

Fixed in v3.3.3


DEPRECATION: Overriding init without calling this._super is deprecated.

DEPRECATION: Overriding init without calling this._super is deprecated. Please call `this._super.init && this._super.init.apply(this, arguments);` addon: `ember-cli-htmlbars`
    at Function.Addon.lookup (/Users/dillonwelch/Code/Work/currica/nsqip-web-ember/node_modules/ember-cli/lib/models/addon.js:896:27)

ember-simple-select 0.6.0 has ember-cli-htmlbars 0.7.9 as dependency, which is causing this deprecation warning. Updating ember-cli-htmlbars to 1.x fixes this issue. Was already done by 3832bf8d30010f2fdd6f2dfd4ca63331fa2451c5. Could you please release a patch version therefore?

Is it possible to release perhaps a 0.6.1 version of this?

Done!
That should not have taken so long. Please accept our apologies.


Add command to review filtered topics

Description
Corresponding PR: https://github.com/dockstore/dockstore-deploy/pull/808
This PR modifies the generate-topics command so that it writes filtered topics to a separate file, which is uploaded to S3. This makes it easier to review filtered topics.
This PR adds a --review flag to the upload-topics command that prints out each filtered topic and asks the user if it should be uploaded to Dockstore. There is a script that helps the user call this command. The output looks like the following:
Review the following topic for TRS ID #workflow/github.com/talkowski-lab/variant-interpretation/relatedness-hail and version eren_vep:
The workflow imports necessary WDL files, defines runtime attributes, and performs tasks such as subsetting VCFs, merging VCFs, imputing sex, checking relatedness, and plotting relatedness, with the output files including the merged VCF file, sex QC plots, relatedness QC, kinship TSV, and relatedness plot.

Do you approve the topic for upload to Dockstore? y/n [enter]:

Proposed flow:

The topics generator scheduled task runs. If there are filtered topics, a file is generated and uploaded to S3 (along with the generated-topics file of the unfiltered ones)
A CloudWatch alarm goes off and notifies Slack that there were filtered topics
The community lead goes to S3 to find the filtered topics CSV file and copies the S3 URI. Alternatively, they can go to the log stream in the topic-updater.log log group and see the logging message of the S3 upload, which contains the S3 URI of the filtered topics file.
The community lead opens CloudShell, sets up their topic-generator.config and calls the helper script which gets and invokes the topic generator JAR so that they can review each topic and approve them

If a topic is approved, it is uploaded to Dockstore. If it's disapproved, nothing happens. This means that this workflow will continue to get topics generated for it and may trigger the alarm every night if we keep disapproving it. I don't think this is very likely and might be overkill at this point so I didn't address it.
If approved, I will write a playbook that is very similar to the steps outlined above for community leads to follow.
Review Instructions
Follow the playbook to review filtered topics.
Issue
SEAB-6736
Security
If there are any concerns that require extra attention from the security team, highlight them here.
Please make sure that you've checked the following before submitting your pull request. Thanks!

[x] Check that you pass the basic style checks and unit tests by running mvn clean install in the project that you have modified (until https://ucsc-cgl.atlassian.net/browse/SEAB-5300 adds multi-module support properly)
[x] Ensure that the PR targets the correct branch. Check the milestone or fix version of the ticket.
[x] If you are changing dependencies, check with dependabot to ensure you are not introducing new high/critical vulnerabilities
[x] If this PR is for a user-facing feature, create and link a documentation ticket for this feature (usually in the same milestone as the linked issue). Style points if you create a documentation PR directly and link that instead.

I don't understand the flow entirely, but does anything prevent an obscene topic from getting repeatedly generated?
1. A genuinely obscene topic is generated for a workflow

2. The reviewer answers `n` when the approval question comes up

3. Next day, the generator runs again for the same workflow, since it has no topic, and a genuinely obscene topic is generated again. I gather the output is not deterministic, but if the source has something obscene it, it seems possible...

4. An alert fires every day for that workflow's topic...

This may come up so infrequently that it may not matter and I don't know what the solution is (or maybe there is one and I overlooked it), but just raising it for consideration.

Yeah that is a concern I have as well, but not sure if it's worth addressing right now. A simple way to address it is to upload an "empty" AI topic for the entry with an obscene topic so that it doesn't get re-generated the next time the topic updater runs.
If we're okay with that, I can add that in this PR.

Yeah that is a concern I have as well, but not sure if it's worth addressing right now. A simple way to address it is to upload an "empty" AI topic for the entry with an obscene topic so that it doesn't get re-generated the next time the topic updater runs.
If we're okay with that, I can add that in this PR.

I only mentioned it so as to think about it. I think the PR is fine as is. If it actually becomes an issue in prod, we could tweak this code fairly easily, as it's not tied to the hotfix release/deploy schedule that other parts of the stack are.

Realized I forgot to request reviews for the dockstore-deploy PR https://github.com/dockstore/dockstore-deploy/pull/808 which may have made the flow unclear


Access denied after initializing bptf listing on startup

I keep getting this error when I try to start up the bot. I have tried starting it both with and without the BPTF Access Token and API key. Doesn't work either way, though the error appears slightly different. Here it is with the token and key:
2020-04-01 22:45:37 info: Initializing bptf-listings...
Unhandled rejection Error: Access Denied
at SteamCommunity. (C:\Users\danma\Desktop\tf2-automatic\node_modules\steamcommunity\components\webapi.js:15:20)
at Request._callback (C:\Users\danma\Desktop\tf2-automatic\node_modules\steamcommunity\components\http.js:67:15)
at Request.self.callback (C:\Users\danma\Desktop\tf2-automatic\node_modules\request\request.js:185:22)
at Request.emit (events.js:305:20)
at Request. (C:\Users\danma\Desktop\tf2-automatic\node_modules\request\request.js:1161:10)
at Request.emit (events.js:305:20)
at Gunzip. (C:\Users\danma\Desktop\tf2-automatic\node_modules\request\request.js:1083:12)
at Object.onceWrapper (events.js:411:28)
at Gunzip.emit (events.js:317:22)
at endReadableNT (_stream_readable.js:1215:12)
at processTicksAndRejections (internal/process/task_queues.js:84:21)
2020-04-01 22:45:40 info: Getting Steam API key...
2020-04-01 22:45:41 error: tf2-automatic failed to start properly, this is most likely a temporary error. See the log:
package.version: 3.3.10; node: v13.5.0 win32 x64}
Stack trace:
Error: Access Denied
at SteamCommunity. (C:\Users\danma\Desktop\tf2-automatic\node_modules\steamcommunity\components\webapi.js:15:20)
at Request._callback (C:\Users\danma\Desktop\tf2-automatic\node_modules\steamcommunity\components\http.js:67:15)
at Request.self.callback (C:\Users\danma\Desktop\tf2-automatic\node_modules\request\request.js:185:22)
at Request.emit (events.js:305:20)
at Request. (C:\Users\danma\Desktop\tf2-automatic\node_modules\request\request.js:1161:10)
at Request.emit (events.js:305:20)
at Gunzip. (C:\Users\danma\Desktop\tf2-automatic\node_modules\request\request.js:1083:12)
at Object.onceWrapper (events.js:411:28)
at Gunzip.emit (events.js:317:22)
at endReadableNT (_stream_readable.js:1215:12)
at processTicksAndRejections (internal/process/task_queues.js:84:21)
Any help would be great

Please join tf2-automatic discord server and search "access denied". You'll find the answer for that problem.
https://discord.tf2automatic.com/

If i recall correctly this is because the account is not premium, meaning that the account has not spent at least $5 on Steam.

@aethezxd Is correct. That is the cause of Access Denied.
In future please join tf2-automatic discord server and search for your problem before creating an issue. You'll find an answer for 99% of problems and save yourself time waiting for a reply.
https://discord.tf2automatic.com/
-closing-


Optimize Range's include? method for numeric values

This is a small optimization for Range#include? when operating on numeric values. Previously, the method would iterate over all values from begin to end and compare them to the argument. Thankfully, the Ruby spec allows us to implement this as equivalent to Range#cover? for numbers. In other words, we're able to simply do arg >= begin && arg <= end, which is a lot faster :) This PR also goes a little further and optimizes for fast integers whenever possible

This is really nice!
One thing: this doesn't handle the case of the triple dots, e.g. 1...10, which is exclusive of the 10. You'll need to check m_exclude_end to handle that.
Oh, and we'll need a test to prove that was broken. 😉

Good catch! Should be updated now (with the accompanying test)


Check that index arguments to slice are in-bounds

If the indices were out of bounds, an exception would eventually be thrown but
it would fail on the first index out of bounds, giving a mis-leading message.
Checking at the beginning of the method means the error message can be
more useful.
For example, the following code:
Matrix someMatrix = ... // 10 x 10
someMatrix = someMatrix.slice(0, 0, 15, 15);

would give IndexOutOfBoundsException: 10 despite 10 not being an argument to the method.
With this change, the user will get IllegalArgumentException: Bad row argument 15; out of bounds immediately after invocation.

Whoops, it looks like some of the tests didn't expect this behavior. Working on fixing them now. :)

Scratch that, the tests were fine but I made a silly mistake. :)

Sweet! Thanks @thomas4g!


nzAutosize do not work correctly in td of nz-table

Reproduction link
https://stackblitz.com/edit/angular-dv6fvg-rch6hy?file=src/app/app.component.ts
Steps to reproduce
1.create a table/nz-table with tds
2.put a textarea with nzAutosize  in any of  the tds
3.paste some text in the textarea
4.if scroll not show paste again
5.try a few times until it shows
What is expected?
a autosized textarea with correct height and no scroll
What is actually happening?
sometimes the scroll shows

Environment
Info

ng-zorro-antd
8.5.1

Browser
chrome

it works outside a table

This issue has been closed due to inactivity.
Please file a new issue or discussion if you are encountering a similar or related problem.


Profane Ascension get dispelled

After the fight with Baphomet profane ascension got dispelled I believe it is a bug related to TTT? I'm using the latest TTT 1.6.1.
Thanks!

That should be impossible... Profane Ascension is a feature not a buff so should not be subject to dispel. I also did not touch it :(

It's removed if you fight against the commands of Nocticula and win. You can't disobey her and keep it.

Oh ic thanks for the information!


Add const to cripts formatter format functions

This is needed to support newer libfmt

Cherry-picked to v10.0.x


Support dense tensors in _SequenceNumericColumn

Resolves https://github.com/tensorflow/tensorflow/issues/20478
To Do:

[ ] Add unit tests

Will do :+1:

It has been 14 days with no activity and the awaiting response label was assigned. Is this PR still valid? Assigning the stalled label. Please comment to reassure me that this is still being worked on.

Closing. We switched away from feature columns.


Input custom vocabulary during inference

Question
The lexicon-based beam search decoder currently has a fixed lexicon and thus a closed set of words that an ASR model can recognise. Is there a way to input a list of additional words/phrases during inference such that these are better recognised by the ASR model? These words/phrases could potentially be out of vocabulary. Is there perhaps a way to boost the language model scores of such words/phrases?
@tlikhomanenko

Can you explain a bit more what you mean ? You can add more phrases to your lexicon before decoding and you could boost their them by using a language model where they are overrepresented. (e.g. by adding them multiple times to the text you are making the language model on)

@joazoa One step would definitely be adding these words to the lexicon at runtime, if they are out of vocabulary. For the next step, we would need a way to boost the language model scores of these words at runtime. Is there a way to do that without re-training the language model along with the original training corpus?

I think you can, but i don't think it will be fast enough.
https://github.com/danpovey/pocolm/blob/master/docs/motivation.md
https://github.com/kpu/kenlm/issues/98
SRILM also has something for it.


Adds [unit] and [unitDisplay] to NumberFormatOptions

Fixes #38012.
Adds the unit and unitDisplay option to NumberFormatOptions in src/lib/es5.d.ts

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: obber sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

This PR is perfectly fine, but while you're at it would be nice to get notation in there too :)

Notation is covered in https://github.com/microsoft/TypeScript/pull/37721

Yo @sandersn, any chance we'd be able to sneak this in before beta release in addition to #38013?
I think this needs to be updated to go in es2020.intl.d.ts same as that other PR

I'll move this over to es2020.int.d.ts

What's going on with this? I'm using Typescript 4.1.3 and still getting an error Argument of type '{ style: string; unit: string; }' is not assignable to parameter of type 'NumberFormatOptions'.   Object literal may only specify known properties, and 'unit' does not exist in type 'NumberFormatOptions'.