history.push cannot replace full url

Version
4.2.2
Test Case

/*<base href="http://<IP_ADDRESS>">*/
export function historyPushState(state = {}, title = '', url = '') {
  let baseTag = document.getElementsByTagName('base')[0];
  if (!!baseTag) {
    let realRequestDestination = baseTag.getAttribute('href');
    let maskedRequestDestination = window.location.origin;
    if (maskedRequestDestination !== realRequestDestination) {
      return history.pushState(state, title, `${realRequestDestination}${url}`);
    }
  }
  return history.pushState(state, title, url);
}

export function historyPush(reactRouterHistory = {}, url = '') {
  let baseTag = document.getElementsByTagName('base')[0];
  if (!!baseTag) {
    let realRequestDestination = baseTag.getAttribute('href');
    let maskedRequestDestination = window.location.origin;
    if (maskedRequestDestination !== realRequestDestination) {
      return reactRouterHistory.push(`${realRequestDestination}${url}`);
    }
  }
  return reactRouterHistory.push(url);
}

Steps to reproduce
Hej,

the historyPushState can replace browser's url to another url e.g. http://<IP_ADDRESS> to http://localhost; while historyPush can replace the url's path e.g. http://localhost/path?a=b1 to http://localhost/another/path?a=b2

if there is base tag in the entry html file, and the base tag having a different href attribute than the url in the browser, history push will complain Same Origin Policy violation

with historyPushState , I can by pass the step 2 error, but I cannot use the same logic for historyPush  i.e. with react-router's history push function.

Assume in my browser, I have url http://localhost, and in the base tag, I have href as http://<IP_ADDRESS>.
Then, with historyPush  I will get something like http://<IP_ADDRESS>/http://<IP_ADDRESS>
I guess there are other approaches out of react-router, like I can make update the base tag to be the same as the browser's url at the entry point, but sometimes, this is not always true, and sometimes, assuming the base tag is fixed.
Expected Behavior
I was expecting the react-router's history push acts like history.pushState that can also replace the full url.
Actual Behavior
I will get something like http://<IP_ADDRESS>/http://<IP_ADDRESS> (a url appended to another url)

history.pushState follows the same origin policy, so that is not correct. It will return an error like this:

history.pushState({}, 'test', 'https://test.com')

Uncaught DOMException: Failed to execute 'pushState' on 'History': A history state object with URL 'https://test.com/' cannot be created in a document with origin 'https://github.com' and URL 'https://github.com/ReactTraining/react-router/issues/6081'.

Check step 2, substep 4 of the specification: https://www.w3.org/TR/2011/WD-html5-20110113/history.html#dom-history-pushstate


Git Version maybe wrong

[Enter feedback here]
I think the stated minimum git version (2.9) should be 2.29?

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

ID: 3c2716bd-7d12-138f-9839-77f2aa400deb
Version Independent ID: 1dfa640a-7206-ba69-52a2-799402a751b3
Content: Deploy a build and release agent on macOS - Azure Pipelines
Content Source: docs/pipelines/agents/v2-osx.md
Product: devops
Technology: devops-cicd-agents
GitHub Login: @steved0x
Microsoft Alias: sdanie

investigating

@QiMata Thank you for letting us know, this will be fixed today (both on here and on the Linux agent page).


Fixed #35754 -- Mapped full-width characters in latex to half-width.

Trac ticket number

ticket-35754
Branch description
Prior to the proposed change, pdf documentation builds rendered curly quotes as full-width due to an issue in ctex latex package: https://github.com/CTeX-org/ctex-kit/issues/389. Relevant mappings are added to convert full-width characters to half-width.
Checklist

[x] This PR targets the main branch.
[x] The commit message is written in past tense, mentions the ticket number, and ends with a period.
[x] I have checked the "Has patch" ticket flag in the Trac system.
[ ] I have added or updated relevant tests.
[ ] I have added or updated relevant docs, including release notes if applicable.
[ ] I have attached screenshots in both light and dark modes for any UI changes.

I've gone through the contribution checklist, but I'm not entirely sure if this should be considered for backport. What do you think?

I've gone through the contribution checklist, but I'm not entirely sure if this should be considered for backport. What do you think?

We sometimes backport Documentation fixes to the latest stable branch but the merger will decide if this qualifies.
How can I run this locally to generate the pdf of the docs?

How can I run this locally to generate the pdf of the docs?

cd docs
make latexpdf
ls _build/latex/django.pdf

Where can we see a PDF generated with the fix?

Here is one from my local build: django.pdf

Thanks. The bug seems fixed also opening with my PDF reader in Linux.

How can I run this locally to generate the pdf of the docs?

cd docs
pip install -r requirements.txt
make latexpdf
ls _build/latex/django.pdf

Note: You may also want to install latex engine related dependencies mainly: texlive and fonts-symbola.
Edit: Added external dependency notes.

Thank you I was struggling with the dependencies :star:


Managed PostgreSQL database need self-signed certificate in certificate chain

⚠ Please verify that this bug has NOT been raised before.

[X] I checked and didn't find similar issue

🛡 Security Policy

[X] I agree to have read this project Security Policy

📝 Describe your problem
I have a managed PostgreSQL database on DigitalOcean... the server needs a mandatory SSL connection
I get this error when I try to connect to the "self-signed certificate in certificate chain"
I created a self-signed certificate and tried to set an environment var path... but when I start the container I get an error and it won't start
I used these variables: UPTIME_KUMA_SSL_KEY and UPTIME_KUMA_SSL_CERT...
I copied the .key and .crt files to the Ubuntu server folder... but the container can't seem to find them.
Should I copy them into the container?
...or did I go the wrong way?
📝 Error Message(s) or Log
self-signed certificate in certificate chain
🐻 Uptime-Kuma Version
1.23.6
💻 Operating System and Arch
Ubuntu 22.04.2
🌐 Browser
Chrome
🐋 Docker Version
No response
🟩 NodeJS Version
No response

The environment variables are not used for connecting monitor targets, but for enabling TLS when accessing Uptime Kuma.
Have you tried adding sslmode=no-verify as a parameter in your connection string?

The environment variables are not used for connecting monitor targets, but for enabling TLS when accessing Uptime Kuma.
Have you tried adding sslmode=no-verify as a parameter in your connection string?

wow works! ... but it's strange because sslmode=required was a mandatory parameter about the documentation.

If you don't want to disable certificate verification, you can try using the environment variable NODE_EXTRA_CA_CERTS=<path to your .crt>. The file needs to be inside the container.

thanks @chakflying  I will try also this way


refactor: adding a pseudo mobile version

Chaning few things, I need a good working version for Denver.

added a mobile version (no debugging, no instructions, easier verification, less real estate)
all examples work now
proving toast doesn't hang

For a mobile version, we should stop the instruction page appearing on the first screen. Because the developer will need the code area primarily and the input/output area secondarily but the instruction section is taking more space instead.


Added new curriculum explainer styling in overview tab

Description
Added new curriculum explainer styling sticky contents and new partners footer in overview tab

Added new partner styling
Curriculum explainer typography styles
Sticky contents pane
Color changes to header

Issue(s)

CUR-892
CUR-895 (only UI part)
CUR-893

How to test

Check for regressions in cycle 1
Test tickets linked above with ENABLE_CYCLE_2 enabled

Screenshots
https://github.com/user-attachments/assets/8d8b981b-8c94-4298-a1da-e08ba3f24753

:tada: This PR is included in version 1.564.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Chunks of xyz.md are not valid / Exception raised while retrieving chunks

I've updated to 0.23.23 today on both my Windows desktop and Android mobile (using couchdb backend). On my desktop I've rebuild the remote database and I'm now trying to fetch it from my mobile to rebuild the local database but am getting thousands of "Chunks of xyz.md are not valid" and "Exception raised while retrieving chunks" messages.
(1) The continuous wall of toasts make the app unusable until it eventually stops. I see some dialogs from livesync pop up behind the toasts, but they're unreadable and unusable.
(2) Am I toast, and will I have to rebuild everything from scratch? Or are there suggestions for how to recover?

I did a "rebuild everything" on the desktop which took a while, but after that my mobile was able to pull again. Side benefit is that the database is now 10x smaller (not sure what happened there...)

This helped me, thanks!

Sorry for being late! This problem has been fixed at v0.24.0. And, Rebuild everything is the best way bring everything back to fine! (But it were possibly a bit of danger if it had not been synchronised for a while. Secondary way is Resend chunks on the Hatch pane. This would be safe).
Would you mind if I ask you to upgrade to the latest version and check the behaviour, please?

No, this doesn't work. I am still getting "Chunks are invalid"


CUDAMatrix.init_random crashes on Windows with Python 3

I have successfully installed the latest cudamat from the master branch (pip reported cudamat-0.3). My environment is:

Windows 10 64-bit
Anaconda Python 3.4.4 (64-bit)
Using Visual Studio 2010 (AKA v. 10.0)
CUDA 7.5
GeForce GTX 650 Ti

I am using Python 3.4 because neither Visual Studio 9.0 (required for Python 2.7) nor Visual Studio 14.0 (required for Python 3.5) is supported by CUDA 7.5.
The compilation goes fine, so do all the tests but one: test_random.
This test crashes the process on the call cm.CUDAMatrix.init_random(1)
Within init_random the offending line is:
        err_code = _cudamat.init_random(CUDAMatrix.rnd_state_p,
                                        ct.c_int(seed),
                                        cudamat_path)

The reason is that  cudamat_path is Unicode under Python 3, while _cudamat.init_random has signature
int init_random(rnd_struct* rnd_state, int seed, char* cudamatpath)
When I change the function signature to
int init_random(rnd_struct* rnd_state, int seed, wchar_t* cudamatpath)
and use _wfopen instead of fopen within the function, everything works fine.
This is just a quick fix, not a solution; a proper solution should work for both Python 2 and 3 series, as well as Windows and non-Windows OS-es.

I am using Python 3.4 because neither Visual Studio 9.0 (required for Python 2.7) nor Visual Studio 14.0 (required for Python 3.5) is supported by CUDA 7.5.

I think these versions should be independent -- you should be able to use any nvcc-supported compiler for the CUDA code. We're just creating a shared library (or DLL) to be loaded via ctypes, not a complete Python module.

The reason is that cudamat_path is Unicode under Python 3

Oh, nice catch! Maybe an easier solution will be to convert the path to a byte string in Python 3, so we can use the same compiled library for Python 2 and 3. Maybe it would even be enough to declare the argument types for ctypes and it will do the conversion automatically.
Would you be willing to try finding a solution that modifies the Python code only? I currently don't have a Windows box with CUDA to work on, but I can at least check Python 2 and 3 under Linux.

I am using Python 3.4 because neither Visual Studio 9.0 (required for Python 2.7) nor Visual Studio 14.0 (required for Python 3.5) is supported by CUDA 7.5.

I think these versions should be independent

Good to know. However, my understanding was that the problem was not so much which compiler is used but which C runtime standard library the code is compiled against. cudamat uses e.g. fopen, which is in the C lib, and it is better if it is the same C lib version that python.exe uses.
Anyway, I will get Python 3.4 working here and then submit a pull request. A quick look at the code makes me think there may be more places where Python 3 unicode handling will cause problems. Maybe I will do a code review to check them out. One thing that got my attention is:
def get_last_cuda_error():
    return str(_cudamat.get_last_cuda_error())

I believe it will not work as expected in Python 3 but I will have to test it.
Good you can test the changes under Linux. At the moment, I do not have a Linux box with CUDA GPU.

Maybe it would even be enough to declare the argument types for  ctypes  and it will do the conversion automatically.

I don't think there is ever an automatic conversion from Unicode to byte string, because it depends on required encoding.

cudamat uses e.g. fopen, which is in the C lib, and it is better if it is the same C lib version that python.exe uses.

Hmm, if cudamat doesn't pass on its file pointers to parts linked against a different C library, everything should be fine, shouldn't it?

A quick look at the code makes me think there may be more places where Python 3 unicode handling will cause problems.

This is entirely possible. #43 didn't stumble across this. Maybe the problem with the path string you found is actually limited to Windows?

I believe it will not work as expected in Python 3 but I will have to test it.

In case it doesn't work, I'd be fine with adding a very basic if sys.version()[0] == 2 check on spot to determine the return type to use (but again, maybe ctypes can handle this for us).

I don't think there is ever an automatic conversion from Unicode to byte string, because it depends on required encoding.

Turns out there is:

For example, a c_char_p item in the argtypes tuple will convert a unicode string passed as argument into a byte string using ctypes conversion rules.

A side question is whether this will break cudamat when installed to a directory containing unicode characters. In Linux, it seems UTF8 is the way to go:
$ mkdir -p bäm/foo
$ python3
>>> import os
>>> os.listdir('bäm')
['foo']
>>> os.listdir('bäm'.encode('utf8'))
[b'foo']
>>> os.listdir('bäm'.encode('utf16'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: listdir: embedded NUL character in path

Not sure what happens under the hood, though.

Not sure what happens under the hood, though.

Tried the same with init_random. It doesn't even check if the file can be opened successfully:
>>> cm.init_random(cudamat.CUDAMatrix.rnd_state_p, ctypes.c_int(123), '/does/not/exist')
0
>>> cm.init_random(cudamat.CUDAMatrix.rnd_state_p, ctypes.c_int(123), '/tmp/bäm/rnd_multipliers_32bit.txt')
0
>>> cm.init_random(cudamat.CUDAMatrix.rnd_state_p, ctypes.c_int(123), '/tmp/bäm/rnd_multipliers_32bit.txt'.encode('utf8'))
0
>>> cm.init_random(cudamat.CUDAMatrix.rnd_state_p, ctypes.c_int(123), '/tmp/bäm/rnd_multipliers_32bit.txt'.encode('utf16'))
Segmentation fault (core dumped)

But again, it likes UTF8, and probably unicode is passed as an UTF8-encoded string if we don't encode it to a bytes string ourselves.

cudamat uses e.g. fopen, which is in the C lib, and it is better if it is the same C lib version that python.exe uses.

Hmm, if cudamat doesn't pass on its file pointers to parts linked against a different C library, everything should be fine, shouldn't it?

Yes. It should. However, it is not that simple. I just tried to install cudamat under Python27 from Anaconda: pip/setuptools insist on using VC2009 libs and includes, but then nvcc refuses to compile claiming VC2009 is not supported. Maybe it is Anaconda-specific problem. Maybe there is a workaround, but I am not going to pursue it; unfortunately, this means I cannot check changes under Python27 on Windows.

But again, it likes UTF8, and probably unicode is passed as an UTF8-encoded string if we don't encode it to a bytes string ourselves.

When using unicode paths in Python 3, they will be automatically converted to proper byte encoding depending on filesystem encoding. On Linux it will be whatever is configured by LC_LANG or other LC_* (which for most modern Linuxes will be UTF-8). On Windows it will be MBCS.

For example, a c_char_p item in the argtypes tuple will convert a unicode string passed as argument into a byte string using ctypes conversion rules.

This means it may get it right, indeed. I tried with:
_cudamat.init_random.argtypes = [ct.POINTER(rnd_struct), ct.c_int, ct.c_char_p]

But it does not work:
======================================================================
ERROR: test_cudamat.test_random
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Tools\Anaconda\envs\cudamat34\lib\site-packages\nose\case.py", line 198, in runTest
    self.test(*self.arg)
  File "C:\Code\NVIDIA\cudamat\test\test_cudamat.py", line 1089, in test_random
    cm.CUDAMatrix.init_random(1)
  File "C:\Tools\Anaconda\envs\cudamat34\lib\site-packages\cudamat\cudamat.py", line 255, in init_random
    cudamat_path)
ctypes.ArgumentError: argument 3: <class 'TypeError'>: wrong type

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

Did I get the argtypes wrong?
My current solution is:
        if sys.version_info.major >= 3:
            cudamat_path = cudamat_path.encode(sys.getfilesystemencoding())

It works fine.

It doesn't even check if the file can be opened successfully:

Segmentation fault (core dumped)

Therefore I want to propose adding test if the result of fopen is NULL and return an error code if it is. The error code will then be converted to a regular python exception, rather than triggering a core dump. I can submit a PR for it too.

pip/setuptools insist on using VC2009 libs and includes, but then nvcc refuses to compile claiming VC2009 is not supported.

Ah, sorry, I forgot how things were set up in cudamat. I think the solution will be #53, so cudamat doesn't use setuptool's C compiler machinery -- nvcc is platform-independent already, supporting the same command line arguments for Windows and *nix, so we can use it directly.

When using unicode paths in Python 3, [...]

Thanks for the explanation!

Did I get the argtypes wrong?

Looking further, it seems "unicode string" may refer to the unicode type in Python 2 only: http://stackoverflow.com/questions/27285405/how-can-ctypes-be-used-to-parse-unicode-strings#comment43039374_27285405
That comment also tells what the mysterious "ctypes conversion rules" are referring to: https://docs.python.org/2/library/ctypes.html#ctypes.set_conversion_mode
The default encoding for Windows is mbcs, which would be fine -- so most probably it is just not triggered at all for Python 3 str objects.

My current solution is:

That's fine by me, go for it! This will work in Linux as well.

Therefore I want to propose adding test if the result of fopen is NULL and return an error code if it is.

Yes, please, this would be appreciated! You can just include this in a single PR of two commits.


fix: generate_cc_impl() presumes all BUILD files were in some subdire…

Bug FIxes:

generate_cc_impl() presumes all BUILD files were in some subdirectory

@nicolasnoble please take a look and approve if it looks good


Update dependencies and workflows

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (207fd86) to head (5bbc204).

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #65   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           11        11
  Lines          368       368
  Branches        44        44
=========================================
  Hits           368       368

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Matching package to framework

Is there a particular reason why you're matching the packages to the framework?
For example Microsoft.Extensions.Caching.Memory 8.0.0 is supported by netstandard2.0, so you may as well have this for all versions. You should try to target as few frameworks as possible in your csproj which would reduce the size of your NuGet package, leading to no performance loss on .NET 8.0 but on earlier frameworks they will make use of potential performance gains from the latest packages.

@MarkCiliaVincenti Thanks for pointing this out.
Basically, I put those conditions to not break the applications that use the package.
I need to test it for different versions.


add a line to docs about passing event handlers

Discovered that I can do this -
<Flex props={{onClick: ()=> alert('event handlers!') }}/>

Very cool! please add a line to the docs to let people know? Please and thanks!

That's an arrow function and it works for any project that uses an ES6 shim. But you can define a function inline in ES5 as well:
<Flex props={{onClick: function() { alert('event handlers!') }.bind(this) }} />
Regardless, it isn't specific to jsxstyle, it's just ES6.

Sorry if I wasn't clear. Point wasn't about the arrow function, but that I could define event handlers for a Flex component via the props prop. This is not mentioned in the docs anywhere.

Ah, I see. You can pass any prop via the props prop since it's just merging them. However, unless he's recently fixed it I believe there's still a bug such that a props tag will be added to your style, so you'll end up with a style tag like style=...props:[object Object]....

Seems like it should know which props a DOM node accepts and pass those through rather than putting them on style.
For instance, ref, key, and anything starting with on should be ignored by jsxstyle and passed through unmolested.

More discussion in #32


Warp sync part I

Closes #1208
Initial support for syncing with GRANDPA warp sync protocol. It works as follows:

Download and verify finality proofs up to  the latest finalized blocks.
Download and whole state snapshot for the block that is proven to be final.
GRANDPA and BABE are reset with authority set and epoch information read from the imported state.

Still left to do in the following PR:

Support for syncing child tries.
A background process to download full block history after initial sync. This will also need to reconstruct authority set changes in sc-finality-grandpa.

Marked with B0-silent as this is still WIP and will be considered complete after the following PR.
polkadot companion: https://github.com/paritytech/polkadot/pull/3382

What's the use of warp-syncing a full node? Won't (most?) full nodes need all the blocks?

As I've mentioned in the description, full blocks will be downloaded in the background after warp sync is complete.

#1208 - does this close it?

Right, closes #1208

Since #1208 is the primary source of documentation for warp sync, it would be good to preserve that documentation either in-line in the code somewhere or in a wiki document. Otherwise, it will disappear and the basis for the code will be less apparent.

Most of what's described in #1208 was not really implemented. The actual thing is buried somewhere in the middle of the discussion there.
I've added basic description to client/network/README.md in e5991c1

@andresilva Waiting for your review

I'm skeptical of merging anything touching sync code right now. What is our maintenance plan for this code?

@rphmeier Could you please elaborate? What's the reason for scepticism?
The "maintenance plan" is the same as for the rest of the code base. Again, do you have reasons to believe the sync code is poorly maintained?

@andresilva Tests are in the following PR #9284

@rphmeier wrt maintainability, there are several isolated parts to warp sync:

Generation and verification of warp proofs. This is currently the responsibility of the sc-finality-grandpa.  It plugs into the networking with a WarpSyncProvider  interface. Maintaining this part requires GRANDPA-specific knowledge,  but not any knowledge of the networking or sync algorithm.
Networking changes. Don't require any GRANDPA specific
2.1  Request/response protocol for downloading warp proofs and state. This is a standard request/response protocol of which we already have several in sc-network.
2.2. Syncing strategy to download and verify wrap proofs and state. This is tied in to the existing sync algorithm and requires knowledge of its specifics.
Client changes that allow the chain to be reset to an arbitrary finalized state.  Requires knowledge of client/db internals, but not much else.
GRANDPA and BABE changes that allow the chain to be reset to an arbitrary state.  Requires GRANDPA/BABE knowledge.

Each of these are tested in isolation, but there's also an integration test.
Tests are/will be added in #9284

@andresilva Care to take another look?

@cheme @bkchr @andresilva Could you please take a look at the companion PR paritytech/polkadot#3382 as well?

bot merge


add packages

Automated PR Comment From BlackDuck

:x: Found dependencies violating policy!

Policies Violated
Dependency
License(s)
Vulnerabilities
Short Term Recommended Upgrade
Long Term Recommended Upgrade
Resolved

Not Required
getpass
N/A

:grey_exclamation:

Not Required
builtin-modules
N/A

3.3.0 (0 known vulnerabilities)
:grey_exclamation:

Not Required
qs -  QS Querystring
N/A

6.11.0 (0 known vulnerabilities)
:grey_exclamation:

Not Required
mime-db
N/A

1.52.0 (0 known vulnerabilities)
1.52.0 (0 known vulnerabilities)
:grey_exclamation:

Not Required
kossnocorp/date-fns
N/A

2.29.3 (0 known vulnerabilities)
:grey_exclamation:

Not Required
is-property
N/A

:grey_exclamation:

Not Required
tough-cookie
N/A

v2.5.0 (0 known vulnerabilities)
4.1.2 (0 known vulnerabilities)
:grey_exclamation:

Not Required
collection-visit
N/A

:grey_exclamation:

Not Required
tar
N/A

v2.2.2 (5 known vulnerabilities)
6.1.13 (0 known vulnerabilities)
:grey_exclamation:

Not Required
object-visit
N/A

:grey_exclamation:

Automated PR Comment From BlackDuck

:x: Found dependencies violating policy!

Policies Violated
Dependency
License(s)
Vulnerabilities
Short Term Recommended Upgrade
Long Term Recommended Upgrade
Resolved

Not Required
getpass
N/A

:grey_exclamation:

Not Required
builtin-modules
N/A

3.3.0 (0 known vulnerabilities)
:grey_exclamation:

Not Required
qs -  QS Querystring
N/A

6.11.0 (0 known vulnerabilities)
:grey_exclamation:

Not Required
mime-db
N/A

1.52.0 (0 known vulnerabilities)
1.52.0 (0 known vulnerabilities)
:grey_exclamation:

Not Required
Strip ANSI
N/A

7.0.1 (0 known vulnerabilities)
:grey_exclamation:

Not Required
babel-code-frame
N/A

6.26.0 (0 known vulnerabilities)
6.26.0 (0 known vulnerabilities)
:grey_exclamation:

Not Required
kossnocorp/date-fns
N/A

2.29.3 (0 known vulnerabilities)
:grey_exclamation:

Not Required
is-property
N/A

:grey_exclamation:

Not Required
tough-cookie
N/A

v2.5.0 (0 known vulnerabilities)
4.1.2 (0 known vulnerabilities)
:grey_exclamation:

Not Required
sindresorhus/got
N/A

12.5.3 (0 known vulnerabilities)
:grey_exclamation:

Automated PR Comment From BlackDuck

:x: Found dependencies violating policy!

Policies Violated
Dependency
License(s)
Vulnerabilities
Short Term Recommended Upgrade
Long Term Recommended Upgrade
Resolved

Not Required
whatwg-url
N/A

12.0.0 (0 known vulnerabilities)
:grey_exclamation:

Not Required
debug-js/debug
N/A

4.3.4 (0 known vulnerabilities)
4.3.4 (0 known vulnerabilities)
:grey_exclamation:

Not Required
regexp-clone
N/A

:grey_exclamation:

Not Required
mpath
N/A

0.9.0 (0 known vulnerabilities)
0.9.0 (0 known vulnerabilities)
:grey_exclamation:

Not Required
Mongoose
N/A

6.9.3 (0 known vulnerabilities)
6.9.3 (0 known vulnerabilities)
:grey_exclamation:

Not Required
sliced
N/A

:grey_exclamation:

Not Required
sift
N/A

13.5.4 (0 known vulnerabilities)
16.0.1 (0 known vulnerabilities)
:grey_exclamation:

Not Required
base64-js
N/A

:grey_exclamation:

Not Required
@types/whatwg-url
N/A

8.2.2 (0 known vulnerabilities)
11.0.0 (0 known vulnerabilities)
:grey_exclamation:

Not Required
node-mongodb-native
N/A

4.14.0 (0 known vulnerabilities)
5.0.1 (0 known vulnerabilities)
:grey_exclamation:

Automated PR Comment From BlackDuck

:x: Found dependencies violating policy!


Add subsection and fix append

subsection
subsection will work by taking in two ints and a list and returning the subsection of that list.
append
For some reason append is not a void function, which is slightly annoying

Closed as of #182


Disallow making chosen expiration dates earlier than the current date

Update - Aug 16, 2023
Previously issue was looking to disallow expiration dates, but thinking further there could be times when users simply wanted to store their old document onto their Pod storage. For these older documents with expirations dates past current date, we could simply display a warning somewhere in the row for the documents table to indicate that it's expired or a warning somewhere near the expiration date.

There is a pretty simple tweak to the MUI DatePicker component to restrict past dates from being selected. Is this something that we want to do via scripting in addition to just modifying the selector? A creative user can wipe the MUI classes off the html element and it seems to accept a past date just fine:

@andycwilliams I've left the opening description blank since I'm not sure of the details when it was a draft, feel free to fill in what your original idea was. @cameronabel would be interested in working on this.

There is a pretty simple tweak to the MUI DatePicker component to restrict past dates from being selected. Is this something that we want to do via scripting in addition to just modifying the selector? A creative user can wipe the MUI classes off the html element and it seems to accept a past date just fine:

Are you saying people can get around the disablePast prop?

I think the onError styling and helperText would also be ideal to add during this PR
https://mui.com/x/react-date-pickers/validation/#show-the-error

There is a pretty simple tweak to the MUI DatePicker component to restrict past dates from being selected. Is this something that we want to do via scripting in addition to just modifying the selector? A creative user can wipe the MUI classes off the html element and it seems to accept a past date just fine:

Are you saying people can get around the disablePast prop?

Yes. The screenshot in my post above was taken with disablePast enabled. I was then able to use the browser dev console to strip the field of all MUI classes and upload a file with a past expiration date.

I still somewhat hesitant about this idea.
Of course, users would probably want to update their latest documents in order to be verified and validated, so the idea would be useful in those cases.
But I could also see a case where users just want to upload their older documents for storage purposes regardless of expiration.

I kind of agree with Ka Hung's last comment. I don't really see a value in preventing a user from uploading an expired document. Maybe display a warning in the documents table if it is expired?

shall we discuss soon and decide to either close this issue, or a direction for it?

Based on the user population, I think they need to store expired docs. A scan of an expired passport for example is still a valuable form of identification.
Maybe this isn't necessary, but could we just add a warning ⚠ icon to the document upload form if an expiration date earlier than the current date is selected? We could also display the document status with the same icon on the document table.

Update - Aug 16, 2023
Previously issue was looking to disallow expiration dates, but thinking further there could be times when users simply wanted to store their old document onto their Pod storage. For these older documents with expirations dates past current date, we could simply display a warning somewhere in the row for the documents table to indicate that it's expired or a warning somewhere near the expiration date.

Basically exactly what @leekahung updated the issue to on Aug 16th.

Hey @cameronabel how's progress going with regards to this issue?

@leekahung I have an idea for this one; I'll take a stab at it too.

@ogorman89 did you implement a PR for this? If so we can close this issue.

@timbot1789 Apologies, I forgot about this one.
The only reason this is still open was that I was going to add a notification if a user tried to upload an expired document. Something like the screenshot below.
After thinking about it more, I think it's better without the warning.
If you agree, then I say we close it for now.

@timbot1789 Apologies, I forgot about this one.
The only reason this is still open was that I was going to add a notification if a user tried to upload an expired document. Something like the screenshot below.
After thinking about it more, I think it's better without the warning.
If you agree, then I say we close it for now.

No worries. And yeah that sounds like a different issue to me. Basically "how should we display expired documents to users?" I like your idea of a notification, but we may also want to display something in the doc table itself.


List Permissions endpoint returns 400 Bad Request in some tenants

Category

[ ] Question
[ ] Documentation issue
[x] Bug

Expected or Desired Behavior
I expect the list permissions API endpoint to work consistently for all tenants.
Observed Behavior
For some tenants that we work with, the list permissions endpoint is returning 400 Bad Request error for any drive items.
Request/Response:
{
  "status": "fail",
  "method": "GET",
  "uri": "https://{tenant}.sharepoint.com/_api/v2.0/sites/{site}/drives/{drive}/items/01UEIXTED2RCCI3IONSRD2OGKY35W47PD2/permissions",
  "request": {
    "headers": {
      "Host": "{tenant}.sharepoint.com",
      "User-Agent": "ISV|{isv}|{app}/1.0",
      "Accept": "application/json"
    },
    "body": "",
    "body_length": 0
  },
  "response": {
    "headers": {
      "Content-Length": "63",
      "Content-Type": "application/json",
      "X-SharePointHealthScore": "3",
      "X-VroomVersion": "2.0",
      "SPRequestGuid": "88de039f-e042-9000-513e-84ec289c8818",
      "request-id": "88de039f-e042-9000-513e-84ec289c8818",
      "MS-CV": "nwPeiELgAJBRPoTsKJyIGA.0",
      "SPRequestDuration": "304",
      "SPIisLatency": "8",
      "MicrosoftSharePointTeamServices": "<IP_ADDRESS>28",
      "X-MS-InvokeApp": "1; RequireReadOnly",
      "X-MSEdge-Ref": "Ref A: FB0B262898664BB69E5C8E5F5B12897E Ref B: CH1EDGE1205 Ref C: 2019-09-13T17:46:22Z",
      "Date": "Fri, 13 Sep 2019 17:46:22 GMT"
    },
    "body": "{\"error\":{\"code\":\"invalidRequest\",\"message\":\"Invalid request\"}}",
    "body_length": "63"
  },
  "code": 400,
  "reason": "Bad Request",
  "duration": 0.4474668502807617
}

Steps to Reproduce
We have seen this behaviour on some tenants while on other tenants the endpoint still work as expected. Not sure if this is something introduced recently and is just being distributed to all farms. However, reproducing that API call (on that tenant, site, drive and item) will always result on a 400 Bad Request error.
Thank you.

Thanks for your feedback.  Is this issue still reproducing?

We also detected an issue with a rollout that we addressed.

@chackman thanks for the response. I can confirm we're not seeing this behaviour on our test tenants. I'm just waiting for confirmation on our customers' tenants.

Thanks, please let us know if this issue was not resolved.

@chackman seems like this has been resolved for all our current clients as well. Closing, will re-open if I see new failures. Thanks!


BTRX - 228 - Add HMB & POA terms & logic to Data Access Request Application

Description
This code maps Poa and Hmb values to be received by ontology to make translate logic.
Also this code has its Ui part which can be seen in BTRX-228
Jira Ticket
BTRX-228-Add HMB & POA terms & logic to Data Access Request Application

[x] Submitter: Include the JIRA issue number in the PR description
[x] Submitter: Make sure Swagger is updated if API changes
[x] Submitter: Check documentation and code comments. Add explanatory PR comments if helpful.
[x] Submitter: JIRA ticket checks:

Acceptance criteria exists and is met
Note any changes to implementation from the description
Add notes on what you've tested

[x] Submitter: Update RC_XXX release ticket with any config or environment changes necessary
[x] Submitter: Update FISMA documentation if changes to:

Authentication
Authorization
Encryption
Audit trails

[x] Submitter: If you're adding new libraries, sign us up to security updates for them
[x] Tell the tech lead (TL) that the PR exists if they wants to look at it
[x] Anoint a lead reviewer (LR). Assign PR to LR

Review cycle:

LR reviews
Rest of team may comment on PR at will
LR assigns to submitter for feedback fixes
Submitter rebases to develop again if necessary
Submitter makes further commits. DO NOT SQUASH
Submitter updates documentation as needed
Submitter reassigns to LR for further feedback

[x] TL sign off
[x] LR sign off
[x] Product Owner sign off
[x] Assign to submitter to finalize
[ ] Submitter: Verify all tests go green, including CI tests
[ ] Submitter: Squash commits and merge to develop
[ ] Submitter: Delete branch after merge
[ ] Submitter: Test this change works on dev environment after deployment. YOU own getting it fixed if dev isn't working for ANY reason!
[ ] Submitter: Verify swagger UI on dev environment still works after deployment
[ ] Submitter: Inform other teams of any API changes via hipchat and/or email
[ ] Submitter: Mark JIRA issue as resolved once this checklist is completed

Coverage increased (+0.03%) to 61.984% when pulling 02aac975bb95c408c8c72d45ad4acbf9ef4d4e10 on lf-BTRX-228-addHMBAndPOA into c703725c22e04cc278a36c92f5767fdb11fc4ed1 on develop.

are there tests to add for this?

At this point, there isn't any.
Later when we use these values for summaries, and reports I'm sure we'll add tests including them, but for this instance we are only mapping values to be used by ontology. Does it sounds ok for you @ahaessly?

ok. thanks for explaining


The behaviour of Diagnostics picker is not consistent with other Pickers.

Contributing guidelines

[X] I have read CONTRIBUTING.md
[X] I have read CODE_OF_CONDUCT.md
[X] I have updated 'mini.nvim' to latest version

Module(s)
mini.pick, mini.extra, mini.tabline
Description
When selecting a diagnostic, instead of opening the file (from where the diagnostic originates) in a new tab, it opens the file in the same buffer, which is not consistent with how other pickers work (they open a new tab).
This causes problem, as when i need to switch the buffer to look at another open file, i loose the file with the error.
Is this behaviour expected, or is it a bug?
Neovim version
0.9.4
Steps to reproduce
vim.g.mapleader = ' '
vim.g.maplocalleader = ' '

local lazypath = vim.fn.stdpath 'data' .. '/lazy/lazy.nvim'
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system {
    'git',
    'clone',
    '--filter=blob:none',
    'https://github.com/folke/lazy.nvim.git',
    '--branch=stable', -- latest stable release
    lazypath,
  }
end

vim.opt.rtp:prepend(lazypath)

require('lazy').setup({
  'tpope/vim-sleuth',

  {
    'neovim/nvim-lspconfig',
    dependencies = {
      { 'williamboman/mason.nvim', config = true },
      'williamboman/mason-lspconfig.nvim',

      { 'j-hui/fidget.nvim',       tag = 'legacy', opts = {} },
    },
  },

  { 'echasnovski/mini.nvim',      version = false },

  { "nvim-tree/nvim-web-devicons" },

  { "EdenEast/nightfox.nvim" },

}, {})

local servers = {
  rust_analyzer = {},
  hls = {},
  lua_ls = {
    Lua = {
      workspace = { checkThirdParty = false },
      telemetry = { enable = false },
    },
  },
}

local mason_lspconfig = require 'mason-lspconfig'

mason_lspconfig.setup {
  ensure_installed = vim.tbl_keys(servers),
}

mason_lspconfig.setup_handlers {
  function(server_name)
    require('lspconfig')[server_name].setup {
      on_attach =
          function(_, bufnr)
            vim.cmd [[autocmd BufWritePre <buffer> lua vim.lsp.buf.format()]]
          end,

      settings = servers[server_name],
      filetypes = (servers[server_name] or {}).filetypes,
    }
  end
}
require("mini.extra").setup()
require('mini.pick').setup({
  options = {
    use_cache = true
  },
  window = {
    config = function()
      height = math.floor(0.618 * vim.o.lines)
      width = math.floor(0.618 * vim.o.columns)
      return {
        anchor = 'NW',
        height = height,
        width = width,
        row = math.floor(0.5 * (vim.o.lines - height)),
        col = math.floor(0.5 * (vim.o.columns - width)),
        border = 'double',
      }
    end,
  }
})

Expected behavior
No response
Actual behavior
https://github.com/echasnovski/mini.nvim/assets/52526849/7dded524-9d98-4c2f-b190-29c8030b85d5

Thanks for the issue!
That's not quite exactly what happens. Neovim has three main abstractions: buffer, window, tabpage. Quoting from :h windows-intro:

Summary:
- A buffer is the in-memory text of a file.
- A window is a viewport on a buffer.
- A tab page is a collection of windows.

What you see as "tabs" are buffers displayed in tabline  with 'mini.tabline'. The thing is, that only listed buffers are shown there (see :h buflisted), as that is essentially what that option is designed for.
On the other hand, some language servers and diagnostic providers can scan not only opened buffers, but other files in the project. This leads to some buffers in diagnostic entries to be unlisted. When you such entry, buffer becomes current (visible), but still unlisted (hence not showing in the tabline). If you execute :edit or setlocal buflisted, it should appear in the tabline.
Still, should not happen and I'll look into it.

This should now be fixed on the latest main.

Thanks for the explanation and for the fix.
And thanks for this awesome library. 👍


RobotFramework-Examples no more working with RF 6.1

Hi,
RobotFramework-Examples is not working anymore with the latest RF release (6.1).
Error message is:
[ ERROR ] Calling method '_start_suite' of listener 'Examples' failed: AttributeError: 'Keyword' object has no attribute 'tags'

https://github.com/robotframework/robotframework/blob/master/doc/releasenotes/rf-6.1.rst#changes-to-testsuite-model-structure
...
Another related change is that doc, tags, timeout and teardown attributes were removed from the robot.running.Keyword object (https://github.com/robotframework/robotframework/issues/4589). They were left there accidentally and were not used for anything by Robot Framework. Tools accessing them need to be updated.
...

I have made tags and timeout at keyword level optional - seems it is no longer passed through or maybe not supported in 6.1. Not sure if these did anything in the first place.
Seems to work now, but needs testing (apart from the tests in the build pipeline)


General Docs Update - Is the AzureAD PowerShell Module Abandonware?

If I go by the documents currently published for the AzureAD module, I would come to the conclusion that the AzureAD module is abandonware.

The version history document hasn't been updated since June 2020, with the last version being <IP_ADDRESS>
The published version in the PowerShell Gallery is older than what's published in the version history
There's no published roadmap to move these cmdlets from legacy .NET Framework to .NET 5+
There is no published GitHub repo for this module, as there is with every other Azure and Azure Graph related cmdlet (this module points to Microsoft Docs as the project site)
While not as intuitive as the AzureAD modules, the Microsoft.Graph PowerShell SDK has all of the above addressed, and appears to be poised to replace the AzureAD module

If I perform a Find-Module in PowerShell, I do see the latest GA version of the module to be <IP_ADDRESS>, and the latest version of the preview module to be <IP_ADDRESS>, both with a publish date of a month ago.  However, with the aforementioned issue about the documentation and roadmaps, I have no insight into what has actually changed between the ~30 revisions between the last document update and this version.
With all of the above, the only two conclusions I can see are that the AzureAD modules are abandonware, or there's some inside-politicking happening that is causing the AzureAD PowerShell Module to stand out as secluding itself from the visibility Microsoft has provided for all of its other Azure and Microsoft Graph related PowerShell projects.  If it's the latter, I want no part of Microsoft's internal strifes impacting the software I depend on for my own work.
If it's the former, can someone at least update the documentation to point to the new Microsoft Graph for PowerShell SDK project?

@aydeisen, thanks for these issues. Here are my responses;

For the version history page, we have updated it with changes from the most recent release and we will ensure to update it as new releases are done. We will also endeavor to highlight the changes in the 7 Azure AD and 6 Preview modules that have been missed in the past.
The GitHub repo for this module is Azure AD PowerShell.
There is work going into the Microsoft.Graph PowerShell SDK documentation to make it more user friendly.

We are now actively working to improve the documentation for Azure AD PowerShell because this module is not abandonware.
I hope this answers your question. I will proceed to close this issue. Feel free to reopen it if you have any further concerns.

@msewaweru
Thanks for your reply.  Just one question remains outstanding:
What's the roadmap to make the AzureAD module compatible with Powershell 7?

Hello @aydeisen, I will follow up with the team to find this out. I will let you know once I do.

@msewaweru
Thank you.  I appreciate the team's effort to bring all of this documentation up to date

Hi @aydeisen. This is to let you know Azure AD PowerShell will not updated to work with PowerShell 7. To get more info on the current and future investments please see this blogpost.


testing error

While trying to test using:
python test.py --dataroot datasets/underwater_dataset/ --cuda

I get this error:
Namespace(batchSize=1, cuda=True, dataroot='datasets/underwater_dataset/', generator_A2B='output/netG_A2B.pth', generator_B2A='output/netG_B2A.pth', input_nc=3, n_cpu=0, output_nc=3, sizeh=308, sizew=548)
Traceback (most recent call last):
  File "test.py", line 55, in <module>
    real_A = Variable(input_A.copy_(batch['A']))
RuntimeError: The size of tensor a (548) must match the size of tensor b (480) at non-singleton dimension 3

The reason for the error is that the size of the test image is not the same as the one given in test.py (line 21 & 22). As the code framework is based on the original CycleGAN, their code has fixed the sizes of the test image (e.g., 548, 308), so you need to match the width and height of test.py (line 21 & 22) to the sizes of your test image (548->480).
If the image you are testing contains different dimensions, it is recommended to modify the code to read in the image dimensions directly rather than fixing them.


I ran npm install & npm run serve but I am unable to connect to the server on port 8080 as the instructions stated

What should I do?
Starting up http-server, serving dist/
Available on:
  http://<IP_ADDRESS>:8080
  http://<IP_ADDRESS>:8080
  http://<IP_ADDRESS>:8080
Hit CTRL-C to stop the server
[Thu Feb 16 2017 16:57:55 GMT-0600 (CST)] "GET /" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36"
[Thu Feb 16 2017 16:57:55 GMT-0600 (CST)] "GET /" Error (404): "Not found"

This is the output of the log file when I go to the following address on my website:
http://<IP_ADDRESS>:8080

Hi
I suspect you didn't run npm run build before executing npm run serve
Hope this helps.

I followed your instruction and I got the following error:
Shyamals-iMac:src shyamalchandra$ npm run serve

><EMAIL_ADDRESS>serve /Users/shyamalchandra/playground
> http-server dist/

events.js:161
      throw er; // Unhandled 'error' event
      ^

Error: listen EADDRINUSE <IP_ADDRESS>:8080
    at Object.exports._errnoException (util.js:1023:11)
    at exports._exceptionWithHostPort (util.js:1046:20)
    at Server._listen2 (net.js:1261:14)
    at listen (net.js:1297:10)
    at doListening (net.js:1396:7)
    at _combinedTickCallback (internal/process/next_tick.js:77:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)
    at Module.runMain (module.js:607:11)
    at run (bootstrap_node.js:418:7)
    at startup (bootstrap_node.js:139:9)

npm ERR! Darwin 16.4.0
npm ERR! argv "/usr/local/Cellar/node/7.5.0/bin/node" "/usr/local/bin/npm" "run" "serve"
npm ERR! node v7.5.0
npm ERR! npm  v4.1.2
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>serve: `http-server dist/`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>serve script 'http-server dist/'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the deep-playground-prototype package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     http-server dist/
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs deep-playground-prototype
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls deep-playground-prototype
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/shyamalchandra/playground/src/npm-debug.log

Error: listen EADDRINUSE <IP_ADDRESS>:8080
It seems port '8080' was already in use in your environment.
You can choose either one of the following solution:

Kill the instance which uses port 8080 and run npm run serve again.
In order to find which process uses port 8080, type lsof -i :8080 in your terminal.
Then kill it by its pid.

Run http server with another port.
Make sure your current directory is root playground directory before executing the command below.
node node_modules/http-server/bin/http-server -p <port number you like to use> dist/

For example, in case you want to run server with port 18080:
node node_modules/http-server/bin/http-server -p 18080 dist/

Best regards.


How can we run an effect on every change (ignore "resistance to infinite loops")?

In the docs on the website:

Resistant To Infinite Loops: atomEffect does not rerun when it changes a value with set that it is watching

Sometimes it is desirable to re-run on every change (provided that the effect makes state changes to avoid loops):
app.tsx:
useAtom(saveEffectAtom)

...

component.tsx:
const setNeedsSave = useSetAtom(needsSaveAtom)

...

return (
    <button onClick={() => setNeedsSave(true)}/>
)

saveEffect.ts:
export const saveEffectAtom = atomEffect((get, set) => {
    const needsSave = get(needsSaveAtom)

    if (needsSave) {
        // handle save

        ...

        // this would prevent infinite loops in a typical useEffect
        // but since we're setting needsSave from the effect, it will never get re-run
        set(needsSaveAtom, false)
    }
})

Is there a better pattern for handling this?

Apologies for a possible dupe – should have made a search first (#27, #16, #26) – gonna try that behavior now and report back.

Confirming that set.recurse(...) fixes the issue for me – but with the caveat that it did not work on a single primitive value change (e.g. a single boolean needsSave that gets toggled from false to true).
It does work if you make the if condition depend on more complicated logic that needs evaluated, e.g.:
export const saveEffectAtom = atomEffect((get, set) => {
    const needsSave = get(needsSaveAtom)
    const unsavedItems = get(unsavedItemsAtom)

    if (needsSave && unsavedItems.length > 0) {

        // handle save

        set.recurse(needsSaveAtom, false)
        set.recurse(unsavedItemsAtom, [])
    }
})

In any case I'm out of the weeds here. Hope it may be helpful to others.

set.recurse should be what you are looking for.
Hmm, its a bug if it doesn't work with primitives.
Would you kindly either:
A. Open a PR with a failing test case.
B. Create a simple codesandbox that exhibits this behavior.
Please let me know, I'll take a look and hopefully will have a fix soon. 🙂
Also, how did you find the documentation? Was it intuitive or did it create some confusion? I'm looking to improve on the docs if its not easy to get started with atomEffect.

Closing this issue as the answered.


Draw the progress bar around a circular image

Hey.
I am using Twitter Bootstrap 3.2 which offers a class that turns an image into a circular view. Its not cropped or anything - but it just is styled to look like its actually round.
For my app, I'd like to draw a progress bar around such image. To be specific: I am uploading an image, and I want to show the image preview and have the progress bar surround it. This way I dont need to make extra space for a usual progress bar and can keep the content displayed minimal.
Is that possible with this plugin?
Kind regards, Ingwie

Yes, it's possible. Here is an example.
I'm going to implement more friendly way to use my plugin as a progress bar in the next version.

Awesome!
For what purpose is

though? I understand everything else though. :)

Am 16.01.2015 um 13:30 schrieb Rostyslav Bryzgunov<EMAIL_ADDRESS>Yes, it's possible. Here is an example http://jsbin.com/pofobe/1.
I'm going to implement more friendly way to use my plugin as a progress bar in the next version.
—
Reply to this email directly or view it on GitHub https://github.com/kottenator/jquery-circle-progress/issues/18#issuecomment-70247507.

It's redundant, I forgot to remove it :)

I see. :) Thanks for the demo, I am going to put your plugin in my project then so i wont forget to update it.

Am 16.01.2015 um 18:54 schrieb Rostyslav Bryzgunov<EMAIL_ADDRESS>It's redundant, I forgot to remove it :)
—
Reply to this email directly or view it on GitHub https://github.com/kottenator/jquery-circle-progress/issues/18#issuecomment-70293225.


some random rules for element rendering?

I have always seen some weird behaviors in the choosing of which tile elements to render.
Now here is an example.
In this video i am only panning the map. As you can see the "Gibert Joseph" poi and house number next to it randomly appear / disappear when i hide / show them.
I say randomly but i think it related to the order the tiles are rendered.
I think it should always be rendered (which is what i want).

In general panning the map may change the visible texts as texts have different weights and texts from new tiles may hide some existing texts which in turn may allow displaying texts with lower priorities. I have some changes to text clipping method that will be in SDK 4.2.1RC2.

It seems much better now. Dont know if it is theme related of sdk related...
Will close this for now


Update contributing details

Is your feature request related to a problem? Please describe.
Contributing instructions are outdated.
Describe the solution you'd like
We should add convention for the committing style.
Example 1: https://www.conventionalcommits.org/en/v1.0.0/
Example 2: https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines

@djs0109 What do you think? And should we use the convention used by Angular?
Defining at least a couple of commit formulation conventions (e.g., chore and docs) in the contributing details would be helpful for the seamless integration of new FiLiP developers. :)

@Maghnie yes, it is indeed meaningful. One direct use case will be the semantic-release tool. I think the one suggested by conventionalcommits.org is a good start. Our developers also had experience with it.


Follow up for the CMake refactoring

:notebook_with_decorative_cover: Description

A few name changes weren't applied globally
VAST_ENABLE_ASSERTIONS was broken.
Unconditionally enable -Wundef
Move defines back to config.hpp
Synchonize definition names between CMake and C++

:memo: Checklist

[x] All user-facing changes have changelog entries.
[x] The PR description contains instructions for the reviewer, if necessary.

:dart: Review Instructions
By commit.

The new CMake summary prints this:
-- The following features have been enabled:

 * VAST_ENABLE_RELOCATABLE_INSTALLATIONS, enable relocatable installations.
 * VAST_ENABLE_SDT, generate USDT tracepoint instrumentation.
 * VAST_ENABLE_ASSERTIONS, enable assertions.
 * BUILD_SHARED_LIBS, build shared instead of static library.
 * VAST_ENABLE_DEVELOPER_MODE, enables build settings for a nicer development environment.
 * VAST_ENABLE_BUNDLED_SCHEMAS, install bundled schemas with VAST.
 * VAST_ENABLE_ARROW, build with Apache Arrow support.
 * VAST_ENABLE_PCAP, build with PCAP support.
 * VAST_ENABLE_OPENSSL, encrypt network communication.
 * VAST_ENABLE_UNIT_TESTS, build unit tests for libvast.
 * VAST_ENABLE_VAST, build the standalone vast binary.

Why does BUILD_SHARED_LIBS have no VAST_ prefix?

@mavam that variable is defined by CMake itself, we just consider it important enough to include it in the summary.

Can we remove this "noise" in the CMake run?
-- CREATING CAF TARGETS
-- Found CAF
-- Found CAF: /usr/local/lib/libcaf_core.dylib;/usr/local/lib/libcaf_io.dylib;/usr/local/lib/libcaf_openssl.dylib (found version "0.17.6") found components: openssl
-- CREATING CAF TARGETS

The all-caps comments probably don't need to be in here, right?

that variable is defined by CMake itself, we just consider it important enough to include it in the summary.

Maybe move it to the top/bottom then? Otherwise it looks like a bug.


Add action link component

What
Adds the action link component from collections and adds a new option.

Apart from the new option, the component is unchanged from collections apart from the gem-c namespace and syntax tweaks to get the tests to run, so the first commit in this PR shouldn't need much scrutiny.
The new option adds the ability to have subtext - text that appears alongside the link on desktop and beneath it on mobile. This is made complicated by two things; the need for the text to vertically align, and the need for a dividing line between the two but only on desktop (and not knowing how long that text will be in practice).
Desktop:

Mobile:

This is solved using display: table-cell and vertical-align: middle on desktop for the individual elements and by adding some new wrapping elements. The wrapping elements are necessary for the dividing line between the link and the subtext. Adding spacing to the right of the link would oddly increase the focus state size (although this was considered).
We also need a parent class on the whole component when subtext is present to style the link differently.
This solution was chosen over flexbox because it works better cross browser without browser prefixes (we used flexbox in an early iteration of this component and getting it to work in all the IEs, even modern ones, was a headache never quite solved).
Why
I'm adding this component to the gem because we are using it collections but there's a version of it in static as well and maintaining two of them has now passed the point of practicality. The plan is to add this to the gem then use it in static and collections.
Trello card: https://trello.com/c/l9xuuuTB/279-update-emergency-banner-design

I'm seeing some odd clipping in Safari on macOS when the link over two lines and focused:

The dark version of the icon is different to the light version of the icon - it's not an inverse version. There's a space between the arrow and the left side of the circle on the dark version, whilst there's no space on the other version. Do you know if this is a deliberate choice?

@alex-ju I think we've diverged a bit since the initial borrowing, including all of the variants and different uses throughout the coronavirus landing page. We initially included the arrow in the focus state but unlike the NHS version our text can get quite verbose so it led to a very large yellow block when focussed, which we decided was unnecessary. In the case of the NHS, they specifically use it to signpost to a service, whereas we just use for important content.

@injms thanks will look at both those issues.

@injms I've fixed the line-height issue and reworked some of the component options in light of your comments (see the Change from original - compact and dark, and margins in the updated PR description).
Having said all that, it doesn't actually address your comment about the light icon not being the actual inverse of the dark one, but yes, the slight difference is deliberate.


Update basemap

Fixes the OSM basemap style enum so the basemap properly displays.

@ldanzinger - is this something that should be merged into master?


Platform netdaemon does not generate unique IDs. ID 86ec6a70-b2b8-427d-8fcf-3f14331dddd7_netdaemon_testapp_app already exists - ignoring switch

The problem
Not sure how bad it is, I see this is happening when entire machine is rebooted.
Environment
I am using Home Assistant and NetDaemon as separate containers on BalenaOS system.
Traceback/Error logs
Additional information

ohh weird. Thank you for reporting. I will check if the unique id generation can be fixed when we create the app entities

@ludeeus you have any ideas why this can be happening?

Looks like old version

@wojciechczyz please make sure you have latest version of integration and NetDaemon and let us know is problem exist

closing this due to inactivity. Reopen if problem still exist using the latest version


fix: anchor regexps in Jest transforms for proper JSON handling

Master has a new regexp for Jest which breaks tests that reference JSON at some point in the dependency chain. This is a fix.
The regexp .(js|jsx) matches .json which means Jest attempts to load JSON files as JS modules. Since they aren't modules, Jest fails.

This may interact with #491

Okkk just double-checked #161 and I believe this fixes it as well (and so #491 is not necessary).
The full absolute path there is<EMAIL_ADDRESS>-- notably "projects/" has a "ts" in it

Which should I merge?

@all-contributors please add @kyle-johnson for bug, code


Adsk Contrib - Remove the 'std::rand' usage

Even if the detected SonarCloud bug is not a potential problem in the OCIO context, the code is updated to avoid disabling some warnings during the static analysis.
Please refer to #773 for details.
Note: The associated unit already exists explaining why no unit test is updated.

The build break is not related to the branch but rather to a Python issue:

2: Test command: C:\hostedtoolcache\windows\Python\3.6.8\x64\python.exe "D:/a/1/s/tests/python/OpenColorIOTestSuite.py" "D:/a/1/s/_build" "True" "Release"
2: Test timeout computed to be: 10000000
2: Traceback (most recent call last):
2:   File "D:/a/1/s/tests/python/OpenColorIOTestSuite.py", line 23, in
2:     import PyOpenColorIO as OCIO
2: ImportError: Module use of python27.dll conflicts with this version of Python.
2/2 Test #2: test_python ......................***Failed    0.71 sec
50% tests passed, 1 tests failed out of 2

Friendly reminder that this PR qualifies for single approver rule so it could now be merged this week.


Laravel 9, Postgres can't change search_path to valid schema

Laravel Version: 9.1.0
PHP Version: 8.1.2
Database Driver & Version: PostgreSQL 14.1 (Debian 14.1-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit

Description:
I am trying to change the search_path to the current schema and unfortunately neither queries nor migrations work. Laravel fails to connect to the database on the defined schema.
Steps To Reproduce:

create new laravel 9 project
change driver to pgsql
create test-db schema
change database.php, postgres setting to 'search_path' => 'test-db',
try to run migration or select query from database

dd(DB::getPdo()->query('select current_schemas(true)')->fetchAll());
^ array:1 [[▼]()
  0 => array:2 [[▼]()
    "current_schemas" => "{pg_catalog}"
    0 => "{pg_catalog}"
  ]
]

php artisan migrate

   Illuminate\Database\QueryException

  SQLSTATE[3F000]: Invalid schema name: 7 ERROR:  no schema has been selected to create in at character 14 (SQL: create table "migrations" ("id" serial primary key not null, "migration" varchar(255) not null, "batch" integer not null))

  at vendor/laravel/framework/src/Illuminate/Database/Connection.php:712
    708▕         // If an exception occurs when attempting to run a query, we'll format the error
    709▕         // message to include the bindings with SQL, which will make this exception a
    710▕         // lot more helpful to the developer instead of just the database's errors.
    711▕         catch (Exception $e) {
  ➜ 712▕             throw new QueryException(
    713▕                 $query, $this->prepareBindings($bindings), $e
    714▕             );
    715▕         }
    716▕     }

      +37 vendor frames
  38  artisan:37
      Illuminate\Foundation\Console\Kernel::handle(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))

Character - in test-db is the issue.
https://github.com/laravel/framework/blob/171f65d2bf43fb82b7a4fe2ec769f94e962d912c/src/Illuminate/Database/Connectors/PostgresConnector.php#L127-L133
It looks PostgresConnector's parsing of config('database.connections.pgsql.search_path') doesn't cover every accepted Postgres symbol character.
preg_match_all('/[a-zA-z0-9$]{1,}/i', 'test-db', $matches);
$matches;
// [
//     [
//         "test",
//         "db",
//     ],
// ]

which should be [["test-db"]].

Funnily enough, 'test_db' (correctly) is parsed only because the regex mistakenly contains range [A-z] instead of [A-Z]:
preg_match_all('/[a-zA-z0-9$]{1,}/i', 'test_db', $matches);
$matches;
// [
//     [
//         "test_db",
//     ],
// ]

Regex '/[a-z0-9$_\-]{1,}/i' might fix it but I have to find an exact definition in the Postgres docs. e.g., whether extended ASCII or multibyte characters are accepted too.

This is also funny because, according to this code, when I pass search_path as array it will work - which looks like a nice workaround temporarily.
But.... also looking at method below https://github.com/laravel/framework/blob/171f65d2bf43fb82b7a4fe2ec769f94e962d912c/src/Illuminate/Database/Connectors/PostgresConnector.php#L150
It looks potentially buggy. It uses count($searchPath) and according to phpdoc @param  array|string  $searchPath. So, if string is passed it will throw Fatal error:  Uncaught TypeError: count(): Argument #1 ($var) must be of type Countable|array, string given. I see that configureSearchPath first uses parseSearchPath, but if so then $searchPath should be typehinted to array.

@derekmd can you maybe PR that?


fix(ziro): hover color of selected playlist

Avoids changing the text color of the selected playlist while hovering over it.
Before:

After:

Can you merge all of your commits into one branch and then only open a single pull request for all of the changes please.


cmd/compile: [0:x] slicing doesn't need to protect against past-end-of-object pointers

For s[i:j:k], SSA does:
	rlen = j-i
	rcap = k-i
	p = s.ptr
	if rcap != 0 {
	    p += i * elemsize
	}
	result = (SliceMake p rlen rcap)

The if is to make sure we don't end up manufacturing a pointer to the next object in the heap, and thus falsely retaining it.
If i==0, we don't need that check.
This comes up in encoding/binary.littleEndian.Uint64:
00008 (get.go:6)	MOVQ	"".b+16(FP), CX
00009 (get.go:6)	CMPQ	CX, $8
00010 (get.go:6)	JCS	$0, 18
00011 (get.go:6)	CMPQ	CX, $0
00012 (get.go:6)	JEQ	$0, 13
00013 (get.go:6)	MOVQ	"".b(FP), CX
00014 (get.go:6)	MOVQ	(CX), CX
00015 (get.go:6)	VARDEF	"".~r1+24(FP)
00016 (get.go:6)	MOVQ	CX, "".~r1+24(FP)
00017 (get.go:6)	RET
00018 (get.go:6)	CALL	runtime.panicslice(SB)
00019 (get.go:6)	UNDEF

That second comparison is useless, and represents the rcap != 0 comparison.  Maybe we should not emit this check at all if i==0.  Maybe we could detect this comparison is redundant (cx >= 8 implies cx != 0), or maybe we could detect that the branch is dumb because its taken and fallthrough go to the same place (as we've already constant-folded the i*elemsize to 0, there's no phi anymore).
@dr2chase @brtzsnr

Note that if we change the slicing in Uint64 to b=b[:8:8], the extra comparison goes away.

This is just a missed optimization by generic.
    If v39 -> b9 b10 (likely)
  b9: <- b8
    v40 = AddPtr <*byte> v30 v29
    Plain -> b10
  b10: <- b8 b9
    v41 = Phi <*byte> v30 v40

v29 is 0 here, but AddPtr v30 v29 is not folded until lowered pass. This means that v41 is not replaced by v30 which means fuse cannot collapse the branch.
Stupid jumps and empty branches after trim are a sign of missed opportunities for fuse.
I'm going to submit a fix tomorrow, but if anyone wants to take care make sure the proper canonicalization rule is added: (AddPtr x const) -> (AddPtr const x).

I think a better canonicalization would be (AddPtr x const) -> (OffPtr [const] x), that way it can be optimized further against other OffPtrs.

Or perhaps better yet, find out where that AddPtr came from. I think there are no (AddPtr x const) at the beginning, by construction, so someone introduced it; they should just introduce OffPtr instead.

(PtrIndex <t> ptr idx) && config.PtrSize == 8 -> (AddPtr ptr (Mul64 <config.fe.TypeInt()> idx (Const64 <config.fe.TypeInt()> [t.ElemType().Size()])))


Package is no longer architecture specific

This is to resolve this issue: https://github.com/jaredhendrickson13/pfsense-api/issues/239
Netgate devices run on arm, and by default FreeBSD will make the package specific to whatever architecture you build it on. By adding NO_ARCH=yes the package will not be architecture specific and so it won't require that you force install. It also allows you to do automatic updates.
You might have thought that Netgate would get around to making their own api for pfsense+ like you mentioned in this issue, sadly not.

Looks good to me, thanks!
I will note that not supporting amd64 and aarch64 installations is more of an intentional decision than a technical limitation. Without purchasing Netgate hardware, I only have access to publicly available (amd64) builds of pfSense, this includes the amd64 builds of pfSense Plus. Even though it's very unlikely, if a conflict did arise in the future I would be unable to effectively troubleshoot or write tests for potential issues specific to different architectures. However, this change will allow this subset of users to use the package without force installing; which will retain certain features for users installing the package on non-supported architectures.
Thanks again!


Graphite tags support

I'm trying to understand if you guys support the new graphite tagging system introduced in version 1.1.x
After going through the repo's intro doc I found out you guys don't support the graphite tagging format, as can be viewed here:
https://grafana.com/blog/2018/01/11/graphite-1.1-teaching-an-old-dog-new-tricks/
I would like to know if there are any plans for gostatsd to support graphite tags

Hi
There was some discussion on #213 - my rough plan was to drop tags entirely in "graphite mode" (with a warning on startup), and there was some concern that there may be some explosion of file handles if we include tags.  The big problem is I don't know the graphite system well enough to assess the potential impact.

Can you please elaborate what about this concern? I don't see how adding tags might cause issues, since its just as adding tags for other endpoints.

As I understand it, every unique metrics (ie, metric name + tagset) requires an open file handle, so cardinality can starve the system.
I don't know if this is a historical thing or not though, so it may well be a non-issue now.

I dont see how it has anything to do with gostatsd.
It is true that every unique metric is resembled as a file (whisper) in graphite, but the tag system does not create a whisper per tag - the tags are being stored in a different database, which is being queried when needed.
Here is a quote from the link I send in my first message:
At its core, the tagging system is implemented as a tag database (TagDB) alongside the metrics that allows them to be efficiently queried by individual tag values rather than having to traverse the metrics tree looking for series that match the specified query. Internally the tag index is stored in one of a number of pluggable tag databases, currently supported options are the internal graphite-web database, redis, or an external system that implements the Graphite tagging HTTP API. Carbon automatically keeps the index up to date with any tagged series seen.

Ahh, sorry - I misunderstood this.  In the prior discussion, there was concern that baking tags in to the metric name could cause problems with lots of file handles (I don't know if it's a issue or not with modern Graphite).
I'll have a shot at adding it over the weekend, it would be nice to cleanup some of the outstanding Graphite issues :)

@TomMizrachi - done! Please do raise a new issue if there's any problems - I don't have a good setup to really test it at scale.


go.mod error

go get -u gitea.com/xorm/core
go<EMAIL_ADDRESS>parsing go.mod: unexpected module path "xorm.io/core"
go get: error loading module requirements

core has been moved to xorm.io/core, you could use go get -u xorm.io/core

go get -u xorm.io/xorm
go: finding xorm.io/xorm v0.7.3
go<EMAIL_ADDRESS>parsing go.mod: unexpected module path "github.com/go-xorm/xorm"
go get: error loading module requirements

core has been moved to xorm.io/core, you could use go get -u xorm.io/core

using xorm.io/core  is work! Another question: xorm.io/xorm

go get -u xorm.io/xorm
go: finding xorm.io/xorm v0.7.3
go<EMAIL_ADDRESS>parsing go.mod: unexpected module path "github.com/go-xorm/xorm"
go get: error loading module requirements

use github.com/go-xorm/xorm is work!
Thanks!

I have the same problem?

github.com/go-xorm/core -> xorm.io/core
github.com/go-xorm/builder -> xorm.io/builder

Thanks very much!

github.com/go-xorm/core -> xorm.io/core
github.com/go-xorm/builder -> xorm.io/builder

how can I use this? Can you show me? thanks

In my situation this was an indirect dependency, so changing the name wasn't really an option.
The following got me past this in my go.mod, may be an abuse of what require is meant for - I have no idea:
module foo/foo/foo

replace github.com/go-xorm/core => xorm.io/core v0.6.2

replace github.com/go-xorm/xorm => xorm.io/xorm v0.7.0

go 1.12

Did that work for you?


how to add a converter for custom operateion written by c++

the model i used has some opration written by c++, using torch.utils.cpp_extention with a .cpp file. I want to convert the model into trt model but failed with the error NVALID_ARGUMENT: Cannot find binding of given name: input_0.
how can i write a converter for the operation written by c++?

First, you need to implement the custom ops you need as a TensorRT plugin, here are some examples.
After you have your plugin, add a creator in torch2trt_dynamic/plugins, note that if you did not implement your plugin inside amirstan_plugin, you need to load library ctypes.CDLL('xxxxx.so')
Finally, add your convertor in torch2trt_dynamic/converters. You can read cummax.py as an example.

Note that since there are some limits on TensorRT, I can not promise that your custom ops can be implemented as a TensorRT plugin.


Duplicate file contents being loaded into editor v0.1.9

If you open a cluster and click something like ingress->ingress_file , then click ingress_file again it will load duplicate contents in to the editor for as many times as you click it.
This happens to any editable file.

Fix merged (#211) - will be included in 0.1.10.  Thanks for flagging this!

Thanks guys


deprecated version 2.4.0 is pulled from npm instead of 2.3.4[🐛]

Description
I have an app that uses 2.x.x. version of this package with package.json:
"react-native-image-picker": "^2.3.3"
But instead of downloading 2.3.4. package that is that latest with 2.x.x. major version (at least per documentation and release notes) it installs 2.4.0. and that version has breaking api changes.
I see in npm repository that it is deprecated but why does it still install?
How to repeat issue and example

in package.json write dependency as: "react-native-image-picker": "^2.3.3"

Solution

I have fixed this by removing ^ and writing "react-native-image-picker": "2.3.4" with a plan to upgrade to 3.x.x

If you cannot influence what is installed with yarn/npm then maybe you should add this as known issue in documentation for 2.x.x.
Additional Information

Image Picker version: [N/A]
React Native version: [N/A]
Platform: [N/A]
Development Operating System: [MacOS]
Dev tools: [N/A]

Sorry for the issue, v2.4.0 was a wrong release due to some issue in CI, it should have been 3.x.x. Can we delete a published NPM version @Johan-dutoit ? I don't think adding it in docs will help, Ideally we should delete the version from NPM.

Apologies for the late response.  2.4.0 has been removed from NPM.


PROCESS: Expected X rows but processed Y rows

I am trying to load our cmdb_ci table, which has around 11M records to load to the DB. We are now using multiple concurrent instances of the SNDML to load parts of the table. Each instance is also partitioned by week/day. The speed it loads is just fine, but when it finishes it does not load all the records, it loads just cca 8.7M records.
This is an example of our YAML file (there are more yaml files, the created parameter is just different):
metrics: Path\To\Metrics\File.metrics
tables:
- {name: cmdb_ci, target: cmdb_ci_load, pagesize: 500, action: insert, created: [2020-01-01, 2020-04-01], partition: day, threads: 64}

For random queries to the table we get the RestTableReader warning log:
22:11:03 WARN RestTableReader [pool-3-thread-17] cmdb_ci.D2023-12-15 PROCESS: Expected 26143 rows but processed 26119 rows
22:11:03 WARN DatePartitionedTableReader [pool-3-thread-17] cmdb_ci.D2023-12-15 FINISH: Expected 26143 rows but only processed 26119 rows

These warnings are also random on every running instance of SNDML.
I also get a random JsonRequest warning when there is a "Time limit exceeded" error in the response, This is an example of the query that triggers the error:
sys_created_on%3E%3D2023-11-19%5Esys_created_on%3C2023-11-20%5Esys_id%3E4fc2139287aa355007ff542bbbbb35ca%5EORDERBYsys_id

What can I do in this situation, so it loads all the records from the table, becasue just the majority is not enough for us.

Regarding the row count mismatches:
This could mean that some process is deleting records while the job is running (e.g. a cleanup job), but it is unlikely. Most likely your issue is caused by an ACL or a Before Query Business Rule. The cmdb_ci class will have lots of sub-classes. Perhaps there is a custom sub-class to which you do not have access, or a Before Query Business Rule is blocking you from reading some of the records.
Regarding the timeout errors:
64 threads is a lot. It means that you are banging at the instance really hard. I am not surprised that you would get timeouts with 64 threads. My prediction is that if you reduce the number of threads to 3 that you will get fewer timeouts, and the job will finish almost as fast.

Thank you, I will look into this and try with 3 threads


chore: upgrades to start-database.sh

✅ Checklist

[x] I have followed every step in the contributing guide (updated 2022-10-06).
[x] The PR title follows the convention we established conventional-commit
[x] I performed a functional test on my final commit

Changelog
In start-database.sh some variables are built from DATABASE_URL and some aren't. This PR changes that so all variables are built from it.

DB_NAME added
DB_CONTAINER_NAME uses "$DB_NAME-postgres"

Screenshots
[Screenshots]
💯

Might have broken your CI pipeline with this 🤦♂


Using CryptoKit

Thank you for your great works! I hope SwiftPackageKeys will be better as it is exactly the library I want for handling credentials in Xcode.


Remove unnecessary git fetching

It seems these git fetches are not necessary.
Signed-off-by: Daniel Farrell<EMAIL_ADDRESS>

As I mentioned in submariner-io/releases#33 (comment) This is actually necessary here to calculate the versions correctly (since we're using git revision) but it's not necessary in most other CI jobs
You'll only see it on the release once it merges (we'll get some weird version probably), perhaps the e2e can live without it

Okay, thanks @mkolesnik! I removed the release.yml change but kept the e2e.yml change in the latest.


Trojan Detected in datascience-ui

Environment data

VS Code version: 1.33.1.
Extension version (available under the Extensions sidebar): 2019.4.11987
OS and version: WIN 10
Python version (& distribution if applicable, e.g. Anaconda): 3.6
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): virtualenv
Relevant/affected Python packages and their versions:

Expected behavior
Work Fine? I don't know, have a trojan free code.
Actual behavior

Steps to reproduce:

Update extension to the latest version with Avast File Shield ON.

Can verify same behavior with Avast on Mac OS.

Same here, updated and detected with the same BitcoinMiner

Same here. Avast on Mac OS 10.14.4.

Same here

Same here

Not sure how that file is being flagged. We don't even use it in the extension. It's a test file.

Our internal scans should have caught the index_bundle.js file that's included. So maybe it's just a red herring.

It's on Avast for everybody so it can be a false positive just in that particular AV. Paths in index.html were changed to Mac style (compared to previous versions of that file) and that would match with "MacOS:" part.

We're going to flag this with Avast and see what they say. The file itself is rather simple, and the index_bundle.js checks out as clear on https://www.virustotal.com/#/home/upload

I can't repro this on Windows 10.
Anybody that's having this problem, can you report back your Avast version number? I'm using this one:

Hey everyone. I've contacted Avast with the index.html file and they have currently stated that the file is not flagged by their system. If anyone who is reproing this issue can, could you upload the index.html file up on this post? I used the index.html from the download site to sent to Avast and I just want to make 100% sure that it's the same file as folks that are having this issue have.

I just heard back from Avast seems like this warning has actually been totally disabled. Here is their reply:

Hi Ian and thank you for your reply,
Using the provided discussion, I noticed that the file was detected as "MacOS:BitCoinMiner-EL [Trj]." I checked our database and this detection was actually disabled completely just yesterday and it should not occur anymore.
We are sorry for any inconvenience this may have caused. If you have any further questions, don't hesitate to contact me again.
Best Regards,
Prokop
The Avast Support Team

Sounds like noone should be seeing this if they are updated as of today with Avast.


How ML will be used is not explained much

@Ou42 said he didn't understand exactly how the computer was going to learn to be smarter.  Ahh, yes, there was much information missing.
Need to clarify

I think it reads better; might need more work later

In any case, close it for now; it's good enough


Remove prop-types peerDep; 5.3.1 release

Rather than revert the 4 commits in #172 (most of which are changes that we do want), I just undid the part that was breaking peoples' builds.
Let me know how this looks, and I'll merge and release. Working on the 6.0.0 branch now (which will just revert fca1ebb )
Resolves #174

Merge at will. :)

Sorry, got caught in a meeting at work. Mergin' now.


The llsc stack is not safe from ABA with how LL/SC is used

On the Cortex-M, STREX will always fail if the processor takes an exception between it and its corresponding LDREX operation

But the load of next at 8000136 is done outside of the LDREX...STREX sequence.
So if the process is preempted between 8000136  and 800013a and during the
preemption we cause the ABA problem (e.g. given h->A->B->C->0, do pop A, pop B, push A resulting in h->A->C->0 with B being in use).
Now given Cortex-M implementations might not have that problem:

A context switch might cause a subsequent Store-Exclusive to fail, requiring a load ... store sequence to be replayed. To minimize the possibility of this happening, ARM recommends that the Store-Exclusive instruction is kept as close as possible to the associated Load-Exclusive instruction, see Load-Exclusive and Store-Exclusive usage restrictions.

(quote from the ARM®v7-M ArchitectureReference Manual, linked in the sourcecode)
The problem is this is a might so depending on where you get your Cortex-M chip from this might or might not be a sound implementation.

https://github.com/japaric/heapless/blob/9ff3a5fa8968fb263cece456ccc9505dc913147e/src/pool/mod.rs#L123-L139

As a side not, I don't know which of the current sold Cortex-M based processors have that problem, neither do I know it there are any.
So this is a specification related bug, but it might not be a bug in the real world.

No, it's absolutely a problem in practice. The load of next is outside of the llsc region, so it doesn't matter about the "might" in the spec. A preemption before that (or concurrent accesses in actual SMP hardware) is not going to trigger an abort. Taking advantage of LL/SC like this is just not possible with C11-based intrinsics - you need the LL(head) part of compare_exchange_weak before the load of next. This is doable in ASM, but not in the typical rust/C/etc intrinsics. The asm shown in the docs is clearly shows how this is incorrect, in order for it to be ok it would need to have reordered the ldrex/lrd.w instructions (and then had different register allocation):
ldrex   r3, [r0]
ldr.w   ip, [r2]
cmp     r3, r1
bne.n   800014a <<heapless::pool::Pool<T>>::pop+0x1a>
strex   r3, ip, [r0]

Meanwhile the warned-about x86-64 generation counter algorithm is safe in basically any realistic scenario.

@japaric Do you know how to fix this?
Or should we just trash the use of atomics and to the critical move in an interrupt free section?
As I see it interrupt free is the way to go to get deterministic execution time and the section will be extremely small.

yes, I have written this stack before using ldrex and strex "intrinsics" (plain functions around inline assembly) before I think that was more correct (and shorter) than what one gets with compare_exchange. That requires a nightly toolchain because of the inline assembly and I no longer have that code around.

Or should we just trash the use of atomics and to the critical move in an interrupt free section?

not a fan of the interrupt::free suggestion. if we are going to make the code device specific, I would look into writing the push and pop subroutines in "external assembly", which works on stable (no time for any of that this week though)

Hmm, what are you not a fan of? It will be a few instructions long (4?) and guaranteed execution time.
So more efficient than the current ldrex and strex code as the current loops and checks will go away as the operation is guaranteed to work.
For keeping test-ability on x86 we can have atomics based spin-wait (same as it is now).
I'm not seeing the problem you are seeing.

the documentation states this a lock-free queue. adding a critical section breaks that guarantee and would be a breaking change in my opinion.

spsc::Queue – single producer single consumer lock-free queue

I think we disagree then, as long as you do not need mutable references it is lock free, as the pool works via immutable references.
And this API will be kept, so for my view it's not a breaking change.
I'd also argue that using atomics here is over-engineered, as it will be an extremely small critical section which in worst case will give a few clocks of predictable latency in the system.
And since the fix seems to entail custom assembly I'd argue even harder that atomics is not the correct thing to use here, given that we want future maintainability and simple understanding.
This means we can keep atomics, but have unbounded worst case and an advanced implementation, or use critical sections and have strictly bounded worst case (which is smaller than the best case with atomics) and very easy to understand code.

I think we disagree then, as long as you do not need mutable references it is lock free, as the pool works via immutable references. And this API will be kept, so for my view it's not a breaking change.

Mutation via shared references (&-) can be called 'interior mutability' and/or 'thread-safe' (= implements Sync). That's a different property than 'lock-free', which means free from 'critical sections' be these achieved via disabling interrupts or using any flavor of Mutex.
To be clear, I'm not opposed to adding a general purpose fixed-capacity queue that works with mutable references but that's a different data structure. People can layer device-specific synchronization on top of that queue to get what you are describing, e.g.
// crate: heapless
pub struct GeneralPurposeQueue<T> { /* .. */ }

impl GeneralPurposeQueue<T> {
    pub fn enqueue(&mut self, item: T) -> Result<(), T> { /* .. */ }
    pub fn dequeue(&mut self, item: T) -> Option<T> { /* .. */ }
}

// crate: cortex-m-queue
pub struct CortexMQueue<T>(interrupt::Mutex<RefCell<GeneralPurposeQueue<T>>>);

impl CortexMQueue<T> {
    pub fn enqueue(&self, item: T) -> Result<(), T> {
        interrupt::free(|cs| self.0.borrow(cs).borrow_mut().enqueue(item))
    }
}

I'd also argue that using atomics here is over-engineered

Bounded (fixed-capacity) lock-free SPSC queues based on atomics are a well-known data structure that date from ~80 (I think the original work is by Lamport). There's plenty of variants (bounded, unbounded, cache-friendly, etc.) by now but I would not call any of them "over enigneered"; they all have different trade offs.

The other problem I see with a critical section based queue that has no atomics is that it's not multi-core safe, where as the lock-free queue here is.
I see that your main line of argument is "bounded time execution". I can see the use case for that and I'm fully OK with a queue that has such property but like I said above that's a different data structure so we should not be modifying the existing spsc::Queue but rather adding a new queue that has such property.

I think we are discussing 2 different things, spsc::Queue is fine as is. pool and its internal Trieber stack is the one with the issue. :)

now that asm! is stable the LL/SC version can be rewritten to use asm!. the optimized generated assembly (target=Cortex-M4F) for the Treiber stack is
; fn push(r0: &Self, r1: NonNull<Node>)
00000000 <treiber_stack::Stack::push>:
   0:   /-> e850 2f00   ldrex   r2, [r0]
   4:   |   600a        str     r2, [r1, #0]
   6:   |   e840 1200   strex   r2, r1, [r0]
   a:   |   2a00        cmp     r2, #0
   c:   \-- d1f8        bne.n   0 <treiber_stack::Stack::push>
   e:       4770        bx      lr

Disassembly of section .text._ZN13treiber_stack5Stack3pop17hbb5864b9da74c787E:

; fn pop(r0: &Self) -> Option<NonNull<Node>>
00000000 <treiber_stack::Stack::pop>:
   0:          4601             mov     r1, r0
   2:   /----> e851 0f00        ldrex   r0, [r1]
   6:   |  /-- b130             cbz     r0, 16 <treiber_stack::Stack::pop+0x16>
   8:   |  |   6802             ldr     r2, [r0, #0]
   a:   |  |   e841 2300        strex   r3, r2, [r1]
   e:   |  |   2b00             cmp     r3, #0
  10:   |  |   bf08             it      eq
  12:   |  |   4770             bxeq    lr
  14:   \--|-- e7f5             b.n     2 <treiber_stack::Stack::pop+0x2>
  16:      \-> 2000             movs    r0, #0
  18:          f3bf 8f2f        clrex
  1c:          4770             bx      lr

I'll prepare a PR


Enhancement: Upgrade Docker to 4.4.1

We have tested calm with docker 2.7.0.
We should upgrade docker and check if it still works.

WontFix. Docker 4.4.1 does to much trouble. We are staying at version 2.7.0


No clarity about thread safety at all. Finally, is ServiceHubContext thread-safe or not?

All the examples of how to obtain and use IServiceHubContext instances do not go beyond a "Hello world" use case and therefore do not provide any answer on what is the recommended approach to it's instance lifecycle.
Can we have a singleton instance of it per process? If yes, will it be thread-safe? Will it automatically reconnect? What if it fails to?
If not, how costly are serviceManager.CreateHubContextAsync() calls?
The only doc I managed to find on this topic is for Asp.Net Hub class, which says its instance methods "are not guaranteed to be thread-safe" (hopefully it is just a boilerplate text and is not true in reality)…
All this uncertainty prevents people from using this package in production-ready environment.

Hi @scale-tone Thanks for asking.

do not provide any answer on what is the recommended approach to it's instance lifecycle

No global shared data, you can use it as static/non-static member. So no special recommendation.

Can we have a singleton instance of it per process?

Both work.

will it be thread-safe?

Yes, except for ServiceHubContext can be disposed only once.

Will it automatically reconnect? What if it fails to?

If it fails:

Transient Mode: No actual connection
Persistent Mode: No, it will not reconnect, user should handle it by himself/serself. Throw exception if disconnects unexpectly.

More information about these two modes can be found here.

how costly are serviceManager.CreateHubContextAsync() calls?

The document alreadly talked about it.

Transient Mode: Cost can be ignore -- Create an instance to call Azure SignalR's REST api to send messages.
Persistent Mode: Main cost -- Establish Websockets connections to send messages.

Thanks @realwanpengli , much more clear now. Still more questions:

Persistent Mode: No, it will not reconnect, user should handle it by himself/serself. Throw exception if disconnects unexpectly.

Did you mean that IClientProxy.SendCoreAsync() will start throwing exceptions in that case?

The document alreadly talked about it.
Transient Mode: Cost can be ignore -- Create an instance to call Azure SignalR's REST api to send messages.
Persistent Mode: Main cost -- Establish Websockets connections to send messages.

I assume, ServiceTransportType.Transient is the default option, is that correct?
Are you saying that in this mode it will be establishing new HTTP connections to Azure SignalR Service REST API for each and every message to be sent?
If yes, this mode seems to be pretty expensive!
I can also see they in Azure Functions SignalR Extension are using this mode (can be configured, but they do not advertise this option, probably, because the rest of the code is not ready for connection failures). They do use ServiceHubContexts as singletons but they do not use "Persistent Mode". Does that make sense? What would be the recommended approach for server-side scenarios like in Azure Functions?

@scale-tone Thanks for mentioning Azure Function SignalR Extension! And sorry for the wrong answer. The Management SDK already have the logic to reconnect
But we only have one websockets connection in persistent mode, if one drops, there's no other connections to send messages. We plan to add more connections, and randomly choose another available connection to send message event if part of the connections drop.

Are you saying that in this mode it will be establishing new HTTP connections to Azure SignalR Service REST API for each and every message to be sent

Yes, the version 1.0.0 only has transient mode, so we plan to add persistent mode to send all messages in one websockets connection in improve performance.
The reason to set transient mode as default is to keep consistency to the previous versions.

The Management SDK already have the logic to reconnect

Yes, but I don't see it working. A bug on that.

It is thread-safe.


Monitor with optional enforcement "actor time"

For history and reference, see this issue

Related to #9 for observability

Deferred until after 0.5


Simpler github module specs

I'm so used to (among other things) Vundle's way of specifying github sources that I want to have:
mod "frimik/puppet-module" to automatically mean a github sourced module!
See gist for the very convoluted monkeypatch I did :)
https://gist.github.com/frimik/4bf625afa466aef5f35281ae4822c1ad#file-puppetfile-rb-L23

While a nice idea, I don't think it's realistic to see this implemented. By now r10k is more popular so that would probably be a good place for such a feature. If that implements it, then librarian-puppet can follow.


Rust version of target code

What's the rust version used for the target code that will be verified? My current project is using rust nightly, but verus seems to be incompatible with that. Is it possible to change the rust version used (like rustup toolchain nightly, but for verus)?

This is not officially supported, but if you swap out this line for
channel = "nightly-2024-02-08" # (not officially supported)

then it might work. That particular date is the date of 1.76.0 release, thus it is the most likely nightly version to work.

That particular date is the date of 1.76.0 release, thus it is the most likely nightly version to work

I'd also try a nightly ~7 weeks before the date of the release, which is when the release branch is forked and stops getting the commits from main (except for specific backports). See https://forge.rust-lang.org for more information on when version branches are branched from master.
I'm going to close this, but feel free to re-open if you need more help.