dependency conflics during packages instalation

Its not possible to install packages due dependency conflicts.
This happens after clean git clone and conda evn create.
`file@Filips-MacBook-Air timesfm % conda env create --file=environment_cpu.yml
Channels:

conda-forge
defaults
anaconda
Platform: osx-arm64
Collecting package metadata (repodata.json): done
Solving environment: done

Downloading and Extracting Packages:
Preparing transaction: done
Verifying transaction: done
Executing transaction: done
Installing pip dependencies: \ Ran pip subprocess with arguments:
['/Users/file/miniconda3/envs/tfm_env/bin/python', '-m', 'pip', 'install', '-U', '-r', '/Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt', '--exists-action=b']
Pip subprocess output:
Collecting utilsforecast (from -r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 2))
Using cached utilsforecast-0.1.12-py3-none-any.whl.metadata (7.5 kB)
Collecting praxis (from -r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached praxis-1.4.0-py3-none-any.whl.metadata (1.2 kB)
Collecting paxml (from -r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 4))
Using cached paxml-1.4.0-py3-none-any.whl.metadata (1.3 kB)
Collecting jax==0.4.26 (from jax[cpu]==0.4.26->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 5))
Using cached jax-0.4.26-py3-none-any.whl.metadata (23 kB)
Collecting einshape (from -r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 6))
Using cached einshape-1.0-py3-none-any.whl.metadata (706 bytes)
Collecting huggingface_hub[cli] (from -r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 1))
Using cached huggingface_hub-0.23.4-py3-none-any.whl.metadata (12 kB)
Collecting ml-dtypes>=0.2.0 (from jax==0.4.26->jax[cpu]==0.4.26->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 5))
Using cached ml_dtypes-0.4.0-cp310-cp310-macosx_10_9_universal2.whl.metadata (20 kB)
Collecting numpy>=1.22 (from jax==0.4.26->jax[cpu]==0.4.26->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 5))
Downloading numpy-2.0.0-cp310-cp310-macosx_14_0_arm64.whl.metadata (60 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 60.9/60.9 kB 1.1 MB/s eta 0:00:00
Collecting opt-einsum (from jax==0.4.26->jax[cpu]==0.4.26->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 5))
Using cached opt_einsum-3.3.0-py3-none-any.whl.metadata (6.5 kB)
Collecting scipy>=1.9 (from jax==0.4.26->jax[cpu]==0.4.26->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 5))
Downloading scipy-1.14.0-cp310-cp310-macosx_14_0_arm64.whl.metadata (60 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 60.8/60.8 kB 4.5 MB/s eta 0:00:00
Collecting jaxlib==0.4.26 (from jax[cpu]==0.4.26->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 5))
Downloading jaxlib-0.4.26-cp310-cp310-macosx_11_0_arm64.whl.metadata (1.8 kB)
Collecting filelock (from huggingface_hub[cli]->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 1))
Using cached filelock-3.15.4-py3-none-any.whl.metadata (2.9 kB)
Collecting fsspec>=2023.5.0 (from huggingface_hub[cli]->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 1))
Using cached fsspec-2024.6.1-py3-none-any.whl.metadata (11 kB)
Requirement already satisfied: packaging>=20.9 in /Users/file/miniconda3/envs/tfm_env/lib/python3.10/site-packages (from huggingface_hub[cli]->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 1)) (24.1)
Requirement already satisfied: pyyaml>=5.1 in /Users/file/miniconda3/envs/tfm_env/lib/python3.10/site-packages (from huggingface_hub[cli]->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 1)) (6.0.1)
Requirement already satisfied: requests in /Users/file/miniconda3/envs/tfm_env/lib/python3.10/site-packages (from huggingface_hub[cli]->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 1)) (2.32.3)
Collecting tqdm>=4.42.1 (from huggingface_hub[cli]->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 1))
Using cached tqdm-4.66.4-py3-none-any.whl.metadata (57 kB)
Requirement already satisfied: typing-extensions>=<IP_ADDRESS> in /Users/file/miniconda3/envs/tfm_env/lib/python3.10/site-packages (from huggingface_hub[cli]->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 1)) (4.12.2)
Collecting InquirerPy==0.3.4 (from huggingface_hub[cli]->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 1))
Using cached InquirerPy-0.3.4-py3-none-any.whl.metadata (8.1 kB)
Collecting pfzy<0.4.0,>=0.3.1 (from InquirerPy==0.3.4->huggingface_hub[cli]->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 1))
Using cached pfzy-0.3.4-py3-none-any.whl.metadata (4.9 kB)
Requirement already satisfied: prompt-toolkit<4.0.0,>=3.0.1 in /Users/file/miniconda3/envs/tfm_env/lib/python3.10/site-packages (from InquirerPy==0.3.4->huggingface_hub[cli]->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 1)) (3.0.47)
Collecting pandas>=1.1.1 (from utilsforecast->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 2))
Downloading pandas-2.2.2-cp310-cp310-macosx_11_0_arm64.whl.metadata (19 kB)
Collecting absl-py==1.4.0 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached absl_py-1.4.0-py3-none-any.whl.metadata (2.3 kB)
Collecting chex>=0.1.85 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached chex-0.1.86-py3-none-any.whl.metadata (17 kB)
Collecting clu==0.0.11 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached clu-0.0.11-py3-none-any.whl.metadata (1.9 kB)
Collecting einops==0.7.0 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached einops-0.7.0-py3-none-any.whl.metadata (13 kB)
Collecting etils==1.7.0 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached etils-1.7.0-py3-none-any.whl.metadata (6.4 kB)
Collecting fiddle==0.3.0 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached fiddle-0.3.0-py3-none-any.whl.metadata (2.3 kB)
Collecting flax==0.8.2 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached flax-0.8.2-py3-none-any.whl.metadata (10 kB)
Collecting jax-bitempered-loss==0.0.2 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached jax_bitempered_loss-0.0.2-py3-none-any.whl.metadata (4.0 kB)
Collecting jaxtyping==0.2.28 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached jaxtyping-0.2.28-py3-none-any.whl.metadata (6.4 kB)
INFO: pip is looking at multiple versions of praxis to determine which version is compatible with other requirements. This could take a while.
Collecting praxis (from -r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached praxis-1.3.1-py3-none-any.whl.metadata (1.1 kB)
Collecting absl-py (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached absl_py-2.1.0-py3-none-any.whl.metadata (2.3 kB)
Collecting einops (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached einops-0.8.0-py3-none-any.whl.metadata (12 kB)
Collecting fiddle==0.2.11 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached fiddle-0.2.11-py3-none-any.whl.metadata (2.2 kB)
Collecting flax==0.8.1 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached flax-0.8.1-py3-none-any.whl.metadata (10 kB)
Collecting praxis (from -r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached praxis-1.3.0-py3-none-any.whl.metadata (1.1 kB)
Collecting chex==0.1.85 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached chex-0.1.85-py3-none-any.whl.metadata (17 kB)
Collecting clu (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached clu-0.0.12-py3-none-any.whl.metadata (1.9 kB)
Collecting praxis (from -r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached praxis-1.2.0-py3-none-any.whl.metadata (1.0 kB)
Collecting flax (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached flax-0.8.5-py3-none-any.whl.metadata (10 kB)
Collecting praxis (from -r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached praxis-1.1.0-1-py3-none-any.whl.metadata (1.1 kB)
Collecting clu==0.0.9 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached clu-0.0.9-py3-none-any.whl.metadata (2.0 kB)
Collecting einops==0.6.1 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached einops-0.6.1-py3-none-any.whl.metadata (12 kB)
Collecting etils==1.4.1 (from etils[enp,epath,epy]==1.4.1->praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached etils-1.4.1-py3-none-any.whl.metadata (5.9 kB)
Collecting flax==0.7.2 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached flax-0.7.2-py3-none-any.whl.metadata (10.0 kB)
Collecting praxis (from -r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached praxis-1.0.0-2-py3-none-any.whl.metadata (951 bytes)
Collecting clu==0.0.8 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached clu-0.0.8-py3-none-any.whl.metadata (2.0 kB)
Collecting einops==0.6.0 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached einops-0.6.0-py3-none-any.whl.metadata (12 kB)
Collecting fiddle==0.2.6 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached fiddle-0.2.6-py3-none-any.whl.metadata (2.1 kB)
Collecting flax==0.6.8 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached flax-0.6.8-py3-none-any.whl.metadata (9.9 kB)
Collecting praxis (from -r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached praxis-0.4.0-py3-none-any.whl.metadata (776 bytes)
Using cached praxis-0.3.0-py3-none-any.whl.metadata (830 bytes)
INFO: pip is still looking at multiple versions of praxis to determine which version is compatible with other requirements. This could take a while.
Using cached praxis-0.2.1-py3-none-any.whl.metadata (840 bytes)
Collecting fiddle==0.2.5 (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached fiddle-0.2.5-py3-none-any.whl.metadata (2.0 kB)
Collecting praxis (from -r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached praxis-0.2.0-py3-none-any.whl.metadata (828 bytes)
Using cached praxis-0.1-1-py3-none-any.whl.metadata (823 bytes)
Collecting fiddle-config (from praxis->-r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3))
Using cached fiddle_config-0.2.2-py3-none-any.whl.metadata (2.0 kB)
The conflict is caused by:
praxis 1.4.0 depends on lingvo==0.12.7
The user requested jax==0.4.26
jax[cpu] 0.4.26 depends on jax 0.4.26 (from https://files.pythonhosted.org/packages/dc/d9/f387d9dfb2cf00f814b24e0f8bf6f4c68ae01870994dc436993fadd73563/jax-0.4.26-py3-none-any.whl (from https://pypi.org/simple/jax/) (requires-python:>=3.9))
praxis 1.3.1 depends on jax==0.4.24
The user requested jax==0.4.26
jax[cpu] 0.4.26 depends on jax 0.4.26 (from https://files.pythonhosted.org/packages/dc/d9/f387d9dfb2cf00f814b24e0f8bf6f4c68ae01870994dc436993fadd73563/jax-0.4.26-py3-none-any.whl (from https://pypi.org/simple/jax/) (requires-python:>=3.9))
praxis 1.3.0 depends on jax==0.4.24
The user requested jax==0.4.26
jax[cpu] 0.4.26 depends on jax 0.4.26 (from https://files.pythonhosted.org/packages/dc/d9/f387d9dfb2cf00f814b24e0f8bf6f4c68ae01870994dc436993fadd73563/jax-0.4.26-py3-none-any.whl (from https://pypi.org/simple/jax/) (requires-python:>=3.9))
praxis 1.2.0 depends on jax==0.4.18
The user requested jax==0.4.26
jax[cpu] 0.4.26 depends on jax 0.4.26 (from https://files.pythonhosted.org/packages/dc/d9/f387d9dfb2cf00f814b24e0f8bf6f4c68ae01870994dc436993fadd73563/jax-0.4.26-py3-none-any.whl (from https://pypi.org/simple/jax/) (requires-python:>=3.9))
praxis 1.1.0 depends on jax==0.4.14
The user requested jax==0.4.26
jax[cpu] 0.4.26 depends on jax 0.4.26 (from https://files.pythonhosted.org/packages/dc/d9/f387d9dfb2cf00f814b24e0f8bf6f4c68ae01870994dc436993fadd73563/jax-0.4.26-py3-none-any.whl (from https://pypi.org/simple/jax/) (requires-python:>=3.9))
praxis 1.0.0 depends on jax==0.4.7
praxis 0.4.0 depends on lingvo
praxis 0.3.0 depends on lingvo
praxis 0.2.1 depends on lingvo
praxis 0.2.0 depends on lingvo
praxis 0.1 depends on lingvo
To fix this you could try to:

loosen the range of package versions you've specified
remove package versions to allow pip attempt to solve the dependency conflict

Pip subprocess error:
ERROR: Cannot install -r /Users/file/Projects/timesfm/condaenv.tokgzgl8.requirements.txt (line 3), jax==0.4.26 and jax[cpu]==0.4.26 because these package versions have conflicting dependencies.
ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts
failed
CondaEnvException: Pip failed
`

Unfortunately as mentioned in the installation section the package does not work on ARM architecture due to the lingvo dependency.

i am not ARM ,it is X64， also error!

I also have the same problem

Two known causes:

ARM
Python < 3.10

Two known causes:

ARM
Python < 3.10

my env  above it，but  the error  have the same problem


Compensate for DPI Resolution and Remote Play Border

I have a 4k Laptop, and everything can run reallly tiny so I need to use DPI Scaling on my Windows 10 machine to enrich some experiences. This messes with the ScriptConfig.TargetSize as it won't be accurate when plugging in coordinates.
I feel that determining a multipler and adding to these lines would help.
https://github.com/komefai/PS4Macro/blob/cf7ce2c4e49301a8d9d225798b499b29b37e41de/PS4MacroAPI/Internal/BackgroundCapture.cs#L63-L64
Since my Display Scaling is set to 200%, a multipler of 2 on both of these helped me.
The border is also not considered, so when trying to crop, you are offset by the left and top borders around the Remote Play window. If we can determine these values, we can get a coordinate system that's all aligned to the same axes.

Hi, I had this problem as well when I switched to a 4K monitor a few months ago, but I totally forget to add this in the documentation.
At first, I tried your approach by multiplying a scaling factor to the dimensions, but this becomes a problem when you distribute your script to other people with different scaling configurations!
So, the best solution to this problem is to find a way to force PS4 Remote Play to not scale with the OS. There are 2 cases for this, one for the latest Windows 10 update and another for the earlier Windows 10 update (2017 and earlier). If you're running the LATEST update then you should have this icon in your taskbar!

Fix for latest Windows 10

Right-Click on the PS4 Remote Play shortcut and select Properties
Go to Compatibility tab
Select High DPI scaling override to System

NOTE: If you're running an earlier Windows 10 that doesn't have the Task View icon, then choose override as System (Enhanced) instead.
Let me know if this helps!


Use relations and scopes for ems and miq servers

extracted from #12427
The goal is to move from virtual attributes and methods to relations and scopes
This allows us to delegate across the relations and avoid downloading data when we simply want to count.
I did not check test coverage.
You can find general numbers in the related PR

LGTM @kbrock, remove the unneeded method above, fix the tests and we're good to go.

@jrafanie In attempts to move this forward, I removed the relationship for active_miq_servers. It caused a stale zone to come out of EvmSpecHelper.create_guid_miq_server_zone (which didn't make sense to me) - so I'll introduce later


Connection error

Could be my thing only but I keep on having a connection issue due to SSL/SSH (see attached error). ODBC and Snowflake account seem to be fine, any hints?

Thanks in advance!

@IraitzM Sorry for the delayed response. Is this still occuring?

Thanks for responding @ssegal100. Actually, it seems had something to do with the PC I was using 'cause using a different device it just worked. Probably the antivirus, will try to debug and find the error just in case it can be solved. Thanks anyways!

Thanks @IraitzM.


Fix case sensitive benchmark links in README

I was having a squiz at the repo and noticed the current links 404 so I thought I'd patch :)

Thanks!


[FLINK-13894][web]Web Ui add log url for subtask of vertex

What is the purpose of the change
This pull request adds log link for subtask in the page of job's vertex. Then it's easy for user seeing log.
Brief change log

The JobSubTaskInterface in job-subtask.ts add resource-id .
job-overview-drawer-subtasks.component.html add log logic.

Verifying this change
no
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (yes)
If yes, how is the feature documented? (not applicable)

As usual, please include a screenshot of the changes.

As usual, please include a screenshot of the changes.

This is the screenshot of the changes.

This is rather unintuitive. The column key is "ID" but the values links to some log file.
We need a better column key, and imo shouldn't directly link to the log file but instead the page of the host TE.

This is rather unintuitive. The column key is "ID" but the values links to some log file.
We need a better column key, and imo shouldn't directly link to the log file but instead the page of the host TE.
This is a part for log change, then user can easily see log from job. So add this log link. And I have discussed with till

I know what the goal is; but this doesn't change the fact that ID is not an appropriate column key for a link to the TaskExecutors log page. For that "Log file" would make more sense.

screenshot

#9696

Thanks a lot for this pull request.
I agree with Chesnay, that the initial approach of adding a "Logs" link next to the ID does not make sense conceptually.
The current approach...

... is also not good in my opinion, for the following reasons:

This view shows metrics per subtask ID, the "log" link is a little bit lost there
I don't understand the decision to use a lowercase "l". I would write "Log".
I'm not sure if it is intuitive for users to understand that this "Log" is the TaskManager log. As a user, I would expect a page that shows the log messages only from this specific SubTask, which is not true.

I don't have much experience with UX design, and I don't have much time to really think this through (I would recommend you to do that), but one idea I had was to solve this similar to how Google does their UI:

With that approach, we could have the three "..." at the end of the line, and then a dropdown that says: "View TaskManager logs"

Could we not update the host column to include the port (like on the taskmanagers page) and link to the TaskManager page? Wouldn't this effectively work like the current iteration, just without an additional column?

Could we not update the host column to include the port (like on the taskmanagers page) and link to the TaskManager page? Wouldn't this effectively work like the current iteration, just without an additional column?
Like this:

Could we not update the host column to include the port (like on the taskmanagers page) and link to the TaskManager page? Wouldn't this effectively work like the current iteration, just without an additional column?

Like this:

screenshot
running

created

The previous design in ths PR is following the blink version UX which may not get enough feedbacks before.
After trying both Robert and zentol's UX suggestion in my local development, I think "..." with dropdown is better since it would give a much more clear meanings for users and save the limited space at the same time.
I have updated the screenshot and code, thanks a lot for your advices.
cc @zentol @rmetzger

@flinkbot run travis

CI failed because FlinkKafkaProducerBase error, ignore.

screenshot
running

created

@zentol I updated the screenshot, is there any problems? Could you give me some advice if possible?

This looks fine to me; however I'd recommend to revise 60b5698aa2b9fe9ae233957688bd67a63325b7db to follow the same approach.


Increase test coverage over 90%

At the moment of writing the test coverage is at 88%.

I will be happy to help a bit during weekend
It seems like the biggest offender is reactive subproject ( 761 lines missed at the time of writing )

👍 @Avasil, glad to hear it!
Look for the low hanging fruits first — some of the lines are non-deterministic (e.g. in compareAndSet loops), we should just turn off coverage for those lines (possible with a comment) and you should avoid those for now.

@alexandru
How would you suggest to measure test coverage locally?

@Avasil with the sbt-scoverage plugin, which is already in Monix's config.
sbt

project evalJVM
coverage
test
coverageReport

@alexandru As an update on this issue, unfortunately I've been very busy lately and it might last a while before I do any meaningful progress but it will happen eventually :)
Also I have some problem with sbt coverage, both on Windows 10 and Ubuntu 14.04, trying different sbt versions (1.0, 0.13.16) and googling didn't help so far, maybe you encountered something similiar:
[IJ]> project evalJVM
[info] Set current project to monix-eval (in build file:/E:/Documents/Idea%20Projects/monix/)
[IJ]> coverage
[error] Not a valid command: coverage
[error] Not a valid project ID: coverage (similar: coreJS, coreJVM)
[error] Expected ':' (if selecting a configuration)
[error] Not a valid key: coverage (similar: homepage, package, compilerCache)
[error] coverage
[error]

If I don't solve it I guess I'll just do some workaround and in worst case commit a lot to PR :P

That is because the sbt-scoverage plugin is dirty, not necessarily supporting new Scala versions in time and attaching itself to the generated POM on deployment and thus disabled by default as a hack.
You need an SBT_PROFILE=coverage environment variable. So run sbt like this:
SBT_PROFILE=coverage sbt


add mcping command

This is technically added. It pings the server, I may add to it eventually, but it's okay for now.


proposal: add a mechanism to allow generic de- and re-structuring of complex values

Background
The Type Parameters Generics proposal has been accepted so type-parametric generic functions will be part of the language in the not wildly distant future. Currently there is a gap in the proposal that has been raised in golang-nuts, here, here and here.
The issue in those discussions is that the type parameterisation approach does not currently allow any kind of correlated structured types unless the structured type is a composite type (structs, arrays, slices, and maps); the current approach covers the majority of structured types but misses types that have complex64 and complex128 as their underlying type. Under the current proposal it is not possible to write something like this:
type Complex interface {
	type complex64, complex128
}

func Abs[T Complex](v T) ? {
	return ?(math.Hypot(real(v), imag(v)))
}

Another example in the opposite direction, showing a use that would useful in generic DSP code is to allow the conversion of a real value to the same value represented as a complex number.
type Real interface {
	type float32, float64
}

func AsComplex[T Real](v T) ? {
	return ?(complex(v, 0))
}

where ? indicates some type specification that would be the float type corresponding to the complex T.
The examples shown here are trivial (though relevant to a generic "math/cmplx" package), but more significant issues exist for example the example given in the first golang-nuts link above, a generic Eigen Decomposition function which takes a real m×n matrix and returns a pair of complex matrices and a complex vector.
type Real interface {
	type float32, float64
}

func Eigen[T Real](m, n int, data []T) (left, values, right []?, ok bool) { ...

If complex values are represented as structs, these issues do not exist, for example, here. However, this shuts out any use of the language's complex types, and it requires that complex types be referred to by their real coefficients' types, rather than by their actual complex type.
Alternatively, the function could be implemented as follows
type Real interface {
	type float32, float64
}

func Eigen[T Real](m, n int, data []T) (leftRI, valuesRI, rightRI []T, ok bool) { ...

where the returned slices hold alternating real and imaginary parts, but the 70s called and they want their language back, and this does not address the issue with non-slice types.
Proposal
I propose that the complex and real keywords be adopted to allow obtaining the correlated type for real and complex values respectively. This would allow the examples above to be written as follows:
type Real interface {
	type float32, float64
}

type Complex interface {
	type complex64, complex128
}

func AsComplex[T Real](v T) complex(T) {
	return complex(T)(complex(v, 0))
}

func Abs[T Complex](v T) real(T) {
	return real(T)(math.Hypot(real(v), imag(v)))
}

func Eigen[T Real](m, n int, data []T) (left, values, right []complex(T), ok bool) { ...

The choice of complex is obvious, though real is perhaps less so, it can be read as the type of the real coefficients of the complex type, rather than the real part. For this reason, imag(T) is not appropriate to obtain the float correspondent of T. If float were still part of the language it could have been chosen.
Since complex values' parts must match, the complex corresponding to a float T, is specified as complex(T) rather than complex(T, T).
A potential alternative syntax instead of complex(T) and real(T) is complex[T] and real[T], though this would be ambiguous with indexing in the code body.

Note that complex and real are not keywords; they are predeclared identifiers.  This proposal effectively extends complex and real to be ordinary (generic) functions when invoked on a value, but to be meta-functions from types to types when invoked on a type.  We have many operators that can be used to convert one type to another type (e.g., the * operator converts T to pointer-to-T), but there would be the first functions.  I don't think that is a blocker for this proposal, I'm just pointing it out.
CC @griesemer

Thanks, @ianlancetaylor. Yes, that was something I was considering in terms of backwards compatibility. I was trying to see if there was something that the syntax choice here was cause problems with but was unable to find any (of course they may exist). Other non-function based syntax is obviously also possible.

I quite like the view of complex types as generic types.
Suppose that we'd already had generics in the language and wanted to add support for complex values.
We could implement much of the current spec with something like this (defined in global scope):
// not currently in global scope but could be.
type realType interface {
	type float32, float64
}

// not currently in global scope but could be.
type complexType[T realType] struct {
	real, imag T
}

type complex64 = complexType[float32]
type complex128 = complexType[float64]

func imag[T realType](x complexType[T]) T {
	return x.imag
}

func real[T realType](x complexType[T]) T {
	return x.real
}

func complex[T realType](r, i T) complexType[T] {
    return complexType[T]{r, i}
}

Perhaps if we think of the existing complex types as a kind of sugar over the above, then it might make sense to allow complex[float32] and complex[float64] as synonyms for complex64 and complex128 respectively.
One issue with that is that this would make the type complex synonymous with the constructor function complex, which is awkward because then there would be an ambiguity between a type conversion complex(x) and a constructor expression complex(r, i). We could disambiguate by treating it as a type conversion when there's one argument and a constructor when there are two, but that feels a little bit dubious.
It also opens up a question: given that type lists allow any type whose underlying types are mentioned, this would also admit complex[floatType] where floatType is a defined type with underlying type float32 or float64.
Would that be OK?

If complex values are represented as structs, these issues do not exist, for example, here. However, this shuts our any use of the language's complex types

FWIW I always felt that the inclusion of complex numbers into the language was a bit strange. IMO, adding more strangeness on top to make them work with generics is bringing the sunk cost fallacy to mind. I think it might well be worthy of consideration to deprecate the builtin complex types in favor of a library-implementation of them - which can actually be built with generics. The generic type could live in math, for example.

In my opinion, this example might show one of the limits of the current form of the proposal where constraints are derived from types.
The opposite should happen, i.e. types should be derived from constraints. (with a way to extract the original constraints of a type so that the general user can constrain type parameters)
Then we could have functions of constraints object argument that returns constraints. This is different from using types as constraints because not all constraints are necessarily types.
They could be propositions (as in "convertible to X")
Propositions and not predicates. I think this ought to be restricted to zeroth-order logic. So straight application of proposition calculus.
I will reference here again the little warning from "A gentle introduction to semantic subtyping" on page 200 as this seem to remotely apply here.
https://www.irif.fr/~gc/papers/icalp-ppdp05.pdf
Their issue is about subtyping relations but I think the more general issue is about type constraint propagation... i.e. whenever there is a relation between types. In the present case for instance or notably when we deal with interfaces, composite types such as structs etc.
The constraint package should eventually be the partial constraint store of the default constraint system induced by the type system.
Just a note.

I don't know what the downvote is for since I see no explication but said in some more simpler terms, types should be built from constraint sets.
An interface would be like a regular type with some structural and the nominal constraints lifted. Effectively allowing subtyping (but not parametricity here because interfaces are themselves types) .
This is going to be important for any other composite types and especially if we want typelists are regular interfaces.
Propositional functions would allow to define precisely the constraint that form a complex type depending on the constraints of the argument float type.
Funnily enough, this is the goal of semantic subtyping: allowing parametricity in the presence of subtyping.

@atdiar I gave a thumbs-down because it sounds to me like you are suggesting a relatively fundamental change to the generics design - not just an amendment to address OPs concerns. I felt that this is neither the time nor place for that discussion. I also didn't want to drag the issue further off-topic, so I tried leaving it with an emoji reaction.

Yes but OP concerns are to me a part of a more general problem with the design. I think it fits here.
Thank you for the clarification.

@Merovius Regarding the removal of built-in complex types, there are two parts that need to be addressed. The first is likely trivial, it would need a rewrite tool to convert the existing infix notation to function calls (we have an extensive collection of functions that work on complex values and a manual rewrite is a non-starter). The second is a judgement call; reading conventional infix notation is much easier for most people. We have other rings (quaternion, dual, hyperdual, dual quaternion and noncom dual complex)  implemented and using those systems is harder than the complex. If a rewrite tool for thing 1 existed I guess it could be coopted to make a code generation tool to convert from infix to function call forms though.

Yeah, my comment was originally prompted by this sentence from your mail to golang-nuts:

Indeed, in the current generics proposal, the Gonum quaternion, dual, hyperdual and dual quaternion number types are easier to integrate into a generics system than the built in complex number types because they are based on structs.

I think the same readability concern also transfers to other types, like big.{Int,Float} or GL(n, R). Singling out ℂ seems based on the prior that they are already natively represented in the language - that's where the sunk cost fallacy comes in :)
Personally, it seems more elegant to me to address the readability issue separately, if we are worried about it. With a solution that can be applied to other library-types as well. If Go had operator overloading, that would solve the readability issue of representing ℂ as structs while also helping Quaternions, *big.Int and GL(n,R) code, while not requiring us to bolt on further exceptions for complex to the generics design. If, on the other hand, we think the costs of operator overloading outweigh their benefits, the same calculus that leads us to conclude that for *big.Int should also be applied to ℂ.
In any case, I just wanted to make the option explicit :) I'm content to just wait and see where the rest of the discussion is going :)

@rsc can I clarify the proposal status of this issue? It has been removed from Incoming, but not placed in Active. Was this intentional?

It's now labeled as a Go2 proposal.

gri

On Wed, Apr 7, 2021, 12:40 PM Dan Kortschak @.***>
wrote:

@rsc https://github.com/rsc can I clarify the proposal status of this
issue? It has been removed from Incoming, but not placed in Active. Was
this intentional?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/45049#issuecomment-815175036, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACBCIT46UXRRWHMOXL3H5IDTHSYJRANCNFSM4ZHUISPQ
.

Maybe how that fits in with https://github.com/golang/proposal#readme could be clarified? This otherwise feels kind of arbitrary.

OK. Thanks for clarifying that. Perhaps some text in the proposal#readme could be added to note this progress path?

I think the same readability concern also transfers to other types, like big.{Int,Float} or GL(n, R). Singling out ℂ seems based on the prior that they are already natively represented in the language - that's where the sunk cost fallacy comes in :)

Is there interest in extending such a proposal to a general syntax for destructuring uncommon types in general? Something like the following example:
type Person struct {
    Firstname, Lastname string
    NumberOfCats,NumberOfDogs int
}
type Name struct {
    FName, LName string
}
type Pets struct {
    Cats, Dogs int
}

func DestructuringExample(person Person) bool {
    name, pets :=  person.{Name, Pets}
    name.FName = "Ted"
    return person.Firstname == name.FName
}

func DestructuringExample2(person Person) bool {
    name, pets :=  (*Name)(unsafe.Pointer(&person)), (*Name)(add(unsafe.Pointer(&person),sizeof(Name))
    name.FName = "Ted"
    return person.Firstname == name.FName
}

Specific concerns would be whether it would be an issue that this exposes otherwise unexported types, and that this now creates a strong coupling between the involved named types. Nonetheless, this type of destructuring can be currently done with raw pointers, though it is considerable more brittle and is not statically checkable.

Rather than using complex as a general type function, we can restrict it to be only used as a constraint.  The expression complex(T), where T is a type that must be a floating-point type, is the complex form of that floating-point type, either complex64 or complex128.
We don't need anything else, because we can rely on type inference.
type Float interface { ~float64 | ~float128 }

func ToComplex[F Float, C ~complex(F)](f F) C { return complex(f) }

func RealPart[C ~complex(F), F Float](c C) F { return real(c) }

In these examples, the function ordinary argument determines the first type argument, and the second type argument is inferred from the first type argument.

A slightly different syntax would be to use complex[R] as the constraint.  That would make it clearer that we are describing (instantiating) a type rather than calling a function.  This also does not introduce new syntax for constraints.  I guess this has some similarities to what @rogpeppe suggested above, although it's not clear that we would want to permit this syntax to be used for anything than a constraint.

To follow-up on @ianlancetaylor's comment, another way of stating this is to say that complex types are (special, built-in) composite types of which there exist two types: complex[float32] and complex[float64], very much the same as the (special, built-in) composite map and channel types (of which there happen to be infinitely many types).
And for historic reasons we also have the aliases
type complex64 = complex[float32]
type complex128 = complex[float128]

The reason why these complex[T] types are not defined as structs is because they allow operations (such as the usual arithmetic operations) which are not available on structs.
The one anomaly we'd have is the fact that complex[T] is both a built-in type and a built-in function, but that may be the price to pay if we want to keep the name complex. (I suppose one could use something like cmplx[float32] and avoid this issue as well, which is perhaps ok since it would only appear in constraints, given that we also have the aliases.)

@ianlancetaylor @griesemer variously s/float128/float32/g and s/float128/float64/g?
@ianlancetaylor I think probably this
func ToComplex[F Float, C ~complex(F)](f F) C { return complex(f) }

is
func ToComplex[F Float, C ~complex(F)](f F) C { return complex(f, 0) }

Is this correct? If so, I think we could live with this approach.

Yes, your understanding is correct.  Sorry for the typos.  I think I've fixed them now.

If we were to have:
type complex64 = complex[float32]
type complex128 = complex[float64]

Then could we write these?
type MyFloat float64
type MyComplex complex[MyFloat]

type ConstraintComplex[T float32 | float64] complex[T]

type AnyComplex128[T ~float64] complex[T]

@zephyrtronium Yes, I believe all these should be valid but I may be missing something.


[X] WSL 2
[ ] WSL 1

Kernel Version
<IP_ADDRESS>
Distro Version
No response
Other Software
PowerShell 7.3.3
Repro Steps
I was having difficulties parsing the output from any wsl command with PowerShell without a bunch of additional lines getting added to the output if capturing the output into an array.
Here is an example output from the version command.
❯ wsl --version
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>
WSLg version: 1.0.49
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19044.2604

Array capture output:
❯ (wsl --version)
WSL version: <IP_ADDRESS>

Kernel version: <IP_ADDRESS>

WSLg version: 1.0.49

MSRDC version: 1.2.3770

Direct3D version: 1.608.2-61064218

DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp

Windows version: 10.0.19044.2604

❯ (wsl --version).Length
15

I saved the commands output into a file (i.e. wsl --version > file.txt) and discovered the cause is due to an incorrect character values placed at the end of each line.
The output is little endian utf16 format and each line is separated with \u0D00 + \u00A0 character sequence. If you look closely you'll notice that \u0D00 should be \u00D0 instead.
Expected Behavior
wsl output is in a standard character encoding with appropriate line ending character values.
Actual Behavior
Output contains an invalid line ending sequence.
Diagnostic Logs
No response

To work around this issue the array output can be filtered with the following command
(wsl --version | ? {$_.Replace("`0","")})

Thanks for reporting this @nickcampau. This is because wsl writes to stdout in unicode by default. You can work around this by setting the environment variable WSL_UTF8 to 1, which wil force all output to be in UTF8.

@OneBlue thanks for the tip on enabling utf-8 output, that avoids the line ending bug I was getting.
However, I think you missed what exactly the bug was that I reported. I understand the the (default) output from wsl is Unicode (utf-16 to be exact) and that isn't an issue. What is wrong is one of the character values at the end of each line. Instead of outputting a carriage return value (\u00D0) the character (\u0D00 MALAYALAM SIGN COMBINING ANUSVARA
ABOVE) is used instead. To put it another way, the incorrect byte order of the value for the carriage return value was outputted.
This issue as reported has not been resolved and this has been marked closed. Can you reopen this issue?

Thanks @nickcampau. I can't reproduce this though. Can you explain how you got that unicode character from wsl and how you computed its value ?

@OneBlue I ran the following command in my PowerShell (ver 7.3.3.) console. wsl --version > wsl_version.txt and opened the file in a hex editor.  I ran the same command in a cmd console and that file was encoded correctly as a UTF-16 LE file. So there looks like there is a mishandling of the output only with PowerShell.


nv_gpu_install_from_commit: update builder script for new GPU Operator repo structure

/uncc @sjug
/uncc @zvonkok

/test gpu-operator-e2e

/test gpu-operator-e2e

/hold cancel

ci/prow/gpu-operator-e2e  fails because the master branch of the GPU Operator is currently broken.
the fix should be merged today, I'll wait for it before merging this PR
/hold

/lgtm

/test gpu-operator-e2e

/test gpu-operator-e2e

\test gpu-operator-e2e
2021-03-25 17:50:09,249 p=3643 u=psap-ci-runner n=ansible | TASK: nv_gpu : Ensure that the GPU Operator PackageManifest exists
2021-03-25 17:50:09,250 p=3643 u=psap-ci-runner n=ansible | ----- FAILED ----
2021-03-25 17:50:09,250 p=3643 u=psap-ci-runner n=ansible | msg: non-zero return code
2021-03-25 17:50:09,250 p=3643 u=psap-ci-runner n=ansible |
2021-03-25 17:50:09,250 p=3643 u=psap-ci-runner n=ansible | <command> oc get packagemanifests/gpu-operator-certified -n openshift-marketplace
2021-03-25 17:50:09,250 p=3643 u=psap-ci-runner n=ansible |
2021-03-25 17:50:09,250 p=3643 u=psap-ci-runner n=ansible | <stderr> Error from server (NotFound): packagemanifests.packages.operators.coreos.com "gpu-operator-certified" not found
2021-03-25 17:50:09,250 p=3643 u=psap-ci-runner n=ansible | ----- FAILED ----

https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift-psap_ci-artifacts/101/pull-ci-openshift-psap-ci-artifacts-master-gpu-operator-e2e/1375124095917625344/artifacts/gpu-operator-e2e/presubmit-operatorhub/artifacts/175004_gpu-operator__deploy_from_operatorhub.sh/ansible_logs

/test gpu-operator-e2e

the GPU Operator master branch is still broken, even when trying the PR that was supposed to fix it:
NAME                                 DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                                  AGE
nvidia-container-toolkit-daemonset   1         1         1       1            1           nvidia.com/gpu.deploy.container-toolkit=true   15m
nvidia-device-plugin-daemonset       1         1         0       1            0           nvidia.com/gpu.deploy.device-plugin=true       15m
nvidia-driver-daemonset              1         1         1       1            1           nvidia.com/gpu.deploy.driver=true              15m

/hold cancel

the PR was lgtm-ed by Eduardo and the patch successfully deploys the GPU Operator from its master branch,
so I force merge as the gpu-operator-e2e test won't pass until the issue is fixed upstream.

Merged!


Fix QUIC deferred access logging for black-holed client

Commit Message: Fix QUIC deferred access logging when client terminates connection before final ack
Additional Description: Addresses bug reported in https://github.com/envoyproxy/envoy/issues/29930.
Risk Level: Low
Testing: Integration test
Docs Changes: N/A

/assign @alyssawilk

needs a main merge to fix CI permafail

this has auto-merge enabled so just needs
/retest


Rust-Nightly autom. CI-Update

I tried out things here:
https://github.com/geo-engine/ci-tests/blob/main/.github/workflows/cargo.yml
That led to:
https://github.com/geo-engine/ci-tests/pull/1

 Rust-Nightly autom. CI-Update

so the checks have failed, how would we now proceed with the PR? Who fixes the new clippy errors? Will they be fixed in this PR or in another one and then we merge the master into this one?

Depends on https://github.com/geo-engine/geoengine/pull/94

Depends on #94

And in the future? Will we always create a new clippy-fix pr, review ist separately und then merge it into the fix-nightly-pr? Or do we fix it in the PR? Who will be responsible to do it?

Depends on #94

And in the future? Will we always create a new clippy-fix pr, review it separately und then merge it into the fix-nightly-pr? Or do we fix it in the PR? Who will be responsible to do it?

We will fix this error in the PR-branch directly if it occurs. Wrt. the responsibility, it is the same for the dependency updates. We have to see how this works out and otherwise discuss it at some point.


Update NPC health data

Only NPCs which have an "Attack" option were dumped.

This updates the NPC health data to include all the NPCs that are in the cache as of the update on May 03 2018.
Changes the OpponentInfo to fetch its health data based on NPC ID instead of name_level format so that there are no NPCs conflicting with each other.

The health information is gathered from the OSRS Wikia. This might cause some data to be inaccurate if the wiki is missing it or has the incorrect values.
For a list of currently missing NPCs: missing.json
npc_health.json: 2102 NPCs
missing.json: 441 NPCs

Would be nice to have this rebased and merged probably

if this gets rebased any raids 1 & 2 monsters should be removed as there hp scales based on party size and would be incorrect for example "7554": 1600, thats olms head and he only has 1600 hp in a solo

Updated and removed raids 1/2 NPCs

Hmm this is still missing stuff like baby dragons and looks like it also has some incorrect data, like Monk lvl 3 should have 5 hp, I think.

Oh, I redumped and I forgot that I had to do those baby dragons manually. As for the monk, I loaded the current npc health file we have and then if I could not find the npc on the wiki (monk lvl 3 in this case doesn't exist) it will use the health data from the old file, where it was already incorrect.
I kept track of NPCs it didn't manage to find health for in this file: https://puu.sh/BdjTR/762bdca1b6.json

Ah alright, seems good then.


Added isLogsExpanded and isLogOrderReversed flags to TalkerScreen widget

Be able to initially set  isLogsExpanded and isLogOrderReversed when open the TalkerScreen

Hello @Ilushnik !
Thank you so much for this contribution ❤
Can you fix review issues to merge this PR ?


raw data no longer available for download

I find that some of the data required to run your comparisons is no longer available, specifically:
| prepare_data_FlowCAP_ND.R   | manual gating data unavailable                                     |
| prepare_data_FlowCAP_WNV.R  | manual gating data unavailable                                     |
| prepare_data_Levine_13dim.R | 404 https://www.cytobank.org/cytobank/experiments/46259   |
| prepare_data_Levine_32dim.R | 404 https://www.cytobank.org/cytobank/experiments/46102   |
if you know of other sources for such data, I would be happy to learn of them.
additionally, if you've extended/improved this framework for contrasting clustering approaches, I would appreciate an education in these efforts...
cheers!

Hi,
Lukas will certainly post a better answer. Meanwhile you can start working with the prepared dataset from Lukas at https://flowrepository.org/id/FR-FCM-ZZPH. There are untransformed data there also.
Best.

Yes, unfortunately some of those raw data links/repositories may no longer be maintained by the original authors.
However, as mentioned above, all our data files are also available in our own repository at https://flowrepository.org/id/FR-FCM-ZZPH, as described in our paper.
Also, since then, we have also made all of these datasets available through our HDCytoData Bioconductor package, which is available at http://bioconductor.org/packages/HDCytoData, and described in our paper at https://f1000research.com/articles/8-1459.


Contact pypi about switching to this as the main pyxform installation

Github support has already changed the listing so that XLSForm/pyxform is the "root" project.
pip install pyxform still points to modilabs / SELColumbia's repo

Verified that the pypi version is code from this directory and that there are no stale links at https://pypi.python.org/pypi/pyxform/


Subject.asObservable() missing?

Hi
either it is missing, or it is missing in the migration guide?
Frank

Missing in the migration guide. At least from my perspective it seems we are intentionally removing it instead of forgetting to add it. Is that correct @blesh @kwonoj @trxcllnt ?

Yes. Unless there's a compelling reason to add it.

@blesh of course there's a compelling reason to add it.  For example, exposing Subjects directly is usually a code smell, instead you want to hide the ability for the consumer of the API to send next calls, etc to it, so to call asObservable prevents that.

Fair, but is that a solid enough reason to add the weight to the type, though?
(honestly just playing devil's advocate)

@blesh absolutely, as there is little to no overhead in doing so as in RxJS v4 asObservable

Yep. Just want the consideration in the issue. I totally agree we should add it.


Revert "chore(deps): update ticommunityinfra/tichi-cherrypicker-plugin docker tag to v2.4.0"

Reverts ti-community-infra/configs#702

/merge


Remove CRDs and its validating webhooks

This removes metallb specific CRDs and its validating web hook
implementation as it's getting moved into metallb repository.
Depends on https://github.com/metallb/metallb/pull/1237
Signed-off-by: Periyasamy Palanisamy<EMAIL_ADDRESS>

Another comment: the CRDs will live in metallb and its manifests, but the operator will still have to deploy them.
We need to find if it's better to expose the CRDs as part of the csv, or to give the operator the permissions to create them and have them in the bindata.
Maybe it's worth researching what other operators do.

@pperiyasamy did a first round, looks good! I have a couple of comments.
I'd wait to move this forward until the crd work lands in metallb (at least, the preliminary part).
Comments:

Not sure what the best practice is, but would it make sense to leave the CRDs at csv level? This would allow us to avoid giving the operator powers to create new ones
We are removing the webhooks here, we don't have them (yet) in metallb, but we'll add them. How do you envision creating those webhooks from the operator? (this is kind of the same question as above, probably it will make sense to bring them back at csv level).

@sabinaaledort mind having a look at this PR? I'd also like to hear your opinion

Not sure what the best practice is, but would it make sense to leave the CRDs at csv level? This would allow us to avoid giving the operator powers to create new ones
We are removing the webhooks here, we don't have them (yet) in metallb, but we'll add them. How do you envision creating those webhooks from the operator? (this is kind of the same question as above, probably it will make sense to bring them back at csv level).

@fedepaol The CSVs now generated using generate-metallb-manifests.sh script by referring to metallb manifests which now contains CRDs, I guess this makes sense as we don't duplicate the CRDs at multiple files. or are you referring to something else ?
For webhooks, are you looking to have a new repository (for example, metallb-admission-controller) which would implement validation for CRD instances.

Not sure what the best practice is, but would it make sense to leave the CRDs at csv level? This would allow us to avoid giving the operator powers to create new ones
We are removing the webhooks here, we don't have them (yet) in metallb, but we'll add them. How do you envision creating those webhooks from the operator? (this is kind of the same question as above, probably it will make sense to bring them back at csv level).

@fedepaol The CSVs now generated using generate-metallb-manifests.sh script by referring to metallb manifests which now contains CRDs, I guess this makes sense as we don't duplicate the CRDs at multiple files. or are you referring to something else ? For webhooks, are you looking to have a new repository (for example, metallb-admission-controller) which would implement validation for CRD instances.

Re: CRDS, before we were creating them from the bundle. With this change, we are giving the operator power to create any crd (https://github.com/metallb/metallb-operator/pull/169/files#diff-03d0a36255d3dafd288c20eadb7ba443002a3e0f9c0cda1f34457aa390051caeR106) and we are copying them in the frr / metallb manifests under bindata. I am not 100% that's the best approach vs keeping them at bundle level
Re: webook, I think it's gonna make sense to have the metallb controller to be the backend of the webhook. My concern is on how to configure it. It must be possible to deploy metallb + webhooks from the bare metallb repo (via helm OR via kustomize), but also from the operator, and again, giving the operator power to create any webhook might not be the right way.

I think it looks good. Like @fedepaol already mentioned, I feel I don't understand the next steps for having the webhooks.

Re: CRDS, before we were creating them from the bundle. With this change, we are giving the operator power to create any crd (https://github.com/metallb/metallb-operator/pull/169/files#diff-03d0a36255d3dafd288c20eadb7ba443002a3e0f9c0cda1f34457aa390051caeR106) and we are copying them in the frr / metallb manifests under bindata. I am not 100% that's the best approach vs keeping them at bundle level

yes @fedepaol , I understand your concern, it's not appropriate operator having power to create any CRDs. AFAIK, these CRDs must be created manually, for example, sriov-network-operator is deployed after network-attachment-definition CRD is created from here and other CRDs here. I think we may need to follow this approach for metallb going forward.

Re: CRDS, before we were creating them from the bundle. With this change, we are giving the operator power to create any crd (https://github.com/metallb/metallb-operator/pull/169/files#diff-03d0a36255d3dafd288c20eadb7ba443002a3e0f9c0cda1f34457aa390051caeR106) and we are copying them in the frr / metallb manifests under bindata. I am not 100% that's the best approach vs keeping them at bundle level

yes @fedepaol , I understand your concern, it's not appropriate operator having power to create any CRDs. AFAIK, these CRDs must be created manually, for example, sriov-network-operator is deployed after network-attachment-definition CRD is created from here and other CRDs here. I think we may need to follow this approach for metallb going forward.

The SR-IOV network operator does not have such permission. Our focus should be deploying via OLM (to benefit from the complete operator lifecycle), hence checking what the csv look like. I think there's no csv on the community version, however if you look at what's being shipped in openshift: https://github.com/openshift/sriov-network-operator/tree/master/manifests/4.10
The CRDs are part of the bundle, and the operator does not have permission to create them. I think it makes sense to adhere to that. @sabinaaledort wdyt?

Re: CRDS, before we were creating them from the bundle. With this change, we are giving the operator power to create any crd (https://github.com/metallb/metallb-operator/pull/169/files#diff-03d0a36255d3dafd288c20eadb7ba443002a3e0f9c0cda1f34457aa390051caeR106) and we are copying them in the frr / metallb manifests under bindata. I am not 100% that's the best approach vs keeping them at bundle level

yes @fedepaol , I understand your concern, it's not appropriate operator having power to create any CRDs. AFAIK, these CRDs must be created manually, for example, sriov-network-operator is deployed after network-attachment-definition CRD is created from here and other CRDs here. I think we may need to follow this approach for metallb going forward.

The SR-IOV network operator does not have such permission. Our focus should be deploying via OLM (to benefit from the complete operator lifecycle), hence checking what the csv look like. I think there's no csv on the community version, however if you look at what's being shipped in openshift: https://github.com/openshift/sriov-network-operator/tree/master/manifests/4.10 The CRDs are part of the bundle, and the operator does not have permission to create them. I think it makes sense to adhere to that. @sabinaaledort wdyt?

The CRDs are added into bundle manifests now and also removed create/update privilege for metallb operator instance.
We still require to move out CRDs from the metallb manifest files 1 and 2 , this would make operator CI to pass.

We still require to move out CRDs from the metallb manifest files 1 and 2 ,

please ignore this comment, the operator is now made to skip creating crds.

Hi @pperiyasamy! this is a great and important PR.
I think there are still files left in path "config/crd/bases" for addresspools, bfdprofiles, bgppeers that should have been deleted.

Hi @pperiyasamy! this is a great and important PR. I think there are still files left in path "config/crd/bases" for addresspools, bfdprofiles, bgppeers that should have been deleted. Also in kustomization.yaml remove crds, and I think kustomizeconfig.yaml should be deleted.

We need them, because we won't let the operator's controller create them, but we will have them either in the csv OR in the operator's manifests.
What we should have is either a common repo to consume the yamls from, or automation in place to ensure they don't drift / make it easier to bump.

@fedepaol any idea about ci failure here whereas its working on my local setup ?


Added Dazta to users.yml and users-logo

Adding new user logo

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Thank you @rust-highfive. Will be waiting for review by @brson

Awesome, thanks!

Can you explain how you or your work involves Rust?
I can not find any details on:

https://www.dazta.com/
https://github.com/dazta
https://github.com/ramsundhar20

We are working on a financial product on Rust, which is currently under
development within our team
புத., 9 ஆக., 2017, 14:07 அன்று kud1ing<EMAIL_ADDRESS>எழுதியது:

Can you explain how you or your work involves Rust?
I can not find any details on:

https://www.dazta.com/
https://github.com/dazta
https://github.com/ramsundhar20

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rust-www/pull/617#issuecomment-321191528,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEshvRFJLkQluZWqSDrGGRvhRhHjgZKLks5sWW-5gaJpZM4KzhN7
.

--
Ramsundhar Madhavan
Skype: ramsundhar20
Phone: +919676921227
http://www.dazta.com
DC1-203, Aarambh Township,
Papi Reddy Colony, Serilingampally,
Hyderabad, Telangana, India - 500 019.

We are working on a financial product on Rust, which is currently under development within our team

Are using it on the back end? Which frameworks do you use? What are your experience with it? Which problems did you occur?


Support parsing multiple files

Issue #, if available:
Description of changes:

Supports linting multiple files

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

A few things may need to get done before merging this one.

[ ] Make sure there is no adverse affect to the people using cfn-lint as a module
[ ] Double check that the IDE plugins still work

I noticed you've removed the WIP tag from this PR -- is it ready for review and merge?

yea I think this is about ready.  In the past there has a been a few argparse things that trip me up.  I'm hoping I can get a few people to put their eyes on it to make sure I didn't miss anything.

@alexjurkiewicz and @adamchainz  -- would either of you be willing to do a quick review/test of this PR to see if it helps with your multi-file use cases?

It should work for both... I'll check in on this.

@cmmeyer comma separated lists shouldn't really pass since commas are allowed in filenames, and there's already a way of passing multiple with space separation

Takes my lint of 73 templates from 53 seconds to 4 seconds!
But one thing that might be worth documenting is using the -- separator, since e.g. --regions consumes multiple arguments, I have to do cfn-lint --regions us-east-1 -- cloudformation/*.yml to make it work. The error message is unclear that there is no template passed without the --.

It would be nice to print each filename in debug mode -- I got an exception when I pointed the linter at a random directory and it was hard to figure out which file caused the exception.
(For what it's worth, the exception was when we hit a binary file(.zip).  I'll create a separate issue for that)
Traceback (most recent call last):
  File "/usr/local/bin/cfn-lint", line 11, in <module>
    load_entry_point('cfn-lint==0.7.2', 'console_scripts', 'cfn-lint')()
  File "/usr/local/lib/python3.6/site-packages/cfn_lint-0.7.2-py3.6.egg/cfnlint/__main__.py", line 30, in main
    (template, rules, template_matches) = cfnlint.core.get_template_rules(filename, args)
  File "/usr/local/lib/python3.6/site-packages/cfn_lint-0.7.2-py3.6.egg/cfnlint/core.py", line 245, in get_template_rules
    (template, matches) = cfnlint.decode.decode(filename, args.ignore_bad_template)
  File "/usr/local/lib/python3.6/site-packages/cfn_lint-0.7.2-py3.6.egg/cfnlint/decode/__init__.py", line 40, in decode
    template = cfnlint.decode.cfn_yaml.load(filename)
  File "/usr/local/lib/python3.6/site-packages/cfn_lint-0.7.2-py3.6.egg/cfnlint/decode/cfn_yaml.py", line 206, in load
    return loads(fp.read(), filename)
  File "/usr/local/lib/python3.6/site-packages/cfn_lint-0.7.2-py3.6.egg/cfnlint/decode/cfn_yaml.py", line 191, in loads
    loader = MarkedLoader(yaml_string, fname)
  File "/usr/local/lib/python3.6/site-packages/cfn_lint-0.7.2-py3.6.egg/cfnlint/decode/cfn_yaml.py", line 140, in __init__
    Reader.__init__(self, stream)
  File "/usr/local/lib/python3.6/site-packages/yaml/reader.py", line 74, in __init__
    self.check_printable(stream)
  File "/usr/local/lib/python3.6/site-packages/yaml/reader.py", line 144, in check_printable
    'unicode', "special characters are not allowed")
yaml.reader.ReaderError: unacceptable character #x0000: special characters are not allowed
  in "<unicode string>", position 0

Thanks for the feedback. Added logging for the filename information and did some extra items around the comma/space parsing.  Also added some more documentation.

Top stuff guys!!
On Thu., 27 Sep. 2018, 03:53 Chuck Meyer<EMAIL_ADDRESS>wrote:

Merged #331 https://github.com/awslabs/cfn-python-lint/pull/331 into
master.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/awslabs/cfn-python-lint/pull/331#event-1869104150,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXKdfpdXIHU9y_LkKhGrNdCWR-7Vgwhks5ue78pgaJpZM4WfJk3
.

🐇

pip install git+git://github.com/awslabs/cfn-python-lint.git works, but when I run pre-commit-validate-config .pre-commit-config.yaml, it fails with the following Traceback:
Traceback (most recent call last):
  File "/usr/bin/pre-commit-validate-config", line 11, in <module>
    sys.exit(validate_config_main())
  File "/usr/lib/python2.7/site-packages/pre_commit/clientlib.py", line 190, in validate_config_main
    load_config(filename)
  File "/usr/lib/python2.7/site-packages/cfgv.py", line 347, in load_from_filename
    contents = f.read()
  File "/usr/lib64/python2.7/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 386: ordinal not in range(128)

@Saichovsky that doesn't seem related to this at all, none of the stack trace frames are in cfn-python-lint. From the stacktrace I guess you have non-unicode characters in your configuration file.

@adamchainz Indeed. Reported on the wrong repo. Apologies.


Why generating *string for string fields in the model?

Not really an issue, rather a question. What is the motivation to generate pointers to string in models rather then strings? It enforces to implement funny dereferencing that may be also not always safe. And, frankly, I do not see a big benefit in this approach. So -- why?
For example, the following spec
type: object
properties:
  code:
    type: string
    description: "Error code"
    example: RESOURCE_NOT_FOUND
  message:
    type: string
    description: "Error message"
    example: "Requested resource not found"
  target:
    type: string
    description: "Related resource"
    example: "/products/42"
  details:
    type: object
    properties:
      code:
        type: string
        description: "Detailed error code"
        example: "MongoDB:2038"
      message:
        type: string
        description: "Detailed error message"
        example: "MongoDB: no document with ObjectID 42"
    required:
      - code
      - message
required:
  - code
  - message

results in (fragment)
type Error struct {

	// Error code
	// Required: true
	Code *string `json:"code"`

	// details
	Details *ErrorDetails `json:"details,omitempty"`

	// Error message
	// Required: true
	Message *string `json:"message"`

	// Related resource
	Target string `json:"target,omitempty"`
}

Code *string looks somehow weird, doesn't it?

duplicate of: #1188

Thanks, got it!


browser support?

🚀 Feature request
Motivation
First, hi! 👋 This library looks awesome, very excited that it exists!
Quick question, should be simple. What is the browser support story for Reakit? Does it rely on modern ES features that must be polyfilled for older browsers?
I'm sure you have an answer ready for this, just a matter of supplying it on the docs site 😄
Example
https://reactjs.org/docs/javascript-environment-requirements.html
https://blueprintjs.com/docs/#blueprint/getting-started.js-environment
Possible implementations
Add a section on https://reakit.io/docs/get-started/.
This is a little bit related to #624, as listing which browsers you test on is a good way of declaring which are officially supported.

It would be nice to have automated tests to enforce this as mentioned in #624
But we support all the modern browsers plus IE 11.


chore: update typescript sdk

Changes

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#1031  👈
#1030
#1029
#1028
#1014
#1013
#1006
#1005
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @NathanFlurry and the rest of your teammates on  Graphite


waf: link static with --whole-archive

In order to take advantage of some of CSP's builtin weak linked functions, the archive needs to be included with --whole-archive. This is because the garbage collector cleans unused symbols before linking rather than after (as would be possible with LTO).
WAF does not have any method to do this as far as i can tell.
https://gitlab.com/ita1024/waf/-/issues/2138
It is also unclear to me if it uses CSP as a shared library or as a static library. And in the case of the shared library, (which i can see cmake uses) if the weak implementations are available.

The new implementation of the examples are working without link whole, so closing now.


SBML translation of log

Should fix #45

I picked up another issue with the L3 formula parsing, i.e. && which should be replaced with and. Fixed in 4e7254e. The test models in https://github.com/PySCeS/pyscesdev/tree/main/sbml_test_models now all covert to PSC without error. All except 235 also execute and give the correct answers when compared to the curation data on BioModels. Model 860 gives some error in the SBML conversion about units not being able to be interpreted correctly, but the model runs and gives the correct numeric answer.
Model 235 executes the simulation correctly but fails in the end during REq evaluation. Not sure if this should be pursued further, this is a gene regulatory network model, maybe it fails because there are no fluxes?
Jupyter notebook with execution results for all the models uploaded to pyscesdev/sbml_test_models as well.

Why are you adding all the PSC files to psc when they are already in pscmodels? They are duplicated. Seems like a remnant from an improper in-place install or executing the python interpreter from the source directory. :confused:

I use a developer mode installation so run everything in-place I'll add that folder to .gitignore


add confmap provider to registry.json

As mentioned in #5387, there are more components that are compatible with the OpenTelemetry Collector.
These include confmap.Converter and confmap.Provider types.
confmap.Converter: https://github.com/open-telemetry/opentelemetry-collector/issues/11582
confmap.Provider: https://github.com/open-telemetry/opentelemetry-collector/issues/4567
There are currently five confmap.Providers that are maintained in the OpenTelemetry Collector core repository and while there is only one Converter there and it is deprecated, there are vendors that make use of converters and it is possible they would choose to publish them in the registry once this is available.
As I am not super familiar with the registry and changes necessary to update the same, I may have missed file(s) that need to be changed and will happily make these changes if suggested.
Additionally, I don't feel strongly about calling them "confmap converter" vs. "converter" or provider, but it seemed slightly more descriptive. Open to feedback there as well.

I will also plan to submit a separate PR to add the existing five confmap.providers to the registry once this change is approved.

Can you put all of them in one PR? Makes it easier to validate things and how we are going to name those values.

Yes, done.

ah shoot, this shows "confmap providers" as the yaml tag; is there any way to have the type listed as "Confmap provider" in the dropdown but show "providers" in the sample manifest?


PWA-333

Pull Request Test Coverage Report for Build 1277

0 of 40 (0.0%)  changed or added relevant lines in 2 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.3%) to 35.555%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

components/FilterBar/components/Content/components/FilterButton/index.jsx
0
1
0.0%

e2e/integration/CategoryPage.js
0
39
0.0%

Files with Coverage Reduction
New Missed Lines
%

e2e/integration/StartPage.js
1
0.0%

Totals

Change from base Build 1276:
-0.3%

Covered Lines:
1220

Relevant Lines:
3312

💛  - Coveralls


Add Nextcloud specific server side encryption support

I will reference this topic of a colective that are using Nextcloud:
https://forum.disroot.org/t/what-do-you-think-about-use-onlyoffice-instead-collabora-online/3132

Hello @CitoplasmaX, please see issue #26 for answer.

Okay

Duplicate of #26


python3 lane_detection_publisher.py

Hello
How to display your gif screen (right)？

Hi, output images publishing as a ros node. You can use Rviz to visualize it. The rviz tool allows real-time visualization of all components of the robotic system —the system of coordinates, moving parts, sensors, camera images — on the 3D stage. https://wiki.ros.org/rviz/DisplayTypes/Camera


Change from Gulp/JSHint to ESLint

See suggestion in #16. Also introduced fixes brought up by ESLint

@wkurniawan07 It's generated by eslint though (through --init). (I'm lazy enough not to come up with such long config). Also, would YAML format be better? (I chose JS so that future maintainers do not need to learn & understand another format).

as a future maintainer, I find that JS is okay :p

Merged


add DefaultsPropertyKit

Project URL

https://github.com/metasmile/DefaultsPropertyKit
Category

Database
Description

DefaultsPropertyKit is Key-Safe, Protocol-Driven, Strongly Typed UserDefaults for iOS, macOS and tvOS.
Why it should be included to awesome-ios (optional)
The simplest UserDefaults wrapper DefaultsPropertyKit lets you guarantee unsafe literal-based UserDefaults keys and values and guarantee them.
Checklist

[x] Only one project/change is in this pull request
[x] Has unit tests, integration tests or UI tests
[x] Addition in chronological order (bottom of category)
[x] Supports iOS 9 / tvOS 10 or later
[x] Supports Swift 4 or later
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

          1 Warning

:warning:
Found 1 link issue, a project collaborator will take care of these, thanks :)

Link issue by awesome_bot

Line
Status
Link

1814
301
https://github.com/app-shack/PlaygroundTDD redirects tohttps://github.com/WhiskerzAB/PlaygroundTDD

  Generated by :no_entry_sign: Danger

I will request later! Thank you


Remove duplicated API

Fix the build errors on mater branch

Docs Build status updates of commit f61f855:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

_dependentPackages/ECMA2Yaml/tools/Run.ps1
:x:Error

Details

_dependentPackages/ECMA2Yaml/tools/Run.ps1

Line 89: [Error] Error happened when executing plug-in script _dependentPackages/ECMA2Yaml/tools/Run.ps1 at step docset_prebuild. Please check your .openpublishing.publish.config.json?on the configuration of the plug-ins or ask for help?in Docs Support teams channel. Detailed error message: {"message":"Duplicated DocId found: M:Microsoft.Office.Interop.InfoPath._ApplicationEvents_SinkHelper.XDocumentBeforePrint(Microsoft.Office.Interop.InfoPath._XDocument,System.Boolean@)","source":"ECMA2Yaml","file":"\\officedocs-dev-infopath-form\\xml\\Microsoft.Office.Interop.InfoPath\\_ApplicationEvents_SinkHelper.xml","line":null,"message_severity":0,"message_severity_string":"Error","code":"ECMA2Yaml_DocId_Duplicated","date_time":"2020-03-05T10:01:05.0045676Z","log_item_type":2,"log_item_type_string":"User","category":"ECMA2Yaml"}.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit e52a036:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

_dependentPackages/ECMA2Yaml/tools/Run.ps1
:x:Error

Details

_dependentPackages/ECMA2Yaml/tools/Run.ps1

Line 89: [Error] Error happened when executing plug-in script _dependentPackages/ECMA2Yaml/tools/Run.ps1 at step docset_prebuild. Please check your .openpublishing.publish.config.json?on the configuration of the plug-ins or ask for help?in Docs Support teams channel. Detailed error message: {"message":"Duplicated DocId found: M:Microsoft.Office.Interop.InfoPath._ApplicationEvents_SinkHelper.XDocumentBeforeClose(Microsoft.Office.Interop.InfoPath._XDocument,System.Boolean@)","source":"ECMA2Yaml","file":"\\officedocs-dev-infopath-form\\xml\\Microsoft.Office.Interop.InfoPath\\_ApplicationEvents_SinkHelper.xml","line":null,"message_severity":0,"message_severity_string":"Error","code":"ECMA2Yaml_DocId_Duplicated","date_time":"2020-03-05T10:35:26.4380998Z","log_item_type":2,"log_item_type_string":"User","category":"ECMA2Yaml"}.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit a32db67:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

_dependentPackages/ECMA2Yaml/tools/Run.ps1
:x:Error

Details

_dependentPackages/ECMA2Yaml/tools/Run.ps1

Line 89: [Error] Error happened when executing plug-in script _dependentPackages/ECMA2Yaml/tools/Run.ps1 at step docset_prebuild. Please check your .openpublishing.publish.config.json?on the configuration of the plug-ins or ask for help?in Docs Support teams channel. Detailed error message: {"message":"Duplicated DocId found: M:Microsoft.Office.Interop.InfoPath._ApplicationEvents_SinkHelper.WindowSize(Microsoft.Office.Interop.InfoPath._XDocument,Microsoft.Office.Interop.InfoPath.Window)","source":"ECMA2Yaml","file":"\\officedocs-dev-infopath-form\\xml\\Microsoft.Office.Interop.InfoPath\\_ApplicationEvents_SinkHelper.xml","line":null,"message_severity":0,"message_severity_string":"Error","code":"ECMA2Yaml_DocId_Duplicated","date_time":"2020-03-05T10:52:33.5773736Z","log_item_type":2,"log_item_type_string":"User","category":"ECMA2Yaml"}.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 6b59ff0:
:warning: Validation status: warnings

File
Status
Preview URL
Details

officedocs-dev-infopath-form/api/Microsoft.Office.Interop.InfoPath.BDCAdapterObject.yml
:warning:Warning

Details

officedocs-dev-infopath-form/api/Microsoft.Office.Interop.InfoPath.InfoPathEditorWithAppDomain.yml
:warning:Warning

Details

officedocs-dev-infopath-form/api/Microsoft.Office.InfoPath.FormControl.yml
:warning:Warning

Details

officedocs-dev-infopath-form/api/Microsoft.Office.Interop.InfoPath._XDocument4.yml
:warning:Warning

Details

officedocs-dev-infopath-form/api/Microsoft.Office.Interop.InfoPath.SharePointListAdapterRW.yml
:warning:Warning

Details

officedocs-dev-infopath-form/api/Microsoft.Office.Interop.InfoPath.SharePointListAdapterRWObject.yml
:warning:Warning

Details

officedocs-dev-infopath-form/api/Microsoft.Office.Interop.InfoPath.MergeEvent.yml
:warning:Warning

Details

officedocs-dev-infopath-form/api/Microsoft.Office.Interop.InfoPath.View3.yml
:warning:Warning

Details

officedocs-dev-infopath-form/xml/Microsoft.Office.Interop.InfoPath/_ApplicationEvents_SinkHelper.xml
:white_check_mark:Succeeded

officedocs-dev-infopath-form/api/Microsoft.Office.Interop.InfoPath.BDCAdapterObject.yml

Line 0: [Warning] Invalid file link:(~/api/e51f978f-ae27-43a0-8450-7dfe5d39ab19).

officedocs-dev-infopath-form/api/Microsoft.Office.Interop.InfoPath.InfoPathEditorWithAppDomain.yml

Line 0: [Warning] Invalid file link:(~/api/frlrfSystemAppDomainClassTopic).
Line 0: [Warning] Invalid file link:(~/api/frlrfSystemAppDomainClassTopic).
Line 0: [Warning] Invalid file link:(~/api/frlrfSystemAppDomainClassTopic).
Line 0: [Warning] Invalid file link:(~/api/frlrfSystemAppDomainClassTopic).

officedocs-dev-infopath-form/api/Microsoft.Office.InfoPath.FormControl.yml

Line 0: [Warning] Invalid file link:(~/api/frlrfSystemAppDomainClassTopic).
Line 0: [Warning] Invalid file link:(~/api/frlrfSystemAppDomainClassTopic).
Line 0: [Warning] Invalid file link:(~/api/frlrfSystemIOStreamClassTopic).
Line 0: [Warning] Invalid file link:(~/api/frlrfSystemIOStreamClassTopic).
Line 0: [Warning] Invalid file link:(~/api/frlrfSystemAppDomainClassTopic).
Line 0: [Warning] Invalid file link:(~/api/frlrfSystemAppDomainClassTopic).
Line 0: [Warning] Invalid file link:(~/api/frlrfSystemIOStreamClassTopic).
Line 0: [Warning] Invalid file link:(~/api/frlrfSystemIOStreamClassTopic).
Line 0: [Warning] Invalid file link:(~/api/frlrfSystemIOStreamClassTopic).

officedocs-dev-infopath-form/api/Microsoft.Office.Interop.InfoPath._XDocument4.yml

[Warning] 1 invalid cross reference(s) "Microsoft.Office.Interop.InfoPath.ObjectWrapper".
[Warning] 1 invalid cross reference(s) "Microsoft.Office.Interop.InfoPath._XDocument4.SetNamedNodeProperty(Microsoft.Office.Interop.InfoPath.IXMLDOMNode,System.String,System.String)".
[Warning] 1 invalid cross reference(s) "Microsoft.Office.Interop.InfoPath._Application4.LanguageSettings".

officedocs-dev-infopath-form/api/Microsoft.Office.Interop.InfoPath.SharePointListAdapterRW.yml

[Warning] 1 invalid cross reference(s) "Microsoft.Office.Interop.InfoPath.SharepointListAdapterRWObject".
[Warning] 1 invalid cross reference(s) "Microsoft.Office.Interop.InfoPath.SharepointListAdapterRW.QueryAllowed".
[Warning] 1 invalid cross reference(s) "Microsoft.Office.Interop.InfoPath.SharepointListAdapterRWObject".
[Warning] 1 invalid cross reference(s) "Microsoft.Office.Interop.InfoPath.SharepointListAdapterRW.SubmitAllowed".
[Warning] 1 invalid cross reference(s) "Microsoft.Office.Interop.InfoPath.SharepointListAdapterRWObject".

officedocs-dev-infopath-form/api/Microsoft.Office.Interop.InfoPath.SharePointListAdapterRWObject.yml

[Warning] 1 invalid cross reference(s) "Microsoft.Office.Interop.InfoPath.SharepointListAdapterRWObject".

officedocs-dev-infopath-form/api/Microsoft.Office.Interop.InfoPath.MergeEvent.yml

[Warning] 1 invalid cross reference(s) "Microsoft.Office.Interop.InfoPath.MergeEvent.Index".

officedocs-dev-infopath-form/api/Microsoft.Office.Interop.InfoPath.View3.yml

[Warning] 2 invalid cross reference(s) "Microsoft.Office.Interop.InfoPath.View3.SelectNodes(Microsoft.Office.Interop.InfoPath.IXMLDOMNode,System.Object,System.Object)", "Microsoft.Office.Interop.InfoPath.View3.SelectText(Microsoft.Office.Interop.InfoPath.IXMLDOMNode,System.Object)".
[Warning] 1 invalid cross reference(s) "Microsoft.Office.Interop.InfoPath.View3.SelectNodes(Microsoft.Office.Interop.InfoPath.IXMLDOMNode,System.Object,System.Object)".

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Continuecovering

fixes #21

Awesome, thanks a lot @brunoproduit, tested it and it works perfectly :smile:


use upstream sigs.k8s.io/kube-storage-version-migrator

move to sigs.k8s.io/kube-storage-version-migrator

/hold
proof for https://github.com/openshift/library-go/pull/892

:+1:

/lgtm

this is proof.  I'll pick for the real
/close


[HOLD] Remove the things

Related PR: https://github.com/denali-js/denali-cli/pull/24
This PR removes:

the app/addon blueprints
the new command
the Command and Blueprint acceptance test classes
the unwrap utility

NOTE: this PR shouldn't be merged until a new version of denali-cli (with the changes in the above PR) has been released.

Does this need a new published version of CLI to be released, or can we merge and double check with master of both before we publish either?

@davewasmer I'm not sure....since the CLI has to be built none of the tests would pass until the CLI is either updated or we modify travis to build a master version of the CLI.
FWIW, I've got local dev builds of both the CLI and Denali with these changes in and it works as far as I can tell.

Ah, right. Ok, I'll try to release a CLI version in a bit here.


Release 19.9.0 ?

Release version seems skipped a lot.

Was just a typo in the release name, tag was correct and I have corrected the name.


[BUG] Appbar rendering issue

screen-capture (2).webm
Session is picked up after the page fully loads and therefore leading to a delay in the rendering of user image and wallet icon

Take an updated pull and make changes to dev

@cb7chaitanya assign me brother

Assigned @Ameerjafar

@cb7chaitanya for this can i add the loading till the session picked up.

@Ameerjafar  You have to take a new fork to work on this, please keep your work seperate, take a new fork as commit history has been rewritten

Ok sir @cb7chaitanya
On Thu, 19 Sep, 2024, 8:59 pm cb7chaitanya, @.***>
wrote:

@Ameerjafar https://github.com/Ameerjafar You have to take a new fork
to work on this, please keep your work seperate, take a new fork as commit
history has been rewritten
—
Reply to this email directly, view it on GitHub
https://github.com/code100x/tiplink/issues/172#issuecomment-2361346651,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AZE45SLZ7O2OSRYKV2EOTNTZXLUXNAVCNFSM6AAAAABONIYDP2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRRGM2DMNRVGE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@cb7chaitanya can i do skeleton loading for the appbar component.


Make PYTHONSTARTUP default to true

Related: https://github.com/microsoft/vscode-python/pull/24140
The default to enable shell integration in Python Terminal REPL via setting PYTHONSTARTUP environment variable has been set to false to target September release version of the Python extension.

After stable release, we could roll the default as true for pre-release users ONLY in October, make sure we are not breaking anyone's Python terminal REPL.

Eventually make default for PYTHONSTARTUP (enable shell integration for Python terminal REPL) as true for release/stable versions after some feedback in November.

This should be in experiment. So, we should be able to switch it after the experiment is 100% both insiders and stable.


[DW.Location.Android] TLocation Invoke error: method 'onLocationChanged'

On Android 13, Delphi 11.2, [TLocation] Crash
com.embarcadero.rtl.NativeDispatchException: Inkove error: method 'onLocationChanged(Ljava/util/List;)V' not found at...
https://quality.embarcadero.com/browse/RSP-39566?jql=text ~ "android 12 location"
After change "DW.Location.Android"
TLocationListener = class(TJavaLocal, JLocationListener)
  private
    FLocation: TLocation;
  public
    constructor Create(const ALocation: TLocation);
**// RSP-39566: Changed the following method to be an overload:
    procedure onLocationChanged(location: JLocation); cdecl;
// RSP-39566: Added the following method:
procedure onLocationChanged(locations: JList); overload; cdecl;**
    procedure onProviderDisabled(provider: JString); cdecl;
    procedure onProviderEnabled(provider: JString); cdecl;
    procedure onStatusChanged(provider: JString; status: Integer; extras: JBundle); cdecl;
  end;

// **implementation**
procedure TLocationListener.onLocationChanged(locations: JList);
var
  I: Integer;
begin
  for I := 0 to locations.size - 1 do
    onLocationChanged(TJLocation.Wrap(locations.get(I)));
end;

This worked. Thanks.

Pushed a fix for it.. thanks!

Excellent. Thanks!!!


Variables only used in @skip or @include directives are stripped from the query def

The following query:
query SomeQuery($assertion: Boolean!) {
  fieldTrue @include(if: $assertion)
  fieldFalse @skip(if: $assertion)
}

gets transformed to:
query SomeQuery {
  fieldTrue @include(if: $assertion)
  fieldFalse @skip(if: $assertion)
}

before being sent to the interface resulting in that kind of issue:
Variable "$assertion" is not defined by operation "SomeQuery".

This issue has been introduced with #518

I just upgraded to 0.4.13 and it seems the patch does not fully work, I'll take a look at it ...

Ok, no sorry, this is an another bug, will fill it!

Followup on #577


feat(loader): made interpolation after merge

What this PR does / why we need it:
Changed interpolation order, it used to interpolate for each config file separately, but now it interpolates after merge.
To be honest, I'm not sure it's a good idea, maybe it'll be better to add an option to control it, like --interpolate-after-merge
Which issue(s) this PR fixes:
Fixes https://github.com/docker/compose/issues/11925

This was my initial intent during compose-go/v2 refactoring, but this breaks when include or extends uses variables for target file/service. Need at least partial interpolation for those - I never took time to look into this, would you like to give it a try ?

but this breaks when include or extends uses variables for target file/service

could you please provide an example?

A typical use:
services:
  prod:
    image: a

  dev:
    image: a-dev

  app:
    extends: ${BASE:-prod}

@ndeloof pushed changes to interpolate include and extends before merging and interpolate everything after the merge, but I think it becomes too complicated.

Checking this PR again I went with an alternate implementation, reusing your test case: https://github.com/compose-spec/compose-go/pull/651
wdyt ?

Closing as https://github.com/compose-spec/compose-go/pull/651 has been merged


seldom crash

Thanks for taking the time for reporting an issue!
Describe what happened
crash
Session summary
 <IP_ADDRESS><PHONE_NUMBER>)
 7.0
 LG Stylo 3 Plus
 Apr 21, 2020, 11:57:00 PM
Stack trace

Fatal Exception: java.util.ConcurrentModificationException
java.util.LinkedHashMap$LinkedHashIterator.nextEntry (LinkedHashMap.java:411)
java.util.LinkedHashSet.<init> (LinkedHashSet.java:169)
kotlin.collections.CollectionsKt___CollectionsKt.toMutableSet (_Collections.kt:1452)
kotlin.collections.CollectionsKt___CollectionsKt.union (_Collections.kt:1467)
com.datadog.android.core.internal.data.file.FileReader.readNextFile (FileReader.kt:72)
com.datadog.android.core.internal.data.file.FileReader.readNextBatch (FileReader.kt:31)
com.datadog.android.core.internal.data.upload.DataUploadRunnable.run (DataUploadRunnable.kt:36)
android.os.Handler.handleCallback (Handler.java:751)
android.os.HandlerThread.run (HandlerThread.java:61)

Steps to reproduce the issue:
Describe what you expected:
Additional context

Android OS version:
Device Model:
Datadog SDK version:
Versions of any other relevant dependencies (OkHttp, …):
Proguard configuration:
Gradle Plugins:

Hey @alparp27 , thanks for submitting this issue, we'll look into it very soon.
Do you have anymore information on this issue (scenario, context, …) ?

Hey @alparp27 we figured it out where the problems might come from and we will let you know once a hotfix release will be available. Thank you again for flagging this !!

@alparp27 we will need one extra bit of information from you, can you please let us know the Datadog SDK version number for which you experienced the crash ? Thanks !!

1.3.0
On Thu, Apr 23, 2020 at 1:56 AM Marius Constantin<EMAIL_ADDRESS>wrote:

@alparp27 https://github.com/alparp27 we will need one extra bit of
information from you, can you please let us know the Datadog SDK version
number for which you experienced the crash ? Thanks !!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/DataDog/dd-sdk-android/issues/234#issuecomment-618274096,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHLCWC3SGQ7GJTQSNSD4YQTRN77EZANCNFSM4MOAOGBA
.

Thank you for all your effort @alparp27. The issue should be solved now in version 1.3.1.


[RFP]: SORA Influencer Marketing Treasury Proposal

Proposal Due Date
27/01/2024
Proposal Overview
The proposal outlines a comprehensive influencer marketing strategy aimed at addressing the current challenges faced in the SORA ecosystem. Please see below the sole iteration of the Request For Proposal, providing a more comprehensive level of detail.
SORA Influencer Marketing Proposal
Proposal Goals
Proposal goals are explained in the corresponding google document.
Scope of Work
Scope of work is explained in the corresponding google document.
Current Roadblocks and Barriers to Success
-Potential lack of collaboration between SSMG and targeted influencers.
-The depletion of the marketing budget due to slippage or volatility, and as a result, we are unable to achieve the level of work quality we envisioned.
Evaluation Metrics and Criteria
Evaluation metrics and criteria are explained in the corresponding google document.
Submission Requirements
The SORA marketing campaign should adhere to the outlined brief, demonstrating a clear alignment with the campaign objectives and statistical performance indicators.
Submission Method
Blockchain: Mainnet
Project Due Date
1/04/2024
Budget Amount
USD$105,500 equivalent in TBCD

Hello, please include the payment address, in this case cnWPbsypqHVdYUXYqMLntD7V8DoczJRsgYvphZzniV863NX9e  in the proposals for future reference


fix: print out the path where the image encode failed

FIX: When I have an image in my dataset that is too small in pixels, the training breaks down, but I can't find the path to that image. For example, an image with this pixel value: 122 x 63

Thank you!


ci: set test timeout to 20 minutes

I set the timeout for the test to 20 minutes because in the past the time it took for a successful CI test was about 10 minutes or less. (The default timeout of 6 hours is too long)
@mtshiba

Thanks!


ci: set job status of e2e tests to passed after 15m timeout

Motivation
Closes https://github.com/ChainSafe/lodestar/issues/5913
Description
E2E tests are sometimes stalling until timeout (6 hours) is reached but we know that after 15 minutes those should have passed already if there are no failed test cases. In this case, just set the job status to passed as there was likely no actual issue.

Scenario
Job status

all tests pass early
✔

after 15m timeout
✔

any test case fails
❌

Regarding the formatting changes, there were a lot of extra white spaces for no good reason, diff comes from auto-formatting.

:tada: This PR is included in v1.12.0 :tada:


New Task topic: Update API Objects in Place Using kubectl patch

This change is

@tengqm, Thanks for the review. I've addressed your comments in https://github.com/kubernetes/kubernetes.github.io/pull/4519/commits/3a4825e51c7d02b58fc7fb763f3ef25d649f5f51.


Add suggestThreadPoolSize param

Could you add suggestThreadPoolSize for server?
Or, if you could, add reactor.getThreadPool().adjustPoolsize(minthreads=some_param1, maxthreads=some_param2)?

Why would Daphne need this? It doesn't use threadpools.


Deprecated include of L.Mixin.Events: this property will be removed in future releases, please inherit from L.Evented instead. Error

Hi,
Can we have this warning removed? I would think that this is a relatively easy fix. Happy to create a PR for it if you'd prefer that.
Great work here man! +1

Deprecated include of L.Mixin.Events: this property will be removed in future releases, please inherit from L.Evented instead. Error

Sure, feel free. I will be on a pull request mode this period, so keep on mind update your branch.


Revert Click 6 regressions for chain and deprecate chain

With Click 6.0 we landed a change that was supposed to fix chain (https://github.com/pallets/click/commit/0a2919f34fcbc635d8530b4c5b60bf119b2bcedb). In the process it got worse and broke a bunch of non chain uses.
We should back out that change and instead deprecate chain. I do not believe there is a way to make chain work with the current argument parsing and execution behavior.
The reason for this is that click really wants to delegate the parsing of subcommands with the remainder of the command line but this breaks in the light of chaining. I would need to look into the exact implementation again but last time I investigated this it looked like a fundamental issue we cannot fix with the current design.

Is there a way to replicate chain functionality using traditional Click methods?

At least in 2015 an expert thought it was fixable :-)

It is currently not possible for chain commands to be nested.  This will be fixed in future versions of Click.

@jcrotts did some research and determined that the changes from 6 were already reverted and released in 6.1. After looking over the issues again, we've decided not to remove chain. Putting aside the broad issue of possibly rewriting the parser or pipeline, the open issues appear to be solvable, so we'll continue to address them for now.