could not build wheels for pycocotools

I have searched related issues but cannot get the expected help.
I have read the FAQ documentation but cannot get the expected help.
The bug has not been fixed in the latest version.

Describe the bug
when i install mmdetection,using connand pip install -v -e ..The error is Building wheel for pycocotools (pyproject.toml) did not run successfully and Could not build wheels for pycocotools, which is required to install pyproject.toml-based projects
my env is cu101 and torch 1.7.0 while my cuda and torch is running ok
i use windows10
Reproduction

What command or script did you run?
git clone https://github.com/open-mmlab/mmdetection.git (ok)
cd mmdetection   (ok)
pip install -r requirements/build.txt (ok)
pip install -v -e . (error)

A placeholder for the command.
(mmdetection) E:\Anaconda\envs\mmdetection\Lib\site-packages\mmdetection>pip install -v -e .
Using pip 22.0.4 from E:\Anaconda\envs\mmdetection\lib\site-packages\pip (python 3.8)

Did you make any modifications on the code or config? Did you understand what you have modified?
no

What dataset did you use?
this stage needn't use dataset,i just want install it well
Environment

Please run python mmdet/utils/collect_env.py to collect necessary environment information and paste it here.
sys.platform: win32
Python: 3.8.12 (default, Oct 12 2021, 03:01:40) [MSC v.1916 64 bit (AMD64)]
CUDA available: True
GPU 0: GeForce GTX 1050
CUDA_HOME: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.1
NVCC: Cuda compilation tools, release 10.1, V10.1.243
GCC: gcc (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0
PyTorch: 1.7.1+cu101
PyTorch compiling details: PyTorch built with:

C++ Version: 199711
MSVC 192729112
Intel(R) Math Kernel Library Version 2020.0.0 Product Build 20191125 for Intel(R) 64 architecture applications
Intel(R) MKL-DNN v1.6.0 (Git Hash 5ef631a030a6f73131c77892041042805a06064f)
OpenMP 2019
CPU capability usage: AVX2
CUDA Runtime 10.1
NVCC architecture flags: -gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_61,code=sm_61;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75;-gencode;arch=compute_37,code=compute_37
CuDNN 7.6.4
Magma 2.5.4
Build settings: BLAS=MKL, BUILD_TYPE=Release, CXX_FLAGS=/DWIN32 /D_WINDOWS /GR /EHsc /w /bigobj -openmp:experimental -DNDEBUG -DUSE_FBGEMM -DUSE_VULKAN_WRAPPER, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, USE_CUDA=ON, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_MKL=ON, USE_MKLDNN=ON, USE_MPI=OFF, USE_NCCL=OFF, USE_NNPACK=OFF, USE_OPENMP=ON,

TorchVision: 0.8.2+cu101
OpenCV: 4.5.2
MMCV: 1.4.0
MMCV Compiler: MSVC 192930137
MMCV CUDA Compiler: 10.1
MMDetection: 2.22.0+6ddbff8
2. You may add addition that may be helpful for locating the problem, such as
- How you installed PyTorch [e.g., pip, conda, source]   :pip
- Other environment variables that may be related (such as $PATH, $LD_LIBRARY_PATH, $PYTHONPATH, etc.)
Error traceback
If applicable, paste the error trackback here.
warning: no files found matching 'mmdet\VERSION'
warning: no files found matching 'mmdet.mim\model-index.yml'
warning: no files found matching 'mmdet.mim\demo**'
warning: no files found matching '.py' under directory 'mmdet.mim\configs'
warning: no files found matching '.yml' under directory 'mmdet.mim\configs'
warning: no files found matching '.sh' under directory 'mmdet.mim\tools'
warning: no files found matching '.py' under directory 'mmdet.mim\tools'
adding license file 'LICENSE'
writing manifest file 'C:\Users\ASUS-PC\AppData\Local\Temp\pip-pip-egg-info-0lfm6539\mmdet.egg-info\SOURCES.txt'
done
error: Microsoft Visual C++ 14.0 or greater is required. Get it with "Microsoft C++ Build Tools": https://visualstudio.microsoft.com/visual-cpp-build-tools/
error: subprocess-exited-with-error
× Building wheel for pycocotools (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> See above for output.
note: This error originates from a subprocess, and is likely not a problem with pip.
full command: 'E:\Anaconda\envs\mmdetection\python.exe' 'E:\Anaconda\envs\mmdetection\lib\site-packages\pip_vendor\pep517\in_process_in_process.py' build_wheel 'C:\Users\ASUS-PC\AppData\Local\Temp\tmpl3p1g0jb'
cwd: C:\Users\ASUS-PC\AppData\Local\Temp\pip-install-nsai7zl7\pycocotools_ad6054d7e050485ab52f31f62aca901d
error
ERROR: Failed building wheel for pycocotools
Failed to build pycocotools
ERROR: Could not build wheels for pycocotools, which is required to install pyproject.toml-based projects
A placeholder for trackback.

**Bug fix**
If you have already identified the reason, you can provide the information here. If you are willing to create a PR to fix it, please also leave a comment here and that would be much appreciated!

@54wb error: Microsoft Visual C++ 14.0 or greater is required. You need to update Microsoft Visual C++ version.

Thank you very much for your help..while I updata MicroSoft Visual C++ version，this error is solved perfectly.If someone else has the same problem, please read this blog for solutions

On Windows this worked for me:
conda install -c esri pycocotools

Thank you very much for your help..while I updata MicroSoft Visual C++ version，this error is solved perfectly.If someone else has the same problem, please read this blog for solutions

Hey, I installed Microsoft Visual Studio with C++ Buildtools, etc in the latest version, but it still keeps showing me that I need a C++ version greater than 14.0. How do I solve this issue?
Thanks

On Windows this worked for me:
conda install -c esri pycocotools

It is works for me

On Windows this worked for me:
conda install -c esri pycocotools

Thanks a lot, only it's working for me, I've tried a many different options before I saw it...


Cannot disable fatal signal handling

Hi,
When I run the build for MSYS2, I get errors as g3log is attempting to reference some windows functions that aren't linked:
/mingw64/bin/g++.exe -shared -o control.dll obj/cpp/DllMain.o obj/cpp/System.o ../../lib-ext/g3log/libg3logger.a -L../../ -lm
../../lib-ext/g3log/libg3logger.a(stacktrace_windows.cpp.obj):stacktrace_windows.cpp:(.text+0x274): undefined reference to `__imp_SymCleanup'
../../lib-ext/g3log/libg3logger.a(stacktrace_windows.cpp.obj):stacktrace_windows.cpp:(.text+0x8a7): undefined reference to `__imp_SymInitialize'
../../lib-ext/g3log/libg3logger.a(stacktrace_windows.cpp.obj):stacktrace_windows.cpp:(.text+0xa34): undefined reference to `__imp_SymGetModuleBase64'
../../lib-ext/g3log/libg3logger.a(stacktrace_windows.cpp.obj):stacktrace_windows.cpp:(.text+0xa54): undefined reference to `__imp_SymFunctionTableAccess64'
../../lib-ext/g3log/libg3logger.a(stacktrace_windows.cpp.obj):stacktrace_windows.cpp:(.text+0xb1f): undefined reference to `__imp_StackWalk64'
../../lib-ext/g3log/libg3logger.a(stacktrace_windows.cpp.obj):stacktrace_windows.cpp:(.text+0xd6d): undefined reference to `__imp_SymFromAddr'
../../lib-ext/g3log/libg3logger.a(stacktrace_windows.cpp.obj):stacktrace_windows.cpp:(.text+0xe47): undefined reference to `__imp_SymGetLineFromAddr64'
../../lib-ext/g3log/libg3logger.a(stacktrace_windows.cpp.obj):stacktrace_windows.cpp:(.text+0x127c): undefined reference to `__imp_SymCleanup'
collect2.exe: error: ld returned 1 exit status
Makefile:29: recipe for target 'control.dll' failed
make: *** [control.dll] Error 1

So I tried to disable the signal handling:
$ cmake -G"MSYS Makefiles" -DENABLE_FATAL_SIGNALHANDLING=OFF
But I still get the errors from stacktrace_windows.cpp.

With the define to turn off signal handling the functionality is still there. It's just not used.
My suggestion is that you put up a pull request for disabling even compiling this code when this define is there. The code you are looking for is in https://github.com/KjellKod/g3log/blob/17756a26578cc9ba5880ee34f288733d9d96ed7d/src/stacktrace_windows.cpp

Closed as this compiler is not supported directly.
If you can make a fix for it, as described above or otherwise then I can review the pull request


Support cancellation for find_lsn_for_timestamp API

Problem
See #5900
Summary of changes
Added cancellation token as param in all relevant code paths and actually used it in the find_lsn_for_timestamp main loop

A step in the right direction for sure. A few places are inconsistent on whether you return an error or Ok on cancellation. Would be good to have be consistent on those, but I think this will work even as it is.

@hlinnaka thanks, I have addressed your comments , please take another look


Only allow staff members to use SUMM.AI bulk action

Motivation

We only use the SUMM.AI bulk action in the page tree for initial translations by our team.
Thus, it should also be limited to staff members.
Region managers are supposed to translate pages in SUMM.AI via the new machine translation interface (#1727).
Proposed Solution

Either check is_staff in the bulk action view or create a new permission and assign it to the service- and cms team
Hide bulk action for users who are not allowed to use it

As a work-around the function was disabled, therefore this issue isn't prio high anymore

Doesn't this issue contradict our decision to cancel the automatic translation page tree (see #1727)? If we don't have the other automatic translation interface, then normal users should be able to use the bulk action, otherwise they don't have the possibility to translate at all...


add logo to README.MD

Description:
Add the logo to the README.md
Issues affected:
Resolves #267

This change is

Reviewed 2 of 2 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Add whitespaces to machine-learning-resources.md

📇 Changes proposed
Added whitespace in machine-learning-resources.md after numbers to these lines: 11.Deep Learning by Prof. Ali Ghodsi at University of Waterloo Fall 2015 STAT and 12.Statistical Machine Learning by Prof. Larry Wasserman to make them look more clear.
✅ Check List (Mark all the applicable boxes)

[x] My code follows the code style of this project.
[x] This PR does not contain plagiarized content.
[x] This PR contains changes in the documentation
[ ] This PR contains changes in the Code of the project
[x] The title of my pull request is a short description of the requested changes.

Thanks for contributing to OSWH @nikohoffren


[WIP] Update "Picking the Right Solution"

Update content
Emphasize Certified Kubernetes Platforms and Distributions

/cc @dankohn

This change is

/approve


feat: add page event view

Description
Linear Ticket
https://linear.app/autokitteh/issue/UI-661/single-event-viewer-on-row-click
What type of PR is this? (check all applicable)

[ ] 💡 (feat) - A new feature (non-breaking change which adds functionality)
[ ] 🔄 (refactor) - Code Refactoring - A code change that neither fixes a bug nor adds a feature
[ ] 🐞 (fix) - Bug Fix (non-breaking change which fixes an issue)
[ ] 🏎 (perf) - Optimization
[ ] 📄 (docs) - Documentation - Documentation only changes
[ ] 📄 (test) - Tests - Adding missing tests or correcting existing tests
[ ] 🎨 (style) - Styles - Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
[ ] ⚙ (ci) - Continuous Integrations - Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
[ ] ☑ (chore) - Chores - Other changes that don't modify src or test files
[ ] ↩ (revert) - Reverts - Reverts a previous commit(s).

Please add missing re-dispatch functionality:

Also, in EventsService.get(eventId), please send jsonValues:true to the client, like this:
const { event } = await eventsClient.get({ eventId, jsonValues: true });
So the outputs would be much prettier and will look better.

Table:

add DestinationID and type

Event view:

display inputs without accordion


[BEAM-8739] Consistently use with Pipeline(...) syntax

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

R: @ibzib lint and tests are now all happy.

Before I actually go through all of this, a few general comments:

I see you did a lot of these conversions automatically. I'd be curious what the scripts looked like.

Yes, I'll attach the script. Nothing fancy.

Ideally we would incorporate this into the linting process, but there's probably enough edge cases to make this infeasible.

Yeah. I'm hoping that mostly people will follow conventions of the surrounding code.

I noticed (as you pointed out on the Jira) that a few tests in here originally didn't call pipeline.run() at all (whether through with or directly). My biggest concern with this PR is that it might go the other direction and somewhere remove an existing call to pipeline.run(). (All other errors I could think of would have resulted in test failures, so you would have caught them already.)

If something is converted to the with syntax, run() will always be called.

If one of the goals here is to encourage everyone to use this syntax, it'd be important to cover the code snippets on the website as well.

Yes. That code is harder to auto (or manually) convert given the amount of mocking and ordering in which things are included/excluded. Taking a pass at the examples and snippets is certainly something that should be done and I'll keep this ticket open until then.

Just a bunch of regular expression munging...
import re
import sys

for file in sys.argv[1:]:
  with open(file) as fin:
   contents = fin.read().split('\n')
  new_contents = []
  in_pipeline = False
  indent = None
  converted_pipelines = 0
  total_pipelines = 0
  for ix, line in enumerate(contents):
    if in_pipeline:
      if line.startswith('%s%s.run()' % (indent, pipeline_var)):
        converted_pipelines += 1
        new_contents.append('%swith %s as %s:' % (indent, pipeline_expr, pipeline_var))
        for b in body:
          new_contents.append('  ' + b if b.strip() and b[0] != '#' else b)
#         if body[-1]:
#           new_contents.append('\n')
        in_pipeline = False
      elif not line.startswith(indent) and line.strip() and not re.match('^ *#', line):
        print('END', file, ix, list(filter(lambda x: x, [b.strip() for b in body]))[-2:])
        new_contents.append(pipeline_init)
        new_contents.extend(body)
        new_contents.append(line)
        in_pipeline = False
      else:
        body.append(line)
    else:
      m = re.match(r'^( *)(\S+) = (\S*Pipeline[(].*)', line)
      if m:
        total_pipelines += 1
        in_pipeline = True
        indent = m.group(1)
        pipeline_init = line
        pipeline_var = m.group(2)
        pipeline_expr = m.group(3)
        body = []
      else:
        new_contents.append(line)

  if in_pipeline and body:
    new_contents.append(pipeline_init)
    new_contents.extend(body)

  if new_contents != contents:
    with open(file, 'w') as fout:
      fout.write('\n'.join(new_contents))
  if total_pipelines:
    print(file, converted_pipelines, total_pipelines)
    print()

Post-holiday ping. Rebased on latest master.


🏆 Awesome and epic initiative from wulfland

[ ] #2
[ ] #3
[ ] #4

@wulfland kaufm

@jessehouwing


Review request

updates due to multi window changes and i want to get an opinion on them
requires:

https://github.com/sh-dave/koremake/tree/system-settings-playground

Oh wow, biggest Kore pull-request yet, thanks a lot for that. Might take me until Thursday evening to read through all of this though (sorry, not much free time today and tomorrow). I like the Application removal.


HSEARCH-3493 Test compatibility with JDK13

https://hibernate.atlassian.net//browse/HSEARCH-3493
I only had to submit a PR to the elasticsearch-maven-plugin so that we can run Elasticsearch with a different JDK. Fortunately it was accepted and released right away, so here is a fully compatible build: everything else already worked.
~I'll start a full build soon to demonstrate that it works.~ => Done, see here: http://ci.hibernate.org/blue/organizations/jenkins/hibernate-search/detail/PR-1897/2/pipeline
For now, I'd rather keep the JDK13 as experimental (= not run on master) and run a separate weekly job to check compatibility, because I expect most of the breaking changes in JDK13 are still to come.

Note the build only failed because of AWS support, which isn't implemented yet. So everything is fine.

Pull Request Test Coverage Report for Build 2

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.006%) to 88.46%

Files with Coverage Reduction
New Missed Lines
%

backend/elasticsearch/src/main/java/org/hibernate/search/backend/elasticsearch/orchestration/impl/ElasticsearchBatchingSharedWorkOrchestrator.java
1
70.24%

Totals

Change from base Build 155:
-0.006%

Covered Lines:
15545

Relevant Lines:
17573

💛  - Coveralls

Rebased and merged thanks

Thanks!


Fixes to quickstart documentation

Minor fixes to quick start doc

Mention that the minimum java version supported is 1.7
Provide http link for the github repository instead of the "git@github" link.

Make same changes in README.

and make sure the default port in the examples are correct (should probably be 15158 now?)

The default is still 1174 so I don't think that change is required.

Thanks for fixing this @nareshbafna


wander --version shows "devel" when built from a tag tarball

Describe the bug
When built outside of the git repo, Buildinfo doesn't populate the version info properly, so the version info is wrong.
To reproduce
Steps to reproduce the behavior:

download the source code tarball generated by github for a tag (example: https://github.com/robinovitch61/wander/archive/refs/tags/v0.11.1.tar.gz)
extract and build
wander --version returns wander version devel

Expected behavior
wander --version returns wander version v0.11.1
Please complete the following information:

OS: Void Linux
Terminal: irrelevant
Version: v0.11.1 bilt from source
Configuration options used: irrelevant

thanks for this @classabbyamp , I'll look into fixing it asap

comparing wander with another popular tui, glow, this behavior is replicable unfortunately, even when cloning the git repo and building off a tagged commit, as they embed version info using ldflags in goreleaser
git clone https://github.com/charmbracelet/glow.git
cd glow
git checkout ad21129703d0bd48a9b45227f56d2737623db57b
go build
./glow --version
glow version unknown (built from source)

The way I do it in wander is a bit better - if there is a git repo, the version will include the hash:
git clone --depth 1 git@github.com:robinovitch61/wander.git
cd wander
go build
./wander --version
wander version rev-09a66a4

That's because I'm using the versioninfo package

Fortunately, with the changes brought in with Go 1.18, now there is a special field just for the main module that will include version control information if it’s available...
One, you can always opt out of including version control information by passing -buildvcs=false to go build. By default, tests don’t include version control information, because it can take some time to include it, and you usually don’t want it.
Two, the build information will just be a Git revision hash (or equivalent for other version control systems), not a Git tag, because you could have multiple tags for the current commit, but there is only one hash for the current commit, so the hash is less ambiguous.
Three, on the other hand, when you install a remote Go binary using go install<EMAIL_ADDRESS>it won’t have any version control information, since it was downloaded and built from Go modules, and not from a version control system. In those cases, you can instead read the BuildInfo.Main.Version which will have the Git tag that was used to publish as a Go module.

My question for you @classabbyamp is why want to build from source code without cloning the git repo? Do any of these alternatives work for you?

go install<EMAIL_ADDRESS>go install github.com/robinovitch61/wander@latest
the git clone method to get the exact commit rather than the latest tag:

git clone --depth 1 git@github.com:robinovitch61/wander.git
cd wander
go build
./wander --version
wander version rev-09a66a4

downloading the pre-built linux binary from the releases page directly, e.g. wander_0.11.1_Linux_*.tar.gz

I am building this as a package for void linux: https://github.com/void-linux/void-packages/blob/master/srcpkgs/wander/template (the script that does the go building is here: https://github.com/void-linux/void-packages/blob/master/common/build-style/go.sh)
by policy, we do not use git repositories or go install as sources for our packages, as we like to be able to do things like cache the tarball. the usual way we do version embedding for go packages is by using go ldflags to specify the version. I guess my preferred solution would be to have an ldflag fallback for this, so that it can be specified when buildinfo won't work

Gotcha!

I guess my preferred solution would be to have an ldflag fallback for this, so that it can be specified when buildinfo won't work

by this do you mean that you'll specify your own ldflags to go build, something like go build -ldflags="-X 'main.Version=v0.11.1'"?

correct, that solution would work nicely

thanks! we'll pick it up in the next release

sweet, released in v0.11.2 with docs in readme


feat: let delegate_noop can handle constGeneric

the macro of delegate_noop cannot handle like
struct A<const X: unsize>, such kind of struct, so I want to fix it

Thanks, the principle looks good, I'll take some time later to carefully review the macro.
More generally for this change, would you mind:
* Add some text in the documentation of the macro explaining how to use it

* Introduce the same change in `wayland-server` as well which has a similar macro

* Add relevant entries to the changelog of the two crates

Sure, I am happy to do this

I'm not sure about that, it seems to me that the pattern you used, $(@< $( const $lt:tt $( : $clt:tt $(+ $dlt:tt )* )? ),+ >)? would match a list like const U: usize, const V: usize, ..., but not a list mixing const arguments and regular type arguments?

Ah.. I see, I fogot that generic types can be muti types..

Ok, now it is ok.. I try add muti generic type,
like
struct A<const X: usize, Y: Sized, Z> {
     it: Z
}

it seems ok


dsc2 doesn't like R NULL objects

File
dsc_null_error.zip
Code
dsc_null_error$ dsc exec settings.dsc
INFO: Constructing DSC from settings.dsc ...
INFO: DSC exported to settings.html
INFO: Building output database dsc_result.rds ...
INFO: Elapsed time 0.402 seconds.
ERROR: 'list' object has no attribute 'shape'
ERROR: 'list' object has no attribute 'shape'

This is tricky. This patch b994d884f0be0c997b9d4971aecc956e716b27ac currently ignores NULL results. But later today I'll try to convert NULL to NA first and throw an error message when I detect problematic dimensions when combing multiple data.
Same as #24 The problem is again in building the final data base with Python. Python / Numpy does not have NULL or NA types. All it has is NaN. So:
NA
For NA data in R I convert them to NaN when generating the query database.
NULL
NULL in return may result in undesirable behavior. For example in one data set:
res <- c(1, 1)

you end up with a vector of 1, 1. But if the return in another data set:
res <- c(NULL, 1)

then you end up with a scale of 1 because NULL will be ignored. The right way to do this for the 2nd data set is
res <-c(NA, 1)

So that DSC2 can properly put together results from different parameter combinations of the same step into a table format.
But DSC2 has no control over user's behavior. Later today I'll change the DSC2 code such that it converts NULL to NA when the return is NULL; and it will throw an error message when down the line it runs into an issue trying to make a table out of different data-sets, for example, it will complain about NA being different in length compared to 1 1.

Implemented as proposed above. Let me know if you dislike the behavior @dcgerard


Bug: rate limiter is not working as expected

Feature
rate limiter is not working as expected,
need to add provide class with ThrottlerGuard
Helplful resources
https://portswigger.net/web-security/csrf
Tasks

[x] Implementing the feature
[x] Completion of the task

commit : https://github.com/canmertinyo/memo-pal/commit/ae8ab082dda5dbf6e51e3a6aeca4df6fc8ed1a77


style(Form): update typings and propTypes usage

This PR is part of work for removing propTypes in production bundle (#524, #731).
Also, cleanups and updates typings for #1072.
Fixes #1304.

Codecov Report

Merging #1320 into master will decrease coverage by -0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1320      +/-   ##
==========================================
- Coverage   99.75%   99.75%   -0.01%
==========================================
  Files         140      140
  Lines        2402     2400       -2
==========================================
- Hits         2396     2394       -2
  Misses          6        6

Impacted Files
Coverage Δ

src/collections/Form/FormField.js
100% <ø> (ø)
:white_check_mark:

src/collections/Form/FormRadio.js
100% <ø> (ø)
:white_check_mark:

src/collections/Form/FormInput.js
100% <ø> (ø)
:white_check_mark:

src/collections/Form/FormDropdown.js
100% <ø> (ø)
:white_check_mark:

src/collections/Form/FormTextArea.js
100% <ø> (ø)
:white_check_mark:

src/collections/Form/Form.js
100% <ø> (ø)
:white_check_mark:

src/collections/Form/FormGroup.js
100% <ø> (ø)
:white_check_mark:

src/collections/Form/FormCheckbox.js
100% <ø> (ø)
:white_check_mark:

src/collections/Form/FormButton.js
100% <ø> (ø)
:white_check_mark:

src/collections/Form/FormSelect.js
100% <ø> (ø)
:white_check_mark:

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 17a5775...f1a099d. Read the comment docs.

I've checked Form typings with compiler and fixes issues.

Rebased to master and added some typings cleanups.

What about this comment, do we still have the conflicting input prop typing issue due to the FormFieldProps extending the InputProps?

Nope.

Thanks, that was obvious :P

Released in<EMAIL_ADDRESS>


task: [querier] design and write some queries for the neo4j graph

We need to come up with a design on how queries will happen and examples of the interfaces that would be required for it. Example queries are that as in the usecase section of the GUAC design doc.

Addressed by https://github.com/guacsec/guac/pull/162


Unable to recreate coverage report (--coverage) after failing tests

Hello there,
New poster here... for some reason, after running PL/SQL tests that failed (once, maybe twice), I'm no longer able to recreate coverage report for (my | any) PL/SQL test project, even after subsequent success of (running | all) tests.
I tried the following...

Deleted 'coverage' folder and restarted tests with --coverage
Deleted 'coverage' folder contents (not the folder itseif) and restarted tests with --coverage
Restarted tests with --coverage and C:\Temp\AnyBlankFolder argument
Created a new, blank project, with plsql-spec init, then created a new _spec.rb then restarted tests with --coverage
Reinstalled ruby-plsql-spec by force, with gem, bundler then both

...to no avail. Note that...

'coverage' folder and files are recreated except index.html file, which is the coverage report itself.
I can still run tests and (re)create normal test reports

So...

What am I doing wrong ?
What would cause the inability of ruby-plsql-spec to recreate coverage report ?

DBMS_PROFILER is likely working, as coverage reports used to be working BEFORE my first failing tests. Also, my privileges are barely sufficient to run tests and create required artifacts in my schema, and haven't changed. Ever.
Thank you.

The issue has been resolved. Root cause still unknown.


add compatibility for psr/http-message 2.0 version

Feature Request

Q
A

Package
yes

New Feature
yes

BC Break
???

Proposal
add compatibility for psr/http-message 2.0 version

@monta990 there's already work in progress for that see PR #110

@nyamsprod it would have been better to have a version supporting both 1.1 and 2.0 of the interface to make it easier to avoid dependency hell with packages wanting incompatible versions of the interfaces.
This might probably even be possible as a 6.9.0 release.

and this dependency hell becomes even worse when considering that the new version supporting 2.0 (and only 2.0) is a new major version of the package.

@stof thanks for the heads up I updated the dependencies to support ^1.1.0 since it does not break the current code I am ok with the change as it improve migration path.

great. Thanks