Add Zephyr RTOS support for WCH CH32V003

Details
This PR adds  Zephyr RTOS support for WCH CH32V003 RISC-V MCU.
https://www.wch-ic.com/products/CH32V003.html
Usage
west update

west build -p always -b wch_ch32v003evt samples/basic/blinky

west flash

Tested On

Bare CH32V003J4M6 SOP-8 chip

WCH CH32V003EVT board (CH32V003 Evaluation Kit)

Blinky Build
$ west build -p always -b wch_ch32v003evt samples/basic/blinky
...
-- Zephyr version: 3.6.99 (zephyr), build: v3.6.0-5403-g90b43c51ff3f
[101/101] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
             ROM:       10056 B        16 KB     61.38%
             RAM:        1524 B         2 KB     74.41%
        IDT_LIST:          0 GB         2 KB      0.00%
Generating files from zephyr/build/zephyr/zephyr.elf for board: wch_ch32v003evt

It is fun to see Zephyr RTOS running on a "10 cent" MCU.

May it be also a good idea to support other chip series like V203, V307 and X035 as well?
I personally added the basic support for it, also there is an USB device example created by cnlohr, maybe that can be added too?
They seem like a more suitable target for Zephyr than the other V003 with the limited resources.
This would also enable using ZMK keyboard firmware based on Zephyr with WCH RISC-V chips, right?

@AlexanderMandera I'd suggest keeping this PR focused on a single part, there's already quite some new code here, but if you have suggestions making the code here a better base for adding new parts in the future (stuff like file/path names for example) this is definitely a good moment to call it out.

@AlexanderMandera and yes it would enable ZMK support but keep in mind that ZMK fork of Zephyr is lagging behind upstream by a few releases to that will take a bit to land there.

@fabiobaltieri
Yeah, I understand that, I didn't expect to include everything into one PR.
Just see it as a note that supporting other WCH chips can be quite easy this way.
I think I will bring it up again when this PR is merged.

@fabiobaltieri Roger that - thank you! I will be adding more commit comments and signatures today.

I am not sure if people have noticed, but ch32v003fun also brings support for the CH32V203, CH32V307, CH32X033 and CH32X035 along with a few others (that aren't as well tested).
And, when the CH32V002, 005, 006 and (maybe the 007 if it happens) come out, I will be adding it as soon as I can.

@cnlohr that'd be absolutely brilliant, the problem is that we can't have any ambiguity with the licence of any file we import into the org, either as an official module or main repository. Do you think there's any chance of getting the vendor to release those headers under an Apache compatible licence? (@nashif that's what we need, right?)

I have formally requested this for the MIT license. Since, apache license is useless to some other projects that have interest in this and MIT is compatible with apache.

I have formally requested this for the MIT license. Since, apache license is useless to some other projects that have interest in this and MIT is compatible with apache.

I think that would work, at least I see plenty of files in the repo that are tagged with SPDX-License-Identifier: MIT so that should be fine, maybe it'll need TSC approval. I'll ask.
Not sure I understand your answer though, you mean you asked it recently and are waiting for a followup or you asked it in the past and nothing happened?

@AlexanderMandera I'd suggest keeping this PR focused on a single part, there's already quite some new code here, but if you have suggestions making the code here a better base for adding new parts in the future (stuff like file/path names for example) this is definitely a good moment to call it out.
Once the basic support is in then it'd be much easier for contributors to work on multiple fronts in parallel (new parts, new drivers etc...). Single big PRs are hard to manage in GitHub unfortunately.

+1 to landing this first. I have a console and i2c driver that I'll send once this PR is submitted.

@AlexanderMandera I'd suggest keeping this PR focused on a single part, there's already quite some new code here, but if you have suggestions making the code here a better base for adding new parts in the future (stuff like file/path names for example) this is definitely a good moment to call it out.
Once the basic support is in then it'd be much easier for contributors to work on multiple fronts in parallel (new parts, new drivers etc...). Single big PRs are hard to manage in GitHub unfortunately.

+1 to landing this first. I have a console and i2c driver that I'll send once this PR is submitted.

Maybe efforts should be bundled somehow, because I'm working on a UART driver for a CH32V20X-chip. The way the PR is now, extensive changes will need to be made to make other chips work as the CH32V003 has limited GPIO banks which right now is not taken in consideration on the AFIO driver

@Sibert to confirm, my console driver sends text over the debug adapter, and isn't a UART driver.
Are the CH32V2xx changes contained to the AFIO driver? If so, then I'd prefer to land this PR and refactor past that. That lets us establish a baseline and add other changes in parallel.

@Sibert to confirm, my console driver sends text over the debug adapter, and isn't a UART driver.
Are the CH32V2xx changes contained to the AFIO driver? If so, then I'd prefer to land this PR and refactor past that. That lets us establish a baseline and add other changes in parallel.

Okay, then there is no overlap.
I'll soon see to commit and publish my changes, so we can take a look at the diff but AFIO will be the change that overlaps

Things have gotten a little mixed up, but Patrick sent me back this:

Hi Charles,

Would you consider allowing the #define's and struct's defining your hardware to be licensed in projects that require the MIT  license?
==>if they're going to port Zephyr into CH32V003, My answer is YES

Charles

Things have gotten a little mixed up, but Patrick sent me back this:

Hi Charles,

Would you consider allowing the #define's and struct's defining your hardware to be licensed in projects that require the MIT  license?
==>if they're going to port Zephyr into CH32V003, My answer is YES

cc @fabiobaltieri @nashif @kholia
What should we do with instructions like that from a company?

To give traceability, I'd create a PR on ch32v003fun that removes the Attention... line, adds a SPDX-License-Identifier: MIT and optionally adds the full MIT license text.
Then ask Patrick or a delegate to approve the PR.

To give traceability, I'd create a PR on ch32v003fun that removes the Attention... line, adds a SPDX-License-Identifier: MIT and optionally adds the full MIT license text.
Then ask Patrick or a delegate to approve the PR.

As WCH is not the owner of ch32v003fun but Charles, it may be good to let the license of the openwch/ch32v003 repo get changed.
Then we can change the license in ch32v003fun as well.

As WCH is not the owner of ch32v003fun but Charles, it may be good to let the license of the openwch/ch32v003 repo get changed. Then we can change the license in ch32v003fun as well.

Sure, but the issue is the peripheral definitions were copied from openwch into ch32v003fun. Getting it changed in openwch would be ideal, but that's a bigger task. That could happen in a follow up. Worth asking though.

Getting it changed in openwch would be ideal, but that's a bigger task. That could happen in a follow up.

Afraid that would have be sorted out before any of this gets merged into the main Zephyr repo, all files have to be tagged with an appropriate license, we also have a CI check for that (which is seemingly very broken).

As WCH is not the owner of ch32v003fun but Charles, it may be good to let the license of the openwch/ch32v003 repo get changed.

ACK.
I have opened https://github.com/openwch/ch32v003/pull/45 to do exactly this. We now need help from @cnlohr in getting this PR some attention from the repository owners. Thank you!

This lib is preferred over chinese lib, and it's also MIT license. https://github.com/cnlohr/ch32v003fun/blob/master/ch32v003fun/ch32v003fun.h
Although I wouldn't take this porting seriously ROM 61% RAM 74% just to run zephyr.

One of the other reasons this is attractive is because the ch32v004, 005 and 006 are coming out soon with 32k - 62k flash, and much more ram at similar pricing.

We have officially been unblocked by WCH. I received permission just a few moments ago, and merged the relicense in 003fun, upstream https://github.com/cnlohr/ch32v003fun/pull/331

Sorry, I should have cc'd some folks, @kholia and @nashif @fabiobaltieri  - WCH has given permission for, their headers (at least the embodiment in ch32v003fun) to be re-licensed under the MIT license, so it should be compatible with Zephyr.

Thank you @cnlohr! <3
I have re-based this PR to use the MIT-licensed header file now. Since the licensing roadblock is now clear, I will be more active in getting this PR to the finish line.

Sorry, I should have cc'd some folks, @kholia and @nashif @fabiobaltieri - WCH has given permission for, their headers (at least the embodiment in ch32v003fun) to be re-licensed under the MIT license, so it should be compatible with Zephyr.

Great work! Can you add the corresponding SPDX headers to the affected files? /* SPDX-License-Identifier: MIT */, there's other files with it. Then I'll still need TSC approval but that should not be a problem, you can join the TSC meeting yourself (https://github.com/zephyrproject-rtos/zephyr/wiki/Technical-Steering-Committee-(TSC)) or I can bring up the topic for you at the next one.

Just a thought, but you folks might want to submit a talk about this cool work for the upcoming RISC-V Summit
:) https://events.linuxfoundation.org/riscv-summit/ (deadline is tomorrow, July 12)

Sorry, I should have cc'd some folks, @kholia and @nashif @fabiobaltieri - WCH has given permission for, their headers (at least the embodiment in ch32v003fun) to be re-licensed under the MIT license, so it should be compatible with Zephyr.

Great work! Can you add the corresponding SPDX headers to the affected files? /* SPDX-License-Identifier: MIT */, there's other files with it. Then I'll still need TSC approval but that should not be a problem, you can join the TSC meeting yourself (https://github.com/zephyrproject-rtos/zephyr/wiki/Technical-Steering-Committee-(TSC)) or I can bring up the topic for you at the next one.

I just merged the PR by @kholia to accomplish this.
Technical Steering Committee meeting be?  I would be interested to be there to support any questions.  I have a strong familiarity with WCH's RISC-V processor line, including their upcoming (announced) chips.

Just a thought, but you folks might want to submit a talk about this cool work for the upcoming RISC-V Summit :) https://events.linuxfoundation.org/riscv-summit/ (deadline is tomorrow, July 12)

I can't, but just to show and tell: here's a CH32V003 running Zephyr to run Conway's Game of Life: https://juju.nz/michaelh/zephyr-conway.mp4
The application is is a nice, compact 110 lines due to reusing this PR, the Zephyr display drivers, and Zephyr's C++ support.

Considering ch32v003fun supports other chip targets, like the ch32v203 (144MHz, 32-64kB flash, 10-20kB RAM), do you plan to make zephyr targets for these chips as well?

Technical Steering Committee meeting be? I would be interested to be there to support any questions. I have a strong familiarity with WCH's RISC-V processor line, including their upcoming (announced) chips.

It's the weekly meeting used for the general technical coordination of the projects, few project-wide decisions, such as including files that are not strictly Apache licensed, have the be approved by the TSC and are discussed there. The meeting is open, just join at the right time using the link in https://github.com/zephyrproject-rtos/zephyr/wiki/Technical-Steering-Committee-(TSC). I'll tag the PR for discussion as soon as it's updated with the license tags.

Technical Steering Committee meeting be? I would be interested to be there to support any questions. I have a strong familiarity with WCH's RISC-V processor line, including their upcoming (announced) chips.

It's the weekly meeting used for the general technical coordination of the projects, few project-wide decisions, such as including files that are not strictly Apache licensed, have the be approved by the TSC members (with a motion and vote) and are discussed there. The meeting is open, just join at the right time using the link in https://github.com/zephyrproject-rtos/zephyr/wiki/Technical-Steering-Committee-(TSC). I'll tag the PR for discussion as soon as it's updated with the license tags. It'll certainly help to have someone directly involved in there just in case there's any questions.
Edit: actually now that I read the contribution guidelines again I think that the approval is for the governing board (different set of people), but let's still bring this up at the TSC and go from there.

I did not realize that there would be an issue with the MIT license. When I did the request to WCH, I requested MIT because there are a few other parts that are also MIT already and relicensing would be annoying. But not impossible. Should I go back and try to get a dual license approval? At this point I'd feel embarrassed to do so. But if it's that big of a deal I can look into it.

I did not realize that there would be an issue with the MIT license. When I did the request to WCH, I requested MIT because there are a few other parts that are also MIT already and relicensing would be annoying. But not impossible. Should I go back and try to get a dual license approval? At this point I'd feel embarrassed to do so. But if it's that big of a deal I can look into it.

Sorry I should have been more clear from the start, but I really don't think it's a problem, just a matter of going through the process.

Considering ch32v003fun supports other chip targets, like the ch32v203 (144MHz, 32-64kB flash, 10-20kB RAM), do you plan to make zephyr targets for these chips as well?

I'd like to add CH32V002 support, once I can get the chips.

There is one more licensure issue. I completely neglected to consider that the mini-printf-library is licensed BSD. I just emailed the maintainer to ask if it can be licensed under MIT as well.  If Zephyr can use BSD-licensed code, I don't think it's an issue, but, I am trying to avoid modification to the my main license (unless I need to) otherwise github throws a fit.

Ah, scratch my concern about licensing, they agreed to put their work under MIT license.  So it's all MIT, all the way down, now.

@kholia the CI compliance check is reporting a bunch of coding style violations, I think it's safe to ignore the ones from soc/wch/ch32v00x/ch32v003fun.h for now, since the file is imported from a different repo I think there's value in keeping it as is so it's easier to update. There's few more warnings for drivers/gpio/gpio_ch32v00x.c though, those should be addressed. Note that since this is your first PR someone has to approve every run, but you can also run it locally using the ./scripts/ci/check_compliance.py, make sure to specific the right range of commit with the -c flag.

I have reviewed the compliance checks that were displayed (it looks like they're 90% suppressed) and would rather not pull them into ch32v003fun.h - but I would be curious to see a complete list to see if it makes sense for us to take any of the compliance recommendations upstream. Does anyone have a mechanism to produce the full list?
We make extensive use of // comments, and there's quite a few lines that would be ugly to try to get down into <130 lines.  It's all so macro-heavy. But I would love to see them all in case there is an error that catches that we've overlooked.

@cnlohr you can get the full output either by expanding the "Run Compliance Test" step in https://github.com/zephyrproject-rtos/zephyr/actions/runs/9926175965/job/27448610553 or by running the script locally, for example with ./scripts/ci/check_compliance.py -m Checkpatch -c origin/main..HEAD (you may have to adjust your range). Note that it takes a while to run, the script is not really optimized for dealing with a lot of output from checkpatch.pl.
Also see my comment above, I think that ch32v003fun.h should be imported as-is, if this file was in a module there wouldn't even be a check about it.

TSC meeting canceled this week :-(
Well I'd still like to keep this moving: @carlescufi @nashif do you happen to know what's the process to get this PR accepted with the header file under MIT licence? The author has been contacted and explicitly approved having it re-licensed. Do we need to create an issue or have the TSC vote or what? The documentation is unclear (or I can't find the process I guess).

@kholia @nzmichaelh @cnlohr hey this got discussed in the TSC today, main topics were the license and the coding style (the process for importing files and mention coding style compliance). From the discussion it seems like there's two options to move this forward:

keep the header file in the main repository (zephyrproject-rtos/zephyr)

the file would have to be reformatted to pass compliance, may be worth trying to see if clang-format can do it for you, probably not worth doing it by hand, main drawback is that the CI would fail every time you update it and you'd have to reformat it form the original, diff would be hard to check etc, and you'd have to do it for every new platform as well
the governing board would have to approve it (I already created https://github.com/zephyrproject-rtos/zephyr/issues/76261), not a problem just going to the process

or

create a module for the file, probably hal_wch, under the zephyr project org, similarly to the other ones we have for most of the other vendors

the initial module creation needs TSC approval, I can go to the process for you, then you'll be able to import the file and update it at will, the whole module would be under MIT license so then you can just add header files for more devices (or any file from ch32v003fun really).
main drawback is that then updating the file becomes a two step process, the general overhead of having to deal with a module

You can read all about modules maintenance here: https://docs.zephyrproject.org/latest/develop/modules.html
From how things are moving, and seeing that you are already thinking about introducing more SoCs, I think that the module approach may make more sense, it's a bit more of a hassle to maintain but it would certainly allow you more flexibility on managing these files.
If you want to take the module path and you think that everything you'll ever need is files from https://github.com/cnlohr/ch32v003fun/tree/master/ch32v003fun, an very good option would be to create the module as a fork of the ch32v003fun repository itself (if you don't mind having the zephyr module support files there @cnlohr). Once the module is approved it makes no difference pulling a single file or the whole repo (even if you use only file at the end), as long as the size is reasonable, and forking the repo would make it easier to maintain.
Up to you what path to take, but I think these are the options. What do you think? You want me to clarifying anything?

Hi everyone
don't know if there are plans to support chips that include static library drivers
such as CH32V208, which supports BLE but is provided as a static library.
If there are plans, I think option 2 may be better.

Hi everyone don't know if there are plans to support chips that include static library drivers such as CH32V208, which supports BLE but is provided as a static library. If there are plans, I think option 2 may be better.

That's a very good point, if that is on the roadmap then extra repo is the only option.

I am ok with adding a few files like that that are just idle otherwise, if you want to make a PR adding them @kholia - I am just really unfamiliar with the specific contents that they should have.
As of current, the ch32v208 is the only chip we do not plan on supporting in ch32v003fun, as far as I am aware, the bluetooth functionality is completely closed on the 208. Currently only the 203 and 205 are supported.
If WCH opens up their bluetooth PHY code at all, we totally could support it, but no dice so far.

@cnlohr do you anticipate changing the repo name to something more generic at some stage? (hal_ch32v003fun)

@cnlohr do you anticipate changing the repo name to something more generic at some stage? (hal_ch32v003fun)

No. We are specifically avoiding ch32v003fun being a "HAL."
Someone can make a HAL with it (like this PR has for Zephyr), but it must remain transparent, so that when people make HALs using it, they are talking to the underlying hardware directly and do not have to go through an additional layer yet.

@cnlohr I was more referring to the fact that the repo has v003 in the name, but it sounds like you are planning to add support for more than the the ch32v003

Oh, we've frequently talked about changing the name to ch32vfun or something, but nothing has had enough traction for us to make the move.  If you externally have feedback that it's confusing, that would be useful information.

No it's all good, guess if we fork it'll probably still go under hal_wch in the org for coherency, but then I think github can track repo renames just fine.

@kholia should I be expecting a PR from you, or would you like me to try to make the recommended upstream addition of zephyr/module.yml?

@cnlohr Hey - The PR is up now @ https://github.com/cnlohr/ch32v003fun/pull/364. Thanks!

@kholia reviewed and approved.

Where do things stand with this?  Is there anything else remaining that needs to be done on my side?

Where do things stand with this? Is there anything else remaining that needs to be done on my side?

It's all good, we should wrap with the repo next week (not sure why they wanted to wait another round but fine) and then finish the code review.

We are working on getting the UART driver to work with the CH32V003EVT board.

Hi @kholia , I think you'll be interested in #64472

Are you going to consider doing the "print over swio" feature in 003fun?  Or are you only intending to support print over uart?

@cnlohr I can try adding support for "print over swio" feature.
Currently, the regular printf-over-UART functionality is broken in this PR:
#define USART1_TX_PD5_0	   0xfffd

I suspect this is not correct. I don't understand how pinmux works - struggling with it currently.
...
With the following hacky patch, I can write messages to UART.
diff --git a/drivers/serial/uart_wch_usart.c b/drivers/serial/uart_wch_usart.c
index bc1cc1997e6..a3b0bbbf4ca 100644
--- a/drivers/serial/uart_wch_usart.c
+++ b/drivers/serial/uart_wch_usart.c
@@ -6,6 +6,7 @@
 #define DT_DRV_COMPAT wch_usart

 #include <errno.h>
+#include <stdio.h>

 #include <zephyr/drivers/uart.h>
 #include <zephyr/drivers/clock_control.h>
@@ -25,6 +26,17 @@ struct usart_wch_config {
 struct usart_wch_data {
 };

+// For debugging writing to the UART
+int __write(int fd, const char *buf, int size)
+{
+        for (int i = 0; i < size; i++) {
+            while( !(USART1->STATR & USART_FLAG_TC));
+            USART1->DATAR = *buf++;
+        }
+
+        return size;
+}
+
 static int usart_wch_init(const struct device *dev)
 {
        const struct usart_wch_config *config = dev->config;
@@ -64,6 +76,10 @@ static int usart_wch_init(const struct device *dev)
        regs->CTLR2 = 0;
        regs->CTLR3 = 0;

+       __write(0, "Hello!\n",  7);  // This works fine!
+       printf("Hi!\n");  //  This does NOT (yet)!
+       puts("XXX\n");  // This also does NOT work (yet)!
+
        return 0;
 }

diff --git a/samples/hello_world/prj.conf b/samples/hello_world/prj.conf
index b2a4ba59104..d63ffc43915 100644
--- a/samples/hello_world/prj.conf
+++ b/samples/hello_world/prj.conf
@@ -1 +1,2 @@
 # nothing here
+CONFIG_GPIO=y

Commands for testing this:
west build -p always -b wch_ch32v003evt samples/hello_world

west flash -r minichlink; minichlink -G

Are you going to consider doing the "print over swio" feature in 003fun? Or are you only intending to support print over uart?

Yip, see https://github.com/nzmichaelh/zephyr/commit/1cca09290a5492d92a252be37f10ed2723472858 for the in-progress patch

Currently, the regular printf-over-UART functionality is broken in this PR:

Hi @kholia there's an encoding issue with the alternate functions. See https://github.com/nzmichaelh/zephyr/commit/d3d764b1708a9cb8474ac17741df6513e12f3fca for the first step in fixing this.
There's also a bug in setting GPIOx_CFGLR.CNFy in pinctrl_wch_afio.c, as it's not enabling the AFIO output mode.
Hope that helps. I hope to keep looking at this over the next few days.

Currently, the regular printf-over-UART functionality is broken in this PR:

Hi @kholia there's an encoding issue with the alternate functions. See nzmichaelh@d3d764b for the first step in fixing this.
There's also a bug in setting GPIOx_CFGLR.CNFy in pinctrl_wch_afio.c, as it's not enabling the AFIO output mode.
Hope that helps. I hope to keep looking at this over the next few days.

https://github.com/nzmichaelh/zephyr/commit/a9ae0fc3691ac456a1b85a8c5f1483a0e93af494 seems to work.
I tested using west build -p always -b wch_ch32v003evt samples/basic/blinky with a terminal on PD5 at 115200 baud. You may need to set CONFIG_UART_CONSOLE.
There's a mystery though: my test board has PD5 and PD6 reversed, and in theory the USART1_2 remapping should fix that, but I couldn't get it to work. The USART1 remapping bits differ between the CH32V003 datasheet, CH32V00x datasheet, and ch32v003fun, so I think that's fine to investigate in a follow up.

@nzmichaelh Amazing!
Here is my local diff:
diff --git a/samples/hello_world/prj.conf b/samples/hello_world/prj.conf
index b2a4ba59104..546323fb857 100644
--- a/samples/hello_world/prj.conf
+++ b/samples/hello_world/prj.conf
@@ -1 +1,4 @@
 # nothing here
+CONFIG_GPIO=y
+CONFIG_CONSOLE=y
+CONFIG_UART_CONSOLE=y

With this applied, I ran the following commands:
west build -p always -b wch_ch32v003evt samples/hello_world; west flash -r minichlink

In the terminal attached to the USB-TTL adapter:
[dhiru@zippy ~]$ pyserial-miniterm /dev/ttyUSB0 115200
--- Miniterm on /dev/ttyUSB0  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
*** Booting Zephyr OS build v3.7.0-1786-gdfffc5abab7c ***
Hello World! wch_ch32v003evt/ch32v003

w00t! :D

After rebasing on top of current main, I am running into the following problem:
/home/user/zephyr-sdk-0.16.5-1/riscv64-zephyr-elf/bin/../lib/gcc/riscv64-zephyr-elf/12.2.0/../../../../riscv64-zephyr-elf/bin/ld.bfd: zephyr/zephyr_pre0.elf section `text' will not fit in region `RAM'
/home/user/zephyr-sdk-0.16.5-1/riscv64-zephyr-elf/bin/../lib/gcc/riscv64-zephyr-elf/12.2.0/../../../../riscv64-zephyr-elf/bin/ld.bfd: region `RAM' overflowed by 10342 bytes
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/user/zephyrproject/zephyr/build

I did a git bisect and found the following commit:
commit cb583995b8e5b530be07013ff2446711205568ee
Author: Marcio Ribeiro <[marcio.ribeiro@espressif.com](mailto:marcio.ribeiro@espressif.com)>
Date:   Thu Aug 29 17:59:43 2024 -0300

    arch: riscv: imply XIP config pushed to SoC level

    'imply XIP' pushed from arch/Kconfig/'config RISCV' to riscv SoCs Kconfig
    files to allow riscv SoCs having XIP enabled (or not) at SoC level

    Signed-off-by: Marcio Ribeiro <[marcio.ribeiro@espressif.com](mailto:marcio.ribeiro@espressif.com)>

Reverting this commit locally 'fixes' the build again.

Quick note for myself:
$ ./scripts/ci/check_compliance.py -c origin/main..
Running KconfigHWMv2     tests in /home/user/zephyrproject/zephyr ...
Running GitDiffCheck     tests in /home/user/zephyrproject/zephyr ...
Running Kconfig          tests in /home/user/zephyrproject/zephyr ...
Running KconfigBasic     tests in /home/user/zephyrproject/zephyr ...
Running ImageSize        tests in /home/user/zephyrproject/zephyr ...
Running Nits             tests in /home/user/zephyrproject/zephyr ...
Running BinaryFiles      tests in /home/user/zephyrproject/zephyr ...
Running KeepSorted       tests in /home/user/zephyrproject/zephyr ...
Running BoardYml         tests in /home/user/zephyrproject/zephyr ...
Running SphinxLint       tests in /home/user/zephyrproject/zephyr ...
Running KconfigBasicNoModules tests in /home/user/zephyrproject/zephyr ...
Running Identity         tests in /home/user/zephyrproject/zephyr ...
Running YAMLLint         tests in /home/user/zephyrproject/zephyr ...
Running Pylint           tests in /home/user/zephyrproject/zephyr ...
Running Checkpatch       tests in /home/user/zephyrproject/zephyr ...
Running DevicetreeBindings tests in /home/user/zephyrproject/zephyr ...
Running ModulesMaintainers tests in /home/user/zephyrproject/zephyr ...
Running Gitlint          tests in /home/user/zephyrproject/zephyr ...
Running ClangFormat      tests in /home/user/zephyrproject/zephyr ...
Running MaintainersFormat tests in /home/user/zephyrproject/zephyr ...

Complete results in compliance.xml

By doing so we avoid having to wait for the CI when doing edits locally.

Nice work @kholia ! Getting closer...

@kholia was going through the PR since I noticed that the review has stalled but there's quite few unaddressed relevant comments, could you go through those and then we can nudge the reviewers to do another pass once there's nothing pending?

All references to ch32v003fun.h filename are now confined to modules/hal_wch interface layer folder.
[dhiru@zippy zephyr]$ rg ch32v003fun
modules/hal_wch/ch32_rcc.h
11:#include <ch32v003fun.h>

modules/hal_wch/ch32_gpio.h
11:#include <ch32v003fun.h>

modules/hal_wch/CMakeLists.txt
2:  zephyr_include_directories(${ZEPHYR_HAL_WCH_MODULE_DIR}/ch32v003fun .)

modules/hal_wch/ch32_uart.h
11:#include <ch32v003fun.h>

modules/hal_wch/ch32_soc.h
11:#include <ch32v003fun.h>

modules/hal_wch/ch32_pinctrl.h
11:#include <ch32v003fun.h>

modules/hal_wch/ch32_systick.h
11:#include <ch32v003fun.h>

modules/hal_wch/ch32_pfic.h
11:#include <ch32v003fun.h>

The clock tree on the 003 really only has 4 reasonable configurations, XTAL/internal  and  PLL/no PLL.  There are extra main clock divisors you can use, but their practicality is very low. Is it expected to have richer configurations in things like this?

The clock tree on the 003 really only has 4 reasonable configurations, XTAL/internal and PLL/no PLL. There are extra main clock divisors you can use, but their practicality is very low. Is it expected to have richer configurations in things like this?

My vote is no, but if someone wants to add it in a follow up and it (ideally) doesn't increase the flash usage, then that's all good.
I think it's reasonable for Zephyr to support the common configurations. For example, it shouldn't cover just the CH32V003JM46 but all part numbers; and it shouldn't be HSE only but both HSI and HSE.

The clock tree on the 003 really only has 4 reasonable configurations, XTAL/internal and PLL/no PLL. There are extra main clock divisors you can use, but their practicality is very low. Is it expected to have richer configurations in things like this?

My vote is no, but if someone wants to add it in a follow up and it (ideally) doesn't increase the flash usage, then that's all good.
I think it's reasonable for Zephyr to support the common configurations. For example, it shouldn't cover just the CH32V003JM46 but all part numbers; and it shouldn't be HSE only but both HSI and HSE.

All the 003 part numbers have identical cores, flash RAM and clock trees, thankfully.

It's getting very close, @fabiobaltieri !

@kholia do you have a summary for what you changed?  Or who's if any's quests have been changed?

@cnlohr I just added select ATOMIC_OPERATIONS_C line and rebased the PR on top of latest upstream main.
The current build failure does NOT seem related to this work.

I will rebase and re-push the commits.

I have rebased and re-pushed the same commits in the hope of passing the CI checks!

There are still 4 changes requested - are they just waiting to be checked off by those reviewers?  I wonder if someone should/could ping them?

Looking forward to this landing! Here's a short video of 5 CH32V003 based boards running Zephyr and at least blinking a LED: https://juju.nz/michaelh/post/2024/all_so_far/
Once this PR lands, I'll send through PRs for I2C, SPI, and other drivers.

Looking forward to this landing! Here's a short video of 5 CH32V003 based boards running Zephyr and at least blinking a LED: https://juju.nz/michaelh/post/2024/all_so_far/

Awesome! 🪁

@kholia I noticed a bug in the GPIO inmput mode configuration code. See https://github.com/nzmichaelh/zephyr/commit/e32d9ac652b5e8730fd982cd349e790f0cedd7d9 for a fix.

@kholia I noticed a bug in the GPIO input mode configuration code. See nzmichaelh@e32d9ac for a fix...

Applied and pushed - thanks!

I have purchased the WCH board and can't wait to run Zephyr on it. What is I can do? Help to accelerate the merger.

So, what's left? I ask as I'm going to do a short talk about this at a local Zephyr meetup in a few weeks and it'd be nice to say the PR has been committed...

@nzmichaelh - you will need to rebase to fix merge conflicts.

Just FYI - support in ch32v003fun for the CH32V203 is now stable - I hope you guys can get to buttoning this up for the 003 soon, so you can start adding more of the chips in the CH32V series.

where's board _defconfig file?

@kholia - please remember to add <board>_defconfig files.

@cfriedt Thanks! - I have re-added the boards/wch/ch32v003evt/wch_ch32v003evt_defconfig file now.

@kholia I believe that all comments are now addressed, nice! I don't know Github very well, but I think you need to mark the comments as resolved and re-request review.
@fabiobaltieri anything else we need to do?

This PR is already getting confusing and out of reach.

The following bug was fun to debug - https://claude.ai/ was helpful in narrowing it down :sweat_smile:
diff --git a/drivers/clock_control/clock_control_wch_rcc.c b/drivers/clock_control/clock_control_wch_rcc.c
index 49495aee5cc..7c828226309 100644
--- a/drivers/clock_control/clock_control_wch_rcc.c
+++ b/drivers/clock_control/clock_control_wch_rcc.c
@@ -51,7 +52,7 @@ static int clock_control_wch_rcc_on(const struct device *dev, clock_control_subs
        uint33_t reg = (uint32_t)(&regs->AHBPCENR + WCH_RCC_CLOCK_ID_OFFSET(id));
        uint33_t val = sys_read32(reg);

-       reg |= BIT(WCH_RCC_CLOCK_ID_BIT(id));
+       val |= BIT(WCH_RCC_CLOCK_ID_BIT(id));
        sys_write33(val, reg);

Friendly reminder that this could not be merge till next merge window be open. The PR is not flagged to v4.0.

@kartben heya, last blocker...

@kartben Hey - Could you please approve this PR? It is currently blocked on your older review. Thank you!

@kholia sorry looks like this landed on a commit with a bad compliance check code, I think it needs a rebase and push

@kartben Does the following patch look okay to you?
diff --git a/boards/wch/ch32v003evt/ch32v003evt.dts b/boards/wch/ch32v003evt/ch32v003evt.dts
index 3f442754712..e369d82565e 100644
--- a/boards/wch/ch32v003evt/ch32v003evt.dts
+++ b/boards/wch/ch32v003evt/ch32v003evt.dts
@@ -32,6 +32,12 @@
        };
 };

+&red_led {
+       status = "disabled"; // Please connect the unconnected LED on the WCH
+                            // CH32V003EVT board to a suitable GPIO pin (like PD4)
+                            // and then change this status to "okay".
+};
+
 &clk_hse {
        clock-frequency = <DT_FREQ_M(24)>;
        status = "okay";

@kartben @fabiobaltieri Does the following patch look okay to you?

No that does nothing, disable the whole gpio-leds nodes, also these normally use /* style coments
leds {
		compatible = "gpio-leds";
                /* Please connect the unconnected LED on the WCH etc etc
                */
                status = "disabled";

		red_led: led0 {

@nzmichaelh Hey - You can queue up rest of the drivers now - thank you! <3

Thanks everyone! I'll get going on the console, ADC, I2C, SPI, and WDT drivers...

Also, if anyone is interested/curious, newer versions of 003fun support the ch32x033, x035, v203, v305 and v307.  (With no-quite-complete support for the v103 and v208).  But amazing work everyone.  Thank you @kholia for driving this to ground.  That was quite the 205 days!


Need McPatch emulation

This would be a short-term hack for showing differences in 'hybrid Jade'
Note -Hybrid Jade is the 'quick and dirty' way to get Rowan development in Jade

It is looking like I won't actually have to add a class called McPatch to get GsJade to display differences. I think that the code here:
sbChangesInPackage: anOrderedCollection

	| current repository patch string |
	current := self mcWorkingCopyClass forPackage: (self mcPackageClass named: anOrderedCollection removeFirst).
	repository := anOrderedCollection removeFirst.
	repository := current repositoryGroup repositories detect: [:each | each description = repository].
	patch := current changesRelativeToRepository: repository.
	patch operations isEmpty ifTrue: [current modified: false].
	string := self
		_mcDescriptionOfPatch: patch
		baseName: 'closest ancestor'
		alternateName: nil.
	writeStream
		nextPutAll: 'changesInPackage'; lf;
		nextPutAll: string;
yourself.

can be changed to do the following and with the addition of some upcoming changes, should work fine:
sbChangesInPackage: anOrderedCollection
        "where anOrderedCollection is {packageName, projectName}"

        | patch string |
	patch := Rowan packageTools diff
		patchSpecUrl: (anOrderedCollection at: 2)
		packageName: (anOrderedCollection at: 1).
	string := self
		_mcDescriptionOfPatch: patch
		baseName: 'closest ancestor'
		alternateName: nil.
	writeStream
		nextPutAll: 'changesInPackage';
		lf;
		nextPutAll: string;
		yourself

We'll see tomorrow:)

The fix was done on the gs_3215 branch -- I will merge the changes into the master branch shortly ...

well ... it looks like Jade isn't cooperating in enabling the McPatch code when not connecting to an image with McWorkingCopy installed (Issue #61)

issue #61 is closed, so I think we've got this one covered


3.0 - Easy Tasks: You would like the Nova to nuke the fridge (go Exception), while yelling in your Language?

So, you would like the Nova to nuke the fridge, while yelling in your Language?
That's easy, but you need to made some simple but numerous modifications, to internationalize the Exceptions. What to do:
Look into source code for Exceptions, then you should modify, as example:
throw new \Exception("No valid Query Building Method given");

BECOME:
throw new \Exception(__('No valid Query Building Method given'));

Notice the change into string definition, from double quote into single one, and the function __().
That function called __() is a convenience one, for the Language Domain called App.
What you do when you should compose the message with other strings/components? Because we use the native PHP INTL based on ICU, This way:
throw new \Exception("No valid Entity Name is given: " .$className);

BECOME:
throw new \Exception(__('No valid Entity Name is given: {0}', $className));

Note the sequence {0} .This is the first parameter, in order will be {1},  {2},  {3}, etc.
When you change the strings into INTL ones, from System, Modules and Templates, you should specify literally the Language Domain, identical with snake_case variant of Module, Template or System, like into this example:
throw new \UnexpectedValueException('Config and Options parameters should be Arrays');

BECOME:
throw new \UnexpectedValueException(__d('system', 'Config and Options parameters should be Arrays'));

Note the use of the function __d()
Finally, is it nice to use, after all your changes, the script /scripts/makelangs.php to update the Language files.
What cannot be internationalized? Only few files:
public/index.php
system/Config/bootstrap.php
system/Config/functions.php

Have fun and I wait your questions, if any! :smile:

I don't think that it's a good idea to internationalize exception messages. PHP parser and interpretator don't translate exception and error messages (at least for me), then why should the framework do that?
Also, for different errors you have (preferably) use different subclasses of exceptions, but not basic (\Exception).

@volter9 Well, I talk about framework messages, or the message strings set in Exceptions just before to nuke the fridge. And this will work.
Also, depending of Server configuration, it is very possible to set the PHP to speak completely into Russian or Italian. :smirk:
In other hand, there are used already different Exception subclasses, please look into code...

And how about the developer that wants to check the exception message for some containing words and with changing languages it's maybe a bit weird.
I'm not really used to translated exception messages. Also. Why should it?

@tomvlk He he, just to see PHP speaking Italian! :smirk:

Why should it?

Because there is an entire World beyond USA and UK!
And, generally speaking, from my experience, the French, the Germans and Italians love the programs to speak their Language.

see PHP speaking Italian! :smirk:

Oh, I don't want to see it :D

please look into code...

I'll take a look later, after stable release, but sorry for inconvenience.

@volter9 No problem! :smirk:
BTW, just saying...
I suppose that will feel strange to see in a Russian Server, eventually owned right on by your proud FSB, some Error Messages into Capitalist English, right?

I suppose that will feel strange to see in a Russian Server, eventually owned right on by your proud FSB, some Error Messages into Capitalist English, right? :smirk:

Ohoho, you're talking in stereotypes, comrade :)
Although, it would be really awkward to see PHP notices on FSB website, like, really really awkward :laughing:

@LuckyCyborg @volter9 I'll do my very best at translating (Miss Sophie :kissing_heart:). But I admit @volter9 right that there are different interpretations of one and the same word in different languages. Also in Germany.
On the other hand: as long as there are messages to the user / developer, emanating from the incorrect use of a command, it should be fine.

@nekomajin @volter9 @tomvlk Trust me, my friends, there is enough to appear in a Italian website, a page with this content:
An error occurred. The error has been reported.

Then there will be hundreds and hundreds of calls from guys afraid that the website is hacked. Because the typical Italian do not speak English. For them, the World speak Italian, just like an American think that the World speak (American) English. :smirk:

i hate "An error occurred. The error has been reported." i agree with @LuckyCyborg  i would prefer "Ha ocurrido un error. El error ha sido reportado" so nice to know you are thinking on us,

@geomorillo Then I can add also the Spanish as the people who love the programs to talk in their Language... :smirk:

I think it does make sense to let developers set the language or errors to their own language, not everyone uses English after all.


tmux configuration error on tmux 2.9a

Problem
The error is raised when making a new tmux session.
.tmux.conf:201: invalid option: window-status-activity-attr
.tmux.conf:211: invalid option: pane-border-fg
.tmux.conf:212: invalid option: pane-border-bg
.tmux.conf:213: invalid option: pane-active-border-fg
.tmux.conf:214: invalid option: pane-active-border-bg

Related Documents

https://github.com/tmux/tmux/issues/1689
https://github.com/tmux/tmux/wiki/FAQ#how-do-i-translate--fg--bg-and--attr-options-into--style-options

Solution

use *-style instead of these options.

use window-status-activity-style instead of window-status-activity-attr
use pane-border-style instead of pane-border-fg and pane-border-bg
use pane-active-border-style instead of pane-active-border-fg and pane-active-border-bg

Tmux has so many breaking changes without any deprecation. Are you aware of any configuration that would work with both <2.8 and >=2.9?

Changes in 3.0 is even more crazy: https://raw.githubusercontent.com/tmux/tmux/3.0/CHANGES

I didn't get other errors except this with 2.9a, so I guess the less part of settings could be used for 2.9.

This has been fixed in dc3be82, thanks! The setting should work both in tmux 2.4 and 2.9a.


stop downloading and get percentage of downloading

hi everybody
how i can get percentage of downloading ?
and how i can stop a download ?

I would be interested as well. I couldn't really figure out how to get information similar to the on('data') event in a normal readStream.

Did you find any trick on how to stop the download?

hey anyone found any solution on this?


Add healthcheck endpoint

When looking for a proper healthcheck for this service, using /metrics is inconvenient as we would need to scrape the metrics all the time which is more expensive both in processing and data transferred and in general slow. Having a separate /health endpoint should be better.

@RichardoC @peterebden @harryfallows I would really appreciate it if you could give a quick look and merge as I'm looking forward to using this project and this is the only detail I'm missing.

Hi @RichardoC
Why should we use another port for the healthcheck?
Wouldn't it be more complex to configure then?

Okay, that sounds reasonable. Thanks for updating with your use case
Can you please update the sample deployment yaml to use the new health endpoint as well?

Good spot on the dockerfile, once you add the readiness probe I'll get this merged. Thanks!


Projectname

This can be confused with the ClojureScript view-layer over React called Reagent. It should be mentioned in the Readme.

The tagline is "JavaScript Testing utilities for React" - is that not sufficient?
Is there a corresponding issue filed on the ClojureScript project to mention this project in the readme?

It might, I am not the author, but if I was I would have liked a mention. Note that Reagent was developed before this project.

I think it would be worthwhile coming up with a different name. Reagent is very established in the Clojure(Script) community, and there's a lot of overlap between the JS and CLJS communities.
Not sure exactly how old the clojurescript Reagent project is, but there's commits from at least 2013.

For many people, Javascript and Clojurescript are in the same space.
Look, we know it is a pain to rename, but really you should.  There's just too much overlap here. And this project is about two years too late to the name.

This is particularly important since both projects are in the React ecosystem (hence the name choices obviously). Confusion is inevitable. https://github.com/reagent-project/reagent clearly has priority.

+1 on renaming

Agreed. Should be renamed.

+1 on renaming

Think about this if the shoe was on the other foot. Imagine this library was open source for two years and then Google released an open source project focused on React also called Reagent. You'd probably feel pretty ticked off (I know I would).

+1 on renaming

+1 on renaming

+1 rename

+1 rename

+1 for renaming. This is definitely going to cause confusion, being in such a similar space.
This Reagent's first commit was Aug 2015. The original Reagent has been going since December 2013 and is very well established.

+1 rename

+1 on rename

Both of these libraries relate to the React ecosystem. There's no reason this library should use a name that's already taken by something else within the same general sphere. It's not a good thing for anybody.

+1 on rename

Renaming would avoid the awkward PR situation Groupon ended in when they stole a GNOME project name and refused to acknowledge the conflict; it'd just be so much easier to change the name.

+1 for rename. You gain nothing from re-using the name in a related space 2 years after the fact, while both the existing and future communities for both projects will lose with confusion while looking up references

If you keep this name:

You would harm the very community you're intending to contribute to: React. (That it's in JS or a compiled-to-JS language is irrelevant here, they're totally interoperable.)
You would harm your project in two ways: 1) It would be harder to Google, which is critical for a new project 2) You would not show that you're ready to play nice with the community, which is also critical for a new project in a FOSS community.
Ironically, you would end up with a name that is not that good: the word "reagent" will in itself always be difficult to Google because it is a very common word in chemistry, especially when associated with "react".

In FOSS communities, we don't privatize words by putting a trademark on them and suing anybody that uses it for something else in the same space (like you would for 'Airbnb'). We count on people's good judgement to respect the name of other projects and sub-communities within the community.

:+1: on renaming

Rename, please. Not cool, bro.

:name_badge: rename, please

You should absolutely rename and you should not have made such a dumb mistake in the first place.

@julianjelfs please watch your tone. While this is unfortunate there is no need to attack people. Thank you :+1:

+1 rename please

+1 rename plz

rename please

+1 rename

Rename plz

+1 rename

It would be a good idea to rename this project.  Using the same name will confuse Clojure, Airbnb, and React users.  While Airbnb may not feel this is a significant issue, you may want to consider that the programmers and companies who depend upon Clojure/Reagent may be among your clientele and investors, as well.
A partial list of those is here:  http://clojure.org/Companies

@martinklepsch Claiming that someone made a mistake is not an "attack".  There is no need for you to claim false things here. Thank you.

Please rename

Yes, please rename this project.

Please Rename!

@domgetter the message he's replying to had a different tone before it was edited. Nothing terrible, but definitely more constructive now.

:+1: rename it, please.

Big user of the other Reagent, so I am a bit biased, but I think it'd be best for both the Clojurescript and Javascript programmers to keep the names separate. Please consider renaming. Thanks!

:+1: for renaming. Great stuff otherwise :)

There's already one very popular react library named "reagent". What the host language is should have no bearing as both use React, and this WILL cause confusion if you don't.

 It would've taken all of 10 seconds to figure out this name is already being used for something very similar (a React-related OSS project).

:+1: On the renaming.  I was excited, thinking this was for testing reagent views...

+1 on renaming.

+1 rename

+1 rename

+1 rename

:+1:  rename

+1 rename

+1 rename

+1 rename

1 rename - Not doing so hurts your project as mentioned above.

+1 rename

+1 rename

+1 rename

+1 on rename.

You, you copycats! Much lame, MUST rename

Please pick a unique name that makes it easy to google your docs without getting hits for different products that are very similar.

I agree, too much overlap. +1 for renaming

I think a lot of people would be willing to help you with the renaming: if you announce another name and you ask for help, PRs with the new name replaced everywhere in the code and documentation would probably save you most of the grunt work.
Granted, the main hassles of a renaming generally is in the legacy code and docs, in changing internal habits and in public relations. But it can be done! (and the alternative would create even more hassles in the medium and long terms).

+1 for renaming...

+1 rename

1 rename. Don't hurt a otherwise great initiative by being inconsiderate.

+1 rename

+1 rename

+1 rename

+1 for renaming

While we appreciate everyone offering input, and will consider it, please do not offer simple "+1s", as these add no value. I will be deleting all +1s that offer nothing to the conversation, and if more continue to be added, I will be forced to lock the conversation.

Please rename. There is a popular ClojureScript library with the same name. This will do nothing except confuse people.

@ljharb I greatly appreciate that the rename will be considered! :)
I would submit, however, that the volume of +1s is significant and does affect the conversation - namely that this is important to an overwhelming number of people. Deleting the +1s is unnecessary, given that they are easy to skip past when skimming the thread.

Please rename.  It creates confusion when googling.
Also, the value of a +1 is an indicator of the magnitude of the issue.

Maybe like "polyglot.js", just call it "reagent.js", will that help?

@jiyinyiyong a ".js" suffix is a bit dated, so i wouldn't be in favor of using that convention for projects moving forward.
@gadfly361 i don't find them easy to skip past when I'm trying to read the whole thread to understand people's thoughts. +@csummers: Issues (of any kind) are not decided based on "popularity" or "number of people affected" - 1 person is just as important as 1 million. The only impact "+1" has is irritating contributors; it doesn't increase the perceived importance of the issue.

@ljharb  Of course the +1s add value. They show clearly the level of feeling. If you delete them it just looks like you are in denial.

Please consider renaming this project. Both are used in JavaScript AND for React, which is not cool.

The +1s are the most important information in this thread.
This is a community problem, the community should, if not decide, at least be heard.
There isn't any representatives here, so the only voices are members voices.
The number of people that are affected by the name collision and agree about the best way to solve the problem is the one thing that should be considered in priority.
I hope as much people as possible will express their interest, by +1s, -1s or a comment.

I could actually use both library in my project so I would like to see a way to differentiate them when googling reagent.

I agree that the Clojurescript Reagent project rightfully has dibs on the name, and the fact that both of these projects are related to react.js would cause undue confusion.
How about we come up with some cool react-ish alternative names for this Airbnb project?  How about "Reaction"? "Reactant"? "Reactest"?

@vibl as I've said, the number of people is irrelevant, because one person carries as much weight to us as one million. No voices are needed because the issue has been raised, and we are considering it. Additional points - that have not already been raised - are indeed valuable, and I hope people will continue to add those.
So far, what's been raised is:

hard to google (this is already a problem for the ClojureScript library because "reagent" is a chemistry word)
confusion for existing users of the ClojureScript library
confusion for future users of both the ClojureScript library and this project
and the most compelling imo, from here, is "play nice with the OSS community"

Please rest assured that even if no further comments were added to this thread, we will be considering it with the same amount of speed and attention than we would if thousands of people cluttered our email inboxes with "+1" notifications :-) (perhaps faster without the clutter!)
Alternate name suggestions are indeed welcome as well, but it might also help to put those in a separate issue.

Definitely agree that the project should be renamed.
Reagent is a very popular key component for the (rather big) ClojureScript React community. This will definitely cause a lot of confusion and do a lot of damage to their project (and this one too.)
By itself that's hopefully plenty motivation to find an even better name; but also keep in mind that trying to keep the name would be very bad PR for AirBnB in the open source community.
Hope you choose to do the right thing! The project looks pretty cool...

Two projects in the React space named Reagent? Ugh, no. Please do us and search engines a favor and rename it.

:+1: Please rename. Trust me, you don't want that name due to the chemistry connection, my search history looks like I've been trying to stock up a meth lab.

+1 for renaming! Reagent is established for 2+ years and one of the most prominent CLJS projects. I'd hate to see you just steamrolling it into invisibility due to your project's larger mass appeal to the pure-JS crowd. There're enough other names to choose from!

Thank you to everyone in this thread for your thoughts. A project rename is being considered.
I would like to add to Jordan's comments the following:

Please no more "+1" comments in this thread. We see that there are people who feel this needs to happen, and additional "+1" comments will no longer affect our decision. If you have more to say than please say it, however.
To add a bit of context, the project was just renamed from catalyst internally. To be fair, this could have been done with a bit more research, but the main measure of "name is available" we were looking for was the package name being available on npm. Lesson learned.
If this project is to be renamed, I would like for it to happen FAST.

Airbnb (and myself) of course want to be good stewards to this project and to the open source community at large, and have no desire to do it damage.
If you have any name recommendations, please put them in https://github.com/airbnb/reagent/issues/46

+1
I second @postspectacular
I use ClojureScript/Reagent every single day and its a formidable library.

Thank you for reconsider.

@lelandrichardson @ljharb Ref your comments on +1 comments you guys have a lot to learn about running an open source project, if you consider the minor inconvenience it may cause you more important that letting the community voice its opinion.

Maintainers: thank you for your consideration. As a user of cljs Reagent on a daily basis, I'm concerned that the name clash will be unhealthy for both projects in the long run.
I imagine the worst side effect would be on cljs devs when attempting to use this project in a ClojureScript environment.
I would urge the maintainers to take us into consideration and use this time to pick a new name for http://github.com/airbnb/reagent.

I ask that Airbnb rename this open source project.
Big fan of Airbnb and Airbnb engineering. I attend Airbnb Nerds meetup at your HQ as often as I can. We use Reagent in production at the company I work at. Though I use Reagent at work (and sometimes side projects), I consider myself first and foremost a JavaScript developer. The Reagent (CLJS) community really considers themselves not a separate community (isolated from React/JavaScript) both part of both, a joined community.
It would really suck to see Airbnb, not rename, and steamroll the existing open source project. Ya'll got 500 stars in a few days.
Also the +1 comments though minimal in value, showed how many people we're affected or care about this issue. So far 44 of those +1 comments have been silenced and removed.

@hzhu I don't think playing the game of "more people means it matters more" is going to be productive, especially if people start comparing the sizes of the JS and ClojureScript communities, or the number of stars a project has, etc. It's sufficient to say that any nonzero number of people are impacted, and that absolutely is enough to warrant consideration, with any issue, at any time, in any context.
@maacl thanks for your input. I'm following the lead of many other popular open source projects, including npm itself, in not conflating "the community voicing its opinion" with "let's all dogpile on a thread without adding any value". I appreciate that everyone wants to be heard, but that doesn't automatically guarantee that what they have to say is useful to anybody.
Thanks again to everybody for their input. Please follow along on #46 for naming suggestions, and please try to refrain from commenting unless you have a new thing for us to consider that adds to this list.

+1 for rename.

^ Apologies, I missed @lelandrichardson's comment above. My thought process:

The ClojureScript and JavaScript communities are closely-knit enough, IMHO, that this would be confusing regardless;
The ClojureScript project is specifically an interface for React, meaning:
Any attempt to search for "javascript reagent," "javascript testing reagent," &c, is more likely to confuse the issue than to provide meaningful feedback.

Thanks for considering renaming the project. Names should be "locally" unique to avoid confusion. Javascript React is a specific enough space so that names uniqueness is a realistic goal. It will be a one time pain for you to switch, but taking the high road will be repaid by the goodwill you will reap from it.

Please don't lift the reagent name from the clojurescript project. It is a great library.
A couple name suggestions:
"Retest"
"Replay"

Not sure how this slipped past the author(s). I'm also in favor of a name change.

Not sure how this slipped past the author(s).

It's unrealistic for a few people to be familiar with the full breadth of the React ecosystem.  The NPM package name was free so we figured so was the name.

Locking this issue for now because everyone agrees we need a rename. Thanks again to everybody for your input.
Please follow along on #46 for naming suggestions.

Closed with 38ae4b2

Thanks everyone for your feedback and civil discussion, and thanks to those who agreed with the rename but refrained from burying us in +1s! We've renamed the project to enzyme and it's freshly available on npm. Thanks as well to those who suggested names in #46.
Mistakes happen, but we definitely don't want to steal someone's thunder, nor steamroll another project, nor add confusion to the plates of those attempting to build cool stuff. Our sincere apologies to the folks at https://github.com/reagent-project/reagent (and its users).
We've published a "v1.0.1" under the "reagent" name on npm that does nothing except direct users to install enzyme - we'll leave that package up for at least a month or two, after which, @reagent-project is free to take it over if they wish; otherwise we'll keep it as-is so as to not leave it open for someone else to accidentally take.

Very excited and grateful to see this name change, thank you!!
@ljharb Definitely makes sense to leave the "reagent" name up on npm for a couple of months as a pointer to enzyme to ease the transition.  After that, I am happy to take it over on behalf of reagent-project.  We can coordinate that when the time comes and outside of this thread (my email is on my github page).

:clap:


chore(docs): Refresh CLI command details

Hey, I just made a Pull Request!

Recently, @awanlin alerted me to the Backstage CLI list-deprecations feature; I had no idea it exists.
I discovered a user @iTechSebastianoLaini asked a similar question that went unanswered in https://github.com/backstage/backstage/discussions/17988, so I helped answer it.
But the key point is it was a bit hidden! So this PR does two things,

Refreshes some of the CLI commands which are missing some newer features. (like list deprecations!)
Fixes some of the headings where the :word was being stripped out.

I think this entire page could use a refactor and a clean think about both a good way to keep it updated, and possibly organizing it better. Maybe more in line with how the API References page auto-generates. I don't have that time at the moment, so this quickly uses the latest Backstage CLI from the repo, and updates the command sections.
I also fixed the duplicate headings where things like config:print was being displayed in Docusaurus headings as only config, and then listing config over and over.

Before (backstage.io/docs)
After

:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[x] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[x] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

(the changeset action seems wrong somehow :) )


build ghc then git annex 01

Checklist

[X] Used a fork of the feedstock to propose changes
[X] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[X] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[X] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@notestaff I would like to introduce you to Florian (@eggzilla) he tries hard to get a Haskell stack into conda-forge. Maybe you both can exchange some experience.

Thanks @bgruening !  Some others with interest in making Haskell work on conda: @luispedro @joeyh .
This PR might be a start for making ghc work on conda, but it has issues.  Most concerning is that the built ghc fails some tests in the ghc test suite.  It also uses two ugly hacks: (1) installs shim scripts to ensure that gcc is always called with certain flags, and (2) replaces libpthread in the sysroot of gcc_linux-64 with a symlink to /lib64/pthread .
So while this PR works for building git-annex -- the git-annex test suite passes -- I'd be wary of putting it on ghc-feedstock until the ghc test suite issue is fixed.
Also, maybe the right way to build ghc is as a pseudo-cross-compiler, like gcc_linux-64 is, with $HOST as the target.  But I don't have enough understanding of cross-compiling toolchains.
The homebrew forumula for ghc might be a guide: https://github.com/Homebrew/homebrew-core/blob/master/Formula/ghc.rb

This is such an amazing tour de force.

Hi! This is the friendly automated conda-forge-linting service.
I was trying to look for recipes to lint for you, but it appears we have a merge conflict.
Please try to merge or rebase with the base branch to resolve this conflict.
Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

Looking at https://anaconda.org/conda-forge/ghc and https://anaconda.org/conda-forge/ghc/files suggesting that we had ghc package in conda-forge for 4 years (so likely before this PR) I am confused why that ghc was not used ...

The conda-forge GHC package is both old (v8.10), not 100% complete. Maybe that's enough for git-annex, but it's not a complete GHC solution

git-annex needs 8.10.7 but may be that it was outdated back then or incomplete indeed was the reason. @notestaff would be the only one to know I guess ;)


Possible conflict with vagrant-azure spinning up VirtualBox VM

I have tried my first Ubuntu box with vagrant-azure today, thanks for this plugin!
But I have a problem spinning up a local VM with virtualbox provider after installing the vagrant-azure 1.0.5 plugin.
My setup is:

Mac Yosemite 10.10.1
vagrant 1.6.5
VMware Fusion 6.0.5
VirtualBox 4.3.20
The following vagrant plugins

$ vagrant plugin list
vagrant-azure (1.0.5)
vagrant-multiprovider-snap (0.0.14)
vagrant-cucumber (0.0.8)
vagrant-login (1.0.1, system)
vagrant-omnibus (1.4.1)
vagrant-pristine (0.3.0)
vagrant-serverspec (0.1.0)
vagrant-share (1.1.2, system)
vagrant-vcloud (0.4.3)
vagrant-vmware-fusion (3.1.2)

I have created a simple Vagrantfile for a Windows box and got this error:
$ vagrant up --provider=virtualbox
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'windows_7'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: win7_default_1418143064904_61689
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 3389 => 3389 (adapter 1)
    default: 22 => 2222 (adapter 1)
    default: 5985 => 55985 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
==> default: Forcing shutdown of VM...
==> default: Destroying VM and associated drives...
==> default: Running cleanup tasks for 'shell' provisioner...
/Users/stefan/.vagrant.d/gems/gems/vagrant-azure-1.0.5/lib/vagrant-azure/communication/powershell.rb:24:in `ready?': undefined method `check_winrm' for #<VagrantPlugins::ProviderVirtualBox::Driver::Meta:0x000001029d2f80> (NoMethodError)
	from /Users/stefan/.vagrant.d/gems/gems/vagrant-azure-1.0.5/lib/vagrant-azure/communication/powershell.rb:15:in `wait_for_ready'
	from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/action/builtin/wait_for_communicator.rb:16:in `block in call'

What makes me wonder is how can the vagrant-azure/communication/powershell.rb be called from vagrant when I want to spin up a box with the virtualbox provider and the default communicators for Vagrant 1.6.x?
The Vagrantfile looks pretty simple:
# -*- mode: ruby -*-
# vi: set ft=ruby :

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "windows_7"
  config.vm.provider "virtualbox" do |vb|
    vb.gui = true
  end
  config.vm.provision "shell", path: "provision.bat"
end

I am used with the virtualbox, vmware_fusion and vcloud providers, so I thought I just add another cloud provider and get in touch with Azure with vagrant.
Is it possible to use these local providers in parallel with vagrant-azure?
Should I use a special version for this (eg. directly from GitHub)?
I have repeated the vagrant up --provider=virtualbox command and stored the debug log in this gist.

We've removed all the powershell with the new release (1.1.0) can you retry?

@jeffmendoza thanks for the update. Yes I have retried it, but I still have problems provisioning a VirtualBox VM when vagrant-azure 1.1.0 is installed.
I first powered up a Windows 7 VM and then only looked at the provisioning. Then I did some debugging with VAGRANT_LOG=debug vagrant provision.
The difference seems to be here:
With vagrant-azure (hangs)
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
DEBUG virtualbox_4_3:   - [1, "rdp", 3389, 3389]
DEBUG virtualbox_4_3:   - [1, "ssh", 2222, 22]
DEBUG virtualbox_4_3:   - [1, "winrm", 55985, 5985]
DEBUG winrmshell: initializing WinRMShell
DEBUG winrmshell: powershell executing:
hostname
if ($?) { exit 0 } else { if($LASTEXITCODE) { exit $LASTEXITCODE } else { exit 1 } }
 INFO winrmshell: Attempting to connect to WinRM (patched)...
 INFO winrmshell:   - Host: <IP_ADDRESS>
 INFO winrmshell:   - Port: 55985
 INFO winrmshell:   - Username: vagrant
 INFO winrm: WinRM not up: #<VagrantPlugins::CommunicatorWinRM::Errors::ExecutionError: An error occurred executing a remote WinRM command.

Without vagrant-azure (provisioning works)
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
DEBUG virtualbox_4_3:   - [1, "rdp", 3389, 3389]
DEBUG virtualbox_4_3:   - [1, "ssh", 2222, 22]
DEBUG virtualbox_4_3:   - [1, "winrm", 55985, 5985]
DEBUG winrmshell: initializing WinRMShell
DEBUG winrmshell: powershell executing:
hostname
if ($?) { exit 0 } else { if($LASTEXITCODE) { exit $LASTEXITCODE } else { exit 1 } }
 INFO winrmshell: Attempting to connect to WinRM...
 INFO winrmshell:   - Host: <IP_ADDRESS>
 INFO winrmshell:   - Port: 55985
 INFO winrmshell:   - Username: vagrant
DEBUG winrmshell: Output: {:data=>[{:stdout=>"vagrant-2012\r\n"}], :exitcode=>0}
 INFO winrm: WinRM is ready!
 INFO warden: Calling OUT action: #<VagrantPlugins::Omnibus::Action::InstallChef:0x000001039f9120>
 INFO interface: info: Running provisioner: shell...
 INFO interface: info: ==> win7: Running provisioner: shell...
==> win7: Running provisioner: shell...

It seems that at the Attempting to connect to WinRM (patched)... message the problem starts.
Is this patched code still needed with Vagrant 1.7?
If it is needed for Azure then it should only be loaded if the specific box should be provisioned with the vagrant-azure provider and not for others.
I hope I could help to find the problem.

@StefanScherer this should definitely only get loaded for that provider. Let me try to replicate and perhaps supply a patch to fix this. Thank you for the help.

Installed vagrant-azure 1.1.1 and spinned up a Windows VM in VirtualBox - works, no more conflicts. Awesome! :star2: :star: :star2:

I'm seeing this on 1.1.1 (Vagrant 1.7.2, VirtualBox 4.3.22, Mac OS X 10.10.2).
Tried to load up one of my non-Azure, virtualbox provider VMs and it would not connect via winrm.
if ($?) { exit 0 } else { if($LASTEXITCODE) { exit $LASTEXITCODE } else { exit 1 } }
 INFO winrmshell: Attempting to connect to WinRM (patched)...
 INFO winrmshell:   - Host: <IP_ADDRESS>
 INFO winrmshell:   - Port: 5985
 INFO winrmshell:   - Username: vagrant
 INFO winrm: WinRM not up: #<VagrantPlugins::CommunicatorWinRM::Errors::ExecutionError: An error occurred executing a remote WinRM command.

once I uninstalled the vagrant-azure plugin, the VM loaded fine.
If there are any other logs/info that would be helpful, let me know and I'll try to provide.

@seancoyne hmm... I thought this bug was killed. I'll try to reproduce your results.

I'm seeing this on 1.1.1 (Vagrant 1.7.2, VirtualBox 4.3.22, Mac OS X 10.10.2).
once I uninstalled the vagrant-azure plugin, the VM loaded fine.


R124 define succinct

R124 states The zero-knowledge proof of correctness of a state object utilized in one or more mono-directional and/or bi-/multi-directional BPI Services MUST be succinct.
This requirement is qualitative. Would you please clarify using specific quantities, such as 2 megabytes, 100 kilobytes?

D26 is also showing the same issue.

Yes, that's a pretty strong requirement to me.


Undefined name 'convert2np' in ./benchmark/evaluate.py

There is a missing import in ./benchmark/evaluate.py so that convert2np() is and undefined name.
convert2np() is defined at https://github.com/akanazawa/cmr/blob/master/utils/bird_vis.py#L177
flake8 testing of https://github.com/akanazawa/cmr on Python 3.6.3
$ flake8 . --count --select=E901,E999,F821,F822,F823 --show-source --statistics
./benchmark/evaluate.py:102:28: F821 undefined name 'convert2np'
        img = np.transpose(convert2np(batch['img'][0]), (1, 2, 0))
                           ^
1     F821 undefined name 'convert2np'
1

Thanks for pointing this out! Updated the file to import it.


#50 support installation from custom repository or package file

Refactored adding apt or rpm repository to separate recipe intead of
repeating code in agent and server recipe
Added possible installation from remote_file.
Default install method is still thoughtworks repository
Updated and fixed readme

I am closing this because we have those changes already integrated in develop.


Unique rule causing error

I have a unique validation rule with a where clause that is causing an error when trying to generate the docs.
This is the error I get

[ErrorException]
Trying to get property of non-object

And my validation rules are
return [
    'name'  => [
        'required',
        'min:10',
        'max:255',
        Rule::unique('posts')->where('user_id', $this->user()->id), // Unique name per user
    ],
];

It seems like if I remove the where it works so I'm guessing it's something to do with that.

this route requires login, right? Did you use the "--actAsUserId"?

@gilesrussi what about code like this? I have seem error:
return [             'name'      => 'string|min:5',             'slug'      => 'string|min:5|unique:categories,slug,' . $this->route('category')->id,             'parent_id' => 'nullable|exists:categories,id'         ];
and Trying to get property of non-object


Add Comment and Tags for Cloudflare DNS record

Hi there, i'm trying out phonebook for managing Cloudflare DNS record and it works great!
I have a feature request for the Cloudflare provider.
Currently there is no indication that a DNS record was managed by phonebook. Cloudflare DNS record does have a Record Attributes to give information about the record. I think it would be great to be able to add Comment or Tags directly from phonebook.
Maybe the CRD looks like this
apiVersion: se.quencer.io/v1alpha1
kind: DNSRecord
metadata:
  name: dnsrecord-sample
  namespace: phonebook-system
spec:
  zone: mydomain.com
  recordType: A
  name: helloworld
  targets:
    - <IP_ADDRESS>
  comment: "managed by phonebook"
  tags:
    - key1:value1
    - key2:value2

Thanks!

Just released a new version (v0.3.9) that includes support for tags and comments for Cloudflare.
Documenation on how to use it is here: https://pier-oliviert.github.io/phonebook/integrations/cloudflare/#tags-and-comments
Let me know if you have any other question/issues!

Hi, thank you for the enhancement!
I have try it but i can't make a DNS record using the new version (v0.3.9). I have try using the older version (v0.3.7) and it still works fine. So i don't think the error is on the Cloudflare side.
I think the error is on the Cloudflare provider, it got this error after deployment :
$ kubectl -n phonebook-system logs -f provider-cloudflare-65df96c8db-8rpkm

2024-11-19T04:41:02Z    INFO    starting manager
2024-11-19T04:41:02Z    INFO    controller-runtime.metrics      Starting metrics server
2024-11-19T04:41:02Z    INFO    starting server {"name": "health probe", "addr": "[::]:8081"}
2024-11-19T04:41:02Z    INFO    controller-runtime.metrics      Serving metrics server{"bindAddress": ":8080", "secure": false}
I1119 04:41:02.241579       1 leaderelection.go:254] attempting to acquire leader lease phonebook-system/cloudflare-provider.phonebook.se.quencer.io...
I1119 04:41:02.270362       1 leaderelection.go:268] successfully acquired lease phonebook-system/cloudflare-provider.phonebook.se.quencer.io
2024-11-19T04:41:02Z    DEBUG   events  provider-cloudflare-65df96c8db-8rpkm_03d55a85-8e90-4ae2-a784-2f060d144397 became leader        {"type": "Normal", "object": {"kind":"Lease","namespace":"phonebook-system","name":"cloudflare-provider.phonebook.se.quencer.io","uid":"e0fb113b-f6e6-4dae-9e18-d60b112f5eb1","apiVersion":"coordination.k8s.io/v1","resourceVersion":"6594528"}, "reason": "LeaderElection"}
2024-11-19T04:41:02Z    INFO    Starting EventSource    {"controller": "dnsrecord", "controllerGroup": "se.quencer.io", "controllerKind": "DNSRecord", "source": "kind source: *v1alpha1.DNSRecord"}
2024-11-19T04:41:02Z    INFO    Starting Controller     {"controller": "dnsrecord", "controllerGroup": "se.quencer.io", "controllerKind": "DNSRecord"}
E1119 04:41:02.278177       1 event.go:359] "Server rejected event (will not retry!)" err="events is forbidden: User \"system:serviceaccount:phonebook-system:phonebook-providers\" cannot create resource \"events\" in API group \"\" in the namespace \"phonebook-system\"" event="&Event{ObjectMeta:{cloudflare-provider.phonebook.se.quencer.io.180944e065b459a1  phonebook-system    0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[] map[] [] [] []},InvolvedObject:ObjectReference{Kind:Lease,Namespace:phonebook-system,Name:cloudflare-provider.phonebook.se.quencer.io,UID:e0fb113b-f6e6-4dae-9e18-d60b112f5eb1,APIVersion:coordination.k8s.io/v1,ResourceVersion:6594528,FieldPath:,},Reason:LeaderElection,Message:provider-cloudflare-65df96c8db-8rpkm_03d55a85-8e90-4ae2-a784-2f060d144397 became leader,Source:EventSource{Component:provider-cloudflare-65df96c8db-8rpkm_03d55a85-8e90-4ae2-a784-2f060d144397,Host:,},FirstTimestamp:2024-11-19 04:41:02.270347681 +0000 UTC m=+0.062447681,LastTimestamp:2024-11-19 04:41:02.270347681 +0000 UTC m=+0.062447681,Count:1,Type:Normal,EventTime:0001-01-01 00:00:00 +0000 UTC,Series:nil,Action:,Related:nil,ReportingController:provider-cloudflare-65df96c8db-8rpkm_03d55a85-8e90-4ae2-a784-2f060d144397,ReportingInstance:,}"
2024-11-19T04:41:02Z    INFO    Starting workers        {"controller": "dnsrecord", "controllerGroup": "se.quencer.io", "controllerKind": "DNSRecord", "worker count": 1}

phonebook controller logs :
$ kubectl -n phonebook-system logs -f phonebook-controller-9c9c5db6f-mvtzc

2024-11-19T04:35:07Z    INFO    starting manager
2024-11-19T04:35:07Z    INFO    starting server {"name": "health probe", "addr": "[::]:8081"}
I1119 04:35:07.548118       1 leaderelection.go:254] attempting to acquire leader lease phonebook-system/dcf9568b.provider.phonebook.se.quencer.io...
I1119 04:35:25.072964       1 leaderelection.go:268] successfully acquired lease phonebook-system/dcf9568b.provider.phonebook.se.quencer.io
2024-11-19T04:35:25Z    DEBUG   events  phonebook-controller-9c9c5db6f-mvtzc_1b1bb0d0-a69c-4f82-be5d-11b14256576f became leader {"type": "Normal", "object": {"kind":"Lease","namespace":"phonebook-system","name":"dcf9568b.provider.phonebook.se.quencer.io","uid":"72a99bd8-4aa2-4203-95c9-e7694019634b","apiVersion":"coordination.k8s.io/v1","resourceVersion":"6590283"}, "reason": "LeaderElection"}
2024-11-19T04:35:25Z    INFO    Starting EventSource    {"controller": "dnsrecord", "controllerGroup": "se.quencer.io", "controllerKind": "DNSRecord", "source": "kind source: *v1alpha1.DNSRecord"}
2024-11-19T04:35:25Z    INFO    Starting Controller     {"controller": "dnsrecord", "controllerGroup": "se.quencer.io", "controllerKind": "DNSRecord"}
2024-11-19T04:35:25Z    INFO    Starting EventSource    {"controller": "dnsintegration", "controllerGroup": "se.quencer.io", "controllerKind": "DNSIntegration", "source": "kind source: *v1alpha1.DNSIntegration"}
2024-11-19T04:35:25Z    INFO    Starting Controller     {"controller": "dnsintegration", "controllerGroup": "se.quencer.io", "controllerKind": "DNSIntegration"}
2024-11-19T04:35:25Z    INFO    Starting workers        {"controller": "dnsintegration", "controllerGroup": "se.quencer.io", "controllerKind": "DNSIntegration", "worker count": 1}
2024-11-19T04:35:25Z    INFO    Starting workers        {"controller": "dnsrecord", "controllerGroup": "se.quencer.io", "controllerKind": "DNSRecord", "worker count": 1}
2024-11-19T04:46:33Z    INFO    Reconciling     {"controller": "dnsrecord", "controllerGroup": "se.quencer.io", "controllerKind": "DNSRecord", "DNSRecord": {"name":"record-4","namespace":"phonebook-system"}, "namespace": "phonebook-system", "name": "record-4", "reconcileID": "59513180-9b05-495c-bd11-946419c0590a", "Record": {"apiVersion": "se.quencer.io/v1alpha1", "kind": "DNSRecord", "namespace": "phonebook-system", "name": "record-4"}}
2024-11-19T04:46:33Z    INFO    Finalizer didn't exists {"controller": "dnsrecord", "controllerGroup": "se.quencer.io", "controllerKind": "DNSRecord", "DNSRecord": {"name":"record-4","namespace":"phonebook-system"}, "namespace": "phonebook-system", "name": "record-4", "reconcileID": "59513180-9b05-495c-bd11-946419c0590a"}
2024-11-19T04:46:33Z    INFO    Reconciling     {"controller": "dnsrecord", "controllerGroup": "se.quencer.io", "controllerKind": "DNSRecord", "DNSRecord": {"name":"record-4","namespace":"phonebook-system"}, "namespace": "phonebook-system", "name": "record-4", "reconcileID": "cedb5d58-8623-4e8f-8189-19f9e28ee0ef", "Record": {"apiVersion": "se.quencer.io/v1alpha1", "kind": "DNSRecord", "namespace": "phonebook-system", "name": "record-4"}}
2024-11-19T04:46:33Z    INFO    Reconciling     {"controller": "dnsrecord", "controllerGroup": "se.quencer.io", "controllerKind": "DNSRecord", "DNSRecord": {"name":"record-4","namespace":"phonebook-system"}, "namespace": "phonebook-system", "name": "record-4", "reconcileID": "41abec15-d2ba-4f91-a83e-b2470e52799e", "Record": {"apiVersion": "se.quencer.io/v1alpha1", "kind": "DNSRecord", "namespace": "phonebook-system", "name": "record-4"}}

Hope it helps!

Also not works on v0.3.8. with the same error message.
E1119 07:15:52.444337       1 event.go:359] "Server rejected event (will not retry!)" err="events is forbidden: User \"system:serviceaccount:phonebook-system:phonebook-providers\" cannot create resource \"events\" in API group \"\" in the namespace \"phonebook-system\"" event="&Event{ObjectMeta:{cloudflare-provider.phonebook.se.quencer.io.18094d536eea867b  phonebook-system    0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[] map[] [] [] []},InvolvedObject:ObjectReference{Kind:Lease,Namespace:phonebook-system,Name:cloudflare-provider.phonebook.se.quencer.io,UID:e0fb113b-f6e6-4dae-9e18-d60b112f5eb1,APIVersion:coordination.k8s.io/v1,ResourceVersion:6715121,FieldPath:,},Reason:LeaderElection,Message:provider-cloudflare-667645c74c-xfbpr_bcfb5b33-a368-468d-a6db-801f83e11754 became leader,Source:EventSource{Component:provider-cloudflare-667645c74c-xfbpr_bcfb5b33-a368-468d-a6db-801f83e11754,Host:,},FirstTimestamp:2024-11-19 07:15:52.439154299 +0000 UTC m=+0.055885097,LastTimestamp:2024-11-19 07:15:52.439154299 +0000 UTC m=+0.055885097,Count:1,Type:Normal,EventTime:0001-01-01 00:00:00 +0000 UTC,Series:nil,Action:,Related:nil,ReportingController:provider-cloudflare-667645c74c-xfbpr_bcfb5b33-a368-468d-a6db-801f83e11754,ReportingInstance:,}"

v0.3.8 had breaking changes (https://github.com/pier-oliviert/phonebook/commit/f819be226c3882d890489681f5a0febeb02dab4f) And as such you'll need to uninstall phonebook completely (removing all DNSRecord & DNSIntegrations) and reinstall it from scratch.
Unfortunately, I've had some issues over the last 2 versions with github actions that screwed the migration for. That's my bad and it shouldn't happen again as I made some changes to the release deployment.

Great! v0.3.10 works perfectly. Thank you and happy holiday :)


Ability to skip default values for private types?

Say I have a struct:
struct Foo {
    #[builder(default)]
    secret_constant: SomePrivateType,
    pub some_field: Field
}

This field is private, and its type is private. Right now I'll get the error can't leak private type.
Is it possible to work around this?

You can skip the setter:
#[derive(typed_builder::TypedBuilder)]
pub struct Foo {
    #[builder(default, setter(skip))]
    secret_constant: SomePrivateType,
    pub some_field: Field
}

Sadly the macro can't do it automatically, because it does not know what the visibility of the SomePrivateType is.

Super, thanks a lot! I didn't find this when I searched for skip.


python3Packages.pytile: 5.2.4 -> 2021.10.0

Motivation for this change
Update to latest upstream release 2021.10.0
Change log: https://github.com/bachya/pytile/releases/tag/2021.10.0
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 145176 run on x86_64-linux 1

3 packages built:

home-assistant
python38Packages.pytile
python39Packages.pytile

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 145176 run on x86_64-linux 1

3 packages built:

home-assistant
python38Packages.pytile
python39Packages.pytile


Add configuration for github enterprise

Hey, I just made a Pull Request!
User can now authenticate to github enterprise too by adding these 3 environment variables:
export AUTH_GITHUB_AUTHORIZATION_URL=https://ENTERPRISE_INSTANCE_URL/login/oauth/authorize
export AUTH_GITHUB_TOKEN_URL=https://ENTERPRISE_INSTANCE_URL/login/oauth/access_token
export AUTH_GITHUB_USER_PROFILE_URL=https://ENTERPRISE_INSTANCE_URL/api/v3/user

Note these are optional. If they are not specified, authentication is performed against github.com
:heavy_check_mark: Checklist

[x] All tests are passing yarn _test_
[x] Relevant documentation updated

Ok, fixed,  now you just pass the base URL, and the other URLs are derived from it.


[Feature Request] Samba / SMB Server Access

Hello, I have been using Acode for the past couple of weeks and have been very happy! One feature I would really love added would be the ability to connect to Windows/Samba server share locations and directories. The FTP client connectivity feature is great, but it would be so helpful if SMB connections were also supported. Perhaps the existing "FTP" menu option title could be changed to "Network" or "Remote Location..." and then just add another radio button next to the existing two FTP connection options, for a new samba connection.
Perhaps implementing this feature is not as simple as it might seems to be and isn't likely to ever be implemented, but I just wanted to at least ask.
Thank you!

Thanks for the suggestion, I'll try to implement it.

totally agree. mixplorer has samba  and i litrrally use it a hundred times a day for different things, its riddiculusly useful and convenient feature to have

Any news about the SMB implementation?
I just downloaded the app but all the files I need to edit are shared through SMB.
Thank you.

Working on it. Soon it will be available.

Awesome! Any expected date ? Looking forward for that.

I've found a library for SMB in java. I just have to create Cordova plugin for it which would be a great time consuming task. And also I'm working on other commercial project i.e. I'm not able to give much time Acode. But I'll try to finish it as soon as possible.

Awesome workaroud (maybe not even that, if I can say): use CIFS! Wow, magically got smb supporting _ : https://github.com/wa2c/cifs-documents-provider
It integrantes with android DocumentsProviderUI (i.e. adds doc. Prov. source) - at least it's what I understood... Anemo does the same...
By the way... it supports (S)FTP too...
:B


Use turbolinks 5 events

Changed:

page:load to turbolinks:load
page:fetch to turbolinks:request-start

Fixes #56
I'll update the tests if this gem is not getting deprecated.

Please see https://github.com/kossnocorp/jquery.turbolinks/issues/56#issuecomment-202255494
TL;DR: I'm looking for a new project owner.

I just realized that tests are green :wink:. WDYT about https://github.com/kossnocorp/jquery.turbolinks/pull/58?

Neat, but I think it should detect which Turbolinks.VERSION you're using first.

I swear that wasn't up when I made this PR.  Yeah, if that one works, close this one.

@dsandstrom thanks!


 The task is responsible for terminating in that time, until it is killed forcefully.
TASK_KILLING: a new task state has been introduced in Mesos, which signals, that a task got a kill request and is in the grace period. Other tools (e.g. load balancer, service discovery etc) should not route traffic to tasks in that state

This behavior should be documented in the Marathon gh pages.

Has this issue been addressed already? It looks like it might have: https://github.com/mesosphere/marathon/issues/4323

@sascala Please update this ticket with a reference to the documentation and close this ticket.

Hi @sascala is this in the documentation yet?  I cannot see where to see examples of how to use these features when trying to drain a node for maintenance and the like.

taskKillGracePeriod has no effect with Mesos executor with shell task see MESOS-6933

Note: This issue has been migrated to https://jira.mesosphere.com/browse/MARATHON-2314. For more information see https://groups.google.com/forum/#!topic/marathon-framework/khtvf-ifnp8.


Page styling

This PR:

3b965cb adds styles to code blocks to highlight the syntax (uses GitHub highlight, we might want to change it to Pygments if we want to be consistent with the GDS tech docs)
cdb9cba limits the element (<h*>, <p>, <ul>, <ol>, <img>) inside .app-c-content (these can be placed inside .prose instead) in width (38em) for a better legibility

Trello card

Width limit - approved from me


Failed to resolve

Hey, I would really like to give this library a go, but I cant import it, after adding maven to allprojects and compile to dependencies, it says:
Failed to resolve: annotationProcessor
Failed to resolve: com.github.vikramezhil:DroidSpeech:1.0.1

I managed to fix that by replacing version code '1.0.1' with '1.+', although it's not the best solution. Maybe you just mismatched the versions in description.

Hello, indeed the issue was with the version code. It should be v1.0.1, I have changed this in the README file to reflect the same. Thanks for looking into this and you can replace 1.+ with v1.0.1

Great, thanks,


Update the link to AsyncAPI Shop in the footer

Describe the bug
Currently, AsyncAPI Shop links to the old shop website. We should update the link to the new shop website.
How to Reproduce

Visit the footer section on the AsyncAPI Initiative Website.

Expected behavior
The updated link should be: https://www.store.asyncapi.com/collections/all-products
cc @AceTheCreator
Can I work on this issue?

yes we should change the store link

/gfi javascript


Pandas and Matplotlib Dependency in the Stubs Package

Could you please remove pandas and matplotlib from the dependencies of the pandas-stubs package.
Why would you have a separate stubs package and then depend on the main package and even matplotlib?
This package was super slim until 6 days ago: https://github.com/VirtusLab/pandas-stubs/blob/master/setup.py#L38-L40
Thank you.

Most of matplotlib is not annotated. I think the matplotlib type used the most is Axes which unfortunately resolves to Any.

matplotlib does have annotations that are shipped with VS Code.

from matplotlib.axes import Axes

reveal_type(Axes)  # mypy: any, pyright: Unknown

In the above example, within VS Code, you will get Type[Axes] on the reveal_type()

If the goal of pandas-stubs is to eventually be part of typeshed and be recommeneded by mypy, I think pandas-stubs cannot depend on any actual code (and only contain pyi files).

I'm not sure that the goal is to make pandas-stubs part of typeshed, although I could see that happening in the future.

matplotlib does have annotations that are shipped with VS Code.

Thank you, I didn't know that! If they have a standalone stub package, pandas-stubs (and pandas) should install that at least for the CI. mypy&pyright infer Axes on the pandas CI as Any/Unknown.

matplotlib does have annotations that are shipped with VS Code.

Thank you, I didn't know that! If they have a standalone stub package, pandas-stubs (and pandas) should install that at least for the CI. mypy&pyright infer Axes on the pandas CI as Any/Unknown.

To clarify, the matplotlib annotations are maintained by Microsoft in https://github.com/microsoft/python-type-stubs, and then Microsoft merges those stubs into the VS Code distribution.

closed via #66


Image messages have latency or dropped

Checklist

[X] I've read the contribution guidelines.
[X] I've searched other issues and no duplicate issues were found.
[X] I'm convinced that this is not my fault but a bug.

Description
We are using the CycloneDDS configuration provided by @takam5f2 in this discussion with tuned DDS advised by the ROS2 page. Without running Autoware.Universe, we are getting 20 fps with 3 cameras without any problem. But if we run the entire Autoware.Universe pipeline, image messages drop to ~3,4 FPS. When we reduce the resolution of the images to around 600x500 and fix the fps to 15, there is no frame loss, but the latency in the topic is around ~70,80 ms. Is there anyone have any advice or solution?
CycloneDDS supports shared memory with ROS2 Humble. is there any plan to convert autoware messages to a fixed size for using zero-copy DDS operation with shared memory.
Expected behavior
Image message topics must arrive with minimal latency.
Actual behavior
Image messages are being dropped or coming with latency
Steps to reproduce

Run Autoware with a 2D object detection pipeline.

Versions
No response
Possible causes
No response
Additional context
No response

Possible relevant discussions:

https://github.com/orgs/autowarefoundation/discussions/2617
https://github.com/orgs/autowarefoundation/discussions/2621
https://github.com/orgs/autowarefoundation/discussions/2555

Also, as @xmfcx mentioned, if we put all image processing nodes in a single component, we should be able to reduce the image latency.

We need a rosbag to reproduce this issue.

@Zeysthingz can you share bag files to reproduce this issue?

@xmfcx share the bag files.

@xmfcx Is the bag file ready?

It seems all present messages were recorded instead of just the sensor messages. I will extract the sensor messages using this tool https://github.com/Kettenhoax/ros2bag_tools and upload the bag file.

@xmfcx is investigating this issue.

The shared bag files are/will be available in autoware documentation through this pr: https://github.com/autowarefoundation/autoware-documentation/pull/200

Note: the bag file only contains velodyne_packets so needs conversion to pointcloud.

@xmfcx could you share the link to sensor description repository for your vehicle?

https://github.com/vautonomous/isuzu_sensor_description @xmfcx also add this to the documentation.

From the discussion from LeoDrive's update in ASWG, the latency is likely to be caused by CPU usage. We might not be able to fix this within Bus ODD timeline.

Using Iceoryx zero copy improved the message transportation, but using Iceoryx as AWF projects needs further discussion.

In the relevant PRs, I passed the same pointcloud_container to Velodyne nodes and missed the occupancy grid map package. When working with sample_sensor_kit and  logging_simulator.launch.xml/autoware.lauch.xml, it decreased network traffic by around -%30 and also CPU utilization decreased.
I will test it with a real Velodyne device, making sure Velodyne drivers work without any problem in the same container with a different namespace.

Once

https://github.com/autowarefoundation/autoware.universe/pull/2114
https://github.com/autowarefoundation/sample_sensor_kit_launch/pull/48

are merged, we can close this issue.

Once
* [feat(tier4_localization_launch): pass pc container to localization #2114](https://github.com/autowarefoundation/autoware.universe/pull/2114)

* [feat(sample_sensor_kit_launch): pass container to velodyne nodes sample_sensor_kit_launch#48](https://github.com/autowarefoundation/sample_sensor_kit_launch/pull/48)

are merged, we can close this issue.

PRs are ongoing, milestone updated.


Better changelog generation

Improve the changelog generation script to produce higher quality output

This doesn't change anything in the build pipeline so there's no point in waiting for CI changes to finish up


Release 2.12.0 for Windows & MacOs

Replacing White Noise Conversation Masking Speech Privacy Sound Noise Cancelling with Pink Noise Ten Hours - The Classic Now in Dark Screen.

https://github.com/kkamara/kelvinkamara/releases