BUGFIX: CEPH Mons autodetection doesn't work reliably across install types

I have been trying to bring up Openstack on Kubernetes deployed by DigitalRebar with Kargo on KVM instances.  :-)
I've found that the ceph network discovery doesn't work cleanly for all install types with Kargo (cloud vs bare metal vs calico flannel. ...).  Injecting the MON_IP and public cluster resolve the issue.  We have the information so it seems cleaner to do it this way.

This change is

This may be a problem, and may directly related to https://github.com/att-comdev/openstack-helm/pull/157
We had to make changes to the upstream image to support autodetection properly.  It would frequently detect IPv6 images, even with "4" specified.
Did you experience this after you switched to the upstream image? This may mean we need to fix your hanging issue rather then switching to the upstream version.
Specifically, fixes here:
https://github.com/att-comdev/dockerfiles/commit/da600c65569c80eb93c6ea6863806a0ed5a43dac
We shouldn't have to specify the network if auto detect is working properly.

Interestingly enough, your upstream change is similar to what I'm doing.  I'm doing it with changing the upstream.
It may have been having issues choosing IPv6 first and that is what was hanging.  It is possible.  The bigger issue that I was having is that the detection through routing is dangerous.  Depending upon what and where you deploy this, the route will not be "sane".   My calico systems end up with routes to 169 addresses.  This doesn't resolve to any address.  I felt it was cleaner to inject the information that we have (or the system has) in this case.  It removes the ambiguity and reliance on upstream.

@alanmeadows we may need to move towards manually specifying the public subnet, though I'd like to hold off as along as possible. It's looking increasingly likely that the ability to autodetect will only become harder moving forward. I've discussed this with a few of the folks in sig-network and it looks like as k8s starts to support more complex topologies though CNI (looking at you Kuryr-Kubernetes, and other fancier implementations) there may not be a single subnet in play - and this will not even be queryable from the API, let alone from within a container :(

I can admit that having magic baked into the container to discover is essentially against our philosophy.  I'm good with this update as long as we can get https://github.com/att-comdev/openstack-helm/pull/157 merged first, and pinned to a specific version (as opposed to latest)

i'll second that. @galthaus i think you have a path now. again, thanks for contributing and trying it out with DigitalRebar 👍
@alanmeadows we need to make note of these conditions in our philosophy documentation (section 1), so developers are aware of project expectations. also, it's really important that we lay out what we expect for sane and consistent values across charts. in only two months, we have 36 stars on the repo. this tells me that people are interested, and it's really important to address this as i expect contributors to start trickling in (especially when we make the move to either Kubernetes or Openstack repos soon).

For sure -- our documentation is in flight and our number one priority to lay these out and begin to reference them in PRs.

@galthaus i cherry picked this change, along with #157, and everything came up as expected. this change is inline with what we really want (using upstream images:tags). once you push a tag in #157, then i can merge in these  two PR's. i used the tag-build-master-jewel-ubuntu-16.04 in my tests, but it appears that latest is mapped to tag-build-master-jewel-ubuntu-14.04, just fwiw.
thanks for these updates! these are extremely helpful changes. :+1:

I'll change latest to tag-build-master-jewel-ubuntu-16.04 in my PR.  Does that sound good?

@galthaus that's perfect.

@alanmeadows and @intlabs let's capture some of the other concerns with ceph for some issues and roadmap. i.e. wrt architectural planning around values structure, etc. i'll mark this issue as a bugfix since it does in fact resolve the current issue (that our ceph deployment doesn't work), and we can plan out and document the framework in more details in issues and between releases.

Is there anything left for me to do?


chore: recommit refactor change spaceone related words, url, etc. to cloudforet

To Reviewers

[x] Skipping review is not a problem (style, chore ONLY)
[ ] Not that difficult

Type of Change

[ ] New feature
[ ] Bug fixes
[ ] Feature improvement

[ ] These changes require a usage change

[x] Others (performance improvement, refactoring, CI/CD, etc.)

Checklist

[ ] Updated Storybook documents
[ ] Tested with console

Description
SSIA
Things to Talk About

:tada: This PR is included in version 1.1.0-beta.383 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Show more biomes to avoid F3 while digging up

Currently only mountains / emerald chunks are indicated, could be changed to show an icon per biome type

How about using biome icons from Wiki? https://minecraft.fandom.com/wiki/Template:BiomeSprite?file=BiomeCSS.png

Image Copyright info (top right on the preview):

This file (or parts of it) is copyright Mojang Studios
This screenshot, texture, audio, song, or other Mojang asset, or derivative of Mojang assets, does not fall under the Fandom Terms of Use but is freely usable on this wiki.

Yeah I thought of that, but I didn't really like these icons. Feels like a lot of them you have to look really close to actually read them, so idk.
 I don't think you really need to know the exact biome you are in in most cases.
We'll also have to see how relevant this issue still is in 1.18. Emerald chunk for example is not relevant for 1.18, as you just find them high up on the surface of mountains. I'd also not want to give information about this when you're in a cave biome.

We'll also have to see how relevant this issue still is in 1.18. (...)

True, it'll probably need rethinking a bit.


feat: support path and relative-path  prop

close #24

 Submitted with StackBlitz Codeflow.

Jump to github demo. @vitepress-demo-preview/component package should achieve for the function. Right?

of course! I'll give it a try

Additionally, I haven't found any test cases to verify this functionality. The dependencies in the example are linked to remote addresses. How should I proceed with testing?

OK, but the codes you modified doesn't do the function. relativePath should is a online link url but you get the absolute path of the local component.

We should make sure that a relativePath prop is resolvable by the plugin. Right?
Maybe you can do it in the @vitepress-demo-preview/component package and provide the function to jump the link.

Translation: I added support for that feature in markdown-it-vitepress-demo#metadata and implemented other features as well. It has indeed been helpful to me. Additionally, I would like to thank the project for providing me with great inspiration!

Thanks, your attention and contribution!
I can test the feature at example and this is the result I saw. You only need to custom a demo-preview component and the usage remains unchanged.

If this meets your expectations, I will merge this PR.

yes, however, it should replace \ with/

yes, however, it should replace \ with/

Yeah, well, you can change the code and submit it. I will merge the pr. Then you just need to customize your own preview component. Thanks!


Failed to erase flash sector at address 0x00000000 on ATSAMD21G18AU

Describe the bug
I'm unable to use cargo-flash, probe-run, and cargo-embed due to the below error while using a Jlink EDU Mini with a feather M0 proto
Caused by:
    0: Failed to erase flash sector at address 0x00000000.
    1: The execution of 'erase_sector' failed with code 1. This might indicate a problem with the flash algorithm.

To Reproduce
Steps to reproduce the behavior:

Ensure Jlink and feather board are plugged in
Clone atsamd-rs board example
Run cargo run
observe the error

Expected behavior
Able to flash and debug device
Stacktrace
If applicable, add a stacktrace to help explain your problem.
Desktop (please complete the following information):

macOS Venture (13.2.1 (22D68)) m1

Additional context
I can flash the board using hf2 and bossac so the board works. I can also connect to the board using Jlink commander.
I assume I have a configuration issue, but I'm unsure. It's also possible the atsamd repo is a better fit for this issue. Let me know what else I can provide.
cargo/config
# samd21 is a Cortex-M0 and thus thumbv6m
[build]
target = "thumbv6m-none-eabi"
rustflags = [
  # This is needed if your flash or ram addresses are not aligned to 0x10000 in memory.x
  # See https://github.com/rust-embedded/cortex-m-quickstart/pull/95
  "-C", "link-arg=--nmagic",
  "-C", "link-arg=-Tlink.x",
]

[target.thumbv6m-none-eabi]
# runner = 'arm-none-eabi-gdb'
runner = 'probe-run --chip ATSAMD21G18A'

Embed.toml
[default.general]
chip = "ATSAMD21G18A"

[default.rtt]
enabled = true

memory.x
MEMORY
{
  /* Leave 8k for the default bootloader on the Feather M0 */
  FLASH (rx) : ORIGIN = 0x00000000 + 8K, LENGTH = 256K - 8K
  RAM (xrw)  : ORIGIN = 0x20000000, LENGTH = 32K
}
_stack_start = ORIGIN(RAM) + LENGTH(RAM);

I tried to use cargo flash from within the feather_m0 board project and got the same error. I'm assuming this means there's a misconfiguration in that project. I'm still trying to figure out where to look for a solution, though. I'd appreciate it if anyone could point me in the right direction to get me started.

This isn't related to that project at all. I get the same error if I run a bare project using the feather m0 board crate and try to flash with cargo embed. This leads me to believe that something is unique about the board or that the flash algorithm is incorrect. The former is more likely, as there would be many more issues.

From what i recall, the ATSAMs have a default bootloader that is locked. So you cannot write to that sector. You would have to write to 0x800 (I think) and not 0x000 and adjust for that or unlock/erase the first sector. We currently only have sequences enabled for the 5 series and not for the 2 series. You could see if you can make it work by reusing the same sequence here: https://github.com/probe-rs/probe-rs/blob/master/probe-rs/src/config/target.rs#L162 or if you can alter the sequence to make it work for both chips. You then also need to give the flash process the correct permissions to erase the sector for you :)

Ok, that tracks with what I've been seeing. I'm new to rust and embedded, but this is just as good of a starting point as any, so I'll give this a shot. Thanks for pointing me in the right direction.

Let me know if you need more info or drop by in the #probe-rs:matrix.org channel =)

I found some mention of this issue and a tutorial from Adafruit that might be useful. Just dropping those here so I (or someone else) can reference them later.
adafruit bootloader flash
segger forum issue

I believe this is a duplicate of #507.  A workaround for SAMD21 is to tell probe-rs (via command line, Embed.toml, etc) that a part with a smaller flash is in use.  For example, if using ATSAMD21G18AU, specify ATSAMD21E15A.

Closing this as a duplicate of #507.


Latency in VM

[Enter feedback here]
It´s to important understood these in pre selection groups,

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 09914aab-7c70-2092-e3a3-41b1efb730e8
Version Independent ID: 848684ed-7e06-e342-0837-3ec5d19d85ef
Content: Co-locate Linux VMs - Azure Virtual Machines
Content Source: articles/virtual-machines/linux/co-location.md
Service: virtual-machines
GitHub Login: @cynthn
Microsoft Alias: zivr

@skyfader We would need more details to understand your feedback better. Can you please elaborate on your document update request? Are you suggesting to add some more information? Let us know. Thanks :)

Latency and contention are similar's concepts in the networking or telecomunications arena, but we need more details or recomendation from ours experts to reduce these issues in the desing VM deployments, by example it's better a prevent some GROUP's in the same physical area in the CLOUD (if it's is possible). REMEMBER we can reduce the latency ... but never eliminate.

Hi @skyfader ,
The doc outlines best practices here which outlines:

If latency is your first priority, put VMs in a proximity placement group and the entire solution in an availability zone. But, if resiliency is your top priority, spread your instances across multiple availability zones (a single proximity placement group cannot span zones).

The doc also recommends using proximity placement groups with accelerated networking to further reduce latency. Given this I believe the doc provides the information your inquiring about regarding what is the best way to reduce latency in Azure. If you have no additional questions, I'd like to close this issue as the doc provides the relevant information. Should you have additional feedback please feel free to leave a comment below. Thanks.


Add a ReadWriteInterface for displays.

This change adds a ReadWriteInterface for displays that have both read/write capabilities. The interface is actually much different than the current one, so let me know what you think. This has been implemented in an ILI9486 driver I'm working on here: https://github.com/chrismoos/ili9486-driver/blob/master/src/gpio/gpio8.rs
Highlights for the change are:

The DataFormat moves from an enum (useable at runtime), to the implementations. In practice, when you wire up an implementation, from compile time, you'll have a fixed mode (GPIO8/16, SPI, etc,.) so this means implementors can focus on the actual formats they support, rather than runtime handling of the enum.
Read support via read_stream - this allows for efficient transfer (allowing chip to stay selected), invoking a closure until the caller is done reading, which it signals to the interface with a bool return in the closure.
Write support via write_iter - similar to read_stream, this supports efficient transfer (pipelining) of a stream of bytes to the device.
An Iterator is provided automatically for ReadWriteInterface, allowing you to easily iterate over the interface to read bytes.
Implementors of ReadWriteInterface must only implement the above 2 methods, the trait provides some default "helper" methods to read into a fixed buffer, or write from a fixed buffer.

PS @therealprof I saw SSD1306 does have read support, also, so not sure which ones would be "write only". Regardless, this could be combined (the RW) into a super trait if you think that makes the most sense.

Thanks for the PR. My few thoughts from looking over this:

This has been implemented in an ILI9486 driver I'm working on here: https://github.com/chrismoos/ili9486-driver/blob/master/src/gpio/gpio8.rs

It's not ideal that the display-interface is intertwined with the actual display driver since it obscures the important bits about the abstraction layer.

The DataFormat moves from an enum (useable at runtime), to the implementations. In practice, when you wire up an implementation, from compile time, you'll have a fixed mode (GPIO8/16, SPI, etc,.) so this means implementors can focus on the actual formats they support, rather than runtime handling of the enum.

The enum handling is pretty much free. The problem here is that you don't know how applications are actually connecting the display. Some offer many different interfaces, even with different data widths so ideally a display-interface should implement all of the variants which make sense for a particular hardware connection so the display driver can choose the correct data format and the display-interface driver can format it properly for the channel, e.g. when sending 16bit data over an 16bit channel you might need to do endian conversion but only if the display endianess differs from the CPU/MCU endianess, over an 8bit channel you don't. Also some hardware drivers might work great with iterators, for some others you can only work with slices and might need to buffer the stream. Also some displays do used mixed operations, e.g. 16bit pixel data with 8bit commands...

PS @therealprof I saw SSD1306 does have read support, also, so not sure which ones would be "write only". Regardless, this could be combined (the RW) into a super trait if you think that makes the most sense.

That is only possible in parallel mode which has never reported to exist in the real world (and is also not supported by the driver). The I2C and SPI implementations are write-only:
To write data to the GDDRAM, select LOW for the R/W# (WR#) pin and HIGH for the D/C# pin for both
6800-series parallel mode and 8080-series parallel mode. The serial interface mode is always in write mode.

@therealprof Thanks for reviewing.

It's not ideal that the display-interface is intertwined with the actual display driver since it obscures the important bits about the abstraction layer.

Can you elaborate on this? Are there some changes in this PR that you feel intertwine the actual driver with the abstraction layer? The read and write methods seem generic enough, and provide flexibility via the DataFormat generic. Also, any default trait methods can be overridden if there are performance concerns.

The problem here is that you don't know how applications are actually connecting the display. Some offer many different interfaces, even with different data widths so ideally a display-interface should implement all of the variants which make sense for a particular hardware connection so the display driver can choose the correct data format and the display-interface driver can format it properly for the channel, e.g. when sending 16bit data over an 16bit channel you might need to do endian conversion but only if the display endianess differs from the CPU/MCU endianess, over an 8bit channel you don't.

Right, so by adding the generic type DataFormat to ReadWriteInterface it still provides that flexibility. The difference is, when someone goes to actually write a display-interface driver, they will then choose which DataFormat types to support. In addition, regarding the pixel format, this flexibility is also achieved. For example, an implementation of ReadWriteInterface<u8> can implement this as applicable for that platform. I do something similar here, which lets an 8-bit parallel interface output the proper pixel format. In the 16-bit parallel interface version, it's different.

That is only possible in parallel mode which has never reported to exist in the real world (and is also not supported by the driver). The I2C and SPI implementations are write-only

Thanks for that info.

Are there some changes in this PR that you feel intertwine the actual driver with the abstraction layer?

No, this PR is clean but by having the actual display-interface adapter implemented in your display driver you're bypassing the layering of this concept, making it hard to verify that the proposed interface works as intended in a typical setting. This is certainly not helped by implementations like https://github.com/chrismoos/ili9486-driver/blob/bebebdbc83ffc240517ad3a4584fc0e627b7b315/src/gpio/gpio8.rs#L99 which should not really be there (according to the concept).

Right, so by adding the generic type DataFormat to ReadWriteInterface it still provides that flexibility. The difference is, when someone goes to actually write a display-interface driver, they will then choose which DataFormat types to support.

The do get to choose the ones they want to support right now, but if they want to provide the most flexibility they realistically have to implement most of them. You don't get the benefit of working in a lot of different situations if you don't. The necessity of including multiple data types and also endianess is something we learned the "hard" way. Only the display driver knows which format and endianess the display chip expects but only the display-interface driver knows how to actually deliver the data in that format.

In addition, regarding the pixel format, this flexibility is also achieved. For example, an implementation of ReadWriteInterface can implement this as applicable for that platform. I do something similar here, which lets an 8-bit parallel interface output the proper pixel format. In the 16-bit parallel interface version, it's different.

I have not checked what kind of magic your display driver does to make that happen but believe me it's not that simple.
There're at least two more display drivers besides ssd1306 which already use this interface, cf https://github.com/yuri91/ili9341-rs (not released yet) and https://crates.io/crates/st7789 . I've verified them in a lot of different settings and hardware configurations to do the right thing (I2C, SPI, 8bit and 16bit paralllel using GPIO, 16bit parallel using a MCU provided parallel bus, ...) and it took a lot of tweaking to make the interface flexible, universal, correct and very efficient (in fact all of the implementations have considerably improved their performance since the adoption of display-interface and I haven't even started adding any hardware specific optimisation yet).

No, this PR is clean but by having the actual display-interface adapter implemented in your display driver you're bypassing the layering of this concept, making it hard to verify that the proposed interface works as intended in a typical setting. This is certainly not helped by implementations like https://github.com/chrismoos/ili9486-driver/blob/bebebdbc83ffc240517ad3a4584fc0e627b7b315/src/gpio/gpio8.rs#L99 which should not really be there (according to the concept).

I 100% agree, it's best to have them implemented here so they can be consumed by multiple display drivers. The only reason I didn't include my implementation (gpio8 and gpio16), and why I didn't adapt the existing ones here, is because of my use of IoPin to provide switchable I/O. I didn't think it made sense to bring that trait in here, it's better tracked upstream in embedded-hal.

Only the display driver knows which format and endianess the display chip expects but only the display-interface driver knows how to actually deliver the data in that format.

In the current interface, the display-interface driver takes a DataFormat (U8, U16LE, U16BE, etc,.) and writes out the bytes. In a parallel interface, there is no discrepancy about which bit should go first (on the data frame/unit level), instead, the concern is in most cases, how to provide pixel data (i.e 18-bit pixel spread across two bytes, or 2 18-bit pixels spread across three bytes in a 16-bit parallel interface). As you said, the display driver is the one who knows what the active pixel format and they should be doing the conversion (whether its Rgb565, Rgb666, etc,.).
The driver should format the pixel(s) needed for the active pixel format and push them down to the display-interface driver via a write call. The caller (the actual driver) doesn't care if the ReadWriteInterface clocks out the data MSB (bit) or LSB, that is specific to the implementor of the ReadWriteInterface, i.e via parallel data lines it doesn't matter, or with SPI it does and you configure SPI to clock out MSB, before it even gets to the display-interface layer.

I have not checked what kind of magic your display driver does to make that happen but believe me it's not that simple.

No magic really :). I updated the code to be a bit more clearer as to how it works, see here.
impl<T> PixelWriter<u8> for T
where
    T: ReadWriteInterface<u8>,

The above lets us determine how to write pixel data for an 8-bit interface. Same can be done with a u16. Now, you aren't constrained either by using just primitives here. For example, by defining type U18 = u32; you can target color when in 18-bit parallel mode:
impl<T> PixelWriter<U18> for T
where
    T: ReadWriteInterface<U18>,

There're at least two more display drivers besides ssd1306 which already use this interface, cf https://github.com/yuri91/ili9341-rs (not released yet) and https://crates.io/crates/st7789 . I've verified them in a lot of different settings and hardware configurations to do the right thing (I2C, SPI, 8bit and 16bit paralllel using GPIO, 16bit parallel using a MCU provided parallel bus, ...) and it took a lot of tweaking to make the interface flexible, universal, correct and very efficient (in fact all of the implementations have considerably improved their performance since the adoption of display-interface and I haven't even started adding any hardware specific optimisation yet).

I reviewed the ili9341 one and, for example on this line,
.send_data(U16BEIter(&mut data.into_iter()))

The endianness specifier is pretty much useless, the driver really just want's to send some u16 words down to the interface, if it's an SPI implementation of WriteOnlyDataCommand, it will take care of clocking MSB out first (based on SPI configuration). If it's parallel, then it doesn't matter. Same thing with the other driver.

I didn't think it made sense to bring that trait in here, it's better tracked upstream in embedded-hal.

Yeah, but I very much prefer a clean separation from the getgo. Maybe something like an established SPI trait would be a better way to do the proofing.

The driver should format the pixel(s) needed for the active pixel format and push them down to the display-interface driver via a write call. The caller (the actual driver) doesn't care if the ReadWriteInterface clocks out the data MSB (bit) or LSB, that is specific to the implementor of the ReadWriteInterface, i.e via parallel data lines it doesn't matter, or with SPI it does and you configure SPI to clock out MSB, before it even gets to the display-interface layer.

It does care. The display driver only knows in which format the display expects the format, it does not know which format the display-interface driver is pushing out the data to the display; that's why we have the different data types in the display-interface, the display driver pushes out the data in the expected format and it's up to the display-interface to make sure it ends up at the display in the expected format.

The endianness specifier is pretty much useless, the driver really just want's to send some u16 words down to the interface, if it's an SPI implementation of WriteOnlyDataCommand, it will take care of clocking MSB out first (based on SPI configuration). If it's parallel, then it doesn't matter. Same thing with the other driver.

No it is not useless. If your system is little endian but you need the data in big endian format (which is very common nowadays) then you will need to do the conversion somewhere, you can either do it in each display driver which is error prone (and potentially have a superfluous byteswap there because you could actually do the swap in hardware or worse you'll have to swap back) or you run into other weird mismatches.
We've been this which is why we have added it in the first place.

Yeah, but I very much prefer a clean separation from the getgo. Maybe something like an established SPI trait would be a better way to do the proofing.

Done, implemented on existing SPIInterface implementation in this repository.

It does care. The display driver only knows in which format the display expects the format, it does not know which format the display-interface driver is pushing out the data to the display; that's why we have the different data types in the display-interface, the display driver pushes out the data in the expected format and it's up to the display-interface to make sure it ends up at the display in the expected format.

It is possible we are just thinking about different ways to accomplish the same thing. :)
In the end though, the driver wants to send command 0x01. This is where its concern ends; the WriteInterface implementation's job is to translate 0x01 -- if it's a GPIO8 implementation, it writes out each bit to the correct data line (i.e Bit 0 to D0, etc,.). If it's an SPI interface, it will call write on a SPI interface. In display-interface speak, the user is constructing an SPIInterface, passing in their device specific SPI instance. When the user constructs the SPI peripheral instance, they will indicate if MSB or LSB should be used. The actual WriteInterface SPI implementation has no idea how the data (in this case u8) will actually be clocked out.
As for pixel format, from what I've seen, depending on the word size of the interface being used (8-bit parallel, 16-bit, SPI - which usually follows 8-bit) is how the pixel format is determined. In this case, it's important the display interface driver knows the interface's word size. This is how the pixel format detection/writing works here.
In fact, in one of the drivers you linked, it is using RGB 565 encoding and here is where it's encoding the pixel. While it works, it doesn't take into consideration differences in encoding if you are on a different interface. The transmission is different depending on 8/16/18-bit modes, for example, and in some cases, the actual pixel format.
In ILI9486, if you want to transmit RGB666 on 8-bit, it takes 3 write cycles, and the 2 LSB bits for each write are not used. But, if you implement on the 18-bit interface, you can send one whole pixel in one write cycle (filling up all 18 bits). In the current system, how can you facilitate this?

No it is not useless. If your system is little endian but you need the data in big endian format (which is very common nowadays) then you will need to do the conversion somewhere, you can either do it in each display driver which is error prone (and potentially have a superfluous byteswap there because you could actually do the swap in hardware or worse you'll have to swap back) or you run into other weird mismatches.

So, I'm not sure I 100% understand the concern here. When we are sending around (u8, u16, u32) throughout our code, the underlying system endianness is abstracted from us. The system endianness is only relevant when you go and access data directly from memory, probably via some unsafe mechanism. Implementations of display-interface may or may not get that far (FSMC, maybe), but at that point, the endianness of the data is not the question. 0x01 is 0x01. Whether you need to write MSB/LSB to the register is another story, but again, that doesn't have any bearing on what we're getting upstream from the driver.

When the user constructs the SPI peripheral instance, they will indicate if MSB or LSB should be used. The actual WriteInterface SPI implementation has no idea how the data (in this case u8) will actually be clocked out.

That is completely irrelevant, we're not talking about bit order here, we're talking about endianess, i.e. how the bytes are ordered in datatypes > u8.

In ILI9486, if you want to transmit RGB666 on 8-bit, it takes 3 write cycles, and the 2 LSB bits for each write are not used. But, if you implement on the 18-bit interface, you can send one whole pixel in one write cycle (filling up all 18 bits). In the current system, how can you facilitate this?

At the moment we can't, there's only 8bit and 16bit support, but others can be added if necessary. Some SPI displays e.g. have a 9bit mode.

So, I'm not sure I 100% understand the concern here. When we are sending around (u8, u16, u32) throughout our code, the underlying system endianness is abstracted from us.

No, it is not abstracted. It is implicit. When you assemble pixel data in the MCU it's in native endian (often little endian), the display expects in a certain endian (often big endian). When you send 16 bit values over an 8 bit interface someone has to convert the data (or not).
That's the whole reason for the U16BE* and U16LE* types. Those allow the display driver to specify in which order the bytes are supposed to arrive at the display and they also allow the display-interface driver to do the conversion (if needed). This removes the need to do gnarly endiness conversions in each and every display driver and allows the display-interface to work as efficiently as possible.
Please have a look at the ST7789 driver which was our implementation playground to make the interface both correct and efficient (in fact we're hitting an embedded-graphics bottleneck now due to the way pixel iterators work and I'm hoping for the new window based iterators to arrive somewhen this lifetime still). I've extensively benchmarked this in 8bit SPI, 8bit parallel and 16bit parallel (both via GPIO and FSMC) modes.

That is completely irrelevant, we're not talking about bit order here, we're talking about endianess, i.e. how the bytes are ordered in datatypes > u8.

Yes, I understand, U16LE and U16BE are about byte order and the calls to to_le and to_be end up doing a byte_swap if necessary. But when you talk about If your system is little endian, I'm assuming you are referring to the MCU, and if that's the case, byte order isn't relevant, but instead if the bits are stored 0..15 or 15..0 in address space.
I think we're at an impasse here as we fundamentally think about this differently, as to how the abstraction should work.

That is completely irrelevant, we're not talking about bit order here, we're talking about endianess, i.e. how the bytes are ordered in datatypes > u8.

Yes, I understand, U16LE and U16BE are about byte order and the calls to to_le and to_be end up doing a byte_swap if necessary. But when you talk about If your system is little endian, I'm assuming you are referring to the MCU, and if that's the case, byte order isn't relevant, but instead if the bits are stored 0..15 or 15..0 in address space.

Yes, internally the MCU uses whatever it uses and that is irrelevant because pixel data will always be in native order. When you push it to the display you may have to change the byte order to accomodate for the required data format (or not which is the idea behind specifying what the data should be). This is not something the display driver should worry about, it simply should format the data as described in the datasheet and let the display interface know what it's supposed to be.

I think we're at an impasse here as we fundamentally think about this differently, as to how the abstraction should work.

I agree.

In ILI9486, if you want to transmit RGB666 on 8-bit, it takes 3 write cycles, and the 2 LSB bits for each write are not used. But, if you implement on the 18-bit interface, you can send one whole pixel in one write cycle (filling up all 18 bits). In the current system, how can you facilitate this?

At the moment we can't, there's only 8bit and 16bit support, but others can be added if necessary. Some SPI displays e.g. have a 9bit mode.

Before we close this out, can you let me know how to implement RGB 6-6-6 on the driver side and support the encoding required for 8, 16, and 18-bit parallel interfaces with the current display-interface? High level is fine, but each encoding is slightly different:

8-bit interface - 3 write cycles, 24 bits
16-bit interface - 1.5 write cycles, 24 bits, and 3 cycles required for 2 pixels (mixes two pixel's color data on the same cycle)
18-bit interface - 1 write cycle, 18 bits

18bit data needs a new set of enum values U18* and the data provided needs to be in a u32.

Yeah, I assumed that would be the suggestion. But in the case of the 16-bit Data Bus for 18-bit/pixel, must the interface read-ahead (in the U18Iter case) to transmit the two pixels in 3 cycles? In addition, if it's wrapped in U18BE, I'm curious how the byte swap would work, especially with the padding in 8/16-bit modes.
Also, for the endianness in general, based on how you read bits in here, if you pass a U16BE and are running on a big endian system, no byte swap would happen. But on a little-endian, like an STM32F103, it would swap the bytes. If that's the case, and you check the bits to set based on the value of what you just swapped, wouldn't this give you the wrong behavior? Let me know if I'm not understanding this correctly.

Yeah, I assumed that would be the suggestion. But in the case of the 16-bit Data Bus for 18-bit/pixel, must the interface read-ahead (in the U18Iter case) to transmit the two pixels in 3 cycles? In addition, if it's wrapped in U18BE, I'm curious how the byte swap would work, especially with the padding in 8/16-bit modes.

The whole point of this API is that it's up to the the display-interface driver to take care of all splitting and bitjuggling and the display driver doesn't have to care. The display driver just says: "I'm giving you an iterator of 18bit pixels values, please take them and provide them as 18bit value in big endian format to the display".

Also, for the endianness in general, based on how you read bits in here, if you pass a U16BE and are running on a big endian system, no byte swap would happen. But on a little-endian, like an STM32F103, it would swap the bytes. If that's the case, and you check the bits to set based on the value of what you just swapped, wouldn't this give you the wrong behavior? Let me know if I'm not understanding this correctly.

This code is just an optimisation to not change pin state if it's the same as the previous state. That's not the whole 16bit value but whatever part of it you've put on the bus last.

The whole point of this API is that it's up to the the display-interface driver to take care of all splitting and bitjuggling and the display driver doesn't have to care. The display driver just says: "I'm giving you an iterator of 18bit pixels values, please take them and provide them as 18bit value in big endian format to the display".

Yeah, I understand this, but then you are hard coding pixel format in the display-interface implementation. Maybe this is fine, I have only read through a few datasheets for different controllers and most seem to encode RGB data the same way for 8-bit, 16-bit etc,., so in practice this may be fine, but still, a consideration.

This code is just an optimisation to not change pin state if it's the same as the previous state. That's not the whole 16bit value but whatever part of it you've put on the bus last.

I'm not talking about the changed state, I'm talking about how the bits are written out to the data lines (specifically, how each bit is checked to see if it's 1).
I see that you are actually using to_be_bytes / to_le_bytes so in this case system endianness has no bearing, so I take back what I said above. It converts to a consistent byte order (big/network order or little, regardless of underlying system endianness).
I'll keep this open as I may update this PR to still add "R/W" support, but with the current DataFormat system instead.
Chris

Yeah, I understand this, but then you are hard coding pixel format in the display-interface implementation. Maybe this is fine, I have only read through a few datasheets for different controllers and most seem to encode RGB data the same way for 8-bit, 16-bit etc,., so in practice this may be fine, but still, a consideration.

No, the display driver provides the pixel data encoding, the display-interface provides the transport. If the display requires some weird interleaving then it's up the display driver to supply that if it wants to support it, e.g.

A usable datasheet will always specifies the acceptable data format and how to stuff pixels into it:

Does your display actually offer a native 18bit mode? If not, there's no need for a 18bit data mode.

I'm not talking about the changed state, I'm talking about how the bits are written out to the data lines (specifically, how each bit is checked to see if it's 1).

? The line you've highlighted checked whether the bit has changed from the previous byte which was clocked out, maybe you've missed the XOR ? https://github.com/therealprof/display-interface/blob/48079b792bebb3bf60330bc5129828c564861a1e/parallel-gpio/src/lib.rs#L88

I'll keep this open as I may update this PR to still add "R/W" support, but with the current DataFormat system instead.

That would be very welcome.

Does your display actually offer a native 18bit mode? If not, there's no need for a 18bit data mode.

Yeah, it does, although I don't have one of those displays in hand.

? The line you've highlighted checked whether the bit has changed from the previous byte which was clocked out, maybe you've missed the XOR ?

I was referring to if value & 4 != 0 {, if value & 8 != 0 {, etc,. for checking if a bit is set.

I was referring to if value & 4 != 0 {, if value & 8 != 0 {, etc,. for checking if a bit is set.

That's just to cater for the GPIO API: if the bit is set the GPIO is pulled high, if not it's pulled low. All the changes are clocked in at once when pulling the WRX high.
https://github.com/therealprof/display-interface/blob/48079b792bebb3bf60330bc5129828c564861a1e/parallel-gpio/src/lib.rs#L211


安卓会报这个错

Launching lib/main.dart on M10 in debug mode...
Initializing gradle...
Resolving dependencies...
* Error running Gradle:
ProcessException: Process "/Users/xxxxxx/examples/flutter_test_demo/android/gradlew" exited abnormally:

> Configure project :flutter_ijkplayer

Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
Project evaluation failed including an error in afterEvaluate {}. Run with --stacktrace for details of the afterEvaluate {} error.

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/seifon/dev-tool/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_ijkplayer-0.2.2/android/build.gradle' line: 23

* What went wrong:
A problem occurred evaluating project ':flutter_ijkplayer'.
> Plugin with id 'kotlin-android-extensions' not found.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 2s
  Command: /Users/seifon/Project/examples/flutter_test_demo/android/gradlew app:properties

Finished with error: Please review your Gradle project setup in the android/ folder.

flutter doctor -v

For java project error, I will fix it in next version.

Fixed it.
Update version to 0.2.3.


Correction for raw affiliation Ethical approval: The human subjects research described in this Perspective was approved by American Institutes for Research's Institutional Review Board IRB00000436 on August 11, 2015, project EX00356.; Other disclosures: None reported.; Twitter: @PM_Alberti.; should be addressed to Philip M. Alberti, Association of American Medical Colleges, 655 K St., NW Suite 100, Washington, DC 20001; telephone:<PHONE_NUMBER>

Correction needed for raw affiliation Ethical approval: The human subjects research described in this Perspective was approved by American Institutes for Research's Institutional Review Board IRB00000436 on August 11, 2015, project EX00356.; Other disclosures: None reported.; Twitter: @PM_Alberti.; should be addressed to Philip M. Alberti, Association of American Medical Colleges, 655 K St., NW Suite 100, Washington, DC 20001; telephone:<PHONE_NUMBER>
raw_affiliation_name: Ethical approval: The human subjects research described in this Perspective was approved by American Institutes for Research's Institutional Review Board IRB00000436 on August 11, 2015, project EX00356.; Other disclosures: None reported.; Twitter: @PM_Alberti.; should be addressed to Philip M. Alberti, Association of American Medical Colleges, 655 K St., NW Suite 100, Washington, DC 20001; telephone:<PHONE_NUMBER>
new_rors: 04q6cg820
previous_rors: 00490n048;04q6cg820
works_examples: W2604575419
contact: f96537dcf1205f2b6ff90b1b97120a76:bc79fb5e13e69a @ air.org

This issue was accepted and ingested by the OpenAlex team on 2024-10-10. The new affiliations should be visible within the next 7 days.


Minor updates to biorefineries

This pull request introduces the following changes:

Delete BDO npy and png files from the TAL folder.

Move TAL npy files to a new TAL.cache folder

Minor enhancements to tests.

Thanks!

The pull request now includes bug fixes to the TRY analysis and process specifications as well as the sugarcane to HP biorefinery


cmd/go: does not find packages under GOPATH when run from GOROOT\src directory on windows

What version of Go are you using (go version)?

go version devel +5aef51a729 Sun Mar 29 02:01:34 2020 +0000 windows/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Alex\AppData\Local\go-build
set GOENV=C:\Users\Alex\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=c:\users\alex\dev
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\users\alex\dev\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\users\alex\dev\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\Alex\AppData\Local\Temp\go-build421324630=/tmp/go-build -gno-record-gcc-switches

What did you do?
c:\>cd %GOROOT%\src

c:\Users\Alex\dev\go\src>type %GOPATH%\src\a\main.go
package main

import (
        "fmt"
)

func main() {
        fmt.Println("Hello")
}

c:\Users\Alex\dev\go\src>go build -o %TMP%\a.exe a && %TMP%\a.exe
package a: cannot find package "." in:
        c:\Users\Alex\dev\go\src\a

c:\Users\Alex\dev\go\src>

What did you expect to see?
I expected my program in package a in my GOPATH directory to build.
What did you see instead?
I see the error above.
This used to work, but was broken by
0fc89a72edc2c73651f7f6841b1146af723f517f is the first bad commit
commit 0fc89a72edc2c73651f7f6841b1146af723f517f
Author: Bryan C. Mills<EMAIL_ADDRESS>Date:   Wed Feb 20 18:25:37 2019 -0500

    cmd,std: add go.mod files

    Updates #30241
    Updates #30228

    Change-Id: Ida0fe8263bf44e0498fed2048e22283ba5716835
    Reviewed-on: https://go-review.googlesource.com/c/go/+/164622
    Run-TryBot: Bryan C. Mills<EMAIL_ADDRESS>    TryBot-Result: Gobot Gobot<EMAIL_ADDRESS>    Reviewed-by: Jay Conrod<EMAIL_ADDRESS>
@bcmills @jayconrod let me know, if you need help to debug this.
Thank you.
Alex

GOROOT/src is a module (the std module, to be specific).
As of Go 1.13, if the working directory is within a module, cmd/go uses module mode (rather than GOPATH mode) by default.
So this seems to be working as designed. If you want to build in GOPATH mode, either run the go command from outside of a module, or set GO111MODULE=off explicitly.

So this seems to be working as designed. If you want to build in GOPATH mode, either run the go command from outside of a module, or set GO111MODULE=off explicitly.

You are correct. My Linux shell is configured with GO111MODULE=off. But I don't have GO111MODULE=off set on my Windows computer. That is why they are different. Setting GO111MODULE=off on Windows makes the command above work as I expected it.
Sorry to waste your time. Closing the issue.
Alex


fix code check on startup of server

fixes the issue that shows errors for project.json

LGTM :+1:


DB2 C API to backup and restore only transaction logs

With IBM DB2, is it possible to take only transaction logs backup and restore from C API? I know I can set the config from C CPI where
LOGARCHMETH1 got set. After setting this, transaction logs got archived but if I need to take a backup of the active transaction only?
Does transaction logs backup supports Full, Incremental, and Delta also?

Only the transaction logs, no.  It is definitely possible to create backup images which also include the minimum necessary set of transaction logs for a future recovery to a minimal point-in-time, but not only on their own.
What use-case do you have in mind?  What are you trying to accomplish that would require a backup of only the logs?
Another way of looking at it though is that log archiving IS essentially a backup of the transaction logs, in an incremental fashion, although there are certainly some boundary cases that deserve advanced consideration depending on the requirements of the system being designed.

Yes, right archiving is essentially a backup of transaction logs. I am looking for a feature through which I can take backup and restore of only logs through C API which is basically transaction logs backup. If we can not take this backup of only logs then do we have any reference from the IBM db2 side?

It might help if you can describe the overall workflow you have in mind.  Which logs files (all, a subset for some purpose, or individual files)?  Most importantly, what you plan to do with those log files later in the future and which use-cases you need to support?
One option, maybe perhaps the closest to what you described, is to create your own log archival 'user exit' program.
https://www.ibm.com/docs/en/db2/11.5?topic=management-user-exit-programs-log-file-archiving-retrieval
There are simple samples pointed to in the documentation, including some implemented in C (any language is possible), as well as in the db2-samples repo:
https://github.com/IBM/db2-samples/blob/8d71c80e1eac7817715fb56626486cdcc470890a/c/db2uext2.cdisk

Closing due to inactivity


Wrong margin on markdown table in notebook

Have a notebook with a markdown cell like this
| A | B |
| ---- | ---- |
| Cell 1 | Cell 1 |
| Cell 2 | Cell 2 |

The second column has weird padding

That is coming from this style rule, I don't understand the purpose:
https://github.com/microsoft/vscode/blob/53c29fc51fa2741732bba39f7ed6aa2234fca8e7/extensions/markdown-language-features/notebook/index.ts#L114-L118
It looks find in the normal markdown preview

I think this rule is too generic. It should only target top level elements of the preview instead of using *


set 'utf8' encoding as default

'binary' is used only when needed
fix: https://github.com/notatestuser/gift/issues/51

Thanks for this. Would you mind syncing with master?


TestPostSetupManager is flaky

Description
TestPostSetupManager is flaky.
Steps to reproduce
Run make test on a fresh clone of the repo.
Actual Behavior
@jonZlotnik reported getting the following failure:
--- FAIL: TestPostSetupManager (0.58s)
    post_test.go:56:
                Error Trace:    post_test.go:56
                                                        asm_amd64.s:1581
                Error:          Not equal:
                                expected: &activation.PostSetupStatus{State:2, NumLabelsWritten:0x800, LastOpts:(*activation.PostSetupOpts)(0xc00047bc50), LastError:error(nil)}
                                actual  : &activation.PostSetupStatus{State:3, NumLabelsWritten:0x800, LastOpts:(*activation.PostSetupOpts)(0xc00047bc50), LastError:error(nil)}

                                Diff:
                                --- Expected
                                +++ Actual
                                @@ -1,3 +1,3 @@
                                 (*activation.PostSetupStatus)({
                                - State: (activation.postSetupState) 2,
                                + State: (activation.postSetupState) 3,
                                  NumLabelsWritten: (uint64) 2048,
                Test:           TestPostSetupManager
FAIL
FAIL    github.com/spacemeshos/go-spacemesh/activation  24.039s

Expected Behavior
Tests on develop should always pass.
Environment
N/A
Additional Resources
From a quick glance at the test, this can possibly be explained by a timing issue (where a second event gets placed in the status channel before the first one is handled). I believe this can be fixed by only performing this check on line 56 if len(mgr.StatusChan())==0. Before doing that we should try to consistently reproduce and then ensure that this fixes it. There’s also a potential race here - if we check this, nothing guarantees that it doesn’t change between the check and the following assertion. This can be fixed by first querying the value and then performing the length check (so in the worst case we skip a validation we could perform).

This should be fixed now. Please reopen if it fails again.


Prevent bonfire block syncing in section transitions

Implement a Sync event listener (once https://github.com/MineInAbyss/DeeperWorld/pull/75 is through)

fixed


chore: update examples and test cases

Signed-off-by: Nitsh Kulkarni<EMAIL_ADDRESS>PR summary
PR includes example updates and test cases for push destinations.
Fixes: #5611
PR Checklist
Please make sure that your PR fulfills the following requirements:

[x] The commit message follows the Angular Commit Message Guidelines.
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

PR Type

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[x] New tests
[ ] Build/CI related changes
[x] Documentation content changes
[ ] Other (please describe)

What is the current behavior?
Examples were not updated for push destinations
What is the new behavior?
included examples and test cases for push destinations
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Syntax error when using the example provided in docs

fix router/doc/article/en-US/router-configuration.md: unexpected token when building the module

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

Thanks all!


Feature: Update to<EMAIL_ADDRESS>

The problem
Incompatibility between the Page type on Axebuilder and Playwight-bdd, Axe expects a Page type 1.43.1 whereas the step gives a 1.42.1 page.

on this code

When("The user needs the page to be accessiblee", async ({ page }) => { // Page 1.42
  const accessibilityScanResults = await new AxeBuilder({ page }).analyze(); // Error on page want version 1.43
...});

A solution

Upgrade the PlaywrightType to 1.43.1 ?
I can open a pull request to handle the issue @vitalets  :)

@synnksou steps should pass Page from the Playwright installed in the project. Could you check why there are two versions of Playwright? For example npm ls playwright-core.

Closing as there is not reply from author.


Introduced argument parsing to customize host/port

Using docopt to parse. There are currently two optional parameters: -p for the port and -i for the ip.
This replaces the PORT env variable.
Please review @rnestler @schmijos :)

Why do you want to replace the env variable?

The reason for the env variable was to prevent an argument system. If we had both, which would take precedence? Also, I could imagine new commandline arguments that wouldn't make sense as env variables.
Do you think it's worth it to bring the env var back, and to introduce it for the IP too?

Rebased and reorganized code.


chore: PR checklist += add PR labels

Description
Add "add appropriate labels to PR" item to pull request template

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[x] included the correct type prefix in the PR title
[ ] added ! to the type prefix if API or client breaking change
[x] targeted the correct branch (see PR Targeting)
[ ] provided a link to the relevant issue or specification
[ ] added a changelog entry to CHANGELOG.md
[ ] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[x] reviewed "Files changed" and left comments if necessary
[ ] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed ! in the type prefix if API or client breaking change
[ ] confirmed all author checklist items have been addressed
[ ] reviewed state machine logic
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

Trivial PR - putting labels as a line item will help me remember in the future.
(Meta: Looks like on a PR updating the template, the template from main is still used when creating the PR)


Advice on best way to handle multiple data sources that rely on each other

I have mixed data source setup (A,B). Data source B relies on a variable that's set from data in data source A. In my panel i need to wait until data source B has completed the lookup. I am not really sure the best way to handle the panel. I can see there is a data source updated event but cant find any advice on how this is used and even if this is applicable to my needs. Any advice on where to start? Thanks

@craftzneko The best way to handle it is using dashboard variables.
It's explained in the recent Grafana Blog: https://grafana.com/blog/2024/03/04/how-to-perform-multi-step-api-calls-with-grafana/


Drop support for rubygems 1.x

Ruby 2.0 is the oldest release we support, and it ships with Rubygems
2.0: https://github.com/ruby/ruby/blob/v2_0_0_0/lib/rubygems.rb#L11
This may fix issues we see in Ci, which have a stack trace like this:
/opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/specification.rb:762:in `block in _resort!': undefined method `name' for nil:NilClass (NoMethodError)
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/specification.rb:761:in `sort!'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/specification.rb:761:in `_resort!'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/specification.rb:713:in `_all'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/specification.rb:896:in `each'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/specification.rb:928:in `find'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/specification.rb:928:in `find_by_path'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems.rb:190:in `try_activate'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:126:in `rescue in require'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:39:in `require'
	from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-12.3.0/lib/chef/provider/package/rubygems.rb:39:in `<top (required)>'

Unfortunately the issue is not consistent so we don't know for sure that this will fix, but there's no harm in dropping older rubygems for the above stated reasons.
@chef/client-core

:+1:

:+1: less code is happiness

:+1:


Suggestion: Formal documentation on how to log authentication activities

Hello,
I spent quite a lot of time searching Google, GitHub and StackOverflow for an official and easy way to do something (in my case, log) on these events:

Successful sign in
Failed sign in
Sign out

There are quite a few complex (and in my view, risky) options like subclassing Devise::SessionController and other solutions that only solve part of the requirements.
I would like to suggest this:

If would be nice if Devise itself can provide configuration option or callbacks that can be defined on the User model to capture these events.
An alternative - if the above is not desired - is to provide a Wiki article about it (I am willing to contribute it, if the solution I found below is acceptable).

The easiest way I found to do it, is to create an initializer and place this code in it:
# config/initializers/warden.rb
# Log authentication activities
# Docs: https://www.rubydoc.info/github/hassox/warden/Warden/Hooks

Warden::Manager.after_set_user except: :fetch do |user, auth, opts|
  $warden_log.info "Successful sign in by #{user.log_entry}"
end

Warden::Manager.before_failure do |env, opts|
  email = Rack::Request.new(env).params['user']['email']
  $warden_log.info "Failed sign in by #{email}"
rescue => e
  $warden_log.error "[Warden::Manager.before_failure] #{e.class}: #{e.message}"
end

Warden::Manager.before_logout do |user, auth, opts|
  $warden_log.info "Successful sign out by #{user.log_entry}"
end

Assuming this way of doing it makes sense, should I add the wiki page?

Sounds really good to me and very useful for many people. That's what a wiki is for. I'd say add it in 🙌

YES Add to wki.
Recommend close.

So I guess the first part of my suggestion didn't pass?

If would be nice if Devise itself can provide configuration option or callbacks that can be defined on the User model to capture these events.

It would be much nicer to define this without resorting to Warden::Manager hooks, since Devise users installed Devise, and I can speak for most of them when I am saying they do not want to deal with Warden.
Perhaps this can even be aliased without much effort, even just to provide similarly named hooks, only under the Devise namespace.
In any case, I will close this for now, perhaps I will add a wiki page (it has been some time since I opened this issue). Feel free to reopen if there is any chance of improving the way users define these hooks in devise itself.


[WFLY-9464] Some XACML tests fail with security manager

This issue cannot be merged directly. It depends on some changes in two libraries jboss-jaxb-api_spec and security-xacml
Apart from the two privileged blocks in the libraries, there are some additional permissions required at the application level.
Issue: https://issues.jboss.org/browse/WFLY-9464
JBEAP Issue: https://issues.jboss.org/browse/JBEAP-13576
It depends on:
https://github.com/picketbox/security-xacml/pull/9
https://github.com/jboss/jboss-jaxb-api_spec/pull/9

@yersan Is this usable now?

Hi @bstansberry , not yet. We need two component upgrades in order to get this test working with secmgr enabled: jboss xacml (minimum 2.0.10) and Jaxb API (minimum 1.0.5)
These are the issues that address the component upgrades
Jaxb API upgrade: https://issues.jboss.org/browse/WFLY-6595
Xacml upgrade: https://issues.jboss.org/browse/WFLY-9589

@yersan I am adding the 'hold' label. Let me know when it is ready (or if it already is!)

@yersan it looks like this could be merged now, although the tests will not pass with the security manager until the components are upgraded?

Hi @stuartwdouglas , exactly, the tests under security manager will not pass until getting jboss xacml (minimum 2.0.10) and Jaxb API (minimum 1.0.5) in Wildfly.
Honestly, I'm not sure if it should be merged now or we should wait until getting those versions already in the project, the changes in this PR were done for enabling the test under a sec manager and require the Jaxb/xacml version upgrades, maybe we should wait for those upgrades before merging this, or we can merge it and wait for the upgrades, after all the tests were failing under sec manager before.

We should wait, so the 'hold' label is still valid :)

It still needs Xacml upgrade: https://issues.jboss.org/browse/WFLY-9589 in order to get the tests pass using secmgr.
Since it is still on hold, I assume it is unnecessary to close it and open it again later once the upgrade is done.

Closing until we have all the required bits


Syndicate Names

I got really tired of "Operator #"
Appends phonetic and Greek alphabet names to Syndies.
:cl: Pancake

tweak: The Syndicate have gotten more creative with their names.

Should be good now. I think.


Failed to compile when I run npm run start in AmplifyDemo

Demo
Specify the name of the demo that you encountered the bug.
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to 'app/AmplifyDemo'.
npm run start
Then the following error occurs.

Failed to compile.

src/components/Meeting.tsx
  Line 25:27:  React Hook "useMeetingStatus" is called in function "clickedEndMeeting" that is neither a React function component nor a custom React Hook function. React component names must start with an uppercase letter  react-hooks/rules-of-hooks

Search for the keywords to learn more about each error.

Expected behavior
Compiled successfully!
Desktop (please complete the following information):

OS: macOS
Version 11.5.2

Additional context
I fix src/components/Meeting.tsx as follows, then it works fine.
const Meeting: FC = () => {
  const meetingManager = useMeetingManager();
+ const meetingStatus = useMeetingStatus();

  const clickedEndMeeting = async () => {
    const meetingId = meetingManager.meetingId;
-     const meetingStatus = useMeetingStatus();
    if (meetingId) {
      await endMeeting(meetingId);
      await meetingManager.leave();
    }
  }

  return (
     ~~~~
  );
};

@azuharu07 thanks for this catch! Pushing a fix right now. I'll go ahead and close this issue.


Antenna characteristics

Hello,
Thanks for the code. I would like to enquire if antenna characteristics (antenna delay) are taken into account?
Also, is there a possibility to only evaluate the data in 2d instead of 3d ( measurements taken at a fixed height)?
Thanks,
Vignesh

Hello dear Vignesh,
1- No, I don't think so.
2- Yes, it's possible.
If you mean you have 2-D antenna structure: please check "antenna_locations" that is the locations of each antenna. If you have your own data, so you need to make the "antenna_locations" by yourself. Please note that you have to set z-value even you have 2-D antenna structure (all z-values are the same). Then, "channel_names" indicates for each signal, which antenna is the transmitter and which one is the receiver (as the index of the antennas in "antenna_locations" list).
If you want to reconstruct 2-D image: 2-D or 3-D antenna array makes no difference. You can reconstruct only one slice. Please check the values of "points" and "axes_" which makes in the line 70. The "points" are the points in which the beamformer estimates the scattered energy. The structure is easy, each point has 3 values; x,y, and z. But about "axes_", I can't remember the exact type or structure, but it contains the values in each axis; 3 sets for x-values, y-values, and z-values.
You can use line 70, then remove unwanted points from "points" and corresponding z-values from "axes_". Or., make them by yourself.
To see the result, just modify the most last number in the line 87.
Please feel free to ask any question.

Correct, the example codes require that the signals originate from the points in antenna locations. This can be achieved in a number of ways, the antenna locations can be the virtual antenna locations, by adding extra delay to times calculated by MERIT or by other forms of calibration. Which you would use would depend on the exact hardware set-up, there is no universal method.

Thank you shahkaram and declanol for your replies. I shall try running the code again by setting a fixed value of z.
I shall try adding a time delay based on the antenna being used to evaluate whether the result varies. I asked since some papers suggest that the location of scatterers would be incorrect if we do not take into account receiving and transmitting delays of the antennas while calculating the intensity of backscattered signals from a point


Style radio buttons in AddTransaction.tsx

This also fixes the visual bug that was introduced when the radio buttons were added.


Switch from "tar --exclude-vcs" to "git archive" to keep .gitignore

After running into trouble on several occasions trying to upgrade golang-*-dev packages that predate dh-make-golang, especially error merging with deleted .gitignore in dh-make-golang-generated tarball, I become convinced that the use of tar --exclude-vcs, which indiscriminately delete files like .gitignore, is not the best solution.
Would git archive be a better solution?  Perhaps something like the following?
git archive --format=tar --prefix=golang-github-author-package/ upstream/0.0_git20160429.0.9abcdef \
    | xz -9 >golang-github-author-pacakage_0.0~git20160429.0.9abcdef.orig.tar.xz

Cheers,
Anthony

Can you point me to a couple of examples in which the tar calls leads to problems?

I can't remember the names of the packages off the top of my head, but trouble arises during an upstream version upgrade in the following situation:

Upstream author originally created a .gitignore file...
...which got removed indiscriminately by dh-make-golang's use of tar --exclude-vcs when it creates an .orig.tar.gz after a git clone.
The first Debian package maintainer decided to create his/own .gitignore file during packaging.
A new upstream release is available as a tarball, say v1.0.0.tar.gz.
A pkg-go team member decides to package the new version using v1.0.0.tar.gz as pristine-tar by running something like gbp import-orig --uscan.
Wham!  Big messy merge conflict!

But messy merge conflict situation aside, I believe the intention to use tar --exclude-vcs is to remove the .git/ directory, which has no place in a release tarball.  However, .gitignore should have been kept as is, especially when the upstream release tarballs contains it, and thus dh-make-golang should not remove it.

Thanks for providing more detail. I’m afraid that I don’t have the time to identify an example myself. Can you provide me with an example with which this problem occurs please?

@stapelberg take this for example, https://github.com/hashicorp/atlas-go
Test fixtures like https://github.com/hashicorp/atlas-go/tree/master/archive/test-fixtures/archive-hg/.hg will be excluded if you use tar --exclude-vcs


[WebGPU] : Native symbol not found

Summary
A summary of the issue you're experiencing.
Steps to reproduce

Platform: Windows
Framework Version: .NET 7
API: WebGPU
API Version: Latest in experimental feed

Create a texture
Call  api.TextureGetWidth() function

Errors :
'Native symbol not found (Symbol: wgpuTextureGetWidth)'
'Native symbol not found (Symbol: wgpuBufferGetConstMappedRange)'

Comments
Same happens with some buffer functions
If you know how to fix this issue, please submit a pull request instead!

That's a good question, i don't really know exactly but i assume vulkan.
That's how i created the device and adapters, didn't provide any info for the driver

if (window is not null)
{
    if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
    {
        cs.SType = SType.SurfaceDescriptorFromWindowsHwnd;
    }
    else if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
    {
        cs.SType = SType.SurfaceDescriptorFromXlibWindow;
    }
    var desc = new InstanceDescriptor() { NextInChain = &cs };
    Instance = new(Api.CreateInstance(desc));

    Surface surface = new(window.CreateWebGPUSurface(Api, Instance));
    {
        var requestAdapterOptions = new RequestAdapterOptions
        {
            CompatibleSurface = surface.Handle
        };

        Api.InstanceRequestAdapter
        (
            Instance,
            requestAdapterOptions,
            new PfnRequestAdapterCallback((_, adapter1, _, _) => Adapter = new(adapter1)),
            null
        );
    }
}

Nono are you using WGPU or Dawn? (or some other driver?)

Ah, i'm using WGPU with the native nuget package you provide

WGPU does not implement those functions at this time, please report this upstream: https://github.com/gfx-rs/wgpu-native/blob/master/src/unimplemented.rs#L282


Unable to use multiple open source firmware Launchpads at the same time

On stock firmware, we can select an ID for our Launchpads in the bootloader, so the Launchpad can present itself as a different MIDI port to avoid conflicts (USB PID 0051 to 0060).
This ID selection is entirely ignored in the open source firmware, and the Launchpad will always present itself as USB PID 4051, no matter what ID is really selected in the bootloader. This makes it impossible to properly utilize multiple open source firmware Launchpads at the same time.
This would be a very welcome fix for anyone who owns multiple Launchpads, and I feel this is a very basic thing that shouldn't really have been an issue from the start.

You're right. I left it out because I didn't see USB being much of a use case. But then, I didn't expect someone to come along and re-implement the stock features (I mean, wow, great work!) on the open SDK.

Live integration was a special challenge ;) Thanks for acknowledging the issue, I've got a bunch of users affected so I'm hoping it gets patched.
On an unrelated note, any chance we could get in touch? I've got multiple issues to report on the USB Driver for the Launchpad that I've been trying to report to you guys for a while now, I believe one of them has been assigned a ticket number but I've gotten no updates for months now. Some of them are a real dealbreaker for the software I'm developing.

@dvhdr ?

Mailed you :)

Just pushed a change to the lib which supports the bootloader device ID. Note that this will only partly help on Windows - the Novation driver will not yet match the open firmware device (but that's a separate issue, as it's only required for multi-client operation).

Thanks for the firmware side fix @dvhdr ! Waiting for the driver fixes then. Could you get back to me over email about the other issues I reported? I've been awaiting your response for 2 weeks already.


utils: resolve macro groups for guidelines

This PR includes the macro groups in the generation of the containedbyfacet.
Fixes #1481

@kepper Can you have a look? The previously commented-out code said that the inclusion of macroGroups resulted in recursive loops. Did not recognize any loops when adding back the macro.parents. But maybe double-check...


"Săpata" is listed in the drop-down menu

Description:
When user writes "Săpata" the location appears in the drop-down menu next to the comune and the county witch is a part according to the law
Precondition:
The website is up an running.

Step 1
Write in the search bar "Săpata"

Expected results
The location appears in the drop-down menu as "Săpata, Argeș"


Update slider/plot dimensions to match cube file dimensions

References #182
Parameterize slider max values, as well as any other applicable values from 120 (manual width/height/depth of rhopol.cube) to an arbitrary width/height/depth of whatever the current cube file is. (Pull from lengths of cube.data3D maybe?)

Set slider max to cube file dimensions, although the ipyvolume aspect ratio is still squished, and will need much more additions out of the scope of this minor task. Created PR.
[t:65]


Create dataset loader for ASR-STIDUSC: A SCRIPTED THAI DAILY-USE SPEECH CORPUS

Dataloader name: asr_stidusc/asr_stidusc.py
DataCatalogue: http://seacrowd.github.io/seacrowd-catalogue/card.html?asr_stidusc

Dataset
asr_stidusc

Description
This open-source dataset consists of 4.56 hours of transcribed Thai scripted speech focusing on daily use sentences, where 5,431 utterances contributed by ten speakers were contained.

Subsets
-

Languages
tha

Tasks
Text-To-Speech Synthesis, Automatic Speech Recognition

License
Creative Commons Attribution Non Commercial No Derivatives 4.0 (cc-by-nc-nd-4.0)

Homepage
https://magichub.com/datasets/thai-scripted-speech-corpus-daily-use-sentence/

HF URL
-

Paper URL
-

#self-assign


[CARBONDATA-1437] Fixed bug for incorrect exception message when loading to table having property 'bucketnumber' set to 0.

In this PR, Table creation would not be allowed, if the table property 'bucketnumber' is set to 0 in create command.
Added unit test case for it as well in class TableBucketingTestCase.scala

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/533/

LGTM


Thank you for the dataset

Hey music-x-lab team,
Just wanted to share with you a few MIDI samples generated with your dataset. I think you may find it interesting.
POP909GeneratedSamples.zip
This was made with GPT2 implementation + custom MIDI processors.
https://github.com/asigalov61/Optimus-VIRTUOSO/blob/main/Optimus_VIRTUOSO.ipynb
I like the results and I will continue exploring what your dataset has to offer.
Thank you.

Thank you for your consideration and appreciation of our dataset!!

Yes, you are very welcome! :)
I am getting fantastic results with it and I wanted to provide you with a longer output sample so that you can see how well it performs.
Thank you very much!
POP909-Long-Output-Sample.zip
Most Sincerely,
Alex


browser:google-chrome will not work for v115+

The delivery process for chrome has changed
https://chromedriver.chromium.org/

More info:

Google announcement (June) https://googlechromelabs.github.io/chrome-for-testing/
Availability page https://googlechromelabs.github.io/chrome-for-testing/
New endpoint to downloads chromedriver for v115+ https://googlechromelabs.github.io/chrome-for-testing/last-known-good-versions-with-downloads.json

Can confirm that BDI fails with chrome from today

Hello @dbrekelmans ,
Here is a PR whith the new JSON endpoint system for chromedriver,
https://github.com/dbrekelmans/browser-driver-installer/pull/75

Could you retry with 1.0.5-beta.3?

Could you retry with 1.0.5-beta.3?

It worked for me. Thanks.

Solved with 1.0.5, thanks everyone who was involved!


Setup improvements

... and one minor autotune bug fix

If you get npm ERR! enoent ENOENT: no such file or directory, access '/root/src/oref0/node_modules/oref0' when running this, run this to fix:
mkdir -p ~/src; cd ~/src && rm -rf oref0 && git clone git://github.com/openaps/oref0.git && cd ~/src/oref0 && git checkout setup-improvements && npm run global-install
We still need to figure out how to reproduce the problem and come up with a better fix.

Was able to successfully use this branch to upgrade from cluckj/master (the 0.6.3 patch release candidate) to 0.7.0.

If no objections, I think I'll merge this to dev tomorrow, and then re-flash this rig and do a direct-to-dev install.


How to update "out" or "in" of a EDGE

OrientDB Version: 3.0.19
Java Version: "11" 2018-09-25
OS: 10.14.4
I am trying to update "out" value of a EDGE class, e.g. :
UPDATE EDGE TableEdge SET out=#53:23 WHERE out.name="a";
Actual behavior
I can see the update here : SELECT out FROM TableEdge WHERE out=#53:23;
But there is no change here : SELECT out(`TableEdge`) as outValue FROM #53:23;
so, outValue = "[]"
TableEdge is defined like :
CREATE CLASS TableEdge IF NOT EXISTS EXTENDS E;
ALTER CLASS TableEdge SUPERCLASS +OTriggered;
CREATE PROPERTY TableEdge.out LINK;
ALTER PROPERTY TableEdge.out MANDATORY TRUE;
CREATE PROPERTY TableEdge.in LINK;
ALTER PROPERTY TableEdge.in MANDATORY TRUE;
CREATE PROPERTY TableEdge.someValue SHORT;

What is wrong here please ?

Hi @petervavro
I just tested v 3.0.19 with your schema plus the following:
create class Person extends V;

create vertex Person set name = 'a'; /* #57:0 */
create vertex Person set name = 'b'; /* #58:0 */
create vertex Person set name = 'c'; /* #59:0 */

create edge TableEdge from (select from person where name = 'a') to (select from person where name = 'b'); /* #45:0 */

UPDATE EDGE TableEdge SET out=#59:0 WHERE out.name="a";

and it seems to work fine. Any clue on how to reproduce?
Thanks
Luigi

Hi,
Cannot reproduce and not more infos, closing


Improve UX for editing non-script text files in the script editor

Godot version:
Master (a7bd9f0)
OS/device including version:
Any.
Issue description:
@Paulb23 added long-requested support for opening arbitrary text files in the script editor in #19225, and it works well.
The UX could be improved in several ways, though:

File > Open in the script editor has the filter "All Recognized" which does not include non-Godot text extensions, so those files are not listed as valid targets. You can change the filter to "All Files (*)" to see them. IMO it's ok that the default excludes non-script text files as it would be difficult to whitelist all possible extensions (.txt, .log, .godot, .import, .cfg, .json, .yaml, etc.). But maybe we can at least rename the default filter to "All Script Formats" to make it clear that it only includes though.
Non-script/resource text files are not shown in the FileSystem dock, so you can't double click them to open them in the text editor. So the only workflow to actually edit them is to use File > Open, change the default filter, and then select the file.

Ideas welcome on how to improve things, without introducing worse issues such as having the FileSystem dock cluttered with text-based .import files.

But maybe we can at least rename the default filter to "All Script Formats" to make it clear that it only includes though.

Actually the current filter also includes resource formats (.tres and (!) .res, while it definitely can't open the latter). Might be worth reviewing the exact list of supported formats for this dialog (it also includes .gdc and .gde which are compiled IINM and likely not editable).
It could have more global filters:

All Script Formats (.gd, .vs, [.cs], .gdns)
All Resource Text Formats (.tres, .tres)
Other Text Formats (.txt, .cfg, .json, .yaml)   // I wouldn't include stuff like .import, .log, or .godot which are unlikely to be edited from there
All Files (*)

I'd let the users specify their whitelist, probably, as the user knows best what he wants to open with the script editor.
Whitelisting should also make those files appear in the file dock

Related to #21787

Could the filter detect and allow opening all UTF-8 plain text documents that aren't on the blacklist? It'd be better than just a plain blacklist, since you don't want to try opening a binary file.

Could be included as custom script extensión “.esc” from escoria framework too?
There’re still crazies like me trying to do something with it. 😄

Just wanted to mention that it's not possible to open a textfile resource by rightclicking on it in the FileSystem tab (v 3.1.1 Windows). The Open menu item does nothing. Opening it via File/Open in the texteditor works, though.
Looks like a bug/oversight. Can it be fixed within this issue, or should I create a new?

Just want to reiterate on the above, there are plenty of very good use-cases where you want to use something like a json / yaml / text file in a project. Things like storing data for loading at runtime,or something as simple as a readme for your project can be useful. Not being able to edit these in app makes godot (as an IDE) more obnoxious to use. Additionally to add to the above, json yaml and txt files aren't even showing in the project directory in godot itself, a good compromise might be a right click open option for text files that opens them in your system default text opener.
My current project use cases include:
A readme and changelog
Standardizing the game API to be modifiable via json file inclusions, this is to allow others to create add-ons to the game without touching the source code. With this the game has some default 'templates' that exist and are loaded in along with any user specified json templates.

Regarding the filesystem dock:
How about introducing a new button to the filesystem dock which toggles whether non-resource assets (*.txt, ...) are displayed. Godot internal files, like *.import, would still be hidden in this view which prevents unnecessary cluttering. I think the 'TextFile'-icon might be suitable for this. Here is a non-functional mock:

Another more advanced option could be using a menu button which allows toggling between e.g. the following three states:

Only Resources (this is what the dock currently shows)
Resources and Assets (includes non-resource assets like *.txt, *.json,..., but no internal files like the project file, *.import,...)
All files

This could also be implemented in an extensible way such that the user can add custom filtering configurations which can be selected from the menu.
One remark independent of these ideas: I thought that the filtering of the files to display in the dock is done in the FileSystemDock class, which would have made it very easy to implement this filter toggling. However, the hidden files are already filtered while creating the representation of the file system in EditorFileSystem. Hence, displaying more files in the FileSystemDock will require modifications in EditorFileSystem. I currently do not know why the files are already filtered in this class, maybe some parts of the editor expect only Resources from there?! If this is not the case, I think moving the filtering over to the FileSystemDock as part of the UX improvement would be a good idea.

These days I was messing on gdas and found this: https://godotengine.org/asset-library/asset/423


what is mmpl?

I am trying to adopt this method to mmdet, and learn more about  mmpl functions. What is 'mmpl' meaning? Is it from a open source project like mmdet and mmseg?  Or a self-build package for fine-tuning? Thanks.

I have release a new version with mmdetection


ExtJS v6

Hi - any plans to update this for ExtJS v6.x? Thanks in advance.

Sorry, I'm rarely working with ExtJS these days so I don't know enough about the changes in 5.x and 6.x to update it myself. I am happy to accept pull requests though, if you or someone else is so inclined!

Hey @burnnat - I'd be happy to contribute - just wondering if you ever ran ESlint in conjunction with Sencha Cmd or did you just run it in a separate process? Thanks in advance.

No, I always ran ESLint separately, either directly through the command or via editor/IDE integration.

A nice thread between @niallobrien and Mitchell Simoens on a way to incorporate ESLint into the build system. https://twitter.com/LikelyMitch/status/900009407685115904
I haven't tried it out yet as I'm just now looking into my options for ESLint in ExtJS 4 and 6.


Syntax Error: ValidationError: Invalid options object. Worker Loader has been initialized using an options object that does not match the API schema

Attach (recommended) or Link to PDF file here:
Configuration:

Web browser and its version: Chrome/98.0.4758.102
Operating system and its version: Mac OS X 10_15_7
PDF.js version: 2.6.347
Is a browser extension: no

Steps to reproduce the problem:

yarn add -D worker-loader
use worker-loader

What is the expected behavior? (add screenshot)
What went wrong? (add screenshot)

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

PDF.js version: 2.6.347

That version is no longer supported, please find the latest releases at https://mozilla.github.io/pdf.js/getting_started/#download

Steps to reproduce the problem:
1. yarn add -D worker-loader
2. use worker-loader

Please see https://github.com/mozilla/pdf.js/blob/master/.github/CONTRIBUTING.md (emphasis mine):

If you are developing a custom solution, first check the examples at https://github.com/mozilla/pdf.js#learning and search existing issues. If this does not help, please prepare a short well-documented example that demonstrates the problem and make it accessible online on your website, JS Bin, GitHub, etc. before opening a new issue or contacting us in the Matrix room -- keep in mind that just code snippets won't help us troubleshoot the problem.


Change parent image to openjdk

The official openjdk image is based on alpine, it is smaller than
the openjdk built by cantara.
Additionally, it supports multi-arch image and it allows to build the zipkin
docker images for other architectures.
Signed-off-by: Alice Frosi<EMAIL_ADDRESS>

On my system I built the docker image with and without the changes of the PR.
I squashed the two images  by using the flag --squash offered by docker build
Docker version:
$ Client:
 Version:      18.03.1-ce
 API version:  1.37
 Go version:   go1.9.5
 Git commit:   9ee9f40
 Built:        Thu Apr 26 07:17:38 2018
 OS/Arch:      linux/amd64
 Experimental: true
 Orchestrator: swarm

Server:
 Engine:
  Version:      18.03.1-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.5
  Git commit:   9ee9f40
  Built:        Thu Apr 26 07:15:45 2018
  OS/Arch:      linux/amd64
  Experimental: true

Build without changes:
$ docker build --squash -t openzipkin/jre-full:cantara .
Sending build context to Docker daemon  73.22kB
Step 1/6 : FROM cantara/alpine-zulu-jdk8
 ---> 82d6c0ad442e
Step 2/6 : MAINTAINER OpenZipkin "http://zipkin.io/"
 ---> Running in c514903bbc14
Removing intermediate container c514903bbc14
 ---> a1eda0f55143
Step 3/6 : RUN rm -rf /usr/local/java/bin /usr/local/java/lib /usr/local/java/include
 ---> Running in 7b27d46a1d3f
Removing intermediate container 7b27d46a1d3f
 ---> cd30716f3ae2
Step 4/6 : RUN ln -s /usr/local/java/jre/bin /usr/local/java/bin
 ---> Running in 72d19f1647ab
Removing intermediate container 72d19f1647ab
 ---> 47cf9b925539
Step 5/6 : RUN apk add --update --no-cache curl
 ---> Running in bfdac346a7bf
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
OK: 13 MiB in 18 packages
Removing intermediate container bfdac346a7bf
 ---> 4e133f552e16
Step 6/6 : RUN echo 'hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4' >> /etc/nsswitch.conf
 ---> Running in c1ea17375329
Removing intermediate container c1ea17375329
 ---> f91fbcfe11a4
Successfully built be1ccc01d201
Successfully tagged openzipkin/jre-full:cantara

Build with changes:
$ docker build --squash -t openzipkin/jre-full:openjdk .
Sending build context to Docker daemon  73.22kB
Step 1/5 : FROM openjdk:8-jdk-alpine
 ---> 224765a6bdbe
Step 2/5 : MAINTAINER OpenZipkin "http://zipkin.io/"
 ---> Running in dd4da5ceb0a2
Removing intermediate container dd4da5ceb0a2
 ---> 137a92510897
Step 3/5 : RUN rm -rf /usr/local/java/bin /usr/local/java/lib /usr/local/java/include
 ---> Running in d790d2afc889
Removing intermediate container d790d2afc889
 ---> 45f3161ac2ca
Step 4/5 : RUN apk add --update --no-cache curl
 ---> Running in 8dbc5d81d01e
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/community/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/community/x86_64/APKINDEX.tar.gz
(1/3) Installing libssh2 (1.8.0-r2)
(2/3) Installing libcurl (7.60.0-r0)
(3/3) Installing curl (7.60.0-r0)
Executing busybox-1.27.2-r7.trigger
OK: 100 MiB in 54 packages
Removing intermediate container 8dbc5d81d01e
 ---> d6ab589f720c
Step 5/5 : RUN echo 'hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4' >> /etc/nsswitch.conf
 ---> Running in 6123bff8d838
Removing intermediate container 6123bff8d838
 ---> 16daa380cbbc
Successfully built 0985e011e4fc
Successfully tagged openzipkin/jre-full:openjdk

Size:
$ docker images | grep openzipkin
openzipkin/jre-full                          openjdk                                    0985e011e4fc        9 minutes ago       104MB
openzipkin/jre-full                          cantara                                    be1ccc01d201        10 minutes ago      164MB

The PR solves the issue https://github.com/openzipkin/docker-jre-full/issues/7

Thanks for putting in the elbow grease! The only things on this PR besides verifying manually that the zipkin image still builds and runs :P... is likely a README update. We formerly had a heuristic to know which patch release something was.

ps we are just waiting for this to be a higher patch level than what we have now.

also we can consider JRE 9 I think. zipkin has no JRE 8 constraints afaik (cc @shakuzen)

whoot! we have a higher patch

thanks @alicefr @zeagord @shakuzen

I've recut the zipkin images which are now on this JRE. Thanks!

hey @alicefr looks like this image has stopped getting patches, and there's no clear signal a 11 version will come either. any ideas?

yes, but there isn't much that we can do. If the openjdk-jre 11 is not released for alpine. See https://bugs.alpinelinux.org/issues/8089


Batch sync commits

Can one of the admins verify this patch?

CI has passed

LGTM, except some commits for the same JIRA wasn't squashed; I manually merged them and pushed in master branch.


Backup to folder in email client ?

How do I get the backup to direct to an folder in an email client of my choosing ?

Hi @SheepDomination
Sorry, I'm not clear about what you want to do.
Do you want backups to be saved to a folder on your computer where they can can be read by your email client?

Hi @SheepDomination
Sorry, I'm not clear about what you want to do.
Do you want backups to be saved to a folder on your computer where they can can be read by your email client?

I want the backups to be sent to a folder for an account in a email client of choice ?

Hi @SheepDomination
Which email client do you want to use?
For Thunderbird there is an export command that takes the backed up emails and outputs a format that works with that client.
Allowing an email client to read imap-backup's backup directly will probably cause problems, as most email client modify the files on disk.
Without knowing which client you wish to use, it is difficult to help.

Hi @SheepDomination
Which email client do you want to use?
For Thunderbird there is an export command that takes the backed up emails and outputs a format that works with that client.
Allowing an email client to read imap-backup's backup directly will probably cause problems, as most email client modify the files on disk.
Without knowing which client you wish to use, it is difficult to help.

I want all email to be synced and backup to Mail Plus email client which exist on my NAS.

I've searched for a way to do this without much luck. I have the impression you would have to set up an import via the MailPlus user interface.

I've searched for a way to do this without much luck. I have the impression you would have to set up an import via the MailPlus user interface.

I did get the Sync to work except it placed not all the emails, it missed about 200 into a folder based on the email address instead of the inbox for Mail Plus. I'm not sure if that had anything to do with Mail Plus Server but I didn't really set up Mail Plus Server other then setup the domain for which I wanted to run IMAP Sync with.
This email account which I'm using has been down for almost three months and its my primary email account, so I don't know what email is bouncing back or that has been stopped. I guess it depends on the server sending the mail. It did work, I just don't understand why if I setup mail plus for this primary email account, why did IMAP Sync place all the emails except 200 although they are still on the mail server all the emails, into a folder based on the email account name, instead of Mail Plus Inbox ?


NETOBSERV-1223: check Maps to make sure not nil b4 iterating

there is some behavior difference with maps between rhel8 and rhel9
on rhel8 it seems maps not even allocated until its populated leading to this issue while in rhel9 that doesn't seem to be the case.
To be on safe side lets make sure maps pointer is != nil before doing invoking Iterate

/ok-to-test

/label qe-approved

/approve


Next release

Coverage remained the same at 100.0% when pulling 76266a2534d5fbba8fca9f1c5beb06c83c578cff on next_release into b344862625a6c6f89333c3717e6a6948b3e9cc2c on master.


Vec.fill(n){e} and Vec(n,e) confusion, especially in IO Bundles.

I have code that works in Chisel2, and makes it through Chisel3 generation, but errors out early in FIRRTL (actually, it was a FIRRTL compiler exception, but a new fix to FIRRTL catches the error now).
The code:
class ExecutionUnitIO(num_rf_read_ports: Int
                     , num_rf_write_ports: Int
                     , num_bypass_ports: Int
                     , data_width: Int
                     )(implicit p: Parameters) extends BoomBundle()(p)
{
   val resp    = Vec.fill(num_rf_write_ports) { new DecoupledIO(new ExeUnitResp(data_width)) }
   // and the fix, commented out...
   // val resp    = Vec(num_rf_write_ports, new DecoupledIO(new ExeUnitResp(data_width)))

The error:
[INFO] Starting Chirrtl Check
Exception in thread "main" firrtl.passes.PassExceptions:
firrtl.passes.CheckChirrtl$UndeclaredReferenceException$1:  @[execute.scala 52:47]:
  [module ALUExeUnit] Reference T_829 is not declared.

The fix:
Switch from Vec.fill(n){e} to Vec(n,e).
The request:
I think it is mandatory that this be caught in Chisel3 before making it to FIRRTL.
It'd also be great if this was caught in the compatibility checker in Chisel2.

I think this is supposed to work in Chisel3. See #104 and #109 where Vec(n,e) was patched but as a "Temporary fix" and hence wasn't extended to fill.

This error is still occurring with current master

Superseded by #445, we will explicitly separate chisel type and hardware constructors.


View Transition API

Feature Request
View Transition API "built-in" to Dioxus Router via Link as in opt-in
Implement Suggestion
N/A

The browsers view transition API seems like a good way to support #656. Some javascript frameworks like astro already support view transitions as first party concept. Astros API for view transitions also supports persisting elements like videos between pages which could be very useful


Added Problem Equinox

Description
Greetings sir/ma'am,
I am LGMSOC participant I have added the code for CodeChef problem asked in div3
Checklist:

[x] My code follows the style guidelines(Clean Code) of this project

[x] I have performed a self-review of my own code

[ ] I have commented my code, particularly in hard-to-understand areas

[ ] I have made corresponding changes to the documentation

[ ] My changes generate no new warnings

[ ] I have added tests/screenshots(if any) that prove my fix is effective or that my feature works

Mention Your Issue


use of python 3.10

can the latest version of python 3.10 would be used in setup.py

Python 3.10 is now supported.


[FEATURE] Sprite Batcher scaling should account for texture size.

Description
Right now, the SpriteBatcher batches draw calls and doesn't account for the default texture size, see here. Personally, I think that providing a scale of one should result in a 1:1 ratio, where the drawn texture is the same size as the texture on disk.
The Why
Usually scalars will make life much easier when drawing simple, already scaled textures to the screen.
The How
All we really have to do is change the method signature to take in two int parameters that represent the default width and height of the texture on disk.
public void Batch(float textureSlotIndex, float textureWidth, float textureHeight, Color color, Vector2 origin, Vector2 position, float rotation, Vector2 scale)
{
...
var w = scale.X * textureWidth;
var h = scale.Y * textureHeight;
...
}

## Requirements

None.

## Possible Issues

None, except maybe a lengthy method signature.

Ehh, kinda decided against this when I realized that drawing a sprite at it's origin would be all out of whack and a bit of a hassle to solve. It's probably better to define the drawing of the sprite in pixels anyways.