Fix: Add extra guard to buffered writer

I saw this error in prod, it was interesting -- hadn't seen it before:
Traceback (most recent call last):
File "/harness/.venv/lib/python3.10/site-packages/dlt/pipeline/pipeline.py", line 272, in extract
self._extract_source(storage, source, max_parallel_items, workers)
File "/harness/.venv/lib/python3.10/site-packages/dlt/pipeline/pipeline.py", line 818, in _extract_source
extract_id = extract_with_schema(storage, source, source_schema, self.collector, max_parallel_items, workers)
File "/harness/.venv/lib/python3.10/site-packages/dlt/extract/extract.py", line 171, in extract_with_schema
extractor = extract(extract_id, source, storage, collector, max_parallel_items=max_parallel_items, workers=workers)
File "/harness/.venv/lib/python3.10/site-packages/dlt/extract/extract.py", line 140, in extract
_write_item(table_name, pipe_item.item)
File "/harness/.venv/lib/python3.10/site-packages/dlt/extract/extract.py", line 81, in _write_item
storage.write_data_item(extract_id, schema.name, table_name, item, None)
File "/harness/.venv/lib/python3.10/site-packages/dlt/common/storages/data_item_storage.py", line 26, in write_data_item
writer.write_data_item(item, columns)
File "/harness/.venv/lib/python3.10/site-packages/dlt/common/data_writers/buffered.py", line 85, in write_data_item
if self.file_max_items and self._writer.items_count >= self.file_max_items:
AttributeError: 'NoneType' object has no attribute 'items_count'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/harness/.venv/bin/revops", line 6, in <module>
sys.exit(app())
File "/harness/.venv/lib/python3.10/site-packages/click/core.py", line 1130, in __call__
return self.main(*args, **kwargs)
File "/harness/.venv/lib/python3.10/site-packages/typer/core.py", line 778, in main
return _main(
File "/harness/.venv/lib/python3.10/site-packages/typer/core.py", line 216, in _main
rv = self.invoke(ctx)
File "/harness/.venv/lib/python3.10/site-packages/click/core.py", line 1657, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/harness/.venv/lib/python3.10/site-packages/click/core.py", line 1688, in invoke
rv.append(sub_ctx.command.invoke(sub_ctx))
File "/harness/.venv/lib/python3.10/site-packages/click/core.py", line 1404, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/harness/.venv/lib/python3.10/site-packages/click/core.py", line 760, in invoke
return __callback(*args, **kwargs)
File "/harness/.venv/lib/python3.10/site-packages/typer/main.py", line 683, in wrapper
return callback(**use_params) # type: ignore
File "/harness/revops/cli.py", line 134, in _
extract_stage(
File "/harness/revops/engine/execution.py", line 127, in extract_stage
info = pipeline.extract(data_source.source)
File "/harness/.venv/lib/python3.10/site-packages/dlt/pipeline/pipeline.py", line 103, in _wrap
step_info = f(self, *args, **kwargs)
File "/harness/.venv/lib/python3.10/site-packages/dlt/pipeline/pipeline.py", line 77, in _wrap
rv = f(self, *args, **kwargs)
File "/harness/.venv/lib/python3.10/site-packages/dlt/pipeline/pipeline.py", line 63, in _wrap
return f(self, *args, **kwargs)
File "/harness/.venv/lib/python3.10/site-packages/dlt/pipeline/pipeline.py", line 137, in _wrap
return f(self, *args, **kwargs)
File "/harness/.venv/lib/python3.10/site-packages/dlt/pipeline/pipeline.py", line 281, in extract
raise PipelineStepFailed(self, "extract", exc, ExtractInfo()) from exc
dlt.pipeline.exceptions.PipelineStepFailed: Pipeline execution failed at stage extract with exception:
<class 'AttributeError'>
'NoneType' object has no attribute 'items_count'

@z3z1ma thx for the report. honestly this should happen because the writer class makes sure that when _file is opened, there's also corresponding _writer. I'll try to reproduce it first because there may be a deeper problem

@rudolfix yes I'm having a hard time making a test case that reproduces the behavior and looking at the code, at least on the surface -- I don't see anything that immediately stands out.
But the error had occurred consistently in production across 3+ invocations I think. So the conditions are not transient, they are somewhat reproducible -- but identifying the code pathway is hard. Doesn't make sense. 😅

fixed in #403


Fixed typo in package.json description

straigntforward > straightforward

Hey! Would you mind fixing the conflicts and breaking this out into separate feature-PRs? There's a lot going on here.

Ah, forgot about all those commits affecting this PR, I'll break those changes up and add stuff one thing at a time!


is there any way to avoid mismatch between autoawq vs llm-awq at cuda level?

https://github.com/casper-hansen/AutoAWQ/blob/main/awq_cuda/quantization/gemm_cuda.h
https://github.com/mit-han-lab/llm-awq/blob/main/awq/kernels/csrc/quantization/gemm_cuda.h
I would have expected in autoawq to have
gemm_forward_cuda same as in llm-awq (hence 2 => "regular")
gemm_forward_cuda become gemm_forward_cuda_old ?
it just creates mismatchs when one compiles the kernels with one toolkit and use one or the other as frontend.

We do not try to have compatibility with llm-awq. We have however contemplated switching the name of the CUDA engine away from awq_inference_engine. I have already renamed the new kernel which has a v2 after it for distinction from the original.

I get it but at the moment there is a conflict with
awq_inference_engine. gemm_forward_cuda() since they don't have the same number of args.

It’s something that will change in the future. You are welcome to create a PR to resolve this. I am fully focused on Mixtral currently

Closing this for now as the question was answered.


Don't connect server when set proxy to computer

My computer set host,eg:http://test.qk.o2o.com.  So, I set proxy throw device wifi setting. i found don't connect server,And i set proxy thorw setProxy(host,port).But can't connect server sometimes. Why i don't know ?

Issues in this project are meant to track bugs and feature requests, not general programming questions.


Use C++ parser via speedy-antlr-tool

The antlr4 C++ runtime parser is supposedly faster than the Python runtime one.
This PR changes the layout of the repository, and adds the source files of the antlr4 C++ runtime.
Both C++ and Python generated file sources are now outside of the distributed module directories, and are only regenerated by manually triggering the src/grammar/build.py script.
The C++ parsers are wrapped for Python via speedy-antlr-tool and added into the build via a new setup.py defining the binary modules.
The new parsers do not expose all antlr4 features, e.g., the named context elements are present in the C++ sources and the Python implementation, but the automatic wrapping does not expose them. Fortunately, all use-cases in the mccode-antlr visitors could be changed to use the functional forms like ctx.params → ctx.expr().
The build system is augmented to use CIBuildwheel for Python 3.8-3.13 on Linux (manylinux and musllinux), macOS (Arm and Intel) and Windows.

At the moment, binary parsers are not measurably faster than the Python implementation from antlr4, and are not worth the extra build and maintenance efforts.
It may be worth returning to this in the future, however.


[DOCS] add license

Description
I want to add license in repo.Please assign this issue to me
Screenshots
No response
Additional information
No response

Please make sure to customize... This project is part of startup!


az backup policy create --workload-type {} KeyError: 'AzureFileShare'

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az backup policy create
Errors:
'AzureFileShare'
Traceback (most recent call last):
Temp\pip-install-7cl6xofh\knack\knack\cli.py, ln 215, in invoke
azure\cli\core\commands\__init__.py, ln 631, in execute
azure\cli\core\commands\__init__.py, ln 695, in _run_jobs_serially
azure\cli\core\commands\__init__.py, ln 688, in _run_job
Local\Temp\pip-install-7cl6xofh\six\six.py, ln 703, in reraise
azure\cli\core\commands\__init__.py, ln 665, in _run_job
azure\cli\core\commands\__init__.py, ln 324, in __call__
azure-cli-core\azure\cli\core\__init__.py, ln 574, in default_command_handler
azure\cli\command_modules\backup\custom_base.py, ln 42, in create_policy
azure\cli\command_modules\backup\custom_wl.py, ln 206, in create_policy
KeyError: 'AzureFileShare'

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az backup policy create --backup-management-type {} --name {} --policy {} --resource-group {} --vault-name {} --workload-type {}

Expected Behavior
Environment Summary
Windows-10-10.0.19041-SP0
Python 3.6.6
Installer: MSI

azure-cli 2.5.1 *

Additional Context
If i try to use 'az backup policy create' without '--workload-type', i get output "Please provide workload type."

backup

@DoppoM : Just wanted to confirm: Are you passing the policy definition as a JSON encoded object?

@pvrk,  of course, I use .json file in cmdlet
az backup policy create `
--backup-management-type AzureIaasVM `
--name $policyName `
--policy ./vm-backup-policy.json `
--resource-group $newRecoveryServicesVault.resourceGroup `
--vault-name $newRecoveryServicesVault.name

@DoppoM : Thanks for the clarity. Will come back on this. @hiaga : Let's take a look and respond.

@DoppoM Currently az backup policy create command doesn't support creation of IAAS VM policy. We have an action item at our end and working actively for supporting this.

@mepand  thx for feedback

@DoppoM  az backup policy create command now supports creation of IAAS VM policy. Since there is no further action pending from our side, closing this issue. Please feel free to reach out incase of any query.

@DoppoM  az backup policy create command now supports creation of IAAS VM policy. Since there is no further action pending from our side, closing this issue. Please feel free to reach out incase of any query.


_Request to add a new tutorial "aberrant_pi3k_pathway_analysis"

With this PR we are introducing a tutorial to measure aberrant pathway activity in TCGA cancer types. This tutorial is based on papaa tool suite (https://github.com/nvk747/papaa) that can be downloaded from the main tool shed. In the tutorial aberrant_pi3k_pathway analysis we describe a machine learning-based approach using various tools in papaa to generate a PI3K_OG (oncogene) classifier that classifies tumor samples based on pi3k aberrant activity. The tutorial can be run using a pre-configured Docker-based galaxy instance with papaa tool suite, necessary datasets, tutorials, and PI3K_OG workflow installed.
Install and run the docker with the following commands.
Pull the docker image: docker pull nvk747/galaxy_papaa:0.1.9 and run the docker container: docker run -p 8888:80 --detach nvk747/galaxy_papaa:0.1.9

Thanks a lot @nvk747, looks good! Sorry for the late response, it has been a bit busy lately, I will try to review this soon. And maybe @anuprulez would also like to have a look this as our brand new topic maintainer? :)

Thanks a lot @nvk747, looks good! Sorry for the late response, it has been a bit busy lately, I will try to review this soon. And maybe @anuprulez would also like to have a look this as our brand new topic maintainer? :)

Thank you @shiltemann

Thank you @shiltemann

@anuprulez the docker is running. it will take some time for the docker to
install all packages.Please wait for few min and recheck at the web link.
Let me know if still problem .
Regards
Vijay
On Tue, Feb 9, 2021 at 1:09 PM Anup Kumar<EMAIL_ADDRESS>wrote:

@anuprulez commented on this pull request.
In topics/statistics/tutorials/aberrant_pi3k_pathway_analysis/tutorial.md
https://github.com/galaxyproject/training-material/pull/2261#discussion_r573117195
:

+> Let's learn how to install this tutorial using Docker with galaxy, and how to download the datasets from Zenodo :
+>
+> 1. TOC
+> {:toc}
+>
+{: .agenda}

+# Pre-installed tutorial tools, datasets and workflows from the docker image
+> An efficient way to install and run the tutorial using papaa tools is available on docker based galaxy instance that has pre-installed papaa tool-suite as papaa under tools section. Additionally this local galaxy instance comes with datasets and workflow for generating PI3K_OG classifier. Instructions to run the docker image is below.
+
+> ### {% icon hands_on %} Hands-on: Tutorial for galaxy docker container installation and running the workflow:
+> 1. Pulling the docker image from docker hub: Open a terminal and type the following command:
+>       docker pull nvk747/galaxy_papaa:0.1.9
+> 2. For running the docker container use the following command :
+>       docker run -p 8888:80 --detach nvk747/galaxy_papaa:0.1.9
+> 3. Open the following http://localhost:8888 in your web browser.
I followed the steps mentioned above to pull the docker image but unable
to see anything at http://localhost:8888
Do I miss anything?
[image: papaa_tutorial]
https://user-images.githubusercontent.com/3022518/107407353-d9ed0900-6b09-11eb-9f68-94afd7294442.png
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/galaxyproject/training-material/pull/2261#pullrequestreview-586848204,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJMPZMCQPR4CHHLGF4SKTN3S6F25RANCNFSM4WEWLWRQ
.

--
*N. Vijay Krishna; **PhD *
Post-Doctoral Fellow
Dr. Daniel Blankenberg group
Genomic Medicine Institute
Lerner Research Institute
Cleveland Clinic
Cleveland USA

@nvk747 I could run Galaxy inside the docker container following the steps mentioned in the tutorial. I tried to upload datasets (20 of them) and the Galaxy uploader has been running for over 1.5 hrs. The total size of the datasets (in Zenodo) is around 3.5 GB. Do you also need this much time to upload the datasets? My internet connection seems to be ok (>100 Mbps download speed). I am not sure if this makes sense, but is it possible to package all these datasets in a Galaxy history inside the docker container as well?

@anuprulez I am sorry the datasets from TCGA are big, yes we did add them
to the docker container, you need to pull them from the data library in the
docker galaxy instance. (library->GTN-Material->PAPAA:PanCancer Aberrant Pathway Activity Analysis->DOI: 10.5281/zenodo.4306639#.X9FJF-lKgZE). These datasets are added while
building the docker.
we did provide the instructions in the tutorial for adding from the data
library.
I am sorry for the inconvenience of our tutorial and thanks for making it
better.
regards
vijay
On Wed, Feb 10, 2021 at 5:45 AM Anup Kumar<EMAIL_ADDRESS>wrote:

@nvk747 https://github.com/nvk747 I could run Galaxy inside the docker
container following the steps mentioned in the tutorial. I tried to upload
datasets (20 of them) and the Galaxy uploader has been running for over 1.5
hrs. The total size of the datasets (in Zenodo) is around 3.5 GB. Do you
also need this much time to upload the datasets? My internet connection
seems to be ok (>100 Mbps download speed). I am not sure if this makes
sense, but is it possible to package all these datasets in a Galaxy history
inside the docker container as well?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/galaxyproject/training-material/pull/2261#issuecomment-776619339,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJMPZMDEECORJSQN5VTL3XDS6JPU3ANCNFSM4WEWLWRQ
.

--
*N. Vijay Krishna; **PhD *
Post-Doctoral Fellow
Dr. Daniel Blankenberg group
Genomic Medicine Institute
Lerner Research Institute
Cleveland Clinic
Cleveland USA

@nvk747 Thanks, no worries :)
I could import the datasets from the data library and could run the workflow but had to stop it because of other intensive programs running in my laptop.

@anuprulez , in our case the training is done with a lot of samples from
TCGA. The transcriptome and mutation datasets are bigger. I cant reduce
that.
I had also made the changes you asked for, just let me know If they are ok
or need to change them or add some more information.
Thanks once again for taking a look at the tutorial.
regards
vijay
On Wed, Feb 10, 2021 at 11:43 AM Anup Kumar<EMAIL_ADDRESS>wrote:

@nvk747 https://github.com/nvk747 Thanks, no worries :)
I could import the datasets from the data library and could run the
workflow but had to stop it because of other intensive programs running in
my laptop.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/galaxyproject/training-material/pull/2261#issuecomment-776847021,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJMPZMFO5PHN5YMCZC5G6MTS6KZUFANCNFSM4WEWLWRQ
.

--
*N. Vijay Krishna; **PhD *
Post-Doctoral Fellow
Dr. Daniel Blankenberg group
Genomic Medicine Institute
Lerner Research Institute
Cleveland Clinic
Cleveland USA

It looks ok to me :+1:
@shiltemann @nvk747

Thanks for reviewing @anuprulez! And sorry for the delay @nvk747, things got a bit busy with Smorgasbord, but will try to look at this today for any final touches.
Maybe I missed some conversation here, but is it needed to keep the Docker? The GTN framework will automatically produce a docker for every topic including all tools, workflows, datasets etc, unless there is more you need in your Docker? Otherwise please remove the docker parts from the tutorial, people can use the GTN topic docker or one of the supporting Galaxy servers to run the tutorial.
This looks great, thanks for putting so much effort in!

@shiltemann  hi, Saika, my apologies for the delayed reply, I had to go to my home country and got stuck with some work. Regarding the current tutorial changes: I and dan felt the additional docker container can be still useful for those who want to use these tools as standalone. Although users use a long list of parameters with default values, we still want them to be visible for performing additional benchmarking steps so we will not hide them. please let me know if you have any other concerns, otherwise can you kindly merge the above tutorials.

Although users use a long list of parameters with default values, we still want them to be visible for performing additional benchmarking steps so we will not hide them.

Hi @nvk747, I'm afraid this doesn't conform to the GTN style conventions. Tutorials are for learners, many of whom are not Galaxy power users. Unless you're describing what each individual parameter does, then we need to remove the default values because they can be overwhelming and cause confusion for learners.
Other tutorials in the GTN only list changed parameters; if they follow this tutorial it might make them believe that every parameter needs to be changed and this can be misleading.
Lastly, these tutorials are not structured data in any way, they cannot really be used for any automated benchmarking. The workflows could, and still retain every parameter!
Would you consider using those for any benchmarking and then updating the tutorial to list only non-default parameters.

@shiltemann Thanks for the quick reply. Yes, for the given tutorial, these options need not be changed by users, nor additional benchmarking analysis. So I agree with your points; I will make respective changes and update you on that.

Thanks so much @nvk747!

@shiltemann @hexylena, can you please take a look at the changes? Let me know if I have to change anything; otherwise, can you merge this tutorial. Thanks again for all the help.


Rethink the definition of a packet

What we call a packet at the current moment is fixed over time and for every component.
That approach is too both too restrictive and wrong. Packet has to evolve over time and each component is contributing to those changes. At the end (after a handler publish it to an application), a packet should be way more than it was when received by a router.

The remark also stands for registrations.
Looking at the broker storage, an entry is defined the following way:
type brokerEntry struct {
	Id      string
	NwkSKey lorawan.AES128Key
	Url     string
}

which in itself almost implies an http protocols (through the Url attribute). The abstraction should be raised up a little bit to let the adapter decide completely how to transfer a message given an option param.

done cde75155a20e132991af681a3c6d27de8b6251a3.


Fix/visual scroll

Coverage increased (+0.04%) to 90.826% when pulling 43ec8bf773ae7b63e9212e9d3d4431fa31365f51 on fix/visual_scroll into ead99db345ec26c16a3f52e0166805c0119c85a5 on master.

Coverage increased (+0.04%) to 90.826% when pulling 43ec8bf773ae7b63e9212e9d3d4431fa31365f51 on fix/visual_scroll into ead99db345ec26c16a3f52e0166805c0119c85a5 on master.


Ends support for Trace/AgentStat V1 tables

Remove puts to Trace/AgentStat V1 tables in collector.
Deprecate reads from Trace/AgentStat V1 tables in web.
Remove legacy APIs for querying AgentStat charts in web.
resolves #2908

Codecov Report

Merging #2910 into master will increase coverage by 0.16%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2910      +/-   ##
==========================================
+ Coverage   37.02%   37.18%   +0.16%
==========================================
  Files        1821     1799      -22
  Lines       61858    61038     -820
  Branches     8705     8586     -119
==========================================
- Hits        22904    22699     -205
+ Misses      36545    35952     -593
+ Partials     2409     2387      -22

Impacted Files
Coverage Δ

...dao/hbase/stat/v1/HbaseSampledResponseTimeDao.java
0% <ø> (ø)
:arrow_up:

.../pinpoint/web/dao/hbase/stat/v1/HbaseJvmGcDao.java
0% <ø> (ø)
:arrow_up:

.../web/dao/hbase/stat/v1/HbaseSampledCpuLoadDao.java
0% <ø> (ø)
:arrow_up:

...oint/web/dao/hbase/stat/v1/HbaseDataSourceDao.java
0% <ø> (ø)
:arrow_up:

...inpoint/collector/receiver/UdpDispatchHandler.java
33.33% <ø> (ø)
:arrow_up:

...ao/hbase/stat/v1/HbaseSampledJvmGcDetailedDao.java
0% <ø> (ø)
:arrow_up:

...dao/hbase/stat/v1/HbaseAgentStatDaoOperations.java
0% <ø> (ø)
:arrow_up:

...inpoint/web/dao/hbase/stat/v1/HbaseCpuLoadDao.java
0% <ø> (ø)
:arrow_up:

.../dao/hbase/stat/v1/HbaseSampledActiveTraceDao.java
0% <ø> (ø)
:arrow_up:

...b/dao/hbase/stat/v1/HbaseSampledDataSourceDao.java
0% <ø> (ø)
:arrow_up:

... and 22 more

Continue to review full report at Codecov.

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


Python 3.8 support for native code debugger

We're missing some basic switch case statements. Beyond that, don't know how much has changed since 3.7 in the affected internal structures.

Updated in: #5823


South Africa and primary culture

Is it possible to make it so that South Africa doesn't have Anglo-African as its primary culture even though Britain never colonized South Africa?

South africa, if it existed at conversion time, will have that primary culture that it had in EU4. If it was released during vic2, then it'll probably default to vanilla files.

Seems like the convertor switches it's vanilla culture of British to the South African neoculture from British ("Anglo-African"). I kinda wish that there would be some sort of event or decision at game start for whatever nation controls the region to change South Africa's culture/religion to the appropriate neoculture/religion (if South Africa doesn't already exist), but I have no real modding experience so I don't know how possible it is to do that. Sorry for focusing on this, I've noticed the AI tends to release them at the start of vic2 so it's been a bit of a pet peeve of mine.

Solved by #669


RuntimeError: a leaf Variable that requires grad is being used in an in-place operation

Hi,
I am playing with the tutorials (e.g., tutorials.small_molecule.affinity_active.ipynb) and encountered the error as in the attached screenshot. I'm wondering if it is a bug or there is something with my installation. I installed the latest stable version as well as the dev one, both gave the same error. I used a conda env with Miniforge for apple silicon and python 3.9.

Thank you,
TB

Updated: Tested on Colab and similar errors occurred.

Hey there,
What version are you using? This bug was introduced in a previous version, but was fixed in the 1.3 release. I realize I forgot to bump the internal package number, so mrl.__version__ returns 1.2 for both version 1.2 and 1.3, but your pip/conda install should show the correct version number.
I just ran the small molecule affinity colab notebook as is with version 1.3 installed and it worked for me.

Hi,
It's weird. I have the version 1.3 installed and still have the same problem. I have PyTorch 1.12.1 + python 3.9

Figured it out. The batch state loss is initialized as a leaf variable. When using a GPU, moving the variable to the GPU removes the leaf flag so everything works fine on the GPU, but this error pops up on CPU. I'll try patch this in the next few days. For now a quick fix is to update the BatchState class at line 474 of callback.py to the code below
class BatchState(SettrDict):
    def __init__(self):
        super().__init__()

        self.samples = []
        self.sources = []
        self.rewards = to_device(torch.tensor(0.))
        self.loss = torch.tensor(0., requires_grad=True)
        self.loss = to_device(self.loss.clone())
        self.latent_data = {}


Modify grow option

Add zeek grow option
Modify -g true to -g

Close: #191

Codecov Report
Base: 5.73% // Head: 5.71% // Decreases project coverage by -0.01% :warning:

Coverage data is based on head (7a669dc) compared to base (4c31c01).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff            @@
##            main    #200      +/-   ##
========================================
- Coverage   5.73%   5.71%   -0.02%
========================================
  Files         19      19
  Lines       3228    3236       +8
========================================
  Hits         185     185
- Misses      3043    3051       +8

Impacted Files
Coverage Δ

src/controller.rs
0.00% <0.00%> (ø)

src/main.rs
0.00% <0.00%> (ø)

src/producer.rs
2.43% <0.00%> (-0.07%)
:arrow_down:

src/zeek.rs
0.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Squash commits skip DCO checks

Steps to reproduce:

Create a repo with DCO bot enabled, branch protection on for the master branch with 'Require status checks to pass before merging' enabled and DCO status check required enabled before merged.
Add a new file to the repo with a DCO signoff. It will automatically force the user to create a new branch and pull request.
In that pull request, the DCO status check should be green or passed.
Choose to do a 'Squash and Merge' for the pull request ( see below ).

In the commit description, remove any Signed-Off by lines. Then click 'Confirm Squash and Merge'.

Expected behavior: Commit is blocked due to lack of DCO signoff
Actual behavior: Commit is successful, and the commit message has no DCO signoff

@brianwarner @tykeal @caniszczyk - Can you confirm the same on your repos?

@jmertic I had a quick look into it, but my understanding is that once you get to the point of merging, there are no more opportunities to fail a status check (which is what enables Probot DCO to block a merge in the first place).  Actions can run, but I think that happens after the merge is already complete.
My initial take is that it's one of those things where with effort or malice it's possible to get around the tooling, but most people are going to mash the green button and not proactively strip the signoffs.  I've encountered a few other corner cases like this, none of which are major blockers but which could allow a determined individual to work around a legit DCO signoff.
So I definitely understand the issue, but don't see a way to avoid it just yet (but maybe @hiimbex, who is much smarter than me, knows).
That said, it's hacktastic, but I suppose it would be possible to have a second Action run that reverts a commit which sneaks through?  I think that might be out of the scope of Probot DCO proper, though.

@brianwarner I do agree we are likely running into a GitHub limitation here. That all said, seeing more and more opportunities for bypassing checks for DCO signoffs ( like what's attempting to be solved by https://github.com/probot/dco/issues/119 ) is problematic.
Maybe the answer here is being proactive on scanning repos for missing DCO signoffs and cleaning up after the fact ( like what is done in https://github.com/jmertic/dco-org-check ).

dco-org-check is fine... but if you rely on that for an operational repo and not one you're taking in then you're going to be constantly chasing this issue.
I've raised the issue directly with GitHub (during one of our customer calls so I don't have an issue to actually point at) that DCO needs to be a first class citizen. Probot DCO is IMO a stop gap / best effort of DCO enforcement until it's supported at the upload / PR requirement level and not left as a validation check.

Also, @jmertic I have to agree with @brianwarner on this. I don't think Probot DCO is going to be able to stop this sort of behavior. If someone is willfully making these changes and they have the needed rights to merge the change, we can't stop them as long as DCO is not truly something that is enforceable at the repo level and not done via CI style checks.

Yep - sounds like it's a limitation of GitHub. It would be good to document this behavior at least if that makes sense @hiimbex

Sorry to resurrect this. @tykeal did you ever get anything concrete from GitHub on this topic?

@mynameistechno, DCO is still not a first class citizen in GitHub. The only way to avoid this particular issue is if DCO enforcement is something that done as a pre-commit hook. Since us common peasants can't create or mange those we're out of luck. We raise this with our GitHub reps regularly that this is something we need to be a native enforcement option and not a bot enforcement but haven't had any movement :(

Thanks @tykeal for the reply. I'll also add it to the TODO group's GitHub wishlist.

I agree with the previous conclusions that:

fully addressing this issue depends on Github support for DCO, and
that a determined bad actor can find a way to work around the DCO.

But I do wonder if the process could be improved slightly by improving the suggested squash-and-merge commit message to provide instructions to leave at least one DCO signoff in the commit message. (I don't know if dcoapp has control over Github's autopopulated commit message suggestion, though.)
When a contributor goes to complete a squash-and-merge, they are confronted with what may seem like an intimidating and repetitive list of commit messages and DCO signoffs. Such contributors may not fully understand the mechanics of the DCO and/or they may not fully understand that the commit message that they are creating will become the only record of their contribution when the feature branch is deleted.
For example, below is the autopopulated contents of my commit message when I go to squash-and-merge one of my PRs.  While performing such cleanup, a well-intentioned contributor may accidentally remove all the DCO signoffs, including the last one.
Does dcoapp control the addition of the final DCO signoff (the one after ---------)? If so, could dcoapp add a message like "Important: pease leave the DCO signoff below this line in your final commit message."? Doing so could help well-intentioned contributors not to make a mistake.
* Rename web app route IDs

Signed-off-by: Carl Gieringer<EMAIL_ADDRESS>
* Convert ContextTrail to TS

Signed-off-by: Carl Gieringer<EMAIL_ADDRESS>
* Update ContextTrailItem to be Connecting-Entity-based

Signed-off-by: Carl Gieringer<EMAIL_ADDRESS>
* Factor out context trail fetch into a provider

Signed-off-by: Carl Gieringer<EMAIL_ADDRESS>
* PR edits and fix creating justifications with extant bases

Signed-off-by: Carl Gieringer<EMAIL_ADDRESS>
* Fix checks

Signed-off-by: Carl Gieringer<EMAIL_ADDRESS>
---------

Signed-off-by: Carl Gieringer<EMAIL_ADDRESS>

I think this is largely handled with the native DCO support in Github, right?


Convert modules to using bp_proc_params, rather than passing individual parameters

Local parameters in module signature need to be cleaned up.
vaddr_width_p and vaddr_width_lp exist in the same parameter list? -- what is the difference?
For parameters that are not required to set the widths of inputs or outputs to modules, they should be in the body of the module.
https://github.com/black-parrot/pre-alpha-release/blob/3e97c60fe6b7129871d98436f8cfb147c8695dc0/bp_fe/src/v/bp_fe_top.v#L35

@spikemar @zaazad

For parameters that are not required to set the widths of inputs or outputs to modules, they should be in the body of the module.

Should I add this to the code aesthetics doc? I personally don't follow this rule and declare every constant in the header

Good suggestion. I added it to BSG SystemVerilog Coding Guidelines
under Parameter Consistency.
I believe it does improve the code readability. I didn't see too many cases where the be has localparams defined in the header that are not used.

Done!

Done.

This is an extension of the previous issue.  Basically, anything which declares structs based on the proc_params should be using the enum rather than the values directly. Fewer lines of code, less bug potential, cleaner looking...


Update deps and peer deps for React v16

Dependencies, but more importantly peer dependencies for react and react-dom need to be updated for React v16:

Updated in version 1.1.0


Add archipelago library & bind heartbeat to setting position in archipelago

Done in https://github.com/decentraland/catalyst/pull/523


Alert: A possible vulnerability to SQL Injection missing MITRE Tactics value

Alert: A possible vulnerability to SQL Injection
Is that different sources for this alerts (SQL.VM/SQL.DB/SQL.MI/SQL.QW) can be considered as MiTRE Tactics: " PreAttack" and something else?
or all of them are "PreAttack" ?
Alerts in Security center are showing as PreAttack but not in official documentation I wonder if this is just a missing or multiple values.

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

ID: a2eb1ae9-1cfc-0dd0-a055-79ae32b62a6d
Version Independent ID: 66ce0f69-16aa-c1f8-5163-7cc5392a3399
Content: Reference table for all security alerts in Azure Security Center
Content Source: articles/security-center/alerts-reference.md
Service: security-center
GitHub Login: @memildin
Microsoft Alias: memildin

Thanks for the question! We are taking a look into this and will get back to you soon.

@vmonge Thanks for the feedback. We will engage the content development team for further investigation, they will verify and perform necessary changes in the document as needed.

Hi @vmonge, thanks for the feedback and for taking the time to help us improve the docs.
I've updated this line in the table. The changes will go live in the coming few days.
I'm going to close this issue, but feel free to comment again here or open a new one if you have additional requests.
#please-close

#please-close


Multiple Parallel chains

To assess convergence to the true distribution, it is useful to run several chains from different start points.  At the moment, this requires running the model multiple times in parallel.
There are two related parts of this issue:

conceptually support multiple chains in the API
use multiprocessing of the like to parallelize

Completed in pull request #30 - more work to be done on making it pretty


The NPM script 'start' exited without indicating that the Angular CLI

https://stackoverflow.com/questions/52724294/how-to-solve-the-npm-script-start-exited-without-indicating-that-the-angular-c
i posted here today .. but no one reply my error.. please check
https://stackoverflow.com/questions/52714606/an-unhandled-exception-occurred-while-processing-the-request-in-netcore
i am facing these error on my different machine.... i spend 9 hours in this issue but still pending both of these

Thanks for contacting us. We're closing this issue as there was no community involvement here for quite a while now.


documentation non-existent

code is not really documented or commented.

i can work on it.
so can you assign the task to me?

sure!


WMI filters for Windows 10

The article says:
•Windows 10
•Windows Server 2016
But the article doesn't contain any examples for Windows 10 nor Server 2016, can this be added please?

@alexverboon Can you list the file where you're seeing this?

Hi, here's the link
https://technet.microsoft.com/en-us/itpro/windows/keep-secure/create-wmi-filters-for-the-gpo
It only shows Windows 8 and server 2012 examples
Cheers
Alex

Thanks for the suggestion Alex. I changed the examples to Windows 10 and Windows Server 2016.


Preview notification banner options

Setting up a quick preview for tech docs review of notification banner Nunjucks options.

You can preview this change here:
Built with commit 022aad8a9c87655f8be74ed3bf4041816196bbb5
https://deploy-preview-1380--govuk-design-system-preview.netlify.app


fix source orbit enablement for Migrate Source

Migrate Source was missing the Clean up tab because the sourceOrbitEnabled() was returning false.
This has been fixed.

Still not seeing the Clean Up Tab

Hi Irfan, I would have to merge the PR and release it for you to get it from the Marketplace
In the meantime, the branch could be checked out and a vsix built and loaded into VS Code

Hi Irfan, I would have to merge the PR and release it for you to get it from the Marketplace In the meantime, the branch could be checked out and a vsix built and loaded into VS Code

I was able to get this result by checking out the branch and Running the Extension locally.
This achieves the same result, I believe


New name! Propose and vote in your favourite! Date of decision is Dec 30, 2017

It has dawned on us that IPFS Station is not the best name for this project. IPFS Station doesn't communicate what this repo is about and it also doesn't get better when we announce an update on twitter, IRC or Reddit about the latest IPFS Station.
With this in mind and similar to what we did to find a name for IPFS Compation, we open this issue to welcome name proposals and encourage everyone to vote on what they like the most. We will use the proposals and that feedback to pick the new name.
Please submit your proposals by creating a separate comment per proposal and give votes with 👍 👎 on that comment.

Keep IPFS Station

IPFS App

Voted 👎 on IPFS App because it feels a tad to generic. IPFSdroid is also an IPFS app, and in a slightly different context, any app built with IPFS is an IPFS app.

IPFS Desktop

IPFS Commander

I also want to provide another perspective cf. @lgierth that many Mac apps are Something.app (e.g., Calculator.app, Calendar.app) but outside of built-in Apple apps, I rarely see it used (e.g., one doesn't say, "VLC.app" . IPFS Desktop is good and expresses the desktop interface...even though Station is a task-/menu-bar based interface.


Button Group component (new)

Description
A Button Group is a collection of Buttons aligned side by side with no space between them. This can be used to create a collection of similar actions, to save space, or to respond to different size containers.
Use cases under consideration

mixing colored buttons for action differentiation
adding dropdown menus for additional options
a responsive experience to handle smaller containers
icon buttons
checkbox and radio group selections

Documentation
Basic

Normal Button design options are available to Button Groups as well
Available for each type of button
Group together similar types of actions that a user can do
Can be used to maximize UI space

Mixed Classes

action types can be mixed in a Button Group
we recommend that primary actions be the first in a group, followed by secondary actions
we recommend that warning actions be the last in a group

Icons

icons used in Button Group will have minimum button width of 72px
flat Buttons have no minimum width. There is only 24px space between icons
flat Button Groups can Action Blue or Grey. Grey is used with Grid and Table actions

Dropdowns

used when a button has a set of actions related to it
caret is to the right of the text or icon
the dropdown will align to the left-most edge of the button or caret button in Split

Overflow

used for preserving space when many buttons are present
can be mannually configured or set to automatically show based on space
can be configured “x” number of buttons and “y” number of actions in the dropdown

Multiple Groups

Button Groups next to one another
use when you want similar actions to be grouped together and separated from others
uses normal spacing between Buttons (12px)
we recommend starting with primary actions followed by secondary actions

Checkbox

use when a small list of options can be selected from, similar to the Checkbox component
blue indicates an option is selected, white (outline) indicates an unselected option
user can click the button to select, and click again to deselect
we recommend that an option label use 1-3 words
can be configured with preselected options

Radio

use when selecting one option from a small list of options, similar to the Radio component
blue indicates an option is selected, white (outline) indicates an unselected option
selecting an unselected option, will deselect the previously selected option
we recommend that an option label use 1-3 words
can be configured with a preselected option

References

https://v4-alpha.getbootstrap.com/components/button-group/
https://v4-alpha.getbootstrap.com/components/buttons/#checkbox-and-radio-buttons

Original request - #240

Closing for now as a duplicate of the original request.

Updated with new documentation and suporting images

I have query on the implementation/usage of this Button Group.
If this is applied on top of a datagrid,if we want same actions to be shown on right click on the datagrid as well will get the capability or we need to add one more control to handle that.?
Ex: of the similar usage is given below.

@vkpavan26 right-click implementation of actions on the datagrid wouldn't be there by default. You can add it by customizing the datagrid although the recommendation is to use the single-row click pattern recommended in #17 that is currently being implemented considering it works better in the context of touch screens as well (when thinking of touch screens we're not only talking about tablets or mobile phones, we're also talking about touch screen devices like Windows 10+ devices for example).

Hi Jehad,
IMO grid should have that capability to expose the same actions on right click, so that whenever we are consuming the grid we need to add customization on our own in every implementation.
Even on single selection/multi selection we should have capability of both because there are usecases where you can allow user to remove multiple configurations in one go.

@vkpavan26 in terms of single selection/multi-selection, that does exist as part of #17 which is currently being implemented. We'll take the suggestion of right-click into consideration but as Clarity, we're trying to get away from using right-click as a main method of actions and moving forward with the design in #17. Based on that, we'll be able to gather more information once it is out and continue to iterate so feedback here is appreciated.

@reddolan Does this design suggest that blue icons should be used in toolbars (e.g. datagrid toolbar)? I thought the intent was to have them grey (#565656) and then they'd turn blue on hover?

@halachliyskid it's spec'd to have grey over datagrid. But you can have either grey or blue if you prefer. The documentation is in the Icons section above

flat Button Groups can Action Blue or Grey. Grey is used with Grid and Table actions

Hi all,
Do you intend to allow stacking button with input fields, is it is possible with the Bootstrap input-groups?

@Jinnie that would be outside the scope of this component. However, if you need that type of component, please file a feature request issue for it.

@reddolan
Not really. Just curious.
While we were using Bootstrap, we were using both button groups and input groups and the team seemed to like them.
Then we dropped Bootstrap and the groups were gone.
When I saw your work on the button groups, I thought that input groups may be coming next :)
For me, personally, it is something cool, but the actual value is more moderate. I might use it if it exists, but I'd not insist for it or start implementing it myself.

@Jinnie thanks for letting us know how you were using it. If you guys find that you do end up needing it for some reason, just drop us a request issue and we'll look into it.

Updated visuals based on discussions


Versioning conventions

I had a discussion with @FynnBe and @k-dominik about versioning conventions, continuing the discussions in #151.
We now decided to adopt the following pattern:

0.3.2-rcN for pre-releases, i.e. tentative releases where the spec changes are not ironed out yet
0.3.2-releaseN for releases, where release0 is the first one where the spec changes are fixed and >0 are used for code changes.

Important: we never use "bare" versions like 0.3.2, because these would have higher precedence than the -release ones, see

cc @oeway
(We should add this to some sort of developer doc)

Looks good! I would only add that please check if that versioning is compatible with python conventions (I believe it's https://www.python.org/dev/peps/pep-0440/), and also we need to make sure it's supported by pypi and conda.

CI is a nice thing to have - turns out x.y.z-something is not valid for conda. Conda doesn't allow for hyphens. I'm not sure I understand the semver spec correctly there - is the hyphen optional or mandatory?

Looks good! I would only add that please check if that versioning is compatible with python conventions (I believe it's https://www.python.org/dev/peps/pep-0440/), and also we need to make sure it's supported by pypi and conda.

good point @oeway - it isn't:

The canonical public version identifiers MUST comply with the following scheme:
[N!]N(.N)*[{a|b|rc}N][.postN][.devN]

in a way that scheme will also work nicely for us (and conda): we can still agree to mark

release candidates with rc
either we omit "bare" release like (0.3.2) here, too, but always appending post, so 0.3.2.post0 as the first "release", or we leave 0.3.2 in place.

this is not semver compliant.

```python
>>> from packaging.version import Version
>>> Version("0.3.2.rc0") < Version("0.3.2") < Version("0.3.2.post0")
True

good enough for me :)

Ok, that's also good enough for me :). It's also nice that we can have the clean "0.3.2" release then.

indeed semver and PEP440 are incompatible:
"Semantic versions containing a hyphen (pre-releases - clause 10) or a plus sign (builds - clause 11) are not compatible with this PEP and are not permitted in the public version field."
--https://www.python.org/dev/peps/pep-0440/#semantic-versioning
it contineus with "One possible mechanism to translate such semantic versioning based source labels to compatible public versions is to use the .devN suffix to specify the appropriate version order."
but as far as I understand PEP440 "0.3.2.rc0" is not allowed. (only "0.3.rc0" would be)

but as far as I understand PEP440 "0.3.2.rc0" is not allowed. (only "0.3.rc0" would be)

I have seen the "0.3.2.rc0" pattern in other packages a lot, e.g. https://github.com/napari/napari/releases/tag/v0.4.10rc0 (although they don't use a dot ...)

afaiu the you can have an arbitrary number of integer version specifiers separated by a . (well minimum one). so even <IP_ADDRESS>.<IP_ADDRESS>.1.22323.post3 is valid

but as far as I understand PEP440 "0.3.2.rc0" is not allowed. (only "0.3.rc0" would be)

I have seen the "0.3.2.rc0" pattern in other packages a lot, e.g. https://github.com/napari/napari/releases/tag/v0.4.10rc0 (although they don't use a dot ...)

indeed, there should not be a . before rc

afaiu the you can have an arbitrary number of integer version specifiers separated by a . (well minimum one). so even <IP_ADDRESS>.<IP_ADDRESS>.1.22323.post3 is valid

Yes, I think so, too: "The release segment consists of one or more non-negative integer values, separated by dots: N(.N)*"
I suppose they just didn't bother writnig an example with n>2...
ok, so we land on (the .postN need the dot):
>>> from packaging.version import Version
>>> Version("0.3.2rc0") < Version("0.3.2") < Version("0.3.2.post0")
True

Ok, just to summarize: we have

0.3.2.rc1 for the release candidates
0.3.2 for the release with (hopefully) the stable current spec
0.3.2.post1 for later releases with fixes / additions to the python package

Is this correct? If yes, let's add this somehow to the docu and then close the issue.

Looks good!

I consider this is settled now.


cabal-lint: add tool

This PR adds the cabal-lint tool. The Consensus team is going to use this to enforce invariants amongst our .cabal files that will help us maintain them given our new reliance on CHaP.

This looks good, however I agree with @erikd that this can be a general tool for Haskell.

@nfrisby I a bit shocked that this went under my radar :D I'll have a look at this. As for your question here note that now we have cabal-install and Cabal-syntax available as libraries. This should help not reinventing the wheel.

Closing; migrated to https://github.com/input-output-hk/ouroboros-consensus/pull/486


Error

hello,
i am a beginner to all of this, ive tried setting up the LCD 2.8 inches on rp zero
when using cd ~ then the (clone https:github..etc_)
it asks me for a username and a password.
ive tried many times even with connecting the screen still nothing and it keeps asking for username and password to be able to continue. i dont know what to do please help.

update i have tried to create a token and unfortunately it is not working i think it needs some other username and password.
i have tried to connect the screen its just white and nothing is moving because the driver is not installed.
to give more details im downloading it through url
i am connected to wifi and have tried at least 20 times and everytime keeps asking for username and password. i would appriciate it if you can help me as soon as possible.


amplify pull doesn't remove models deleted in the Amplify Admin Panel

Describe the bug
I've been making changes to my data models in the Amplify Admin Panel. Recently, I removed an enum type...
To Reproduce
I ran amplify pull to update the schemas on my machine...
Expected behavior
And the models were correctly updated, however, the enum (that was deleted) was left over... Should be deleted?
Environment(please complete the following information):

Amplify Framework Version: 1.0
Amplify Categories:

[ ] Analytics
[x] API
[ ] Auth
[x] DataStore
[ ] Predictions
[ ] Storage

Dependency Manager: SwiftPM
Swift Version: 5
CLI Version: 5.0.0
Xcode Version: 12.4

Can you confirm that if you remove the files manually in Xcode (that is, remove both the file and the project reference), that amplify pull doesn't re-populate them? I agree that it would make sense to remove files that are under codegen control, as long as we can verify that the file to be removed actually should be. It would obviously be bad if we removed user-generated files from the amplify/generated/models directory (even though it's unlikely there would be any there).

Confirmed: once manually deleted, they don't get re-populated

@maxhumber what you're experiencing seems related to https://github.com/aws-amplify/amplify-codegen/issues/50
Which version of the CLI are you on? Looks like the issue has been addressed and the new behaviour is behind a feature flag with a default value to false for old projects.
You can check the value of the feature flag cleanGeneratedModelsDirectory in your project by verifying the content of amplify/cli.json.
The feature flag should be under the codegen key, but if it's not there you can always added it.
After this change, your amplify/cli.json should look similar to
{
    "features": {
        ...
        "codegen": {
            ....
            "cleangeneratedmodelsdirectory": true
        }
    }
}

Closing due to inactivity, feel free to reopen if you have more questions.


duologues, equaling

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.4
logical conflict every: 100
sleep for: 300s
[pullrequest]
requests per hour: 30
deps=[d,e]

/trunk merge


attempt to update npm totally broke it

any way to return to the previous version?
ERROR: npm v10.2.5 is known not to run on Node.js v12.22.8.  This version of npm supports the following node versions: `^18.17.0 || >=20.5.0`. You can find the latest version at https://nodejs.org/.

ERROR:
/usr/lib/node_modules/npm/lib/utils/exit-handler.js:19
  const hasLoadedNpm = npm?.config.loaded
                           ^

SyntaxError: Unexpected token '.
....

node versions  ^18.17.0 || >=20.5.0 are incompatible with my system

There is a script at https://www.npmjs.com/install.sh that can be used to bootstrap npm on a system that doesn't have a working version of npm.
You can set the $npm_install shell variable to the specific version you want and then run the script.

thanks, wraithgar, for your response. It did resolved the issue (with some extra debugging and searching). But the issue itself is still there and the next person on an outdated system, trying to update npm will likely ends up at the same point.
Don't you think adding compatibility check in the update process will be useful? If node or other dependencies are incompatible with the version of npm being installed - exit with the found incompatibility message instead of breaking existing npm. It'd save a lot of time for people who are focused on other tasks.

Newer versions of npm do have this fix.  This obviously does no good for folks on a version of npm before the fix, but as time goes on we'll see less of this.
If you were to install npm 8.19.4 (the newest version that runs in node 12) you would get this:
~ $ npm -v
8.19.4
~ $ node --version
v12.22.12
~ $ npm i -g npm@latest
npm ERR! code EBADENGINE
npm ERR! engine Unsupported engine
npm ERR! engine Not compatible with your version of node/npm<EMAIL_ADDRESS>npm ERR! notsup Not compatible with your version of node/npm<EMAIL_ADDRESS>npm ERR! notsup Required: {"node":"^18.17.0 || >=20.5.0"}
npm ERR! notsup Actual:   {"npm":"8.19.4","node":"v12.22.12"}


Bug: QA Test Data Cycle Time Injection Date

Issue:
Date validation issue.  End date in new cycle time injection record prior to begin date is saved without error.
Steps to Recreate:

Add Cycle time summary
Add component id 202
Add test number 2345
Add test reason DIAG
Add test result FAILED
Add begin date time 6/14/2023 3:50
Add end date time 6/14/2023 3:15
Add Cycle Time Summary Total time 10
Add Cycle time injection

@mosesdeeCVP

End Date Cycle Time Injection record prior to begin date causes error as expected.


Android app instrumental testing for the UI

Android app UI testing . The classes include the different Matchers( drawable, recycleView and Toast).
:ballot_box_with_check: Definition of Done checklist

[ ] Meaningful title and valuable description in pull request
[ ] Code change tested manually if not covered by automated tests
[ ] Pull request linked to one or more issues/stories
[ ] Acceptance criteria of the linked stories satisfied
[ ] Code change comprehended by those who approved it
[ ] State of target branch maintained or improved after the code change

do you what was the reason why the ci failed? i don't see any conflicts

i see, it shows up now

I think its some dependencies, will try fix it tomorrow.

So this is the first part of testing?

So this is the first part of testing?

Yeah, its the starting.


tensor flow resource exhausted error on Kaggle notebooks

Please make sure that this is an issue related to performance of TensorFlow.
As per our
GitHub Policy,
we only address code/doc bugs, performance issues, feature requests and
build/installation issues on GitHub. tag:performance_template
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): no
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): MacOS 11.6
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: no
TensorFlow installed from (source or binary): pip
TensorFlow version (use command below): 2.0
Python version: 3.9
Bazel version (if compiling from source): no
GCC/Compiler version (if compiling from source): NIL
CUDA/cuDNN version: NIL
GPU model and memory: kaggle notebook

You can collect some of this information using our environment capture
script
You can also obtain the TensorFlow version with:

TF 1.0: python -c "import tensorflow as tf; print(tf.GIT_VERSION, tf.VERSION)"
TF 2.0: python -c "import tensorflow as tf; print(tf.version.GIT_VERSION, tf.version.VERSION)"

Describe the current behavior
this is the error i have been displayed:
Resource exhausted: OOM when allocating tensor with
shape[800000,32,30,62] and type float on
/job:localhost/replica:0/task:0/device:GPU:0 by allocator GPU_0_bfc
[[{{node conv2d_1/convolution}}]]
Describe the expected behavior:
the expected behavior was that it runs the code and outputs the desired result.
Standalone code to reproduce the issue
Provide a reproducible test case that is the bare minimum necessary to generate
the problem. If possible, please share a link to Colab/Jupyter/any notebook.
none
Other info / logs Include any logs or source code that would be helpful to
diagnose the problem. If including tracebacks, please include the full
traceback. Large logs and files should be attached.
none

@VivanVatsa ,
We see you are using tf v2.0. Could you please update TensorFlow to the latest stable version v2.6 and let us know if you are facing the same error. Thanks!

was running the latest tensorflow2.6 on Kaggle notebooks, still no luck

@VivanVatsa ,
In order to expedite the trouble-shooting process, could you please provide the complete code and dataset to reproduce the issue reported here.Thanks!


Replacing WASM paths in setup.sh to continue pointing to assets.

Fixes https://casperlabs.atlassian.net/browse/STS-62

bors r+

bors r+


Blog post: Enhancing Kubernetes API Server Efficiency with API Streaming

A blog post about the API Streaming feature tracked by https://github.com/kubernetes/enhancements/issues/3157

Hey hey,
it's Matteo here, Comms Lead for 1.32
Is this piece ready for review?
Reminder that the review deadline is on the 25th of November.
Let us know if you need something from us, otherwise we will just mark it as ready for review and have sig-docs-blogs review it for content and the assigned SIG to chime in for a tech review.
Thank you!

Hey, hey @mbianchidev, yes, the PR is ready for review.

/hold for https://github.com/kubernetes/website/pull/48513#discussion_r1852564340

/hold cancel

/lgtm

/hold
pending assignment of publication date

Actually, release comms may have a new process to follow.

/lgtm

/lgtm
typo

Hey @p0lyn0mial, first of all thanks a lot for this blog!
Can you add in the metadata of the file a draft: true attribute?
As follows
---
layout: blog
title: 'Enhancing Kubernetes API Server Efficiency with API Streaming'
date: 2024-11-21
slug: kube-apiserver-api-streaming
draft: true
author: >
 Stefan Schimanski (Upbound),
 Wojciech Tyczynski (Google),
 Lukasz Szaszkiewicz (Red Hat)
---

In this way you won't need to change the date or the filename when Comms assigns you a publication date, but it will be directly us making that (and only that) change in coordination with SIG Docs.
As @sftim pointed out, we are trying out this new process that Tim himself suggested, to lift off some weight off the shoulders of blog authors and make it easier for us to shift dates in case it's needed.
Your assigned date is currently 17th of December, just so you know!

Can you add in the metadata of the file a draft: true attribute?

done, @mbianchidev PTAL.

/lgtm

/lgtm
I'll seek SIG-Docs approval.
The current date assigned still works, awesome work folks!

Oh, hold on. Is this a post-release blog article? If so then we'll need to assign a date after the release. That's pencilled in for the 17th, but actually you should do something slightly different.
See https://github.com/kubernetes/website/pull/48513#issuecomment-2495452549 for the fuller detail but broadly:

you set the publication date to the K8s v1.32 release date
you set draft: true in the front matter

@mbianchidev the date in https://github.com/kubernetes/website/pull/48513#issuecomment-2495452549 wasn't what I'd expect (I'd expected to see the v1.32 release date there), but otherwise I agree with that.
Maybe we could use a label for PRs that are part of the release blog. Something for a retro maybe.
@p0lyn0mial I apologise for the noise. This may well be good to merge; let me do a final check.

/hold cancel

@sftim Agreed on having a label like release-feature-blog - and a release-blog one for the mid-cycle and final release tbh
IMHO there's no need for the author to set the Kubernetes release as date, having draft: true in there is enough.
I communicated the assigned publication date just to let the author know when to expect the blog to be published - maybe they wanna share it with their network or someone interested.
Operationally all the feature blogs are tracked on the board with an assigned date and that already makes it easy for Comms to open that separate PR to set all the current dates at once :eyes:

Looks good to merge as a draft. We can take fixup PRs ahead of publication.
/lgtm
/approve


Awake no longer working on "Keep awake indefinitely" setting

Microsoft PowerToys version
0.81.0
Installation method
WinGet
Running as admin
No
Area(s) with issue?
Awake
Steps to reproduce
After updating to 0.81.0, with Awake on the "Keep awake indefinitely" my computer is locking again. Before 0.81.0 it was working just fine.
No steps to reproduce other than updating to 0.81.0 as that was all I did before it stopped working.
✔ Expected Behavior
I expected the "Keep awake indefinitely" setting to keep my computer awake indefinitely.
❌ Actual Behavior
Computer auto locks after the standard amount of time of it takes to auto-lock.
Other Software
No response

Closing this as it looks like a potential duplicate.


linux: CONFIG_NET_SCH_FQ_CODEL=y

Description of changes
Beginning in 2014, systemd sets the default qdisc to fq_codel, in order to fight off the general scourge of internet bufferbloat.
https://github.com/systemd/systemd/commit/e6c253e363dee77ef7e5c5f44c4ca55cded3fd47
At the moment this gets built as a module, but since at least 99% of NixOS users are not going to change their qdisc, let's build this code into the kernel and save the disk I/O at boot of loading another kernel module.
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

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

[ ] Fits CONTRIBUTING.md.

What does it save in practice? How big is the fq_codel ko module? And isn't this micro-optimization in the context of NixOS targets?

What does it save in practice? How big is the fq_codel ko module? And isn't this micro-optimization in the context of NixOS targets?

It's possible that NixOS could be booting from spinning-metal hard drives, as the boot.initrd.availableKernelModules documentation in all-hardware.nix makes clear:
https://github.com/NixOS/nixpkgs/blob/7394735942afb1f0f826ac9aa29f419339c85b22/nixos/modules/profiles/all-hardware.nix#L12
On such a system, fq_codel ko module could be located far away and take many milliseconds to seek and read.  If we know that this module is virtually certain to be loaded on every boot, it makes sense to load it into the kernel image.

What does it save in practice? How big is the fq_codel ko module?

The size of the .ko file is irrelevant if it gets loaded on (virtually) every boot.  It's going to occupy the same amount of RAM once loaded.

What does it save in practice? How big is the fq_codel ko module? And isn't this micro-optimization in the context of NixOS targets?

It's possible that NixOS could be booting from spinning-metal hard drives, as the boot.initrd.availableKernelModules documentation in all-hardware.nix makes clear:
https://github.com/NixOS/nixpkgs/blob/7394735942afb1f0f826ac9aa29f419339c85b22/nixos/modules/profiles/all-hardware.nix#L12
On such a system, fq_codel ko module could be located far away and take many milliseconds to seek and read. If we know that this module is virtually certain to be loaded on every boot, it makes sense to load it into the kernel image.

Could you set up a QEMU test with HDD (with precise values for emulating HDD, e.g. slow seek times, 7200RPM thingies) before this PR / after this PR?

Could you set up a QEMU test with HDD (with precise values for emulating HDD, e.g. slow seek times, 7200RPM thingies) before this PR / after this PR?

No.

Could you set up a QEMU test with HDD (with precise values for emulating HDD, e.g. slow seek times, 7200RPM thingies) before this PR / after this PR?

No.

Then I'm afraid we will have trouble to proceed here because there are very few details on why this is any relevant and this introduces a weird precedent where everyone with their usecase could say "I think this will make things faster so let's do X".


Fix namespacing

> Sidekiq::Cronitor::PeriodicJobs.sync_schedule!
NameError: uninitialized constant Sidekiq::Cronitor::Error

The nested modules actually broke this - sorry @aflanagan 😢 . You're gonna wanna pull 3.2
Reverted the nesting and tested locally. Tried to add specs, but I can't figure out how to stub those constants.

Thanks for catching that! Will update!


fix(meta): use correct prev epoch on recovery

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Use the committed epoch from HummockManager as the value of previous epoch on bootstrap recovery and failure recovery.
Consider there're 3 in-flight barriers:
downstream
B4 (p=3, c=4)
B5 (p=4, c=5)
B6 (p=5, c=6)
upstream

If B5 fails, we previously rebuilt the actors and sent a barrier with (p=6, c=7) since the epoch is retrieved from the in_flight_prev_epoch. This is not that correct but actually works because we always clear the shared buffer on recovery, then reads on epoch 6 will get the identical results with reads on epoch 3.
After this PR, we will send (p=3, c=7) (note: 7 is based on the physical time!) on recovery, which has better correctness. This also enables executors like Now to get rid of its state store, since it can now correctly obtain the old timestamp value emitted to the downstream from the previous epoch of the recovery barrier.
Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Documentation

[ ] My PR contains user-facing changes.

Click here for Documentation
Types of user-facing changes
Please keep the types that apply to your changes, and remove the others.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note

Hmm... I think we have sanity check to make sure prev epoch of the current barrier == cur epoch of the prev barrier. Will this PR break this check?

To solve it, we should call try_wait_epoch(latest epoch on meta) during recovery.

Yeah. Do you mean https://github.com/risingwavelabs/risingwave/pull/8468?

Yeah. Do you mean https://github.com/risingwavelabs/risingwave/pull/8468?

Look like the code in #8468 is all on the meta side. On CN side we should also call try_wait_epoch to ensure the max committed epoch on the CN is aligned to the committed epoch on the meta.

Yeah. Do you mean #8468?

Look like the code in #8468 is all on the meta side. On CN side we should also call try_wait_epoch to ensure the max committed epoch on the CN is aligned to the committed epoch on the meta.

try_wait_epoch is an RPC from the meta service to all compute nodes. This is introduced originally for synchronize the version when scaling, but it seems also necessary for recovery.

try_wait_epoch is an RPC from the meta service to all compute nodes. This is introduced originally for synchronize the version when scaling, but it seems also necessary for recovery.

Oh I see. So it works fine now.

Does it remain the same in this PR

Yes. Although we now always call bootstrap_recovery and then inject_barrier on startup, the logic for filtering out "empty" workers is still there in the implementation of inject_barrier.

👍 Appreciate it, I will review it later.

Yes. Although we now always call bootstrap_recovery and then inject_barrier on startup, the logic for filtering out "empty" workers is still there in the implementation of inject_barrier.

If so, is it possible that we still fail in the assertion that prev_epoch == hummock_version.epoch when BarrierKind::Initial?
For example, let's say a CN are empty at a moment, and other CNs have received its initial barrier and start working, and some barriers have been processed and committed to new hummock version, which increases the hummock_version.epoch. If now we send an initial barrier to that previously empty CN before it receives the latest hummock version, the prev_epoch in the barrier will be greater than the epoch in its stale hummock version, and the assertion fails.

If so, is it possible that we still fail in the assertion that prev_epoch == hummock_version.epoch when BarrierKind::Initial?

I guess not. 🤔 The "initial" is a global concept and the first barrier received by this "previously empty" compute node will not be Kind::Initial, so it won't trigger the assertion.

The recovery test failed due to epoch check in hummock:
thread '<unnamed>' panicked at 'assertion failed: epoch > max_committed_epoch', src/storage/src/hummock/event_handler/uploader.rs:839:17
stack backtrace:
   0: rust_begin_unwind
             at /rustc/f0411ffcebcd7f75ac02ed45feb53ffd07b75398/library/std/src/panicking.rs:593:5
   1: core::panicking::panic_fmt
             at /rustc/f0411ffcebcd7f75ac02ed45feb53ffd07b75398/library/core/src/panicking.rs:67:14
   2: core::panicking::panic
             at /rustc/f0411ffcebcd7f75ac02ed45feb53ffd07b75398/library/core/src/panicking.rs:117:5
   3: update_pinned_version
   4: {async_fn#0}
             at ./src/storage/src/hummock/event_handler/hummock_event_handler.rs:479:9

The recovery test failed due to epoch check in hummock:

Do you have any ideas for this? 🥺 @wenym1

Do you have any ideas for this? 🥺

It looks like there are data of a older epoch (let's say epoch 5) is still under processing while the epoch (epoch 5) or a later epoch (maybe epoch 7) has been committed.
Is might happen that, we have a previously empty CN, so it does not receive the global initial barrier. Let's say current epoch is epoch 3. And later the rest of the cluster has finished epoch 5 and the epoch of hummock version is 5 in meta node, but still 3 in the hummock version of the empty CN. Now the empty CN becomes non-empty and start receiving its first barrier(not the initial barrier) with prev epoch 5. Since such barrier is not initial, epoch 5 will be sealed on this CN. Later when such CN receives the asynchronously updated hummock version of epoch 5, it will fail in this assertion.
A potential solution is that, when the CN receives its first barrier after recovery, it explicitly call try wait epoch to ensure that the prev epoch of the first barrier is aligned with the epoch of the hummock version in the CN.

After analyzing the logs, I found that the panic occurs when the compute node received the first VersionUpdate PinnedVersion event after its recovery (due to meta getting killed), and it found there's still an epoch value before the recovery in the unsealed_data. This should not happen if the uploader is correctly reset.
This seems to be caused by the changes in the bootstrap recovery progress. Even if we find there's no actor in the cluster, we should still call force_stop_actors in reset_compute_nodes, which resets the internal states of the storage and the local stream manager of all compute nodes.
I'll fix this and check whether it happens again. cc @yezizp2012


Remove old nav bar

Old JSX navbar was accidentally added back in #86, so we have 2 NavBar files now. I tested the site after removing and everything seems to be fine.

Yeah, I tested everything when adding the new nav bar. Should have no problems with it, probably just something that confused git during a PR merge


(#227) Refactor setting schema reference attribute

As per #227:
Refactored the addition of xsi:noNamespaceSchemaLocation to generated metric.xml into applying a few Xembly instructions instead of an XSL transformation.
Three instructions were eventually needed—one to point the cursor to the metric element (since it points above the root element by default), one to declare the XML namespace of the schema location attribute, and one to set the location itself.

Job #325 is now in scope, role is REV

Codecov Report

Merging #325 into master will increase coverage by 0.02%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master     #325      +/-   ##
============================================
+ Coverage     75.58%   75.61%   +0.02%
  Complexity      184      184
============================================
  Files            34       34
  Lines          1102     1103       +1
  Branches         88       88
============================================
+ Hits            833      834       +1
  Misses          238      238
  Partials         31       31

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/org/jpeek/Report.java
93.47% <100%> (+0.14%)
6 <0> (ø)
:arrow_down:

Continue to review full report at Codecov.

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

This pull request #325 is assigned to @ilyakharlamov/z, here is why; the budget is 15 minutes, see §4; please, read §27 and when you decide to accept the changes, inform @paulodamaso/z (the architect) right in this ticket; if you decide that this PR should not be accepted ever, also inform the architect; this blog post will help you understand what is expected from a code reviewer; there will be no monetary reward for this job

@Protagores Are you sure you want to create a pull request from your master? That's usually a bad practice because you will not be able to change anything else, you will not be able to fix any other bug without affecting this issue. I recommend you to cancel this pull request, create a separate branch exclusively for this issue #227, make the fixes only in that branch and submit a new pull request.

@ilyakharlamov

I recommend you to cancel this pull request, create a separate branch exclusively for this issue #227, make the fixes only in that branch and submit a new pull request.

Done, see #326

Job was finished in 2 hours, bonus for fast delivery is possible (see §36)

@fabriciofx/z please review this job completed by @ilyakharlamov/z, as in §30; the job will be fully closed and all payments will be made when the quality review is completed

Pull request #325 was not merged, no payment for ARC, see §28

Job #325 is not in the agenda of @ilyakharlamov/z, can't inspect

The job #325 is now out of scope

@0crat quality bad

Quality is low, no payment, see §31

Quality review completed: +4 point(s) just awarded to @fabriciofx/z


Performance advice

Although the adaptive stuff is very cool for per-image pair evaluation, I have found that batching together in 32 offers order of magnitude better speed-up. So if you do 3D reconstruction, just write some batching script and enjoy the speed-up.

The adaptive mechanisms indeed don't yet support batching well. We could however conservatively exit when all pairs in the batch are ready and prune to the large number of keypoints retained across the batch.

@ducha-aiki Sorry to ask this but would it possible to share a snippet of the batching code? If not possible, some intuition how would one go about it? I am using SuperPoint + LightGlue and these are things I have tried up till now,

Superpoint batching (failed): tried updating lightglue/utils.py ImagePreprocessor and Extractor but towards the end in SuperPoint torch.stack fails because keypoints are of different sizes
Ran Superpoint for batch_image size individually in a for loop and tried creating a dictionary {image0: dict, image1: dict} but failed again because  keypoints are of different sizes

@udit7395 your version 2 is correct:

Ran Superpoint for batch_image size individually in a for loop and tried creating a dictionary

What you also should do, is to reduce threshold to zero and reduce nms.
Finally, consider padding with random descriptors for those, which are still less than needed.

@ducha-aiki any chance you could share an example of how to run superpoint in batches to extract keypoints?


user-guide: review "Managing External Data" examples

Per request from @mroutis in https://github.com/iterative/dvc/issues/2092#issuecomment-499131334

See doc in question: https://dvc.org/doc/user-guide/managing-external-data#examples (SSH)
This part specifically for example may not make sense:
# Add SSH remote to be used as cache location for SSH files
dvc remote add sshcache ssh://user@example.com:/cache

# Tell dvc to use the 'sshcache' remote as SSH cache location
dvc config cache.ssh sshcache

# Add data on SSH directly
dvc add ssh://user@example.com:/mydata

Because the sshcache remote name is never used.

[x] Also, the paths used in SSH URIs throughout don't match (:/cache vs :/mydata vs :/home/shared/data.txt).

Related to #143

Because the sshcache remote name is never used.

I don't think that's correct. The remote is registered and then configured as the SSH cache.
The paths are strange indeed though, for all the remote types. E.g.
# Add data on SSH directly
dvc add ssh://user@example.com:/mydata

What does adding a URL do? I don't think you can even do that, at least it's not explained in https://dvc.org/doc/commands-reference/add

Another note to add to this document (and to the external dependencies one) is that SSH remote locations (and soon others) now support adding entire directories. See https://github.com/iterative/dvc/issues/1654#issuecomment-539634772.

Also now supported for https://github.com/iterative/dvc/pull/2619

I just noticed that this is all done now.


Add new entries to top of table instead of bottom

The user cannot see the entry has been added once there are several items. Adding to the top would be a better experience. At least a feature switch could be added to do this.
addTop: true

ref: https://github.com/tabalinas/jsgrid/issues/398

Thank you for the suggestion

This configuration option might be better as a string parameter:
insertedRowLocation: "bottom"|"top"
This would allow more freedom in the future for different placement options, rather than limiting the user to a binary choice.

@richraid21, yes, good proposal.

Something like this would probably work. I didn't write tests or anything yet, just playing around with it. Row placement defaults to the bottom but can be configured to insert at the top.

@richraid21 This doesn't seem to work when using the jsgrid CDN


Use additional abort field on jobs table for abortion requests

Closes #1136

Successful PR Checklist:

[x] Tests

[ ] (not applicable?)

[x] Documentation

[ ] (not applicable?)

PR label(s):

[x] https://github.com/procrastinate-org/procrastinate/labels/PR type%3A breaking 💥
[ ] https://github.com/procrastinate-org/procrastinate/labels/PR type%3A feature ⭐
[x] https://github.com/procrastinate-org/procrastinate/labels/PR type%3A bugfix 🕵
[ ] https://github.com/procrastinate-org/procrastinate/labels/PR type%3A miscellaneous 👾
[ ] https://github.com/procrastinate-org/procrastinate/labels/PR type%3A dependencies 🤖
[ ] https://github.com/procrastinate-org/procrastinate/labels/PR type%3A documentation 📚

Looking good. What about naming the column abort_requested?
Alternatively, it could be a nullable timestamp abort_requested_at that can also be inferred as a flag but also conveys the time it is requested in the job table.

Looking good. What about naming the column abort_requested?

Yes, that sounds good. I renamed it to abort_requested.

Alternatively, it could be a nullable timestamp abort_requested_at that can be inferred as a flag but also conveys the time it is requested in the job table.

For the sake of simplicity, I would keep it a boolean flag. I make sure that the event of an abortion request is recorded (and the event itself has a timestamp). Are you okay with that?

Some design decisions:

I haven't intentionally made abort_requested available on the Job itself because if the user checks job.abort_requested of a passed context inside a task (in contrast to calling should_abort), this information is not up-to-date.
I reset the abort_requested to False when the job is finished.
The migration becomes quite long as it is not possible to remove a value (in this case, aborting) from an enum type. A new enum type must be created, the old one must be swapped out, and all dependencies (indexes, functions, trigger) must be recreated. I tried to add good comments to make things clear.

I will switch the branch to merge against when we have a new branch for our beta.

The migration becomes quite long as it is not possible to remove a value (in this case, aborting) from an enum type. A new enum type must be created, the old one must be swapped out, and all dependencies (indexes, functions, trigger) must be recreated. I tried to add good comments to make things clear.

That is the main drawback of postgres enum. They are not designed to have their values deleted

I haven't intentionally made abort_requested available on the Job itself because if the user checks job.abort_requested of a passed context inside a task (in contrast to calling should_abort), this information is not up-to-date.

And as long as the Job class is marked as frozen, we can't simply change the flag.
Here is a thought on how the should_abort could work:
The task doesn't call the database through the JobManager.
Instead, instead:

a side task from the worker polls the database at a configured interval for any job that should be aborted (and it would only be interested in the jobs that it currently runs)
additionally, a listener is notified every time a job is requested to be aborted which provides low latency.
The worker maintains a set of the job ids that should be aborted.
The JobContext exposes a function that returns whether the job id is in that set.

This means the tasks can check through the JobContext without introducing database overhead.
For async task, the worker could call cancel on the asyncio Task. The user code can then handle CancellationError to control abortion.

Here is a thought on how the should_abort could work:
The task doesn't call the database through the JobManager. Instead:

a side task from the worker polls the database at a configured interval for any job that should be aborted (and it would only be interested in the jobs that it currently runs)
additionally, a listener is notified every time a job is requested to be aborted which provides low latency.

The worker maintains a set of the job ids that should be aborted. The JobContext exposes a function that returns True if the job id is in that set.
This means the tasks can check through the JobContext without introducing database overhead.
For async task, the worker could call cancel on the asyncio Task. The user code can then handle CancellationError to control abortion.

Yes, that all sounds reasonable. But let's start by getting this PR (as it is) in the v3 branch, then the worker refactoring, and then start from there. At least we have a solid base, then. @ewjoachim Do you agree?

I agree. @onlyann your proposal seems to match what #1084 describes.

(is the PR ready for review after the worker refactor ?)

(is the PR ready for review after the worker refactor ?)

Yes, I think so.


Dream gate warp out of a boss scene and return to the statue

How do I use dream nail to warp out of a boss scene and return to the statue? What object/configs do I need to setup for this? Currently I am able to setup a statue and enter the boss scene. But I was not able to teleport back. Is this supported?

Also knight doesn't return to statue on death as well (instead went to some bench)

figured out. map zone needs to be gods_glory (that's too very hard to notice for beginners I guess :)


Content type "blog post"

Hi, first: thank you a lot for providing this package!
I was wondering if you would accept a PR for adding the ability to create blog posts?
From a quick test, I could post a blog to Confluence Cloud by creating a class \CloudPlayDev\ConfluenceClient\Entity\ContentBlogPost which extends \CloudPlayDev\ConfluenceClient\Entity\AbstractContent defining a $type "blogpost" and extending the existing code which works with ContentPage and ContentComment classes so that is also can handle blog posts.
Example usage code:
$confluenceClient = new ConfluenceClient($confluenceHost);
$confluenceClient->authenticateBasicAuth($confluenceUser, $confluenceToken);

$post = new ContentBlogPost();
$post->setSpace($space);
$post->setTitle($title);
$post->setContent($content);

$result = $confluenceClient->content()->create($post);

Hi @mzeis,
I am glad that this package has been helpful to you.
I would be happy if we could work on the BlogPost topic.
The body of a blog can have two types of content: BlogPostBodyWrite, BlogPostNestedBodyWrite. We should take these into account.
AbstractContent has properties like Children, Ancestors which I don't think a BlogPost has.
Maybe you can make a draft and we can see together what we can make of it.

Hi @astepin,
thank you for your response and detailing the next steps.
To get things working, I created an internal fork with the mentioned changes, and this works for creating our type of blog post. I'll try to find time to create a draft for a proper integration - I cannot promise anything on the timeframe, unfortunately.
Besides the mentioning of BlogPostBodyWrite and BlogPostNestedBodyWrite in the API, do you know of any more information from Atlassian for the concepts / usage etc. that would help us here?

I don't really know the exact background and concepts behind the blogs yet. I haven't used this type of content yet. I'll probably have to catch up on that.
There is also the normal content that you can create with the “blogpost” type. But apparently there is also a separate API just for blogposts. You have to check that first.
The blogpost API is also only available in v2.
https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-blog-post/


Fix double spaces in the v5.0.0 section of the CHANGELOG

Nothing breaking the code examples or markdown, just untidy formatting.

Carried the update on the release notes as well.


Add License

Great project 🚀, keep it coming!
Can you please add a License file to your project?

Thank you @Konfuzian!


How to create new user by call rest API ?

RT

Please vote on #285, please. I hope I can do this until the end of the year.

@zxl777 we have created a small CLI tool for adding users, you can use it. Or just check the API calls we make, it's pretty straight forward.
https://github.com/ironsharkde/filemanager-usermanager

@TUNER88 that's a nice app you've got there! Just as a follow up: we are making some changes and moving the name from File Manager to File Browser 😄

@hacdias shouldn't be a problem to rename our package as well, as soon you have released new version 😄

Done! 1.5.0 has the new name already 😄

Done filebrowser-usermanager v0.0.2 released ✅


Cast integers to float.

This is important when JavaScript is building requests because JS only
has floats, but represents 2.0 as 2 when serializing.

Awesome! I think now is a good time to add tests for integer and float casting. You can see examples here:
https://github.com/elixir-lang/ecto/blob/master/test/ecto/type_test.exs#L39
Can you please amend this PR?

@josevalim NP, tests added!

Doh, I just realized the tests are in the doctests. Sorry for the derpness, I merged just the first commit.


Create a handy way to set a ffmpeg log handler.

I'm working out this in my current project with the aim of using tracing but essentially this would let a use provide a lambda callback and handle getting it into av_log_set_callback. If I get it working in my project I'll aim to make something more generic and PR it if it could be useful for others

Hey, forked the sys crate and the ffmpeg-next crate and merged most of the current merge requests of both crates. If you have no problem with using a non crates.io crate, you can use this one. I will keep merging pull requests because these repositories seem mostly abandonded.
I build something just like you and added basic log callback functions to my crate version. To do or use something dynamic in log callbacks you will have to use statics and probably synchronization which is way too specific for such a crate imo.


WingX weirdness

latest WingX release 5.5b
WingX will report say 9 1090 traffic but only be displaying 4
the stratus web page traffic pages generally shows what WingX is plotting say the 4... so where is the 9 coming from?

Any chance it's filtering distant targets? I remember there's an option for this in the totally impenetrable WingX settings, but I can't recall where.

nope. I have the altitude filter turned off so it should be showing everything...

Huh. I'd give it a shot, but my Stratux is in pieces and it's raining cats and dogs out here today!

Same combo as the OP and not seeing the same issue.

So the number of 1090 traffic reported in the wingx stratux pull down tab always matches the number of targets displayed on screen?
Huh... I wonde what's wrong with mine.
I still don't get but a handful and only out to 40 miles I wonder if I have a mediocre sdr

Reopen with more info to reproduce if still an issue.


fix DeprecationWarning in test_ecdh

Also update docs to match
Fixes:
 CryptographyDeprecationWarning: Curve argument must be an instance of an EllipticCurve class.

Thanks for the update!


sfdx force:auth:web:login keeps on running and don't open any browser window

Summary
The sfdx command "sfdx force:auth:web:login" is not working as expected. It should open the browser window to login into the salesforce org but it does not. It just keeps on running.
Steps To Reproduce:

Create a project in vs code using ctrl+shipt+p => SFDX: Create project with manifest
As the project is created try to authorize an org using ctrl+shipt+p => SFDX : Authorize an org

Expected result
The browser should have opened a new tab on the specified url like "https://login.salesforce.com"
Actual result
Nothing happened. The command keeps running in vs code bottom right corner
Additional information
Feel free to attach a screenshot.
SFDX CLI Version

SFDX plugin Version(to find the version of the CLI plugin run sfdx plugins --core)

OS and version:
Windows 10
Existing Solution Suggestions
It is been suggested in some solutions that changing the default browser or setting the default browser to Microsoft Edge will resolve this issue.
However the same is not correct in my case as I have tried that but is not working.
I have also tried installing the vs code and cli again but to no luck.

check and see if you have a node process using port 1717, kill it, and try again.

thanks for the suggestion, running sudo lsof -i :1717 didn't pull anything
up.
On Mon, Nov 16, 2020 at 3:57 PM Zack Whipkey<EMAIL_ADDRESS>wrote:

check and see if you have a node process using port 1717, kill it, and try
again.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/forcedotcom/cli/issues/739#issuecomment-728152263,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN4IHREY4HHFWCI6FM5HJ3SQFDVTANCNFSM4TUXJ3IA
.

killing the Process doesn't help either. The issue still persists.

Only works for me when disconnected from VPN, but I do get the login page, the sfdx command never completes though after completing login.

This is fixed in newer releases for both windows and linux.  Please reopen if it's still happening


AuthorizationEndpoint does not support response_type=id_token

/authorize?nonce=...&state=...&redirect_uri=...&response_type=id_token&client_id=client&scope=openid

is a valid request. Yet there exists this:
if(!responseTypes.contains("token") && !responseTypes.contains("code")) {
            throw new UnsupportedResponseTypeException("Unsupported response types: " + responseTypes);
        }

I am happy to post a PR on this. Is that agreeable? This is really stopping us to get certified on a few other OIDC profiles.

Duplicates #619 #220.

Closing as duplicate

Thanks. Good to know it was documented elsewhere.


translating from GenBank ontology terms to SO and vice versa

Currently, the new offline GenBank-SBOL3 converter being implemented in sbol_utilities/sbol3_genbank_conversion.py on the feature/sbol3-genbank-conversion branch, uses two data files gb2so.csv and so2gb.csv to translate between ontology terms for GenBank and SO.
The conversions in those CSV files are taken up from here.
There also needs to be default terms for GenBank/SO while converting; should no row in the CSV match the term present in the file to be converted, there are a couple of issues regarding this:

The default SO Term, if no GenBank term in gb2so.csv matches the term present in any feature of the given GenBank file to convert, is mentioned in the spreadsheet to be SO:0000110. However, this clashes with the default used by the online converter, which is SO:0000001. In this case, which default should be accepted for the new converter?
Also, correspondingly, no default GenBank term is specified in the spreadsheet

In conversation with @cjmyers today, figured out the resolution.

I was confused: I thought SO:0000001 was the parent of SO:0000110, but it's actually the other way around.
The default GenBank term is misc_feature


Fixed overlapping strcpy with 8bit terminal

This PR fixes a bug detected by valgrind in term.c in Vim-8.1.173 and older:
==13302== Memcheck, a memory error detector
==13302== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==13302== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info
==13302== Command: ./vim --clean -c q
==13302==
==13302== Source and destination overlap in strcpy(0x7d29ad1, 0x7d29ad2)
==13302==    at 0x4C33337: strcpy (vg_replace_strmem.c:512)
==13302==    by 0x30A893: parse_builtin_tcap (term.c:1486)
==13302==    by 0x30B2FB: set_termname (term.c:1842)
==13302==    by 0x30BD96: termcapinit (term.c:2513)
==13302==    by 0x3647DF: main (main.c:383)

Bug is reproducible with:
$ TERM=xterm-8bit valgrind vim --clean -c q 2> valgrind.log

And valgrind.log contains the above error message.
Coverity detected this bug (defect Id=1307798). See:
https://scan5.coverity.com/reports.htm#v41229/p10101/fileInstanceId=143617210&defectInstanceId=40347990&mergedDefectId=1307798

Codecov Report

Merging #3187 into master will decrease coverage by 0.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #3187      +/-   ##
==========================================
- Coverage   76.43%   76.41%   -0.02%
==========================================
  Files          93       93
  Lines      136754   136755       +1
==========================================
- Hits       104526   104503      -23
- Misses      32228    32252      +24

Impacted Files
Coverage Δ

src/term.c
59.77% <0%> (+0.05%)
:arrow_up:

src/gui_beval.c
55.02% <0%> (-7.43%)
:arrow_down:

src/if_xcmdsrv.c
84.17% <0%> (-0.54%)
:arrow_down:

src/window.c
81.69% <0%> (-0.52%)
:arrow_down:

src/ex_cmds2.c
82.63% <0%> (-0.1%)
:arrow_down:

src/screen.c
76.73% <0%> (-0.03%)
:arrow_down:

src/if_py_both.h
76.57% <0%> (ø)
:arrow_up:

src/syntax.c
78.39% <0%> (+0.02%)
:arrow_up:

src/terminal.c
74% <0%> (+0.04%)
:arrow_up:

... and 3 more

Continue to review full report at Codecov.

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


feat: run workflow with option for multiple executions, improve cypress execution logic

Adds the possibility of driving cypress for test magnitude using VITE_SI_CYPRESS_MULTIPLIER to multiply the amount of times the tests are executed on each run to simulate user load. Additionally modified the CI build to be a matrix (of 1) so we can easily multiply on that vector too to give larger scale if needed. i.e.
CI Executor Multiples x VITE_SI_CYPRESS_MULTIPLIER x Test Number = Load
I also added a Posthog command to push a custom UUID into Posthog for each test to allow us to easily look at the user session for each event. This should be super helpful when we get more complicated tests or fragile tests to figure out what is wrong.

Looks good:

bors merge