Document Out of Band release procedures

Write a document that includes the procedures and expectations for Out of Band (OOB) releases. Break this down by role, such as responsibilities for Helm Yes! engineer, code owner, project manager, etc.
SURE-5362

@PennyScissors , where are the documents we need to review?

@MKlimuszka This was completed a while ago as part of the series of KTs we did for the MApps team

The transition to the Mappsteam is complete, and all hand offs have been finished. Marking as complete.


[Watch Video] Daniel Marques Viral Video

In this post, we delve into the viral video by Daniel Marques that has captured the attention of the internet. After uploading a video of herself in a Spider-Man costume, Daniel Marques quickly became an online sensation. The video, which showcases her posing in various creative ways, rapidly spread across social media platforms like Twitter and Reddit, becoming a hot topic of discussion.
WATCH VIDEO: https://bit.ly/3w1OE7x
The Viral Daniel Marques Spider-Man Video
Daniel Marques’s Spider-Man costume video first gained traction on TikTok before spreading to other platforms. Its creative and unique approach made it stand out, and it didn’t take long for it to go viral. The video has made a lasting impression on viewers and continues to circulate online, attracting both curiosity and admiration.
Daniel Marques: A Rising Online Influencer
Known for her engaging and exciting content, Daniel Marques is steadily rising as a notable online influencer. The viral Spider-Man video is just one example of her creative output, and it has sparked widespread interest across various social media platforms. The video even prompted searches on the Tubi channel, though viewers discovered that the related content was a 2022 movie titled Spider, rather than Marques’s viral clip.
Reactions and Discussions on Social Media
The Spider-Man video has generated significant discussion online, particularly within the Reddit community. Many users praised Marques’s creativity, while others expressed discomfort, finding the video explicit or provocative. The video has also been shared on OnlyFans, where it continues to garner attention, contributing to the ongoing dialogue about her content.
The Impact of the Spider-Man Video
In the fast-paced world of social media, viral content can spread like wildfire, and Daniel Marques’s video is no exception. While some praised the video for its originality, others were quick to criticize it. The debate reflects the broader trend of how quickly content, especially those considered controversial, can gain traction online.
Who is Daniel Marques?
Daniel Marques is a digital star known for her distinctive and creative videos, including the now-famous Spider-Man clip. Her content often showcases her artistic abilities and adaptability, earning her a growing following on platforms like Reddit and Twitter.


RFC: Expand ADC API to support batch_mode sampling

Introduction
This RFC entails expanding the ADC API with support for batch_sampling sampling. This will allow a driver to, for example, sample an ADC continiously using a DMA and a circular buffer without ever triggering an interrupt a large amount of samples continiously using extra_samples and then only generate a single interrupt. This allows a driver to optionally offload more processing to the silicon if possible, f.i. using a DMA.
Initially mentioned in https://github.com/zephyrproject-rtos/zephyr/issues/39640. I'm creating a new issue as that discussion seems to be more driver specific and includes DMA changes. This RFC is purely for the ADC API.
Problem description
In time constraint scenarios where the MCU needs to take high frequency ADC readings it's benificial to offload as much processing to the silicon as possible, instead of handling the data through code and interrupts.
The ideal solution is to allow the ADC to sample continously, and the DMA continuously places new samples into a circular buffer, without the need of interrupts or polling. The sampling is completely handled by the silicon. This will be hard to implement with the current infrastructure, but a balance can be found by allow the DMA to sample 1 + extra_samples samples continuously, all with a DMA if possible, and only raise a single callback after it's done.
In our use-case we have a STM32H7 that needs to sample 16 channels at 100Hz on two ADCs. The addition of sampling multiple channels (https://github.com/zephyrproject-rtos/zephyr/pull/53534) along with DMA support (https://github.com/zephyrproject-rtos/zephyr/pull/52965) already improves this. But it's still interrupt based and creates way too many interrupts, about 200 per second, which is causing many stability issues. This proposed change would allow us to expand the ADC driver to remove all these interrupts, except one, without reducing the amount of samples.
This additional will cause minimal change to existing drivers.
Proposed change
Expand the existing ADC API to support continous sampling. The actual implementation will be driver dependent and is not part of this RFC.
Detailed RFC
Proposed change (Detailed)

Edit: Updated proposed solution as mentioned in https://github.com/zephyrproject-rtos/zephyr/issues/55783#issuecomment-1471562281.
/**
 * Sets ADC reading in batch_mode mode
 * The driver will complete reading of all channels and sample required extra_samples
 * in one shot, and only afterwards call the callback.
 * The driver will attempt to offload as processing to the silicon as possible.
 * For example, if coupled with DMA, this entire read sequence can be completed
 * without any interrupts, meaning context changes, except for when it's completed.
 */
 bool batch_mode;

This can then be called in sync or async mode as the normal read, and will act accordingly. The adc_context will have to modified slightly to not call callbacks until the all samples has been taken if this option is enabled. The actual implementation of this is ofloaded to the driver, and can function without DMA to remain portable.
When implemented in STM32 with DMA: The DMA will not be set in circular buffer mode, but rather have a buffer of length 1 + extra_samples, and attempt to fill it. It will only raise an ISR when this buffer is full, which will then call adc_context, which will raise the callback.
Alternative naming suggestion of bool one_shot, but I prefer continuous.
Pros:

The buffer will be safe to use after a read until the user explicitly starts a new read.
Devices with different ADCs of varying capability can handle each case correctly internally.
Portable, as the driver can choose to implement it in any way.
Existing drivers will still function normally, as the main change is made in adc_context. A driver can optionally add additional functionality to offload more processing to the silicon.

Cons:

First, the API needs a way to start a continuous read. My first thought was to expand adc_sequence_options with a bool continuous variable. However, this might not be a good solution, because then it can theorically be used with both adc_read and adc_read_async, which would not make sense. Continuous mode would always be async. It will also mean the bool can be set on a driver which does not implement it yet, without letting the user know.
A better solution would be to a dedicated function:
/**
 * @brief Start a continuous ADC read.
 *
 * @note This function is available only if @kconfig{CONFIG_ADC_CONTINUOUS}
 * is selected.
 *
 * @note This function does not support callbacks, or a given interval.
 *
 * @param dev       Pointer to the device structure for the driver instance.
 * @param sequence  Structure specifying requested sequence of samplings.
 *
 * @returns 0 on success, negative error code otherwise.
 *          See adc_read() for a list of possible error codes.
 *
 */
__syscall int adc_read_continuous(const struct device *dev,
			     const struct adc_sequence *sequence);

#ifdef CONFIG_ADC_CONTINUOUS
static inline int z_impl_adc_read_continuous(const struct device *dev,
					const struct adc_sequence *sequence)
{
	const struct adc_driver_api *api =
				(const struct adc_driver_api *)dev->api;

	return api->read_continuous(dev, sequence);
}
#endif /* CONFIG_ADC_CONTINUOUS */

This is better because:

It which will follow the convention used by existing and similar adc_read_async.
This means that if the function is called on a driver which it's not implemented on yet it will cause a linker error, instead of undefined behaviour.
The execution of a continiuous read will be vary significantly from adc_read and adc_read_async, because it won't need adc_context, which means a seperate function will be more intuitive.

This means a new kconfig value will be introduced, something this is adc/kconfig:
config ADC_CONTINUOUS
	bool "Continuous sampling support"
	help
	  This option enables the continuous ADC sampling.

The driver would also need some way to stop the continuous sampling.
__syscall int adc_stop_continuous_read(const struct device *dev);

#ifdef CONFIG_ADC_CONTINUOUS
static inline int z_impl_adc_stop_continuous_read(const struct device *dev)
{
	const struct adc_driver_api *api =
				(const struct adc_driver_api *)dev->api;

	return api->stop_continuous_read(dev);
}
#endif /* CONFIG_ADC_CONTINUOUS */

The circular buffer size can be set to hold 1 + extra_samples samples. It's up to the caller to provide this buffer through the existing adc_sequence.buffer.
The adc_context does not have to be changed, because it will not be used. It's main purpose is managing callbacks and the order of samples. This RFC does not use callbacks, and the sampling is explicitly handled by the silicon.
Dependencies
This change will not affect existing drivers. Drivers will need to add explicit support for it to function.
Concerns and Unresolved Questions

Should CONFIG_ADC_CONTINUOUS depend on CONFIG_DMA? Are there boards where DMA is not required for continuous sampling? Ideally this should be board specific, but I don't see how a board specific kconfig value could force CONFIG_ADC_CONTINUOUS=n if CONFIG_DMA=n for example.
The adc_stop_continuous_read could be be made more generic, as in adc_stop_read and possibly allow stopping an ongoing adc_read_async. However, I do not think this is the right direction.
In #39640 they wanted to add a callback on DMA buffer half-full, and this RFC currently doesn't include supporting callbacks. In our opinion it would defeat the purpose of ofloading the ADC sampling to the silicon to prevent unnecessary interrupts. And adding the ability for optional callbacks would bring in unnecessary complexity, and the user might use it without realizing the effect it might have on performance.
While the user is reading the circular buffer then interrupts should be disabled using irq_lock() to ensure the data remains unchanged while being accessed. This may lead to unexpected behaviour when not used correctly. IMO we can leave this caveat as-is, however I would love to hear if there is a better way to do it.

Alternatives
No alternatives were considered.

@xyzzy42 just to be clear, this RFC is not about using adc_context to mimic continuous sampling. This is of course possible, and what we are currently doing anyway. The problem with this, even if there are no callbacks, is that it still creates interrupts which should be handled by adc_context, which creates context switches. Do this at high frequencies, especially on smaller MCU's, and it will lock up your MCU as it constantly switches between ISRs and other code execution.
This RFC is purely to be able to access some MCU's ability to continously sample an ADC completely in hardware, the physical silicon, without the need for maintaining it using interrupts. This is typically achieved with a DMA.  As mentioned, this is very useful, and often used, in high frequency sampling.
The only compromise I'm willing to make on this is to create one interrupt after the buffer is full, with one callback, if it's possible. And in that case it might make more sense to add a bool continuous to adc_sequence.

Continuous mode would always be async.

Does that really need to be the case? It seems like starting a non-async continuous sampling should work fine. It blocks forever, or until there is an error.
I've written code that does this now, with the existing API, by having the callback always return ADC_ACTION_REPEAT. The callback handles processing the data. The thread that called adc_read blocks until there is an error, in which case it handles it. If it was written to use async read, it would do the same thing, just in a more complex way.

Depends on what we decide on what continuous means. I
f we decide that a single interrupt should be, then it would make more sense to be part of adc_sequence, which in that case would mean that it could sync or async, yes.

This means that if the function is called on a driver which it's not implemented on yet it will cause a linker error, instead of undefined behaviour.

Couple things here. Firstly, the example code won't cause a linker error. It'll call the function pointer in the api struct, and that pointer is NULL, and it will crash. What you want to do is check if the pointer is NULL first and return ENOSYS if it is, otherwise call the method. This is how other optional api methods work.
Secondly, can drivers not return EINVAL or ENOTSUP for adc_sequence_options they do not support? I see plenty of drivers do this. So if a driver does not support continuous sampling, it can return an error.

It looks to me like it would cause a linker header. If CONFIG_ADC_CONTINUOUS=n then the prototype would be defined, but no implementation.
Regardless, relying on the driver to return ENOTSUP isn't very scalable or modular, because then every driver needs now needs to explicitly state that it doesn't support continuous. And each time a new driver is added the contributor needs to remember to add the ENOTSUP. Much better to offload that check to adc.h where it's generic, as mentioned.
And again, depends on how we define a continuous read, where it would make most sense.

Should CONFIG_ADC_CONTINUOUS depend on CONFIG_DMA?

I see no reason why one needs DMA. In fact, the adc_context.h code could support continuous mode in a way that would make it work with most existing drivers without needing to modify the driver.
Consider app portability. I write code that uses a circular buffer and continuous sampling because that makes the most sense. Then I want to run that code on another board that doesn't have DMA or needs the channels for something else. Now the app needs to write a totally new block of code to run the ADC in a different mode without the circular buffer.

As mentioned earlier in this comment, this RFC is specifically to (in the STM32 at least) offload the sampling procedure in it's entirety to the hardware. Relying on adc_context with ADC_ACTION_REPEAT does defeat this purpose completely. Therefore, in the case of STM32 it needs DMA.
The only reason I asked this, is because I don't know how other boards would implement this, or if it's possible. So if you have knowlegde of that, please share.

this RFC currently doesn't include supporting callbacks

How does one know what data in the circular buffer is new and what is not?
I think it in now way defeats the purpose of DMA to have a callback. The callback is no longer every sample, but every many samples. The interrupt load is decreased by orders of magnitude. Also consider, if you have no callback, how do you process the data? Have something on a timer that periodically reads the circular buffer? And what causes this timer to fire? Is it an interrupt? So there are still interrupts, just timer interrupts instead of DMA interrupts.

Adding a single interrupt/callback when the entire buffer is full might be good enough and a good idea, but IMO it's not really needed. It would also make the logic simpler I guess. I'm willing to go in that direction.
As to when you would read the buffer, well, whenever. If it's every second, maybe it's done with timer, maybe it's not, but importantly it's up to the user to decide.

just to be clear, this RFC is not about using adc_context to mimic continuous sampling. This is of course possible, and what we are currently doing anyway. The problem with this, even if there are no callbacks, is that it still creates interrupts which should be handled by adc_context, which creates context switches.

Having a product with 4 channel 200 Hz per channel ADC that wants to go to 10 channels at 200 Hz per channel, I understand this fully.  If anything I said appeared to be about only supporting emulation of proper continuous sampling with per-sample interrupts or per-sample callbacks, this was not my intention.

It looks to me like it would cause a linker header. If CONFIG_ADC_CONTINUOUS=n then the prototype would be defined, but no implementation.

Consider if there are two different ADCs.  Everyone with an external ADC on SPI/I2C will almost certainly have also an internal ADC in the MCU, and thus different ADCs.  So this is not strange at all, but very common.  The configuration option is global.  Just because it is on doesn't mean all ADCs (or even any ADCs, but then why turn it on?) have support for continuous sampling.
It is the same as say CONFIG_UART_LINE_CTRL.  Just because this option is turned on, doesn't mean any given UART driver actually supports api->line_ctrl_set.  Most don't.  So it's necessary to check if the driver supplies that API method and return -ENOSYS if not, exactly as the Zephyr UART API code does.  You should see most of the Zephyr "optional" driver APIs work this way.  Those that don't, IMHO, are bugs.  I'm looking at you adc_read_async....

Consider app portability. I write code that uses a circular buffer and continuous sampling because that makes the most sense. Then I want to run that code on another board that doesn't have DMA or needs the channels for something else. Now the app needs to write a totally new block of code to run the ADC in a different mode without the circular buffer.
As mentioned earlier in this comment, this RFC is specifically to (in the STM32 at least) offload the sampling procedure in it's entirety to the hardware. Relying on adc_context with ADC_ACTION_REPEAT does defeat this purpose completely.

I think you're missing the point.  It's nothing to do with callbacks and repeat.  It's about making a useful API extension.  If the API can support only one precise use case and one specific vendor HAL's method of operation, then it's not as useful as an API.
A Zephyr user wants to sampling continuously from an ADC into a circular buffer, and do it efficiently.  This is surely a common design.  So they use this API.  Of course this should DMA when it can.  But suppose someone wants to run this app on hardware where they can't use DMA?  What is better: a) Too bad, you need DMA, write another app for DMA-less hardware.  Or b), the API keeps working without DMA!  It's less efficient on this hardware, sure, but the app still works without needing to be re-written or even modified.
I think b) is a totally achievable goal.  It should be possible extend the code in adc_context.h that most ADC drivers use continuous sampling, even if the driver itself can't support it natively.

The only reason I asked this, is because I don't know how other boards would implement this, or if it's possible. So if you have knowlegde of that, please share.

If you want to see how to implement continuous DMA is a portable way that experience has proven successfull, look to the Linux ALSA API.  This supports DMA efficiently on a huge variety of hardware, from decades old ISA soundcards to every phone application processor, while presenting a consistent API to user code that doesn't need to know details about the hardware it runs on.
It is however probably too complex for Zephyr.
But the basic concepts of buffer size, fragment size, application pointer should still work.  The constraints system should be made much much simpler.

As to when you would read the buffer, well, whenever. If it's every second, maybe it's done with timer, maybe it's not, but importantly it's up to the user to decide.

But how can you know what to read from the buffer?  You've got to know where the "head" pointer is currently at, where it was last time you read, and if it wrapped around more than once.  Obviously the code doing this periodic reading can keep track of its last head pointer, but how does it get the current pointer?  How does it detect multiple wraps of the pointer?
The answer to detecting wraps is that you must interrupt and check the pointer location more often than it takes to DMA one entire circular buffer.  Making the interval between checks triggered on the samples of data transfered is very a easy way to do this!
Some DMA controllers don't give you a register with some kind of current position pointer you can always read from.  They process data in fragments and interrupt after each fragment is done.  You have no idea where DMA is between fragments and if you want to know where the DMA pointer is, you must count fragments in software.
This is where the two interrupts per circular buffer come from.  It's the minimum number to make it work on this type of hardware.  If you think about one interrupt per buffer, you'll see it is fatally flawed in that upon being notified that DMA has completed one buffer and being able to start processing the buffer, DMA will also be overwriting the buffer from the beginning!

@xyzzy42 valid points. Then I propose we change the approach to be an option, like this
/**
 * Sets ADC reading in continuous mode
 * The driver will complete reading of all channels and sample required extra_samples
 * in one shot, and only afterwards call the callback.
 * The driver will attempt to offload as processing to the silicon as possible.
 * For example, if coupled with DMA, this entire read sequence can be completed
 * without any interrupts, meaning context changes, except for when it's completed.
 */
 bool continuous;

This can then be called in sync or async mode as the normal read, and will act accordingly. The adc_context will have to modified slightly to not call callbacks until the all samples has been taken if this option is enabled. The actual implementation of this is ofloaded to the driver, and can function without DMA to remain portable.
When implemented in STM32 with DMA: The DMA will not be set in circular buffer mode, but rather have a buffer of length 1 + extra_samples, and attempt to fill it. It will only raise an ISR when this buffer is full, which will then call adc_context, which will raise the callback.
Alternative naming suggestion of bool one_shot, but I prefer continuous.
Pros:

The buffer will be safe to use after a read until the user explicitly starts a new read.
Devices with different ADCs of varying capability can handle each case correctly internally.
Portable, as the driver can choose to implement it in any way.

Cons:

Existing drivers will silently ignore this option if not handled explicitly.

NXP adc driver already has a continues conversion mode, which is not  the same meaning for the RFC, but to avoid confusion, maybe change the name form continues to batch_mode be more preferred.

@heinwessels , NXP hardware has a continue_convert feature which is not related to your proposal, so to avoid confusion, maybe change 'continues' to 'batch_mode/

The problem with batch mode for STM32 specifically is that not all STM32 series support one-shot (aka limited) mode. E.g. one cannot just stop continuous mode on F1/F2/F4/F7 without disabling the entire peripheral. And, of course, it's not exactly a replacement for a proper continuous mode, as it introduces jitter between batches. Apart from that, this feature looks like a useful addition, and I'm already debugging some rough implementation for STM32 on my STM32L4 board.

The problem with batch mode for STM32 specifically is that not all STM32 series support one-shot (aka limited) mode. E.g. one cannot just stop continuous mode on F1/F2/F4/F7 without disabling the entire peripheral. And, of course, it's not exactly a replacement for a proper continuous mode, as it introduces jitter between batches.

Yeah, it's not an ideal solution, but IMO a good compromise to make an easy to use driver without any drastic changes required  to the existing drivers. And that's also why I'm leaning to a batch mode which samples 1 + extra_samples because supporting a true continuous read will not fit the current code well.

Apart from that, this feature looks like a useful addition, and I'm already debugging some rough implementation for STM32 on my STM32L4 board.

Nice! I'm also working on a solution already. Would be interesting to compare notes.

I implemented a draft addition to the API, with the basic implementation in adc_context and some unit tests.
The true effect of this addition will come when drivers start implementing specilized code to streamline sampling, possibly offloading it to a DMA, and only calling adc_context_on_sampling_done once it's completely done.

Couldn't one get this same effect by not supplying a callback handler? Then there doesn't need to be an interrupt after each sample. When adc_read() returns or adc_read_async() signals, that is the one interrupt that the batch is done.

Do you suggest that the implementation should choose between the fast path (one long DMA transfer) and the slow one (many short DMA transfers) based on the presence of the callback? I'd say that the user should make this choice explicitly.

Do you suggest that the implementation should choose between the fast path (one long DMA transfer) and the slow one (many short DMA transfers) based on the presence of the callback? I'd say that the user should make this choice explicitly.

pre my prototyping code, if the batch_mode variable is true, it shall override the extra_samplings parameter, so if user sets the batch_mode to true, then it is in the fast path, and other settings are dropped.

Do you suggest that the implementation should choose between the fast path (one long DMA transfer) and the slow one (many short DMA transfers) based on the presence of the callback?

It should choose the most efficient way to accomplish the requirements provided by the API call made.  It is better for the driver to do this, rather than requiring application code to know the details of every driver it should every run correctly with.  Portability.
If there is no need to generate an interrupt after each sample, then it shouldn't do that.  Is the alternative, that the driver should generate an interrupt after each sample and then just ignore it better?  What's the point of that?

If I understand correctly, this API extension will cause the adc_read call to take 1 + extra_samples samples, call the callback handler, then stop. Another call to adc_read is needed to start again, which means there will be a gap between batches. The extension to the existing behavior is to not generate an interrupt nor call the handler after each sample, but only when all samples are taken.

Exactly. The gap between batches is not ideal, but allows the addition of the driver to fit into the current infrastructure much better.

Couldn't one get this same effect by not supplying a callback handler? Then there doesn't need to be an interrupt after each sample. When adc_read() returns or adc_read_async() signals, that is the one interrupt that the batch is done.

Do you suggest that the implementation should choose between the fast path (one long DMA transfer) and the slow one (many short DMA transfers) based on the presence of the callback? I'd say that the user should make this choice explicitly.

I agree with @tagunil. The fact if a callback is specified or not shouldn't decide if some other functionality is activated or not, it's not very intuitive. Besides, it's possible to restart the read by return ADC_CONTEXT_REPEAT from the callback, which is very useful.

It should choose the most efficient way to accomplish the requirements provided by the API call made. It is better for the driver to do this, rather than requiring application code to know the details of every driver it should every run correctly with. Portability.
If there is no need to generate an interrupt after each sample, then it shouldn't do that. Is the alternative, that the driver should generate an interrupt after each sample and then just ignore it better? What's the point of that?

And this is also exactly what this addition allows. However, @xyzzy42 I think the point you're trying to make is the proposed behaviour can currently be achieved by not supplying a callback? And yes, that is true. I guess the driver can see that there's no callbacks and offload more to the silicon because it knows it doesn't need to notify adc_context until it's done. However, I don't want to remove the ability to have callbacks, it's a very useful tool.

pre my prototyping code, if the batch_mode variable is true, it shall override the extra_samplings parameter, so if user sets the batch_mode to true, then it is in the fast path, and other settings are dropped.

For this aspect I still think it's better change as little of the interface as possible, meaning when batch_mode = true, then for example it will still sample every channel 1 + extra_sample times. It will keep the addition very intuitive and easy to use.

For this aspect I still think it's better change as little of the interface as possible, meaning when batch_mode = true, then for example it will still sample every channel 1 + extra_sample times. It will keep the addition very intuitive and easy to use.

in NXP platform, there is an option to choose hardware to do the average on 4/8/16/32, I guess it is very users need oversampling, if my understanding is right, then this extra_sampling is a hardware depends feature, and in NXP platform we open this to user by the sequence->oversampling.

in NXP platform, there is an option to choose hardware to do the average on 4/8/16/32, I guess it is why users need extra samples, if my understanding is right, then this extra_sampling is a hardware depends feature, and in NXP platform we open this to user by the sequence->oversampling.

Do you mean the hardware supports sampling every sample multiple times and then averaging it, and returns that as if it was one sample? Usually called oversanpling? As I understand that's something different than extra_samples. In my experience extra_samples means if will repeat the reading of selected channels, and keep filling the given buffer with samples.
Oversampling (or averaging) is something else, and is set by adc_sequence->oversampling. Probably only used by specific drivers if supported. However, it doesn't influence this API addition.

extra_samples means if will repeat the reading of selected channels, and keep filling the given buffer with samples.

Thanks for clarifing, and what;s the user case for extra_sampling? how to deal with the extra samples?

Do you suggest that the implementation should choose between the fast path (one long DMA transfer) and the slow one (many short DMA transfers) based on the presence of the callback?

It should choose the most efficient way to accomplish the requirements provided by the API call made.  It is better for the driver to do this, rather than requiring application code to know the details of every driver it should every run correctly with.  Portability.
If there is no need to generate an interrupt after each sample, then it shouldn't do that.  Is the alternative, that the driver should generate an interrupt after each sample and then just ignore it better?  What's the point of that?

Well, callback-related behavior is not the only difference between batch mode and normal mode. For example, batch mode should ignore interval_us parameter and sample as fast as possible. Maybe something else could surface. I think these differences between modes should be made explicit and transparent for the user. Not the implementation details, but the expectations of each mode.

You do lose callbacks. But if the callback is only called after the entire sequence is finished, then are they really that useful? Keep in mind that ADC_ACTION_REPEAT only repeats the last sample, not the entire sequence. If you want to repeat the sequence again, the only way is to make a new adc_read call. And ADC_ACTION_FINISH on the last sample has the same effect as ADC_ACTION_CONTINUE.

Yes, looks like the meaning of ADC_ACTION_REPEAT should be reconsidered somehow for the batch mode. Maybe it should repeat the whole batch?

For example, batch mode could ignore interval_us parameter and sample as fast as possible.

It is rare application that doesn't care at all about the time between samples. But if the application did want to sample as fast as possible, even if that was possibly faster than it can process the samples, would it not just set interval_us to 0?

Well, of course applications do care about the sampling rate. But the sampling process itself takes time, and there is little need for additional idle intervals at Msps rates. Moreover, the interrupt-less implementation that we are talking about just can't support any interval_us > 0, so if you still want to make the implementation choice implicit, it would be conditional on (callback == NULL) && (interval_us == 0). That complicates things even more.

I agree, ADC_ACTION_REPEAT should repeat the entire batch.

That complicates things even more.

And this does get complicated. I'd rather be explicit about it with batch_mode, where it can still call a callback at the end. A caveat is that it might ignore interval_us.

Well, of course applications do care about the sampling rate. But the sampling process itself takes time, and there is little need for additional idle intervals at Msps rates. Moreover, the interrupt-less implementation that we are talking about just can't support any interval_us > 0, so if you still want to make the implementation choice implicit, it would be conditional on (callback == NULL) && (interval_us == 0). That complicates things even more.

One should of course take the time it takes to make a sample into account and adjust the delay between samples to achieve the overall rate desired.  I did this in my MCP356x driver. The sampling time is calculated, and it being a delta-sigma ADC this is more complex, then this is subtracted from interval_us and the result converted into the ADCs clock and loaded intro the ADCs delay register.
If an ADC can not support any delay between samples, then surely setting this batch mode flag while also setting interval_us != 0 should return -EINVAL or -ENOTSUP.  Silently ignoring invalid settings is rarely the desired behavior.

If an ADC can not support any delay between samples, then surely setting this batch mode flag while also setting interval_us != 0 should return -EINVAL or -ENOTSUP.  Silently ignoring invalid settings is rarely the desired behavior.

That sounds like a good idea.

Well, of course applications do care about the sampling rate. But the sampling process itself takes time, and there is little need for additional idle intervals at Msps rates. Moreover, the interrupt-less implementation that we are talking about just can't support any interval_us > 0, so if you still want to make the implementation choice implicit, it would be conditional on (callback == NULL) && (interval_us == 0). That complicates things even more.

One should of course take the time it takes to make a sample into account and adjust the delay between samples to achieve the overall rate desired. I did this in my MCP356x driver. The sampling time is calculated, and it being a delta-sigma ADC this is more complex, then this is subtracted from interval_us and the result converted into the ADCs clock and loaded intro the ADCs delay register.
If an ADC can not support any delay between samples, then surely setting this batch mode flag while also setting interval_us != 0 should return -EINVAL or -ENOTSUP. Silently ignoring invalid settings is rarely the desired behavior.

Is there any chance to commit your MCP356x driver?

Is there any chance to commit your MCP356x driver?

I tried, it was just ignored.  The Zephyr caste system results in "Contributors" getting treated like crap.

Such batch mode looks like a good addition to me. But maybe instead of the batch_mode field we could use one named flags or operation (something similar to what is present e.g. in I2C or SPI) that would allow adding more flags in the future. All existing ADC drivers would need to return -ENOTSUP if they don't support any of the flags selected in this field.

How is the callback being done in user mode? This API probably should not be a syscall. This might be a good time to reconsider how this API looks given the __syscall being passed a callback is breaking the user space contract.

So I have a similar-ish use-case whereby I simply need to set the ADC to sample continuously and forget. In my case, the DMA populates one peripheral value directly with the reading from the ADC and this is triggered periodically by a timer. The current calls to adc_read aren't suitable for my application as they cause the thread to yield execution until the callback is called - so I actually also created a function called adc_read_continuous where I can set the ADC/DMA running but without yielding the thread.
I guess this change would be out of scope of this RFC and is something I should submit separately, but I appreciate a fair amount of thought has gone into this RFC (and adding DMA to the ADC in general) so it would be great to hear thoughts


AppVeyor code coverage

The AppVeyor build keeps failing while trying to detect coverage statistics---see e.g. this build. Since the Travis builds successfully report coverage should we just have the AppVeyor build run tests but not detect and report coverage?

Hmmm yeah that's weird. Seems that it fails if any coverage file is missing but Julia does not produce a coverage file for files that have zero coverage.
Could probably fix this but also a good idea to disable and just have one CI pipeline be responsible for reporting code coverage. Appveyor is useful for Windows testing.


Wrong image in users#edit

There is a misplaced icon in users#edit. It shouldn't be there at all or should it?

As of 2ca8b1a640e0768af0c35bd1e0fc29cec54b292c, it is no longer there. It used to be the delete link for the user though.


Py3 compat, remove PISA deps, small bugfixes & touchups

Okay, this is ready for review / merge.

Alright, thanks for looking it over. I fixed the merge conflict in scan_llh.py, completely missed that on first pass.


Split logical Workspace resource from physical ClusterWorkspace resource

Our physical ClusterWorkspace resource contains data about infrastructure like shard scheduling information, like shard movement, other status data possibly in the future. We are not able to keep this stable as our architecture is still in flux.
The Workspace type will be minimal and supportable:
apiVersion: tenancy.kcp.dev/v1beta1
kind: Workspace
metadata:
  name: myapp
spec: {}
status:
  phase: Ready
  url: https://..../clusters/redhat_myapp

Also, this change allows us to introduce other backing types for workspace, and then repesent them as a unified type.
If we want to add more spec or status for specific backing types, we will use discriminated union fields (similar to storage in Kube).

I think this is LGTM modulo rebase & getting things green

Merged through #508.


Provided structured description of ECO usages on OBO metadata

https://github.com/OBOFoundry/OBOFoundry.github.io/issues/451

I added an example for GO - if you can provide more, preferable with a URL with ECO in the URL

Hi @cmungall - how many usage examples do you need? We have a whole list of users at http://evidenceontology.org/about_us/#usergroups
For example (let me know if this is what you're looking for and I can provide more):
 - user: http://www.ebi.ac.uk/GOA
   type: annotation
   description: ECO is used by the UniProt Gene Ontology Annotation (UniProt-GOA) Database to provide annotations to proteins in the UniProt Knowledgebase.
   examples:
    - url: http://www.ebi.ac.uk/QuickGO/term/ECO:0000256
      description: automated annotations from matches to sequence models

@cmungall is this still something we should add to the OBOFoundry file?

Closing for now.
@cmungall please reopen if you want us to take further action on this one.


Update entities.php

add & update for v0.26.1

Thank you @kostefun for this contribution.
Will merge this in now, ready for the next patch release.


[bug] faceenhance RuntimeError: start (12) + length (1) exceeds dimension size (12).

Describe the bug
ace restore breaks on default workflow. Using stability matrix
Reproduction
I finally got the first part of the face-swap workflow working after installing your wheels, and following this advice: https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/13985#issuecomment-1814243471
just trying to run faceswap example workflow
Expected behavior
it runs faceenhance.py successfully
Operating System
Windows (Default)
Comfy Mode
Other (online services, containers etc..)
Console output
occurred when executing Restore Face (mtb):

start (12) + length (1) exceeds dimension size (12).

File "D:\AI\StabilityMatrix-win-x64\Data\Packages\ComfyUI-clean\execution.py", line 317, in execute
output_data, output_ui, has_subgraph = get_output_data(obj, input_data_all, execution_block_cb=execution_block_cb, pre_execute_cb=pre_execute_cb)
File "D:\AI\StabilityMatrix-win-x64\Data\Packages\ComfyUI-clean\execution.py", line 192, in get_output_data
return_values = _map_node_over_list(obj, input_data_all, obj.FUNCTION, allow_interrupt=True, execution_block_cb=execution_block_cb, pre_execute_cb=pre_execute_cb)
File "D:\AI\StabilityMatrix-win-x64\Data\Packages\ComfyUI-clean\execution.py", line 169, in _map_node_over_list
process_inputs(input_dict, i)
File "D:\AI\StabilityMatrix-win-x64\Data\Packages\ComfyUI-clean\execution.py", line 158, in process_inputs
results.append(getattr(obj, func)(**inputs))
File "D:\AI\StabilityMatrix-win-x64\Data\Packages\ComfyUI-clean\custom_nodes\comfy_mtb\nodes\faceenhance.py", line 247, in restore
out = [
File "D:\AI\StabilityMatrix-win-x64\Data\Packages\ComfyUI-clean\custom_nodes\comfy_mtb\nodes\faceenhance.py", line 248, in
self.do_restore(
File "D:\AI\StabilityMatrix-win-x64\Data\Packages\ComfyUI-clean\custom_nodes\comfy_mtb\nodes\faceenhance.py", line 208, in do_restore
cropped_faces, restored_faces, restored_img = model.enhance(
File "D:\AI\StabilityMatrix-win-x64\Data\Packages\ComfyUI-clean\venv\lib\site-packages\torch\utils\_contextlib.py", line 115, in decorate_context
return func(*args, **kwargs)
File "D:\AI/StabilityMatrix-win-x64/Data/Packages/ComfyUI-clean/custom_nodes/comfy_mtb/extern/GFPGAN\gfpgan\utils.py", line 139, in enhance
bg_img = self.bg_upsampler.enhance(img, outscale=self.upscale)[0]
File "D:\AI\StabilityMatrix-win-x64\Data\Packages\ComfyUI-clean\custom_nodes\comfy_mtb\nodes\faceenhance.py", line 139, in enhance
s = comfy.utils.tiled_scale(
File "D:\AI\StabilityMatrix-win-x64\Data\Packages\ComfyUI-clean\comfy\utils.py", line 761, in tiled_scale
return tiled_scale_multidim(samples, function, (tile_y, tile_x), overlap, upscale_amount, out_channels, output_device, pbar)
File "D:\AI\StabilityMatrix-win-x64\Data\Packages\ComfyUI-clean\venv\lib\site-packages\torch\utils\_contextlib.py", line 115, in decorate_context
return func(*args, **kwargs)
File "D:\AI\StabilityMatrix-win-x64\Data\Packages\ComfyUI-clean\comfy\utils.py", line 740, in tiled_scale_multidim
m = mask.narrow(d, t, 1)

Additional context
No response

I'm going to look into it, can you share your workflow?

I can @melMass

RuntimeError start (12)  length (1) exceeds dimension size (12).json
The thing is I had this error: https://github.com/xinntao/Real-ESRGAN/issues/841
At LOAD FACE ENHANCE MODEL
so I did this change: ..\python_embeded\Lib\site-packages\basicsr\data\degradations.py
And modified this:
# from torchvision.transforms.functional_tensor import rgb_to_grayscale
from torchvision.transforms._functional_tensor import rgb_to_grayscale

now you can reproduce.


Versioning in the docs

We should probably explain with each package installation what version of Julia is recommended/required.
More thoughts: https://discourse.julialang.org/t/universal-differential-equations/89093/7

Something like this?
https://arnostrouwen.github.io/ArnoTester.jl/dev/

oh that's really nice!

This has been implemented.


[Bug]: "instanceof Error" fails under Jest

Version
27.1.0
Steps to reproduce
Clone https://github.com/cakoose/jest-instanceof-bug
yarn install
yarn run tsc --build

node dist/normal.js
# the console shows `instanceof` checks yielding `true`.

jest dist/test.js
# the console shows `instanceof` tests yielding `false`.

Expected behavior
When running under jest, I expect the instanceof checks to yield true, just like they do when I run under node.
Actual behavior
The instanceof checks yield false.
Additional context
No response
Environment
$ npx envinfo --preset jest
Need to install the following packages:
  envinfo
Ok to proceed? (y) y

  System:
    OS: macOS 11.5.2
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 16.4.1 - ~/.volta/tools/image/node/16.4.1/bin/node
    Yarn: 1.22.10 - ~/.volta/tools/image/yarn/1.22.10/bin/yarn
    npm: 7.18.1 - ~/.volta/tools/image/node/16.4.1/bin/npm

I am seeing the same issue with node 12.22.7 and jest 27.3.1.

it's caused by this: https://github.com/facebook/jest/issues/2549

yep


Cleared fields for other authentication methods when using one

Jira: https://jira.splunk.com/browse/ADDON-38274

Cleared fields for other authentication methods when using one

:tada: This PR is included in version 1.7.5 :tada:
The release is available on:

v1.7.5
GitHub release

Your semantic-release bot :package::rocket:


Fatal error on composer update

On composer update, the dependency kriswallsmith/buzz is updated to 0.17.1. This causes the following fatal error, rending site search entirely broken:
PHP Fatal error:  Uncaught Error: Call to undefined method Buzz\Client\Curl::setVerifyPeer() in /[..]/vendor/opensearchserver/opensearchserver/src/OpenSearchServer/Handler.php:41

A quick fix is to fork and force version 0.16.0, however setVerifyPeer() needs to be factored out of the component.

I'm not very Composer literate.  How can I limit kriswallsmith/buzz to 0.16.0?
Also, Any status on this getting fixed?

@emmanuel-keller 's commit seems to have solved this.


Alternatives for unwrap when applying builder pattern

See e.g.: https://github.com/manuelmauro/algonaut/blob/v0.2.0/algonaut_transaction/src/builder.rs#L104-L107
We probably should return Result. Or maybe add the required fields to new. The later would verify at compile time, but we lose the field names, so e.g. first_valid and last_valid can be accidentally swapped. A possible solution for this could be to pass a new struct that contains only the required fields.

@i-schuetz I like to take this one. I will try to guess what you want here.
You want to take genesis_hash, last_valid, sender, txn_type and put them in separate struct, and pass the struct to Transaction::new()?

Thanks for asking @dash2507! I was just listing alternatives. My preference would be to use Result. It seems to most clear and simple.

I also support the solution using Result. In the latter solution, the stuct feels too artificial.

https://github.com/manuelmauro/algonaut/pull/60


Publish on the app store iOS and Android

We have a background in .Net Core and UWP apps and now we are building a mobile app for ios and android.
So we went directly to Xamarin as a first approach, but I just realized the progress in blazor, so given our background the choice of mobileblazorbindings is immediate!  👍 👍 👍
Does anyone knows if an app using blazor bindings, mixing xamarin xaml and blazor syntax can be published on the stores for ios and android, or will there be any rejection during the publication process owing to the way the app is built? I do not expect it, but I prefer to ask before on-boarding.
In any case, I have a big thumbs up for this project!

@Ponant though I haven't tried it (I don't have dev accounts for the Google Play Store of Apple App Store - yet!), any app build with Mobile Blazor Bindings is in effect "just a regular" Xamarin app. So, as long as you follow the steps for publishing a Xamarin app to an app store, it should be all the same.
Here is some more info:

Publish to Apple App Store: https://docs.microsoft.com/xamarin/ios/deploy-test/app-distribution/
Publish to Google Play Store: https://docs.microsoft.com/xamarin/android/deploy-test/publishing/publishing-to-google-play/

And there is a lot more info on those docs site if you look around.


Workspaces?

What would be really, really great is the ability to configure "workspaces".
usually tabs would be placed on the default workspace.
But if you switch to another workspace then they would be saved there, until you switch back to the default or another workspace.
This is useful because often you are in different "work" modes at a computer.. let's say you are programming, if you better tab a lot of programming links it will clutter up the whole page - but you know you will be programming for many hours straight so if you change to the programming workspace then you can keep all your tabs there instead of cluttering up the default space.
Of course an ability to move tab sets  between workspaces would also be required if workspaces were to be implemented.
thanks

Hi, thank you for your suggestions. What do you think about a tag/group feature? You can mark the lists as a tag or a group and you can filter them that just display the lists with one tag or group. I think it is more general and easy to understand than "workspaces".

sure, good idea, tagging and filtering would work too - if it is was easy to use
but tagging the group of tabs - nobody wants to individually tag every page in a group


Conditional-Flow Multiple OR'd conditions?

Hi,
Can we have multiple conditions but the logic OR instead of AND?
<input
	type="text"
	cf-questions="Question to ask.."
	cf-conditional-cfc-hello="world" /> <!-- will check for name attribute cfc-hello -->
	cf-conditional-cfc-world="hello" /> <!-- will check for name attribute cfc-world -->

The above example question will only be shown when BOTH the conditions:

cfc-hello="world" and
cfc-world="hello"
are met.

Is there a way to make it so that even if only one of the multiple conditions is met, the question is still shown?
Thanks!

@AfaanBilal would this work: cf-conditional-cfc-hello="||world" here the conditional would go through if "no value" and value "world". I can add it tomorrow.

@felixnielsen Thanks for responding!
Wouldn't this go through if both cfc-hello and cfc-world are left blank?
I need at least one of them to have the required value.

@AfaanBilal Interesting case. Do you have any suggestions for how you'd like a solution to work?

@danielfriis Maybe something like this could be done:
<input
	type="text"
	cf-questions="Question to ask.."
	cf-or-conditional-cfc-hello="world" /> <!-- will check for name attribute cfc-hello -->
	cf-or-conditional-cfc-world="hello" /> <!-- will check for name attribute cfc-world -->

The cf-or-conditional could be evaluated in the same way as the existing cf-conditional except that multiple cf-or-conditional should be joined with an OR || instead of an AND &&.
Would that be possible?
Thanks!

Hi @AfaanBilal I have been testing your PR and playing around with it. However, I do see an issue when we start combining cf-conditional (&&) with the cf-or-conditional (||). As I see it any cf-conditionals on the same tag as cf-or-conditional will be ignored, correct? Do you have any ideas as to how we could solve that?
cf-conditional-cfc-beer="ipa"
cf-or-conditional-cfc-intro="yes"
cf-or-conditional-cfc-please="yes"

Hi @jenssogaard Yes, you're right.
So, the behavior that we desire should be that all cf-conditional tags must evaluate to TRUE and at least one of the cf-or-conditional tags must evaluate to TRUE for the form tag to be shown, right?

Hi @jenssogaard I've pushed a new commit to the pull request that solves this issue implementing the logic as in my comment above.
Thanks!

I'm still having a conditional problem, I read the docs and followed the instructions for multiple conditionals and no dice. Is this a bug that's going to be fixed in the near future?


PostgreSQL: support empty user name for PGPASS auth model

It may be useful when user name is not known.
In this case DBeaver must get the first configuration which matches host/port/database parameters.

verified


SyntaxError: Identifier 'init' has already been declared

When using -D js-es=6, latest Lime and Haxe 4.1, I'm seeing the following error:
SyntaxError: Identifier 'init' has already been declared
I also tried with Haxe 4.2 rc1 nightly from today.
This happens even on the simplest of projects. Here are the offending lines:
let init = lime__$internal_backend_html5_HTML5Application;
let init = lime_app_Application;

It seems this was always kind of happening, but was hiding behind the fact that, before Haxe 4.1, these were to consecutive vars rather than lets... as in:
var init = lime__$internal_backend_html5_HTML5Application;
var init = lime_app_Application;

It looks like the 1st line in this case comes from lime.app.Application's __init__() around line 81.
And the 2nd line, which simply overwrites the 1st when targeting es5, but blows up bc of the double let declaration on es6, is coming from templates/haxe/ApplicationMain's __init__() around line 137.
So what I can't figure out is why are these 2 lines being declared this way back-to-back in the same scope. Near as I can tell, this has been happening for at least several versions, but, again, went unnoticed (by me, at least) until es6 started using let.
So why are these 2 declarations back-to-back in the same scope?
There was a related and now closed Haxe issue here: https://github.com/HaxeFoundation/haxe/issues/9426

Anyone get a chance to look into this yet?


CIP-0010 | Misspelled keyword for 1694 label

Noticed one entry had a typo, decided to fix it.

@rphair probably not the right place for this discussion / question, but what's your opinion of adding a "cddl" attribute to the CIP10 registry which would be an array of CDDL definitions locations.
CIP25 is used for metadata label 721, but there is no easy way to go from CIP10 registry JSON to CIP25 CDDL files - if you don't know where to look. So this CDDL definition would make that link easy / direct..
I'm building something that works with these metadata labels and I'm looking to automatically parse / validate the payload with their intended metadata schema. I was actually super glad that Ales decided to create those for CIP25 - very forward thinking!
Curious on your thoughts!

@Godspeed-exe I don't have experience with these implementations (@Crypto2099 would be better suited to this) but can see how what you're suggesting might be useful:

If you feel confident that a specific format of the CIP-0010 registry would be useful for this, please submit a PR when ready against CIP-0010 with an update to the registry schema & explanation of how to use it.
If not yet confident or just want to discuss the idea, please submit an issue on this repository and I'll add it to the agenda of whichever CIP Editors' meeting comes up next (and will tag you in case you want to be present for that discussion).


[Schemas] In-memory schema service

Part of https://github.com/ConduitIO/conduit/issues/1560.
We need to implement a service that exposes methods to fetch and register schemas. The service will be used for other internal, connector-related, methods.  "Connector utility service" is just a working name, we can change to whatever we agree might be better.
It also needs to run on a randomly generated port (in the future this port might be made configurable). The port should be exposed through an environment variable so that connectors can use it.
In this issue, we can have an in-memory implementation, so that the Connector SDK work can be unblocked.
Note: We should keep in mind that connectors and processors communicate with Conduit differently.

https://github.com/ConduitIO/conduit/blob/main/pkg/plugin/processor/builtin/impl/avro/schemaregistry/fake.go

Closed with #1605 and https://github.com/ConduitIO/conduit-connector-protocol/pull/88.


Please support folder workflow editor list

Now the workflow list in editor is not convenient to manage  when the workflow is more than 100+. How hard  it is to implement folder group manage(like the attach picture shows)?Left is folder tree, right is workflow list under the folder.

Directories are available since Hue 3.10: http://gethue.com/hue-3-10-with-its-new-sql-editor-is-out/


Make it easier to click an individual point

It's pretty hard to click and individual point - sometimes it seems like I am hovering over the right spot, but then I click and it doesn't work. Just because my curser changes from the crosshairs to the pointer, it doesn't mean that when I click I will hit the point under my pointer.

do you have this issue when there are a lot of points drawn in the window or is it consistent even when zoomed in?

even when I am zoomed in. My cursor will change from the crosshair to the pointer, but when I click, it won't flip until I click closer to the middle of the dot.

i believe this is fixed, let me know if the issue still persists


Single Static Submitter

Based on the discussion about the submitter registration interface (https://github.com/pfnet-research/k8s-cluster-simulator/pull/191#issuecomment-482040505, https://github.com/pfnet-research/k8s-cluster-simulator/pull/191#issuecomment-482046764), this PR ...

Modifies NewKubeSim*() functions to take a single submitter as an argument

One cannot add submitters directly to KubeSim after the instantiation

Provides CompositeSubmitter struct

Combines one or more submitters into a single submitter

In this PR, CompositeSubmitter doesn't handle dynamic submitter addition. We can support it in a later PR.
Closes #151

Can we receive a slice of submitters in the arguments? I know the composite pattern can be used to implement multiple submitters but giving multiple submitters to a simulator is more intuitive to grasp the relations of them as I described in the chart of the blog. It’s easier to understand than the composite.
When a scheduler has 2 submitters, I don’t think you think the scheduler has a submitter which has 2 submitters.
What do you think?

Let me think about it a little bit more.
Maybe naming the composite pattern like SubmitterGroup May help.

In the design of the CompositeSubmitter (or you can call it by another name), I put emphasis on separating the responsibility of doing complex handling of submitters from KubeSim.
We can keep it simple by transferring the responsibility of handling multiple submitters from KubeSim to CompositeSubmitter.
The currently supported "complex handling of submitters" is the registration of multiple static submitters, but when it becomes necessary to handle more complex situations such as dynamic registration, implementing these functionalities to KubeSim would make it complicated and the maintenance should be a burden.
Another way of thinking is KubeSim itself handles the simple situation of "register multiple (static) submitters", as of the current design.
However, users would be confused if there are multiple ways; Even if KubeSim accepts multiple submitters, users can still use CompositeSubmitter.
I agree that passing multiple submitters directly to KubeSim is more intuitive than using a composite submitter, but the unintuitiveness would be mitigated by providing a common composite submitter.
Users can in practice register multiple submitters only by writing a few additional lines to wrap the submitters in CompositeSubmitter.
I have just added a comment to buildSubmitter() in example/main.go.

when it becomes necessary to handle more complex situations such as dynamic registration

Aren't we dropping this feature?

when it becomes necessary to handle more complex situations such as dynamic registration

Aren't we dropping this feature?

Yes, by this PR we will drop this feature from KubeSim.
I meant that if users do need the dynamic submitter registration, they can opt-in this feature by implementing a custom submitter, not by extending KubeSim.

I'm not sure why do we want to drop multiple submitter interface??  From a user perspective, I think multiple submitters would be useful.
Even if we provide CompositeSubmitter interface, this means we introduce another burden to users.
Why should we have to introduce single submitter interface??
Would you mind explaining this??


is there cfg_options available for classification framework?

its dificult to add custom options on the base config. adding custom files is less friendly on kaggle.

Hi,
Please specify it using —options

No update for a long time, closed.
If the problem is not solved, please open a new issue.


Updated the PowerShell that fetches the SCP.

Updated the PowerShell that fetches the SCP in easiest way to the end user.

@mzmaili : Thanks for your contribution! The author(s) have been notified to review your proposed change.

The script already has this defined as a variable that it collects on its own.

#please-close


[C++][Parquet] DecodeSpaced copies more values then necessary

It potentially touches memory twice with memset

The stopping condition should be when the indices are equal
Changing these could provide some marginal performance improvements depending on data shape.

Reporter: Micah Kornfield / @emkornfield
Assignee: Micah<EMAIL_ADDRESS>/ @emkornfield
PRs and other links:

GitHub Pull Request #6908

Note: This issue was originally created as PARQUET-1840. Please see the migration documentation for further details.

Antoine Pitrou / @pitrou:
Issue resolved by pull request 6908
https://github.com/apache/arrow/pull/6908


Remove @alisondy from Maintainers (inactive)

Per discussion in slack, @alisondy is inactive as a Flux maintainer.

I took the liberty of adding an emeriti section like we do for other Flux sub-projects.

@fluxcd/core-maintainers please weigh in.

After reading out governance docs, https://github.com/fluxcd/website/pull/1093 was merged a bit too quickly. If there should be disagreements with this PR, we can revert the other one.


Parse multiValueHeader cookies in request APIG events

Description:
APIG sends "multiValueHeaders" as part of its event. Currently (4.10) Vandium doesn't check this field for Cookies ( like it does for headers ).
API:
No user-facing API. Will be auto like for headers.
Implementation Details:
processCookies() would be a good place to start - it checks for a Cookie field on the headers and so could be modified to also check for each member of the value in multiValueHeaders.

I will tackle this

Actually, the Cookie header in multiValueHeaders will never differ from its single value counterpart, so this feature is unneeded. Keeping until maintainers close in case I was correct about something initially.


Animation Is not trigger

Hi There,
I'm trying to use the example to animate my skeleton. However, it's not getting animated.
To Reproduce
Steps to reproduce the behavior:

Use the following Code:

Text("Finished requesting users!")
                    .skeleton(with: true)
                    .appearance(type: .solid(color: .red, background: .blue))
                    .animation(type: .pulse())
                    .background(Color.black)

Expected behavior
It should be animated
Screenshots

What could be happening?
Best Regards

I've been running into some issues regarding the animation in a side project where I'm also using it. It's a great way for debugging purposes in unusual contexts.
I've created a branch where I'm trying to address the fix I spotted, but as it is very related to yours, maybe could you try if it gets improved or solved?
Thanks
The branch is: feature/SU-41_AnimationFixes


Email Flow for Project Created

When a project has been created on Giveth we should notify the project owner and send them an email that gives them more information on the next steps.
when the activity is triggered we gather this info from the back-end:
projectTitle
email
projectLink
firstName
lastName
and we send an email to the project owner that looks like this:

the project title should populate correctly, the button view my project should go to the project details page. We collect their firstname and lastname to correctly populate their user names in our CRM for reference, it does not show up on the email.

@divine-comedian We don't send any email or notification when project is published.

@divine-comedian We don't send any email or notification when project is published.

We should re-enable sending emails but not in-app notifications

I haven't faced the problem of project name
this is an email for project creation in my previous tests

I've checked again and there is no change in the email text compared to the photo above, Is this the final?


Typeahead Reference Change

Typeahead is currently used in two locations. Both instances search the dictionary collection. However, they should search separate collections. When searching for credential records, the typeahead should reference the credentials collection rather than the dictionary collection.

This will require making sure this code is functioning properly and documented with Swagger docs.
https://github.com/Defaultinator/defaultinator-api/blob/main/api/routes/credentials.js#L18-L75

Depends on https://github.com/Defaultinator/defaultinator-api/issues/17


_quantumprogram.py syntax error in Python 3.4 due to dictionary merging

_quantumprogram.py generates a syntax error with Python 3.4 due to dictionary merging that is not supported in python 3.4. See this topic:
https://stackoverflow.com/questions/38987/how-to-merge-two-dictionaries-in-a-single-expression
Here is the error message:
File "../../qiskit-sdk-py/qiskit/_quantumprogram.py", line 1002
"config": {**job["config"], **qobj["config"]}})
^
SyntaxError: invalid syntax
From dtmcclure:
Based on the stackoverflow discussion referenced above, it seems like the for loop at that point in _quantumprogram should be replaced with the version below in order to make this code work for any version of Python 3.
     for job in qobj["circuits"]:
        fullconfig = job["config"].copy()
        fullconfig.update(qobj["config"])
        jobs.append({"compiled_circuit": job["compiled_circuit"],
                     "config": fullconfig})

Thanks for the report!
I'll take a look.

@dan9thsense I've been reviewing what needs to be done for making the SDK compatible with Python 3.4, but seems like too many things need to addressed/ported. Unfortunately, we cannot support Python 3.4 for the moment.
Anyway, we would love to hear from your specific use cases, is it possible for you to upgrade to Python 3.5/3.6?
Thanks!

Yes, I have already upgraded, easy solution.  But I thought you would want to know about the issue.
On Sep 11, 2017 1:48 PM, Juan Gomez<EMAIL_ADDRESS>wrote:
@dan9thsensehttps://github.com/dan9thsense I've been reviewing what needs to be done for making the SDK compatible with Python 3.4, but seems like too many things need to addressed/ported. Unfortunately, we cannot support Python 3.4 for the moment.
Anyway, we would love to hear from your specific use cases, is it possible for you to upgrade to Python 3.5/3.6?
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/QISKit/qiskit-sdk-py/issues/64#issuecomment-328601490, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA_or6muU9QfVd1pGir9Gn7htWKflpufks5shW7MgaJpZM4PTS2m.

Great, I'm glad you can use QISKit :)


opusfile: Add feature for disabling the openssl dependency

Added a feature for making the opusfile dependency on openssl optional.
It is a heavy dependency (huge filesize) and you don't need the https support when you only want a nice wrapper around the opus API.

Thanks for the PR and sorry for the delay!
I renamed the feature to opusurl to better describe the interface that this library provides, instead of the interface it consumes.


Update reserved network port

Current Behavior
This line identifies the reserved port number that this adapter is be listening on - https://github.com/layer5io/meshery-tanzu-sm/blob/master/main.go#L33. Currently, it is using port 10000. This needs to be changed to 10010.
Implementation

[ ] Update main.go in this repo so that the adapter listens on the specific port reserved for it, which is port 10010.
[ ] Update Meshery Docs' so that the reserved network port documentation reflects use of port 10010- https://meshery.layer5.io/docs/architecture#network-ports

hey @leecalcote can i work on this one?

Hi @guacamole, sounds great. Yes, please.


feat: add support for Webpack 5

Webpack 5 doesn't polyfill NodeJS modules anymore. This change replaces usage of NodeJS path with
path-browserify.
fix #142

@cdoublev may I ask why you closed this PR?

I believe there will be no more support (including merging PR) for this package from the author or the current maintainer, as well as for the other two related packages: react-universal and webpack-flush-chunks.
I forked and cleaned these 3 packages. Doing this for react-universal makes me realize that this plugin currently has a lot of uncovered edge cases for detecting/transforming import(component). It covers the main cases but since you can use react-universal without it, it might not be worth using it. A new collaborator might be confused to see an asynchronous import(component) executed at runtime if nobody tells him it is transformed for a client/server differentiated execution. And if you remove the extra features from react-universal and webpack-flush-chunks that you don't need, you may end up with an amount of code that may be not worth to release as a package.
React is not moving so fast on this, but eventually server side components may also makes this packages family useless.
To sum up, I believe it's not worth investing more time on them.

Thank you for this thorough explanation! 👍

I believe there will be no more support (including merging PR) for this package from the author or the current maintainer, as well as for the other two related packages: react-universal and webpack-flush-chunks.

Would you please add something to the docs saying that this package will be depreciated as of Webpack 5?

Agreed. I’ve invested in server-side suspense renderrers and no longer can afford the time to maintain the universal OSS suite. Most of my work is going into module federation


[WIP] Increase test coverage constraints_test

Codecov Report
All modified lines are covered by tests :white_check_mark:

Comparison is base (3525ec7) 57.92% compared to head (20874cb) 57.94%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #18639      +/-   ##
==========================================
+ Coverage   57.92%   57.94%   +0.01%
==========================================
  Files         334      334
  Lines       32596    32596
  Branches     6374     6374
==========================================
+ Hits        18882    18887       +5
+ Misses      12283    12278       -5
  Partials     1431     1431

Flag
Coverage Δ

keras
57.94% <ø> (+0.01%)
:arrow_up:

keras-numpy
57.94% <ø> (+0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 1 file with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Move kernel/fs/fat32_debug.c to tests/unit/

The file contains just debug-util functions to dump a FAT32 in-memory partition. It doesn't make sense to keep it in the kernel itself.
Note: its declaration in include/tilck/common/fat32_base.h has to be removed as well.

hi @vvaltchev i want to contribute the tilck and think i can handle this, can you assign me to the issue? Or may I be a contributer?

Hi @lvntky, you’re absolutely welcome to contribute. I’ve assigned the issue to you.

Thank you very much @vvaltchev ! Even though I am new to the contributing OSS, I really like tilck, I will do my best and hopefully be a helpful long-term contributor. Tomorrow I will start with reading the contribution and testing guidelines!

After merging https://github.com/vvaltchev/tilck/pull/125, this issue has been fixed.


Snake case all ui_properties

Updating the values of chartDataModel that are passed to or come from the API to be chart_data_model. This will make the ui_properties of a Blueprint more consistent with only snake_case variables.
I did a test of Blueprints including updating / creating Blueprints with these new values (note that I did update all of my existing blueprints in the DB to use chart_data_model). Would appreciate an additional smoke test @dtaylor113 :)

Hi, I think we only need to change it in two places:
Once when we get it from API:
client/app/states/designer/blueprints/editor/editor.state.js
function StateController($state, $stateParams, blueprint, blueprintTags, serviceTemplates) {
    var vm = this;
    vm.title = 'Blueprint Designer';
    if (blueprint) {
      ...
      vm.blueprint = blueprint;
      vm.blueprint.ui_properties.chartDataModel = blueprint.ui_properties.chart_data_model;
      // if we don't want two copies floating around
      delete(vm.blueprint.ui_properties.chart_data_model);
    }

And another time when we set it via the API
client/app/services/blueprints-state.service.js
function getBlueprintPostObj(tmpBlueprint) {
...
blueprintObj.ui_properties.chart_data_model = chartDataModel;
...
Would this work?  It involves far less changes to the code base.

Just did a smoke test, everything looks fine :-)


UI: fix create repository focus on name

Additionaliy the info icon should skip tab index

@N-o-Z sure, update description soon


[ReactNative] Adds EmbeddedWallet (email)

Problem solved
You can now do:
import { ThirdwebProvider, embeddedWallet } from "@thirdweb-dev/react-native";

<ThirdwebProvider
  clientId="your-client-id"
  supportedWallets={[embeddedWallet()]}
>
  <App />
</ThirdwebProvider>;

To use the embeddedWallet you need to add the following dependencies to your project:

"amazon-cognito-identity-js": "^6.3.3"

react-native-quick-base64

react-native-quick-crypto

There's an open issue on RN > 0.72: https://github.com/margelo/react-native-quick-crypto/issues/186 which you can fix by adding the following to your android/app/build.gradle file:
packagingOptions {
    pickFirst 'lib/x86/libcrypto.so'
    pickFirst 'lib/x86_64/libcrypto.so'
    pickFirst 'lib/armeabi-v7a/libcrypto.so'
    pickFirst 'lib/arm64-v8a/libcrypto.so'
}

react-native-aes-gcm-crypto

This package requires minSdkVersion = 26 on Android

Changes made

[ ] Public API changes: list the public API changes made if any
[ ] Internal API changes: explain the internal logic changes

How to test

[ ] Automated tests: link to unit test file
[ ] Manual tests: step by step instructions on how to test

/release-pr

/release-pr

/release-pr

/release-pr


Simplify _asgi code with context

Follow-up to #1533.
This wasn't possible to do before due to the warning messages. See the new docstring of TaskContext added in #1533 for current semantics.

@prbot approve


chore(main): release 0.4.1

:robot: I have created a release beep boop
0.4.1 (2023-04-01)
Bug Fixes

TOC: add colons after 摘要 & ABSTRACT (#41) (a9b769a)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/CCXXXI/thesis/releases/tag/v0.4.1 :sunflower:


chore: Add remote variant to execution mode

Stack:

#1933 ⬅
#1924

⚠ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.

This change is

✓ Commit merged in pull request #1956


feat: the non-unital star subalgebra generated by id is dense in C(s, 𝕜)₀

This is a version of the Weierstrass approximation theorem for C(s, 𝕜)₀, and is necessary for instances of the non-unital continuous functional calculus.
Co-authored by: @adedecker

[ ] depends on: #13323

bors r+


Added locale dropdown to user util links

Closes #863

Coverage remained the same at 100.0% when pulling 358e8be145e54f59cb68c6df193b76783d0ebcd9 on 863-locale-dropdown into 44050528f1f377768e6b0391245ae90ae0a5e8c3 on main.

I've asked for more analysis and feedback from the PO

Thank you @hackartisan and @kelynch ! made a ticket for the translations that do not show: https://github.com/pulibrary/pomegranate/issues/866

Okay @kelea99 's suggestion was to merge / deploy this and she will make the languages not public in the relevant exhibits until enough from #866 is done for it to make sense.


Proposal of fix to typo in in 27_bucket_list.py

Hello team,
I would like to report a typo from this file.
The string 'paragragh' should be replaced with 'paragraph'.
See attached picture for more context. 👇

great job!!!


Unreliable inputs with redundancy

Switches input rpcs to be unreliable but with redundancy.
The idea is we don't want a single lost or out of order packet to jam up the flow of our game. Something that becomes increasingly likely the more players you have or the faster you dial up the tick rate.
This simple change dramatically improved response times in my test games and stopped states of 'rollback choking' as Enet tries to recover from a packet discrepancy.
The other benefit is now UDP packets race to provide the next tick info at the cost of slightly more data.
Tested with upto 20% packet loss and game remained stable. At higher packet loss rates Enet kills the connection.
Relevant discussion: https://github.com/foxssake/netfox/discussions/194
How Enet works when set to reliable
Happy to change this to a switch if prefered. Let me know what you think :)

Thanks @albertok, both for looking into it and providing this PR! This looks promising, I'll do some testing on my end too.

Tested locally as well - although it didn't disconnect ( somehow ) at 20% packet loss. The improvement is massive! It went from barely playable to playable with some slight jitters! Which is pretty good at a 200ms roundtrip with 20% packet loss.
This is the command I've used:
sudo tc qdisc change dev lo root netem delay 100ms loss random 20

Tested locally as well - although it didn't disconnect ( somehow ) at 20% packet loss. The improvement is massive! It went from barely playable to playable with some slight jitters! Which is pretty good at a 200ms roundtrip with 20% packet loss.
This is the command I've used:
sudo tc qdisc change dev lo root netem delay 100ms loss random 20

I had been using
sudo tc qdisc add dev lo root netem loss 20%

which I believe is a static 20% loss, random 20 I believe does 'random loss upto 20%'


"Click here" of "Add AppMap to your project" does nothing

Testing latest AppMap VSCode plugin  with a fresh checkout of https://github.com/junit-team/junit5
The "click here" link in the screenshot isn't doing anything when I click it.

@jansorg, I was able to reproduce the (similar) problem with these steps:

Clone junit5 repo
Click "click here" to add configs
Open launch.json or settings.json
Delete them from the Source Control section ("Discard Changes") while keeping launch.json open in the editor
Click "click here" again

Files will be added but launch.json will be empty and "Add AppMap to your project" will keep showing the warning, which is correct, since launch.json is not added properly.
What were your steps to produce the problem?
https://github.com/getappmap/vscode-appland/assets/98758224/202482e5-758b-4118-82fe-bd827c337c23


fix: 🐛 better async loading for keyboardjs

closes #103

:tada: This PR is included in version 5.4.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


feat(host-deployer): update host-deployer spec

Adapt to libguestfs
shrink host-deployer capability

cherrypick: release/3.6
/hold https://github.com/yunionio/onecloud/pull/8848

/hold cancel


Active item in the header nav shouldn't cause the subsequent nav items to shift horizontally

The active item in the header nav should allow for the extra width of the bold font and not cause the subsequent nav items to shift horizontally.

Originally posted by @jrbarnes9 in https://github.com/ONSdigital/design-system/discussions/160#discussioncomment-1911508

Unable to replicate behaviour, closing


cmd/compile: missing T.m is a field, not a method error upon assignments to interfaces

The 1.17 compiler did report this extra error. See fixedbugs/bug231.go for a test case.
package main

type I interface{ m() }
type T struct{ m func() }
type M struct{}

func (M) m() {}

func main() {
	var t T
	var m M
	var i I

	i = m
	// types2 does not give extra error "T.m is a field, not a method"
	i = t // ERROR "not a method|has no methods|does not implement I"
	_ = i
}

cc: @findleyr

This requires a bit of consolidation and clean-up around method/field lookups and error reporting. Moving forward.


[Bug] Shearing wont work in Quests

Description of issue:
I am experiences that shearing wont work in Quests. This applies to every colors. Settings are default, and has not been changded.

CONFIG SECTION (DELETE IF NOT RELEVANT):
Quests:
      '1':
        Name: Regular Joe
        Objectives:
        - Breed;Sheep;10
        - Shear;White;10
        - Milk;Cow;3
        RewardCommands:
        - eco give [playerName] 100
        - msg [playerName] Completed quest!
        RewardDesc:
        - Be a farmer and get money
        - Get 100 for this!

Server Type (Spigot/Paperspigot/etc): Paperspigot
Server Version (using /ver): Paper-483 (MC: 1.16.5)

Without any more informations, how we know that it is not working? It should work. You probably uses old version of Jobs and also, if you spawns a Sheep from spawner or egg spawner, then the result will be no income, but if you enable enable-pay-near-spawner in generalConfig, it will pay for it.

First of all, I use the previous version 4.16.3, not the new 4.17.0 as it can not yet be said to be safe. Can also add that I have tested the same with 4.17.0.
Second, if enable-pay-near-spawner solves this, then that feature don't work because I do not want players to get paid near a spawner. I have searched the areas for spawners and made sure that there was nothing that could interfere with the shearing.
Third, I said it did not work in quest. It works when you should get paid from a normal job, but it does not count shearing in quest.

I had a player report this and have confirmed it. Having the Farmer job does not increase progress on this quest when shearing sheep (white).


import Visual Studio theme into Visual Studio Code

I have defined my own theme for Visual Studio and I'd like to have an option to import it into Visual Studio Code.
I think many Visual Studio users would be happy if they could import / sync the theme to Visual Studio Code.

Closing as out of scope of core VS Code. This could be implemented as a script. See the vscode-theme-generator for example: https://github.com/Tyriar/vscode-theme-generator


Not working?

Installed on Microsoft Edge(chromium), latest.
Aproved the aplication in trello, but nothing happens. When clicking login and aproving on the new tab asking for aproval the page only refreshs, instead of showing that it was aproved.
In trello itself, in settings, the extension is there as approved...
but the extension doesnt recognize its approved. It only ever shows 'login' and activating it in any way (context menu or icon) brings up the page asking for login.

Yep, I am seeing the same behaviour in Chrome

I've been looking into it. New users indeed weren't able to login, but it was hard to diagnose. Fixing this also required almost a whole rewrite because I needed to upgrade to manifest v3. Should be fixed once v3.0.0 goes live on the Chrome Web Store!

v3.0.0 is live now, let me know if there are any other issues!


“Match Whole Word” not working properly in Global Search

Does this issue occur when all extensions are disabled?:   I.e., the _ is at a word boundary.  You can test this by removing the underscore from the setting:
Editor: Word Separators
and re-running your search and then you would get your expected single License_Action find.

It is normal to search in the current document and turn on "Match Whole Word".
Search should not be affected by settings.

I actually can't repro this. Is it possible that you have changed the wordSeparators setting to include underscore?

That's funny.  I did add the underscore to my wordSeparators (long forgotten) and so I can reproduce what I think @xianghongai doesn't like.  If I remove the underscore, there is only the one find result: LICENSE_ACTION.    So that does appear to be the issue...
Is it possible an extension changed that setting?

@roblourens @ArturoDent
Yes, the ‘wordSeparators’ setting contains underscores~😂


change ss58 format for SubstraTEE from 44 to 13 and add ChainX

We are ChainX developers(https://github.com/chainx-org/ChainX) and we launch our mainnet at 05.25.2019. At that time, Substrate have not provide a way to set ss58 version for chain. Thus we just follow the docs about address version, and choose 44 as our mainnet ss58 version. We forked substrate to set 42 to 44 directly for our chain.
Later,  at 01.29.2020, the pr https://github.com/paritytech/substrate/pull/4764 from the team SCS(https://github.com/scs/substraTEE-node) which have done a request to set 44 as their blockchain address type.
Now, we are developing ChainX to update to substrate 2.0, therefore we connect the SCS team to discuss whether they could allow us to use 44, and they change to another address type.
They agree this proposal, and choose 13 as their ss58 address type, so that I do this pr to change 44 as ChainX substrate ss58 address version, and add 13 as Substratee substrate ss58 address version istead.

@brenzi here, please to check this change, thank you very much

I approve this change on behalf of substraTEE


Menu bubble does not appear after adding styles

Describe the bug
I am trying to recreate the example from here (with the menu bubble)
It all seems to be working okay, apart from the fact that the menu bubble just appears above the RTE, like this:

So i found some styles here and included them at the bottom of my component
Now the bubble menu does not appear by deafult, but it also doesn't appear after selecting some text
Please note that I have got no console errors, and no build errors.
Also, I am using these type definitions:
https://gist.github.com/grindpride/bc1f9e8db202c681b6d35c1055627a42
https://gist.github.com/grindpride/ce8a7b7d94f8c8d797262dc278607682
https://gist.github.com/grindpride/e436290d359b6da878b320b8ebf33446
Steps to Reproduce / Codesandbox Example
Steps to reproduce the behavior:

vue create test-project (use typescript)
Copy code below into th HelloWorld component

Expected behavior
I am expecting the bubble menu to only appear after highlighting some text in the editor
Environment

OS: Windows 10
Browser: Chrome, Firefox
Mobile / Desktop: Desktop

Code
<template>

      <editor-menu-bubble :editor="editor"
                          :keep-in-bounds="keepInBounds"
                          v-slot="{ commands, isActive, menu }">
        <div class="menububble"
            :class="{ 'is-active': menu.isActive }"
            :style="`left: ${menu.left}px; bottom: ${menu.bottom}px;`">
          <button class="menububble__button"
                  :class="{ 'is-active': isActive.bold() }"
                  @click="commands.bold">
            <icon name="bold" />
          </button>

          <button class="menububble__button"
                  :class="{ 'is-active': isActive.italic() }"
                  @click="commands.italic">
            <icon name="italic" />
          </button>

          <button class="menububble__button"
                  :class="{ 'is-active': isActive.code() }"
                  @click="commands.code">
            <icon name="code" />
          </button>

      </editor-menu-bubble>

      <editor-content class="editor__content" :editor="editor" />

</template>

After inspecting the generated html I can see the bubble menu does seem to appear, but its just totally invisible and in the wrong place (normally right at the bottom of the page)
Is there some styling that I need to keep it inside the editor?

I just needed to import all of those styles and now it seems to be working fine

Hey @sebasijan I know this is out of scope here, but due to your comment here: https://github.com/scrumpy/tiptap/issues/54 I guess you deleted it, here is my typedef. gist again: https://gist.github.com/Chris2011/511597c9b95850e1fd08fefa93dec9fb I think I deleted it accidentally
Cheers

Sry for that, I couldn't inform you in an other way :)

@Chris2011  Ah no worries!  I ended up using just using the type definitions I linked above and they see to be working great, but thanks for reaching out!

Ahh ok I see, those are more powerful :). Mine was enough for me. Cheers


Application Failed to Run

Fresh application, after installing the Nuget package. still failed.

Thank you for using LottieSharp
This package is compatible with WPF only and i can see you have universal app

It's WPF, And I named it as "FakeUWPanime" because, I thought only UWP is being supported. When I found Lottiesharp I tried to use it and ended up as the "screenshots" shows. Same exception showed up in the sample/demo which is present in this repository.

Are you loading any specific animation? Or did you try to download the source and run it with default animation?

I download a json file from the Lottie website, and you can see the same in the first screenshot" strong lock.json".

Hi, is the json file copied into the debug/release folder?

Yeah, thanks, it works now, But the designer still shows NullReferenceException. I still want to see the designer to work properly on UI.

It looks a bug in the designer. We have skipping codes for the designer and I'll check it again.

I encountered this issue too, my work around is just setting the FileName property on your AnimationView in the code. In my experience, the designer has trouble finding relative paths if you aren't using a pack URI but since LottieSharp doesnt support pack URIs (maybe a feature request 😄) you should convert the relative path into an absolute path at runtime then pass it to the animation view.


add note for preserved tabs navigation state

This is not yet implemented as of GoRouter, currently supported by beamer.

Thank you for your contribution.
However, this is no longer needed as #6 has been merged.


Update README.md

Overall change:
Changing yarn add global crypto-dip-alert to yarn global add crypto-dip-alert because there's an npm module called global, when you use the former it installs the global and crypto-dip-alert library in the current working directory instead of the global directory.
Code changes:
N/A

[x] I have assigned myself to this PR and the corresponding issues

Testing:
N/A

Haha, good catch


Connect curator service to mongodb using mongoose

Small changes from ab's original PR https://github.com/open-covid-data/healthmap-gdo-temp/pull/24:

using one env variable, not sure why the need for conenction url + db name was there, a single string seems sufficient
this is not using the environment validator that the data service is using (to be reconciled in a subsequent PR)
using promises instead of callbacks when using mongoose find()

 Implement curator service CRUD API for sources and runs


[stable/node-problem-detector] Upgrade node-problem-detector to v0.8.9

Description
This pr bumps node-problem-detector version to v0.8.9.
Checklist

[x] Title of the PR starts with chart name (e.g. [stable/mychartname])
[x] I have read the contribution instructions, bumped chart version and regenerated the docs
[ ] Github actions are passing

Hi @devholic thanks for your contribution and sorry for the slow review. Could you fix the failed CI tests so we can merge? See here for details: https://github.com/deliveryhero/helm-charts#contributing

Hello @max-rocket-internet :)
I thought that I regenerated README, but there was a missing update 😓
I just regenerate README. Could you take a look? 🙇


PlatformException(initConnection, responseCode: 3, , null) - Is it client device issue, can we just ignore it ?

Version of flutter_inapp_purchase
5.3.1
Platforms you faced the error (IOS or Android or both?)
Android
Expected behavior
No error thrown
Actual behavior
PlatformException(initConnection, responseCode: 3, , null)
Only a small portion of users affected, including google's test devices sdk_goog3_x86_64. So maybe it's an issue of GooglePlayStore settings at client's device ??
Tested environment (Emulator? Real Device?)
Real device - production release
Steps to reproduce the behavior
I can't reproduce yet. It works fine when I used test cards at real device. Some users can make purchase with this version. As I said, It happens occasionally.
Code snippet
  late FlutterInappPurchase _inner;

  StreamSubscription? _purchaseUpdatedSubscription;
  StreamSubscription? _purchaseErrorSubscription;
  StreamSubscription? _connectionSubscription;

  void init() async {
    _inner = FlutterInappPurchase.instance;
    await _inner.initialize();
    subscribe();
    restorePurchases();
    initProduct();
  }

  void subscribe() {
    _connectionSubscription =
        FlutterInappPurchase.connectionUpdated.listen((connected) {
      print('connected: $connected');
    });

    _purchaseUpdatedSubscription =
        FlutterInappPurchase.purchaseUpdated.listen((item) {
      print('purchase-updated: $item');
    });

    _purchaseErrorSubscription =
        FlutterInappPurchase.purchaseError.listen((purchaseError) {
      print('purchase-error: $purchaseError');
    });
  }

  void restorePurchases() async {
    await _inner.getAvailablePurchases();
  }

  void initProduct() async {
    await _inner.getProducts(productIds);
  }

  @override
  void dispose() {
    _purchaseUpdatedSubscription?.cancel();
    _purchaseErrorSubscription?.cancel();
    _connectionSubscription?.cancel();
    _inner.finalize();
    super.dispose();
  }

Did you find a solution?

@mokhalid1698 My current solution is just ignore it 😅 My assumption is that there's something wrong with their devices. Maybe a bot device, unavailable google play service, side loaded app or unsupported countries. Those users can't make make purchase via google payment anyway.

Did you find a solution?


Simplify config, don't use pretty URLs, disable a bunch of plugins to make it simpler

Doesn't show the "news" at the bottom of posts, looks like Nikola can't do that yet :-)

@ralsina Wow. Fantastic. Thanks for the Nikola sample site update. Thanks for the config clean-up. PS: Will send out (on twitter some announcements tomorrow). Cheers.

@ralsina  Might be a stretch. If you are interested you're more tan welcome to join the stay static team so you can change the (Nikola) sample source without any pull request anytime - if yes the I send you an invitation via GitHub. Cheers.

No need, happy to use PRs :-)


[AMD] StreamPipeline V1: fix depArg return mapping

Previously, if an arg inside the loop was marked as a depArg, then a new iter_arg would be added to the for loop to handle the arg; but any usages of these variables after the for loop would not be updated; those usages would get the wrong value. This PR fixes this by updating the return mapping. See the comment added in StreamPipeline.cpp for an example.

In general, I'd suggest to move the mapping out of emitEpilogue, since it's not part of it.
You can check this closed PR: https://github.com/triton-lang/triton/pull/4422

@zhanglx13 thanks for the suggestion, I put this logic in a new function.  Curious, why didn't you merge your previous PR?

Because we are moving towards stream-pipelineV2 and v2 does not have this issue. Do you still need v1 for a while?

Yes - hopefully we'll be switching soon, but I'm not sure exactly when so it would be nice if we can fix this


Adopt a Widget - Shortcuts

The Shortcuts widget needs:

A code / DartPad sample

For details about how to participate, see flutter.dev/adoptawidget

Hey @johnpryan I would like to take this issue!


nvim crash by whichkey

Hello, try the following:

open a file
press leader (space) (whichkey is opening)
wait a bit (1sec)
press "f"

my NVIM v0.9.0-dev crashes after these steps. If i am fast enough and can press "leader + ft" really fast then neo-tree can open.

nightly is broken right now due to TUI rework. Use stable or wait till its fixed upstream


Does this run the JS serverside or client side?

Does this run the JS server side or client side?

Same question here.

looks like it's client side

Thanks. Yes confirmed it's client side for sure.

Yes it does run client side, that was actually the whole motivation since I had to do an API call with the auth cookie of the client and didn't know how. That's why I made the package.