[Fix] username len and fix role error

What changes were proposed in this pull request
Issue Number: close #xxx

Brief change log

Verifying this change

This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
Modified the user name length limit error issue when creating a user
add project:delete role and app:lauch role

Hi @wangsizhu0504 , why do you add the pnpm-lock.yaml?

When there is a lock file, the front-end installation dependency will be downloaded according to the information recorded in the lock file, which records the version of the dependency installation, which can sometimes avoid some unnecessary problems. At the same time, you can also speed up your dependency on downloads. If there is no lock.yam, npm will download the latest version of the dependency, but sometimes the latest version of the dependency may affect the project.

Hi @wangsizhu0504 , why do you add the pnpm-lock.yaml?

When there is a lock file, the front-end installation dependency will be downloaded according to the information recorded in the lock file, which records the version of the dependency installation, which can sometimes avoid some unnecessary problems. At the same time, you can also speed up your dependency on downloads. If there is no lock.yam, npm will download the latest version of the dependency, but sometimes the latest version of the dependency may affect the project.

We can refer other apache projects how to solve this problem, such as Apache Flink

Hi @wangsizhu0504 , why do you add the pnpm-lock.yaml?

When there is a lock file, the front-end installation dependency will be downloaded according to the information recorded in the lock file, which records the version of the dependency installation, which can sometimes avoid some unnecessary problems. At the same time, you can also speed up your dependency on downloads. If there is no lock.yam, npm will download the latest version of the dependency, but sometimes the latest version of the dependency may affect the project.

We can refer other apache projects how to solve this problem, such as Apache Flink

ok! Well, it was thoughtless before. The current solution is to clear the lock file (the official source of NPM in China is slow to download), and add the method of setting the image source in readme. Chinese developers can speed up dependent downloads according to this method when using this project


android can not build with error compile

Hi! 👋
Firstly, thanks for your work on this project! 🙂
Today I used patch-package to patch<EMAIL_ADDRESS>for the project I'm working on.

Here is the diff that solved my problem:
diff --git a/node_modules/react-native-i18n/android/build.gradle b/node_modules/react-native-i18n/android/build.gradle
index 2614c62..746b873 100644
--- a/node_modules/react-native-i18n/android/build.gradle
+++ b/node_modules/react-native-i18n/android/build.gradle
@@ -22,5 +22,5 @@ android {
 }

 dependencies {
-  compile "com.facebook.react:react-native:+" // From node_modules
+  implementation "com.facebook.react:react-native:+" // From node_modules
 }

This issue body was partially generated by patch-package.

This solved the problem for me as well, thank you!

I'm facing the same issue, how to fix it ?

This solved the problem for me as well

This will help https://www.youtube.com/watch?v=1JhdbLl-Kdg


Can't start a service

I'm trying to start nginx service like this:
systemctl start nginx

but i get the following error:
System has not been booted with systemd as init system (PID 1). Can't operate.

I know that WSL currently uses a proprietary init process, but I don't know how to use it to start/restart/stop services.
It's also interesting to note that with Ubuntu WSL the command service nginx start works fine. Is it possible to do the same thing with Arch WSL ?

I finally got nginx started 🎉
I just opened the nginx service file (\usr\lib\systemd\system\nginx.service) and run the command at the line that contains ExecStart:
/usr/bin/nginx -g 'pid /run/nginx.pid; error_log stderr;'

It's probably possible to make a script that run services this way automatically.

Microsoft/WSL#1579
WSL does not support systemd / an init system, so you cannot use services. You have to run the commands yourself.

It seems to be possible in Debian WSL.

We can't use service command on Arch Linux,because Arch Linux doesn't supports openrc,.
Arch Linux designed for use systemd.
but you can install openrc from AUR,probably you can use rc-* command for control services.

i m getting below error when i run
'systemctl start postgresql '
please help me...
System has not been booted with systemd as init system (PID 1). Can't operate.

@mithunpp4u
please run program manually.
run /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data

@yuk7
Sir i m a newbie ,
And when i exicute  run /usr/bin/postgres -D /usr/pgsql/data
I m getting,  bash: run command not found

@mithunpp4u
excute this line↓
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data

I'm currently using batch scripts in the windows startup folder as an alternative, for example:
bash
Could probably even configure it to launch as a windows service somehow to have auto restart and stopping working correctly

I think that issue is indeed https://github.com/Microsoft/WSL/issues/2576
Separate issue.

I wasn't mentioning an issue @yuk7 , was merely offering a temporary workaround until the problem is fixed.

I couldn't get working OpenRC so I used Supervisor which is working great for automatically starting my services and managing it.

I don't seem to be able to start cronie or crontab with supervisor, how would you start it?

People, who need to run services on Arch on WSL, might also be interested in runit and/or Artix.
I provide daily Artix for WSL builds on my repo, along with the simple script to start service supervisor right from Windows Powershell

Replacing /init is safe?

For anyone, still interested runit is pretty good. I even use it in my real arch linux machine. All you need to do is download runit-systemd. The services can be written with simple shell scripts that can run super fast if you use link dash to sh in arch. It's amazing.

Replacing /init is safe?

safe but not working at all---wsl will still use Microsoft's init

What about WSL2? I heard that there can be ported systemd by using fake namespacing or so?

It's possible to bypass that in a hacky way using genie

I created systemctl alternative script package
https://github.com/yuk7/arch-systemctl-alt/releases/tag/1.4.3027-1

I created systemctl alternative package and documented it.
If you use WSL2,you can use genie.
that's all we can do.
This is a common problem with container Linux and WSL.

You can work around the issues with systemctl by replacing it with this script by @gdraheim:
https://github.com/gdraheim/docker-systemctl-replacement/blob/master/files/docker/systemctl.py
just do the following (assumes /usr/bin/systemctl) :
mv /usr/bin/systemctl /usr/bin/systemctl.old
curl https://raw.githubusercontent.com/gdraheim/docker-systemctl-replacement/master/files/docker/systemctl.py > /usr/bin/systemctl
chmod +x /usr/bin/systemctl

Thanks, i can confirm this script is working, i have my systemctl now :)

microsoft/WSL#1579
WSL does not support systemd / an init system, so you cannot use services. You have to run the commands yourself.

I don't get it. If you use the Ubuntu image from the Microsoft Store, it ships with Systemd. No idea why it does not work with this Arch distro!

I created systemctl alternative package and documented it.

TGhe document link in comment https://github.com/yuk7/ArchWSL/issues/20#issuecomment-545245760 is broken. From some looking around this might be the next/newest info:
https://wsldl-pg.github.io/ArchW-docs/Known-issues/#systemdsystemctl

Windows Task Scheduler is an alternative for those services that can be run through commands. Timers work well too for repeated tasks.

You can work around the issues with systemctl by replacing it with this script by @gdraheim: https://github.com/gdraheim/docker-systemctl-replacement/blob/master/files/docker/systemctl.py
just do the following (assumes /usr/bin/systemctl) :
mv /usr/bin/systemctl /usr/bin/systemctl.old
curl https://raw.githubusercontent.com/gdraheim/docker-systemctl-replacement/master/files/docker/systemctl.py > /usr/bin/systemctl
chmod +x /usr/bin/systemctl

That worked for me! Thanks!

You can work around the issues with systemctl by replacing it with this script by @gdraheim: https://github.com/gdraheim/docker-systemctl-replacement/blob/master/files/docker/systemctl.py
just do the following (assumes /usr/bin/systemctl) :
mv /usr/bin/systemctl /usr/bin/systemctl.old
curl https://raw.githubusercontent.com/gdraheim/docker-systemctl-replacement/master/files/docker/systemctl.py > /usr/bin/systemctl
chmod +x /usr/bin/systemctl

That worked for me! Thanks!

You need to install python2 first
$ sudo pacman -Syuu
$ sudo pacman -S python2
$ sudo mv /usr/bin/systemctl /usr/bin/systemctl.old
$ sudo curl https://raw.githubusercontent.com/gdraheim/docker-systemctl-replacement/master/files/docker/systemctl.py -o /usr/bin/systemctl
$ sudo chown root /usr/bin/systemctl
$ sudo chgrp root /usr/bin/systemctl
$ sudo chmod +x /usr/bin/systemctl

You can work around the issues with systemctl by replacing it with this script by @gdraheim: https://github.com/gdraheim/docker-systemctl-replacement/blob/master/files/docker/systemctl.py
just do the following (assumes /usr/bin/systemctl) :
mv /usr/bin/systemctl /usr/bin/systemctl.old
curl https://raw.githubusercontent.com/gdraheim/docker-systemctl-replacement/master/files/docker/systemctl.py > /usr/bin/systemctl
chmod +x /usr/bin/systemctl

its worked, thanks a lot sir , savior !


[Discussion] Could there be a Misc section?

This is a discussion for whether adding a miscellaneous section is necessary or not.
I say it is, for projects like these.

I don't know if Misc is the right naming to use, but I also see a problem that we cannot add projects that are based on multiple technologies or are technology-agnostic here.

One possible solution would be to have the projects categorized based on what they provide, rather on how they are built, but that would create another problem as a big chunk of the projects here are libraries or programming tools. What do you think @anasAsh @mjalajel ?

Related to this issue, where can I add this project: https://jordanstreetart.com/

Related to this issue, where can I add this project: https://jordanstreetart.com/

@rayasharbain  I came here to add the same project but I don't know where to put it as well


[BUG] Electrical Arch Furnace ouput all oredict steel ingots at the same time

Version of Advanced Rocketry
Version 1.6.0-164
Have you verified this is an issue in the latest unstable build
Yes.
Version of LibVulpes
Version 0.4.1-62
Version of Minecraft
Minecraft version 1.12.2
Does this occur without other mods installed
No it doesn't. With only AdvancedRocketry you receive the native ingot. With another mod (i.e. Thermal Expansion) I recived its steel ingot.
Description of the problem
I attempted to make steel in the Alectrical Arc Furnace (from Advanced Rocketry) and with only the input of 1 charcoal and 1 iron it outputted 4 steel ingots, one from each mod (TE, Mek, NC, libVulpes). The recipe is the same in JEI (re:outputs)
The speed multiplier was at 1.95. (three aluminium coils) Power was provided through hardened redstoneflux conduits supplied by a Nuclearcraft fission (et.al.) reactor. The ouput was automated through Buildcraft pipes with a pulsar gate.

I regenerated the XML file for the Electrical Arc Furnace and that fixed it.


AttributeError: module 'stable_baselines3.common.logger' has no attribute 'record'

submit issue
`Traceback (most recent call last):

  File "/finrl/env/env_stocktrading.py", line 210, in step
    logger.record("environment/portfolio_value", end_total_asset)
AttributeError: module 'stable_baselines3.common.logger' has no attribute 'record'`

hello, how to solve this problem. I met the same issue.

They made some changes to logging in stable baselines
There is an example of the change in this module  - https://github.com/DLR-RM/stable-baselines3/blob/master/stable_baselines3/common/base_class.py
You need to do something along the lines of the following:
from stable_baselines3.common import utils
self._logger = utils.configure_logger(self.verbose, self.tensorboard_log, tb_log_name, reset_num_timesteps)

Can anyone describe the solution to this in more detail? I am following this tutorial for reference. https://github.com/AI4Finance-LLC/FinRL/blob/master/tutorials/tutorial_multistock_docker.ipynb
@BruceYanghy , @spencerR1992 , @XiaoYangLiu-FinRL

Can anyone describe the solution to this in more detail? I am following this tutorial for reference. https://github.com/AI4Finance-LLC/FinRL/blob/master/tutorials/tutorial_multistock_docker.ipynb
Update: I fixed this error but a new one has appeared. Now I get 'StockTradingEnvV2' object has no attribute 'verbose'
@BruceYanghy , @XiaoYangLiu-FinRL

do this
replace the current import with
from stable_baselines3.common import utils
insert below line in the class
self.logger = utils.configure_logger()
all the other places which has reference to logger should be replaced with self.logger

Is it working for you @kmungantiwar and is it getting saved in the environment folder, I have done the necessary changes that you suggested, plus we need to specify the tensorboard dir and name in configure_logger
self.logger = utils.configure_logger(tensorboard_log=config.TENSORBOARD_LOG_DIR,tb_log_name="environment")
Still, nothing is getting logged.


Change from 1.5.5 to 1.6.2 results in authentication failure.

We have some code that successfully talks to a Google API using v1.5.5 but breaks under v1.6.2 with the following error:
"Request is missing required authentication credential. Expected OAuth 2 access token, login cookie or other valid authentication credential"
Our build statement looks like:
 return build(
     'monitoring',
     'v3',
     discoveryServiceUrl=discovery_url,
     developerKey=self.api_key,
     credentials=credentials)

I'm wondering if the following commit may be culprit here:
https://github.com/google/google-api-python-client/commit/068eb35c9a70e31a42f04d5cb69c36d59e4a2a69

Because we supply both "credentials" and "developerKey" and expect the bearer token / other context from the credentials to be propagated regardless of the presence of "developerKey" (it was my understanding that "developerKey" simply adds a "key=" to the discovery URL and to the API requests, but the headers implied by the credentials should still be provided in this case).
Can you fix this? Thanks!

@michaelsafyan which API are you using that requires both a developer key and credentials?

Oh, I see, monitoring. You can just leave out the developer key, the monitoring API does not use it.

The developerKey is needed for visibility labels.

Looking in more detail, it looks like the API key is needed on the discovery URL but not on subsequent API calls which only need the HTTP bearer token.

We can workaround by dropping developerKey and manually appending the API key to the discovery URL (building the discovery URL ourselves rather than relying on the client library to construct the discovery URL), but it would be ideal if this worked correctly without that workaround.

I should also add, on top of the above, that if both a developerKey and credentials object are supplied but only one of the two is applied, wouldn't credential make more sense? Typically credentials include more authority than a simple API key. It may also make sense to log a warning/error to make this condition easier to debug (it took about two days to figure out the issue was in the client library version, not a result of IAM permissions or other causes).

Looking in more detail, it looks like the API key is needed on the discovery URL but not on subsequent API calls which only need the HTTP bearer token.

Weird, developerKey should only be needed there for non-public (alpha/beta/EAP) APIs.

I should also add, on top of the above, that if both a developerKey and credentials object are supplied but only one of the two is applied, wouldn't credential make more sense? Typically credentials include more authority than a simple API key. It may also make sense to log a warning/error to make this condition easier to debug (it took about two days to figure out the issue was in the client library version, not a result of IAM permissions or other causes).

Yeah, absolutely. This is a bit tricky. :) I agree it should either apply both or error.

Just to clarify, it is a non-public API (the Monitoring API includes both publicly released portions as well as portions that are restricted behind visibility labels). I'm currently working on a team that is iterating towards an EAP on one of these subsets of the API, and the code that broke is demo client code that uses only the external client library code to demo / test / verify the functioning of this part of the API.


Out of sync

Greetings. Cool project you have here... with one current exception.
This project seems to be out of sync with npmjs.com e.g. 2653218/package.json#L3 shows 1.1.1 and npm shows
Will there be an update somewhere to fix this?
Thanks so much.

https://github.com/chalk/chalk/commits/1.1.3

I did see that there is a branch with 1.1.3 but the repo doesn't appear to be set to default to that.

So the issue shouldn't be closed.

@Martii what's the problem? In any way you get latest version - 1.1.3, and as you can see the diffs between are just bump of one dep.

Well it's a little confusing that I had to go diving for a branch to verify things are still aok for dep updates... would be nice to have it mentioned in the README.md. Even the releases show 1.1.1.

Even the releases show 1.1.1.

Good point.

verify things are still aok

they are okey, that's a patch bump - no breaking changes or new features.

@Martii It's common to create separate release branches for patch/minor versions of older major versions. Master is currently targeting a 2.0.0 release.

1.1.3 is a roll back from the botched release 1.1.2. It was an emergency situation that led to a few things being wonky for a while. The next time we release, things should be synced up.
Further, npm has been doing weird things lately with the whole unpublish/Azer/left-pad stuff. I've seen strange behavior being reported all over the internet about it - especially caching problems. I also have text alerts set up for them when things go awry and lately there have been a lot of outages and 2spooky4me stuff going on.


installation: problem with cryptography minimum version

As you can see here: https://travis-ci.org/inveniosoftware/invenio-oauthclient/builds/158729080
There is a issue with lowest requirements and python 2.7.
CDefError: 'point_conversion_form_t' has no values explicitly defined: refusing to guess which integer type it is meant to be (unsigned/signed, int/long)

I think I found the problem and I'll make a PR.

Closed via 5098fd6dbf4d8bffe0d2f87719a19370c64dc7c2


Failing to verify the application id?

Hey, I was playing around with this library, and I noticed that I could get a token issued under one client id, and validate it with another. It's possible I'm missing something, but I think this may be vulnerable to a confused deputy problem.
For example, I can take my oauth app from Google:
926872579832-ruurs5s2cirehpavk7141n2tqqjj5el5.apps.googleusercontent.com

Generate a token with it using this link, in a browser (I'm doing this from Ember, which doesn't matter):
https://accounts.google.com/o/oauth2/v2/auth?response_type=token&client_id=926872579832-ruurs5s2cirehpavk7141n2tqqjj5el5.apps.googleusercontent.com&redirect_uri=http%3A%2F%2Flocalhost%3A4200%2Ftorii%2Fredirect.html&state=z7D36Js0tlu8b6Xx&scope=email

Which gives me the token:
ya<censored>8e

If I use tokeninfo, it validates to that app id:
$ curl 'https://www.googleapis.com/oauth2/v3/tokeninfo?access_token=ya<censored>8e'

{
"azp": "926872579832-ruurs5s2cirehpavk7141n2tqqjj5el5.apps.googleusercontent.com",
"aud": "926872579832-ruurs5s2cirehpavk7141n2tqqjj5el5.apps.googleusercontent.com",
"sub": "",
"scope": "https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/plus.me",
"exp": "1508539316",
"expires_in": "3522",
"email"<EMAIL_ADDRESS>"email_verified": "true",
"access_type": "online"
}
But when I validate it in passport-google-token configured as such (note that clientID is different, as is clientSecret):
  passport.use(
    new GoogleTokenStrategy({
      clientID: '926872579832-dij365g8vl2j7ntsq8ib09toegel1lp1.apps.googleusercontent.com',
      clientSecret: '<censored>',
    },
    function(accessToken, refreshToken, profile, done) {
      console.log(accessToken);
      console.log(profile);

      return done(null, {});
    })
  );

It successfully validates the token (I'm censoring some fields):
{ provider: 'google',
  id: '<id>',
  displayName: '',
  name: { familyName: '', givenName: '' },
  emails: [ { value: '<email>' } ],
  _raw: '{\n "id": "<id>",\n "email": "<email>",\n "verified_email": true,\n "name": "",\n "given_name": "",\n "family_name": "",\n "picture": "https://lh3.googleusercontent.com/-XdUIqdMkCWA/AAAAAAAAAAI/AAAAAAAAAAA/4252rscbv5M/photo.jpg",\n "hd": "<email>"\n}\n',
  _json:
   { id: '<id>',
     email: '<email>',
     verified_email: true,
     name: '',
     given_name: '',
     family_name: '',
     picture: 'https://lh3.googleusercontent.com/-XdUIqdMkCWA/AAAAAAAAAAI/AAAAAAAAAAA/4252rscbv5M/photo.jpg',
     hd: '<domain>' } }

I'm pretty sure that's incorrect behaviour. From Google's docs, it says:

Important: Before using the token, you need to verify that this field's value exactly matches your Client ID in the Google API Console. This verification ensures that your application is not vulnerable to the confused deputy problem.

I'm pretty sure that's not happening.

I noticed looking at the code that this uses userinfo and not tokeninfo, so it might be that this library isn't designed to validate the token, just to use it. Let me know if that's the case. :)


Button click event callback never fired if mouse down in button but mouse up outside of button

Description
I am finding that a buttons click event callback never gets fired if the user mouses down with the button in focus (inside the button) but mouses up when the button isn't in focus (outside of the button).
To Reproduce

Configure a button as follows:

static lv_res_t enable(lv_obj_t* obj)
{
    printf("enabling something\n");
    return LV_RES_OK;
}

static lv_res_t disable(lv_obj_t* obj)
{
    printf("disabling something\n");
    return LV_RES_OK;
}

void foo(void)
{
    lv_obj_t* fooBtn = lv_btn_create(lv_scr_act(), NULL);
    lv_btn_set_action(fooBtn, LV_BTN_ACTION_PR, enable);
    lv_btn_set_action(fooBtn, LV_BTN_ACTION_CLICK, disable);
    lv_obj_set_height(fooBtn, 35);
    lv_obj_t* fooBtnLbl = lv_label_create(fooBtn, NULL);
    lv_label_set_text(fooBtnLbl, "Foo");
}

Launch application
Mouse down in button and hold mouse down until step 5, observe press event handler is executed
Drag mouse outside of button
Release mouse down (mouse up)
Issue: Observe the click event handler never got executed

Expected behavior
I would have expected the click event handler to still get fired after dragging the mouse outside of the button.
Screenshots
NA
Additional context

LVGL version: 5.2.0

Coworker created a patch. Add the following:
if(ext->actions[LV_BTN_STATE_REL] && state != LV_BTN_STATE_INA) {
    res = ext->actions[LV_BTN_STATE_REL](btn);
}

to the end of the if(ext->state == LV_BTN_STATE_PR) block that is inside the else if (sign == LV_SIGNAL_PRESS_LOST) block of the lv_btn_signal() function found in the lv_btn.c source file.


Support for non integer offset values

Some databases support functions/ sub query for determining offset values like
for ex in postgres this is allowed
SELECT myid FROM mytable OFFSET floor(random()*N) ;
or
SELECT myid FROM mytable OFFSET (SELECT COUNT(myid)-100 FROM MYtable) ;
However yii\db\QueryTrait supports only integer offsets
Support for function based/ subquery based offset values, alternatively non integer values should not be allowed in the function argument

I guess it could be done with Expression.

There is a little problem: in order to support yi\\db\Expression with params an additional argument should be added to the method QueryBuilder::buildLimit(), which actually breaks a BC.

@klimov-paul Is that really needed?
For orderBy it is solved by adding the params after building the sql snippet:
$sql = $this->buildOrderByAndLimit($sql, $query->orderBy, $query->limit, $query->offset);

        if (!empty($query->orderBy)) {
            foreach ($query->orderBy as $expression) {
                if ($expression instanceof Expression) {
                    $params = array_merge($params, $expression->params);
                }
            }
        }

It seems like the same could be done for limit and offset?

Won't be implemented in 2.0.


⚠ Processors has degraded performance

In 4fbb53d, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 47 ms

Resolved: Processors performance has improved in 56e7505.


Compiler implementation

@mm0821 I fixed the rendering bug and evidence now renders as expected:

@b-studios I've drafted an explanation of lift inference. Maybe you can take a look if you find the time.

Great thanks @mm0821. I left a few comments, but LGTM otherwise

In general, it would also be great to have a compiler pipeline picture summarizing the different phases (linking lift inference) to your description. The other phases could easily be described later in separate documents.
Right now, the main description of the compiler pipeline can be found in https://github.com/effekt-lang/effekt/blob/master/effekt/shared/src/main/scala/effekt/Compiler.scala -- though I just noticed that the overview does not mention lift.

I've drafted the picture and a description of the pipeline.
@b-studios Please take a look.

Looks great, thanks!


Add pyproject.toml

pip 18.0 is out with complete PEP 518 support :tada: so we should add a pyproject.toml to list all the dependencies instead of using setup.py. I don't think we have to wait for pip 18 to arrive to conda-forge (https://github.com/conda-forge/pip-feedstock/pull/13), since the escenarios are:

System Python: they would have to create a virtual environment anyway, since it's likely too old (Python 2 or 3.4).
Virtualenv/pipenv/pyenv or similar: they will be able to upgrade pip before the next release of poliastro is out.
conda environment + pip: pip 10 is already in defaults and pip 18 will be everywhere soon (hopefully), so I guess there won't be problems here either.
conda environment + conda: they will use the conda package anyway.

I didn't think about this carefully enough, and in fact we already have a pyproject.toml that specifies the minimum build requirements. The runtime requirements are left for PEP 517:
https://www.python.org/dev/peps/pep-0517/
Which will likely see the light in a future release of pip.

This only makes sense if we use flit, so this is blocked on #252, which is closed until further notice.


Made font consistent across entire webpage.

Pull Request Checklist
BEFORE ADDING FONT:

The font of the navbar and body is different which makes website looks incompatible.

AFTER MAKING FONT CONSITENT FOR ENTIRE WEBPAGE:
-Updated the font across all pages to 'Vollkorn' to ensure consistency.

This change improves the visual coherence of the website and enhances readability.

[ YES] I have added screenshots and videos to show before and after the working of my code.
[YES ] I have ensured that the screen size is set to 100% while making the video.
[YES ] I have synced the latest fork with my local repository and resolved any conflicts.
[YES ] I understand that if any the above conditions are not met , my PR will not be MERGED .

-Closes #201

This branch has conflicts that must be resolved
refork and resync the repo

Kindly refork and resync you have old files


enable_cody: false in setup fails plugin during config

I'm trying to use this plugin with an enterprise installation that doesn't have cody enabled (and likely never will). I found enable_cody in config help, but get the following error on startup when setting that:
Failed to run `config` for sg.nvim

.../share/nvim/lazy/sg.nvim/lua/sg/cody/plugin/commands.lua:169: Invalid command (not found): CodyRestart

# stacktrace:
  - /sg.nvim/lua/sg/cody/plugin/commands.lua:169 _in_ **delete_command**
  - /sg.nvim/lua/sg/cody/plugin/commands.lua:186 _in_ **setup**
  - /sg.nvim/lua/sg/init.lua:40 _in_ **setup**
  - dotfiles/nvim/.config/nvim/init.lua:301 _in_ **config**
  - dotfiles/nvim/.config/nvim/init.lua:91

I'm using Lazy as the plugin manager, and here's my setup for sg.nvim:
{
    "sourcegraph/sg.nvim",
    dependencies = {
        "nvim-lua/plenary.nvim",
        "nvim-telescope/telescope.nvim",
    },
    config = function()
        require("sg").setup({
            enable_cody = false,
        })
    end,
},

and :checkhealth sg:
sg: require("sg.health").check()

sg.nvim report
- Machine: arm64, sysname: Darwin
- OK Valid nvim version: table: 0x0104e4b240
- ERROR sg.nvim has not been setup. See ':help sg' for more info.
- ERROR Run require('sg').setup() somewhere in your configuration

Ah, I think I found the problem -- if you're still having an error, let me know.


[VSCodeEndGameTesting-Aditi][Command-Palette] Getting error when trying to run command for dnx.

From @v-pavanp on March 10, 2016 1:47
OS: Windows 10
VS Code Version: 0.10.12-alpha
Node: 4.1.1
Steps:

Launch VS code.
Launch command palette by pressing CTRL+P and inter ">dnx" and selection option for Run command.
Verify editor response.
Actual: Getting error "omniSharp" server is not running.
Expected: It should run the command and ask for re-start.

Copied from original issue: Microsoft/vscode#3944

This is very stale at this point.


Pybids doesn't detect the files in derivatives

The pybids seams ignores the files in derivatives

@Peyman-N yes. Derivatives do not have (yet) a clear specification in BIDS and are therefore not reliably to capture in an automated conversion between BIDS datasets and openMINDS. Please ignore derivatives for now.


Filter window not updated properly for split='no'

Problems summary
ddu-ui-ff does not renew the filter window properly when split='no'. When I enter the first letter for filtering, the filter window shows the result of filtering. The filter window no longer accepts input because it is showing filtered result, which is not modifiable. This is also reproduced in vim=v9.0.1676. It works perfectly fine when split='horizontal' is set.
Expected
The filter window should not show the filtered result. Even after the input of the first letter, it should retain the filtering window.
Environment Information

ddu-ui-ff version (SHA1):a5238c6fea598f7b8f76d1c2ce280a7b01753aa5

denops.vim version (SHA1):62b1d22b3e60fcc9e570a531a5af1e4b2393c15a

deno version(deno -V output): deno 1.34.3

OS: arch linux

neovim/Vim :version output:

NVIM v0.9.1
Build type: Release
LuaJIT 2.1.0-beta3

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info

Provide a minimal init.vim/vimrc without plugin managers (Required!)
set runtimepath^=~/.plugins/Shougo/ddu-commands.vim
set runtimepath^=~/.plugins/Shougo/ddu-filter-matcher_substring
set runtimepath^=~/.plugins/Shougo/ddu-source-file_old
set runtimepath^=~/.plugins/Shougo/ddu-ui-ff
set runtimepath^=~/.plugins/Shougo/ddu.vim
set runtimepath^=~/.plugins/vim-denops/denops.vim

call ddu#custom#patch_global({
\   'ui': 'ff',
\   'uiParams': {
\     'ff': {
\       'split': 'no',
\     },
\   },
\   'sourceOptions': {
\     '_': {
\       'matchers': ['matcher_substring'],
\     },
\   },
  \ })

nnoremap <SPACE>fo <Cmd>Ddu -name=find file_old<CR>

autocmd FileType ddu-ff call s:ddu_my_settings()
function! s:ddu_my_settings() abort
  nnoremap <buffer> i <Cmd>call ddu#ui#do_action('openFilterWindow')<CR>
endfunction

How to reproduce the problem from neovim/Vim startup (Required!)

press 'SPACE fo'
press 'i'
enter the first letter to filter and you will not be able to continue filtering.

Fixed.


confluent_kafka_topic always show configuration drift for unchanged Topic config

I am trying to make some changes on another topic configuration, but terraform plan result always showing configuration diff for topic that not being changed/updated.
As example below, I have 3 topic, I only change topic-c retention from 7 days to 15 days. But both topic-a and topic-b are also said to be updated as well.
Example :
terraform {
  required_version = "~> 1.2.0"

  required_providers {
    confluent = {
      source  = "confluentinc/confluent"
      version = "1.4.0"
    }
  }
}

locals {
  retention = {
    _7days  = 604800000
    _15days =<PHONE_NUMBER>
  }
  kafka_topics = {
    "topic-a" = {
      partitions_count    = 8
      min_insync_replicas = 2
      retention_ms        = local.retention._7days
    }
    "topic-b" = {
      partitions_count    = 16
      min_insync_replicas = 2
      retention_ms        = local.retention._7days
    }
    "topic-c" = {
      partitions_count    = 8
      min_insync_replicas = 2
      retention_ms        = local.retention._15days
    }
  }
}

resource "confluent_kafka_topic" "dev_topics" {
  kafka_cluster {
    id = confluent_kafka_cluster.kafka-cluster-dev.id
  }
  for_each         = local.kafka_topics
  topic_name       = each.key
  partitions_count = each.value.partitions_count
  config = {
    "min.insync.replicas"    = each.value.min_insync_replicas
    "retention.ms"           = each.value.retention_ms
    "message.timestamp.type" = "CreateTime"
    "segment.bytes"          = "536870912"
    "max.message.bytes"      = "2097164"
  }
  rest_endpoint = confluent_kafka_cluster.kafka-cluster-dev.rest_endpoint
  credentials {
    key    = confluent_api_key.dev_rw_api_key.id
    secret = confluent_api_key.dev_rw_api_key.secret
  }
}

Log :
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # confluent_kafka_topic.dev_topics["topic-a"] will be updated in-place
  ~ resource "confluent_kafka_topic" "dev_topics" {
      ~ config           = {
          + "max.message.bytes"      = "2097164"
          + "retention.ms"           = "604800000"
            # (3 unchanged elements hidden)
        }
        id               = "lkc-6kz1xx/topic-a"
        # (3 unchanged attributes hidden)

        # (2 unchanged blocks hidden)
    }

  # confluent_kafka_topic.dev_topics["topic-b"] will be updated in-place
  ~ resource "confluent_kafka_topic" "dev_topics" {
      ~ config           = {
          + "max.message.bytes"      = "2097164"
          + "retention.ms"           = "604800000"
            # (3 unchanged elements hidden)
        }
        id               = "lkc-6kz1xx/topic-b"
        # (3 unchanged attributes hidden)

        # (2 unchanged blocks hidden)
    }

  # confluent_kafka_topic.dev_topics["topic-c"] will be updated in-place
  ~ resource "confluent_kafka_topic" "dev_topics" {
      ~ config           = {
          + "max.message.bytes"      = "2097164"
          ~ "retention.ms"           = "1296000000" -> "604800000"
            # (3 unchanged elements hidden)
        }
        id               = "lkc-6kz1xx/topic-c"
        # (3 unchanged attributes hidden)

        # (2 unchanged blocks hidden)
    }
Plan: 0 to add, 3 to change, 0 to destroy.

Step to reproduce :
terraform plan

@robertusnegoro thanks for opening an issue!
Could you split your example TF configuration into "before change" and "after change" so it's easier to reproduce?

@linouk23 Sure, here is the before change code :
locals {
  retention = {
    _7days  = 604800000
    _15days =<PHONE_NUMBER>
  }
  kafka_topics = {
    "topic-a" = {
      partitions_count    = 8
      min_insync_replicas = 2
      retention_ms        = local.retention._7days
    }
    "topic-b" = {
      partitions_count    = 16
      min_insync_replicas = 2
      retention_ms        = local.retention._7days
    }
    "topic-c" = {
      partitions_count    = 8
      min_insync_replicas = 2
      retention_ms        = local.retention._7days
    }
  }
}

resource "confluent_kafka_topic" "dev_topics" {
  kafka_cluster {
    id = confluent_kafka_cluster.kafka-cluster-dev.id
  }
  for_each         = local.kafka_topics
  topic_name       = each.key
  partitions_count = each.value.partitions_count
  config = {
    "min.insync.replicas"    = each.value.min_insync_replicas
    "retention.ms"           = each.value.retention_ms
    "message.timestamp.type" = "CreateTime"
    "segment.bytes"          = "536870912"
    "max.message.bytes"      = "2097164"
  }

The after code is exactly the same with the snippet I wrote on first / issue starter above.

 Resources: 3 added, 0 changed, 0 destroyed.

✗ terraform plan
confluent_kafka_topic.dev_topics["topic-b"]: Refreshing state... [id=lkc-xxmrrx/topic-b]
confluent_kafka_topic.dev_topics["topic-a"]: Refreshing state... [id=lkc-xxmrrx/topic-a]
confluent_kafka_topic.dev_topics["topic-c"]: Refreshing state... [id=lkc-xxmrrx/topic-c]

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.

✗ terraform plan
confluent_kafka_topic.dev_topics["topic-b"]: Refreshing state... [id=lkc-xxmrrx/topic-b]
confluent_kafka_topic.dev_topics["topic-a"]: Refreshing state... [id=lkc-xxmrrx/topic-a]
confluent_kafka_topic.dev_topics["topic-c"]: Refreshing state... [id=lkc-xxmrrx/topic-c]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # confluent_kafka_topic.dev_topics["topic-c"] will be updated in-place
  ~ resource "confluent_kafka_topic" "dev_topics" {
      ~ config           = {
          ~ "retention.ms"           = "604800000" -> "1296000000"
            # (4 unchanged elements hidden)
        }
        id               = "lkc-xxmrrx/topic-c"
        # (3 unchanged attributes hidden)

        # (2 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

✗ terraform apply --auto-approve
confluent_kafka_topic.dev_topics["topic-b"]: Refreshing state... [id=lkc-xxmrrx/topic-b]
confluent_kafka_topic.dev_topics["topic-c"]: Refreshing state... [id=lkc-xxmrrx/topic-c]
confluent_kafka_topic.dev_topics["topic-a"]: Refreshing state... [id=lkc-xxmrrx/topic-a]
confluent_kafka_topic.dev_topics["topic-c"]: Modifying... [id=lkc-xxmrrx/topic-c]
confluent_kafka_topic.dev_topics["topic-c"]: Still modifying... [id=lkc-xxmrrx/topic-c, 10s elapsed]
confluent_kafka_topic.dev_topics["topic-c"]: Modifications complete after 10s [id=lkc-xxmrrx/topic-c]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
➜  demo10 git:(remove-https-thin) ✗ terraform plan
confluent_kafka_topic.dev_topics["topic-b"]: Refreshing state... [id=lkc-xxmrrx/topic-b]
confluent_kafka_topic.dev_topics["topic-a"]: Refreshing state... [id=lkc-xxmrrx/topic-a]
confluent_kafka_topic.dev_topics["topic-c"]: Refreshing state... [id=lkc-xxmrrx/topic-c]

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.

Let me try again with 1.2.9.

 Resources: 3 added, 0 changed, 0 destroyed.
✗ terraform plan
confluent_kafka_topic.dev_topics["topic-a"]: Refreshing state... [id=lkc-xxmrrx/topic-a]
confluent_kafka_topic.dev_topics["topic-b"]: Refreshing state... [id=lkc-xxmrrx/topic-b]
confluent_kafka_topic.dev_topics["topic-c"]: Refreshing state... [id=lkc-xxmrrx/topic-c]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

✗ terraform plan
confluent_kafka_topic.dev_topics["topic-b"]: Refreshing state... [id=lkc-xxmrrx/topic-b]
confluent_kafka_topic.dev_topics["topic-c"]: Refreshing state... [id=lkc-xxmrrx/topic-c]
confluent_kafka_topic.dev_topics["topic-a"]: Refreshing state... [id=lkc-xxmrrx/topic-a]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # confluent_kafka_topic.dev_topics["topic-c"] will be updated in-place
  ~ resource "confluent_kafka_topic" "dev_topics" {
      ~ config           = {
          ~ "retention.ms"           = "604800000" -> "1296000000"
            # (4 unchanged elements hidden)
        }
        id               = "lkc-xxmrrx/topic-c"
        # (3 unchanged attributes hidden)

        # (2 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform apply" now.

✗ terraform apply --auto-approve
confluent_kafka_topic.dev_topics["topic-b"]: Refreshing state... [id=lkc-xxmrrx/topic-b]
confluent_kafka_topic.dev_topics["topic-a"]: Refreshing state... [id=lkc-xxmrrx/topic-a]
confluent_kafka_topic.dev_topics["topic-c"]: Refreshing state... [id=lkc-xxmrrx/topic-c]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # confluent_kafka_topic.dev_topics["topic-c"] will be updated in-place
  ~ resource "confluent_kafka_topic" "dev_topics" {
      ~ config           = {
          ~ "retention.ms"           = "604800000" -> "1296000000"
            # (4 unchanged elements hidden)
        }
        id               = "lkc-xxmrrx/topic-c"
        # (3 unchanged attributes hidden)

        # (2 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.
confluent_kafka_topic.dev_topics["topic-c"]: Modifying... [id=lkc-xxmrrx/topic-c]
confluent_kafka_topic.dev_topics["topic-c"]: Still modifying... [id=lkc-xxmrrx/topic-c, 10s elapsed]
confluent_kafka_topic.dev_topics["topic-c"]: Modifications complete after 11s [id=lkc-xxmrrx/topic-c]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
✗ terraform plan
confluent_kafka_topic.dev_topics["topic-a"]: Refreshing state... [id=lkc-xxmrrx/topic-a]
confluent_kafka_topic.dev_topics["topic-b"]: Refreshing state... [id=lkc-xxmrrx/topic-b]
confluent_kafka_topic.dev_topics["topic-c"]: Refreshing state... [id=lkc-xxmrrx/topic-c]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

@robertusnegoro could you confirm all 3 topics were created via TF? There's a well known friction that one have to specify all topic settings when importing a topic from UI but that doesn't seem to be a case here.

Apparently there is one or two topics outside of these three were created not from TF code, such as topic which automatically created when we create a managed connector. But these 3 topics is purely from the TF.
Another stuff (but I am not sure if it's related), these three topics also used by confluent-replicator as both source and destination.

2 things:

Could you confirm that terraform plan (after the 1st terraform apply) show 0 changes?
OK one way to get more debug data would be to use API to get a list of topic settings (for any topic) after terraform apply and see that for every topic setting, source is set to DYNAMIC_TOPIC_CONFIG:

{
  "kind": "KafkaTopicConfigList",
  "metadata": {
    "self": ".../topics/ui_orders2/configs",
    "next": null
  },
  "data": [
    {
{
  ...,
  "cluster_id": "lkc-m2rg1q",
  "name": "cleanup.policy",
  "value": "delete",
  "is_read_only": false,
  "is_sensitive": false,
  "source": "DYNAMIC_TOPIC_CONFIG",
  "synonyms": [
    {
      "name": "cleanup.policy",
      "value": "delete",
      "source": "DYNAMIC_TOPIC_CONFIG"
    },
    {
      "name": "log.cleanup.policy",
      "value": "delete",
      "source": "DEFAULT_CONFIG"
    }
  ],
  "topic_name": "ui_orders2",
  "is_default": false
},

Here's a list of target topic settings:
    "min.insync.replicas"
    "retention.ms"
    "message.timestamp.type"
    "segment.bytes"
    "max.message.bytes"

I can confirm that after first apply, terraform plan will show 0 changes. But after few minutes, it will show the permanent diff case again.
Here the output of 1 topic sample

{
  "kind": "KafkaTopic",
  "metadata": {
    "self": "https://pkc-xxxx.us-east1.gcp.confluent.cloud/kafka/v3/clusters/lkc-xxxx/topics/topic-a",
    "resource_name": "crn:///kafka=lkc-xxxx/topic=topic-a"
  },
  "cluster_id": "lkc-xxxx",
  "topic_name": "topic-a",
  "is_internal": false,
  "replication_factor": 3,
  "partitions_count": 4,
  "partitions": {
    "related": "https://pkc-xxxx.us-east1.gcp.confluent.cloud/kafka/v3/clusters/lkc-xxxx/topics/topic-a/partitions"
  },
  "configs": {
    "related": "https://pkc-xxxx.us-east1.gcp.confluent.cloud/kafka/v3/clusters/lkc-xxxx/topics/topic-a/configs"
  },
  "partition_reassignments": {
    "related": "https://pkc-xxxx.us-east1.gcp.confluent.cloud/kafka/v3/clusters/lkc-xxxx/topics/topic-a/partitions/-/reassignment"
  },
  "authorized_operations": []
}

Will it show 0 diff when running terraform plan in like 5 minutes too?

That's a great start! Could you send GET to configs.value (https://pkc-xxxx.us-east1.gcp.confluent.cloud/kafka/v3/clusters/lkc-xxxx/topics/topic-a/configs) that will list topic settings?

No, it will show the diff on unchanged topics configs. "No change" will only show at very first terraform plan and if I ran it quickly after apply finished.
Sure, here I got

  {
    "kind": "KafkaTopicConfig",
    "metadata": {
      "self": "https://pkc-xxxx.us-east1.gcp.confluent.cloud/kafka/v3/clusters/lkc-xxxx/topics/topic-a/configs/min.insync.replicas",
      "resource_name": "crn:///kafka=lkc-xxxx/topic=topic-a/config=min.insync.replicas"
    },
    "cluster_id": "lkc-xxxx",
    "name": "min.insync.replicas",
    "value": "2",
    "is_read_only": false,
    "is_sensitive": false,
    "source": "DYNAMIC_TOPIC_CONFIG",
    "synonyms": [
      {
        "name": "min.insync.replicas",
        "value": "2",
        "source": "DYNAMIC_TOPIC_CONFIG"
      },
      {
        "name": "min.insync.replicas",
        "value": "2",
        "source": "STATIC_BROKER_CONFIG"
      },
      {
        "name": "min.insync.replicas",
        "value": "1",
        "source": "DEFAULT_CONFIG"
      }
    ],
    "topic_name": "topic-a",
    "is_default": false
  },
  {
    "kind": "KafkaTopicConfig",
    "metadata": {
      "self": "https://pkc-xxxx.us-east1.gcp.confluent.cloud/kafka/v3/clusters/lkc-xxxx/topics/topic-a/configs/retention.ms",
      "resource_name": "crn:///kafka=lkc-xxxx/topic=topic-a/config=retention.ms"
    },
    "cluster_id": "lkc-xxxx",
    "name": "retention.ms",
    "value": "604800000",
    "is_read_only": false,
    "is_sensitive": false,
    "source": "DYNAMIC_TOPIC_CONFIG",
    "synonyms": [
      {
        "name": "retention.ms",
        "value": "604800000",
        "source": "DYNAMIC_TOPIC_CONFIG"
      }
    ],
    "topic_name": "topic-a",
    "is_default": false
  },
  {
    "kind": "KafkaTopicConfig",
    "metadata": {
      "self": "https://pkc-xxxx.us-east1.gcp.confluent.cloud/kafka/v3/clusters/lkc-xxxx/topics/topic-a/configs/message.timestamp.type",
      "resource_name": "crn:///kafka=lkc-xxxx/topic=topic-a/config=message.timestamp.type"
    },
    "cluster_id": "lkc-xxxx",
    "name": "message.timestamp.type",
    "value": "CreateTime",
    "is_read_only": false,
    "is_sensitive": false,
    "source": "DYNAMIC_TOPIC_CONFIG",
    "synonyms": [
      {
        "name": "message.timestamp.type",
        "value": "CreateTime",
        "source": "DYNAMIC_TOPIC_CONFIG"
      },
      {
        "name": "log.message.timestamp.type",
        "value": "CreateTime",
        "source": "DEFAULT_CONFIG"
      }
    ],
    "topic_name": "topic-a",
    "is_default": false
  },
  {
    "kind": "KafkaTopicConfig",
    "metadata": {
      "self": "https://pkc-xxxx.us-east1.gcp.confluent.cloud/kafka/v3/clusters/lkc-xxxx/topics/topic-a/configs/segment.bytes",
      "resource_name": "crn:///kafka=lkc-xxxx/topic=topic-a/config=segment.bytes"
    },
    "cluster_id": "lkc-xxxx",
    "name": "segment.bytes",
    "value": "536870912",
    "is_read_only": false,
    "is_sensitive": false,
    "source": "DYNAMIC_TOPIC_CONFIG",
    "synonyms": [
      {
        "name": "segment.bytes",
        "value": "536870912",
        "source": "DYNAMIC_TOPIC_CONFIG"
      },
      {
        "name": "log.segment.bytes",
        "value": "104857600",
        "source": "STATIC_BROKER_CONFIG"
      },
      {
        "name": "log.segment.bytes",
        "value": "1073741824",
        "source": "DEFAULT_CONFIG"
      }
    ],
    "topic_name": "topic-a",
    "is_default": false
  },
  {
    "kind": "KafkaTopicConfig",
    "metadata": {
      "self": "https://pkc-xxxx.us-east1.gcp.confluent.cloud/kafka/v3/clusters/lkc-xxxx/topics/topic-a/configs/max.message.bytes",
      "resource_name": "crn:///kafka=lkc-xxxx/topic=topic-a/config=max.message.bytes"
    },
    "cluster_id": "lkc-xxxx",
    "name": "max.message.bytes",
    "value": "2097164",
    "is_read_only": false,
    "is_sensitive": false,
    "source": "STATIC_BROKER_CONFIG",
    "synonyms": [
      {
        "name": "message.max.bytes",
        "value": "2097164",
        "source": "STATIC_BROKER_CONFIG"
      },
      {
        "name": "message.max.bytes",
        "value": "1048588",
        "source": "DEFAULT_CONFIG"
      }
    ],
    "topic_name": "topic-a",
    "is_default": false
  }

@linouk23 I tried to keep the config.value before and after "re-apply". And compare them using diff command. Here I got :
❯ diff before-apply.json after-apply.json
221c221
<       "source": "STATIC_BROKER_CONFIG",
---
>       "source": "DYNAMIC_TOPIC_CONFIG",
223a224,228
>           "name": "max.message.bytes",
>           "value": "2097164",
>           "source": "DYNAMIC_TOPIC_CONFIG"
>         },
>         {

I think it's because of the below missing configuration values in your code.  Include them in the "config" block for the topics.
These are the default confluent cloud configurations for topics. If you don't include them while creating the topic - you'll see the above behavior.  I
"delete.retention.ms"                   = "86400000"
    "max.compaction.lag.ms"                 = "9223372036854775807"
    "message.timestamp.difference.max.ms"   = "9223372036854775807"
    "message.timestamp.type"                = "CreateTime"
    "min.compaction.lag.ms"                 = "0"
    "retention.bytes"                       = "-1"
    "segment.bytes"                         = "104857600"
    "segment.ms"                            = "604800000"

@bluedog13 it even add up unchanges lines to be like this :
# confluent_kafka_topic.dev_topics["topic-a"] will be updated in-place
  ~ resource "confluent_kafka_topic" "dev_topics" {
      ~ config           = {
          + "delete.retention.ms"                 = "86400000"
          + "max.compaction.lag.ms"               = "9223372036854775807"
          + "message.timestamp.difference.max.ms" = "9223372036854775807"
          + "min.compaction.lag.ms"               = "0"
          + "retention.bytes"                     = "-1"
          ~ "segment.bytes"                       = "536870912" -> "104857600"
          + "segment.ms"                          = "604800000"
            # (4 unchanged elements hidden)
        }
        id               = "lkc-xxxx/topic-a"
        # (3 unchanged attributes hidden)

        # (2 unchanged blocks hidden)
    }
    ```

@linouk23 I tried to keep the config.value before and after "re-apply". And compare them using diff command. Here what I got

Thanks for waiting!
Could you try to override max.message.bytes to a default value of 2097164 when creating a topic (or override it for an existing topic) to make this topic setting DYNAMIC_TOPIC_CONFIG.

@linouk23 I tried to keep the config.value before and after "re-apply". And compare them using diff command. Here what I got

Thanks for waiting!
Could you try to override max.message.bytes to a default value of 2097164 when creating a topic (or override it for an existing topic) to make this topic setting DYNAMIC_TOPIC_CONFIG.

It's actually what I set right now. Got max.message.bytes equal to2097164

Sounds great! Does terraform plan command show any difference still?
If yes,

Could you rerun https://pkc-xxxx.us-east1.gcp.confluent.cloud/kafka/v3/clusters/lkc-xxxx/topics/topic-a/configs and copy the settings for conflicting values.
Copy config block of a confluent_kafka_topic.
Copy config block from terraform.tfstate file.

Plan output :
# confluent_kafka_topic.dev_topics["topic-a"] will be updated in-place
  ~ resource "confluent_kafka_topic" "dev_topics" {
      ~ config           = {
          + "delete.retention.ms"                 = "86400000"
          + "max.compaction.lag.ms"               = "9223372036854775807"
          + "max.message.bytes"                   = "2097164"
          + "message.timestamp.difference.max.ms" = "9223372036854775807"
          + "min.compaction.lag.ms"               = "0"
          + "retention.bytes"                     = "-1"
          + "retention.ms"                        = "604800000"
          + "segment.ms"                          = "604800000"
            # (3 unchanged elements hidden)
        }
        id               = "lkc-xxxx/topic-a"
        # (3 unchanged attributes hidden)

        # (2 unchanged blocks hidden)
    }

TF  code :
terraform {
  required_version = "~> 1.2.0"

  required_providers {
    confluent = {
      source  = "confluentinc/confluent"
      version = "1.4.0"
    }
  }
}

locals {
  retention = {
    _7days  = 604800000
    _15days =<PHONE_NUMBER>
  }
  kafka_topics = {
    "topic-a" = {
      partitions_count    = 8
      min_insync_replicas = 2
      retention_ms        = local.retention._7days
    }
    "topic-b" = {
      partitions_count    = 16
      min_insync_replicas = 2
      retention_ms        = local.retention._7days
    }
    "topic-c" = {
      partitions_count    = 8
      min_insync_replicas = 2
      retention_ms        = local.retention._15days
    }
  }
}

resource "confluent_kafka_topic" "dev_topics" {
  kafka_cluster {
    id = confluent_kafka_cluster.kafka-cluster-dev.id
  }
  for_each         = local.kafka_topics
  topic_name       = each.key
  partitions_count = each.value.partitions_count
  config = {
    "delete.retention.ms"                 = "86400000"
    "max.compaction.lag.ms"               = "9223372036854775807"
    "max.message.bytes"                   = "2097164"
    "message.timestamp.difference.max.ms" = "9223372036854775807"
    "message.timestamp.type"              = "CreateTime"
    "min.compaction.lag.ms"               = "0"
    "min.insync.replicas"                 = each.value.min_insync_replicas
    "retention.bytes"                     = "-1"
    "retention.ms"                        = each.value.retention_ms
    "segment.bytes"                       = "536870912"
    "segment.ms"                          = "604800000"
  }
  rest_endpoint = confluent_kafka_cluster.kafka-cluster-dev.rest_endpoint
  credentials {
    key    = confluent_api_key.dev_rw_api_key.id
    secret = confluent_api_key.dev_rw_api_key.secret
  }
}

API call to config definition : example conflicting value default.retention.ms
{
      "kind": "KafkaTopicConfig",
      "metadata": {
        "self": "https://pkc-xxxx.us-east1.gcp.confluent.cloud/kafka/v3/clusters/lkc-xxxx/topics/topic-a/configs/delete.retention.ms",
        "resource_name": "crn:///kafka=lkc-xxxx/topic=topic-a/config=delete.retention.ms"
      },
      "cluster_id": "lkc-xxxx",
      "name": "delete.retention.ms",
      "value": "86400000",
      "is_read_only": false,
      "is_sensitive": false,
      "source": "DEFAULT_CONFIG",
      "synonyms": [
        {
          "name": "log.cleaner.delete.retention.ms",
          "value": "86400000",
          "source": "DEFAULT_CONFIG"
        }
      ],
      "topic_name": "topic-a",
      "is_default": true
    }

Relevant tfstate block
{
          "index_key": "topic-a",
          "schema_version": 2,
          "attributes": {
            "config": {
              "delete.retention.ms": "86400000",
              "max.compaction.lag.ms": "9223372036854775807",
              "max.message.bytes": "2097164",
              "message.timestamp.difference.max.ms": "9223372036854775807",
              "message.timestamp.type": "CreateTime",
              "min.compaction.lag.ms": "0",
              "min.insync.replicas": "2",
              "retention.bytes": "-1",
              "retention.ms": "604800000",
              "segment.bytes": "536870912",
              "segment.ms": "604800000"
            },
            "credentials": [
              {
                "key": "redacted",
                "secret": "redacted"
              }
            ],
            "id": "lkc-xxxx/topic-a",
            "kafka_cluster": [
              {
                "id": "lkc-xxxx"
              }
            ],
            "partitions_count": 4,
            "rest_endpoint": "https://pkc-xxxx.us-east1.gcp.confluent.cloud:443",
            "topic_name": "topic-a"
          },
          "sensitive_attributes": [
            [
              {
                "type": "get_attr",
                "value": "credentials"
              },
              {
                "type": "index",
                "value": {
                  "value": 0,
                  "type": "number"
                }
              },
              {
                "type": "get_attr",
                "value": "secret"
              }
            ]
          ],
          "private": "redacted",
          "dependencies": [
            "confluent_api_key.dev_rw_api_key",
            "confluent_kafka_cluster.kafka-cluster-dev"
          ]
        },

Thanks for attaching all these snippets! I've got a quick question: is that accurate that first you run terraform apply to create these 3 topics, then waited for like 20 minutes and then rerun terraform plan to see this diff? cc @robertusnegoro
If that's correct, seeing DEFAULT_CONFIG for delete.retention.ms is definitely a little bit unexpected.

I think less than 10 minutes after terraform apply, then I will get the diff.

@robertusnegoro could you send your Kafka Cluster ID (lkc-xyz123) to<EMAIL_ADDRESS>I might know where the issue is but might need to double check.

@robertusnegoro also if possible please share the output of that TF diff that appeared like after 10 minutes from the initial apply (or the list of target topic settings that you could see TF diff for with before and after values).

So the permanent diff is actually caused by Confluent Replicator. I just realize that Replicator trying to sync the topic configuration too.
I end up to test both cluster with exact same retention.ms which previously left default on the source cluster.
And the terraform plan outuput is clean now.
Sorry for the misleading circumstances. I will close the issue now


remove useless tests_require

The dependency of tests_require is for python 2.4/2.5/2.6 and no more supported.

Thanks!


chore: Add testing framework.

My thoughts about #59. Note that since ts-jest and babel-jest@24 do not play well together @babel/preset-typescript is used as a workaround.

getting a bunch of warning on install about missing peer dependency "<EMAIL_ADDRESS>

Fixed, added @babel/core as dev-dependency 🙂


[Trustification][SPOG][UI]Home page Search fields loads all the data for the first time

On Trustification home page, when the user tries to search for an SBOM or advisory - the application loads all the data instead of filtering the given input.
This happens only for the first time and when the user navigates back to the home page from the search result and perform the same search, the results are loaded as expected.
Steps to reproduce:

Open a private/incognito window or clear cache
Navigate to trustification application
On Home screen, enter "amq" on the "Search for an SBOM or advisory" text box
Click on "Search" button
Application will navigate to "Search Result" page with all the SBOM and advisory information

Attached image for reference, where the API call is made for empty query and amq subsequently to retrieve all the information.

Image version - v0.1.0-nightly.2f94c33f-dirty
Environment - https://trustification.dev/
JIRA# https://issues.redhat.com/browse/TC-378

I've tried to reproduce this issue but I've not been able to so far.
Following the instructions listed above below is a screen shot of what I see:

This looks like what I'd expect with the result entries all look related to amq. Is there something I'm missing or could this perhaps we been fixed already?

@danbev Interesting, I could reproduce this error on SBOM tab.
But on the advisories tab this is inconsistent. On 3 out of 5 tries, I could reproduce the issue on Advisory tab.
At the screenshot you have attached the SBOM count pointed to 207, where as there are only 6 SBOMs matching for the filtering condition.
I have added comments and screen recording on the JIRA - https://issues.redhat.com/browse/TC-378

@mrrajan Sorry, I was looking at the list of results and not at the counts. Thanks for the screen recording, I'll take another look at this now.


SBC 2.x Known Quirks

as per Neraidaphobia #9014 (many thanks for that!):

THE MOST COMMON ISSUE IS BAD LINE BREAKS DUE TO PDF FORMATING LIMITATIONS.  First transfer to a word processer to remove extra breaks, this fixes 75% of problems.
A line should never end on a comma.  It is either the sign of a line break or stray punctuation.
Hard break is required at the end of the entire statblock if it does not end on a "gear," or a non imported section (ecology, special abilities etc.)
PRCs prevent imports at the moment.  Replace them in the stat block with base classes with the same HD dice size for import, and then change them manually after.
Hard breaks in the middle of some lines will prevent imports. (Spells/Spell-likes, resistances/immunities, various other stat locations) Copying to a word processor makes it easier to spot missed breaks.
Bloodline/Domain spell-like abilites almost never import, and must be added in manually.
Sometimes an import is prevented when a creature only has a fly speed.  Adding a "0 ft.," (0 speed) in front of it can sometimes fix it.
Other then flying manueverability, often things in parethesis in the speed section, such as limitations on burrow can break imports.
In the attacks section, everything before the "or" or after must be one continous line without any breaks.
"Touch" based attacks that have "Touch" after the attack bonus, such as in "Incorporeal Touch +25 Touch" will import as a "+25 touch", as in an attack with +25 enhancement bonus called touch.  Remove the second touch, and manually set it to spell attack melee/ranged.
Spell-Like usage per day will not import and must be manually edited, exception: At-will is working properly.
Spells are imported at thier highest available level, and must be adjusted after import to class.
There should be no breaks at all in the feat section and in the gear section in order for it all to parse properly into the stat block.
Remove all D (Domain), B(Bonus), M(Mythic), book locations (OH, APG etc) and any other punctuation other than commas from the end of everything, or else they will not link properly to the compendium entry.
Cleric of XYZ 3 should be changed to Cleric (XYZ) 3 in order to mantain the cleric class tag for some dependancies. This applies to inquistitor as well.
Alchemist, Mesmerist, Psychic, and many other caster classes will not import their spell/extract list.  Change the class to "Wizard spells prepared" will ensure the will import.  Then fix them manually
The size catagory must be capitalized.
Abnormal characters, such as the "1/2" or "1/3" characters can break the import.
Check for stray punctuation if none of these work.  Even in some printed PDFs typos exist and can break an import.
Apostrophes do not play nice with the SBC, best to remove them and add them back in later.
Altering the SBC Buff does nothing, it must be copied first, and the original deleted and then the copy edited to make changed.
At current version, Class HD is not being calculated, and is being left blank in the HP section under class, and must be manually added.
Sometimes, but not often, the "Tactic" will break an import if it has too many line breaks in it.  Suspected keywords at the start of lines may be the issue, but it is another potential problem point.  Normally formating does not matter in that section.
Sometimes cutting out the whole "Spell like ability section" will fix an import that doesnt work.  Just add it in manually later.
Longer statblocks take longer to parse.
When you get an error can sometimes tell you what kind of error it is.  If it starts processing for a while, and then stops, its probably an issue in the spells or spell like abilities section.
When stuck, try taking out all additional information in parathesis except for attacks damage, creature subtypes,caster level information, hitpoint calculations and AC breakdown, and add them back in later.

Hp calculation needs to be seperated for multiclassing, even if the HD is the same, so a fighter 1/gunslinger 1 needs to have the hd as 1d10+1d10, not 2d10.  This includes Racial HD as well.

Any class names, or keywords in the name will create errors sometimes, so remove them and put them back in after the import.

Archetypes will almost always break the import, so remove them from the class line.

Currently there are some issues with importing spell lists for spontaneous casters.  for the present it is better to delete the spells prior to import, and then manually put them in after the import.  The Quick Insert mod makes this a much easier process.

Currently there are some issues with importing spell lists for spontaneous casters.  for the present it is better to delete the spells prior to import, and then manually put them in after the import.  The Quick Insert mod makes this a much easier process.

I'll start a new issue to collate "quirks" of 3.x


[Workspace Feeds] Card name field on confirmation page

Explanation of Change

[Workspace Feeds] Card name field on confirmation page
Fixed Issues

$ https://github.com/Expensify/App/issues/51908
PROPOSAL: N/A
Tests

[x] Verify that no errors appear in the JS console

❗❗❗ Important notes:

Testing is available only on the staging server for now.
The card name saving works only if the card is assigned to the current user. So it won't work if you assign the card to another member, it's going to be fixed in the future, discussion: slack link

Login to the account that has workspace with the Company Cards feature enabled and a workspace feed added.
Go to the Workspace -> Company card section.
Start the Card assignment flow and reach the confirmation screen.
Make sure the Card name is displayed on the confirmation screen and looks like ${assignee name/login}'s card
Try to update the card name and make sure it works.
Confirm the card assignment.
Make sure the card name is displayed in the list and on the details page.

Offline tests

N/A
QA Steps

[x] Verify that no errors appear in the JS console

Same, as in the Tests section.
PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/user-attachments/assets/9fd48c7c-ed6a-4f60-9dda-d2bbd8d7994e

Android: mWeb Chrome

https://github.com/user-attachments/assets/018bcf24-103c-4d21-9360-7e60bef2a642

iOS: Native

https://github.com/user-attachments/assets/3bd55178-a076-4003-bd2b-409805f543d2

iOS: mWeb Safari

https://github.com/user-attachments/assets/47409211-630a-4a9c-8cc2-42e746c5f672

MacOS: Chrome / Safari

https://github.com/user-attachments/assets/d007442f-a40e-477b-91fe-84f864ba21c8

MacOS: Desktop

https://github.com/user-attachments/assets/0f383544-6c91-42af-b73a-411ff1255ce8

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

Field on confirmation page

Editing field

field character limit

saving name change

fallback default name with primary login if no first name set


PUT, POST and DELTE to named maps should invalidate varnish

right now when a named map is updated the instances of the maps are not invalidated
cc @zenitraM

I duplicated this ticket on #247.
Do we want to invalidate on POST?

I think PUT and DELETE are the ones, right?

:-) https://github.com/CartoDB/Windshaft-cartodb/blob/247-add-named-maps-surrogate-keys/lib/cartodb/cartodb_windshaft.js#L72

This was implemented in https://github.com/CartoDB/Windshaft-cartodb/pull/249


fix(types): generate declaration files instead of importing from src

What: I'm touching the types folder in order to be able to use TypeScript project references which requires to generate my own .d.ts files in my project. As cli-testing-library is relying on src in its own .d.ts files, it makes TypeScript type checks the sources from my project, even with "skipLibCheck": true.

Why: With these changes, the sources of cli-testing-library won't be type-checked anymore by my project and I will be able to generate my own .d.ts files.

How: This is what I did:

I temporarily put "noEmit": false in tsconfig.json and used tsc to generate the .d.ts files: npx tsc --declaration --emitDeclarationOnly --outDir dts
I copied the relevant files from the generated dts to the types folder, mainly dts/user-events/**/*.d.ts and dts/event-map.d.ts
I rewrote the references to src to the new .d.ts files
Now it works ✅

Checklist:

[x] Tests
[x] TypeScript definitions updated
[x] Ready to be merged

Note that the relevant commit is this one.
For the second one, I just applied npm run format and fixed the warnings detected by npm run lint. 👍
I think the best long-term solution would be to rewrite the whole project from scratch in TypeScript. But I saw that it's forked from dom-testing-library so that's not something easy if you want to keep following upstream. 😅

This looks like a good set of changes, but I do worry about keeping the source files in sync with non-source files.

I think the best long-term solution would be to rewrite the whole project from scratch in TypeScript. But I saw that it's forked from dom-testing-library so that's not something easy if you want to keep following upstream. 😅

You know truth be told, I think we're at the point where dom-testing-library is less "upstream" and is more "inspiration with flavor" (the flavor being copied code :P ). We're already doing so much custom work on top of their original base. I think we should move forward with the idea of rewriting into TS.


Merge 1.x changes

att

Codecov Report

Merging #249 (a5f25e0) into master (13f1bd3) will increase coverage by 0.01%.
The diff coverage is 98.55%.

@@            Coverage Diff             @@
##           master     #249      +/-   ##
==========================================
+ Coverage   97.30%   97.32%   +0.01%
==========================================
  Files          42       43       +1
  Lines        3114     3135      +21
==========================================
+ Hits         3030     3051      +21
  Misses         84       84

Impacted Files
Coverage Δ

src/drivers/mysql/schema.js
96.96% <ø> (ø)

src/drivers/postgres/attribute.js
100.00% <ø> (ø)

src/data_types.js
98.73% <95.00%> (-0.61%)
:arrow_down:

src/bone.js
97.29% <100.00%> (+0.03%)
:arrow_up:

src/drivers/abstract/spellbook.js
96.61% <100.00%> (+0.02%)
:arrow_up:

src/drivers/postgres/schema.js
100.00% <100.00%> (ø)

src/drivers/sqlite/data_types.js
100.00% <100.00%> (ø)

src/drivers/sqlite/schema.js
98.98% <100.00%> (+1.07%)
:arrow_up:

src/query_object.js
98.50% <100.00%> (+0.02%)
:arrow_up:

src/raw.js
100.00% <100.00%> (ø)

... and 3 more

Continue to review full report at Codecov.

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


Nuxt3 SSR Hydration mismatch

Current Behavior:
When i follow the doc for a Nuxt3 installation and copy paste the media-player into my component i got an SSR mismatch error, also the video are displaying while loading ( SSR ) but as soon as i got the Hydration mismatch ( after component mounted) the video are not available to play or not displaying
Expected Behavior:
No SSR mismatch -- poster show during load --> video display after can play == true
Steps To Reproduce:
Fresh nuxt3 install, fresh vidstack install , following the doc

Reproduction Link: How to create a repro?
Environment:

Anything Else?

Everything is working as expected in my testing. The hydration warning is annoying but I can't fix that at the moment. You can remove the warning by adding the following:
<media-player v-warning="false">

Everything is working as expected in my testing but the hydration warnings are annoying. We can't fix this at the moment but we might create official Vue wrapper for our library that should resolve this. Looking into it for 1.0.
ℹ  For now you can consider rendering the player client-side only using the <ClientOnly> Nuxt component.

Bind to props and make sure internals are wrapped with ClientOnly. Reference for anyone in the future to avoid this issue:
<script setup>
import "vidstack/bundle";

const title = ref("Sprite Fight"),
  src = ref("https://files.vidstack.io/sprite-fight/720p.mp4");
</script>

<template>
  <media-player .title="title" .src="src">
    <ClientOnly>
      <media-provider>
        <media-poster
          class="vds-poster"
          src="https://files.vidstack.io/sprite-fight/poster.webp"
        ></media-poster>
      </media-provider>
      <media-video-layout
        thumbnails="https://files.vidstack.io/sprite-fight/thumbnails.vtt"
      ></media-video-layout>
    </ClientOnly>
  </media-player>
</template>


[ramp] ramp behavior is different when number of stops < 256

Hi :)
in ramp.ts, the timeIndex function uses binary search to find the time index when number stops > 256 (https://github.com/thi-ng/umbrella/blob/34ac95538d96f046090fef5fd3a1dc36d54663d5/packages/ramp/src/ramp.ts#L163)
If the exact time can't be found, binary search returns a negative index (https://github.com/thi-ng/umbrella/blob/34ac95538d96f046090fef5fd3a1dc36d54663d5/packages/arrays/src/binary-search.ts#L58), which then causes the at() function to return the first stop value:
     return i < 0 ? first[1] : i >= n ? last[1] : impl.at(stops, i, t);

I would expect it to return impl.at(stops, -i, t) in this case ... where am I wrong?

Just released the fix as v3.3.12 - thank you again!

Thanks to you! I should have provided a PR in the first place, I wasn't 100% sure I was right

Ah, don't worry! The fix was actually slightly different, and I also added some tests to make sure:
https://github.com/thi-ng/umbrella/blob/39a504b5e15f38580e53057e3127e8170f2b994e/packages/ramp/src/ramp.ts#L169


TUTORIAL: Update documentation of "fields"

TUTORIAL: Document suggested common field names

This should help standardize templates a bit.

Signed-off-by: Rafał Miłecki<EMAIL_ADDRESS>
TUTORIAL: Move regex info to the "Parser regex" section

It's where it's really useful. In "fields" other parsers can be used.
Some of them not requiring regex at all.

Signed-off-by: Rafał Miłecki<EMAIL_ADDRESS>
I was trying to start discussion on naming fields in the #309 and just recently a feature request has been opened: #311.
This Pull Request updates documentation adding some standard fields names that should be used for common invoice data.
Please feel free to discuss & comment this idea as well as chosen names.

Preview of updated TUTORIAL.rst

In #311 we shortly discussed following some names documented in UBL.
This Pull Requests adds:

email: does it make sense to replace it with electronic_mail (to match ElectronicMail)?
phone: is there any UBL name for that?
vat: does it make sense to replace it with company_id (to match PartyTaxScheme / CompanyID)?
amount_untaxed: does it make sense to make it tax_exclusive_amount (to match TaxExclusiveAmount)?
lines: does it make sense to make it invoice_lines (to match multiple InvoiceLine)?

I like having things standardized but somehow I'm not convinced about above field names (like electronic_mail or company_id).

I do ask myself if we'd like to follow this mixed way of writing or go all lowercase with _ before a group of capital letters or single capital letters. Anything that speaks for/against using the original UBL entity name besides personal preferences? I do agree that this looks a bit akward and yes the terms do not really feel like fitting everyday life.
Maybe it is an idea to have some mapping and processing at hand, so old template names could be rewritten for xml export? Not sure if thats actually needed by anyone. My basic idea was only to have existing standards implemented, but I do see that maybe UBL is not the way to go?
Considering the terms:

From what I have seen it looks like telephone is ubl for the phone.
considering the company_id it does make sense from my pov as the tax number should be universal identifier for most countries and companys. As long as it is not flagged als "necessary" field, it shouldnt cause any problems in usage.
tax_exclusive_amount should be understandible from my pov
using invoice_lines against invoice_line might create unnecessary confusion

Currently we follow Python syntax (snake case) for field names. UBL names (camel case) should be "translated" before using. This is also done when going e.g. from JS to Python.
I'd always use UBL for new field names. For existing fields, it's probably not worth breaking backwards compat and existing templates users may have locally. Also because this project's relation to UBL isn't very strong.

I converted all our doc files to Markdown. Much easier to edit.

I will start this weekend. current pandemic has kept me busy in doing all those cheap jobs to stay fluid.

I've updated this pull request.
Preview: https://github.com/rmilecki/invoice2data/blob/tutorial-fields/TUTORIAL.md#fields
Suggested documented fields names:

company_id - based on UBL's cbc:CompanyID
electronic_mail - based on UBL's cbc:ElectronicMail
telephone - based on UBL's cbc:Telephone
tax_exclusive_amount - based on UBL's cbc:TaxExclusiveAmount
sale_date - custom name
tax_exclusive_amount - based on UBL's cbc:TaxExclusiveAmount
bic - custom name as UBL's cbc:ID doesn't fit
due_date - based on UBL's cbc:DueDate
bic - custom name as UBL's cbc:ID doesn't fit
payment_means_name - based on UBL's @name

@m3nu, @Seriousness: can you review this pull request, please?

sorry forgot.
I'd add:
tax_inclusive_amount - based on cbc:TaxInclusiveAmount
tax_total - based on cbc:tax_total - document level
per item+document level:
tax_percent - based on cbc:Percent
I am not sure if this is internationally common, in Germany the VAT normally applies for the date the service has been provided/finished. If we agree on that it could be
tax_date - based on  cbc:TaxPointDate

Could you include a section of other programs using this library?
As it would be usefull to know which fields are used so current implementations are'nt getting broken.
For example this library is used in the invoice2data module of odoo.
https://github.com/OCA/edi/tree/14.0/account_invoice_import_invoice2data
That module looks at the following fields:
vat: for matching the invoice to the vendor. (if the VAT number of the supplier is not in the text of PDF file, add it as a static in the template or add a 'partner_name' key)
'partner_name' can be optionally used for matching of supplier
partner_email can be optionally used for matching of supplier
partner_website can be optionally used for matching of supplier
sirenfrench vat number
invoice_number as a reference of the invoice
currency
amount ('amount' is the total amount with taxes)
amount_untaxed or amount_tax (one or the other, no need for both)
date: the date of the invoice
invoice_number
date_due, if this information is available in the text of the PDF file.
date_start , if this information is available in the text of the PDF file.
date_end, if this information is available in the text of the PDF file.
In the lines section
name or description, currently support is in development to use this to match a product
price_unit
product,currently support is in development
qty
On a different note, to make a invoice fully compliant to one of the ubl standards a lot more info needs to be used / mapped.
For those interested have a look in the oca repositories. For example in community data-files there is al lot of information on ubl invoicing.

Closing this one, even if the discussion is still valid.
It should not be documented in the main readme.md.
We moved the documentation to readthedocs.
Where it is much easier to document extensive/ advanced functions.


allow pasting in keys with whitespace in them

Strip all whitespace from keys as many things export keys in pattern of "xxxx xxxx xxxx..." and base32 doesn't include whitespace.

Thanks. I pushed a fix for this.  Sorry about that.


fix: Removed telemetry parameter from RSV test - avm/res/recovery-services/vault

Description
Removed redundant telemetry parameter from test files for RSV
Pipeline Reference

Pipeline

Type of Change

[ ] Update to CI Environment or utlities (Non-module effecting changes)
[ ] Azure Verified Module updates:

[x] Bugfix containing backwards compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:

[ ] Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
[ ] The bug was found by the module author, and no one has opened an issue to report it yet.

[ ] Feature update backwards compatible feature updates, and I have bumped the MINOR version in version.json.
[ ] Breaking changes and I have bumped the MAJOR version in version.json.
[ ] Update to documentation

Hey @alexanderojala, please take a look when you have a chance :)


If no Network Connection to InfluxDB it reboots

Thanks for the code. My Device worked many weeks.
Now we had a Internet disconnect and i no longer got Data from my Device.
I found out, that if you have no Internet or the Server is not reachable it reboots.
I want to send my device as a Christmas Present to someone else. I dont know the Wireless Credentials.  So I will never have the Chance to enter the Credentials.
Can you set a timeout or something or check the connection in first place?
[W][ota:107]: Last Boot was an unhandled reset, will proceed to safe mode in 1 restarts
[C][influxdb:010]: Setting up InfluxDB Writer...
E (24814) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (24814) task_wdt:  - loopTask (CPU 1)
E (24814) task_wdt: Tasks currently running:
E (24814) task_wdt: CPU 0: IDLE
E (24814) task_wdt: CPU 1: IDLE
E (24814) task_wdt: Aborting.
abort() was called at PC 0x4010430c on core 0
Backtrace:0x40084185:0x3ffbeabc |<-CORRUPTED
ELF file SHA256:<PHONE_NUMBER>000000
Rebooting...

I have the same issue, although the server should be reachable.
[18:10:40][C][influxdb:010]: Setting up InfluxDB Writer...
[18:10:45]E (24094) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
[18:10:45]E (24094) task_wdt:  - loopTask (CPU 1)
[18:10:45]E (24094) task_wdt: Tasks currently running:
[18:10:45]E (24094) task_wdt: CPU 0: IDLE
[18:10:45]E (24094) task_wdt: CPU 1: IDLE
[18:10:45]E (24094) task_wdt: Aborting.
[18:10:45]
[18:10:45]abort() was called at PC 0x400ff674 on core 0
[18:10:45]
[18:10:45]
[18:10:45]Backtrace:0x400838cd:0x3ffbe9dc |<-CORRUPTED
[18:10:45]
[18:10:45]
[18:10:45]
[18:10:45]
[18:10:45]ELF file SHA256:<PHONE_NUMBER>000000
[18:10:45]
[18:10:45]Rebooting...


Button component

Includes a specialized button for Timestamps.

Should all be fixed now, but not entirely sure if I handled children in the best way.


[5.0.0] pnpm error - Peer dependencies that should be installed

@ricardogobbosouza
I'm using nuxt 2 with nuxt bridge, which can't use webpack 5.
Also in my case I can't use vite, because vuetify 2 doesn't support it without complex workarounds.
With 5.0.0 I get the following error in pnpm:
└─┬ @nuxtjs/stylelint-module 5.0.0
  ├─┬ vite-plugin-stylelint 4.2.0
  │ └── ✕ missing peer<EMAIL_ADDRESS>|| ^3.0.0 || ^4.0.0"
  └─┬ stylelint-webpack-plugin 4.1.0
    └── ✕ unmet peer<EMAIL_ADDRESS>found 4.46.0
Peer dependencies that should be installed:
<EMAIL_ADDRESS>|| ^3.0.0 || ^4.0.0"

Originally posted by @MartinX3 in https://github.com/nuxt-community/stylelint-module/issues/74#issuecomment-1460639127

Ho @MartinX3
Can share you configuration?

@ricardogobbosouza yes of course
{
"version": "1.0.0",
"private": true,
"packageManager"<EMAIL_ADDRESS>"scripts": {
"build": "nuxi generate",
"dev": "nuxi dev",
"lint": "pnpm lint:markup && pnpm lint:js && pnpm lint:style && pnpm lint:prettier",
"lint:js": "eslint --ext ".js,.ts,.vue" --ignore-path .gitignore --fix .",
"lint:markup": "vue-tsc",
"lint:prettier": "prettier --write --list-different .",
"lint:style": "stylelint "/.{css,scss,sass,html,vue}" --ignore-path .gitignore --fix",
"predev": "pnpm lint",
"preinstall": "npx only-allow pnpm",
"prepare": "husky install && nuxi prepare"
},
"dependencies": {
"@pinia/nuxt": "~0.4.7",
"@yeger/vue2-masonry-wall": "~2.3.3",
"date-holidays": "~3.18.0",
"nuxt": "~2.16.2",
"pinia": "~2.0.33",
"uuid": "~9.0.0",
"vue": "~2.7.14",
"vuetify": "~2.6.14"
},
"devDependencies": {
"@babel/core": "~7.21.0",
"@commitlint/cli": "~17.4.4",
"@commitlint/config-conventional": "~17.4.4",
"@mdi/js": "~7.1.96",
"@nuxt/bridge": "npm<EMAIL_ADDRESS>"@nuxt/types": "~2.16.0",
"@nuxtjs/eslint-config-typescript": "~12.0.0",
"@nuxtjs/eslint-module": "~4.0.1",
"@nuxtjs/router": "~1.7.0",
"@nuxtjs/vuetify": "~1.12.3",
"@rushstack/eslint-patch": "~1.2.0",
"@types/mime-types": "~2.1.1",
"@types/node": "~18.15.0",
"@types/uuid": "~9.0.1",
"@vue/eslint-config-prettier": "~7.1.0",
"@vue/eslint-config-typescript": "~11.0.2",
"buffer": "~6.0.3",
"consola": "~2.15.3",
"eslint": "~8.35.0",
"eslint-plugin-nuxt": "~4.0.0",
"eslint-plugin-vue": "~9.9.0",
"eslint-plugin-vuetify": "~1.1.0",
"husky": "~8.0.3",
"lint-staged": "~13.1.2",
"postcss-html": "~1.5.0",
"prettier": "~2.8.4",
"stylelint": "~15.2.0",
"stylelint-config-recommended-vue": "~1.4.0",
"stylelint-config-standard": "~30.0.1",
"typescript": "~4.9.5",
"vue-tsc": "~1.2.0",
"webpack": "~4.46.0"
},
"gitHooks": {
"pre-commit": "lint-staged"
},
"lint-staged": {
".vue": "bash -c vue-tsc",
".{js,ts,vue}": "eslint --fix",
".{css,scss,sass,html,vue}": "stylelint --fix",
"*.": "prettier --ignore-unknown --write"
}
}

@MartinX3
In your case try version [v4.2.1(https://github.com/nuxt-community/stylelint-module/tree/v4.2.1)

@ricardogobbosouza with 4.2.1 I get the pnpm error
+ @nuxtjs/stylelint-module 4.2.1 (5.0.1 is available)

 WARN  Issues with peer dependencies found
.
└─┬ @nuxtjs/eslint-module 4.0.2
  ├─┬ vite-plugin-eslint 1.8.1
  │ └── ✕ missing peer vite@>=2
  └─┬ eslint-webpack-plugin 4.0.0
    └── ✕ unmet peer<EMAIL_ADDRESS>found 4.46.0
Peer dependencies that should be installed:
  vite@>=2

nuxt 2 uses webpack 4.
nuxt 2 bridge also, since vite is optional there.

These are warnings and not errors.
When using webpack 4 you must use the nuxt2 branch

Ah thank you
I thought I should use v5 with nuxt bridge because of the changelog.
Especially since I also don't get an error at buildtime as well there.


Fixes RadarChart axes (#796)

I ran into the same issue (#796).  The RadarChart axes does not show or is displayed incorrectly (ex. wrong number of ticks) depending on what the startingAngle is.  Rotating your graph a certain degree can cause these problems, because JavaScript's trigonometric functions (ex. Math.sin & Math.cos) can return numbers with floating point errors (see table below). These floating point numbers can cause calculation errors.

Trig Function
Angle
JavaScript Value
True Value

sin
PI
1.2246467991473532e-16
0

cos
PI/3
0.5000000000000001
0.5

Shown below is what I used for my RadarChart.
class App extends Component {
  render() {
    const RADAR_PROPS = {
      data: [{
        C: 30,
        VisualBasics: 60,
        Excel: 40,
        Access: 40
      }],
      domains: [
        {name: 'C', domain: [0, 100]},
        {name: 'VisualBasics', domain: [0, 100]},
        {name: 'Excel', domain: [0, 100]},
        {name: 'Access', domain: [0, 100]}
      ],
      height: 300,
      width: 400,
    };
    return (
      <div>
        <RadarChart
          data={RADAR_PROPS.data}
          domains={RADAR_PROPS.domains}
          height={RADAR_PROPS.height}
          width={RADAR_PROPS.height}
          startingAngle={Math.PI/4}
          className='overflow-okay horizontally-centered'
          style={{
              labels: {
                  fontSize: 13
              },
              polygons: {
                  fillOpacity: 0.1,
                  strokeOpacity: 1,
                  strokeWidth: 0.5,
              },
          }}
        />
      </div>
    );
  }
}

For the src/utils/axis-utils.js, I wanted to make sure the axes displayed the correct number of ticks, because there could be cases where maybe more ticks would be generated than what was specified.  Let me know what you think.  Thanks.

thanks @NoobCIT !

I actually would like to see a follow up to this with some tests, there's some behavior in there that i'm not 100% sure about

@mcnuttandrew , yeah I'll look into it.


Specify sharding for jax.numpy.meshgrid

If there would be a way to simply specify sharding or devices for the output arrays of jax.numpy.meshgrid() (https://jax.readthedocs.io/en/latest/_autosummary/jax.numpy.meshgrid.html) so the output does not necessarily have the whole global array on each device, that would be awesome!
E.g.:
import jax
import jax.numpy as jnp
from jax.experimental import mesh_utils
from jax.sharding import Mesh, PartitionSpec, NamedSharding

n_devices = jax.device_count()
mesh = Mesh(mesh_utils.create_device_mesh((n_devices, 1)), ("x", "y"))
sharding = NamedSharding(mesh, PartitionSpec("x", "y"))

N = 10000
xlin = jnp.linspace(0.0, 100.0, N)
X, Y = jnp.meshgrid(xlin, xlin, device=sharding)   # currently there is no `device=` option

in the same fashion as how jax.numpy.ones() or jax.numpy.array() does it.

I don't think that meshgrid should have a device or sharding argument – ones and array have these because they are methods of creating an array from scratch. meshgrid on the other hand takes input arrays, processes them, and returns output arrays, so it seems reasonable that users would control input and output sharding the same way as with any function on arrays (some discussion in https://jax.readthedocs.io/en/latest/sharded-computation.html)
What do you think?

Got it! So something like?
sharded_meshgrid = jax.jit(jnp.meshgrid, out_shardings=sharding)

The paradigm not to specify sharding when a function takes arrays as input makes sense. In this function the input arrays are typically small and not distributed, while the outputs are huge and may need to be constructed in a distributed way to avoid running out of memory, so as long as that can be accomplished, it's all good!

Yeah that seems like the right approach when in an eager flow. Within jit you could use with_sharding_costraint for control, or you could annotate the input and output sharding for the overall function and let the compiler decide on the location for intermediate arrays.

Thanks! I'll close the issue