setup.py seems to be expecting GCC

Description
When setting CC and CXX to non-gcc compilers -- eg nvcc -- the setup.py build breaks because it is passing GCC-only flags to CC. For example this works on NERSC's Perlmutter (https://docs.nersc.gov/systems/perlmutter/) system:
blaschke@muller:login02:~> LDFLAGS="$CRAY_CUDATOOLKIT_POST_LINK_OPTS" NVCC="nvcc $CRAY_CUDATOOLKIT_INCLUDE_OPTS" CC=cc CXX=CC pip install cupy

when loading:
module load PrgEnv-gnu

as this will set cc=gcc and CC=g++. However loading:
module load PrgEnv-ndivida

will set cc=nvcc and CC=nvc++. And the command above will break because the -fwrapv flag is passed to cc (i.e. nvcc) which doesn't know what to do with the flag:
    -------- Configuring Module: cuda --------
    nvc-Error-Unknown switch: -fwrapv
    command 'cc' failed with exit status 1
    nvc-Error-Unknown switch: -fwrapv
    **************************************************
    *** WARNING: Cannot check compute capability
    command 'cc' failed with exit status 1
    **************************************************

    ************************************************************
    * CuPy Configuration Summary                               *
    ************************************************************

    Build Environment:
      Include directories: ['/tmp/pip-install-io1hkbby/cupy_93b134b374a5423fa60a2e4e1263db36/cupy/_core/include/cupy/cub', '/tmp/pip-install-io1hkbby/cupy_93b134b374a5423fa60a2e4e1263db36/cupy/_core/include', '/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/compilers/include']
      Library directories: ['/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/compilers/lib']
      nvcc command       : ['nvc', '-I/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/cuda/11.5/include', '-I/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/cuda/11.5/nvvm/include', '-I/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/cuda/11.5/extras/Debugger/include', '-I/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/cuda/11.5/extras/CUPTI/include', '-I/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/math_libs/11.5/include']
      hipcc command      : (not found)

    Environment Variables:
      CFLAGS          : (none)
      LDFLAGS         : -L/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/cuda/11.5/lib64 -L/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/cuda/11.5/nvvm/lib64 -L/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/cuda/11.5/extras/Debugger/lib64 -L/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/cuda/11.5/extras/CUPTI/lib64 -L/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/math_libs/11.5/lib64 -Wl,--as-needed,-lcupti,-lcudart,--no-as-needed -lcuda
      LIBRARY_PATH    : (none)
      CUDA_PATH       : (none)
      NVTOOLSEXT_PATH : (none)
      NVCC            : nvc -I/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/cuda/11.5/include -I/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/cuda/11.5/nvvm/include -I/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/cuda/11.5/extras/Debugger/include -I/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/cuda/11.5/extras/CUPTI/include -I/opt/nvidia/hpc_sdk/Linux_x86_64/21.11/math_libs/11.5/include
      HIPCC           : (none)
      ROCM_HOME       : (none)

    Modules:
      cuda      : No
        -> Include files not found: ['cublas_v2.h', 'cuda.h', 'cuda_profiler_api.h', 'cuda_runtime.h', 'cufft.h', 'curand.h', 'cusparse.h', 'nvrtc.h']
        -> Check your CFLAGS environment variable.

    ERROR: CUDA could not be found on your system.

    HINT: You are trying to build CuPy from source, which is NOT recommended for general use.
          Please consider using binary packages instead.

    Please refer to the Installation Guide for details:
    https://docs.cupy.dev/en/stable/install.html

    ************************************************************

To Reproduce
Log into NERSC's Perlmutter system.

This works:

user@perlmutter:login02:~> module load PrgEnv-gnu
user@perlmutter:login02:~> module load cudatoolkit
user@perlmutter:login02:~> module load python
user@perlmutter:login02:~> LDFLAGS="$CRAY_CUDATOOLKIT_POST_LINK_OPTS" NVCC="nvcc $CRAY_CUDATOOLKIT_INCLUDE_OPTS" CC=cc CXX=CC pip install cupy --user

This doesn't work:

user@perlmutter:login02:~> module load PrgEnv-nvidia
user@perlmutter:login02:~> module load cudatoolkit
user@perlmutter:login02:~> module load python
user@perlmutter:login02:~> LDFLAGS="$CRAY_CUDATOOLKIT_POST_LINK_OPTS" NVCC="nvcc $CRAY_CUDATOOLKIT_INCLUDE_OPTS" CC=cc CXX=CC pip install cupy --user

Installation
Source (pip install cupy)
Environment
N/A -- this is a compile problem
Additional Information
No response

I am pretty sure "-fwrapv" is generated somewhere other than CuPy. Most likely from the Perlmutter Python env which conflicts with nvc++, see this issue and the solution therein: https://github.com/mpi4py/mpi4py/issues/114
Also, the Perlmutter instruction recommends to install CuPy wheel from PyPI:
https://docs.nersc.gov/development/languages/python/using-python-perlmutter/#cupy
Although the instruction may not be fully up-to-date due to the nature of the rapidly changing Perlmutter environment. Maybe opening a ticket with the admin for consultation? 🙂

Thanks for the related issue @leofang ... pretty much every time I have a HPC python problem, I get directed to an issue from @ax3l 😉
Anyway, in this case the -noswitcherror in combination with compiler wrappers (nor nvc/nvc++) still doesn't work. In this case it seems to have trouble finding its own standard lib 😞
    -------- Configuring Module: cuda --------
    nvc-Warning-Unknown switch: -fwrapv
    "/tmp/tmp1mjffzr4/a.cpp", line 9: warning: last line of file ends without a newline
      int main() {return 0;}
                            ^

    "/tmp/tmp1mjffzr4/a.cpp", line 9: warning: use of non-prototype function declarator
      int main() {return 0;}
          ^

    /usr/bin/ld: read in flex scanner failed
    Cannot build a stub file.
    Original error: command 'nvc' failed with exit status 2
    nvc-Warning-Unknown switch: -fwrapv
    "/tmp/tmpn4ub4z8r/a.cpp", line 6: warning: use of non-prototype function declarator
              int main() {
                  ^

    "/tmp/tmpn4ub4z8r/a.cpp", line 10: error: identifier "cudaDeviceProp" is undefined
                    cudaDeviceProp prop;
                    ^

    "/tmp/tmpn4ub4z8r/a.cpp", line 10: error: expected a ";"
                    cudaDeviceProp prop;
                                   ^

    "/tmp/tmpn4ub4z8r/a.cpp", line 11: error: identifier "prop" is undefined
                    CHECK_CUDART(cudaGetDeviceProperties(&prop, i));
                    ^

    "/tmp/tmpn4ub4z8r/a.cpp", line 12: error: identifier "prop" is undefined
                    printf("%d%d ", prop.major, prop.minor);
                                    ^

    "/tmp/tmpn4ub4z8r/a.cpp", line 16: warning: last line of file ends without a newline

              ^

    4 errors detected in the compilation of "/tmp/tmpn4ub4z8r/a.cpp".
    **************************************************
    *** WARNING: Cannot check compute capability
    command 'cc' failed with exit status 2
    **************************************************

Even trying to help it out by including the compiler and linker flags -- eg:
LDFLAGS="$CRAY_CUDATOOLKIT_POST_LINK_OPTS" CFLAGS="-I$CUDATOOLKIT_HOME/targets/x86_64-linux/include -noswitcherror" CC=cc CXX=CC pip install cupy

doesn't help. I am tempted to refer this to the vendors at this stage -- depending on what @lastephey thinks. In the meantime we've published the (ugly) workaround above.

@leofang  For completeness:

Also, the Perlmutter instruction recommends to install CuPy wheel from PyPI: https://docs.nersc.gov/development/languages/python/using-python-perlmutter/#cupy

I like recommending that users try the wheels first, but it's also important to me that we document how to build python dependencies using the vendor compilers wherever this is feasible. One situation where this might matter is when some python modules need to be compiled with specific vendor compilers, or linked against specific cuda versions. In this situation it is nice to know how all dependencies can be compiled using a single consistent toolchain.

Maybe opening a ticket with the admin for consultation? 🙂

HA! That would likely land on mine, or @dmargala 's or @lastephey 's desk 😜

This is a problem of distutils where the flags used to compile python are unconditionally set to any UNIX compiler.
https://github.com/pypa/setuptools/blob/main/setuptools/_distutils/sysconfig.py#L219-L221
Also we call this from:
https://github.com/cupy/cupy/blob/master/install/cupy_builder/cupy_setup_build.py#L487-L489
The problem here is that you won't be able to override the CFLAGS passed to the compiler without calling mock or probably creating your own compiler definition for setuptools which I am not sure if it would be able to cleanly skip the sysconfig setting.
The only immediate way that comes to my mind that can cleanly solve this is to compile Python with nvc. However, I am not sure if that would even work or create other problems for users. But I think it is worth a try.
Thanks for the report! this is an interesting behavior that we were not fully aware. It would be great if we can find a nice fix for this so lets leave this open for discussion.

Thanks, @JBlaschke. Emilio is right -- those configs are coming from the build env of the specific Python interpreter in question, and is recorded in sysconfig so that when building Python extension modules for this interpreter, the compiler flags can be made consistent.
Let me add that there is no way out AFAIK -- sysconfig is heavily used in the community (CuPy, mpi4py, conda-forge, and almost all open source projects that I am aware of). It's likely that -- if possible at all -- you need to rebuild the Python interpreter for your users using the lowest common denominator flags to make nvc++ happy...


Full spark integration

[Short description explaining the high-level reason for the pull request]
Changes
How I tested this
Notes
Checklist

[ ] PR has an informative and human-readable title (this will be pulled into the release notes)
[ ] Changes are limited to a single goal (no scope creep)
[ ] Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
[ ] Any change in functionality is tested
[ ] New functions are documented (with a description, list of inputs, and expected output)
[ ] Placeholder code is flagged / future TODOs are captured in comments
[ ] Project documentation has been updated if adding/changing functionality.

Things to look over:

[ ] Documentation -- where else can we add references?
[ ] API -- we'll be locked in after this
[ ] Clarity of explanations -- I can do a better job here I think


Same title error

Describe the bug
Sometimes sync doesn't work because same title
To Reproduce
Steps to reproduce the behavior:

Set sync type to one-way sync
Create a note in Fleeting Notes with title "Hello"
Sync with Obsidian
Delete note from FN and create another note with "Hello"
Sync with Obsidian, see error

this might not be a bug. just tested it out


Replica counts not being honored for helm installations

Describe the bug
After generating a settings.json file that contains replica counts greater than one:
  "OXAUTH_REPLICAS": 2,
  "OXTRUST_REPLICAS": 2,
  "LDAP_REPLICAS": 3,
  "OXSHIBBOLETH_REPLICAS": 2,
  "OXPASSPORT_REPLICAS": 2,
  "OXD_SERVER_REPLICAS": 2,

running pygluu-kubernetes.pgz helm-install will install gluu as desired without the correct replica counts. The only stateful set that was scaled up was openDJ. I had to manually scale the other services and verify functionality
To Reproduce
Steps to reproduce the behavior:

pygluu-kubernetes.pgz generate-settings
Input replica counts greater than 1
pygluu-kubernetes.pgz helm-install
Verify statefulset count and pod count with kubectl

Expected behavior
If settings.json was built to request 2 replicas of everything, or 3 of everything, I would expect the stateful sets to already be scaled for it
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: macOS 10.15.7
Browser chrome
Version 87

Additional context
The version of pygluu I'm working with is built from source from the last tag with the zipapp method. Also it feels like it would be worth adding a version subcommand for support purposes

Thanks @shairozan for reporting this issue. We will check it out.


Modified nodeName handling for web pages served as XML

When a web page is served with Content-Type: application/xhtml+xml, the DOM property nodeName will always have a lowercased value instead of a uppercased one typically seen in normal HTML pages.
This modification is meant to help users who want to serve their web pages with Content-Type: application/xhtml+xml and is not supposed to break anything.

Thanks for the PR, this issue is fixed in the next branch (Popper v2) which will be released in the upcoming weeks. Support for XML is not planned for the current version.


Wide & breaking changes - embeds/message detection

Moved regex to own file
Added utilities
Added welcome/DM ident
Added embeds
Updated .env

This PR is likely to introduce breaking changes - please ensure you're locally up to date before doing a checkout, and review .env.example for changes

@TamzinHadasa I changed a required check name (Lint with mypy) so this won't automatically pass - lemme know when you've reviewed it and I'll force it through 😄

Have resolved the required changes, and logged #29 so we can circle back :)


dead link

Hi,
the guys that made deezloaderrmx created a successor, Deemix.
Base: https://notabug.org/RemixDev/deemix WebUI: https://notabug.org/RemixDev/deemix-pyweb Docker Container: https://github.com/Bockiii/deemix-docker

everything is gone.

dead


Vehicle shop extra row bug fix

In some vehicle shops, there were extra empty rows which made no sense. They are removed and fixed.

Maybe you should test this before we merge this in as I believe those empty rows does have a meaning, check "data.lua" to see if there's any sign of empty rows there.

It is been tested.

Cause of this might be something else like not properly cleaned variables or similar, this does solve the graphical issues which is fair enough for now. /Merging into master


error: ignoring return value of freopen

Here:
https://github.com/KhronosGroup/OpenCL-CTS/blob/8579e61401d66d9c1e9e2903cf4eaad1c8d5afdc/test_conformance/printf/test_printf.cpp#L147
the return value is ignored. This cause a compilation error when using a release build of the CTS on my system (the main relevant info should be: GCC 7.5 and its default standard library on Ubuntu 18.04, libstdc++).
../test_conformance/printf/test_printf.cpp: In function 'int acquireOutputStream()':
../test_conformance/printf/test_printf.cpp:147:12: error: ignoring return value of 'FILE* freopen(const char*, const char*, FILE*)', declared with attribute warn_unused_result [-Werror=unused-result]
     freopen(gFileName,"w",stdout);
     ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors

The fix is probably trivial, however it might be better to disable -Werror by default as a general rule because build will fail on a slightly different system than the one used for development/testing.

Being addressed by https://github.com/KhronosGroup/OpenCL-CTS/pull/801

Glad to see this already being addressed. I wonder what is your opinion (and others') on my comment about not using -Werror by default.

We did enable it recently to get feedback from the CI on silly code issues that show up as warnings. The discussion was in https://github.com/KhronosGroup/OpenCL-CTS/pull/782.

verified fixed in same environment

Feel free to close this ticket if there is no strong interest to remove -Werror from non-CI environment.

Feel free to close this ticket if there is no strong interest to remove -Werror from non-CI environment.


page.hover(selector) throws undefined

page.hover(selector) does not work
Tell us about your environment:

Puppeteer version: 1.8.0
Platform / OS version: Mac OS
Node.js version: v8.9.1

Puppeteer config:
  browser = await puppeteer.launch({ headless: true });
    page = await browser.newPage();
    const override = Object.assign(page.viewport(), { width: 1920 });
    await page.setViewport(override);
    await page.goto(`http://<IP_ADDRESS>:3000`, { waitUntil: 'networkidle0' });

What steps will reproduce the problem?

Here is a snippet of my code that tries to do hover on element and take screenshot.

const hoverScreenshot = async (page, dataHook, directory) => {
  const element = await page.hover(`[data-hook="${dataHook}`);
  await page.waitFor(50);
  await element.screenshot({
    omitBackground: true,
    path: `e2e/screenshots/${directory}/${dataHook}-hover.png`
  });
})

See error.

What is the expected result?
Taken screenshot of hovered element.
What happens instead?
Throws an error:
TypeError: Cannot read property 'screenshot' of undefined

      35 |   const element = await page.hover(`[data-hook="${dataHook}`);
      36 |   await page.waitFor(500);
    > 37 |   await element.screenshot({
         |                 ^
      38 |     omitBackground: true,
      39 |     path: `e2e/screenshots/${directory}/${dataHook}-hover.png`
      40 |   });

I am pretty sure that element is in the DOM as my other function that searches with the same data-hook finds it:
const standardScreenshot = async (page, dataHook, directory) => {
  const element = await page.$(`[data-hook="${dataHook}`);
  await page.waitFor(50);
  await element.screenshot({
    omitBackground: true,
    path: `e2e/screenshots/${directory}/${dataHook}.png`
  });
};

Update. await page.$([data-hook="${dataHook}).hover() throws that it is not a function.

Thanks this is a life saver!

const element = await page.$(`[data-hook="${dataHook}`);
await element.hover()

also works for me. You don't need to select it twice.


Markers move erratically while zooming on mobile

Given a Leaflet map, if you initialize the map, add a circle marker, and invoke the following:
map.dragging.disable();
map.dragging.enable();

Then when you "pinch-to-zoom" on mobile via touch, the markers on the map move erratically while zoom is in progress, snapping back to the correct position after the zoom is complete. This makes for an ugly user experience.
http://i.imgur.com/O7ZlME5.gif

Replicated on Leaflet latest (1.0.0), on Android Chrome, and Chrome on a MS Surface Pro 3 running Windows 10 (using the touch screen.) Cannot replicate on desktop using a scroll wheel.
See playground here.

Note to self: try to make a test case using prosthetic-hand.

@IvanSanchez

What I think happens is that disabling and again enabling the dragging, event handlers switch order.
After dragging is enabled again, a pinch zoom suddenly initializes both a drag and a pinch zoom, which in turn makes the markers use twice the offset, probably once from the drag handler and once from the pinch zoom.
If you do it on desktop with touch support, it becomes even more obvious, since after stopping the pinch zoom, the mouse is still in drag mode, dragging the map around even if no mouse button is pressed.

Some further detail: without the disable/enable map drag, a drag only touches the leaflet-map-pane transform, and a pinch zoom only touches the leaflet-tile-container and svg element transforms.
After the disable/enable map drag, a pinch zoom touches the leaflet-map-pane transform, the leaflet-tile-container and svg element transforms, which of course results in a double offset.

Yet another update: the root cause is the order of map handlers, and in turn the order they register event handlers.
I have reproduced the issue without enabling/disabling map drag, by just making sure the Map.Tap handler is registered before the drag handler.
When the tap handler is registered before, it catches touch events and turns them into simulated mouse events.
When the handlers are in the opposite order, the drag and/or touch zoom handlers will call preventDefault on the events, and they will not be turned into simulated events.

Have we been able to bisect this issue?

Haven't tried it, but given that your comments in #3872 more or less exactly describe this issue, it sounds likely it might be the source. Don't have time to do a bisect right now.

L.Draggable receives a touch event, causing it to initiate a drag
TouchZoom handler receives two fingers down, causing it to initiate a touch zoom
Once the touch zoom is going, TouchZoom will prevent any touch events from reaching Draggable, it will however not prevent the simulated events (which it doesn't listen to)
Draggable receives all simulated events, and since it has initiated a drag in step 1, it will continue to interpret them as drag events
Draggable will never exit dragging, since it doesn't receive the finger up events, since they're caught by TouchZoom.

Answering my own question ('why firing both touch and simulated in the same time'):

we want Leaflet users to be able to just listen for mouse events while having code working also on touch
we still want advanced users to be able to listen for the original touch events, to have more control when needed
we can't merge both events in one ('mousemove' with touches sounds too weird, and those advanced users will anyway keep listening on 'touchmove' for example)
this means that when listening for both mouse and touch events in a same listener, it's better to ignore simulated ones

For now, we'll keep the flag _simulated private in simulated events, but consider making it public when/if we get any feedback on anyone using this outside of the Leaflet codebase.

This is still a problem on mobile devices (using Chrome or Safari on iOS). Desktop is ok.

This is still a problem on mobile devices (using Chrome or Safari on iOS). Desktop is ok.

Desktop WITH touchscreen is still NOT oke! That is what I meant in my comment.
It is just the touchscreen support that is not working properly


Still Has Showstopping "Can't Update Certificate" Error

Installed the newest release, and it STILL has the error where nothing can be done if the existing certificate is a wildcard cert. Cannot deploy new WAP's or ADFS instances if the existing cert is a wildcard, once you get to the SSL Certificate screen, it says 'SSL Certificate Already Provided' and cannot browse to a new one, browse button is greyed out. Clicking the 'Enter Password' screen and entering the password throws and error that says 'The certificate does not have a suitable subject name, please provide a new certificate' but like I said, you can't even browse to a new certificate (which doesn't matter, we want to use our EXISTING certificate).
I've submitted this error to support, and on user voice, and I find it hard to believe this error hasn't been addressed as it prevents the product from being used. The bigger question is, the cert is a wildcard cert, one we've been using for years now. Why the error saying it doesn't have a suitable subject name...it's a wildcard cert!!! This product is fundamentally broken, and this issue has been reported for months now.

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

ID: 57f5478b-3132-21d0-a420-a1140db235de
Version Independent ID: 266bbd16-2117-f680-6493-e183eb09fdbc
Content: Azure AD Connect: Version release history
Content Source: articles/active-directory/hybrid/reference-connect-version-history.md
Service: active-directory
GitHub Login: @billmath
Microsoft Alias: billmath

@jaypatrick
Thanks for your feedback! We will investigate and update as appropriate.

@jaypatrick I have created a complete lab and tested two scenarios with a wildcard certificate and was successful to configure a new ADFS server both the times using the current AD connect version <IP_ADDRESS> as per the following options marked in red.

The certificate details which I used in my lab are as below.

As you can see the certificate is an existing wildcard certificate and SAN parameters were filled out . If we use the first option "Configure a new AD FS farm " , that works and I don't get any error after selecting the certificate :-

While if we select the second option and try to "Use an existing AD FS farm"  , even that works. WE are not able to generate the error which you have mentioned and we have tried to use the wizard in every way possible . The current AD connect version works just fine. You mentioned that you had reached support team as well . Could you please email us at azcommunity [@] microsoft [dot] com with the Suport case number , your azure subscription ID and the details of the step which is failing in our case and we would certainly like to take a look and help you with alternative options in this case. at this point we will close this issue however , we request you to send us an email with the details to the address mentioned above referencing this github issue and we would be happy to help on the same.
Thank you.


when running ./install-kubeflow.sh, getting internal error message.

Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "clusterservingruntime.kserve-webhook-server.validator": failed to call webhook: Post "https://kserve-webhook-server-service.kubeflow.svc:443/validate-serving-kserve-io-v1alpha1-clusterservingruntime?timeout=10s": no endpoints available for service "kserve-webhook-server-service"
Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "clusterservingruntime.kserve-webhook-server.validator": failed to call webhook: Post "https://kserve-webhook-server-service.kubeflow.svc:443/validate-serving-kserve-io-v1alpha1-clusterservingruntime?timeout=10s": no endpoints available for service "kserve-webhook-server-service"
Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "clusterservingruntime.kserve-webhook-server.validator": failed to call webhook: Post "https://kserve-webhook-server-service.kubeflow.svc:443/validate-serving-kserve-io-v1alpha1-clusterservingruntime?timeout=10s": no endpoints available for service "kserve-webhook-server-service"
Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "clusterservingruntime.kserve-webhook-server.validator": failed to call webhook: Post "https://kserve-webhook-server-service.kubeflow.svc:443/validate-serving-kserve-io-v1alpha1-clusterservingruntime?timeout=10s": no endpoints available for service "kserve-webhook-server-service"
Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "clusterservingruntime.kserve-webhook-server.validator": failed to call webhook: Post "https://kserve-webhook-server-service.kubeflow.svc:443/validate-serving-kserve-io-v1alpha1-clusterservingruntime?timeout=10s": no endpoints available for service "kserve-webhook-server-service"
Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "clusterservingruntime.kserve-webhook-server.validator": failed to call webhook: Post "https://kserve-webhook-server-service.kubeflow.svc:443/validate-serving-kserve-io-v1alpha1-clusterservingruntime?timeout=10s": no endpoints available for service "kserve-webhook-server-service"
Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "clusterservingruntime.kserve-webhook-server.validator": failed to call webhook: Post "https://kserve-webhook-server-service.kubeflow.svc:443/validate-serving-kserve-io-v1alpha1-clusterservingruntime?timeout=10s": no endpoints available for service "kserve-webhook-server-service"
Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "clusterservingruntime.kserve-webhook-server.validator": failed to call webhook: Post "https://kserve-webhook-server-service.kubeflow.svc:443/validate-serving-kserve-io-v1alpha1-clusterservingruntime?timeout=10s": no endpoints available for service "kserve-webhook-server-service"
Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "clusterservingruntime.kserve-webhook-server.validator": failed to call webhook: Post "https://kserve-webhook-server-service.kubeflow.svc:443/validate-serving-kserve-io-v1alpha1-clusterservingruntime?timeout=10s": no endpoints available for service "kserve-webhook-server-service"
Retrying to apply resources

@gpitchai did you create the OKE cluster with the terraform script provided, with the terraform provided cloud-init is applied. Please confirm OKE the version >= v1.27.2

@julioo Yes, OKE was provided using TF script and the OKE version is 1.27.2

@gpitchai How many nodes and OCPU did you deploy ? Make sure to have enough resources
Confirm containers status:
kubectl get po -A

@julioo currently I am running 7 OCPUS and 7 nodes. Following services are up and running.
NAMESPACE     NAME                                   READY   STATUS    RESTARTS        AGE
kube-system   coredns-7498987c54-548vh               1/1     Running   0               4d23h
kube-system   coredns-7498987c54-5gbv9               1/1     Running   0               4d23h
kube-system   coredns-7498987c54-8nhrg               1/1     Running   0               4d23h
kube-system   coredns-7498987c54-dbcnm               1/1     Running   0               4d23h
kube-system   coredns-7498987c54-lr6xh               1/1     Running   0               4d23h
kube-system   coredns-7498987c54-nffkb               1/1     Running   0               4d23h
kube-system   coredns-7498987c54-trcm4               1/1     Running   0               4d23h
kube-system   csi-oci-node-565zg                     1/1     Running   1 (4d23h ago)   4d23h
kube-system   csi-oci-node-gdgwz                     1/1     Running   0               4d23h
kube-system   csi-oci-node-hgnbb                     1/1     Running   0               4d23h
kube-system   csi-oci-node-mvwnb                     1/1     Running   0               4d23h
kube-system   csi-oci-node-pdgvp                     1/1     Running   0               4d23h
kube-system   csi-oci-node-xgdrq                     1/1     Running   0               4d23h
kube-system   csi-oci-node-z2lft                     1/1     Running   0               4d23h
kube-system   kube-dns-autoscaler-589f67587d-bsfqq   1/1     Running   2 (4h14m ago)   4d23h
kube-system   kube-flannel-ds-6vhgf                  1/1     Running   1 (4d23h ago)   4d23h
kube-system   kube-flannel-ds-8psv8                  1/1     Running   1 (4d23h ago)   4d23h
kube-system   kube-flannel-ds-ht4fz                  1/1     Running   1 (4d23h ago)   4d23h
kube-system   kube-flannel-ds-mwmpk                  1/1     Running   1 (4d23h ago)   4d23h
kube-system   kube-flannel-ds-n96s7                  1/1     Running   1 (4d23h ago)   4d23h
kube-system   kube-flannel-ds-prr9r                  1/1     Running   1 (4d23h ago)   4d23h
kube-system   kube-flannel-ds-r2nr8                  1/1     Running   1 (4d23h ago)   4d23h
kube-system   kube-proxy-8bkqc                       1/1     Running   0               4d23h
kube-system   kube-proxy-8wqtq                       1/1     Running   0               4d23h
kube-system   kube-proxy-fxbwd                       1/1     Running   0               4d23h
kube-system   kube-proxy-mjwtc                       1/1     Running   0               4d23h
kube-system   kube-proxy-qwnk7                       1/1     Running   0               4d23h
kube-system   kube-proxy-ssghc                       1/1     Running   0               4d23h
kube-system   kube-proxy-xkwdv                       1/1     Running   0               4d23h
kube-system   proxymux-client-55787                  1/1     Running   0               4d23h
kube-system   proxymux-client-cp5ql                  1/1     Running   0               4d23h
kube-system   proxymux-client-db22d                  1/1     Running   0               4d23h
kube-system   proxymux-client-hw8gh                  1/1     Running   0               4d23h
kube-system   proxymux-client-n6gpd                  1/1     Running   0               4d23h
kube-system   proxymux-client-qp4nr                  1/1     Running   0               4d23h
kube-system   proxymux-client-s7ctb                  1/1     Running   0               4d23h

@gpitchai please show all the namespaces, the following command
kubectl get po -A

@julioo Output that I shared in my previous comment is the output of Kubectl get po -A.
kubectl get ns
NAME              STATUS   AGE
default           Active   5d
kube-node-lease   Active   5d
kube-public       Active   5d
kube-system       Active   5d

@gpitchai can you confirm kustomize version ?

@gpitchai After further testing, we found that disabling OKE in-transit encryption may resolve the issue. Your input before closing the matter would be appreciated.

Closing make sure to disable OKE in-transit encryption


freeze all SHAs temporarily

also removed ScalaMeter because it is currently known to hang;
that's https://github.com/scala/scala-dev/issues/280
and a fix is in the works
until 2.12.1 is out the door, we don't want new errors constantly
popping up at us, especially now that the community build is part
of the release-main flow in Jenkins.  so freeze all SHAs for now.
to be unfrozen after the release is out the door.
doing this on 2.12.x, not by making a 2.12.1 branch, since the release
flow is configured to use the same branch in all involved repos.
note that I have not yet taken steps to make sure these SHAs won't
eventually disappear from GitHub, as detailed at
https://github.com/scala/community-builds/issues/338 . I should
do that at the time we unfreeze after 2.12.1.

green with a Scala SHA from a few days ago at https://scala-ci.typesafe.com/job/scala-2.12.x-integrate-community-build/1037/consoleFull

started a new run with 2.12.1-ccfa360-nightly (at the moment ccfa360 is still HEAD on 2.12.x): https://scala-ci.typesafe.com/job/scala-2.12.x-integrate-community-build/1038/consoleFull


AM-Softmax Implementation

Is there AM-Softmax implementation in this paper https://arxiv.org/pdf/2003.07618.pdf ?. Thanks

Yes, it's there.
https://github.com/opencv/openvino_training_extensions/blob/develop/pytorch_toolkit/person_reidentification/engine/losses/am_softmax.py


Update rammap v1.52

Docs Build status updates of commit d84e2d1:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sysinternals/downloads/rammap.md
:white_check_mark:Succeeded
View

sysinternals/downloads/sysinternals-suite.md
:white_check_mark:Succeeded
View

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

Docs Build status updates of commit b81ad86:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sysinternals/downloads/rammap.md
:white_check_mark:Succeeded
View

sysinternals/downloads/sysinternals-suite.md
:white_check_mark:Succeeded
View

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


[ERROR] ng new failed on @angular/cli 1.6

Versions
Angular CLI: 1.6.0
Node: 8.9.1
OS: darwin x64

Repro steps
when i launch command ng new to create a new app, i have error.
Observed behavior
ng new look-error
error! look-error/src/app/app.component.html already exists.
error! look-error/src/app/app.component.spec.ts already exists.
error! look-error/src/app/app.component.ts already exists.
error! look-error/src/app/app.module.ts already exists.
ENOENT: no such file or directory, uv_chdir
Error: ENOENT: no such file or directory, uv_chdir
at process.chdir (/usr/local/lib/node_modules/@angular/cli/node_modules/graceful-fs/polyfills.js:21:9)
at /usr/local/lib/node_modules/@angular/cli/tasks/init.js:74:25
at
at process._tickCallback (internal/process/next_tick.js:188:7)
Desired behavior
Mention any other details that might be useful (optional)

Same problem here :(

Same here on Windows 7.

I have the same problem. But the strangest thing is that when I go back to v1.5.5 this problem still occurs.
Node: 8.9.2
OS: macOS 10.13.1

Seeing this on Win 10, Node 8.1.2 too.
(I tried uninstalling, clearing NPM cache and re-installing, without luck)

I don't think it's an issue with angular-cli itself but on one of its dependencies.

Same error on Window 7 and Ubuntu 16.04.
Angular CLI: 1.6.0
Node: 8.9.2
OS: win32 x64
Angular CLI: 1.6.0
Node: 9.1.0
OS: linux x64

@yarrgh you are right, when I downgraded it to 1.5.5 and 1.4.x this problem still occured.

Same error Windows 10:
Angular CLI: 1.6.0
Node: 9.2.0
OS: win32 x64

Testing locally, I'll come back with some (hopefully good) news soon.

Same error here with Windows 10/Node 6.11.5/npm 3.10.10.
If I create the directory myself and run the command, it  has the same first errors and says it's installing packages and that it succeeds,  but there are only '.git' and 'node_modules' folders and no files, and node_modules is empty.
$ ng new tt2
error! tt2/src/app/app.component.html already exists.
error! tt2/src/app/app.component.spec.ts already exists.
error! tt2/src/app/app.component.ts already exists.
error! tt2/src/app/app.module.ts already exists.
Installing packages for tooling via npm.
npm WARN enoent ENOENT: no such file or directory, open 'C:\git\web\tt2\package.json'
npm WARN tt2 No description
npm WARN tt2 No repository field.
npm WARN tt2 No README data
npm WARN tt2 No license field.
Installed packages for tooling via npm.
Project 'tt2' successfully created.

This is a problem with trying to overwrite files in Schematics. It seems like some files were created twice and fixing a bug in validation actually uncovered the error. I'm working on a fix right now.

Thank you @hansl.

Hopefully fixed soon ...

this commit is the fix https://github.com/angular/devkit/pull/319/commits/bd25a1ff88f7c15fe3c5b4d863bd7be7b8a443c5
Will release in 5-10 minutes.

(just need to release the devkit)

Same thing here, also tested with v1.5.5

Done. Can someone checks that it works?

Should I install the the latest? @hansl

Just creating a new project should be sufficient.

@YAdelMehraban yes reinstall global CLI please.

Testing now @hansl

@hansl Just tried it, everything is working.

@hansl Can confirm working on mac os after reinstalling and creating new project. Thanks!

@hansl works now, thank you so much

Closing this issue as fixed. Thanks all!

wow, thanks :) literally just found this a few minutes ago.

Thanks for the fix Hansl!

I am completely new to this, can some one please give me some advice on how to apply the fix? Thanks in advance.

@cortez-scr npm install -g @angular/cli, ng new my-app

Oh ok, I understand . By re-executing npm install, i am downloading the fixes and automatically replacing them on my machine. Pretty cool! Thanks

Thanks @hansl

Shouldn't there be a publicly visible 1.6.1 release for this fix? I do not see it when I click on the Releases tab.

@fmorriso No, because it wasn't @angular/cli that had the issue. It was another package that @angular/cli depends on (angular/devkit package).

@yarrgh Thanks for the clarification.  I was unaware this issue was caused by another package, much less that it was fixed, which is why I waited (in vain it turns out) for a patch release to appear.
May I make a suggestion?  Whenever these situations exist and are fixed by some kind of "not visible to the general public" technique like was the case in this issue, can somebody make a public announcement (changelog.md ?, WiKi entry, etc.) so that it stands out?  Otherwise, you  have to search through the issues and hopefully notice that the issue was resolved, something I'm betting that not a lot of people will see.
Just my two cents worth.

Same issues here...Any workaround guys?
I am new to angularjs and just get angularcli installed and run
"ng new my-app" which from official getting started doc. And i got this issue.
(Win 10)
Angular CLI: 1.6.3
Node: 8.9.0
OS: win32 x64

@seekheart  try creating the project at some new path. this resolved the issue for me.


Header Sec-Fetch-* can not set

I sets the headers like these:

But in the server, I print the request headers, there are no headers Sec-Fetch-* printed.

Anybody can help me with this question?

Please, don't post pictures of code, it breaks search and accessibility. Just paste plain text and use the markdown code escape.

Please, don't post pictures of code, it breaks search and accessibility. Just paste plain text and use the markdown code escape.

ok, thank for remind


Bug with sending image message

Is the bug present in the demo Chat SDK project? (yes/no)
yes
Steps taken to reproduce bug:
once sending an image message and go back to the thread list.
and again enter any chat activity, then I can not send image message.
Expected result:
should be moved to the crop image activity.
Actual result:
gallery is just closed
Comments:
onActivityResult in ChatActivity was not called by clicking gallery image item.

Seems to be a duplicate of #195.


Support MSBuild tasks of varying versions across projects

I have an MSBuild task assembly that has multiple assembly versions (acquired via NuGet package). I’ve found that if an MSBuild node picks up one version of the assembly, it will use that version for all project builds instead of picking up another version of the assembly for another project that points at a different DLL location. This causes build breaks for the customer such as this one. It can appear either in a single build (because distinct projects use distinct versions of the task assembly) or across multiple builds (because of /nodereuse:true being the default).
Can MSBuild be taught to load each unique assembly version of an assembly that projects may have a UsingTask for?

Spent some time this week looking into this. I don't think there's going to be an easy general fix, but there are a couple of things a task author can do to work around the funky behavior.
After getting a UsingTask to associate a task with a specific assembly on disk, the actual loading of the assembly happens in TypeLoader using Assembly.UnsafeLoadFrom. LoadFrom's documentation mentions

The LoadFrom method has the following disadvantages. Consider using Load instead.

If an assembly with the same identity is already loaded, LoadFrom returns the loaded assembly even if a different path was specified.

Unfortunately, it seems to be using a broad definition of "identity" that does not always differentiate on version. If you have assemblies with the same name but different versions, the .NET assembly loader will return whichever was loaded first--as long as the assembly identity does not have a public key.
Workaround 1
The key phrase in the last sentence was does not have a public key. If the assembly is signed, the loader compares versions and will happily load different versions side by side. So one could start signing their task assembly (note that this has downsides).
Workaround 2
Alter the UsingTask that refers to your task assembly to force the task to run out-of-process by adding TaskFactory="TaskHostFactory".
When a new task host process starts, it won't have the task assembly loaded, so it will load the one specified for the project that's currently building.
This doesn't require changing the task, but does require MSBuild logic changes and will slightly slow down the build (due to the overhead of starting the task host node and IPCing to it to run the task).

Whoa. I already knew the CLR would only load multiple versions of the same assembly if it were strong-name signed. But I strongly name sign all my assemblies so I am amazed to see indeed that NB.GV isn't strong-name signed.
Thanks for the workaround. I'm happy to use that. I'll test this and close the issue after confirming it works.

Confirmed. Strong-name signing the task assembly resolved the issue. Thank you!

@rainersigwald the strategies outlined here seem applicable to only desktop MSBuild. What is the appropriate strategy for .NET Core?

My understanding is that the current answer is "there's no good strategy that the user can use at this time". That's bad. I believe the path forward is #1754, which is currently marked for consideration in the .NET Core 3.0 timeframe.


Add support for graphql-transport-ws protocol

Quick and dirty implementation of the graqhql-ws-transport protocol, as mentioned in #958
Fixes https://github.com/zino-hofmann/graphql-flutter/issues/958
Reference implementation https://github.com/enisdenjo/graphql-ws

Rebased on master, and I will review in this week with a deep drive to the spec https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md
Sorry for delay here!

Rather than using a mutex, you can probably just store the future (or maybe FutureOr) in _socketClient instead of the SocketClient.

I think this is the better solution in general, but there may still be a race between connectOrReconnect and dispose with the code as-is. Looking back, it should probably be pulled out into its own issue/PR after the core issue here is addressed (the reentrancy issue is a low likelihood/low impact leak).
There is some simplification that can occur since
  // cannot be final because we're changing the instance upon a header change.
  SocketClient? _socketClient;
...
  /// Connects or reconnects to the server with the specified headers.
  Future<void> connectOrReconnect() async {

doesn't hold for the current implementation as the headers can't be changed. This means that a single future and some simple semaphores in link & client should work and be simpler.

@jamesgorman2

I think this is the better solution in general, but there may still be a race between connectOrReconnect and dispose with the code as-is

With the explicitly calling connect and assigning the future client synchronously, can you go into detail what kind of race conditions you’re seeing?

I think this is the better solution in general, but there may still be a race between connectOrReconnect and dispose with the code as-is

I'm not able to imagine your race condition inside one client, I'm so sorry. The client should be able to send multiple requests at a time, and the server is responsible for the race condition. Of curse, putting a mutex everywhere could be good from the race condition point of view, however, for now without having a use case where the race condition is a real problem I considered the use of mutex a bad design.
Of curse, if you call a mutation and at the same time call connectOrReconnect it is a race condition, but it is a usage error!
P.S: I'm just not able to see the problem, but happy to reconsider it with a real use case or workflow that can happen inside an app.

The race is a low likelihood resource bleed:

only in the case of passing up future errors
regardless of using a future socket client or not
without restructuring the method flow

In this sequence, SC1 is disposed twice and SC2 becomes detached and cannot be disposed.
Two options are:

don't wait for _socketClient.connect() or _socketClient.dispose() - you can't pass errors out but they are safe w.r.t. calling subscribe
use futures and value swaps, something like this flows on all the errors and obeys the dispose comment:

/// A Universal Websocket [Link] implementation to support the websocket transport.
/// It supports subscriptions, query and mutation operations as well.
///
/// NOTE: the actual socket connection will only get established after a [Request] is handled by this [WebSocketLink].
/// If you'd like to connect to the socket server instantly, call the [connect] method after creating this [WebSocketLink] instance.
class WebSocketLink extends Link {
  /// Creates a new [WebSocketLink] instance with the specified config.
  WebSocketLink(
    this.url, {
    this.config = const SocketClientConfig(),
    this.subProtocol = SocketSubProtocol.graphqlTransportWs,
  });

  final String url;
  final String subProtocol;
  final SocketClientConfig config;

  bool disposed = false;

  // cannot be final because we're late binding.
  Future<SocketClient>? _socketClient;

  @override
  Stream<Response> request(Request request, [forward]) async* {
    if (disposed) {
      yield* Stream.error('Cannot request on disposed WebSocketLink');
      return;
    }

    final sc = await connect();
    yield* sc.subscribe(request, true);
  }

  /// Connects to the server with the specified headers.
  Future<SocketClient> connect() async {
    if (disposed) {
      return Future.error('Cannot connect to disposed WebSocketLink');
    }
    _socketClient ??= SocketClient(
        url,
        config: config,
        protocol: subProtocol,
      ).connect();
    return _socketClient!;
  }

  /// Disposes the underlying socket client explicitly. Only use this, if you want to disconnect from
  /// the current server in favour of another one. If that's the case, create a new [WebSocketLink] instance.
  @override
  Future<void> dispose() async {
    disposed = true;
    final fsc = _socketClient;
    _socketClient = null;
    final sc  = await fsc;
    return sc?.dispose() ?? Future.value();
  }
}

@jamesgorman2 thanks for explaining. In your example, you seem to be re-connecting on every request, is this intentional?
Alternatively, I think we can get by the race by making connectOrReconnect and dispose completely synchronous and then effectively queueing the operations. Something along the lines of:
  Future<SocketClient?> _socketClientF = Fututre.value();

  Future<SocketClient> connectOrReconnect() {
    return connectF = _socketClientF
      .then(c => c?.dispose())
      .then(() => SocketClient(url, config: config).connect());
    _socketClientF = connectF.catchError((_e) => null);
    return connectF;
  }

  Future<SocketClient> get _client => _socketClient.then((c) => c  ?? connectOrReconnect());

  /// Disposes the underlying socket client explicitly. Only use this, if you want to disconnect from
  /// the current server in favour of another one. If that's the case, create a new [WebSocketLink] instance.
  Future<void> dispose() {
    const disposeF = _socketClient
       .then((c) => c?.dispose());
    _socketClientF = disposeF.catchError((_e) => null);
    return disposeF;
  }

  @override
  Stream<Response> request(Request request, [forward]) async* {
    SocketClient client = await _client; // Possibly yield error here?
    yield* client.subscribe(request, true);
  }

you seem to be re-connecting on every request, is this intentional?

connect is behaving as connectIfNotConnected via the ??=, so will only connect to the underlying socket once. (This was a language recommendation from Idea - it replaced the original if null test I had). I'll edit it to make it clearer.
I'm also removing the ambiguity around reconnection and disposal in the current implementation, which influences my design decisions.

Alternatively, I think we can get by the race by making connectOrReconnect and dispose completely synchronous

Yes, this also works, and encapsulates the async code. Also like that you've highlighteda different failed connection behaviour.
Comparing these makes me think there are questions that should be clarified:

can a link be meaningfully reconnected?
should a link be able to reconnect after disposal?
should a failed connection be allowed to retry?
should connection errors propagate up?

connect is behaving as connectIfNotConnected via the ??=, so will only connect to the underlying socket once. (This was a language recommendation from Idea - it replaced the original if null test I had). I'll edit it to make it clearer.

 Thanks for clarifying.

Comparing these makes me think there are questions that should be clarified:

can a link be meaningfully reconnected?
should a link be able to reconnect after disposal?
should a failed connection be allowed to retry?
should connection errors propagate up?

I think these are great questions! It's not obvious to me why we should support re-connection after disposing. Instead, we should encourage users to just create another link. Arguably, I believe we should retry on requests and yield the errors as part of the response to the request. This follows the standard query and mutations where server and connection errors are returned as part of the query response.
So ideally, we could remove the reconnect feature as proposed by your solution. The problem is however that it would introduce a breaking change to the API. Which ultimately might delay the release of this feature (i.e., for a major version we most likely want to bundle up a few breaking features). So arguably, we should try and solve the race with the existing API, even though it might not be the best solution.

@budde377 thank you, exactly the sort of answers I was looking for.
@vincenzopalazzo are you still able to look at this?
I'm about to get slammed with a bunch of things, that'll tie me up for a week or two, but I'll be able to review & answer questions.

are you still able to look at this?

I put it on my to-do list and see what I can do, but I think the race condition in the context of a follow-up request, in this PR I'm interested in the was protocol support.
I will try to split this talk into one or more issues so we can keep track

I put it on my to-do list and see what I can do, but I think the race condition in the context of a follow-up request, in this PR I'm interested in the was protocol support.
I will try to split this talk into one or more issues so we can keep track

No complaints from me about breaking it up.

IMHO this PR is ready to land, I divided the other topics discussed inside the following issue:

https://github.com/zino-hofmann/graphql-flutter/issues/1124
https://github.com/zino-hofmann/graphql-flutter/issues/1123
https://github.com/zino-hofmann/graphql-flutter/issues/1122

When @budde377 will review it, I'm happy to merge!

@vincenzopalazzo good idea on postponing the other issues on another PR.
What are your thoughts on testing this?

@vincenzopalazzo good idea on postponing the other issues on another PR.
What are your thoughts on testing this?

@vincenzopalazzo, NVM, just saw #1124

NVM, just saw https://github.com/zino-hofmann/graphql-flutter/issues/1124

Yeah! just thinking what is the best way to do this integration testing, looks like we don't have a global mock server to test graphql client implementation. I'm curious how Appollo handle this integration testing


[Meta] Upgrade client from elastic-app-search to elastic-enterprise-search

elastic_enterprise_search integration plugin is using the elastic-app-search client which is now deprecated. The client to use is elastic-enterprise-search, problem that arise is that the old client permitted to connect to AppSearch SaaS simply passing the parameter :host_identifier , which represents the host for the engine, like host-2376rb while the new client doesn't accept it and is intended to be used only to connect to Elastic Enterprise Search , both on-premise or SaaS, providing the full connection URL which bring the parameter name of :host.
The problem
Existing Logstash installations that uses logstash-integration-elastic_enterprise_search up to version 2.1.2 permit to connect both to Swiftype SaaS AppSearch and ElasticEnterpriseSearch. If a user configure the host setting it goes for SaaS Swiftype else if url and path are specified is can connect to on-premise or to Elastic Enterprise SaaS.
Switching to the new client, the plugin must provide the same functionality as before, permitting to configurations containing host setting to continue to work.
Implementation
The idea is to use both clients, switching to one or the other based on which plugin options are contained in the pipeline definition.
If a user has defined host then connect to Swiftype's AppSearch SaaS using the old client elastic-app-search, for all the other cases use the new client elastic-enterprise-search.
Tasks

[x] If both host and url are provided, the plugin fails to register: "Error message telling the user that host is only using when using app search in Swiftype, and url only works for Elastic Enterprise Search".
Was already present, fixed error message with commit 2fa377c7066563612bfeee000033b26b308821bc
[x] DOC: Clarify host and path only applies to Swiftype and add a couple examples of configuration about how to use it with Elasticsearch/Elastic Cloud vs Swiftype.
[x] use host setting to automatically sends to Swiftype's SaaS (so use old client). Done with 6d70b83473716758d4d830fdb1e04c4f2eabb610
[x] useurl setting to sends to Elastic Enterprise Search (so use new client). Done with 6d70b83473716758d4d830fdb1e04c4f2eabb610
[x] Unit Test: setting host would only ensure we use the old client. Done with a4e420d35648ea2037f766ede76714af9182640a
[x] Integration Test: setting url would continue to work as it does now, using the NEW client. Do not add a integration test for old behavior. Test already present
[x] Deprecation warning about host setting saying "this will go away when Swiftype app search service is shutdown". Only when using this setting. Done with commit 2d943e51988cd0b856b08db7435ff66d06ffec25

PR #3 implements all of this and  released with 2.2.0


"Recieve to" doesnt work

Behavior:
When doing a right click on a utxo in the UTXOs tab and pressing on "Recieve to" at any UTXO nothing happens.
Expected Behavior:
Switch to recieve tab with a recieve adress which will direct funds to the selected utxo in the utxo tab.
Version 1.4.1
Ubuntu 21.04

Thanks for the report. Fixed in 911153e.
Note you won't be directing funds to that UTXO, but rather to the same address as that UTXO. This is not generally good practice (but certainly is valid).


Some musthave features

-Downgrade java version to 1.7
-Add summary logging
-Add exclude configuration parameter

Codecov Report

Merging #2 into master will increase coverage by 1.89%.
The diff coverage is 88.37%.

@@            Coverage Diff             @@
##           master       #2      +/-   ##
==========================================
+ Coverage   74.64%   76.54%   +1.89%
==========================================
  Files           4        5       +1
  Lines          71       81      +10
  Branches       11       12       +1
==========================================
+ Hits           53       62       +9
  Misses         13       13
- Partials        5        6       +1

Impacted Files
Coverage Δ

...om/github/unknownnpc/plugins/JsonToStringMojo.java
83.33% <100%> (+11.11%)
:white_check_mark:

...om/github/unknownnpc/plugins/util/SummaryUtil.java
57.14% <57.14%> (ø)

...com/github/unknownnpc/plugins/util/FileIOUtil.java
83.33% <87.5%> (+1.28%)
:white_check_mark:

Continue to review full report at Codecov.

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


Any plans on adding multiple backends

Do you have any plans on adding different backends like Vulkan/OpenglES/Metal?

Ok, it seems to be working, the code for initialization:
#define GLFW_INCLUDE_ES2
#include <GLFW/glfw3.h>

int main()
{
    glfwInit();

    glfwWindowHint(GLFW_CLIENT_API, GLFW_OPENGL_ES_API);
    glfwWindowHint(GLFW_CONTEXT_CREATION_API, GLFW_EGL_CONTEXT_API);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 2);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 0);
    GLFWwindow* window = glfwCreateWindow(1920, 1080, "Window Title", NULL, NULL);
    glfwMakeContextCurrent(window);

    while (1) {
        glClearColor(0.0f, 1.0f, 1.0f, 1.0f);
        glClear(GL_COLOR_BUFFER_BIT);
        glfwSwapBuffers(window);
    }
}

On touching the screen the output in logs is:
V/threaded_app: New input event: type=2
On window focus change, there are also events:
V/threaded_app: WindowFocusChanged: 0x6fdb41ca00 -- 0
V/threaded_app: WindowFocusChanged: 0x6fdb41ca00 -- 1

Wow. That is very exciting. Do you have it drawing? Can you post a screenshot?
That would make my day. Very cool.

Yes it is drawing, however I noticed that the merge stopped. It seems that the GLFW API is not very suitable for touch events and the changes were not merged completely.
I have found GLFM, a different library inspired by GLFW that is specialized for Android and IOS, I tried to run an example however there are some errors coming from native VM side which may prove a big pain to fix.

Ok, now this is very promising. I got the application working and it responds to touch events very well.
Here are some screenshots:

And after moving using the touch:

Goddamn it even works with external keyboard connected via usb, so in theory it should work with virtual keyboard no problems

Uh yeah. That is fantastic

Hell yeah!


Security vulnerabilities

HEAD is now at a236157... Merge pull request #662 from OA-PASS/develop
npm WARN notice [SECURITY] atob has the following vulnerability: 1 moderate. Go here for more details: https://nodesecurity.io/advisories?search=atob&version=2.0.3 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] lodash has the following vulnerability: 1 low. Go here for more details: https://nodesecurity.io/advisories?search=lodash&version=3.10.1 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] is-my-json-valid has the following vulnerability: 1 low. Go here for more details: https://nodesecurity.io/advisories?search=is-my-json-valid&version=2.17.1 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] sshpk has the following vulnerability: 1 high. Go here for more details: https://nodesecurity.io/advisories?search=sshpk&version=1.13.1 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] tunnel-agent has the following vulnerability: 1 moderate. Go here for more details: https://nodesecurity.io/advisories?search=tunnel-agent&version=0.4.3 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] stringstream has the following vulnerability: 1 moderate. Go here for more details: https://nodesecurity.io/advisories?search=stringstream&version=0.0.5 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] randomatic has the following vulnerability: 1 low. Go here for more details: https://nodesecurity.io/advisories?search=randomatic&version=1.1.7 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] debug has the following vulnerability: 1 low. Go here for more details: https://nodesecurity.io/advisories?search=debug&version=2.6.8 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] mixin-deep has the following vulnerability: 1 low. Go here for more details: https://nodesecurity.io/advisories?search=mixin-deep&version=1.3.0 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] lodash has the following vulnerability: 1 low. Go here for more details: https://nodesecurity.io/advisories?search=lodash&version=4.17.4 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] hoek has the following vulnerability: 1 moderate. Go here for more details: https://nodesecurity.io/advisories?search=hoek&version=2.16.3 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] growl has the following vulnerability: 1 critical.

I'd estimate 6 hours of work to remove the critical and high vulnerability issues here.

I"m not sure which security vulnerability was patch, but verification shown that there is still a critical security vulnerability see file attached. This ticket will remain opened until no critical security vulnerability is reported
npm-audit.txt

Will park this issue until an ember developer is available.

in PR #715 the remaining security vulnerabilities were resolved.


SaltpackVerify: Remove unused global context

Makes it easier to use these methods in other packages, like
go-updater. Since this stuff only has logging dependencies maybe we
could move it into the saltpack package.
FYI, we should be using GlobalContext infrequently if possible, and
instead use interfaces.

@maxtaco @oconnor663

:+1:


What is the final version of the library?

Reported by beutlich on 16 Dec 2015 22:59 UTC
Since 3cfd14d5f1894be8fb17f98c47b637368440f4cd the following note
// IMPORTANT NOTE
// This parameter may be removed in the final version of the library
// for consistency reasons with respect to the single phase
// electromagnetic converter, where the orientation shall NOT be
// implemented in the final version

was added to MultiPhaseElectroMagneticConverter.
Please revise that note or check if the orientation parameter can be removed as intended.

Migrated-From: https://trac.modelica.org/Modelica/ticket/1863

Comment by ahaumer on 19 Dec 2015 21:16 UTC
resolved by 811c96eb7a71c641c5896f9b27bbf34016f1d097

Modified by ahaumer on 19 Dec 2015 21:16 UTC


Dev License

When i try tu publish an extension i get the error "The request for path /NAV/dev/apps?SchemaUpdateMode=recreate failed with code 422. Reason: Your program license does not allow you to publish 'GRWPagExtPacWebServiceDetails'."
this is in a server with a container, i search online and it appears is my license but i do not know how to get my dev license, i work for a partner
My extensions add a new field to a existing table and add the field to a page everything compiles good

Can you open finsql from container, upload dev licence and restart service within container?
Or upload licence from cmd inside container and restart service.

Can you open finsql from container, upload dev licence and restart service within container?
Or upload licence from cmd inside container and restart service.

My doubt is where i get the license? i create my container from BC online enviroment

If you work for a partner then you should ask somebody in your company to provide you .flf file. There is parameter -licenseFile in New-NavContainer command when you create new container.
Like this
New-NavContainer -containerName BCNLA -accept_eula -additionalParameters --publish-all -auth NavUserPassword -doNotExportObjectsToText -enableSymbolLoading -imageName mcr.microsoft.com/businesscentral/sandbox -includeCSide -includeTestToolkit -isolation process -licenseFile "D:\Lic\My_License_File.flf" -memoryLimit 4G -updateHosts -useBestContainerOS

If you work for a partner then you should ask somebody in your company to provide you .flf file. There is parameter -licenseFile in New-NavContainer command when you create new container.
Like this
New-NavContainer -containerName BCNLA -accept_eula -additionalParameters --publish-all -auth NavUserPassword -doNotExportObjectsToText -enableSymbolLoading -imageName mcr.microsoft.com/businesscentral/sandbox -includeCSide -includeTestToolkit -isolation process -licenseFile "D:\Lic\My_License_File.flf" -memoryLimit 4G -updateHosts -useBestContainerOS

i get my sandbox enviroment from a BC 365 with locally host option where can i download the license, i ask the team that create that BC 365 and they do not know anything about that file


Crashes in 1.19.1

https://crashy.net/9GeoPw3TfrGYOhhRUrBi
Can you add an 1.19.1 version?

I hadn't realized it wouldn't work in 1.19.1 - I'll take a look.
It appears to be due to the SendPacketMixin no longer getting added in, which might make it annoying to fix.

I've just released v1.6.2 to fix this! Thanks.


ESM loading fails for native<EMAIL_ADDRESS>loader

Description
I'm trying to import xstate using Node@13 native support for ES Modules.
Expected Result
Should be able to import as specified is the docs
Actual Result

The requested module 'xstate' does not provide an export named 'Machine'

Reproduction

Simply run the following code after installing xstate and run it with Node >= 13.0.0
import { Machine } from 'xstate';

Additional context
I've tried both setting the "type": "module" in my package.json and renaming the script file to *.mjs, but the error still persists.
Out of curiosity, I decided to use the import-star syntax to see what happened:
import * as xs from 'xstate';

console.log(xs);

It outputs:
[Module] {
  default: {
    matchesState: [Function: matchesState],
    mapState: [Function: mapState],
    StateNode: [Function: StateNode],
    State: [Function: State] {
      from: [Function (anonymous)],
      create: [Function (anonymous)],
      inert: [Function (anonymous)]
    },
    Machine: [Function: Machine],
    createMachine: [Function: createMachine],
    send: [Function: send],
    sendParent: [Function: sendParent],
    sendUpdate: [Function: sendUpdate],
    assign: [Function (anonymous)],
    doneInvoke: [Function: doneInvoke],
    forwardTo: [Function: forwardTo],
    interpret: [Function: interpret],
    Interpreter: [Function: Interpreter] {
      defaultOptions: [Object],
      interpret: [Function: interpret]
    },
    spawn: [Function: spawn],
    matchState: [Function: matchState],
    actions: {
      raise: [Function: raise],
      send: [Function: send],
      sendParent: [Function: sendParent],
      sendUpdate: [Function: sendUpdate],
      log: [Function: log],
      cancel: [Function (anonymous)],
      start: [Function: start],
      stop: [Function: stop],
      assign: [Function (anonymous)],
      after: [Function: after],
      done: [Function: done],
      respond: [Function: respond],
      forwardTo: [Function: forwardTo],
      escalate: [Function: escalate]
    },
    ActionTypes: {
      Start: 'xstate.start',
      Stop: 'xstate.stop',
      Raise: 'xstate.raise',
      Send: 'xstate.send',
      Cancel: 'xstate.cancel',
      NullEvent: '',
      Assign: 'xstate.assign',
      After: 'xstate.after',
      DoneState: 'done.state',
      DoneInvoke: 'done.invoke',
      Log: 'xstate.log',
      Init: 'xstate.init',
      Invoke: 'xstate.invoke',
      ErrorExecution: 'error.execution',
      ErrorCommunication: 'error.communication',
      ErrorPlatform: 'error.platform',
      ErrorCustom: 'xstate.error',
      Update: 'xstate.update',
      Pure: 'xstate.pure'
    },
    SpecialTargets: { Parent: '#_parent', Internal: '#_internal' }
  }
}

So it looks like even though state has an ESM target, it doesn't seem it's being properly loaded, because this looks like the CommonJS exported module.
For reference, here's my package.json:
{
  "name": "xstate-labs",
  "version": "1.0.0",
  "module": "index.js",
  "license": "MIT",
  "type": "module",
  "dependencies": {
    "xstate": "^4.7.7"
  }
}

Tested with<EMAIL_ADDRESS>

I've educated myself about ESM support in node@13 and I think I understand its intricacies now. It's not as easy to support it as I have thought - when you also want to support older nodes, bundlers etc (and we do).
I will explore making it work in v5, but at the moment I don't think it's worth it to include this in v4.
If you want to patch your node_modules and xstate in it then I think this should work if you add this to pkg.json
"type": "module",
"exports": "./es/index.js"

I've looked into what it would take to add support for this - even if it looks simple, it is not that trivial in the case of XState (it has some module state). I want to add support for this eventually, but it's not a priority right now.

I get the same problem with node v13.9.0 and xstate 4.8.0.
SyntaxError: The requested module 'xstate' does not provide an export named 'interpret'
Any developments on this issue?

Literally the previous comment says that we wont work on this right now and that we are going to tackle this in upcoming v5

With that said, I'd accept a PR from someone who wants to fix this for the current version.

Problem is that this would be a breaking change for all of our ESM-node consumers - im not sure if it would be a good thing to “fix” this within v4 for that reason because we know that this would break all of those consumers immediately.

So, in the meantime what is your advice to keep things gong? Revert to a previous version of node.js? Which, by the way?

In the meantime, found this workaround:
npm install esm
node -r esm xstateTest.js

Also added this line to launch.json node xstateTest.js launch configuration:
"runtimeArgs": ["-r", "esm"]

Sorry for not responding sooner, I've missed your reply.

So, in the meantime what is your advice to keep things gong?

use CJS
or use default export for now
or use esm loader like you have done.

Just an update - we'll be providing "exports" field in the future in the XState 5. It's not yet implemented and nor v5 is ready to be shipped even as a prerelease but at least I have a plan now to make this happen. At this point in time, pkg.json#exports semantics seem to be pretty stable as webpack is going to ship support for it soon-ish, so it should be safe for us to start using that in the future.

I know this is not going to be fixed for this version (I read the older comments), but just as a question: does this it not fixed by either using the .mjs extension or adding the "type": "module" to the package.json?
trying to learn about these issues myself, since I have a full-ESM setup even for testing (using vitest)

.mjs extension might break some older tools that might work with XState today.
I feel super bad about issues like this - I understand the pain of the users trying to utilize this. I've wasted dozens of hours maneuvering through that ESM mess, trying to figure out a solution that would work everywhere, with every tool, for every package. This has been proven to be just impossible.
Some solutions work for some packages while they might not work for some other packages. Trying to figure out a perfect combination of things that can be done to address this in a particular package is exhausting and is always associated with a risk that we won't get it right for the first time (for the record - I've been going through this with Nicolo from the Babel team and it took him like 5 patch releases of the @babel/runtime to land on something that has worked in all of the supported contexts. The situation with XState would probably be simpler but still...).
We also can't just use the type: module or .mjs because that would make it impossible to require XState in node and there is surely code out there that needs this to work.
However, I think that we are only using named exports and currently node should be able to load CJS files with named exports from an ESM file - if only those named exports are declared in a certain way (to be statically analyzable). If you prepare a runnable repro case of the problem I might take a look at this to assess what's going on. Note that this was not true at the beginning and there are node versions out there that can't do this - but AFAIK all of the latest versions in any major line of node with ESM support should already be able to handle this.

I have a reproduction repo I can push tonight! I manage to fix it by setting a config on vitest side.
one solution that could work is basically having a separate esm version of the library. since this could be just a different build config it could be generated so we can avoid code duplication and inconsistencies. something like:
import { createModel } from 'xstate/esm'

not sure if this is important for this version or maybe v5!
thanks for your response @Andarist !

adding some references of issues that happens with other packages with similar configurations as xstate:
https://github.com/vitejs/vite/issues/6395
https://github.com/horacioh/vitest-radix-demo

I've verified that node can load XState just fine, using the code like this:
import { createMachine } from 'xstate'
import { createModel } from 'xstate/lib/model.js'

console.log({
    createMachine,
    createModel
})

If the issue is about Vite/Vitest... well, this is kinda their issue, right? 😉 I mean, especially for Vitests, this sounds like an infancy problem that hopefully should be fixed somewhat soon. Fixing this anyhow on our side would be rather counter-productive because that would only fix compatibility with this specific tool for a single package (XState). The proper fix to fix compatibility with valid packages should be pursued on their side.

@Andarist yes you are right, there's no real issue withing XState in order to use it with Vite nor Vitest. I was commenting the issues I have related to libraries as XState that does not export .mjs modules or have the "type": "module" attribute in the package.json.
I add those references since you mentioned you are trying to figure out a way to make the compat issue for v5. Just as a reference, not as something that needs to change in XState specifically.
Sorry that you felt it was something I wanted to be fixed here just to make it work with my current tooling, that was not the intent!! Actually I would love some hints and other links I can read to understand this compat issue better, but this is also out of scope of this issue ;)
Looking forward to see how v5 looks like!! 💪🏼

The last time that I've checked this, XState was actually compatible with ESM loader in node. That is mostly thanks to us not using default exports. It is true that XState was not compatible with that right from the start. However, that was back when the ESM support was still marked as experimental in node. The improved support for loading CJS modules from ESM modules has been introduced in this PR and ESM modules have only been marked as stable after that.
So I think it's fair to close this issue. If you find any problems with any tooling - I could take a look at your repro cases to assess what's wrong and where. I don't think though that such issues would be XState issues.

On Node v21.2.0 with freshly npm installed version of xstate.
Project has one file.
index.mjs
import { createMachine } from "xstate";

and
node index.mjs

produces
SyntaxError: The requested module 'xstate' does not provide an export named 'createMachine'


chore: bdd-ghfjxy-import-1586820189 to 0.0.1

chore: Promote bdd-ghfjxy-import-1586820189 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Can not find perception input

How can I find the perception module inputs, for example:
128 channel LiDAR data (cyber channel /apollo/sensor/velodyne128)

Generally speaking the DAG file hold the channel infos and manage the topologies.

You can find perception input from "apollo/modules/perception/production/dag/dag_streaming_perception.dag".

Also there are some topic register in component "Init" by readers.

  chassis_reader_ =
      node_->CreateReader<Chassis>(chassis_reader_config, nullptr);

Both are needed inputs.

Thanks for your kind reply!
Would you also tell me:

Is that possible to include a new sensor in the localization or perception modules to collect simulated data and show it in Dreamview?

Are there some methods to simulate the sensors for apollo?

Best wishes!

According to my understanding, I think it depends on what function you want to verify.

If you need to subscribe to messages, you just need to create a new "reader" to subscribe to the corresponding topic.
Functional verification requires you to design it yourself. If you want to add a camera and display obstacles, this requires you to subscribe to new messages in the perception module and increase sensor fusion.

谢谢大佬回复。可能用中文能描述的更精确一些。

如果我想添加新的传感器例如新的IMU或者camera，而不是apollo已有的传感器到平台上是否可行，如果可行要在哪些地方添加进去呢？
我现在没有硬件，如果我想模拟出不同的传感器设备，并获得相应的数据传输到apollo，并且在dreamview中显示，该如何操作呢？
谢谢！

1.I found some reference but not exactly you need link
Maybe you should add the driver, and then publish the topic, you can ref the code in apollo.

You can use a simultor to mock the hardware. like lgsvl.

These two tasks may take some time, and the detailed steps may not be explained here. It is recommended that you try them first.

Super! Thanks a lot!

Did the suggestion above help solve your issue? We will close the issue for now. If you have any additional question, please feel free to open a new issue.


[adobepass] Add mso FX Preview Pass

Please follow the guide below

You will be asked some questions, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your pull request (like that [x])
Use Preview tab to see how your pull request will actually look like

Before submitting a pull request make sure you have:

[x] At least skimmed through adding new extractor tutorial and youtube-dl coding conventions sections
[x] Searched the bugtracker for similar pull requests
[x] Checked the code with flake8

In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[ ] Bug fix
[x] Improvement
[ ] New extractor
[ ] New feature

Description of your pull request and other information
Add FX Preview Pass as new mso TempPass_fx_60min.

This also works with ViceTV (TempPass_VICELAND_30min)


expose E2E signing somehow so we can use it for signing things like messages or attachments a la PGP

I'm not sure what this means exactly: is this talking about the federation signing stuff or the encryption signing stuff (which already covers messages?)?

I'm assuming it's talking about signing for unencrypted messages.


IPv6 binding with Dual Stack Support

This PR will allow binding to IPv6 addresses. It also has ability to accept both IPv4 and IPv6 connections by creating a Dual Stack bind on supported systems.

Hello @simonrob , I was just wondering if you had a chance to review this ?

Hello @simonrob .
Dual Stack initially didn't work as I has set the environment to Python 3.6, because I read #120 and the README and assumed that this was supposed to support Python 3.6+
But when I changed to Python 3.8,  dual stack worked fine.
Single Stack IPv6 (or IPV4) Binding is working fine for Python 3.6 (as well as 3.8)
I see that you have added a comment regarding this in the code, but maybe you could add a note in the README or config file as well that dual-stack will only work with Python 3.8+ as usually users will not go through the code.

Thanks for the review – I've clarified in the configuration file readme. All good to merge now I think.


humanize.naturalDay() doesn't apear to return today, yesterday as apropriate

`humanize = require("humanize")
console.log( humanize.naturalDay(new Date(),"m-d-Y" ) )
// returns "07-08-2016"`
Doesn't work on my application or tonicDec/npm

I hit the same issue and figure it how. You need to pass a unix timestamp, not a date object.
something like:
console.log( humanize.naturalDay(new Date().getTime() / 1000,"m-d-Y" ) )
If you use moment.js you can just do:
console.log( humanize.naturalDay(moment().unix(),"m-d-Y" ) )


Failed to fetch dynamically imported module "/_nuxt/OpeningHours.CTqYYKGj.js"

Environment

Operating System: Windows_NT
Node Version:     v21.6.1
Nuxt Version:     3.11.1
CLI Version:      3.11.1
Nitro Version:    2.9.5
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      runtimeConfig, sourcemap, app, css, modules, i18n, alias, auth, build, site, schemaOrg, ogImage, sitemap, devtools
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

Reproduction
This is an indeterministic bug in production, I cannot find commonalities when it occurs. Apple users (Safari browser) tend to have it more often. I get a lot of sentry errors and see it in the server logs, but mixed with a lot of correct requests, it works on all my devices and on ones of my colleagues, but according to sentry there are users who experience crashes.
Describe the bug
According to our sentry report, there are regular crashes of the app on many different pages (sometimes on the homepage, sometimes during search etc.), when nuxt fails to resolve a file path and the app crashes.
The majority of logs are fine, but still we see a regular issues popping up in sentry. The components that fail to resolve are also different. They work on all my devices, so I cannot reproduce the error in production. Nor does it occur in development.
We host the app on Azure App Service.
I recently upgraded to the latest nuxt version, where the naming of the chunks was changed, still I saw some logs today that a component with the old naming style could not be imported. I am not opting in for the old one, I switched to the default new one.
Can setting the builder: 'webpack' help?
I feel like this issue might be related @danielroe ? #21780

Additional context
No response
Logs
No response

I suspect this is due to new deployments and failing to load a dynamic chunk after a new deployment occurs, which might have invalidating existing public assets. We currently handle chunk loading errors when navigating across routes but we could probably think about whether there is anything we could do when that is a dynamic component import.

@danielroe is there anything I can do to avoid this crashing in production? did I understand correctly that this is due to the fact that I use Lazy components - i.e. dynamically loaded ones? Or is this an internal issue?

I can confirm that this issue (and others like it) occurs after a new deployment. This isn't just related to "Lazy Components" as it gives me the "Failed to load dynamically..." message for pages, layouts and middleware modules (chunks) as well. My observations when the error occurs:

Lazy components
The new deployment has not yet been detected by the check-outdated-build plugin
The new deployment is detected by check-outdated-build and handled by Nuxt, but an unhandled exception still occurs (this error should be ignored)
After a new deployment, somehow after a new visit, the old version of the page is loaded (how? Browser cache?) and immediately crashes with a "Failed to load dynamically..." for chunks that have changed (new file hash?)

@michalzaq12 thank you for your observations! So I am using GitHub actions with Azure app service to deploy the app. Will a manual build an deploy via file upload for example help?

@mikeCrafted it won't help. For now, there is no way to avoid these errors.

We've also encountered these errors after deployments, which we fixed by triggering page reload on chunk error by adding the following file plugins/error-handler.ts:
export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.hook('app:chunkError', () => {
    window.location.reload()
  })
})

I believe Nuxt should handle this internally, as I am sure it is a common problem.
Related Issues can be found on this thread: https://github.com/nuxt/nuxt/issues/14594

@meirroth I think this handler is already added by default in Nuxt, see #19086
am I right, @danielroe ? Or can this custom plugin indeed make a difference?

@mikeCrafted From what I understood, and I could be wrong, the built in handler takes care of errors only during route navigation. The plugin I shared above helps with any other chunk loading errors, such as lazy components.

@meirroth oh, that is interesting! why are you not using reloadNuxtApp() instead of window.location.reload()?

We've also encountered these errors after deployments, which we fixed by triggering page reload on chunk error by adding the following file plugins/error-handler.ts:
export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.hook('app:chunkError', () => {
    window.location.reload()
  })
})

I believe Nuxt should handle this internally, as I am sure it is a common problem. Related Issues can be found on this thread: #14594

I see the possibility of an endless reload loop. That's probably why Nuxt doesn't support it internally.

@michalzaq12 adding a query parameter to the URL would help, right? so that we can tell if a reload was already attempted.

@meirroth oh, that is interesting! why are you not using reloadNuxtApp() instead of window.location.reload()?

@mikeCrafted  Haven't tried that. I'll give it it a shot now.

I see the possibility of an endless reload loop. That's probably why Nuxt doesn't support it internally.

@michalzaq12 How so? I haven't encountered any issue in my testing, and got this running in production.

@mikeCrafted reloadNuxtApp() is a wrapper for window.location.reload() with additional features like ttl and persistent useState. So considering we use Pinia and not useState, and I didn't need ttl window.location.reload() was good on it's own. But they both work, I just tested.

@mikeCrafted torahlive.com 😃

To avoid most errors:

Do not delete old files during deployment, allow the user to smoothly update to the new version after a new visit (or when check-outdated-build detects new version)
Make sure that all .html files are not cached (check Cache-Control header)
Finally, you can add a plugin for users who still have a problem:

export default defineNuxtPlugin(nuxtApp => {
  const MAX_RETRIES = 2;
  const QUERY_PARAM_NAME = 'nuxt_reload_attempt'

  // Handle "Failed to fetch dynamically imported module ..." or similar issues
  nuxtApp.hook('app:chunkError', () => {
    const searchParams = new URLSearchParams(window.location.search);
    const currentRetry = Number(searchParams.get(QUERY_PARAM_NAME)) || 0
    if (currentRetry < MAX_RETRIES) {
      console.log('[nuxt]: Reloading due to chunk error')
      searchParams.set(QUERY_PARAM_NAME, (currentRetry + 1).toString())
      // Changing the search also causes a refresh
      window.location.search = searchParams.toString()
    }
  })
})

I see the possibility of an endless reload loop. That's probably why Nuxt doesn't support it internally.

@michalzaq12 How so? I haven't encountered any issue in my testing, and got this running in production.

Duplicate of https://github.com/nuxt/nuxt/issues/23612

To avoid most errors:

Do not delete old files during deployment, allow the user to smoothly update to the new version after a new visit (or when check-outdated-build detects new version)
Make sure that all .html files are not cached (check Cache-Control header)
Finally, you can add a plugin for users who still have a problem:

export default defineNuxtPlugin(nuxtApp => {
  const MAX_RETRIES = 2;
  const QUERY_PARAM_NAME = 'nuxt_reload_attempt'

  // Handle "Failed to fetch dynamically imported module ..." or similar issues
  nuxtApp.hook('app:chunkError', () => {
    const searchParams = new URLSearchParams(window.location.search);
    const currentRetry = Number(searchParams.get(QUERY_PARAM_NAME)) || 0
    if (currentRetry < MAX_RETRIES) {
      console.log('[nuxt]: Reloading due to chunk error')
      searchParams.set(QUERY_PARAM_NAME, (currentRetry + 1).toString())
      // Changing the search also causes a refresh
      window.location.search = searchParams.toString()
    }
  })
})

Doc says that hard reload at the route level is done by default: https://nuxt.com/docs/guide/going-further/experimental-features#emitroutechunkerror.
If the idea is to watch for that hook and refresh the window, I believe adjusting the emitRouteChunkError to manual might be required to avoid weird behaviour or making hard to debug what really is fixing the issue.
I'm having the same issue. Currently, deploying at Cloudflare Pages; and all cache settings were reviewed. We tried using a similar approach as the proposed plugin; even adding a t=Date.now() to the URL upon refresh to double down in the cache refresh force was not enough.

I've just started to have these errors on production, after updating to v3.12.2.
Solved it by replacing
experimental: {
    componentIslands: {
        selectiveClient: 'deep'
    }
}

with
experimental: {
    componentIslands: 'local+remote'
}

as per docs https://nuxt.com/docs/api/components/nuxt-island.

@urbgimtam Do you have any component called 'nuxt-island' in your code base?

No, this is configuration on nuxt.config.ts.
A quarta, 19/06/2024, 15:20, 1cor13 @.***> escreveu:

I've just started to have these errors on production, after updating to
v3.12.2.
Solved it by replacing
experimental: {
componentIslands: {
selectiveClient: 'deep'
}
}
with
experimental: {
componentIslands: 'local+remote'
}
as per docs https://nuxt.com/docs/api/components/nuxt-island.
@urbgimtam https://github.com/urbgimtam Do you have any component
called 'nuxt-island' in your code base?
—
Reply to this email directly, view it on GitHub
https://github.com/nuxt/nuxt/issues/26565#issuecomment-2178840425, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIDITLHTOOFMQSFO76TMD3ZIGHT3AVCNFSM6AAAAABFOYFQ76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZYHA2DANBSGU
.
You are receiving this because you were mentioned.Message ID:
@.***>

I also encountered this problem when I used nginx and a domain name for reverse proxy. The error did not occur when I accessed the port directly using the IP address. The problem was that it was normal once in the middle, and I thought I had solved the problem until I updated the files the next time.

Upstream issue in vite:
https://github.com/vitejs/vite/issues/11804

We've also encountered these errors after deployments, which we fixed by triggering page reload on chunk error by adding the following file plugins/error-handler.ts:
export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.hook('app:chunkError', () => {
    window.location.reload()
  })
})

I believe Nuxt should handle this internally, as I am sure it is a common problem. Related Issues can be found on this thread: #14594

Thanks for sharing this. Did you stop seeing the errors in Sentry after adding this? Or is this just making sure the app reloads if an error of this kind comes up?

@leopoldkristjansson Sure! It didn’t stop the errors in Sentry, but the issue is fixed from the user’s perspective.

@leopoldkristjansson Sure! It didn’t stop the errors in Sentry, but the issue is fixed from the user’s perspective.

@meirroth - OK, exactly. Thanks again!

The next release of Nuxt v3 will ship a significant fix to this - hopefully you might be able to avoid custom solutions then 🙏  (Let me know if that doesn't resolve things for you!)

Hey, is there any update for this?
Also, is it possible to somehow store these chunks on a CDN to prevent new deployments from breaking existing users' apps?

The next release of Nuxt v3 will ship a significant fix to this - hopefully you might be able to avoid custom solutions then 🙏 (Let me know if that doesn't resolve things for you!)

@danielroe which version has this issue fixed?

Any updates on this?

@BlazingTide @1cor13 @MarkusLund Here is the fix from @danielroe
https://github.com/nuxt/nuxt/commit/820908696
Released mit der nuxt version 3.13.2

@BlazingTide @1cor13 @MarkusLund Here is the fix from @danielroe 820908696
Released with nuxt version 3.13.2

The problem continued here even after updating to this version or using any of the mentioned plugins. The problem is when you press the browser's back button.

I managed to get around the error by following the tips suggested here. Thanks @meirroth
Here is my plugin "0.error-handler.client.ts" with three ways to get around this localhost error:
export default defineNuxtPlugin(() => {
  const router = useRouter()

  if (process.env.NODE_ENV === 'development') {
    // Mode 1
    router.onError((error) => {
      if (error.message.includes('Failed to fetch dynamically imported module')) {
        window.location.reload()
      }
    })

    /*
    // Mode 2
    context.hook('app:chunkError', () => {
      window.location.reload()
    })
    */

    /*
    // Mode 3
    context.hook('app:error', (error) => {
      if (error.message.includes('Loading chunk')) {
        window.location.reload()
      }
    })
    */
  }
})

I'm still seeing this on 3.14.1592 - it's triggering the full error page I've defined as described in the documentation here .
From my understanding of the error handling in nuxt.ts, it's checking for CSS failures, but not any JS ones (hence the need for your plugin above @TonhaoSantos (which I'm trying out now).
Seems like an easy one to add on the face of it, I'd be happy to try submit a pull request to add that error check, would save us needing plugins and custom solutions

I've seen a similar issue with Sentry. I think the only solution is to do an Atomic Deployment on the infrastructure side and leave the old version of the file for a certain period of time.


Support for laravel 6.x changes

Correction version limit for illuminate/support

I also adjusted some errors in README.md

Hi @silviayc, It will become a new project if you change the name of the package.

Hi @minchao
This is a mistake because I am not yet familiar with GitHub.
I resubmitted a modification.


Fix conpty cursor movement detection on double-width lines

Summary of the Pull Request
When the VT render engine checks whether the cursor has moved in the
InvalidateCursor method, it does so by comparing the origin of the
given cursor region with the last text output coordinates. But these two
values are actually from different coordinate systems, and when on a
double-width line, the x text coordinate is half of the corresponding
screen coordinate. As a result, the movement detection is sometimes
incorrect.
This PR fixes the issue by adding another field to track the last cursor
origin in screen coordinates, so we have a meaningful value to compare
against.
References and Relevant Issues
The previous cursor movement detection was added in PR #17194 to fix
issue #17117.
Validation Steps Performed
I've confirmed that the test case from issue #17232 is now fixed, and
the test case from issue #17117 is still working as expected.
PR Checklist

[x] Closes #17232

Given the number of times I've got this wrong already, I wouldn't be surprised if there is still some edge case that I'm missing, but I think this should be correct now.


Added error UUID to SNS message and user-facing display

Closes #494.

Looks good to me. I'd want to include the uuid in the body of the email as well, but I can add that on a separate issue.

✅ Added the UUID to the email subject.


Move headers under serac to avoid collisions

physics/base_physics.hpp -> serac/physics/base_physics.hpp
This should happen in both the repository (src/serac/physics) and the installed include directory.

Tagging @samuelpmishLLNL since he asked about this feature.