null is not an object (evaluating 'this.$$scope.$root.$$phase')

I'm submitting a ...

[x] bug report
[ ] feature request
[ ] other (Please do not submit support requests here (see above))

Current behavior:
An error is thrown on mobile safari from Angular's internals:
null is not an object (evaluating 'this.$$scope.$root.$$phase')

Relevant lines of code from Angular source (error originates from the else if line):
var that = this;
    if (debounceDelay > 0) {
      this.$$pendingDebounce = this.$$timeout(function() {
        that.$commitViewValue();
      }, debounceDelay);
    } else if (this.$$scope.$root.$$phase) {
      this.$commitViewValue();
    } else {
      this.$$scope.$apply(function() {
        that.$commitViewValue();
      });

Expected / new behavior:
For the error not to throw.
Minimal reproduction of the problem with instructions:
Unfortunately I have none, this was caught in production on a mobile safari client. Could have been a one-off, as we've not encountered this error before, nor on other platforms/clients.
It originated from the this.$$debounceViewValueCommit(trigger); call in $setViewValue().
Could have been introduced in 1.6.6 or 1.6.5, as this error did not occur prior to that version.
AngularJS version: 1.6.6
Browser: Mobile safari iOS 10.3.1
Anything else:
TypeError: null is not an object (evaluating 'this.$$scope.$root.$$phase')
  at $$debounceViewValueCommit(angular.js:13756:0)
  at $setViewValue(angular.js:13737:0)
  at call(angular.js:12304:0)
  at handlerWrapper(angular.js:2078:0)
  at apply(angular.js:2068:0)
  at r(raven.js:294:0)

Any thoughts on what might have caused it and under what circumstances $root could be null?

This means that the scope was already destroyed by the time $$debounceViewValueCommit() was called.
This could be a result of many things, including Mobile Safari firing events out-of-order or app code manually calling $setViewValue() after the scope has been destroyed. It could also be a race condition happening due to deferring the $setViewValue() on certain events.
It is really hard to tell without a reproduction (or at least more info, such as what type of element was it, what was the trigger, what were the ngModelOptions etc).

The easy way out (assuming this is not a browser bug), would be checking if $$scope  has already been destroyed inside $$debounceViewValueChange(), but we probably need to clearly define (and implement) how debouncing is handled when the input is destroyed. (E.g. Is the pending value committed immediately? Is it discarded?)

So the app code itself was not calling $setViewValue in this case. The only calls on ngModel that were made were:
this.ngModel.$setDirty();
this.ngModel.$validate();

However from the stack trace that was captured I can't confirm whether or not it happened after those calls or before.
There's not much to the component that triggered it, it's basically a dropdown from which a user selected a value, and that value got pushed into an array which was passed upstream to the parent component via an event.
Could a call to $setDirty() or $validate() on the model have triggered it?
Otherwise I think it may have been an out-of-order events thing.

Could a call to $setDirty() or $validate() on the model have triggered it?

Not afaict.

it's basically a dropdown from which a user selected a value, and that value got pushed into an array which was passed upstream to the parent component via an event

So, I assume it is a <select> element. Can you confirm? Are you using ngOptions?

value got pushed into an array which was passed upstream to the parent component via an event

Could this value update cause the element to be destroyed?

So, I assume it is a  element. Can you confirm? Are you using ngOptions?

No, it's a custom dropdown with mainly simple elements, div, ul etc.
I am using ngOptions, in the following manner:
this.ngModel.$isEmpty = function() {

        //Needed here to prevent $validate from setting the model to undefined
        $ctrl.ngModel.$options = $ctrl.ngModel.$options.createChild({
          allowInvalid: true,
        });

        //Return check now
        return (!angular.isArray($ctrl.members) || $ctrl.members.length === 0);
      };

Could this value update cause the element to be destroyed?

No, it wouldn't.  Unless Safari mucked the events up like you said earlier...

If it is a custom dropdown, when do you call the $setViewValue() method?

The user would have to press a Next button first -- I assume they can't be that fast to press it before the selection was propagated

I previously assumed that the error was about this.$$scope.$root (not being an object), which can only happen if this.$$scope was destroyed.
But it is possible that the error is about this.$$scope not being an object. This should never happen, though. But we do define $$scope as a getter (Object.defineProperty(this, '$$scope', {value: $scope})). I wonder if it is a bug with getters/setters in Mobile Safari (maybe caused by some (de-)optimization, thus only triggered is specific circumstances). Or maybe just a one-of, weird bug.

I don't call $setViewValue, the component passes on the newly selected value through an event to the parent component. That component updates the array with the values and that is passed back to the child component through one way data binding 😮

I am using ngOptions, in the following manner:
...

I just realized you probably mean ngModelOptions (which is very different from ngOptions :smiley:)
(Also why are you creating a new $options instance whenever $isEmpty() is called? That seems redundant.)

I don't call $setViewValue

Interesting. Then I have no idea what is calling it (because ngModel doesn't do it on its own and we only do it for the built-in input/select/textarea directives). (ngOptions calls it too, but it only works on select elements and even then it checks that the scope has not been destroyed before calling it.)
That being said, (and although the stack trace you provided does not correspond to the "vanilla" angular.js v1.6.6 file), it seems that $setViewValue() is called inside an event handler. So, either someone (you? 3rd-party lib?) attached an event handler to your control and calls $setViewValue() or you are using a built-in directive (e.g. select) 😕

In any case, I am afraid there is not much we can do without more info (or a repro). I am going to close this, but feel free to continue the discussion below.

Also why are you creating a new $options instance whenever $isEmpty() is called? That seems redundant

Not sure -- that piece of code was refactored from pre 1.6 when the API for modifying the ngModelOptions changed. I even had a discussion about that (twice!) here on https://github.com/angular/angular.js/issues/12884, because $overrdeModelOptions didn't exist yet.
At the time of writing the original code, that was the only way I could make it to work. I remember it being a real pain. I must have just chucked it in place of the $$setOptions and carried on, happy it was working. Will probably have another look at it now with a clear head and refactor to $overrdeModelOptions while I'm at it.

the stack trace you provided does not correspond to the "vanilla" angular.js v1.6.6 file

It's being concatenated in a build process, I'm using the orginal sources, not the minified ones, to build a new minified vendor libraries file.

but it only works on select elements and even then it checks that the scope has not been destroyed before calling it

There's not a single <select> element in our entire codebase 💃
Perhaps it's a third party extension that somehow generates a selectbox for whatever reason on our page. I'll leave it on Sentry for a while and if we see more occurrences of it I'll check again! Thanks for looking into it. Don't you love puzzles like these 😆

Yep seems to work fine like:
      //Override model options
      this.ngModel.$overrideModelOptions({
        allowInvalid: true,
      });

      //Empty check
      this.ngModel.$isEmpty = function() {
        return (!angular.isArray($ctrl.members) || $ctrl.members.length === 0);
      };

Thanks for the heads up. Sometimes you get code blindness if you've been seeing something for too long 😆


"Failed to compile" - Can't resolve './CreateLeagueButton.jsx'

Hi. I'm brand new to the project, or brand new to wanting to explore the project; but I cloned it yesterday, and failed to get it up and running...
Steps I followed:

Cloned master@28f8e33 on 4/28/2018.
Added .env to project...
Per Readme, added environment vars to .env (and provisioned Google+ Api)
npm install
npm run dev

Asciicast of terminal output:

https://asciinema.org/a/178982
Notably, this error?

ERROR in ./client/src/components/create_league/CreateLeagueSelector.jsx
Module not found: Error: Can't resolve './CreateLeagueButton.jsx' in '/Users/emjayess/Sources/freeCodeCamp/league-for-good/client/src/components/create_league'
 @ ./client/src/components/create_league/CreateLeagueSelector.jsx 17:26-61
 @ ./client/src/components/create_league/CreateLeagueForm.jsx
 @ ./client/src/components/Content.jsx
 @ ./client/src/app.jsx
 @ ./client/index.js

Hey!
You'll get a few of these errors I think - Just go into your files and change all import statements to "CreateLeagueButton.js".  For example:  components/create_league/CreateLeagueSelector.jsx, should now import "CreateLeagueButton.js" instead of jsx
Just a small glitch that was recently pushed

If you haven't done so already, join us on Slack!  (Check the readme for the link)


make client.newCall typesafe

This was primary change
public interface Operation<T extends Operation.Data, V extends Operation.Variables>
Now when you do client.newCall(Operation) it is typesafe to that operation.
Additionally I removed the additional parameter on ApolloClient for the CallAdapter it will not working since we cannot do a return type of a parameterized generic ie R (because java).  My new plan to deal with the call adapter stuff is to make wrappers around the client.

just questions to IntegrationTest all cache logic has been moved to CacheTest, other then that lgtm except it has some compilation errors


Reconsider adding an address to the imported StockLocation

We're currently using Shopify's HQ as the default stock location address, but we'd probably better off not setting an address at all, making the behavior more simple and understandable.
@MinasMazar wdyt?

Hi @elia! This is no longer an issue since #39 has been merged 👍


[llvm] update to 13.0.0

Fixes #20524

Let me re-check.

I can already tell you that the debug build succeeds: I didn't finish the release build with it. flang-new is still a bit of pointless since it does not yet support code generation on any platform.

halide failed with the error like this:

Halide has been update to v13.0.0.

Let me re-check.

I can already tell you that the debug build succeeds: I didn't finish the release build with it. flang-new is still a bit of pointless since it does not yet support code generation on any platform.

@Neumann-A I was able to build 64-bit version of Flang for Windows (with MSVC), but 32-bit version doesn't compile. I've added an error message about this.

@alexreinking Could you review this PR?

This looks good to me, but note that #19797 is still outstanding.

@yurybura
Have you tested these features in this PR?

@yurybura
Have you tested these features in this PR?

I haven't tested all possible combination of features.

We should also remove these codes from ci.baseline.txt.
https://github.com/microsoft/vcpkg/blob/3730cbe99a0035a85158dec3c8cf0f783a9ca16b/scripts/ci.baseline.txt#L779-L781
For uwp, I noticed that there is already supports: !uwp in vcpkg.json. Could you please help confirm the status of arm? Does it support arm now?

Sorry, @yurybura - could you update the usage file in the Halide port as well?

We should also remove these codes from ci.baseline.txt.
https://github.com/microsoft/vcpkg/blob/3730cbe99a0035a85158dec3c8cf0f783a9ca16b/scripts/ci.baseline.txt#L779-L781
For uwp, I noticed that there is already supports: !uwp in vcpkg.json. Could you please help confirm the status of arm? Does it support arm now?

I've tested target ARM64 on Windows but it won't compile. I think this issue is related to cross-compilation which is not supported yet. This can be done in a separate PR.

Sorry, @yurybura - could you update the usage file in the Halide port as well?

Done.

I've tested target ARM64 on Windows but it won't compile. I think this issue is related to cross-compilation which is not supported yet. This can be done in a separate PR.

Thanks for your test and confirm. Now you can add supports: !(arm | uwp), remove these failure information from ci.baseline.txt. We prefer to use supports field to express this.

I've tested target ARM64 on Windows but it won't compile. I think this issue is related to cross-compilation which is not supported yet. This can be done in a separate PR.

Thanks for your test and confirm. Now you can add supports: !(arm | uwp), remove these failure information from ci.baseline.txt. We prefer to use supports field to express this.

This has been done already.

Sorry, I didn't notice the latest update for ci.baseline before.

I tried to test these features of llvm, but it failed with out of memory. So I'm not sure if the features can work normally on the current version. Do you have any suggestions to test these features? @yurybura

@NancyLi1013 In case of OOM issues, it often helps to reduce memory pressure by adjusting VCPKG_MAX_CONCURRENCY.

@dg0yt thanks for your suggestion. But seems VCPKG_MAX_CONCURRENCY is only used in Unix platform.
https://github.com/microsoft/vcpkg/blob/897ff9372f15c032f1e6cd1b97a59b57d66ee5b2/scripts/bootstrap.sh#L235
I encountered this problem on Windows. I will try to test some features at the same time.
I think it might be better to add  vcpkg-ci-llvm to test_ports like vcpkg-ci-ffmpeg and vcpkg-ci-opencv.

@yurybura What's your opinion of adding a test port vcpkg-ci-llvm to test the features on CI?

@NancyLi1013 Bootstrapping vpkgis entirely unrelated to building ports using vcpkg. During bootstrap, downloading an digitally signed vcpkg binary is preferred to building from source, for the major platforms.
So my point stands.

I tried to test these features of llvm, but it failed with out of memory. So I'm not sure if the features can work normally on the current version. Do you have any suggestions to test these features? @yurybura

If you have disk space issues I think you can try testing the configurations one by one: debug only and then release only.
If the linker.exe runs out of memory, vcpkg usually restarts the linker without concurrency (see vcpkg_execute_build_process CMake function).

@yurybura What's your opinion of adding a test port vcpkg-ci-llvm to test the features on CI?

It would be nice. Could I add this test by myself?

For what it's worth, I recently upgraded my workstation from 32GB of RAM to 64 GB specifically because LLVM debug builds on Windows wouldn't link without at least that much, no matter the parallelism...

For what it's worth, I recently upgraded my workstation from 32GB of RAM to 64 GB specifically because LLVM debug builds on Windows wouldn't link without at least that much, no matter the parallelism...

Even though my laptop has 16GB of RAM (+16GB fixed paging file on the SSD), I can compile LLVM+Halide+Mesa with default features.

For what it's worth, I recently upgraded my workstation from 32GB of RAM to 64 GB specifically because LLVM debug builds on Windows wouldn't link without at least that much, no matter the parallelism...

Even though my laptop has 16GB of RAM (+16GB fixed paging file on the SSD), I can compile LLVM+Halide+Mesa with default features.

Default features excludes target-all, right? It's just the backends for the host system.

For what it's worth, I recently upgraded my workstation from 32GB of RAM to 64 GB specifically because LLVM debug builds on Windows wouldn't link without at least that much, no matter the parallelism...

Even though my laptop has 16GB of RAM (+16GB fixed paging file on the SSD), I can compile LLVM+Halide+Mesa with default features.

Default features excludes target-all, right? It's just the backends for the host system.

Yes. Only host backend.

I tried to test these features of llvm, but it failed with out of memory. So I'm not sure if the features can work normally on the current version. Do you have any suggestions to test these features? @yurybura

If you have disk space issues I think you can try testing the configurations one by one: debug only and then release only. If the linker.exe runs out of memory, vcpkg usually restarts the linker without parallelism (see vcpkg_execute_build_process CMake function).

@yurybura What's your opinion of adding a test port vcpkg-ci-llvm to test the features on CI?

It would be nice. Could I add this test by myself?

Yes, you can add this test in this PR.

@PhoebeHui I've resolved merge conflicts with actual master.
I also cannot reproduce Halide build failure locally.

Dear @alexreinking, could you help to fix Halide build error?
[1695/1739] cmd.exe /C "cd /D D:\buildtrees\halide\x64-windows-rel\src\autoschedulers\li2018 && D:\buildtrees\halide\x64-windows-rel\bin\demo_gradient.generator.exe -n demo_gradient -d 0 -g demo -f demo -e c_header,object,registration -p D:/buildtrees/halide/x64-windows-rel/src/autoschedulers/li2018/autoschedule_li2018.dll -s Li2018 -o . target=x86-64-windows-no_runtime auto_schedule=true"
FAILED: src/autoschedulers/li2018/demo_gradient.h src/autoschedulers/li2018/demo_gradient.obj src/autoschedulers/li2018/demo_gradient.registration.cpp D:/buildtrees/halide/x64-windows-rel/src/autoschedulers/li2018/demo_gradient.h D:/buildtrees/halide/x64-windows-rel/src/autoschedulers/li2018/demo_gradient.obj D:/buildtrees/halide/x64-windows-rel/src/autoschedulers/li2018/demo_gradient.registration.cpp
cmd.exe /C "cd /D D:\buildtrees\halide\x64-windows-rel\src\autoschedulers\li2018 && D:\buildtrees\halide\x64-windows-rel\bin\demo_gradient.generator.exe -n demo_gradient -d 0 -g demo -f demo -e c_header,object,registration -p D:/buildtrees/halide/x64-windows-rel/src/autoschedulers/li2018/autoschedule_li2018.dll -s Li2018 -o . target=x86-64-windows-no_runtime auto_schedule=true"

Full logs: https://dev.azure.com/vcpkg/public/_build/results?buildId=63749&view=results

Dear @alexreinking, could you help to fix Halide build error?
[1695/1739] cmd.exe /C "cd /D D:\buildtrees\halide\x64-windows-rel\src\autoschedulers\li2018 && D:\buildtrees\halide\x64-windows-rel\bin\demo_gradient.generator.exe -n demo_gradient -d 0 -g demo -f demo -e c_header,object,registration -p D:/buildtrees/halide/x64-windows-rel/src/autoschedulers/li2018/autoschedule_li2018.dll -s Li2018 -o . target=x86-64-windows-no_runtime auto_schedule=true"
FAILED: src/autoschedulers/li2018/demo_gradient.h src/autoschedulers/li2018/demo_gradient.obj src/autoschedulers/li2018/demo_gradient.registration.cpp D:/buildtrees/halide/x64-windows-rel/src/autoschedulers/li2018/demo_gradient.h D:/buildtrees/halide/x64-windows-rel/src/autoschedulers/li2018/demo_gradient.obj D:/buildtrees/halide/x64-windows-rel/src/autoschedulers/li2018/demo_gradient.registration.cpp
cmd.exe /C "cd /D D:\buildtrees\halide\x64-windows-rel\src\autoschedulers\li2018 && D:\buildtrees\halide\x64-windows-rel\bin\demo_gradient.generator.exe -n demo_gradient -d 0 -g demo -f demo -e c_header,object,registration -p D:/buildtrees/halide/x64-windows-rel/src/autoschedulers/li2018/autoschedule_li2018.dll -s Li2018 -o . target=x86-64-windows-no_runtime auto_schedule=true"

Full logs: https://dev.azure.com/vcpkg/public/_build/results?buildId=63749&view=results

Sure... I'll try to repro locally first.

It looks like the mesa upstream was fixed this issue in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13273.

Also imagine that Halide developers decide to rely upon VCPKG to get LLVM libraries, then you have a chicken and egg problem.

@abique - Just to be clear, a chicken-egg problem will never, ever happen. Even if we were to use vcpkg to manage LLVM, we would need to maintain our own overlay port to continuously test against trunk LLVM. There's no other practical way to stay on top of API changes.

Imagine that Halide developers are on holidays for 6 months... 🌞 ⛰

All of us?

Also imagine that Halide developers decide to rely upon VCPKG to get LLVM libraries, then you have a chicken and egg problem.

@abique - Just to be clear, a chicken-egg problem will never, ever happen. Even if we were to use vcpkg to manage LLVM, we would need to maintain our own overlay port to continuously test against trunk LLVM. There's no other practical way to stay on top of API changes.

Imagine that Halide developers are on holidays for 6 months... sun_with_face mountain

All of us?

Well you get my point.
It must be a nightmare for Yuri. Something as simple as a version update is almost taking 3 months and is not yet finished.
I would never have the time and motivation to do this.
I'm also having an overlay in order to use llvm-13, and I consider this an unnecessary task.
Thing is that there are project which depends on different versions of llvm and the obvious solution to me is to let multiple versions of llvm co-exist. I don't says that older versions of llvm have to be maintained forever, but I think that it should not take more that a few days to get llvm-14 when it will be released.
To me the current situation puts to light that the current integration of llvm is broken by design.

@yurybura, @PhoebeHui - I also cannot reproduce any issue locally. Here's the log from my terminal:
D:\vcpkg>vcpkg install halide[target-all]:x64-windows
Computing installation plan...
The following packages will be built and installed:
    halide[core,jit,target-aarch64,target-all,target-amdgpu,target-arm,target-d3d12compute,target-hexagon,target-metal,target-mips,target-nvptx,target-opencl,target-powerpc,target-riscv,target-x86]:x64-windows -> 13.0.1
  * llvm[clang,compiler-rt,core,default-options,default-targets,disable-abi-breaking-checks,disable-assertions,disable-clang-static-analyzer,enable-bindings,enable-rtti,enable-terminfo,enable-threads,enable-zlib,lld,target-aarch64,target-amdgpu,target-arm,target-hexagon,target-mips,target-nvptx,target-powerpc,target-riscv,target-x86,tools]:x64-windows -> 13.0.0
  * vcpkg-cmake[core]:x64-windows -> 2021-09-13
  * vcpkg-cmake-config[core]:x64-windows -> 2021-11-01
  * zlib[core]:x64-windows -> 1.2.11#13
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x64-windows...
A suitable version of git was not found (required v2.32.0). Downloading portable git v2.32.0...
Downloading git...
  https://github.com/git-for-windows/git/releases/download/v2.32.0.windows.2/PortableGit-<IP_ADDRESS>-32-bit.7z.exe -> D:\vcpkg\downloads\PortableGit-<IP_ADDRESS>-32-bit.7z.exe
Extracting git...
A suitable version of 7zip was not found (required v19.0.0). Downloading portable 7zip v19.0.0...
Downloading 7zip...
  https://www.7-zip.org/a/7z1900-x64.msi -> D:\vcpkg\downloads\7z1900-x64.msi
Extracting 7zip...
A suitable version of powershell-core was not found (required v7.2.0). Downloading portable powershell-core v7.2.0...
Downloading powershell-core...
  https://github.com/PowerShell/PowerShell/releases/download/v7.2.0/PowerShell-7.2.0-win-x86.zip -> D:\vcpkg\downloads\PowerShell-7.2.0-win-x86.zip
Extracting powershell-core...
Restored 0 packages from C:\Users\Alex Reinking\AppData\Local\vcpkg\archives in 653.8 us. Use --debug to see more details.
Starting package 1/5: vcpkg-cmake:x64-windows
Building package vcpkg-cmake[core]:x64-windows...
-- Installing: D:/vcpkg/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg_cmake_configure.cmake
-- Installing: D:/vcpkg/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg_cmake_build.cmake
-- Installing: D:/vcpkg/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg_cmake_install.cmake
-- Installing: D:/vcpkg/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg_cmake_get_vars.cmake
-- Installing: D:/vcpkg/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/cmake_get_vars
-- Installing: D:/vcpkg/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/cmake_get_vars/CMakeLists.txt
-- Installing: D:/vcpkg/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg-port-config.cmake
-- Installing: D:/vcpkg/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\Alex Reinking\AppData\Local\vcpkg\archives\e7\e76eb71c7beb5dbdca6d2a6b185bb6f9fc7095853a84ab560bb1de9470ad27cb.zip
Installing package vcpkg-cmake[core]:x64-windows...
Elapsed time for package vcpkg-cmake:x64-windows: 100.2 ms
Starting package 2/5: vcpkg-cmake-config:x64-windows
Building package vcpkg-cmake-config[core]:x64-windows...
-- Installing: D:/vcpkg/packages/vcpkg-cmake-config_x64-windows/share/vcpkg-cmake-config/vcpkg_cmake_config_fixup.cmake
-- Installing: D:/vcpkg/packages/vcpkg-cmake-config_x64-windows/share/vcpkg-cmake-config/vcpkg-port-config.cmake
-- Installing: D:/vcpkg/packages/vcpkg-cmake-config_x64-windows/share/vcpkg-cmake-config/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\Alex Reinking\AppData\Local\vcpkg\archives\40\40362c8ee61340d6650f5b6a25a46fbae2c89731ab2b918db4dfd06ecdaf00bf.zip
Installing package vcpkg-cmake-config[core]:x64-windows...
Elapsed time for package vcpkg-cmake-config:x64-windows: 88.47 ms
Starting package 3/5: zlib:x64-windows
Building package zlib[core]:x64-windows...
-- Downloading https://www.zlib.net/zlib-1.2.11.tar.gz;https://downloads.sourceforge.net/project/libpng/zlib/1.2.11/zlib-1.2.11.tar.gz -> zlib1211.tar.gz...
-- Extracting source D:/vcpkg/downloads/zlib1211.tar.gz
-- Applying patch cmake_dont_build_more_than_needed.patch
-- Applying patch 0001-Prevent-invalid-inclusions-when-HAVE_-is-set-to-0.patch
-- Applying patch add_debug_postfix_on_mingw.patch
-- Applying patch 0002-android-build-mingw.patch
-- Using source at D:/vcpkg/buildtrees/zlib/src/1.2.11-e9a093319e.clean
-- Found external ninja('1.10.2').
-- Configuring x64-windows
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Installing: D:/vcpkg/packages/zlib_x64-windows/share/zlib/vcpkg-cmake-wrapper.cmake
-- Fixing pkgconfig file: D:/vcpkg/packages/zlib_x64-windows/lib/pkgconfig/zlib.pc
-- Downloading https://repo.msys2.org/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-2-any.pkg.tar.zst;https://www2.futureware.at/~nickoe/msys2-mirror/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-2-any.pkg.tar.zst;https://mirror.yandex.ru/mirrors/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-2-any.pkg.tar.zst;https://mirrors.tuna.tsinghua.edu.cn/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-2-any.pkg.tar.zst;https://mirrors.ustc.edu.cn/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-2-any.pkg.tar.zst;https://mirror.bit.edu.cn/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-2-any.pkg.tar.zst;https://mirror.selfnet.de/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-2-any.pkg.tar.zst;https://mirrors.sjtug.sjtu.edu.cn/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-2-any.pkg.tar.zst -> msys-mingw-w64-i686-pkg-config-0.29.2-2-any.pkg.tar.zst...
-- Downloading https://repo.msys2.org/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>06.c9a21571-1-any.pkg.tar.zst;https://www2.futureware.at/~nickoe/msys2-mirror/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>06.c9a21571-1-any.pkg.tar.zst;https://mirror.yandex.ru/mirrors/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>06.c9a21571-1-any.pkg.tar.zst;https://mirrors.tuna.tsinghua.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>06.c9a21571-1-any.pkg.tar.zst;https://mirrors.ustc.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>06.c9a21571-1-any.pkg.tar.zst;https://mirror.bit.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>06.c9a21571-1-any.pkg.tar.zst;https://mirror.selfnet.de/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>06.c9a21571-1-any.pkg.tar.zst;https://mirrors.sjtug.sjtu.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>06.c9a21571-1-any.pkg.tar.zst -> msys-mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>06.c9a21571-1-any.pkg.tar.zst...
-- Using msys root at D:/vcpkg/downloads/tools/msys2/aa5af7b2aa7e90e8
-- Fixing pkgconfig file: D:/vcpkg/packages/zlib_x64-windows/debug/lib/pkgconfig/zlib.pc
-- Installing: D:/vcpkg/packages/zlib_x64-windows/share/zlib/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\Alex Reinking\AppData\Local\vcpkg\archives\98\985ae57dce844bc6fae01f25fa917411d10359d7335528103ca5687a137c4bbf.zip
Installing package zlib[core]:x64-windows...
Elapsed time for package zlib:x64-windows: 7.396 s
Starting package 4/5: llvm:x64-windows
Building package llvm[clang,compiler-rt,core,default-options,default-targets,disable-abi-breaking-checks,disable-assertions,disable-clang-static-analyzer,enable-bindings,enable-rtti,enable-terminfo,enable-threads,enable-zlib,lld,target-aarch64,target-amdgpu,target-arm,target-hexagon,target-mips,target-nvptx,target-powerpc,target-riscv,target-x86,tools]:x64-windows...
-- Note: llvm only supports static library linkage. Building static library.
-- Downloading https://github.com/llvm/llvm-project/archive/llvmorg-13.0.0.tar.gz -> llvm-llvm-project-llvmorg-13.0.0.tar.gz...
-- Extracting source D:/vcpkg/downloads/llvm-llvm-project-llvmorg-13.0.0.tar.gz
-- Applying patch 0002-fix-install-paths.patch
-- Applying patch 0003-fix-openmp-debug.patch
-- Applying patch 0004-fix-dr-1734.patch
-- Applying patch 0005-fix-tools-path.patch
-- Applying patch 0007-fix-compiler-rt-install-path.patch
-- Applying patch 0009-fix-tools-install-path.patch
-- Applying patch 0010-fix-libffi.patch
-- Applying patch 0011-fix-libxml2.patch
-- Using source at D:/vcpkg/buildtrees/llvm/src/org-13.0.0-41c002f263.clean
-- Downloading https://www.python.org/ftp/python/3.10.0/python-3.10.0-embed-amd64.zip -> python-3.10.0-embed-amd64.zip...
-- Found external ninja('1.10.2').
-- Configuring x64-windows
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Installing: D:/vcpkg/packages/llvm_x64-windows/share/clang/copyright
-- Installing: D:/vcpkg/packages/llvm_x64-windows/share/clang/usage
-- Installing: D:/vcpkg/packages/llvm_x64-windows/share/lld/copyright
-- Installing: D:/vcpkg/packages/llvm_x64-windows/share/lld/usage
-- Installing: D:/vcpkg/packages/llvm_x64-windows/share/llvm/copyright
-- Installing: D:/vcpkg/packages/llvm_x64-windows/share/llvm/usage
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\Alex Reinking\AppData\Local\vcpkg\archives\bf\bfcc12eb8042b419a40f791851b9f9792541b04c93cbe5baf2801be9a01dd0ec.zip
Installing package llvm[clang,compiler-rt,core,default-options,default-targets,disable-abi-breaking-checks,disable-assertions,disable-clang-static-analyzer,enable-bindings,enable-rtti,enable-terminfo,enable-threads,enable-zlib,lld,target-aarch64,target-amdgpu,target-arm,target-hexagon,target-mips,target-nvptx,target-powerpc,target-riscv,target-x86,tools]:x64-windows...
Elapsed time for package llvm:x64-windows: 1.139 h
Starting package 5/5: halide:x64-windows
Building package halide[core,jit,target-aarch64,target-all,target-amdgpu,target-arm,target-d3d12compute,target-hexagon,target-metal,target-mips,target-nvptx,target-opencl,target-powerpc,target-riscv,target-x86]:x64-windows...
-- Downloading https://github.com/halide/Halide/archive/fb39d7e3149c0ee1e848bb9957be2ea18765c35d.tar.gz -> halide-Halide-fb39d7e3149c0ee1e848bb9957be2ea18765c35d.tar.gz...
-- Extracting source D:/vcpkg/downloads/halide-Halide-fb39d7e3149c0ee1e848bb9957be2ea18765c35d.tar.gz
-- Using source at D:/vcpkg/buildtrees/halide/src/a18765c35d-2675946ec3.clean
-- Found external ninja('1.10.2').
-- Configuring x64-windows
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\Alex Reinking\AppData\Local\vcpkg\archives\8e\8e4c32e908915d9186448733125be2f2b30d94f05c095fb24a5c9865d7a9e198.zip
Installing package halide[core,jit,target-aarch64,target-all,target-amdgpu,target-arm,target-d3d12compute,target-hexagon,target-metal,target-mips,target-nvptx,target-opencl,target-powerpc,target-riscv,target-x86]:x64-windows...
Elapsed time for package halide:x64-windows: 17.87 min

Total elapsed time: 1.443 h

The package halide provides CMake targets:

    set(CMAKE_CXX_STANDARD 17)
    set(CMAKE_CXX_STANDARD_REQUIRED YES)
    set(CMAKE_CXX_EXTENSIONS NO)

    find_package(Halide REQUIRED)

    # JIT mode:
    add_executable(my_halide_app main.cpp)
    target_link_libraries(my_halide_app PRIVATE Halide::Halide)

    # AOT mode:
    add_executable(my_generators my_generators.cpp)
    target_link_libraries(my_generators PRIVATE Halide::Generator)
    add_halide_library(my_first_generator FROM my_generators)
    add_halide_library(my_second_generator FROM my_generators
        PARAMS parallel=false scale=3.0 rotation=ccw output.type=uint16)
    add_halide_library(my_second_generator_2 FROM my_generators
        GENERATOR my_second_generator
        PARAMS scale=9.0 rotation=ccw output.type=float32)
    add_halide_library(my_second_generator_3 FROM my_generators
        GENERATOR my_second_generator
        PARAMS parallel=false output.type=float64)

For more information see:
    https://github.com/halide/Halide/blob/v13.0.0/README_cmake.md

@yurybura @alexreinkin, I could repro this issue on local machine finally, it only failed with release configuration, and this issue can't repro when test all features togather. could you please take a look again?
Repro commands:
./vcpkg install llvm[clang,compiler-rt,core,default-options,default-targets,disable-abi-breaking-checks,disable-assertions,disable-clang-static-analyzer,enable-bindings,enable-eh,enable-rtti,enable-terminfo,enable-threads,enable-zlib,flang,libclc,lld,lldb,mlir,polly,target-aarch64,target-all,target-amdgpu,target-arm,target-avr,target-bpf,target-hexagon,target-lanai,target-mips,target-msp430,target-nvptx,target-powerpc,target-riscv,target-sparc,target-systemz,target-webassembly,target-x86,target-xcore,tools,utils]:x64-windows
./vcpkg install halide[core,jit,target-x86]:x64-windows

@PhoebeHui - I'll try this, thanks

Well you get my point. It must be a nightmare for Yuri. Something as simple as a version update is almost taking 3 months and is not yet finished. I would never have the time and motivation to do this.

Yeah, that much is clear. Homebrew and even Debian Sid managed to update Halide / LLVM much more rapidly. On the other hand, vcpkg is much more thorough in its CI testing. In any case, three months is excessive and I would encourage the vcpkg devs to seriously consider what could be done to speed up the process in the future.

Thing is that there are project which depends on different versions of llvm and the obvious solution to me is to let multiple versions of llvm co-exist. I don't says that older versions of llvm have to be maintained forever, but I think that it should not take more that a few days to get llvm-14 when it will be released. To me the current situation puts to light that the current integration of llvm is broken by design.

Yeah, LLVM's API is quite unstable and breaking changes are expected between every major release. Yet retaining old versions enables dependees to simply never upgrade, which is worse.

I'm also having an overlay in order to use llvm-13, and I consider this an unnecessary task. [...] Unless, llvm-13 is not yet on master because somehow its packaging script isn't working. But I've the impression that llvm itself is fine and the problem comes from the packages that depends upon llvm and were working well with llvm-12.

For a released version, it is annoying to have to maintain an overlay port. However, I don't see any other way of getting nightly builds via vcpkg. Even then, it's not exactly trivial to maintain the overlay (the SHA is constantly changing, for example). So in practice, Halide's CI uses vcpkg on Windows for all dependencies except LLVM because it's just incompatible with our development requirements. If that changes in the future, we'd love to use it everywhere.

Many thanks to all to help. Anyway I will do my best to complete this PR.
Sorry for delay.

Yeah, LLVM's API is quite unstable and breaking changes are expected between every major release. Yet retaining old versions enables dependees to simply never upgrade, which is worse. I'm not convinced that keeping a multitude of llvm-$MAJOR ports around is a good idea.

2 versions are probably enough. Maybe 3 if you want a month of notice before dropping packages that depends on llvm-(n-2) and did not update.

Yeah, LLVM's API is quite unstable and breaking changes are expected between every major release. Yet retaining old versions enables dependees to simply never upgrade, which is worse. I'm not convinced that keeping a multitude of llvm-$MAJOR ports around is a good idea.

2 versions are probably enough. Maybe 3 if you want a month of notice before dropping packages that depends on llvm-(n-2) and did not update.

I think it's better to have the possibility implemented in VCPKG to update a LLVM version without switching other libraries to the new LLVM version. And probable to have an ability to install different versions of the same library.

@PhoebeHui @yurybura -- I am able to repro locally.
When I manually run the failing commands, I get an error related to not finding zlib1.dll. The command succeeds if I add D:\vcpkg\installed\x64-windows\bin to the PATH. I thought that zlib1.dll would be copied next to Halide.dll (due to vcpkg overriding add_executable), but this does not happen in either build. I am unsure why the debug build does work.

No, it does seem to be failing even when it finds zlib1.dll, so that's not the problem... will investigate with a debugger...

It's crashing inside of LLVM's code which is statically linked into Halide. Here's the backtrace:
 	vcruntime140.dll!memcpy() Line 440	Unknown
 	[Inline Frame] Halide.dll!std::_Copy_memmove(llvm::MachineInstr * *) Line 4382	C++
 	[Inline Frame] Halide.dll!std::_Move_unchecked(llvm::MachineInstr * *) Line 4656	C++
 	[Inline Frame] Halide.dll!std::move(llvm::MachineInstr * * _First, llvm::MachineInstr * *) Line 4698	C++
>	[Inline Frame] Halide.dll!llvm::SmallVectorImpl<llvm::MachineInstr *>::erase(llvm::MachineInstr * const *) Line 713	C++
 	[Inline Frame] Halide.dll!llvm::SetVector<llvm::MachineInstr *,llvm::SmallVector<llvm::MachineInstr *,8>,llvm::SmallDenseSet<llvm::MachineInstr *,8,llvm::DenseMapInfo<llvm::MachineInstr *>>>::remove(llvm::MachineInstr * const &) Line 161	C++
 	Halide.dll!`anonymous namespace'::MachineCopyPropagation::ReadRegister(llvm::MCRegister Reg, llvm::MachineInstr & Reader, `anonymous-namespace'::MachineCopyPropagation::DebugType DT) Line 322	C++
 	Halide.dll!`anonymous namespace'::MachineCopyPropagation::ForwardCopyPropagateBlock(llvm::MachineBasicBlock & MBB) Line 684	C++
 	Halide.dll!`anonymous namespace'::MachineCopyPropagation::runOnMachineFunction(llvm::MachineFunction & MF) Line 918	C++
 	Halide.dll!llvm::MachineFunctionPass::runOnFunction(llvm::Function & F) Line 72	C++
 	Halide.dll!llvm::FPPassManager::runOnFunction(llvm::Function & F) Line 1439	C++
 	Halide.dll!llvm::FPPassManager::runOnModule(llvm::Module & M) Line 1484	C++
 	Halide.dll!`anonymous namespace'::MPPassManager::runOnModule(llvm::Module & M) Line 1554	C++
 	[Inline Frame] Halide.dll!llvm::legacy::PassManagerImpl::run(llvm::Module &) Line 542	C++
 	Halide.dll!llvm::legacy::PassManager::run(llvm::Module & M) Line 1681	C++
 	Halide.dll!Halide::emit_file(const llvm::Module & module_in, llvm::raw_pwrite_stream & out, llvm::CodeGenFileType file_type) Line 387	C++
 	Halide.dll!Halide::Module::compile(const std::map<enum Halide::Output,std::string,std::less<enum Halide::Output>,std::allocator<std::pair<enum Halide::Output const ,std::string>>> & output_files) Line 594	C++
 	Halide.dll!Halide::compile_multitarget(const std::string & fn_name, const std::map<enum Halide::Output,std::string,std::less<enum Halide::Output>,std::allocator<std::pair<enum Halide::Output const ,std::string>>> & output_files, const std::vector<Halide::Target,std::allocator<Halide::Target>> & targets, const std::vector<std::string,std::allocator<std::string>> & suffixes, const std::function<Halide::Module __cdecl(std::string const &,Halide::Target const &)> & module_factory, const std::function<std::unique_ptr<Halide::Internal::CompilerLogger,std::default_delete<Halide::Internal::CompilerLogger>> __cdecl(std::string const &,Halide::Target const &)> & compiler_logger_factory) Line 802	C++
 	Halide.dll!Halide::Internal::generate_filter_main_inner(int argc, char * * argv, std::basic_ostream<char,std::char_traits<char>> & error_output) Line 1077	C++
 	Halide.dll!Halide::Internal::generate_filter_main(int argc, char * * argv, std::basic_ostream<char,std::char_traits<char>> & cerr) Line 1087	C++
 	[Inline Frame] demo_gradient.generator.exe!invoke_main() Line 78	C++
 	demo_gradient.generator.exe!__scrt_common_main_seh() Line 288	C++
 	kernel32.dll!BaseThreadInitThunk()	Unknown
 	ntdll.dll!RtlUserThreadStart()	Unknown

Well you get my point. It must be a nightmare for Yuri. Something as simple as a version update is almost taking 3 months and is not yet finished. I would never have the time and motivation to do this.

Generally, we prefer to ensure stability of the catalog over speed of update of any single thing in the catalog, which is likely to make things take longer than they would otherwise, but ensures a better experience for folks that consume the actual bits. There are exceptions that can be made (if a dependency is unresponsive or similar) but it seems Halide folks are responsive here.

@yurybura @alexreinking, I created a vs feedback to compiler team and confirm if it's a backed issue. See https://developercommunity.visualstudio.com/t/Exception-thrown-at-0x00007FFB356F162E-/1610030?from=email&space=62&scope=follow

@yurybura @alexreinking, I created a vs feedback to compiler team and confirm if it's a backed issue. See https://developercommunity.visualstudio.com/t/Exception-thrown-at-0x00007FFB356F162E-/1610030?from=email&space=62&scope=follow

I don't think this is an MSVC compiler issue. Halide uses the deprecated llvm::legacy::PassManager. I think Halide team need a time to investigate this issue internally and maybe re-implement this code.
@PhoebeHui @BillyONeal How can we skip the Halide issue and finally merge LLVM update?

Halide uses the deprecated llvm::legacy::PassManager. I think Halide team need a time to investigate this issue internally and maybe re-implement this code.

That's no reason for LLVM to crash on only Windows x64-release and not on other platforms. The last time we hit a bug like this was also due to MSVC mis-compiling SmallVector.

Halide uses the deprecated llvm::legacy::PassManager. I think Halide team need a time to investigate this issue internally and maybe re-implement this code.

I don't think "deprecated" means "expected to crash". Is there evidence that the crash is actually related to this?

Halide uses the deprecated llvm::legacy::PassManager

FYI: This is true, but for a good reason: Halide uses it for codegen purposes that aren't fully available under the new pass manager yet. In LLVM13 , the 'legacy' PassManager is deprecated only for use as an optimization pipeline [1], but the deprecation doesn't apply to codegen [2]. There's not really much we can do until LLVM completes that work.
[1] https://releases.llvm.org/13.0.0/docs/ReleaseNotes.html#changes-to-the-llvm-ir
[2] https://groups.google.com/g/llvm-dev/c/HoS07gXx0p8

Halide uses the deprecated llvm::legacy::PassManager

FYI: This is true, but for a good reason: Halide uses it for codegen purposes that aren't fully available under the new pass manager yet. In LLVM13 , the 'legacy' PassManager is deprecated only for use as an optimization pipeline [1], but the deprecation doesn't apply to codegen [2]. There's not really much we can do until LLVM completes that work.
[1] https://releases.llvm.org/13.0.0/docs/ReleaseNotes.html#changes-to-the-llvm-ir [2] https://groups.google.com/g/llvm-dev/c/HoS07gXx0p8

Thanks for the answer and clarification. Anyway I think you need a time to investigate this issue. Could you give an advise how to reduce LLVM update time?

Anyway I think you need a time to investigate this issue.

I'm not sure I understand.

Could you give an advise how to reduce LLVM update time?

I definitely don't understand.

Could you give an advise how to reduce LLVM update time?

I definitely don't understand.

I think that was directed at the vcpkg maintainers.

Anyway I think you need a time to investigate this issue.

I'm not sure I understand.

Could you give an advise how to reduce LLVM update time?

I definitely don't understand.

Ok. Let me try to explain. It is not possible to merge LLVM update in the master due to Halide build failure on CI. Could you help to investigate the build failure or give an advice to workaround this issue?

Could you help to investigate the build failure or give an advice to workaround this issue?

I don't really have much in the way of advice to give -- Halide has been testing LLVM 13.0 against Halide for many months now (with MSVC 16.9.4) and hasn't seen any issues of this sort. As mentioned before, there have been known issues in the past with some versions of MSVC miscompiling SmallVector -- what specific version(s) of MSVC are you using for building and testing?

Could you help to investigate the build failure or give an advice to workaround this issue?

You should determine the minimal set of build options for LLVM to trigger this issue. The dependent builds of LLVM for halide:x64-windows and halide[target-all]:x64-windows do not trigger this bug.

16.9.4

@steven-johnson @alexreinking Thanks very much for the attention to the problem.
MSVC version is available in the CMake generation log:
[1/2] "D:/downloads/tools/cmake-3.21.1-windows/cmake-3.21.1-windows-i386/bin/cmake.exe" -S "D:/buildtrees/halide/src/v13.0.2-2675946ec3.clean" -B .. "-DTARGET_AARCH64=OFF" "-DTARGET_AMDGPU=OFF" "-DTARGET_ARM=OFF" "-DTARGET_D3D12COMPUTE=OFF" "-DTARGET_HEXAGON=OFF" "-DTARGET_METAL=OFF" "-DTARGET_MIPS=OFF" "-DTARGET_NVPTX=OFF" "-DTARGET_OPENCL=OFF" "-DTARGET_POWERPC=OFF" "-DTARGET_RISCV=OFF" "-DTARGET_X86=ON" "-DWITH_DOCS=NO" "-DWITH_PYTHON_BINDINGS=NO" "-DWITH_TESTS=NO" "-DWITH_TUTORIALS=NO" "-DWITH_UTILS=NO" "-DCMAKE_INSTALL_LIBDIR=bin" "-DCMAKE_INSTALL_DATADIR=share/halide" "-DHalide_INSTALL_CMAKEDIR=share/halide" "-DHalide_INSTALL_HELPERSDIR=share/HalideHelpers" "-DHalide_INSTALL_PLUGINDIR=bin" "-DCMAKE_MAKE_PROGRAM=D:/downloads/tools/ninja/1.10.2-windows/ninja.exe" "-DBUILD_SHARED_LIBS=ON" "-DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=C:/a/1/s/scripts/toolchains/windows.cmake" "-DVCPKG_TARGET_TRIPLET=x64-windows" "-DVCPKG_SET_CHARSET_FLAG=ON" "-DVCPKG_PLATFORM_TOOLSET=v142" "-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON" "-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON" "-DCMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY=ON" "-DCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP=TRUE" "-DCMAKE_VERBOSE_MAKEFILE=ON" "-DVCPKG_APPLOCAL_DEPS=OFF" "-DCMAKE_TOOLCHAIN_FILE=C:/a/1/s/scripts/buildsystems/vcpkg.cmake" "-DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=ON" "-DVCPKG_CXX_FLAGS=" "-DVCPKG_CXX_FLAGS_RELEASE=" "-DVCPKG_CXX_FLAGS_DEBUG=" "-DVCPKG_C_FLAGS=" "-DVCPKG_C_FLAGS_RELEASE=" "-DVCPKG_C_FLAGS_DEBUG=" "-DVCPKG_CRT_LINKAGE=dynamic" "-DVCPKG_LINKER_FLAGS=" "-DVCPKG_LINKER_FLAGS_RELEASE=" "-DVCPKG_LINKER_FLAGS_DEBUG=" "-DVCPKG_TARGET_ARCHITECTURE=x64" "-DCMAKE_INSTALL_LIBDIR:STRING=lib" "-DCMAKE_INSTALL_BINDIR:STRING=bin" "-D_VCPKG_ROOT_DIR=C:/a/1/s" "-D_VCPKG_INSTALLED_DIR=D:/installed" "-DVCPKG_MANIFEST_INSTALL=OFF" "-DCMAKE_DISABLE_SOURCE_CHANGES=ON" -G "Ninja" "-DCMAKE_BUILD_TYPE=Release" "-DCMAKE_INSTALL_PREFIX=D:/packages/halide_x64-windows"
-- The C compiler identification is MSVC 19.29.30137.0
-- The CXX compiler identification is MSVC 19.29.30137.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Halide 'host' platform triple:   x86-64-windows
-- Halide 'cmake' platform triple:  x86-64-windows
-- Halide default AOT target:       host
-- Windows: setting CMAKE_OBJECT_PATH_MAX to 260
-- Looking for pthread.h
-- Looking for pthread.h - not found
-- Found Threads: TRUE
-- Found OpenGL: opengl32
-- Found OpenMP_C: -openmp (found version "2.0")
-- Found OpenMP_CXX: -openmp (found version "2.0")
-- Found OpenMP: TRUE (found version "2.0")
-- Found ZLIB: optimized;D:/installed/x64-windows/lib/zlib.lib;debug;D:/installed/x64-windows/debug/lib/zlibd.lib (found version "1.2.11")
-- Found LLVM 13.0.0
-- Using LLVMConfig.cmake in: D:/installed/x64-windows/share/llvm
-- Using ClangConfig.cmake in: D:/installed/x64-windows/share/clang
-- Disabling AArch64 backend
-- Disabling AMDGPU backend
-- Disabling ARM backend
-- Disabling Hexagon backend
-- Disabling Mips backend
-- Disabling NVPTX backend
-- Disabling PowerPC backend
-- Disabling RISCV backend
-- Enabling WebAssembly backend
-- Enabling X86 backend
-- Using LLDConfig.cmake in: D:/installed/x64-windows/share/lld
-- Compiling Halide WITH RTTI.
-- Compiling Halide WITH exceptions.
-- Found JPEG: optimized;D:/installed/x64-windows/lib/jpeg.lib;debug;D:/installed/x64-windows/debug/lib/jpeg.lib (found version "62")
-- Found PNG: optimized;D:/installed/x64-windows/lib/libpng16.lib;debug;D:/installed/x64-windows/debug/lib/libpng16d.lib (found version "1.6.37")
-- WITH_WABT is not yet supported on Windows
-- WITH_WASM_SHELL is not yet supported on Windows
-- Building autoschedulers enabled
-- Building tests disabled
-- Building Python bindings disabled
-- Building tutorials disabled
-- Building docs disabled
-- Building utils disabled
-- Configuring done
-- Generating done

I reproed this issue with VS2019 16.11.7, I will double confirm if this issue could be reproed with VS 2022 17.1 Preview1.1.

Double confirmed: this issue can't repro in VS2022 v17.0.3, it should be fixed, however it still could be reproed with VS 2022 17.1 Preview1.1. So I think some fix may not be merged to 17.1 preview 1.1, I will confirm with compiler team.

I am of the opinion that we should take #3; it is important that we can get up to date LLVM libraries in the catalog. We can then fix it permanently later.

Edit: Verified, when I added extra feature 'enable-abi-breaking-checks', the issue has gone.

@PhoebeHui - does that mean this feature should be added as a dependency to the Halide port on Windows?

@alexreinking, I'm not sure, compiler team is still investigating this issue, it's fine to add it as dependency for me, we can remove it in future.
llvm:x64-osx:
[8661/8878] cd /Users/vagrant/Data/buildtrees/llvm/x64-osx-dbg/tools/flang/tools/f18 && /Users/vagrant/Data/downloads/tools/cmake-3.21.1-osx/cmake-3.21.1-macos-universal/CMake.app/Contents/bin/cmake -E make_directory /Users/vagrant/Data/buildtrees/llvm/x64-osx-dbg/include/flang && /Users/vagrant/Data/buildtrees/llvm/x64-osx-dbg/bin/f18 -fsyntax-only -module-dir /Users/vagrant/Data/buildtrees/llvm/x64-osx-dbg/include/flang /Users/vagrant/Data/buildtrees/llvm/src/org-13.0.0-41c002f263.clean/flang/module/__fortran_type_info.f90
FAILED: include/flang/__fortran_type_info.mod /Users/vagrant/Data/buildtrees/llvm/x64-osx-dbg/include/flang/__fortran_type_info.mod
cd /Users/vagrant/Data/buildtrees/llvm/x64-osx-dbg/tools/flang/tools/f18 && /Users/vagrant/Data/downloads/tools/cmake-3.21.1-osx/cmake-3.21.1-macos-universal/CMake.app/Contents/bin/cmake -E make_directory /Users/vagrant/Data/buildtrees/llvm/x64-osx-dbg/include/flang && /Users/vagrant/Data/buildtrees/llvm/x64-osx-dbg/bin/f18 -fsyntax-only -module-dir /Users/vagrant/Data/buildtrees/llvm/x64-osx-dbg/include/flang /Users/vagrant/Data/buildtrees/llvm/src/org-13.0.0-41c002f263.clean/flang/module/__fortran_type_info.f90
/bin/sh: line 1: 84087 Killed: 9

I am of the opinion that we should take #3; it is important that we can get up to date LLVM libraries in the catalog. We can then fix it permanently later. @BillyONeal do you agree?

Sure, thanks for running this to ground. And thanks to @yurybura @PhoebeHui @alexreinking @steven-johnson and probably more GitHub won't show me for helping :)

building of llvm fails now here: https://github.com/microsoft/vcpkg/pull/21790
REGRESSION: llvm:x64-osx. If expected, add llvm:x64-osx=fail to .\scripts\ci.baseline.txt.
Undefined symbols for architecture x86_64: "__nc_panelhook_sp"

Is this issue related to this PR?

@daschuer, thanks, we will take a look.

I believe https://github.com/microsoft/vcpkg/pull/22230 fixed it?

I believe #22230 fixed it?

Yes, it fixed the failures.


Automatic object mapper

Perhaps you considered this as a low-level (in terms of architecture, not class) and didn't need it necessary but the Object mapping option is powerful indeed, however, writing object mapper for nested and big objects could be time-consuming and requires a lot of boilerplate code which is against the whole idea of this tool which is consuming less time.

Object mapper is out of scope for this. They are useful. Boon (another parser that I wrote [a lot of] which was forked into Groovy) does object mapping. I don't plan on adding an object mapper at this time.


add GeoJSON Feature and FeatureCollection encoding

Geo.JSON.encode!/1 behaves exactly the same
Geo.JSON.encode!/2 accepts feature: true to use new behavior

see #119
agree with @achedeuzot, thanks for the great lib. here is an attempt to address encoding to GeoJSON Feature/FeatureCollection types without breaking existing structure.

Awesome! Thanks I think this is a good way to handle the problem without making a breaking change

Thanks, @bryanjos ! This will be helpful in the next release. I also have a bounds() function for adding bbox: [...] to Features. Would that be helpful? If so, would it fit best here in this lib, or maybe in topo?


.custom properties cannot be null.

When using the .custom properties on Deliverable, Repository, and Team, the .custom should never be set to null. If you are using the property, you should add it explicitly (e.g. repo.custom.foo = bar), and deleted explicitly (e.g., delete repo.custom.foo).
You should not just assign something to .custom (e.g., repo.custom = baz) as this will overwrite any other additions that have been made to the custom property.
It is best practice to prefix any keys with something that is unlikely to conflict with others (e.g., repo.custom.assignmentRubric or repo.custom.sdmmStatus) rather than names that are more generic (e.g., repo.custom.obj or repo.custom.value).

@jopika this is why the 340 tests are all failing right now: team.custom is set to null in many places.

Most recent pushes (02c60530cde3d96cc07ad9ae1fac3040d01725c9) have addressed this issue. Frontend and backend of assignment related methods should be updated in accordance to this change.


new project: ev3-mapping

Hello!
Some friends and I are working in a project with the goal of doing some mapping with the EV3. The project is called ev3-mapping and we use, of course, ev3dev and this Python library.
It's our first project with GitHub, Python, documentation and everything, so any advice or help is very welcomed!!

This weekend we'll be coding some classes that could be useful for everyone (or maybe they have already been created), like a class for any Differential Robot and other for a EXPLOR3R robot.

Hi, take a look this video from a student in a Imperial course.
https://www.youtube.com/watch?v=5dL6v2m0zH8

That's brilliant! Pfff, they have done a lot of cool stuff. This project on localization it's what I'd like to achieve in a near future: https://www.youtube.com/watch?v=AsIN9RMKYPE
That's why I'm starting with the ev3-mapping project.
Anyway, I just took a look at your work... amazing!! I am currently working on a Occupancy grid map, like the one you describe on the README of your livingrobots repository.
And I have encountered two dilemmas so far. They are explained here. Can you take a look, please? :grin:

Looks cool :)


Improve cargo commands

Makes the cargo commands produce output in an HTML window, so that error messages are clickable. It also adds cargo check, cargo fmt and cargo clippy commands.
To support so many new commands the bundle now uses the single shortcut key approach.
Also has changes under the hood to support using the bundle for Fuchsia development and a refinement of the symbol list.

So @carols10cents @infininight any notion on how to get this more visibility?


Add async version of the Storage trait and RmwNorFlashStorage implementation

This matches the sync version and make the async version as useful as the sync version.

@aurelj Could you add an entry to the changelog about this?

Sure, there it is.


Deduplicate HuggingFace test code

Create hf_test_utils.py and move HFGPT2Tracer, HFBertTracer and other HF-related code there

try to use plain HFTracer


How Do I Modify the Outpaint Mask? All Tutorials / Videos Outdated

I'd like to add more to my outpaint mask to replace a portion of the original image at the same time. I do not see "init outpaint mask" or a way to view the current mask it is using in a way that I can edit it. All the tutorials I can find are using buttons that don't exist (eg init inpaint mask, init outpaint mask, set init image, set mask). Is there an updated tutorial that includes outpainting and modifying the mask before generation? Or can someone just tell me?

It should be noted that if you hover over the mask in the current version, two little pencil icons show up. One is labeled "view original mask" and other "view modified mask". Clicking either of them does appears to do absolutely nothing.


Rename zh-cn.json to zh_cn.json

Naming errors prevent language files from loading

Manually renamed them in every branch


Fix sidebar in docker-registry

Description
Changes proposed in this pull request:

...
...
...

Related issue(s)

/cla


make opportunities page responsive

Assign this task to me

@lokeshvasnik are you working on this issue

@lokeshvasnik are you still working on this issue ?

@lokeshvasnik are you still working on this issue ?

No

Hello @hparashar27 can you assign this issue to me?


Disable zero-copy string compute for array_union

Although ArrayUnionFunctionString sets reuse_strings_from_arg = 0, it only allows reusing the string buffer from the first argument but not the second. Since zero-copy will not be used, no point to create a separate function for it.

The CircleCI failure is due to the removal of varchar singature, wondering how to fix it?


feat: Implementations of string similarity metrics - Rust source code

Includes Hamming, Levenshtein, OSA, Damerau-Levenshtein, Jaro, Jaro-Winkler,
and SÃ¸rensen-Dice.
.
This package contains the source for the Rust strsim crate, packaged by
debcargo for use with cargo and dh-cargo.
Log: Implementations of string similarity metrics -
Rust source code
Issue: deepin-community/sig-deepin-sysdev-team#56
Task: https://github.com/orgs/deepin-community/projects/7
Influence: Implementations of string similarity metrics - Rust source code

/lgtm


Add second batch

@shntnu - I remember you mentioning that we have another batch of Cell Painting data for this project. Can you point me to where this data lives?
We should work towards getting this data on here and processed. @sMyn42 is looking for a good dataset to test different batch effect correction tools (e.g. Harmony) to extend his Summer Research project. Having the second batch on here will help!

Duplicate of #57

Duplicate of #57


Allow xPath functions in footer rows and refactor

Allows expressions such as  in the footer rows of tables. Plus Refactored  the evaluation of xpath to a new method

maybe my requirements addressed in pull-request 36 (see https://github.com/chrlutz/Open-Xml-PowerTools/commit/23fe566ad293e24dd6ca621bf1ce5cf4a3c076ef) are also solved here. It would be fine if you could test your solution again the test case described in https://github.com/chrlutz/Open-Xml-PowerTools/commit/c13d12256a15af42e93c6600261d9dbfc7c3e31d

@chrlutz It looks to me as though my changes will address your issue.  I will try out the tests next time I'n in the code. Although do feel free to grab my branch and run those tests yourself :-)

@EricWhiteDev Are you back from your travels yet :-) can this be pulled in?

@BrettBailey Yes, I'm back.  I can address those next week.  Looking forward to doing the merge!

@EricWhiteDev Looks like you've had a great big merge jamboree. I'm looking forward to using all the new features.  @chrlutz 's multiline stuff will be very useful


blank pages oover and over

Describe the bug
Not able to create sign-in authentication
Link to the Bolt URL that caused the error
https://bolt.new/~/sb1-jsit27
Steps to reproduce
not working
Expected behavior
create sign-in authentication
Screen Recording / Screenshot
No response
Platform
Browser name = Chrome
Full version = <IP_ADDRESS>
Major version = 130
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36
performance.memory = {
  "totalJSHeapSize": 148207956,
  "usedJSHeapSize": 140157156,
  "jsHeapSizeLimit":<PHONE_NUMBER>
}
Username = tdadelaja
Chat ID = f3e1e3fe0218

Additional context
No response

Hi @tdadelaja,
Some advice on efficient use of tokens when prompting Bolt can be found here: #678. Effective prompt engineering is an area of active development. More information can be found here.


Include robust check for extracting column names for fingerprints

Fix for #446 by introducing a robust check for different potential formats for feature names.
Hotfix for #446 by introducing a limit for the version of scikit-fingerprints.
Note that this is only meant as a temporary solution and to inform you and might not even be merged. Depending on how much effort it is to generalize the existing code, we might abandon this. I already informed @Hrovatin regarding this as I guess that it makes sense if she investigates how severe this issue is as she implemented the corresponding feature.

Note: I executed the tests while pinning the version of scikit-fingerprints explicitly to 1.12 and this worked.

@AdrianSosic anything open or can you approve here? Would make sense to have this merged net as e.g. #442 's test currently always fail due to this.


1.2.1 does not work at all

I have tried saving FTP/SFTP settings and all Synapse says is "Authentication Error. Please check setting your input" - All the information I am using is correct.

Hi there - the plugin was working fine prior to 1.2.1 - I authenticate successfully but I don't left hand-side Synapse file browser does not load, so I can't do anything.  That's after I have deleted my servers because I could no longer connect to them.

can you confirm developer tools?
Debug > Show Develper Tools
then
Console (tab) > All

Here's what I see in the dev logs:
[NodeDomain] Error loading domain "synapse": Unable to load one of the
modules:
C:/Users/Yannick/AppData/Roaming/Brackets/extensions/user/brackets-synapse/node/SynapseDomain,
reason: Cannot find module 'jsftp'/utils/NodeDomain.js:148 (anonymous
function)
On Mon, Oct 5, 2015 at 8:00 PM, Kohei Hayashi<EMAIL_ADDRESS>wrote:

can you confirm developer tools?
Debug > Show Develper Tools
then
Console (tab) > All
—
Reply to this email directly or view it on GitHub
https://github.com/kooohei/brackets-synapse/issues/40#issuecomment-145701695
.

After submitting my password in the decrypt pop-up I get the following in
the dev console:
Uncaught TypeError: undefined is not a functionPanel.js:185
(anonymous function)thirdparty.min.js:559 (anonymous
function)thirdparty.min.js:559 jthirdparty.min.js:559
k.fireWiththirdparty.min.js:559 e.(anonymous function)thirdparty.min.js:559
jthirdparty.min.js:559 k.addthirdparty.min.js:559 (anonymous
function)thirdparty.min.js:559 jthirdparty.min.js:559
k.fireWiththirdparty.min.js:559 e.(anonymous function)Notify.js:94
(anonymous function)thirdparty.min.js:559 (anonymous
function)thirdparty.min.js:559 jthirdparty.min.js:559
k.fireWiththirdparty.min.js:560 hthirdparty.min.js:559
jthirdparty.min.js:559 k.fireWiththirdparty.min.js:559
k.firethirdparty.min.js:560 n.extend.dequeuethirdparty.min.js:560
d.completethirdparty.min.js:559 jthirdparty.min.js:559
k.fireWiththirdparty.min.js:560 Xb.ithirdparty.min.js:560 n.fx.tick
On Mon, Oct 5, 2015 at 8:08 PM, Yannick Tessier<EMAIL_ADDRESS>wrote:

Here's what I see in the dev logs:
[NodeDomain] Error loading domain "synapse": Unable to load one of the
modules:
C:/Users/Yannick/AppData/Roaming/Brackets/extensions/user/brackets-synapse/node/SynapseDomain,
reason: Cannot find module 'jsftp'/utils/NodeDomain.js:148 (anonymous
function)
On Mon, Oct 5, 2015 at 8:00 PM, Kohei Hayashi<EMAIL_ADDRESS>wrote:

can you confirm developer tools?
Debug > Show Develper Tools
then
Console (tab) > All
—
Reply to this email directly or view it on GitHub
https://github.com/kooohei/brackets-synapse/issues/40#issuecomment-145701695
.

ok sorry, fix soon.

1.2.2 upload now.
please try that.

Thanks!
On Oct 5, 2015 8:27 PM, "Kohei Hayashi"<EMAIL_ADDRESS>wrote:

ok sorry, fix soon.
—
Reply to this email directly or view it on GitHub
https://github.com/kooohei/brackets-synapse/issues/40#issuecomment-145705785
.

I'll be able to test in an hour or so.
On Oct 5, 2015 8:32 PM, "Yannick Tessier"<EMAIL_ADDRESS>wrote:

Thanks!
On Oct 5, 2015 8:27 PM, "Kohei Hayashi"<EMAIL_ADDRESS>wrote:

ok sorry, fix soon.
—
Reply to this email directly or view it on GitHub
https://github.com/kooohei/brackets-synapse/issues/40#issuecomment-145705785
.

Finally go around to testing 1.2.2 - same error here:
Uncaught TypeError: undefined is not a functionPanel.js:185
(anonymous function)thirdparty.min.js:559 (anonymous
function)thirdparty.min.js:559 jthirdparty.min.js:559
k.fireWiththirdparty.min.js:559 e.(anonymous function)thirdparty.min.js:559
jthirdparty.min.js:559 k.addthirdparty.min.js:559 (anonymous
function)thirdparty.min.js:559 jthirdparty.min.js:559
k.fireWiththirdparty.min.js:559 e.(anonymous function)Notify.js:94
(anonymous function)thirdparty.min.js:559 (anonymous
function)thirdparty.min.js:559 jthirdparty.min.js:559
k.fireWiththirdparty.min.js:560 hthirdparty.min.js:559
jthirdparty.min.js:559 k.fireWiththirdparty.min.js:559
k.firethirdparty.min.js:560 n.extend.dequeuethirdparty.min.js:560
d.completethirdparty.min.js:559 jthirdparty.min.js:559
k.fireWiththirdparty.min.js:560 Xb.ithirdparty.min.js:560 n.fx.tick
On Mon, Oct 5, 2015 at 9:11 PM, Yannick Tessier<EMAIL_ADDRESS>wrote:

I'll be able to test in an hour or so.
On Oct 5, 2015 8:32 PM, "Yannick Tessier"<EMAIL_ADDRESS>wrote:

Thanks!
On Oct 5, 2015 8:27 PM, "Kohei Hayashi"<EMAIL_ADDRESS>wrote:

ok sorry, fix soon.
—
Reply to this email directly or view it on GitHub
https://github.com/kooohei/brackets-synapse/issues/40#issuecomment-145705785
.

What's interesting is that after I've removed the extension and re-installed it, it remembers my crypto password and does not ask me to create a new one.

yeah. i get the same. and it wont acept the password i mae previously

now 1.2.2 available, and functionPanel.js is no relationship with synapse.

perhaps other extension make conflict.
can you tell me installed extensions?

What's interesting is that after I've removed the extension and re-installed it, it remembers my crypto password and does not ask me to create a new one.
this is no problem, extensions config write to .brackets.json
please confirm [Debug] -> [Open Preferences File]
you can find the line with brackets-synapse prefix.

I removed all other extensions and re-installed brackets-synapse and after
adding my password here's the error I get in the console:
Uncaught TypeError: undefined is not a function
/C:/Users/Yannick/AppData/Roaming/Brackets/extensions/user/brackets-synapse/modules/Panel.js:185
On Tue, Oct 6, 2015 at 8:34 AM, Kohei Hayashi<EMAIL_ADDRESS>wrote:

What's interesting is that after I've removed the extension and
re-installed it, it remembers my crypto password and does not ask me to
create a new one.
this is no problem, extensions config write to .brackets.json
please confirm [Debug] -> [Open Preferences File]
you can find the line with brackets-synapse prefix.
—
Reply to this email directly or view it on GitHub
https://github.com/kooohei/brackets-synapse/issues/40#issuecomment-145842837
.

ok thanks, I wanted it.
please try 1.2.3, now available.

OK - it's working again
On Wed, Oct 7, 2015 at 12:34 AM, Kohei Hayashi<EMAIL_ADDRESS>wrote:

ok thanks, I wanted it.
please try 1.2.3, now available.
—
Reply to this email directly or view it on GitHub
https://github.com/kooohei/brackets-synapse/issues/40#issuecomment-146074954
.

Thank you! Very useful extension.
On Wed, Oct 7, 2015 at 12:40 AM, Yannick Tessier<EMAIL_ADDRESS>wrote:

OK - it's working again
On Wed, Oct 7, 2015 at 12:34 AM, Kohei Hayashi<EMAIL_ADDRESS>wrote:

ok thanks, I wanted it.
please try 1.2.3, now available.
—
Reply to this email directly or view it on GitHub
https://github.com/kooohei/brackets-synapse/issues/40#issuecomment-146074954
.

thanks too.
This extension does not improve.
If you do not have everyone's advice.

I agree.  Here's an error I'm getting now when saving a file.
Uncaught Error: Could not save file to server     /FileManager.js:99
I know I can update my AWS ec2 instance using winSCP on port 22
successfully using the same user.  Actually, I can auto upload to my AWS
server using JetBrains PHPStorm as well using the same user, etc.
On Wed, Oct 7, 2015 at 1:01 AM, Kohei Hayashi<EMAIL_ADDRESS>wrote:

thanks too.
This extension does not improve.
If you do not have everyone's advice.
—
Reply to this email directly or view it on GitHub
https://github.com/kooohei/brackets-synapse/issues/40#issuecomment-146078047
.

ok so, did file actually saved?

I need help you,
open the file FileManager.js ([Help] ->[Show Extensions Folder])
user -> brackets-synapse -> modules -> FileManager.js
and replace the following code and 99 line.
throw new Error("Could not save file to server", err);
then please tell me what did you see on the error log when retry same action.(file save)

Uncaught Error: Could not save file to server FileManager.js:99
(anonymous function) thirdparty.min.js:559
(anonymous function) thirdparty.min.js:559
j thirdparty.min.js:559
k.fireWith  thirdparty.min.js:559
e.(anonymous function) RemoteManager.js:194
(anonymous function)  thirdparty.min.js:559
(anonymous function)   thirdparty.min.js:559
j   thirdparty.min.js:559
k.fireWith    thirdparty.min.js:559
NodeConnection._receive  /utils/NodeConnection.js:498

sorry for the late response.
please confirm error in the developer tools after update to version 1.2.7

now available 1.2.71.
append to the display response code with error on synapse console.
please confirm the number of code.


Custom NuGet package sources ignored during C# project load

Issue Description
I can't figure out how to get OmniSharp to look in all of my currently configured machine-wide NuGet sources.  I'm not sure if this is a bug or just something I have not done properly.  I have seen other logs online where customized sources ARE checked for dependencies, so I expect there's a way to make it work.
Steps to Reproduce
Added a third, on-premise package source via Visual Studio's Options->NuGet Package Manager Settings, in addition to the existing Microsoft Visual Studio Offline Packages and nuget.org sources.  All 3 are available, and Visual Studio is able to use the new source (let's call it "privatenuget").
Expected Behavior
When I open a directory in VS Code containing C# projects, I expect all 3 sources (Microsoft Visual Studio Offline Packages, nuget.org, and privatenuget) to be searched for loading NuGet dependencies.
Actual Behavior
Only the original two sources (Microsoft Visual Studio Offline Packages and nuget.org) are searched, so private packages are not found.  I have reloaded VS Code, rebooted the system, and also uninstalled/cleaned/reinstalled the OmniSharp Extension.
Logs
OmniSharp log
c:\Workspaces\PrivateRepo\Private.Project\Private.Project.csproj(0,0): Error: Unable to find package Private.Common. No packages exist with this id in source(s): Microsoft Visual Studio Offline Packages, nuget.org
C# log
Installing C# dependencies...
Platform: win32, x86_64
Downloading package 'OmniSharp for Windows (.NET 4.6 / x64)' (31766 KB).................... Done!
Validating download...
Integrity Check succeeded.
Installing package 'OmniSharp for Windows (.NET 4.6 / x64)'
Downloading package '.NET Core Debugger (Windows / x64)' (47921 KB).................... Done!
Validating download...
Integrity Check succeeded.
Installing package '.NET Core Debugger (Windows / x64)'
Downloading package 'Razor Language Server (Windows / x64)' (47276 KB).................... Done!
Installing package 'Razor Language Server (Windows / x64)'
Finished
Environment information
VSCode version: 1.33.0
C# Extension: 1.18.0
Dotnet Information
.NET Core SDK (reflecting any global.json):
 Version:   2.1.602
 Commit:    04475eb7cf
Runtime Environment:
OS Name:     Windows
OS Version:  10.0.17134
OS Platform: Windows
RID:         win10-x64
Base Path:   C:\Program Files\dotnet\sdk\2.1.602\
Host (useful for support):
Version: 2.1.9
Commit:  dcedc87d22
.NET Core SDKs installed:
1.0.4 [C:\Program Files\dotnet\sdk]
1.1.0 [C:\Program Files\dotnet\sdk]
2.1.4 [C:\Program Files\dotnet\sdk]
2.1.103 [C:\Program Files\dotnet\sdk]
2.1.104 [C:\Program Files\dotnet\sdk]
2.1.200 [C:\Program Files\dotnet\sdk]
2.1.201 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.403 [C:\Program Files\dotnet\sdk]
2.1.500 [C:\Program Files\dotnet\sdk]
2.1.502 [C:\Program Files\dotnet\sdk]
2.1.503 [C:\Program Files\dotnet\sdk]
2.1.505 [C:\Program Files\dotnet\sdk]
2.1.602 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download

Visual Studio Code Extensions

Extension
Author
Version

azurecli
ms-vscode
0.4.4

code-settings-sync
Shan
3.2.8

cpptools
ms-vscode
0.22.1

csharp
ms-vscode
1.18.0

language-x86-64-assembly
13xforever
2.2.11

powershell
ms-vscode
1.12.0

python
ms-python
2019.3.6352

vscode-docker
PeterJausovec
0.6.1

@emuslor What happens if you dotnet restore your project before you open it in vs code?

@rchande Restore completes successfully.  Then when I re-open vs code, there are no errors from omnisharp.  I would simply do this all the time, but I'm dealing with a source tree containing a lot of directories full of project with frequently changing dependencies, so the ability to auto-traverse that tree and successfully restore deps with omnisharp when I open vs code would be quite useful.

@emuslor The C# extension has 2 commands ".NET: Restore All Projects" and ".NET Restore Project" (which will let you select a project) that should do what you need---they'll invoke dotnet restore on your behalf for the requested projects.

@rchande Thanks.  Is there a way to make that happen recursively for all projects in a tree?  It seems like it tries to do that, but it stops at the first subdirectory that it finds projects in.  For example, say my repo tree looks like this:
Myproject/
-- Projdir1/
---- a/
------ a.csproj
---- b/
------ b.csproj
-- Projdir2/
---- c/
------ c.cspoj
---- d/
------ d.csproj
If I open the Myproject directory in VS Code and then do a .NET: Restore All Projects, it restores for a.csproj and b.csproj.  Those are also the only choices when I do a .NET: Restore Project.  c and d are ignored.

@emuslor Do you have a .sln file that only includes some of the projects? You can choose what the target sln/csproj is using the selector next to the green flame icon in the lower left.

@rchande Indeed.  So I guess I just need to select each sln and do the restore all for each.  Any way to do them all at once without combining into an uber sln?

@emuslor We don't provide a way to do that. Out of curiosity, why do you have solutions that don't contain all of the projects in the project reference dependency graph?

@rchande That's a fine question.  I'm claiming innocence on that one, as it is an existing project I am now helping more with. :)  But this helps a good bit.  Thanks for assiting the omnisharp n00b!


SemAct registry?

I notice in SemanticAction::satisfies? "FIXME: should have a registry"
I'm keen to see that, as I'd like to experiment with ShExMap. Did you have ideas about how such a registry should be implemented? For instance, does it make sense to have it be a field on the options hash, and inject it during parse, or better to have it be a class variable on ShEx? The latter as the default value for the former?

Discovery is done base on the URI, so parsing doesn't come into it. Perhaps something lie RDF::Vocabulary, with an sub-class using the URI of the plugin. We can then use an inherited hook to add it to the registry when the class is created. The issue is knowing what environment to provide to such plugins, as the spec is vague about this; probably the instance of the calling Operator.
Haven't looked at ShExMap.

In terms of the registry object itself, my question comes down to, I think, is there a reasonable argument that a single global registry is sufficient? If different ShEx::Algebra::Schema will need their own registries, how should that be passed to the SemAct that needs it to do lookup?
The subclassed hook approach, which sounds good to me, sounds like there's no driver for anything but a global registry.
I definitely agree that SemActs are vaguely defined, as I review the spec about them. I'd assumed they should be understood by analogy to semantic actions in string parsing algorithms.
I tend to agree that the calling Operator should pass as complete a "satisfaction result" into the SemAct as possible; what of that context the SemAct uses would be up to the implementation. Again, by analogy to string parsing, where there is larger context involved with processing a semantic action, it's the semantic engine's responsibility to maintain that; the parser's responsibility is to provide enough information for the engine to do that processing. I'd despair at prognosticating about exactly what information that would be; an data structure designed to expand nicely as needed seems like it's called for.
I'm interested in pulling together a PR for this; I've already got a rights transfer on file for RDF.rf - does that transfer?

The only "registry" I believe we need is for Semantic Actions. I think if SemAct serves as a super-class, then different implementations (e.g., SemActTest) could be created using something like the following:
class SemActTest < ShEx::Algebra::SemAct("http://shex.io/extensions/Test/")
  def satisfied?(expression, matched, unmatched)
        str = if md = /^ *(fail|print) *\( *(?:(\"(?:[^\\"]|\\")*\")|([spo])) *\) *$/.match(operands[1].to_s)
          md[2] || case md[3]
          when 's' then matched.first.subject
          when 'p' then matched.first.predicate
          when 'o' then matched.first.object
          else          matched.first.to_sxp
          end.to_s
        else
          matched.empty? ? 'no statement' : matched.first.to_sxp
        end
        $stdout.puts str
        status str
        not_satisfied "fail" if md && md[1] == 'fail'
        true
  end
end

SemAct then implements something like:
  def inherited(subclass) # @private
    unless @@uri.nil?
      @@subclasses[@@uri] = subclass
    end
    super
  end

Then in SemAct#satisfies?:
def satisfies?
  subclass = @@subclasses.fetch(operands.first.to_s)
  subclass.new.satisfies?(*operands)
rescue KeyError => e
  status("unknown SemAct name #{operands.first}") {"expression: #{self.to_sxp}"}
  false
end

ShEx has one or two subclasses of SemAct built in (Test at least). Different gems can implement more subclasses, which when required by the application, automatically cause them to be registered and available for dispatch.

I think, is there a reasonable argument that a single global registry is sufficient? If different ShEx::Algebra::Schema will need their own registries, how should that be passed to the SemAct that needs it to do lookup?

Each SemAct needs to be uniquely identified by the URI operand. There shouldn't be overlap, but if there is, an application can choose which implementation to require.

I'm interested in pulling together a PR for this; I've already got a rights transfer on file for RDF.rf - does that transfer?

I'll make sure you have rights on this gem. You should add yourself as an AUTHOR, but recognize that this comes with responsibilities! Thanks for your help, contributions and contributors are more than welcome! After things settle down, we should create an issues list to manage the direction of the gem.

Right now, I'm reworking #execute and #satisfies, with #execute always returning (or raising) the marked-up operands to be able to walk back to determine why a shape was satisfied or not.
I'd like to get ShExJ implemented, both to read and write.
A SXP reader might be useful (should be trivial).
Heavy-wieght tracking of matched/unmatched satisfied/unsatisfied might be controlled using a :verbose option, so that in the simple operational case, the matching could be pretty light weight.
I'm not happy with the duplication with focus and map (in the gem or the spec). I think that focus is used for start, and the body should probably iterate through the map, so that a given shape could match different resources with one or more shapes in one call.

Please work on a GitFlow feature branch, and let's do PRs to get back into the develop branch. Once I've completed the work I'm doing right now, I'll do the same.


Add using at SerialDevice.FromIdAsync()

Resolved the problem of returning null when calling the OnLaunched1() method more than once.

@stevewhims
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


docs: add typescriptreact (tsx) files to the recommended config

Adding this config after a while trying to figure out why xo wasn't working

Thank you!


[Bug Report] build module copy the public folder incorrectly

Chrome extension may have some special file ( or folder ) in extension root, like _locales folder for i18n, or static assets folder.
However, After add this vite plugin, those files in public folder will not copy to dist folder when execute vite build --watch.
But when execute command vite build without --watch param, those files will copy fined.
Steps to reproduce

Create a normal vite project

yarn create vite
cd bug-report
mkdir public
echo 'test file' > public/test.txt
yarn
yarn build --watch

In this step, we can see the file test.txt corrent copy to the public folder, then exit and rm the dist folder.

Add this vite plugin,

yarn add -D vite-plugin-web-extension

and sort project like the demo/vanilla, the whole filetree are like this
src
│  manifest.json
│
├─assets
│  └─icon
│          128.png
│
├─background
│      index.ts
│
├─options
│      index.html
│      main.ts
│
├─popup
│      index.html
│      main.ts
│
└─public
    └─_locales
        ├─en
        │      messages.json
        │
        └─zh_CN
                messages.json

in manifest.json, I change the key name like:
{
  "name": "__MSG_extName__"
}

and the minimal reproduction can see this repo: https://github.com/Rhilip/bugreport-vite-plugin-web-extension-watchbuild

The run the build command,

For vite build --watch , the dist folder is like

dist
  │  manifest.json
  │  modulepreload-polyfill.js
  │
  ├─assets
  │  └─icon
  │          128.png
  │          16.png
  │          48.png
  │
  ├─background
  │  │  index.js
  │  │
  │  └─_locales   <-  It appeared in background folder
  │      ├─en
  │      │      messages.json
  │      │
  │      └─zh_CN
  │              messages.json
  │
  ├─options
  │      index.html
  │      index.js
  │
  └─popup
          index.html
          index.js

For vite build, the dist folder is like

dist
│  manifest.json
│  modulepreload-polyfill.js
│
├─ ... other same folder
│
└─_locales
    ├─en
    │      messages.json
    │
    └─zh_CN
        messages.json

I also test two structure, however still same as step 3

move public folder into project root

	  root
	  ├─node_modules
	  ├─public
	  │  └─_locales
	  │      ├─en
	  │      └─zh_CN
	  └─src
	      ├─assets
	      │  └─icon
	      ├─background
	      ├─options
	      └─popup

separate old public folder, leave _locales folder inside src folder, and use same assets folder.

	  root
	  ├─node_modules
	  └─src
	      ├─_locales
	       │ ├─en
	       │ └─zh_CN
	      ├─assets
	      │  └─icon
	      ├─background
	      ├─options
	      └─popup

What is actually happening?
When run command vite build , the files in public folder will be copy to dist/background folder and dist folder,
When run command vite build --watch, those files will only be copy to dist/background folder.
What is expected?
When run command vite build or vite build -watch, the public folder will copy as default vite behavior: copy to dist folder.

Sorry, just saw this!
TBH, I completely forgot about the public folder, thanks for reporting this! I'm surprised it doesn't just work out of the box, I don't think the extension does anything that would effect it. I'll check this out this weekend, and hopefully get out a fix.
If you need something right now, you can use rollup-plugin-copy to copy files to exactly where they need to go in your output. I use it and it works for both regular and watch build modes.

Sorry for the late reply, it's working fine now


Document the codebase

The codebase is growing, but it doesn't have a lot to it in terms of documentation.
Write comments describing what things do.

Core is done

Config is done

Window and input map are done

Systems done

All existing code seems to be documented, alright


BE AS CLEAR AND CONCISE AS POSSIBLE.
describe the bug
what is the bug - what happens?
when I run sudo npm i -g notion-enhancer, I got the following error.
=== NOTION ENHANCEMENT LOG ===
### ERROR ###
[Error: EACCES: permission denied, mkdir '/var/root/.notion-enhancer'] {
  errno: -13,
  code: 'EACCES',
  syscall: 'mkdir',
  path: '/var/root/.notion-enhancer'
}
=== END OF LOG ===

expected behaviour
why is this a bug - what should be happening?
I expect it will be installed successfully. Since I ran the command under root.
screenshots
if applicable, add screenshots of your problem.
I have copied and pasted the error message above.
platform
what OS are you using? e.g. windows 7, windows 10, WSL, ubuntu, arch linux, macOS
I am using macOS catalina, 10.15.6.

Same issue also on Catalina 10.15.6.

macOS Catalina 10.15.7 bug still present.
trying to install with/without root results in the same EACCES error:
2020-10-14T17_56_54_159Z-debug.log
under user:
npm WARN checkPermissions Missing write access to /usr/local/lib/node_modules/notion-enhancer
npm WARN checkPermissions Missing write access to /usr/local/lib/node_modules
npm ERR! code EACCES
npm ERR! syscall access
npm ERR! path /usr/local/lib/node_modules/notion-enhancer
npm ERR! errno -13
npm ERR! Error: EACCES: permission denied, access '/usr/local/lib/node_modules/notion-enhancer'
npm ERR!  [Error: EACCES: permission denied, access '/usr/local/lib/node_modules/notion-enhancer'] {
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'access',
npm ERR!   path: '/usr/local/lib/node_modules/notion-enhancer'
npm ERR! }
npm ERR!
npm ERR! The operation was rejected by your operating system.
npm ERR! It is likely you do not have the permissions to access this file as the current user
npm ERR!
npm ERR! If you believe this might be a permissions issue, please double-check the
npm ERR! permissions of the file and its containing directories, or try running
npm ERR! the command again as root/Administrator.

under root:
### ERROR ###
Error: EACCES: permission denied, mkdir '/Applications/Notion.app/Contents/Resources/app'
    at Object.mkdirSync (fs.js:921:3)
    at Object.promisified.mkdirpSync (/usr/local/lib/node_modules/notion-enhancer/node_modules/asar/lib/wrapped-fs.js:24:38)
    at module.exports.extractAll (/usr/local/lib/node_modules/notion-enhancer/node_modules/asar/lib/asar.js:177:6)
    at module.exports (/usr/local/lib/node_modules/notion-enhancer/pkg/apply.js:57:5)
    at async CAC.<anonymous> (/usr/local/lib/node_modules/notion-enhancer/bin.js:29:5) {
  errno: -13,
  syscall: 'mkdir',
  code: 'EACCES',
  path: '/Applications/Notion.app/Contents/Resources/app'
}
=== END OF LOG ===

@tonyshutov that's a different error. Same error code, different path - the original error was a bug, this is just a user installation issue. Run these commands to fix it (and don't do the npm i -g notion-enhancer under root).
sudo chmod -R a+wr /usr/local/lib/node_modules
sudo chmod -R a+wr /usr/local/bin
sudo chmod -R a+wr /Applications/Notion/Contents/Resources
sudo chmod -R a+wr /Applications/Notion.app/Contents/Resources


Cascadia Mono font not found

Windows Terminal version
1.18.2681.0
Windows build number
10.0.22621.2283
Other Software
winget v1.6.2701
Steps to reproduce
Install an older version of Terminal. Upgrade to 1.18.2681.0 using winget.
Expected Behavior
Upgrade succeeds.
Actual Behavior
Terminal says it can't find a font named Cascadia Mono, and falls back to Consolas

I know this has been reported a million times, but it just happened to me and all of the previous issues on it seem to be closed, so it clearly isn't resolved.
I do not see Cascadia Mono in the Windows Fonts UI or in C:\Windows\Fonts or in %localappdata%\Microsoft\Windows\Fonts, so something either uninstalled it, or it is not included in Windows 11 Home.
I tried doing a Repair, but it didn't accomplish anything.

This is wacky and very unexpected. The other issues are all closed, because we thought we fixed this a few releases ago. We added a final fallback to try and load the font directly from a file in our package (not from the font cache).
What rendering engine are you using (could you share your settings.json file)? (we're pretty sure the rendering engine shouldn't matter here.)
Our only theory right now is that the way we detect a failure to load the font might not be working anymore?
23d45a7e3a286f37924fd68d222168fce631282d was the last touch here, which only shipped in 1.18 preview. That we might need to revert 😞

I just encountered this after upgrading using winget.

Windows Terminal version (after upgrading): 1.18.2822.0
Windows build number: 10.0.19045.0
winget version: v1.6.2771

yes

This is wacky and very unexpected. The other issues are all closed, because we thought we fixed this a few releases ago. We added a final fallback to try and load the font directly from a file in our package (not from the font cache).
What rendering engine are you using (could you share your settings.json file)? (we're pretty sure the rendering engine shouldn't matter here.)
settings.json

Reminder that Cascadia Mono did not seem to be installed in Windows 11 for some reason (which is weird because I was using an old version of Terminal without having ever seen that error), so it seems to be Terminal depending on something which isn't guaranteed to be present?

Here's my settings.json, too.
I've not reconfigured anything related to rendering engines, fonts, or anything like that.

The plot thickens: I have C:\Windows\Fonts\CascadiaMono.ttf, and I was also able to use the Cascadia Mono font in Notepad without issue.

.github/workflows/generator-generic-ossf-slsa3-publish.yml

I'm not sure if this is what #16196 is addressing, but I decided to run Process Monitor while starting up Terminal and saw it was trying to load C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.17.11461.0_x64__8wekyb3d8bbwe\CascadiaMono.ttf, but I'm currently running v1.18.2822.0.  Just thought I'd share incase the PR doesn't address this.

I'm not sure if this is what #16196 is addressing, but I decided to run Process Monitor while starting up Terminal and saw it was trying to load C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.17.11461.0_x64__8wekyb3d8bbwe\CascadiaMono.ttf, but I'm currently running v1.18.2822.0. Just thought I'd share incase the PR doesn't address this.

I should have waited to post until I did this, but after restarting my machine, I am no longer having issues with the Cascadia Mono font not found message.  My font is still set to Cascadia Mono, just no more error messages.

I'm not sure if this is what #16196 is addressing, but I decided to run Process Monitor while starting up Terminal and saw it was trying to load C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.17.11461.0_x64__8wekyb3d8bbwe\CascadiaMono.ttf, but I'm currently running v1.18.2822.0. Just thought I'd share incase the PR doesn't address this.

I should have waited to post until I did this, but after restarting my machine, I am no longer having issues with the Cascadia Mono font not found message. My font is still set to Cascadia Mono, just no more error messages.

I can confirm your experience. I haven't booted this Windows system the last days. So my system started updating several "things".
After a while I opened the Terminal and god this strange error message. So I checked Github here.
Before rebooting, I could enter the exact directory that you mention in my Explorer. The font files where not possible to open ad all. Double click failed. But also a thing like trying to open it with Notepad.
It gave me a permissions related error.
After rebooting, this path did not exist anymore, but the Terminal was working fine again and the font just loads without any issues.
So my conclusion is that the Terminal still tried to load the font from an old directory that was being uninstalled by the update. But somehow that process was not fully complete until reboot.
Which may not be strange at all, but it's not what you expect from an App Store based app in general.
So it seems that some kind of proper warning system warning the user that he really needs to reboot is missing here.


Add Support for 2022.3

Unfortunately, plugin is currently not working for PHPStorm 2022.3.*, because it is not declared to be compatible with these version of PHPStorm.
When trying to build an own zip file from the repository, I unfortunately get a build error.
Would be nice to have this plugin available for current PHPStorm versions. TIA!

Hi @PhMemmel ,
We are working on Mid version that will support PHPStorm 2022.3, Some changes are that the plugin is no more alow to change the oriinal PHP files template and we need to implimant it.
We will glade to any kind of help if you can. and hope to enable it ASAP

Thank you very much for answering. I just raised this because it looked like the issue is just about interchanging some version numbers and re-release it which apparently is not the case, thank you for clarifying. Unfortunately I will not be able to provide any help here, because I have no experience developing JetBrains plugins at all, sorry :-( But I appreciate your efforts very much, thank you for your great work!


added b2d using js and regex

hey maintainer ,just created a vanilla app of binary to decimal convertor . I am aware that there is already one using vanilla js. But it has some errors(event bubbling occurs in the whole container ) .
I have done It keeping in mind

Hello everyone 👋
I hope this message finds you well. As you may know, the original repository for app ideas has not been updated in a while and is no longer actively maintained. However, I'm excited to let you know that a new repository has been created to continue this project (https://github.com/vincent0426/app-ideas).
The new repository aims to provide a comprehensive list of practical and achievable app ideas that developers of all levels can work on to improve their skills and build their portfolios. We welcome contributions from anyone who wants to add their own app ideas or improve the existing ones, and we are also looking for volunteers who can help maintain the repository and keep it up to date.
If you are interested in contributing or maintaining this project, please head over to the new repository (https://github.com/vincent0426/app-ideas) ⭐ and take a look at the existing issues and pull requests. Feel free to open a new issue if you have an app idea to suggest or if you have any questions about the project.
Thank you for your attention, and I hope to see you in the new repository soon! 💖

⚠ This message was generated by a robot 🤖, if this message reached you, consider leaving a star for this robot, repository link
⭐ https://github.com/aldairandre/github-bot ⭐