Compiling on M2 Mac running MacOS 13.0 fails

I'm a long time KMonad user, and have been using a self-compiled binary from the keycode-refactor branch.
I'm now moving to a new M2 Mac (Previous one was M1) and I can't for the life of me compile the binary.
stack.yaml:
resolver: lts-18.28
packages:
- .
pvp-bounds: both

System config:
brew config
HOMEBREW_VERSION: 4.0.26
ORIGIN: https://github.com/Homebrew/brew
HEAD: eff45ef570f265e226f14ce91da72d7a6e7d516a
Last commit: 6 days ago
Core tap origin: https://github.com/Homebrew/homebrew-core
Core tap HEAD: c16f7de902c54fef88c34d909452aae7a8e3a4e9
Core tap last commit: 4 weeks ago
Core tap branch: master
Core tap JSON: 03 Jul 08:38 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_EDITOR: nvim
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 2.6.10 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit arm_blizzard_avalanche
Clang: 14.0.3 build 1403
Git: 2.41.0 => /opt/homebrew/bin/git
Curl: 7.84.0 => /usr/bin/curl
macOS: 13.0-arm64
CLT: <IP_ADDRESS>.1.1683849156
Xcode: 14.3.1
Rosetta 2: false

gcc -v
Apple clang version 14.0.3 (clang-14<IP_ADDRESS>.1)
Target: arm64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

git --version
git version 2.41.0

stack install log (Watch out, hella long):
stack install --flag kmonad:dext
Building all executables for kmonad once. After a successful build of all
of them, only specified executables will be rebuilt.
kmonad> configure (lib + exe)
Configuring kmonad-0.4.1...
kmonad> build (lib + exe)
Preprocessing library for kmonad-0.4.1..
Building library for kmonad-0.4.1..
[ 1 of 71] Compiling KMonad.Prelude.Imports
[ 2 of 71] Compiling KMonad.Prelude.Types
[ 3 of 71] Compiling KMonad.Prelude.Util
[ 4 of 71] Compiling KMonad.Prelude
[ 5 of 71] Compiling KMonad.App.Invocation.TH
[ 6 of 71] Compiling KMonad.Util.Ctx
[ 7 of 71] Compiling KMonad.App.Main.OS
[ 8 of 71] Compiling KMonad.Util.FFI
[ 9 of 71] Compiling KMonad.Util.Keyboard.Common
[10 of 71] Compiling KMonad.Util.Keyboard.Compose
[11 of 71] Compiling KMonad.Util.LayerStack
[12 of 71] Compiling KMonad.Util.Logging.Operations
[13 of 71] Compiling KMonad.Util.Logging.Types
[14 of 71] Compiling KMonad.Util.Logging.IO
[15 of 71] Compiling KMonad.Util.Logging
[16 of 71] Compiling KMonad.Util.Name
[17 of 71] Compiling KMonad.Util.Keyboard.Keynames
[18 of 71] Compiling KMonad.Util.Keyboard.Mac
[19 of 71] Compiling KMonad.Util.Keyboard.OS
[20 of 71] Compiling KMonad.Util.OS
[21 of 71] Compiling KMonad.Util.Time.Types
[22 of 71] Compiling KMonad.Util.Time.Operations
[23 of 71] Compiling KMonad.Util.Time.IO
[24 of 71] Compiling KMonad.Util.Time
[25 of 71] Compiling KMonad.Util.Keyboard.Types
[26 of 71] Compiling KMonad.Util.Keyboard.Operations
[27 of 71] Compiling KMonad.Util.Keyboard.IO
[28 of 71] Compiling KMonad.Util.Keyboard
[29 of 71] Compiling KMonad.Util
[30 of 71] Compiling KMonad.Pullchain.Types
[31 of 71] Compiling KMonad.Pullchain.Components.Sluice
[32 of 71] Compiling KMonad.Pullchain.Components.Dispatch
[33 of 71] Compiling KMonad.Pullchain.Action
[34 of 71] Compiling KMonad.Pullchain.Components.Hooks
[35 of 71] Compiling KMonad.Pullchain.Button
[36 of 71] Compiling KMonad.Pullchain
[37 of 71] Compiling KMonad.Model.Types
[38 of 71] Compiling KMonad.Model.IO
[39 of 71] Compiling KMonad.Model
[40 of 71] Compiling KMonad.Pullchain.Operations
[41 of 71] Compiling KMonad.Pullchain.Components.Keymap
[42 of 71] Compiling KMonad.Pullchain.Env
[43 of 71] Compiling KMonad.Pullchain.Loop
[44 of 71] Compiling KMonad.App.KeyIO.Common.Types
[45 of 71] Compiling KMonad.App.KeyIO.Common.KeyRepeat
[46 of 71] Compiling KMonad.App.KeyIO.Common
[47 of 71] Compiling KMonad.App.KeyIO.Mac.IOKitSource
[48 of 71] Compiling KMonad.App.KeyIO.Mac.Ext
[49 of 71] Compiling KMonad.App.KeyIO.Mac.IO
[50 of 71] Compiling KMonad.App.KeyIO.Mac
[51 of 71] Compiling KMonad.App.KeyIO.OS
[52 of 71] Compiling KMonad.App.KeyIO
[53 of 71] Compiling KMonad.App.Types
[54 of 71] Compiling KMonad.Pullchain.IO
[55 of 71] Compiling KMonad.App.Main.Loop
[56 of 71] Compiling KMonad.App.Parser.Types
[57 of 71] Compiling KMonad.App.Parser.Operations
[58 of 71] Compiling KMonad.App.Parser.Keycode
[59 of 71] Compiling KMonad.App.Parser.Tokenizer
[60 of 71] Compiling KMonad.App.Parser.TokenJoiner
[61 of 71] Compiling KMonad.App.Parser
[62 of 71] Compiling KMonad.App.Invocation.Types
[63 of 71] Compiling KMonad.App.Invocation.Operations
[64 of 71] Compiling KMonad.App.Parser.IO
[65 of 71] Compiling KMonad.App.Invocation.Parser
[66 of 71] Compiling Paths_kmonad
[67 of 71] Compiling KMonad.App.Invocation.IO
[68 of 71] Compiling KMonad.App.Invocation
[69 of 71] Compiling KMonad.App.Main.Run
[70 of 71] Compiling KMonad.App.Main
[71 of 71] Compiling KMonad.App

/Users/orel/dev/external/kmonad/In file included from c_src/mac/dext.cpp:1:0: error:

/Users/orel/dev/external/kmonad/c_src/mac/keyio_mac.hpp:160:39: error:
     warning: 'kIOMasterPortDefault' is deprecated: first deprecated in macOS 12.0 [-Wdeprecated-declarations]
        kr = IOServiceGetMatchingServices(kIOMasterPortDefault,
                                          ^~~~~~~~~~~~~~~~~~~~
                                          kIOMainPortDefault
    |
160 |     kr = IOServiceGetMatchingServices(kIOMasterPortDefault,
    |                                       ^

/Users/orel/dev/external/kmonad//Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/IOKit.framework/Headers/IOKitLib.h:133:19: error:
     note: 'kIOMasterPortDefault' has been explicitly marked deprecated here
    |
133 | const mach_port_t kIOMasterPortDefault
    |                   ^
const mach_port_t kIOMasterPortDefault
                  ^

/Users/orel/dev/external/kmonad/In file included from c_src/mac/dext.cpp:1:0: error:

/Users/orel/dev/external/kmonad/c_src/mac/keyio_mac.hpp:169:72: error:
     warning: 'kIOMasterPortDefault' is deprecated: first deprecated in macOS 12.0 [-Wdeprecated-declarations]
        IONotificationPortRef notification_port = IONotificationPortCreate(kIOMasterPortDefault);
                                                                           ^~~~~~~~~~~~~~~~~~~~
                                                                           kIOMainPortDefault
    |
169 |     IONotificationPortRef notification_port = IONotificationPortCreate(kIOMasterPortDefault);
    |                                                                        ^

/Users/orel/dev/external/kmonad//Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/IOKit.framework/Headers/IOKitLib.h:133:19: error:
     note: 'kIOMasterPortDefault' has been explicitly marked deprecated here
    |
133 | const mach_port_t kIOMasterPortDefault
    |                   ^
const mach_port_t kIOMasterPortDefault
                  ^

/Users/orel/dev/external/kmonad/In file included from c_src/mac/dext.cpp:4:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service.hpp:7:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service/client.hpp:12:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/client.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/client_impl.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/asio_helper.hpp:11:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio.hpp:18:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/associated_allocator.hpp:20:0: error:

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/detail/type_traits.hpp:88:12: error:
     error: no member named 'result_of' in namespace 'std'
   |
88 | using std::result_of;
   |            ^
using std::result_of;
      ~~~~~^

/Users/orel/dev/external/kmonad/In file included from c_src/mac/dext.cpp:4:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service.hpp:7:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service/client.hpp:12:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/client.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/client_impl.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/asio_helper.hpp:11:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio.hpp:19:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/associated_executor.hpp:20:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/execution/executor.hpp:20:0: error:

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/execution/execute.hpp:97:13: error:
     error: no member named 'result_of' in namespace 'asio'
   |
97 | using asio::result_of;
   |             ^
using asio::result_of;
      ~~~~~~^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/execution/execute.hpp:153:17: error:
     error: no template named 'result_of'
           typename result_of<typename decay<F>::type&()>::type
                    ^
    |
153 |        typename result_of<typename decay<F>::type&()>::type
    |                 ^

/Users/orel/dev/external/kmonad/In file included from c_src/mac/dext.cpp:4:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service.hpp:7:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service/client.hpp:12:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/client.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/client_impl.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/asio_helper.hpp:11:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio.hpp:19:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/associated_executor.hpp:20:0: error:

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/execution/executor.hpp:42:18: error:
     error: no template named 'result_of'
            typename result_of<typename decay<F>::type&()>::type
                     ^
   |
42 |         typename result_of<typename decay<F>::type&()>::type
   |                  ^

/Users/orel/dev/external/kmonad/In file included from c_src/mac/dext.cpp:4:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service.hpp:7:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service/client.hpp:12:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/client.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/client_impl.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/asio_helper.hpp:11:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio.hpp:19:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/associated_executor.hpp:22:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/system_executor.hpp:20:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/execution.hpp:23:0: error:

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/execution/bulk_execute.hpp:112:13: error:
     error: no member named 'result_of' in namespace 'asio'
    |
112 | using asio::result_of;
    |             ^
using asio::result_of;
      ~~~~~~^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/execution/bulk_execute.hpp:186:18: error:
     error: no template named 'result_of'
            typename result_of<
                     ^
    |
186 |         typename result_of<
    |                  ^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/execution/bulk_execute.hpp:192:10: error:
     error: no member named 'value' in the global namespace
          >::value
           ~~^
    |
192 |       >::value
    |          ^

/Users/orel/dev/external/kmonad/In file included from c_src/mac/dext.cpp:4:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service.hpp:7:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service/client.hpp:12:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/client.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/client_impl.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/asio_helper.hpp:11:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio.hpp:21:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/awaitable.hpp:129:0: error:

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/impl/awaitable.hpp:189:20: error:
     error: no template named 'result_of'
              typename result_of<Function(awaitable_frame_base*)>::type,
                       ^
    |
189 |           typename result_of<Function(awaitable_frame_base*)>::type,
    |                    ^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/impl/awaitable.hpp:192:7: error:
     error: expected ')'
          >::type* = 0)
          ^
    |
192 |       >::type* = 0)
    |       ^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/impl/awaitable.hpp:186:23: error:
     note: to match this '('
      auto await_transform(Function f,
                          ^
    |
186 |   auto await_transform(Function f,
    |                       ^

/Users/orel/dev/external/kmonad/In file included from c_src/mac/dext.cpp:4:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service.hpp:7:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service/client.hpp:12:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/client.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/client_impl.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/asio_helper.hpp:11:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio.hpp:22:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/basic_datagram_socket.hpp:20:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/basic_socket.hpp:36:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/detail/reactive_socket_service.hpp:30:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/detail/reactive_socket_accept_op.hpp:26:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/detail/socket_holder.hpp:20:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/detail/socket_ops.hpp:380:0: error:

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/detail/impl/socket_ops.ipp:2515:7: error:
     warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]
          sprintf(if_name + 1, "%lu", scope_id);
          ^
     |
2515 |       sprintf(if_name + 1, "%lu", scope_id);
     |       ^

/Users/orel/dev/external/kmonad//Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:188:1: error:
     note: 'sprintf' has been explicitly marked deprecated here
    |
188 | __deprecated_msg("This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
    | ^
__deprecated_msg("This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
^

/Users/orel/dev/external/kmonad//Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:215:48: error:
     note: expanded from macro '__deprecated_msg'
            #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
                                                          ^
    |
215 |         #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
    |                                                ^

/Users/orel/dev/external/kmonad/In file included from c_src/mac/dext.cpp:4:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service.hpp:7:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service/client.hpp:12:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/client.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/client_impl.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/asio_helper.hpp:11:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio.hpp:36:0: error:

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/bind_executor.hpp:198:31: error:
     error: no template named 'result_of'
      typename void_type<typename result_of<T()>::type>::type>
                                  ^
    |
198 |   typename void_type<typename result_of<T()>::type>::type>
    |                               ^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/bind_executor.hpp:403:12: error:
     error: no template named 'result_of'
      typename result_of<T(Args...)>::type operator()(
               ^
    |
403 |   typename result_of<T(Args...)>::type operator()(
    |            ^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/bind_executor.hpp:411:12: error:
     error: no template named 'result_of'
      typename result_of<T(Args...)>::type operator()(
               ^
    |
411 |   typename result_of<T(Args...)>::type operator()(
    |            ^

/Users/orel/dev/external/kmonad/In file included from c_src/mac/dext.cpp:4:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service.hpp:7:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service/client.hpp:12:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/client.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/client_impl.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/asio_helper.hpp:11:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio.hpp:45:0: error:

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/co_spawn.hpp:367:16: error:
     error: no template named 'result_of'
          typename result_of<F()>::type>::type) CompletionToken
                   ^
    |
367 |       typename result_of<F()>::type>::type) CompletionToken
    |                ^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/co_spawn.hpp:366:5: error:
     error: too few template arguments for concept 'completion_token_for'
        ASIO_COMPLETION_TOKEN_FOR(typename detail::awaitable_signature<
        ^
    |
366 |     ASIO_COMPLETION_TOKEN_FOR(typename detail::awaitable_signature<
    |     ^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/async_result.hpp:501:11: error:
     note: expanded from macro 'ASIO_COMPLETION_TOKEN_FOR'
      ::asio::completion_token_for<s>
              ^
    |
501 |   ::asio::completion_token_for<s>
    |           ^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/async_result.hpp:492:14: error:
     note: template is declared here
    |
492 | ASIO_CONCEPT completion_token_for =
    |              ^
ASIO_CONCEPT completion_token_for =
             ^

/Users/orel/dev/external/kmonad/In file included from c_src/mac/dext.cpp:4:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service.hpp:7:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service/client.hpp:12:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/client.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/client_impl.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/asio_helper.hpp:11:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio.hpp:45:0: error:

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/co_spawn.hpp:450:16: error:
     error: no template named 'result_of'
          typename result_of<F()>::type>::type) CompletionToken
                   ^
    |
450 |       typename result_of<F()>::type>::type) CompletionToken
    |                ^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/co_spawn.hpp:449:5: error:
     error: too few template arguments for concept 'completion_token_for'
        ASIO_COMPLETION_TOKEN_FOR(typename detail::awaitable_signature<
        ^
    |
449 |     ASIO_COMPLETION_TOKEN_FOR(typename detail::awaitable_signature<
    |     ^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/async_result.hpp:501:11: error:
     note: expanded from macro 'ASIO_COMPLETION_TOKEN_FOR'
      ::asio::completion_token_for<s>
              ^
    |
501 |   ::asio::completion_token_for<s>
    |           ^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/async_result.hpp:492:14: error:
     note: template is declared here
    |
492 | ASIO_CONCEPT completion_token_for =
    |              ^
ASIO_CONCEPT completion_token_for =
             ^

/Users/orel/dev/external/kmonad/In file included from c_src/mac/dext.cpp:4:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service.hpp:7:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/include/pqrs/karabiner/driverkit/virtual_hid_device_service/client.hpp:12:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/client.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/client_impl.hpp:9:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/pqrs/local_datagram/impl/asio_helper.hpp:11:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio.hpp:45:0: error:

/Users/orel/dev/external/kmonad/In file included from c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/co_spawn.hpp:467:0: error:

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/impl/co_spawn.hpp:181:22: error:
     error: no template named 'result_of'
        typedef typename result_of<F()>::type awaitable_type;
                         ^
    |
181 |     typedef typename result_of<F()>::type awaitable_type;
    |                      ^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/impl/co_spawn.hpp:265:16: error:
     error: no template named 'result_of'
          typename result_of<F()>::type>::type) CompletionToken>
                   ^
    |
265 |       typename result_of<F()>::type>::type) CompletionToken>
    |                ^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/impl/co_spawn.hpp:264:5: error:
     error: too few template arguments for concept 'completion_token_for'
        ASIO_COMPLETION_TOKEN_FOR(typename detail::awaitable_signature<
        ^
    |
264 |     ASIO_COMPLETION_TOKEN_FOR(typename detail::awaitable_signature<
    |     ^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/async_result.hpp:501:11: error:
     note: expanded from macro 'ASIO_COMPLETION_TOKEN_FOR'
      ::asio::completion_token_for<s>
              ^
    |
501 |   ::asio::completion_token_for<s>
    |           ^

/Users/orel/dev/external/kmonad/c_src/mac/Karabiner-DriverKit-VirtualHIDDevice/src/Client/vendor/include/asio/async_result.hpp:492:14: error:
     note: template is declared here
    |
492 | ASIO_CONCEPT completion_token_for =
    |              ^
ASIO_CONCEPT completion_token_for =
             ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
3 warnings and 20 errors generated.
`gcc' failed in phase `C Compiler'. (Exit code: 1)

Error: [S-7282]
       Stack failed to execute the build plan.

       While executing the build plan, Stack encountered the error:

       [S-7011]
       While building package kmonad-0.4.1 (scroll up to its section to
       see the error) using:
       /Users/orel/.stack/setup-exe-cache/aarch64-osx/Cabal-simple_6HauvNHV_<IP_ADDRESS>_ghc-8.10.7 --verbose=1 --builddir=.stack-work/dist/aarch64-osx/Cabal-<IP_ADDRESS> build lib:kmonad exe:kmonad --ghc-options " -fdiagnostics-color=always"
       Process exited with code: ExitFailure 1

Any input would be welcome, I'm banging my head against the wall at this point.

Can you try this fix? I upgraded the DriverKit-VirtualHIDDevice to v2.1.0. It works fine on my computer.

Can you try this fix? I upgraded the DriverKit-VirtualHIDDevice to v2.1.0. It works fine on my computer.

Seems to have worked by combining this and refactoring the code marked deprecated, thanks!


Waze still throws unhandled exception (but not on startup)

Home Assistant release with the issue:
0.87.1
Last working Home Assistant release (if known):
N/a, this error was supposed to be fixed with #20316 but it fixed it only for startup
Operating environment (Hass.io/Docker/Windows/etc.):
Hassbian on a Pi3B
Component/platform:
Waze Traveltime sensor
Description of problem:
Waze still throws unhandled exceptions, just not at startup anymore. I have 3 sensors set up, and I have had 2 of these exceptions in the 24 hrs that I have 0.87.1 installed. Either exception happend at different sensors - I just copied one example here. Timing seems to be random. This particular sensor uses a device tracker and a zone, but the other is a zone-to-zone (work-home) setup (so no changing coordinates or so).  It is not the same error as #20953 (even though I do see that error too at startup). This is a different error at different point in time.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
### sensors.yaml
- platform: waze_travel_time
  name: Reistijd Bob naar huis
  origin: device_tracker.bob_s9
  destination: zone.home
  region: 'EU'

Traceback (if applicable):
2019-02-13 18:55:01 ERROR (MainThread) [homeassistant.helpers.entity] Update for sensor.reistijd_bob_naar_huis fails
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/helpers/entity.py", line 221, in async_update_ha_state
    await self.async_device_update()
  File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/helpers/entity.py", line 349, in async_device_update
    await self.hass.async_add_executor_job(self.update)
  File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 56, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/util/__init__.py", line 315, in wrapper
    result = method(*args, **kwargs)
  File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/components/sensor/waze_travel_time.py", line 207, in update
    routes = params.calc_all_routes_info(real_time=self._realtime)
  File "/srv/homeassistant/lib/python3.6/site-packages/WazeRouteCalculator/WazeRouteCalculator.py", line 145, in calc_all_routes_info
    routes = self.get_route(npaths, time_delta)
  File "/srv/homeassistant/lib/python3.6/site-packages/WazeRouteCalculator/WazeRouteCalculator.py", line 95, in get_route
    response_json = response.json()
  File "/srv/homeassistant/lib/python3.6/site-packages/requests/models.py", line 897, in json
    return complexjson.loads(self.text, **kwargs)
  File "/usr/local/lib/python3.6/json/__init__.py", line 354, in loads
    return _default_decoder.decode(s)
  File "/usr/local/lib/python3.6/json/decoder.py", line 339, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/local/lib/python3.6/json/decoder.py", line 357, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Additional information:
Sensor does update itself after this error, when the new update_interval trigger is activated (no breaking-breaking error).

I am also still receiving this error, but not on startup.  I do have a thought.  I noticed that user: hmmbob also is using a device tracker as the starting point (as am I), wonder if the error is tied to the device tracker being unavailable, or reporting bad data at the time?  I dont have any waze sensors at the time that just use zones, or static coordinates.  but I'll try that out and see if the errors go away
2019-02-13 19:37:19 ERROR (MainThread) [homeassistant.helpers.entity] Update for sensor.pauls_time_to_home fails
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/helpers/entity.py", line 221, in async_update_ha_state
    await self.async_device_update()
  File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/helpers/entity.py", line 349, in async_device_update
    await self.hass.async_add_executor_job(self.update)
  File "/usr/lib/python3.6/concurrent/futures/thread.py", line 56, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/util/__init__.py", line 315, in wrapper
    result = method(*args, **kwargs)
  File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/components/sensor/waze_travel_time.py", line 207, in update
    routes = params.calc_all_routes_info(real_time=self._realtime)
  File "/srv/homeassistant/lib/python3.6/site-packages/WazeRouteCalculator/WazeRouteCalculator.py", line 145, in calc_all_routes_info
    routes = self.get_route(npaths, time_delta)
  File "/srv/homeassistant/lib/python3.6/site-packages/WazeRouteCalculator/WazeRouteCalculator.py", line 95, in get_route
    response_json = response.json()
  File "/srv/homeassistant/lib/python3.6/site-packages/requests/models.py", line 897, in json
    return complexjson.loads(self.text, **kwargs)
  File "/srv/homeassistant/lib/python3.6/site-packages/simplejson/__init__.py", line 518, in loads
    return _default_decoder.decode(s)
  File "/srv/homeassistant/lib/python3.6/site-packages/simplejson/decoder.py", line 370, in decode
    obj, end = self.raw_decode(s)
  File "/srv/homeassistant/lib/python3.6/site-packages/simplejson/decoder.py", line 400, in raw_decode
    return self.scan_once(s, idx=_w(s, idx).end())
simplejson.errors.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Nope, if you read my post carefully you will see that I reported this happens to both my device_tracker-zone sensor AND my zone-zone sensors. I just copy-pasted one of them, als the error does not differ besides the time stamp.
My guesstimate is that the Waze server is returning an empty response (for whatever reason) that is not handled correctly.

this is was happens because the waze component is starting too early, there is a fix for this problem in the way  @ https://github.com/home-assistant/home-assistant/pull/21087
Sorry about that :)

@VirtualL Sorry, but no. Please read back what I reported in the first post. This is NOT the same issue.

I think this error needs to be fixed in the waze library that home assistant uses.

OK, I checked the upstream library (https://github.com/kovacsbalu/WazeRouteCalculator), and it is at version 0.7.2 (instead of 0.6 which HA uses). It is supposed to have a few fixes, especially for the error handling.
However, pulling the sensor into a custom sensor, updating the required version of the package to 0.7.2 led me to not being able to get any route, as the routing did not accept any GPS coordinates anymore. There is a PR for the upstream package to get it to accept GPS coordinates again, but that hasn't been merged.
Reverted all my changes, back to the currently shipped version that comes with HA.


update caption

Testing av pull request
This PR fixes #7
##Done

created branch
updated the md file

##TO DO

[x] Merge changes
[x] Delete branch

cc: @ThLarsen

OK


Multiple ShinyProxy Servers estart

Accidentally posted comment while editing see below for comment.

The issue is that when we have multiple ShinyProxies running on Docker Swarm and have enabled reclaiming containers ShinyProxy grabs containers from other processes.
An additional yet related issue is that running multiple URL as endpoints on the same ShinyProxy are not supported, because landing pages are not configurable per app instance.

Hi

The issue is that when we have multiple ShinyProxies running on Docker Swarm and have enabled reclaiming containers ShinyProxy grabs containers from other processes.

If I understand correctly, you are using App Recovery? Currently it's not possible to use app recovery together with pre-initialized containers. The reason is that we cannot persist the user apps using the labels of the docker containers (since they are not really related). However, it's possible to use Redis for persisting the sessions, allowing you to restart ShinyProxy, see: https://shinyproxy.io/documentation/configuration/#session-and-app-persistence
I see we did not yet mention in the docs that app recovery isn't supported, therefore I just updated the docs. In addition the next version of ShinyProxy will produce an error when app recovery is enabled together with a pre-initialized container.

Thanks, this makes sense.


SharePoint 2016 SPFx React TypeScript Issue

I am getting an error of TypeScript 2.2.2 in SharePoint 2016.
I can install SPFx web part with No JavaScript Framework approach. And it's working fine but when I choose "React" in "yo @ microsoft/sharepoint" command then I got below error.

Hi,
Can you post your package.json?

Package JSON:
{
  "name": "fifth-wp",
  "version": "0.0.1",
  "private": true,
  "engines": {
    "node": ">=0.10.0"
  },
  "scripts": {
    "build": "gulp bundle",
    "clean": "gulp clean",
    "test": "gulp test"
  },
  "dependencies": {
    "@microsoft/sp-core-library": "~1.1.0",
    "@microsoft/sp-lodash-subset": "~1.1.0",
    "@microsoft/sp-webpart-base": "~1.1.0",
    "@types/es6-collections": "^0.5.31",
    "@types/react": "15.0.38",
    "@types/react-addons-shallow-compare": "0.14.17",
    "@types/react-addons-test-utils": "0.14.15",
    "@types/react-addons-update": "0.14.14",
    "@types/react-dom": "0.14.18",
    "@types/webpack-env": ">=1.12.1 <1.14.0",
    "react": "15.4.2",
    "react-dom": "15.4.2"
  },
  "devDependencies": {
    "@microsoft/sp-build-web": "~1.1.0",
    "@microsoft/sp-module-interfaces": "~1.1.0",
    "@microsoft/sp-webpart-workbench": "~1.1.0",
    "@types/chai": ">=3.4.34 <3.6.0",
    "@types/mocha": ">=2.2.33 <2.6.0",
    "add": "^2.0.6",
    "babel-core": "^6.26.3",
    "babel-loader": "^7.1.4",
    "babel-plugin-transform-class-properties": "^6.24.1",
    "babel-preset-env": "^1.7.0",
    "babel-preset-react": "^6.24.1",
    "gulp": "~3.9.1"
  }
}

I have created a hellowold webpart with 1.1.0 Framework, i don't have error.
My package .json :
{
  "name": "spfx",
  "version": "0.0.1",
  "private": true,
  "engines": {
    "node": ">=0.10.0"
  },
  "dependencies": {
    "@microsoft/sp-core-library": "~1.1.0",
    "@microsoft/sp-webpart-base": "~1.1.0",
    "@types/webpack-env": ">=1.12.1 <1.14.0",
    "react": "15.4.2",
    "react-dom": "15.4.2",
    "@types/react": "0.14.46",
    "@types/react-dom": "0.14.18",
    "@types/react-addons-shallow-compare": "0.14.17",
    "@types/react-addons-update": "0.14.14",
    "@types/react-addons-test-utils": "0.14.15"
  },
  "devDependencies": {
    "@microsoft/sp-build-web": "~1.1.0",
    "@microsoft/sp-module-interfaces": "~1.1.0",
    "@microsoft/sp-webpart-workbench": "~1.1.0",
    "gulp": "~3.9.1",
    "@types/chai": ">=3.4.34 <3.6.0",
    "@types/mocha": ">=2.2.33 <2.6.0"
  },
  "scripts": {
    "build": "gulp bundle",
    "clean": "gulp clean",
    "test": "gulp test"
  }
}

version of node is 6.10.3 and npm is 3.10.10

Ok Done. with latest version of node. Thank you so much for help


Full release of 0.6.0

Hi, I was wondering when you planned on cutting a full version of 0.6.x.  Pip install makes you pass in --pre for pre release versions like this - was hoping to avoid that .

Sure, I'll tag a release!

Published!


Batch update spreadsheet doesn't parse requests from json

This is my request object,
update_req = {
"requests": [
{
"insertDimension": {
"range": {
"sheetId": 0,
"dimension": "COLUMNS",
"startIndex": 2,
"endIndex": 4
},
}
},
{
"insertDimension": {
"range": {
"sheetId": 0,
"dimension": "ROWS",
"startIndex": 0,
"endIndex": 3
},
}
},
],
}
self.body = request_representation.new(request_object).to_json(skip_undefined: true)
The request object is accessible untill i do a "to_json". After i do a to_json call the object becomes null.

This seems strange. Its working when i send a request like as suggested by @sqrrrl here : https://github.com/google/google-api-ruby-client/issues/463
range = Google::Apis::SheetsV4::DimensionRange.new
    range.sheet_id =0
    range.end_index =5
    range.start_index =2
    range.dimension ='ROWS'
    ins = Google::Apis::SheetsV4::InsertDimensionRequest.new(:inherit_from_before=> true, :range => range)

    batch = Google::Apis::SheetsV4::BatchUpdateSpreadsheetRequest.new(requests: [])
    batch.requests.push(Google::Apis::SheetsV4::Request.new(insert_dimension: ins)) # Wrap in Request before adding

    service.batch_update_spreadsheet(spreadsheet_id, batch, {})

But the alternate method using hashes doesn't seem to work. Is there anything i am doing wrong ?
        "requests": [
            {
                "insertDimension": {
                    "inheritFromBefore": true,
                    "range": {
                        "sheetId": 0,
                        "dimension": "ROWS",
                        "startIndex": 0,
                        "endIndex": 3
                    }
                }
    }]
    }

See the README. When using hashes, the property names need to match the ruby style (snake case) instead of the underlying JSON format (camel case).


Enforce strict equality checking

Motivation
In a PR review, usage of non-type safe equality was spotted. Since It is a good practice to use type safe equality, this PR enforces it via linting rules and also fixes the various places in the code base non-type safe equality has been used.

Closing for now, as not priority and no consensus on the improvement the lint rule provides.


Admin Dashboard

An admin dashboard ( Django is preferred but NodeJS+ Express is welcome too) so that users can simply update the contents of the portfolio using  a GUI.
Continue this on a separate branch please

Hey, @smaranjitghose the idea sounds great, and using NodeJS + Express JS is a great way of achieving the goal. But can you tell me that alongside HTML5 and CSS3 are you using any kind of front-end frameworks like React, Angular, or Vue JS?

Hey, @smaranjitghose the idea sounds great, and using NodeJS + Express JS is a great way of achieving the goal. But can you tell me that alongside HTML5 and CSS3 are you using any kind of front-end frameworks like React, Angular, or Vue JS?

Yes. Once the frontend is finalized we will shift to React

@smaranjitghose, you'll also require a database to store the users, and then some kind of authentication will be necessary so one user cannot change the contents of the other user's portfolio.

@shreyakapoor08

@smaranjitghose, you'll also require a database to store the users, and then some kind of authentication will be necessary so one user cannot change the contents of the other user's portfolio.

Since this is portfolio website so only the user for whom the website is made will be handling the dashboard, unless specifically required, we do not give access to our personal websites to someone else

@smaranjitghose, what contents of the portfolio will be managed by the dashboard?

@smaranjitghose, what contents of the portfolio will be managed by the dashboard?

Basically, most of the data we are entering as a JSON in our JS files

Can I work on this issue? @smaranjitghose sir? Making this admin panel?

Can I work on this issue? @smaranjitghose sir? Making this admin panel?


[feaLib] handling of mixed single and multiple or ligature substitutions

If I have a feature like this:
feature isol {
 sub a by A;
 sub b by B C;
} isol;

feaLib will generate two lookups, a single substitution lookup and a multiple substitution one. But IMO it should have been a single multiple substitution lookup, as the first rule can be seen as a multiple substitution lookup with just one replacement glyph. The same happens when mixing single substitutions with ligature substitutions.
In many of my fonts this results in 10s of lookups which can slow the OpenType layout processing in some implementations. It does not help that the feature syntax does not provide any way to make this explicit, since the three different substitution subtypes use the same syntax.
It gets even worse with named lookups, a lookup like this will not even compile:
lookup isol0 {
 sub a by A;
 sub b by B C;
} isol0;

FontForge used to handle this gracefully and guess the right lookup type in these situations. I didn’t check with FDK does here.

Currently, it seems that feaLib and FDK produce identical output for these snippets. But of course that doesn’t mean they absolutely have to: feaLib could certainly make optimizations which makeotf doesn’t make, as long as everyone conforms to the published specification. However, it would add friction for font designers if a given feature file is accepted by some implementations but rejected by others.
Here’s the output from running makeotf v2.0.90 on the first example:
<?xml version="1.0" encoding="UTF-8"?>
<ttFont sfntVersion="true" ttLibVersion="3.0">

  <GSUB>
    <Version value="1.0"/>
    <ScriptList>
      <!-- ScriptCount=1 -->
      <ScriptRecord index="0">
        <ScriptTag value="DFLT"/>
        <Script>
          <DefaultLangSys>
            <ReqFeatureIndex value="65535"/>
            <!-- FeatureCount=1 -->
            <FeatureIndex index="0" value="0"/>
          </DefaultLangSys>
          <!-- LangSysCount=0 -->
        </Script>
      </ScriptRecord>
    </ScriptList>
    <FeatureList>
      <!-- FeatureCount=1 -->
      <FeatureRecord index="0">
        <FeatureTag value="isol"/>
        <Feature>
          <!-- LookupCount=2 -->
          <LookupListIndex index="0" value="0"/>
          <LookupListIndex index="1" value="1"/>
        </Feature>
      </FeatureRecord>
    </FeatureList>
    <LookupList>
      <!-- LookupCount=2 -->
      <Lookup index="0">
        <!-- LookupType=1 -->
        <LookupFlag value="0"/>
        <!-- SubTableCount=1 -->
        <SingleSubst index="0">
          <Substitution in="a" out="A"/>
        </SingleSubst>
      </Lookup>
      <Lookup index="1">
        <!-- LookupType=2 -->
        <LookupFlag value="0"/>
        <!-- SubTableCount=1 -->
        <MultipleSubst index="0">
          <Substitution in="b" out="B,C"/>
        </MultipleSubst>
      </Lookup>
    </LookupList>
  </GSUB>

</ttFont>

For the second example, makeotf v2.0.90 rejects it (just like feaLib), printing this error: “Lookup type different from previous rules in this lookup block”.

This might be related to a limitation in some font shaper.
Le sam. 28 mai 2016 20:15, Sascha Brawer<EMAIL_ADDRESS>a
écrit :

Currently, it seems that feaLib and FDK produce identical output for these
snippets. But of course that doesn’t mean they absolutely have to: feaLib
could certainly make optimizations which makeotf doesn’t make, as long as
everyone conforms to the published specification. However, it would add
friction for font designers if a given feature file is accepted by some
implementations but rejected by others.
Here’s the output from running makeotf v2.0.90 on the first example:

For the second example, makeotf v2.0.90 rejects it (just like feaLib),
printing this error: “Lookup type different from previous rules in this
lookup block”.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/behdad/fonttools/issues/612#issuecomment-222325092,
or mute the thread
https://github.com/notifications/unsubscribe/AB1ao7keBKE6oCDmiID3hB-_yCvmM_W8ks5qGJRpgaJpZM4IpH-8
.

VOLT also creates such lookups, so I think it is unlikely that there is a problem in applying such lookups. Anyway, it shouldn’t be the compiler job to decide which kinds of lookups are allowed or not and currently the syntax does not provide any other way to handle such mixed lookups. Working around this is easy for single substitutions, but things gets complex for contextual substitutions that reference other lookups since splitting such a lookup into two will complicate things needlessly.
So the question now is, should we just do what FontForge did since the spec is silent about this (AFAICT) or raise the issue with AFDKO first?

@readroberts, what do you think? (See bug history for context).

The current implementation of feaLib and the FDK are at least consistent.   A lookup can contain only one type of rule (excepting kerning) and mixed rules are handled only by isolating them in separate lookups. This can't be done in named lookups, since a named lookup can be only a single lookup.
I agree that the 'isol' feature example shows a case where it would be useful to deal with mixed rules by promoting single substitution rules to more complex substitution rules in order to avoid a proliferation of lookups,  and that this points to a need for a change in the feature file spec to support this. If anyone has any good ideas, let's hear them. I do not favor having to add something to each rule to force it be a particular type. I am a little leery of having the implementation silently change rule types.  My best idea so far is to add an attribute keyword for a feature or lookup that specifies the common substitution type to which all rules should be promoted, if possible.  The could be a new keyword/value pair like "preferredRuleType oneToMany;". Any rule than cannot be promoted to the preferredRuleType wold be handled by starting a new lookup, as with the current logic.

I think a lookuptype keyword (similar to lookupflag can be introduced) and then any rule that can not be expressed in this type should cause an error. When such keyword is missing, then the current behaviour is assumed.

Here is another case, so that all cases are considered.
lookup foo {
 sub a by A;
 sub b by B C;
} foo;

feature calt {
 sub c [a b]' lookup foo;
} calt;

With current FDK/feaLib, we will need two lookups which means duplicating the rule, and for complex substitution this can quickly complicate things greatly.

My preference is that the compiler silently chooses the right lookup type.  The font designer doesn't care how the substitution is done as long as it does exactly what they specify.

Well, a given feature file should either work across all compilers, or (in case of invalid input) every compiler should equally reject it. Without consistency across tools, font designers won’t be happy people. The problem is named lookup blocks, whose subtables must all have the same type. Should the following be valid? Depending on what lookup type the compiler happens to pick, the feature file becomes invalid or not. That’s why choosing lookup types isn’t just a silent optimization.
lookup foo {
  sub a by A;
  sub b by B C;
} foo;

Actually, just wondering: couldn’t this be handled by constraint resolution? In a first pass over a named lookup block, compilers would identify for each statement a set of potential lookup types. If the intersection of these sets becomes empty, compilers would reject the feature file as invalid. In a second pass, compilers would generate the subtables, using one of the lookup types in the intersection set. Apart from optimization, it wouldn’t really matter which lookup type the compiler has picked. — Admittedly, this would be a little complicated for compiler writers (basically, @readroberts and me). But we wouldn’t have to add new keywords to an already complicated language.
Whatever we do, I think it should be clearly decidable (without ambiguity) from the language specification whether a given feature file is valid. Otherwise, we’ll have an interoperability nightmare.

The font designer doesn't care how the substitution is done as long as it does exactly what they specify.

Some font designers do care, and not being informed that something was changed or implemented in a certain way behind the scenes can lead to a lot of frustration when differences arise between what the designer/developer expected from the code and what results they're getting (on e.g. an app).
I'm all for un-complicating things that are simple, but I'm leery of tools that are too helpful because there will be times when they make the wrong assumptions/decisions and if the designer/developer grows accustomed to being shielded from understanding what and how the tool is doing for him/her, it will eventually become an unwieldy tool.

Some font designers do care, and not being informed that something was changed or implemented in a certain way behind the scenes can lead to a lot of frustration when differences arise between what the designer/developer expected from the code and what results they're getting (on e.g. an app).
I'm all for un-complicating things that are simple, but I'm leery of tools that are too helpful because there will be times when they make the wrong assumptions/decisions and if the designer/developer grows accustomed to being shielded from understanding what and how the tool is doing for him/her, it will eventually become an unwieldy tool.

To me, it sounds like you are saying "designers have had bad experiences with bad tools in the past, so let's not make tools smart".  I disagree.  We should make great tools that simplify things for designers; I don't think we should expose more low-level details to designers.

Actually, just wondering: couldn’t this be handled by constraint resolution? In a first pass over a named lookup block, compilers would identify for each statement a set of potential lookup types.

Yes, that's what Khaled and I have been suggesting.

To me, it sounds like you are saying "designers have had bad experiences with bad tools in the past, so let's not make tools smart". I disagree. We should make great tools that simplify things for designers; I don't think we should expose more low-level details to designers.

Another view: having this be explicit means that the designer can know what is happening with the lookup when they encounter an issue with a rendering engine/application and can work around possible bugs in said hypothetical engine/application. Much like useExtension: the designer can choose to use this if they want explicitly, knowing what it will mean for application support, rather than having it be applied automagically and then being left to wonder why something isn't working in an application.

@behdad what @benkiel said

Only if figuring out "why it doesn't work in X app" was so simple :).

Automagical features tend to create a debt of understanding in the future.

Only if figuring out "why it doesn't work in X app" was so simple :).

A reason to not make it more complicated.

I don’t see where is all the magic that is hidden from the user here:
feature foo {
sub a by A;
sub b by B A;
sub c by C;
sub d by D B A;
} foo;

The lookup above is clearly multiple substitution lookup, with some entries substituting to a single glyph. There is no more magic here than FDK deciding to split this into 4 lookups behind the type designer’s back. IMO the fact that FDK does not support such multiple substitution lookups is a bug/limitation since it does not provide any other way to have such a perfectly legit OpenType lookup.

Yes, I think the intended semantics of your snippet is quite obvious. What I’m less sure about is how to amend the OpenType Feature File specification, so that it’s unambiguously clear to compiler writers that your snippet is valid syntax—even when it’s part of a named lookup block. Maybe @readroberts sees a way for writing this down in the spec?

Which will be silently reorder by FDK.

Are you sure?

This is clearly written in the spec, and I tried it with makeotf before posting to be sure.

I didn't know it was in the spec and neither was aware that makeotf worked that way :grinning:


Where is the source of mexResize

As the title.

Writing instruction in readme.
Cheers
On Thu, Jan 12, 2017 at 12:59 PM, Siyuan Ren<EMAIL_ADDRESS>wrote:

As the title.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bertinetto/staple/issues/2, or mute the thread
https://github.com/notifications/unsubscribe-auth/ADLRuXgPzhh_7r3-Z7LGZAMhxhW4GdVDks5rRiOYgaJpZM4LhuOK
.


Added video

Fixes:  #2372
Description
Added video in about us section about Swapreads
Type of PR

[x] Feature enhancement

Screenshots / videos (if applicable)

Checklist:

[x] I have made this change from my own.
[ ] I have taken help from some online resources.
[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers and screenshots after making the changes.

nice