error: unknown target triple 'xtensa', please use -triple or -arch

I followed the instructions on https://github.com/esp-rs/rust-build and made a project with:
# STD Project
cargo generate esp-rs/esp-idf-template cargo

No mater if I compile with cargo build or if I use cargo espflash save-image --chip esp32 test
I get the following error message.
Rust is know for it's helpful error messages but in this case I get a bunch of messages but I don't know what they want to tell me...
A bunch of Env-Vars, CMake-Vars bla, bla, but what is right and what's wrong in this incredible complex build environmen????
The last lines of the error message shows that some flags are wrong or missing - OK, maybe, but where should I set the flags?
Please help!
cargo espflash save-image --chip esp32 test
   Compiling esp-idf-sys v0.33.2
error: failed to run custom build command for `esp-idf-sys v0.33.2`

Caused by:
  process didn't exit successfully: `/Volumes/DevLocal/DevRust/Learn/esp32-v2/target/debug/build/esp-idf-sys-6aca48eb5088c401/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=ESP_IDF_TOOLS_INSTALL_DIR
  cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG
  cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG_DEFAULTS
  cargo:rerun-if-env-changed=MCU
  cargo:rerun-if-env-changed=ESP_IDF_SYS_ROOT_CRATE
  cargo:rerun-if-env-changed=ESP_IDF_VERSION
  cargo:rerun-if-env-changed=ESP_IDF_REPOSITORY
  cargo:rerun-if-env-changed=ESP_IDF_CMAKE_GENERATOR
  cargo:rerun-if-env-changed=IDF_PATH
  cargo:rerun-if-env-changed=EXTRA-COMPONENTS
  cargo:rerun-if-env-changed=ESP_IDF_COMPONENTS
  IDF_PYTHON_ENV_PATH=/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/python_env/idf4.4_py3.11_env
  PATH=/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/tools/xtensa-esp32-elf/esp-2021r2-patch5-8.4.0/xtensa-esp32-elf/bin:/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/tools/esp32ulp-elf/2.35_20220830/esp32ulp-elf/bin:/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/tools/cmake/3.23.1/CMake.app/Contents/bin:/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/tools/ninja/1.10.2/:/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/python_env/idf4.4_py3.11_env/bin:/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/tools:$PATH
  Current system platform: macos-arm64
  Skipping<EMAIL_ADDRESS>(already installed)
  Skipping<EMAIL_ADDRESS>(already installed)
  Skipping<EMAIL_ADDRESS>(already installed)
  Skipping<EMAIL_ADDRESS>(already installed)
  IDF_PYTHON_ENV_PATH=/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/python_env/idf4.4_py3.11_env
  PATH=/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/tools/xtensa-esp32-elf/esp-2021r2-patch5-8.4.0/xtensa-esp32-elf/bin:/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/tools/esp32ulp-elf/2.35_20220830/esp32ulp-elf/bin:/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/tools/cmake/3.23.1/CMake.app/Contents/bin:/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/tools/ninja/1.10.2/:/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/python_env/idf4.4_py3.11_env/bin:/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/tools:$PATH
  cargo:rerun-if-changed=/Volumes/DevLocal/DevRust/Learn/esp32-v2/sdkconfig.defaults
  CMAKE_PREFIX_PATH_xtensa-esp32-espidf = None
  CMAKE_PREFIX_PATH_xtensa_esp32_espidf = None
  TARGET_CMAKE_PREFIX_PATH = None
  CMAKE_PREFIX_PATH = None
  CMAKE_xtensa-esp32-espidf = None
  CMAKE_xtensa_esp32_espidf = None
  TARGET_CMAKE = None
  CMAKE = None
  running: cd "/Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out/build" && CMAKE_PREFIX_PATH="" EXTRA_COMPONENT_DIRS="" IDF_PATH="/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6" IDF_TARGET="esp32" IDF_TOOLS_PATH="/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif" PATH="/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/python_env/idf4.4_py3.11_env/bin:/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/tools/cmake/3.23.1/CMake.app/Contents/bin:/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/tools/ninja/1.10.2/:/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/tools:/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/tools/esp32ulp-elf/2.35_20220830/esp32ulp-elf/bin:/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/tools/xtensa-esp32-elf/esp-2021r2-patch5-8.4.0/xtensa-esp32-elf/bin:/Users/mikemitterer/.local/bin:/usr/local/sbin:/opt/homebrew/opt/openjdk@17/bin:/Volumes/DevLocal/DevPython/Production/Utils/src/main/bash:/Volumes/DevLocal/DevPython/Production/Utils/src/main/python:/Volumes/DevLocal/DevBash/Production/BashTools/src:/Users/mikemitterer/bin:/Applications/Sublime Text.app/Contents/SharedSupport/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Users/mikemitterer/.cargo/bin:/Users/mikemitterer/Library/Application Support/JetBrains/Toolbox/scripts:/Users/mikemitterer/Library/Android/sdk/platform-tools:/Users/mikemitterer/Library/Android/sdk/emulator:/Users/mikemitterer/Library/Android/sdk/tools/bin:./node_modules/.bin:/Users/mikemitterer/.yarn/bin:/Users/mikemitterer/.config/yarn/global/node_modules/.bin:/Users/mikemitterer/bin/fmpp_0.9.15/bin::/Users/mikemitterer/.cargo/bin:/Users/mikemitterer/Library/Python/3.11/bin" SDKCONFIG_DEFAULTS="/Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out/gen-sdkconfig.defaults;/Volumes/DevLocal/DevRust/Learn/esp32-v2/sdkconfig.defaults" "cmake" "/Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out" "-G" "Ninja" "-DCMAKE_TOOLCHAIN_FILE=/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/tools/cmake/toolchain-esp32.cmake" "-DCMAKE_BUILD_TYPE=" "-DPYTHON=/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/python_env/idf4.4_py3.11_env/bin/python" "-DCMAKE_INSTALL_PREFIX=/Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out" "-DCMAKE_C_FLAGS= -mlongcalls -Wno-frame-address -ffunction-sections -fdata-sections" "-DCMAKE_CXX_FLAGS= -mlongcalls -Wno-frame-address -ffunction-sections -fdata-sections" "-DCMAKE_ASM_FLAGS= -mlongcalls -ffunction-sections -fdata-sections"
  -- Checking Python dependencies...
  Python requirements from /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/requirements.txt are satisfied.
  -- Project sdkconfig file /Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out/sdkconfig
  Loading defaults file /Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out/gen-sdkconfig.defaults...
  Loading defaults file /Volumes/DevLocal/DevRust/Learn/esp32-v2/sdkconfig.defaults...
   "--config" "MinSizeRel" "--parallel" "10"
  [1/7] Generating ld/sections.ld
  [2/7] Performing build step for 'bootloader'
  [0/1] Re-running CMake...
  -- Building ESP-IDF components for target esp32
  -- Project sdkconfig file /Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out/sdkconfig
  -- Adding linker script /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/soc/esp32/ld/esp32.peripherals.ld
  -- Adding linker script /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/esp_rom/esp32/ld/esp32.rom.ld
  -- Adding linker script /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/esp_rom/esp32/ld/esp32.rom.api.ld
  -- Adding linker script /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/esp_rom/esp32/ld/esp32.rom.libgcc.ld
  -- Adding linker script /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/esp_rom/esp32/ld/esp32.rom.newlib-funcs.ld
  -- Adding linker script /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/bootloader/subproject/main/ld/esp32/bootloader.ld
  -- Adding linker script /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/bootloader/subproject/main/ld/esp32/bootloader.rom.ld
  -- Components: bootloader bootloader_support efuse esp32 esp_common esp_hw_support esp_rom esp_system esptool_py freertos hal log main micro-ecc newlib partition_table soc spi_flash xtensa
  -- Component paths: /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/bootloader /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/bootloader_support /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/efuse /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/esp32 /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/esp_common /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/esp_hw_support /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/esp_rom /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/esp_system /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/esptool_py /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/freertos /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/hal /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/log /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/bootloader/subproject/main /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/bootloader/subproject/components/micro-ecc /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/newlib /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/partition_table /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/soc /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/spi_flash /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/xtensa
  -- Configuring done
  -- Generating done
  -- Build files have been written to: /Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out/build/bootloader
  [1/1] cd /Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out/build/bootloader/esp-idf/esptool_py && /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/python_env/idf4.4_py3.11_env/bin/python /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/partition_table/check_sizes.py --offset 0x8000 bootloader 0x1000 /Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out/build/bootloader/bootloader.bin
  Bootloader binary size 0x6430 bytes. 0xbd0 bytes (11%) free.
  [3/5] Linking C executable libespidf.elf
  [4/5] Generating binary image from built executable
  esptool.py v3.3.4-dev
  Creating esp32 image...
  Merged 2 ELF sections
  Successfully created esp32 image.
  Generated /Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out/build/libespidf.bin
  [5/5] cd /Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out/build/esp-idf/esptool_py && /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/python_env/idf4.4_py3.11_env/bin/python /Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6/components/partition_table/check_sizes.py --offset 0x8000 partition --type app /Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out/build/partition_table/partition-table.bin /Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out/build/libespidf.bin
  libespidf.bin binary size 0x27c00 bytes. Smallest app partition is 0x100000 bytes. 0xd8400 bytes (84%) free.
  cargo:root=/Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out
  cargo:rerun-if-changed=/Users/mikemitterer/.cargo/registry/src/index.crates.io-6f17d22bba15001f/esp-idf-sys-0.33.2/src/include/esp-idf/bindings.h
  cargo:rustc-env=EMBUILD_GENERATED_BINDINGS_FILE=/Volumes/DevLocal/DevRust/Learn/esp32-v2/target/xtensa-esp32-espidf/debug/build/esp-idf-sys-da73dfd7aaa6214c/out/bindings.rs

  --- stderr
  Build configuration: BuildConfig {
      esp_idf_tools_install_dir: None,
      esp_idf_sdkconfig: None,
      esp_idf_sdkconfig_defaults: None,
      mcu: None,
      native: NativeConfig {
          esp_idf_version: Some(
              Tag(
                  "v4.4.6",
              ),
          ),
          esp_idf_repository: None,
          esp_idf_cmake_generator: None,
          idf_path: None,
          extra_components: [],
          esp_idf_components: None,
      },
      esp_idf_sys_root_crate: None,
  }
  Using managed esp-idf repository: RemoteSdk { repo_url: None, git_ref: Tag("v4.4.6") }
  Using esp-idf v4.4.6 at '/Volumes/DevLocal/DevRust/Learn/esp32-v2/.embuild/espressif/esp-idf/v4.4.6'
  Built components: esp_ringbuf, efuse, esp_ipc, driver, esp_pm, mbedtls, bootloader, esptool_py, partition_table, app_update, bootloader_support, spi_flash, nvs_flash, pthread, esp_gdbstub, espcoredump, esp_phy, esp_system, esp_rom, hal, vfs, esp_eth, tcpip_adapter, esp_netif, esp_event, wpa_supplicant, esp_wifi, ieee802154, console, openthread, lwip, log, heap, soc, esp_hw_support, xtensa, esp32, esp_common, esp_timer, freertos, newlib, cxx, app_trace, asio, bt, cbor, unity, cmock, coap, nghttp, esp-tls, esp_adc_cal, esp_hid, tcp_transport, esp_http_client, esp_http_server, esp_https_ota, esp_https_server, esp_lcd, protobuf-c, protocomm, mdns, esp_local_ctrl, sdmmc, esp_serial_slave_link, esp_websocket_client, expat, wear_levelling, fatfs, freemodbus, idf_test, jsmn, json, libsodium, mqtt, openssl, perfmon, spiffs, usb, tinyusb, ulp, wifi_provisioning
  error: unknown target triple 'xtensa', please use -triple or -arch
  thread 'main' panicked at 'libclang error; possible causes include:
  - Invalid flag syntax
  - Unrecognized flags
  - Invalid flag arguments
  - File I/O errors
  - Host vs. target architecture mismatch
  If you encounter an error missing from this list, please file an issue or a PR!', /Users/mikemitterer/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bindgen-0.63.0/ir/context.rs:530:15
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Did you forget to run ./export-esp.sh prior to building?

And by the way, and because you mention again how helpful Rust is

Rust is know for it's helpful error messages but in this case I get a bunch of messages but I don't know what they want to tell me...

... well, this panic is coming from Rust bindgen. And it is extremely unhelpful. Yeah, it is not us.
I'll think how (actually if possible at all) to capture this panic and print something meaningful. The crux of the problem is that you are running the wrong Clang (your system one), which does not know that "xtensa" arch exists, as the xtensa arch is not upstreamed yet - neither in Rust, nor in Clang (as these share a common backend - LLVM).
The other problem you complained about in that other thread (the env vars thing) is also an upstream problem - in cmake-rs. Which is in the rust-lang org, if you notice. I could not find a way to tell cmake-rs NOT to pick env vars from the parent process (us).
So where I'm getting at is that the build is complex, but it is not always us. :)

@MikeMitterer
Can you try:
cargo install espup
espup install

$HOME/export-esp.sh
cargo build

Only ~/export-esp.sh is necessary.
@SergioGasquez This is really a total PITA. Remember this?

Only ~/export-esp.sh is necessary.
@SergioGasquez This is really a total PITA. Remember this?

I'll probably bring this for discussion on the next meeting (if I'm able to attend, that is). Or at least leave a reminder about it in the Discussion notes.
I mean, I can try to check for the xtensa Clang lib being on the path when building esp-idf-sys, from within the esp-idf-sys build, yet having the requirement to the user to run this export script is one more variable in an already complex equation.

Aaaargh.
@hanusek @MikeMitterer Note that the correct command line (at least on Linux) is:
. ~/export-esp.sh
Just doing ~/export-esp.sh (without the "." and space after it) will not do it, as the file seems not to be a real shell script (and its not marked as executable anyway) but just a "variables" source script!
@SergioGasquez Was this always the case, or was this changed just recently?

For no_std - yes. The clang lib (which is the culprit) and which is the one thing causing headaches for STD builds needs to be around for the foreseeable future. We don't need the GCC linker. This is only for no_std.

Right, not sure if you know, and also its definitely not a solution but something that can simplify stuff for std ONLY users, is using the -s/--std flag of espup which skips installing GCC.

Right, not sure if you know, and also its definitely not a solution but something that can simplify stuff for std ONLY users, is using the -s/--std flag of espup which skips installing GCC.

This is not simplifying anything. We don't use the espup GCC, and we don't care about it, in the path or not. What we need is ONLY the LIBCLANG_PATH variable. Setup correctly and ideally without a source script users will keep forgetting about.

And by the way, at the very least we should be improving the message espup spits out w.r.t. export-esp.sh:

It is an info log (extra noise). Why?
It is together with a bunch of other info logs on the console, and difficult to spot. And this is the ONE thing users should not be forgetting to do... :(

This is not simplifying anything. We don't use the espup GCC, and we don't care about it, in the path or not. What we need is ONLY the LIBCLANG_PATH variable. Setup correctly and ideally without a source script users will keep forgetting about.

But even if espup GCC is not used, is still downloaded and installed by espup unless you used that flag. I think setting LIBCLANG_PATH automatically can be an improvement. What if we set LIBCLANG_PATH in all environments (that means setting it on Unix as its already set for Windows) and we leave the export-esp.sh to only modify the PATH (this would only be required for no_std users on Unix)

And by the way, at the very least we should be improving the message espup spits out w.r.t. export-esp.sh:
It is an info log (extra noise). Why?
It is together with a bunch of other info logs on the console, and difficult to spot. And this is the ONE thing users should not be forgetting to do... :(

The message saying that you need to source the export file is a warn, this is the usual output in Unix:
[2023-10-11T08:26:49Z INFO ] 🔧  Uncompressing tar.xz file to '/home/esp/.rustup/tmp/.tmpWECcbn'
[2023-10-11T08:26:49Z INFO ] 🔧  Installing 'rust-src' component for Xtensa Rust toolchain
[2023-10-11T08:27:35Z INFO ] 🔧  Creating export file
[2023-10-11T08:27:35Z WARN ] 💡  Please, set up the environment variables by running: ' /home/esp/export-esp.sh'
[2023-10-11T08:27:35Z WARN ] ⚠   This step must be done every time you open a new terminal
[2023-10-11T08:27:35Z INFO ] ✅  Installation successfully completed!

Also, in all the installation guides, we mention that Unix users must source the export file, not sure how this can be improved, any suggestion?

But it's a bunch of logs still. Why? This is not a service or a firmware. Look at rustup. It does NOT spit out logs, with long timestamps, icons, level whatever - all that noise. Just the essence. And in this essence, the fact that there is something environment related that the user has to pay attention to is the most important, LAST message, on a separate li e and so on. Readable.

Here is the output of doing curl https://sh.rustup.rs -sSf | bash -s -- -y
info: installing component 'rust-std'
 24.7 MiB /  24.7 MiB (100 %)  17.2 MiB/s in  1s ETA:  0s
info: installing component 'rustc'
 61.6 MiB /  61.6 MiB (100 %)  18.9 MiB/s in  3s ETA:  0s
info: installing component 'rustfmt'
info: default toolchain set to 'stable-x86_64-unknown-linux-gnu'

  stable-x86_64-unknown-linux-gnu installed - rustc 1.73.0 (cc66ad468 2023-10-03)

Rust is installed now. Great!

To get started you may need to restart your current shell.
This would reload your PATH environment variable to include
Cargo's bin directory ($HOME/.cargo/bin).

To configure your current shell, run:
source "$HOME/.cargo/env"

I created https://github.com/SergioGasquez/espup/tree/feat/environment with some changes to the logs and here is what the output of this branch looks like:
[INFO]: 📥  Downloading file '/home/esp/.rustup/tmp/.tmp6taYwd/rust-src.tar.xz' from 'https://github.com/esp-rs/rust-build/releases/download/v<IP_ADDRESS>/rust-src-<IP_ADDRESS>.tar.xz'
[INFO]: 🔧  Extracting tar.xz file to '/home/esp/.rustup/tmp/.tmp6taYwd'
[INFO]: 🔧  Installing 'rust-src' component for Xtensa Rust toolchain
[INFO]: 🔧  Creating export file

        💡  To get started, you need to set up some environment variables by running: '. /home/esp/export-esp.sh'
        ⚠  This step must be done every time you open a new terminal.
            See other methods for setting the environment in https://esp-rs.github.io/book/installation/riscv-and-xtensa.html#3-set-up-the-environment-variables
[INFO]: ✅  Installation successfully completed!

Also, I opened https://github.com/esp-rs/espup/pull/373, which simplifies the amount of environment variables that we need to set up. This would be the resulting export-esp.sh:
export LIBCLANG_PATH="/home/esp/.rustup/toolchains/esp/xtensa-esp32-elf-clang/esp-16.0.0-20230516/esp-clang/lib"
export PATH="$HOME/.rustup/toolchains/esp/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin:$PATH"
export PATH="/$HOME/.rustup/toolchains/esp/riscv32-esp-elf/esp-13.2.0_20230928/riscv32-esp-elf/bin:$PATH"

We can continue the discussion on the community meeting, but I am happy to set up those variables in espup or at least set the LIBCLANG_PATH since its less “sensitive” than modifying the user PATH

I created esp-rs/espup#375 with some changes to the logs and here is what the output of this branch looks like:
[INFO]: 📥  Downloading file '/home/esp/.rustup/tmp/.tmp6taYwd/rust-src.tar.xz' from 'https://github.com/esp-rs/rust-build/releases/download/v<IP_ADDRESS>/rust-src-<IP_ADDRESS>.tar.xz'
[INFO]: 🔧  Extracting tar.xz file to '/home/esp/.rustup/tmp/.tmp6taYwd'
[INFO]: 🔧  Installing 'rust-src' component for Xtensa Rust toolchain
[INFO]: 🔧  Creating export file

        💡  To get started, you need to set up some environment variables by running: '. /home/esp/export-esp.sh'
        ⚠  This step must be done every time you open a new terminal.
            See other methods for setting the environment in https://esp-rs.github.io/book/installation/riscv-and-xtensa.html#3-set-up-the-environment-variables
[INFO]: ✅  Installation successfully completed!

This is a great improvement, thank you! Would it be possible to put the "To get started, you need..." text as the last step / log in the sequence? Basically after "Installation successfully completed!". This way - and similarly to rustup - it will be the last thing, and the one action item user needs to care about (on a regular basis).
I guess I'm nit-picking (removing the timestamp was already a big improvement), but do we need the icons? They look cool, but are yet another distraction imo. And [INFO] can be lowercased so it is less into the eyes, like e.g. info:.

export LIBCLANG_PATH="/home/esp/.rustup/toolchains/esp/xtensa-esp32-elf-clang/esp-16.0.0-20230516/esp-> ```

We can continue the discussion on the community meeting, but I am happy to set up those variables in `espup` or at least set the `LIBCLANG_PATH` since its less “sensitive” than modifying the user `PATH`

That would be absolutely great, but I suggest rather than putting the variable in ~/.profile (or whatever), can't we source the export-esp.sh script from there? My concern is what happens when the user upgrades to a new version of the toolchain, and the value of this variable changes? You need to grep the var in the ~./profile file and change it, which is risky. Far better to reference export-esp.sh from there. And perhaps rename it to env (it is not a real .sh, is it?) and move it inside .espup.

@SergioGasquez How about the following alternative proposal that completely bypasses altering the user's environment:

Create a symlink - $HOME/.espup/libclang_path - that points to the actual directory where the Espressif xtensa liobclang directory is located (as it can change if you upgrade the toolchain with espup)
esp-idf-sys should be altered to look for the presence of $HOME/.espup/libclang_path and use that if available, or else fallback to the standard mechanism bindgen uses to locate libclang. This can optionally only be done when building for xtensa targets

This way we kinda get the best of both worlds:

Easy way to find the Clang lib location (if installed via espup)
No pollution of user's env
Might even work on Windows? Not sure we can symlink there these days?

Sure, no_std users would still have to suffer with the export-esp.sh script for a while, but that's only because of GCC, and as you say - temporary.

This is a great improvement, thank you! Would it be possible to put the "To get started, you need..." text as the last step / log in the sequence? Basically after "Installation successfully completed!". This way - and similarly to rustup - it will be the last thing, and the one action item user needs to care about (on a regular basis).
I guess I'm nit-picking (removing the timestamp was already a big improvement), but do we need the icons? They look cool, but are yet another distraction imo. And [INFO] can be lowercased so it is less into the eyes, like e.g. info:.

Thanks for the feedback! This is how it currently looks like:
[warn]: ⚠   Previous installation of Xtensa Rust <IP_ADDRESS> exists in: '/home/esp/.rustup/toolchains/esp'. Reusing this installation
[info]: 🔧  Creating export file
[info]: ✅  Installation successfully completed!

        💡  To get started, you need to set up some environment variables by running: '. /home/esp/export-esp.sh'
        ⚠   This step must be done every time you open a new terminal.
            See other methods for setting the environment in https://esp-rs.github.io/book/installation/riscv-and-xtensa.html#3-set-up-the-environment-variables

Will think about removing the emojis and the environment variables next week (I'm on vacations until then). And thanks again for all the alternatives!

@ivmarkov F...  + SORRY because of another problem . ~/export-esp.sh was not called and caused all the error messages. Thanks for pointing me to the right direction.
@all here in the discussion - Thanks! It's really cool to see how you improve the logs and the whole environment to make the Rust environment, and it's toolchain even more helpful!!!!

Will think about removing the emojis and the environment variables next week (I'm on vacations until then). And thanks again for all the alternatives!

Seems like symbolic links require admin privileges / developer mode on Windows.
Well I guess on Windows the %HOME%\.espup\esp-clang-lib sym link can just be a copy of the actual directory - %HOME%\.rustup\toolchains\esp\xtensa-esp32-elf-clang\esp-16.0.0-20230516\esp-clang\lib
no?

(Will keep this open, but renamed the issue to reflect where we got after discussing.)

Might even work on Windows? Not sure we can symlink there these days?

Windows should have this issue already solved, we don't need to source the export-esp.sh file on Windows, we modify the environment variables.

Sure, no_std users would still have to suffer with the export-esp.sh script for a while, but that's only because of GCC, and as you say - temporary.

Even when we use LLD as linker, we would still need to set LIBCLANG_PATH, so we would still require the sourcing.
Here is how rustup modifies the PATH: https://github.com/rust-lang/rustup/blob/master/src/cli/self_update/unix.rs#L83

Might even work on Windows? Not sure we can symlink there these days?

Windows should have this issue already solved, we don't need to source the export-esp.sh file on Windows, we modify the environment variables.

OK, fine. I don't like it because we then do different things for different OS-es, but even if we have the symlink for non-Windows, that would be a step forward.

Sure, no_std users would still have to suffer with the export-esp.sh script for a while, but that's only because of GCC, and as you say - temporary.
Even when we use LLD as linker, we would still need LIBCLANG_PATH, so we would still require the sourcing.

Here is how rustup modifies the PATH: https://github.com/rust-lang/rustup/blob/master/src/cli/self_update/unix.rs#L83

No. The idea of the symlink is that esp-idf-sys would detect it and it will itself setup LIBCLANG_PATH prior to calling bindgen.
If you don't like the symlink idea - fine - just modify the user's env on ALL operating systems. Even though this is polluting the user env, which was the primary reason I came up with the sourcing link - it is something ONLY esp-idf-sys needs to know and use so a symlink is less obtrusive.
But having this "sourcing" for non-Windows is really, really hurting the initial user experience. I absolutely want to avoid this extra step.

Im just working on releasing espup 0.7.0 with GCC 13 (less environment variables to set) and updated logging, since we are probably releasing a <IP_ADDRESS> Xtensa Rust version. After that I will start working in removing the export file one way or another, also, if we go for the environment approach, we should add a no-modify-env flag

Im just working on releasing espup 0.7.0 with GCC 13 (less environment variables to set) and updated logging, since we are probably releasing a <IP_ADDRESS> Xtensa Rust version. After that I will start working in removing the export file one way or another, also, if we go for the environment approach, we should add a no-modify-env flag

Sounds great. If you would like to minimize any changes / impact, we can have the symlink in addition to / without retiring the export file for now. That would be enough for esp-idf-sys to pull the libclang location even if the user forgot to source from the export file.

Hi! I've been working on this the last few days, and I've come up with two PRs:

https://github.com/esp-rs/espup/pull/380
https://github.com/esp-rs/espup/pull/381

Let me know your thoughs, I definitely prefer setting user environment as it will solve the issue for both approaches, and it basically mimics what rustup does. In the end, espup just tries to be a rustup for esp-rs.

My 2c:
The reason why I suggested the symlink approach in the first place - for both Windows and ?nix though - is because - in the shiny new world where espup will no longer have to install the GCC toolchain, you'll not need to modify the user's env EXCEPT for this pesky libclang stuff, which - please note - is only ever used by esp-idf-sys.
So why bother doing rocket science with detecting user shell and whatnot given that this effort will not pay off anymore in the near future? YAGNI.
With that said - as long as I don't have to do the . ~/export-esp.sh dance every now and then - and the user env modifications work reliably - I guess I'm fine with either.

My 2c:
The reason why I suggested the symlink approach in the first place - for both Windows and ?nix though - is because - in the shiny new world where espup will no longer have to install the GCC toolchain, you'll not need to modify the user's env EXCEPT for this pesky libclang stuff, which - please note - is only ever used by esp-idf-sys.
So why bother doing rocket science with detecting user shell and whatnot given that this effort will not pay off anymore in the near future? YAGNI.
With that said - as long as I don't have to do the . ~/export-esp.sh dance every now and then - and the user env modifications work reliably - I guess I'm fine with either.

Thanks for your input! Since it seems like there are some progress on LLD side, we can go with the symlink approach, and if we still see some areas for improvements, we can reevaluate later.
Just to recap, here is how it would like for the different approaches/OSes:

Windows currently modifies the user environment, so the user does not need to source the export file
Unix would include a symlink from $HOME/.espup/esp-clang/ to the directory containing Xtensa clang.

This would only help esp-idf-x users, so we would keep the documentation as it is (asking the users to source the export file), but if they forget to do so, on esp-idf-x it will work anyway.

Please hold on for a sec.
I'm just debugging an issue, where the build for esp-idf-sys fails on ESP IDF master because - for whatever reason - the CMake triggered by esp-idf-sys seems to pick up the GCC installed by espup (instead of the private, hidden, not-on-the$PATH, newer GCC installed by esp-idf-sys itself).
If I can't workaround this by - say - somehow re-ordering the $PATH items passed to CMake, we might already have a big problem with the fact that espup unconditionally puts a GCC instance in the user env (with export-esp.sh for *nix and directly in the user env for Windows).

@SergioGasquez TL;DR: False alarm.
Turns out ESP IDF master had renamed the xtensa GCC toolchain and now has a single one for all xtensa MCU variants (just like the riscv toolchain, which was always a single one btw).
Yet - and  a bit weirdly - ESP IDF builds tries to use the old GCC toolchain (and fails, as it is not compatible with the ESP IDF master branch) if it can't locate the new one.
Now, since espup is in fact installing an old GCC toolchain and putting it in the user $PATH, ESP IDF was picking up that one, and failing the build.

@SergioGasquez I've implemented the symlink support here. Let me know in case you change the symlink name and location in the final espup release. For now, I assume it is ~/.espup/esp-clang.
Note that the symlink approach will also run on Windows, where the symlink might not be available, but then why not? User might want to set it up himself there, instead of polluting its environment env.

Now, since espup is in fact installing an old GCC toolchain and putting it in the user $PATH, ESP IDF was picking up that one, and failing the build.

espup is also installing the latest GCC now (since v0.7.0)

@SergioGasquez I've implemented the symlink support here. Let me know in case you change the symlink name and location in the final espup release. For now, I assume it is ~/.espup/esp-clang.
Note that the symlink approach will also run on Windows, where the symlink might not be available, but then why not? User might want to set it up himself there, instead of polluting his environment env.

Great, I will do some testing with https://github.com/esp-rs/espup/pull/380 and using the master branch to include your commit

Update: Just did some testing, and I was able to build an std project without sourcing the export file on Linux

I think we can now close this issue has been released including this!


Modify docker client to skip expanding layer

Create a modified version of the docker client that will skip the expanding of the layers.  This will be used to load in the images to the central node until the pyrsia has been modified.

The expansion code is actually in the docker daemon.  Need to find another solution to make expansion faster instead of skipping it.


[video_player] fixed misleading size and aspect ratio documentation

fixes https://github.com/flutter/flutter/issues/77112
also, changed formatting for caption contructor
Pre-launch Checklist

[ ] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[ ] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[ ] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
[ ] I read and followed the [Flutter Style Guide] and the [C++, Objective-C, Java style guides].
[ ] I listed at least one issue that this PR fixes in the description above.
[ ] I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test exempt.
[ ] I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy].
[ ] I updated CHANGELOG.md to add a description of the change.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I signed the [CLA].
[ ] All existing and new tests are passing.

Thanks for the contribution! Could you add a version bump and CHANGELOG update? We need those in order to publish, and the published version is the version people are likely to be looking at the comments for.


pswrd validation Resolve conflicts

Related Issue
@apoorvaron
Screenshots

all errors have been added in this
related to change password.php
passwrod will only change if it is strong else weak passwords are not changed
Closes: #60
Description of Changes

Checklist:

[x] My code adheres to the established style guidelines of this project.
[x] I have conducted a self-review of my code.
[x] I have included comments in areas that may be difficult to understand.
[x] I have made corresponding updates to the project documentation.
[x] My changes have not introduced any new warnings.

Ok will change it give me some time today itself will be done


Eloquent find() method generate weird sql query

Laravel Version: 7.8.1
PHP Version: 7.3.12
Database Driver & Version: Mysql 8.0.19

Description:
The Eloquent find() method seems not generating sql as it should be, when we pass a Model to the $id parameter. The sql query maybe working as expected, but it seems weird for me.
$site->participants()->find(Auth::user())

It will produce a query something like this:
select
  `users`.*,
  `site_participant`.`site_id` as `pivot_site_id`,
  `site_participant`.`participant_id` as `pivot_participant_id`
from
  `users`
  inner join `site_participant` on `users`.`id` = `site_participant`.`participant_id`
where
  `site_participant`.`site_id` = 1
  and `users`.`id` in (
    1,
    'John Doe',
<EMAIL_ADDRESS>    '2020-04-28T22:50:03.000000Z',
    '2020-04-28T22:50:03.000000Z',
    '2020-04-28T22:50:03.000000Z'
  )

Instead only passing the Model's ID, Laravel pass the whole Model's data.
The docblock said that it accepts Model as a value. But it seems Laravel not handle it correctly.
It affects:

Illuminate\Database\Eloquent\Builder::find()
Illuminate\Database\Eloquent\Relations\BelongsToMany::find()
Illuminate\Database\Eloquent\Relations\HasManyThrough::find()

The docblock said that it accepts Model as a value.

Where does it say that? It says that it returns a model.

@staudenmeir Ah, you're right. Ok, let me re-phrase my statement.

It seems this is related to https://github.com/laravel/framework/pull/30312

I don't know this use case, but in Laravel 7.x now it's impossible to pass an EloquentCollection into Illuminate\Database\Eloquent\Relations\BelongsToMany::findMany().
In the end, I don't know this is a bug or just a feature that getting removed.
Because in 7.x there is still Illuminate\Database\Eloquent\Relations\Concerns\InteractsWithPivotTable::parseIds() that prepares ids from an EloquentCollection.

Passing a model isn't supported.

@driesvints But but..in 6.x, it's still supported. Is there any documentation about this?
So what's the purpose of this https://github.com/laravel/framework/blob/7.x/src/Illuminate/Database/Eloquent/Relations/Concerns/InteractsWithPivotTable.php#L591 ?

Well, at least it has been fixed by @taylorotwell at the end...
https://github.com/laravel/framework/commit/353442d80722e8862c3f140b7e34c27578e89f7d#diff-fac59ee2778e54567a539e9140a1a42c


Fixing build from error 19

PR #1236 had created a compiler that would result in error 19 being thrown in subsequent builds. It would also raise warning 170 in many places.
This temporarily comments out a key line in  cruise.umple/src/UmpleInternalParser_CodeClass.ump
that triggered the error 19 cases. This will need to be addressed by @BernardYuan by most likely changing the associations that were triggering the problem.
A strictness directive is also added to suppress warning 170, since the compiler allows some custom  constructors.

This problem happens because some Umple source code violates the rule b) concluded from issue#988.
For example, there exist associations like:
class GenConstructor{
	0..1 -- * GenMethodParameter parameters;
	0..1 -- * GenParentMethodParameter parentParameters;
	* -- 1 GenClass owner;
}

where GenParentMethodParameter is subclass of GenMethodParameter, having different rolename, however the two associations have different multiplicities. Therefore it is judged as an Error 19.


Work over RenderedTreeSpec.

I tend to glaze over looking at large nested case
class constructions so I took a flier at making this
test more visual. Here's a sample from the diff:
  -    "find simple difference in child" in {
  -      val t1 = NonTerminal(Nil, Some("A"), Terminal(Nil, Some("B")) :: Nil)
  -      val t2 = NonTerminal(Nil, Some("A"), Terminal(Nil, Some("C")) :: Nil)
  -      t1.diff(t2) must_==
  -        NonTerminal(Nil, Some("A"),
  -          Terminal(">>>" :: Nil, Some("B")) ::
  -            Terminal("<<<" :: Nil, Some("C")) ::
  -            Nil)
  -    }
  +    "find simple difference in child" in expect(
  +      'A /\ 'B,
  +      'A /\ 'C,
  +      'A /\ (-'B, +'C)
  +    )

[Current coverage][cc-pull] is 74.94% (diff: 100%)

Merging [#1278][cc-pull] into [master][cc-base-branch] will decrease coverage by 0.01%

@@             master      #1278   diff @@
==========================================
  Files           190        190
  Lines         11160      11160
  Methods       10920      10920
  Messages          0          0
  Branches        111        111
==========================================
- Hits           8366       8364     -2
- Misses         2794       2796     +2
  Partials          0          0

Powered by Codecov. Last update [00659cd...8199e0f][cc-compare]
[cc-base-branch]: https://codecov.io/gh/quasar-analytics/quasar/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/quasar-analytics/quasar/compare/00659cdcbe0fe5cde21963c0db3337510f75c63d...8199e0f4c20a081195ef9dc5b9fe4b975022285e?src=pr
[cc-pull]: https://codecov.io/gh/quasar-analytics/quasar/pull/1278?src=pr

This makes the tests much more concise and easier to understand at a glance!

@paulp I marked this as ready, so feel free to make the minor tweak I suggested or not before merging.


Android Elevation

I have set the elevation property on the CardView, using NS Angular, yet there is no shadow at all on Android.

I am seeing the same issue, no console errors but doesn't show shadow on Android. (Testing on Note 8)

Same problem for me, elevation is not working. Tested with Android emulator API 28.

same problem for me , <CardView elevation="40" radius="5" ios:shadowRadius="3"> elevation is not working while test on Android device (API 24)

Demo seems to be working 🤔 - Possibly something in the projects, maybe clashing support libs are causing problems in some projects. If someone can put together a simple demo reproducing this I'd be happy to look into it but I'm unable to repro currently.

now its working, problem was android:hardwareAccelerated="false" in AndroidManifest.xml. it should be true;


Would be possible to use numeric lists similarly as ChatGPT uses them instead of multiple chained `` instances

Here a detailed example:

Exported result:

That'd be amazing!

You are right. But list item will not only contains code. Anyway, thanks for your input!


Delete file migrations.

Codecov Report

Merging #8 into master will decrease coverage by 26.16%.
The diff coverage is 66.92%.

@@              Coverage Diff              @@
##             master       #8       +/-   ##
=============================================
- Coverage     94.35%   68.19%   -26.17%
+ Complexity      234      222       -12
=============================================
  Files            39       38        -1
  Lines           762      698       -64
=============================================
- Hits            719      476      -243
- Misses           43      222      +179

Impacted Files
Coverage Δ
Complexity Δ

src/Business/Migration/CreateIndex.php
100% <ø> (ø)
2 <0> (ø)
:arrow_down:

...Provider/ElasticsearchMigrationServiceProvider.php
100% <ø> (ø)
2 <0> (-1)
:arrow_down:

src/Business/Repository/ElasticsearchMigration.php
100% <100%> (ø)
14 <0> (-2)
:arrow_down:

src/Business/Repository/ElasticsearchClients.php
100% <100%> (ø)
7 <7> (?)

...Business/Repository/ElasticsearchMigrationStep.php
94.44% <100%> (-1.02%)
12 <0> (-2)

src/Business/Mapper/MigrationStatus.php
100% <100%> (ø)
2 <2> (?)

src/ElasticsearchMigration.php
60.73% <60.84%> (-34.34%)
76 <75> (+49)

src/Business/Mapper/MigrationTypes.php
90.9% <90.9%> (ø)
2 <2> (?)

src/Business/Migration/UpdateIndex.php
0% <0%> (-100%)
8% <0%> (ø)

src/Business/Migration/DeleteIndex.php
0% <0%> (-100%)
1% <0%> (ø)

... and 9 more

Continue to review full report at Codecov.

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

Pull Request Test Coverage Report for Build 157

157 of 241 (65.15%)  changed or added relevant lines in 6 files are covered.
100 unchanged lines in 10 files lost coverage.
Overall coverage decreased (-26.07%) to 68.809%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/Business/Mapper/MigrationTypes.php
9
10
90.0%

src/ElasticsearchMigration.php
120
203
59.11%

Files with Coverage Reduction
New Missed Lines
%

src/Business/Repository/ElasticsearchMigrationStepUpdateIndex.php
1
92.31%

src/Business/Validation/FieldDatatypeMigration.php
1
92.0%

src/Business/Migration/DeleteIndex.php
3
0.0%

src/ElasticsearchMigration.php
3
55.61%

src/Business/Migration/DeleteByQuery.php
9
0.0%

src/Business/Migration/UpdateByQuery.php
11
0.0%

src/Business/Migration/Alias.php
12
0.0%

src/Business/Migration/Reindex.php
13
0.0%

src/Business/Factory/MigrationBuilder.php
21
4.55%

src/Business/Migration/UpdateIndex.php
26
0.0%

Totals

Change from base Build 148:
-26.07%

Covered Lines:
439

Relevant Lines:
638

💛  - Coveralls


Add Docker configuration

Add Docker configuration for

Production deploy https://github.com/apinf/api-umbrella-dashboard/wiki/Deploy-with-Docker.
Setup development environment https://github.com/apinf/api-umbrella-dashboard/wiki/Development-installation-with-Docker.

The instructions do not mention installing docker-compose.

Please include step-by-step instructions, including setting up related images:
mongo uses an image, skipping
apiumbrella uses an image, skipping

I get the following error on step 3 (docker-compose up):
Cannot link to a non running container: /apiumbrelladashboard_apiumbrella_1 AS /apiumbrelladashboard_web_1/apiumbrella

I also get the following error when trying to add the docker IP to my hosts file:
docker-machine: command not found

@brylie Cannot link to a non running container
Can you try run
docker-compose up web

$ docker-compose up web
apiumbrelladashboard_mongo_1 is up-to-date
Starting apiumbrelladashboard_apiumbrella_1
Starting apiumbrelladashboard_web_1
ERROR: Cannot link to a non running container: /apiumbrelladashboard_apiumbrella_1 AS /apiumbrelladashboard_web_1/apiumbrella

@brylie And please try this one:
docker-compose up apiumbrella

docker-compose up apiumbrella
Starting apiumbrelladashboard_apiumbrella_1
Attaching to apiumbrelladashboard_apiumbrella_1
apiumbrella_1 | luajit: 14:11: did not find expected '-' indicator
apiumbrella_1 | stack traceback:
apiumbrella_1 | 	[C]: in function 'error'
apiumbrella_1 | 	...mbedded/apps/core/current/vendor/share/lua/5.1/lyaml.lua:287: in function 'error'
apiumbrella_1 | 	...mbedded/apps/core/current/vendor/share/lua/5.1/lyaml.lua:306: in function 'parse'
apiumbrella_1 | 	...mbedded/apps/core/current/vendor/share/lua/5.1/lyaml.lua:412: in function 'load_node'
apiumbrella_1 | 	...mbedded/apps/core/current/vendor/share/lua/5.1/lyaml.lua:364: in function 'load_node'
apiumbrella_1 | 	...mbedded/apps/core/current/vendor/share/lua/5.1/lyaml.lua:349: in function 'load_node'
apiumbrella_1 | 	...mbedded/apps/core/current/vendor/share/lua/5.1/lyaml.lua:349: in function 'load_node'
apiumbrella_1 | 	...mbedded/apps/core/current/vendor/share/lua/5.1/lyaml.lua:349: in function 'load_node'
apiumbrella_1 | 	...mbedded/apps/core/current/vendor/share/lua/5.1/lyaml.lua:349: in function 'load_node'
apiumbrella_1 | 	...mbedded/apps/core/current/vendor/share/lua/5.1/lyaml.lua:466: in function 'load'
apiumbrella_1 | 	...d/apps/core/current/src/api-umbrella/cli/read_config.lua:155: in function 'read_system_config'
apiumbrella_1 | 	...d/apps/core/current/src/api-umbrella/cli/read_config.lua:369: in function 'read_config'
apiumbrella_1 | 	...mbedded/apps/core/current/src/api-umbrella/cli/setup.lua:296: in function 'setup'
apiumbrella_1 | 	.../embedded/apps/core/current/src/api-umbrella/cli/run.lua:39: in function 'run'
apiumbrella_1 | 	...ella/embedded/apps/core/current/src/api-umbrella/cli.lua:8: in function 'command_function'
apiumbrella_1 | 	...ella/embedded/apps/core/current/src/api-umbrella/cli.lua:130: in function 'cli'
apiumbrella_1 | 	...umbrella/embedded/apps/core/current/bin/api-umbrella-cli:28: in main chunk
apiumbrella_1 | 	[C]: at 0x00404720
apiumbrelladashboard_apiumbrella_1 exited with code 1

Can Docker be installed on a 32-bit machine? My Ubuntu machine is 32-bit, not 64. I also couldn't open this link given here for Linux.

@Alapan I not tried 32-bit, but based on google answer, should works.
Try use this link https://docs.docker.com/engine/installation/linux/ubuntulinux/, in "Development installation with Docker" typo, I will fix it.

@Alapan from docker docs:
Prerequisites
Docker requires a 64-bit installation regardless of your Ubuntu version. Additionally, your kernel must be 3.10 at minimum. The latest 3.10 minor version or a newer maintained version are also acceptable.

So now I am not sure that it will work for you.

@shaliko No, in that case, this task cannot be performed on my machine. Some other 64-bit Ubuntu machine will be needed.

@shaliko Tested "docker-compose up" (development env)
Works great on Macbook Pro 64-bit using docker-toolbox :)
We might want to align MongoDB with Meteor bundled mongo version (currently 2.6.7) MongoDB driver upgrade for 3.2 is on roadmap for MDG.
Did you have docker-compose.yml for production env? I think we could release to Docker Hub and pull image from there when installing to production.

@jykae We already pushed image to docker hub https://hub.docker.com/r/apinf/apinf/ and provided instructions for run it.

Good point about MongoDB, should we provide details about mongo driver version in Readme?
I don't have docker-compose.yml for production not sure that we need it. Because looks like docker-compose.yml not fit good for production. What we need is just independently run 2 docker images and then visit apinf-umbrella-dashboard and configure (link to api-umbrella) on settings page in admin UI.

@brylie You still have issue on Linux?

@shaliko, tested on Ubuntu 16.04, it works.

@elnzv Great to hear that, thanks a lot!

@shaliko please resolve conflicts, so that we can merge.


database migrations for image expiry notification (PROJQUAY-7075)

database migrations for image expiry notification (PROJQUAY-7075)
fix format
seeding db changes for cypress

#4
#3  👈
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Sunandadadi and the rest of your teammates on  Graphite


Update dependencies

Hey folks,
updating Sentry sort of escalated and led me to checking which other dependencies I could painlessly update without breaking the tests. I ran make test-full locally and it passed, but wasn't sure whether there's more automated testing I could do.
If this is somehow undesirable feel free to let me know. I can also cut this into smaller chunks.
Cheers
Lucas
PS: Would it potentially make sense to enable something like dependabot for this repo?

hey @x3ro , thanks for this pr too. usually we do this just before we cut a release because node security breaks so much it's a waste of time to do it now, we'll just have to do it again later.
that said, if you'd still like it merged here are my notes:
as noted in the other one, i'd prefer sticking to the convention ~ that already exists in this project, rather than change some of them to ^ and leave the rest ~. it's already hard to reason about the one operator.
the if statements you added don't fit the code style of the project. we leave a space after if.
the commit message does not meet our guidelines. it would also be nice if the additional code changes that aren't updating dependencies are noted.

closing to inactivity. please feel free to reopen if you have a new patch.


Movable - contains with snap is placed outside of container

Steps to reproduce:

go to: https://codesandbox.io/s/11r0n?file=/Example.jsx
add snap(60, 60)
drag the element to the top-left (of the container) or top-right.

Should consider enforcing the contain prop when snap is also used, even if the movable element will not snap to the "correct" location according to the snap grid.

Now I understand the order of the props array is important here


Adding trajcluster back to the worflow

Adding back trajcluster and all the subsequent modules to the default workflow now that the issue https://cdcvs.fnal.gov/redmine/issues/28517 has been solved in larsoft v09_90_00

trigger build with DUNE/dunesw#122

:heavy_check_mark: CI build for LArSoft Succeeded on slf7 for e26:prof -- details available through the CI dashboard

:heavy_check_mark: CI build for LArSoft Succeeded on slf7 for c14:prof -- details available through the CI dashboard

:x: CI build for DUNE Failed at phase ci_tests DUNE on slf7 for c14:prof -- details available through the CI dashboard
:rotating_light: For more details about the failed phase, check the ci_tests DUNE phase logs
parent CI build details are available through the CI dashboard

:warning: CI build for DUNE Warning at phase ci_tests DUNE on slf7 for e26:prof -- details available through the CI dashboard
:rotating_light: For more details about the warning phase, check the ci_tests DUNE phase logs
parent CI build details are available through the CI dashboard


Generate AppImage

Requirements

Linux 64-bit machine

Description of the Change
This PR, when merged, will compile this application on Travis CI upon each git push, and upload an AppImage to a temporary download URL on transfer.sh (available for 14 days). The download URL is toward the end of each Travis CI build log of each build. Please note: Instead of storing AppImage builds temporarily for 14 days each on transfer.sh, you could use GitHub Releases to store the binaries permanently. In this case, delete this line from the .travis.yml file.
Alternate Designs

Flatpak: Requires the setup of Flatpak and a runtime first, need to use the command line. Does not work out-of-the-box on most distributions but Fedora. Does not run on Live CDs.
Snap: Canonical centric solution, Requires the setup of Snap and a runtime first, does not work out-of-the-box on most distributions but Ubuntu.

Why Should This Be In Core?
Linux should be a first-class desktop for Atom, and using Atom on Linux should be as easy as on Windows and macOS.
Benefits
Providing an AppImage would have, among others, these advantages:

Works for most Linux distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
One app = one file = super simple for users: just download one AppImage file, make it executable, and run
No unpacking or installation necessary
No root needed
No system libraries changed
Just one format for all major distributions
Works out of the box, no installation of runtimes needed
Optional desktop integration with appimaged
Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
Can optionally GPG2-sign your AppImages (inside the file)

Here is an overview of projects that are already distributing upstream-provided, official AppImages.
Possible Drawbacks
None. Providing an AppImage could be done in addition to providing other types of Linux packages and/or bundles.
Applicable Issues

https://github.com/atom/atom/issues/13118: Feature request: Provide an AppImage for Atom Stable and Atom Beta releases
https://github.com/atom/atom/issues/4980: Add portable version for Linux
https://github.com/atom/atom/issues/11000: Building Atom Beta releases so they can be installed simultaneously, on the same machine, to stable releases
https://github.com/atom/atom/issues/4330: Installing atom without sudo privileges
https://github.com/atom/atom/issues/2956: Add Linux software repositories for app update support
https://github.com/atom/atom/issues/11837: Flatpak release support
https://github.com/atom/atom/issues/13298: Please provide a snap package

Ping. Asking for a review.

Hi.
At this time we have no resources available to support additional distribution formats beyond the ones for Atom on Linux we currently maintain (deb and rpm).

Hi @damieng I understand that your resources are limited. I hope you have considered that I have essentially already done the work, so this is a "turnkey" solution...

The problem is adding .AppImage is just the tip of the iceberg. We'd have to understand it to be able to support it as well as be able to maintain and fix it should it break, answer questions and problems with it's usey, be able to reproduce issues on a variety of distributions that use it...

@damieng Is there any progress on this?

@Serkan-devel there is no progress as we aren't pursuing it as per my previous response;

We are not adding any additional distribution formats at this time due to resource constraints in supporting them.

Come on, I have already done the work...

@damieng You already provide binary tar.gz for linux which is very similar to AppImage and will cause same issues on different distributions.
I am very unhappy about your decisions.

Did anything change in regard to providing an *.AppImage file for distribution?

Just asking since there are now quite a few applications which support this format. (ref. https://appimage.github.io/apps/  or https://www.appimagehub.com/browse)


Empty media rules cause Unrecognised input

A rule like this will throw your "Unrecognised input" error.
@media (min-width: @screen-md-min) {

}

Note that this issue is unique to iless, doesn't happen on lessphp and less.php. But those don't support the 'new' mixin syntax, lol.

I've created unit test for this issue and it passes. Can please you provide your code which is failing?

Ok, this is white-space sensitive. I hacked your test case around a bit. This isn't a real test case any more as I made it exit, but you can see the problem...
<?php

/*
 * This file is part of the ILess
 *
 * For the full copyright and license information, please view the LICENSE
 * file that was distributed with this source code.
 */

/**
 * Issue #39 test
 *
 * @package ILess
 * @subpackage test
 */
class ILess_Test_Issues_039Test extends ILess_Test_TestCase
{
    public function testIssue()
    {
        $parser = new ILess_Parser(array(
            'compress' => false
        ));

		try
		{
        $parser->parseString(
'@media (min-width: 100px) {
}
');

        $css = $parser->getCSS();
	}
	catch (Exception $ex)
	{
		exit('.less problem: '.$ex->getMessage());
	}
        $expected =
'@media (min-width: 100px) {
}

';
        $this->assertEquals($expected, $css);
    }

}

Ok, I get it.
The css output of empty media declaration should be an empty string...


Source API documentation

Hi,
I got inspired by your application and want to use the API to pull the data from my TC MAX to do some analyses on battery use, range, etc.
I was wondering where you got the information for the API, since I am searching but can not find any documentation on it.
Also I noticed that you have two files for the API (vmoto_soco_api.py and super_soco_api.py) which one should I use to retrieve the data?
Kind regards,
Mathijs

Hi, Mathijs. Thanks for taking interest in this project.
Unfortunately there's no official documentation for the APIs, since I believe that Vmoto Soco never intented to open them to pulbic use besides the mobile apps. Everything I did was sniffing the network traffic from those apps and reverse engineering their code.
At some point I'll upload these API implementations to PyPI, but for now feel free to grab any of the files you mentioned and use them. There's one for the original API (super_soco_api.py) and one for the new API made available for newer bikes and replacement ECUs (vmoto_soco_api.py), so it depends on the mobile app you used to register your bike.
Best,
Brian


Binder symbols in Exists is not linked

Compare:

Lean 4: exists_eq
Lean 3: exists_eq

Only the Lean3 versions let you inspect the binder symbol in the docs. While for Existss this is obvious, for other binders the hover text is very useful.
It's possible this requires a patch to Lean4 itself; the Lean 3 patch was https://github.com/leanprover-community/lean/pull/781.

This does most likely require a patch to lean itself, doc-gen4 merely analyses datastructures on top of the info trees: https://github.com/leanprover/doc-gen4/blob/main/DocGen4/Output/Base.lean#L208
CC: @Kha what do you think?

Yes, doc-gen shows whatever the info view shows


Game button

A button is to be provided that will re-direct to our game, now its upon your creativity where u place this button such that  visitor's eye catches this button.

I have started working on it, will do a pr by today

will this button be in the homepage?

A button is to be provided that will re-direct to our game, now its upon your creativity where u place this button such that visitor's eye catches this button.

will this button be in the homepage?

A button is to be provided that will re-direct to our game, now its upon your creativity where u place this button such that visitor's eye catches this button.

Yes

I have started working on it, will do a pr by today

i want it done by the EOD


Documentation for incrementality

We some high-level docs in the pipeline spec, but incrementality is a pretty complex flag to use and understand. We needs a short doc that explains in detail what data will be available, how it's exposed, and how to use it (files added, modified, or deleted). This should include a simple example.
I think creating a doc for performance optimizations that includes incrementality, batch, perhaps more details on lazy/copy elision or other optimizations we often tell users.
I don't think @dwhitena nor I actually know how incremental really works. @jdoliner, since you're working on batch too, can you take a first pass at this doc and then we'll review and expand?

Added here: http://pachyderm.readthedocs.io/en/latest/fundamentals/incrementality.html


Problem with oncoplot and nonmutated samples

I am trying to make an oncoplot with the oncoplot function of the maftools package (version 2.4.0), using R version 4.0.0. Everything is fine as long as I don't try to plot the nonmutated samples. But when I call:
oncoplot(maftest,removeNonMutated=FALSE)

Error in top_bar_data[, colnames(numMat), drop = FALSE] :
subscript out of bounds
....I get the error message above. My MAF file contains nonmutated samples, having just a name, but otherwise empty. Is there an issue with the format of those nonmutated rows in the MAF file or have I found a bug? I did not experiece this message with a previous version of R/BionConductor and maftools.
sessionInfo() R version 4.0.0 (2020-04-24) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Manjaro Linux
Matrix products: default BLAS: /usr/lib/libblas.so.3.9.0 LAPACK: /usr/lib/liblapack.so.3.9.0
locale: [1] LCCTYPE=enUS.utf8 LCNUMERIC=C
[3] LCTIME=enUS.UTF-8 LCCOLLATE=enUS.utf8
[5] LCMONETARY=enUS.UTF-8 LCMESSAGES=enUS.utf8
[7] LCPAPER=enUS.UTF-8 LCNAME=C
[9] LCADDRESS=C LCTELEPHONE=C
[11] LCMEASUREMENT=enUS.UTF-8 LC_IDENTIFICATION=C
attached base packages: [1] stats graphics grDevices utils datasets methods base
other attached packages: [1] maftools_2.4.0
loaded via a namespace (and not attached): [1] compiler4.0.0 Matrix1.2-18 tools4.0.0 RColorBrewer1.1-2 [5] survival3.1-12 splines4.0.0 grid4.0.0 data.table1.12.8 [9] lattice_0.20-41

I can reproduce this. Thank you for reporting. I will fix it soon.

Hi,
I have fixed the issue. Could you please try it out and let me know if it fixes the issue?
You will have to install from GitHub.
BiocManager::install("PoisonAlien/maftools")

Yes, it works.
Thank you very much!
Oddmund
On Thursday, May 21, 2020 11:55 CEST, Anand Mayakonda<EMAIL_ADDRESS>wrote:

Hi,
I have fixed the issue. Could you please try it out and let me know if it fixes the issue?
You will have to install from GitHub.BiocManager::install("PoisonAlien/maftools")
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


jstree fails to load when child node is having special characters in name ,example  'test?'

Console error: Failed to execute 'querySelector' on 'Element': '#@@@:/test/TestSlash/Test?/' is not a valid selector.
Can we have workaround for this.

Which jsTree version are you using? From what I can see the : is not escaped, but is explicitly handled in the latest code, so maybe you are using an older version.
If you are using the latest version and still get the error - please provide the actual ID you are trying to use.
Btw - the error is caused by IDs, not by the name - so please do not use the name as an ID, it will be better off to let jstree handle the IDs instead of assigning gibberish as an ID.
Best regards,
Ivan

Thanks a lot :-) , I have updated the library and it is working fine.


fix: Sonar suggestions

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


Correctly skip mismatching targets

@simonpasquier

Suggestions for testing?
This often comes up with bugs triggered by map iteration randomization. In the end it seems the only way to validate this with some reliability is looping a test 1000 times – and even then it might not happen.
Doing that for every place where we iterate over map would get a bit out of hand.

In the end it seems the only way to validate this with some reliability is looping a test 1000 times – and even then it might not happen

That was my idea. Agree that it might give a feeling of false confidence...

Suggestions for testing?

Drive-by comment. At the extreme, break it by design: implement TargetsActive so that it usually returns elements in a different order. May not be practical here, but it could be applied to testing, if you control the implementation in the test.

Alternate proposal, let's factor out the behavior into a function so we can skip on the label, which is easy to misplace.
I think that prevents the issue from happening in the first place in a very obvious way. I'd prefer that to a randomized (and likely flaky) test that tries to fight the runtime. Those have their place, e.g. fuzzing our sample compression. But it just doesn't seem like a scalable approach for every map iteration in our code base.

@fabxc works for me!


Update AboutUs page

Add my own profile to the AboutUs Page.
Do check for errors!

Codecov Report

Merging #2 (b4d8c1d) into master (1e08e96) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master       #2   +/-   ##
=========================================
  Coverage     72.15%   72.15%
  Complexity      399      399
=========================================
  Files            70       70
  Lines          1232     1232
  Branches        125      125
=========================================
  Hits            889      889
  Misses          311      311
  Partials         32       32

Continue to review full report at Codecov.

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


GPT-J model implementation

Tested with https://huggingface.co/Kastor/GPT-J-6B-Pygway-ggml-q4_1/blob/main/GPT-J-6B-Pygway-v2-ggml-q4_1.bin

About to sleep so I can't look over this properly, but looks good at a glance!

Can you rename Gptj to GptJ?
Does llm gptj work?
Is there a way to share code amongst the examples? They look pretty similar.

Otherwise, should be fine.

This also solves #165 and its been tested with these models here https://huggingface.co/Guglielmo. Will be closing my PR #165


Atomic support for uncached regions

We need to consider atomics for uncached regions, namely the manycore system. The RISC-V method for determining which regions have support which types of memory access is through PMAs. We should store PMA properties (uncached, atomic supported, pre-fetchable) in the TLB.  We also need a way for software to query PMAs, most likely through MMIO.
As for the actual atomic access, my understanding is that the manycore network supports this functionality, so we need a method of passing memory request info through the manycore bridge.  Since these are uncached accesses, I don't believe BlackParrot needs any additional hardware support, but we need it to speak the same interface language.
At the moment, we throw an assertion if an atomic operation is performed on an uncached region.
Action items are

Design and implement an enhancement to the manycore bridge to support atomics
Add atomic interface information to manycore bridge documentation.
Add regression test for this interaction

See additional discussion in PR #129

Mostly agree except the part about PMA being stored in the TLB, since PMA
must apply even when translation is off. I think we should see how far just
using address ranges gets us.
On Sat, Apr 20, 2019 at 3:49 PM Dan Petrisko<EMAIL_ADDRESS>wrote:

We need to consider atomics for uncached regions, namely the manycore
system. The RISC-V method for determining which regions have support which
types of memory access is through PMAs. We should store PMA properties
(uncached, atomic supported, pre-fetchable) in the TLB. We also need a way
for software to query PMAs, most likely through MMIO.
As for the actual atomic access, my understanding is that the manycore
network supports this functionality, so we need a method of passing memory
request info through the manycore bridge. Since these are uncached
accesses, I don't believe BlackParrot needs any additional hardware
support, but we need it to speak the same interface language.
At the moment, we throw an assertion if an atomic operation is performed
on an uncached region.
Action items are

Design and implement an enhancement to the manycore bridge to
support atomics
Add atomic interface information to manycore bridge documentation.
Add regression test for this interaction

See additional discussion in PR #129
https://github.com/black-parrot/pre-alpha-release/pull/129
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/black-parrot/pre-alpha-release/issues/140, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEFG5AD4UWOBQ6C5DJAQBOLPROMWRANCNFSM4HHKR2SQ
.

I thought we agreed that we were filling the PMA along with the PMP, even with translation off.  Otherwise the FE will have no conception of the PMAs

We explored that idea and then agreed to punt until later. I think we can
have a module that is reused in both the FE and the BE that returns the
appropriate information, which is currently statically determined?
On Sat, Apr 20, 2019 at 8:43 PM Dan Petrisko<EMAIL_ADDRESS>wrote:

I thought we agreed that we were filling the PMA along with the PMP, even
with translation off. Otherwise the FE will have no conception of the PMAs
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/black-parrot/pre-alpha-release/issues/140#issuecomment-485222199,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEFG5AAJPW47PZCL2TR33RTPRPPG3ANCNFSM4HHKR2SQ
.

Getting back to this:
Do you think we'll need AMO support for IO, or just the LR/SC? Currently how the emulation works is we detect AMO as illegal instruction at decode.  It wouldn't be too much trouble to add that detection to be after physical address translation -- AMO+cached is illegal, AMO+uncached is legal (pass it to the CCE and beyond).

Interesting. Yeah, we would like AMO support for I/O; for the manycore in
particular.
M
On Thu, Apr 25, 2019 at 3:27 PM Dan Petrisko<EMAIL_ADDRESS>wrote:

Getting back to this:
Do you think we'll need AMO support for IO, or just the LR/SC? Currently
how the emulation works is we detect AMO as illegal instruction at decode.
It wouldn't be too much trouble to add that detection to be after physical
address translation -- AMO+cached is illegal, AMO+uncached is legal (pass
it to the CCE and beyond).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/black-parrot/pre-alpha-release/issues/140#issuecomment-486860245,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEFG5AHEC4CBJGCB6WPDN5TPSIV6PANCNFSM4HHKR2SQ
.

In the riscv spec PMA section, they describe AMO support in terms of subsets of supported operations. The least of which is supporting only AMO.swap. What would be nice about that is we wouldn't need an ALU in the endpoint controller. Do you think that’s sufficient?

On Apr 25, 2019, at 3:47 PM, taylor-bsg<EMAIL_ADDRESS>wrote:
Interesting. Yeah, we would like AMO support for I/O; for the manycore in
particular.
M
On Thu, Apr 25, 2019 at 3:27 PM Dan Petrisko<EMAIL_ADDRESS>wrote:

Getting back to this:
Do you think we'll need AMO support for IO, or just the LR/SC? Currently
how the emulation works is we detect AMO as illegal instruction at decode.
It wouldn't be too much trouble to add that detection to be after physical
address translation -- AMO+cached is illegal, AMO+uncached is legal (pass
it to the CCE and beyond).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/black-parrot/pre-alpha-release/issues/140#issuecomment-486860245,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEFG5AHEC4CBJGCB6WPDN5TPSIV6PANCNFSM4HHKR2SQ
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

That’s interesting. We haven’t totally settled on what we support, but
ideally it will be bottom up.
Does the latest spec have a lot more on PMA?
M
On Fri, Apr 26, 2019 at 11:50 AM Dan Petrisko<EMAIL_ADDRESS>wrote:

In the riscv spec PMA section, they describe AMO support in terms of
subsets of supported operations. The least of which is supporting only
AMO.swap. What would be nice about that is we wouldn't need an ALU in the
endpoint controller. Do you think that’s sufficient?

On Apr 25, 2019, at 3:47 PM, taylor-bsg<EMAIL_ADDRESS>wrote:
Interesting. Yeah, we would like AMO support for I/O; for the manycore in
particular.
M
On Thu, Apr 25, 2019 at 3:27 PM Dan Petrisko<EMAIL_ADDRESS>wrote:

Getting back to this:
Do you think we'll need AMO support for IO, or just the LR/SC?
Currently
how the emulation works is we detect AMO as illegal instruction at
decode.
It wouldn't be too much trouble to add that detection to be after
physical
address translation -- AMO+cached is illegal, AMO+uncached is legal
(pass
it to the CCE and beyond).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/black-parrot/pre-alpha-release/issues/140#issuecomment-486860245
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AEFG5AHEC4CBJGCB6WPDN5TPSIV6PANCNFSM4HHKR2SQ

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/black-parrot/pre-alpha-release/issues/140#issuecomment-487163328,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEFG5AEQBE3YSIZVGVBFGKTPSNFGJANCNFSM4HHKR2SQ
.

I'm not sure when this was introduced, but it's in latest

So it turns out it's actually easier to have PMA attributes live in/near the PTW.  Otherwise, we need to manually map an MMIO page as part of our start code #203 .  And I'm not sure how this would interact with Linux (this is basically the IOMMU concept).  The only real downside is that the FE-BE interface needs to contain the PMA information (tlb_fill_response), but there aren't that many PMA bits so it should be scalable.


Duplicated key Warning

When I run a middleman server, everything works. However I get this warning:
== The Middleman is loading
/Users/me/.rvm/gems/ruby-2.2.1/gems/middleman-blog-4.0.0/lib/middleman-blog/blog_data.rb:170: warning: duplicated key at line 170 ignored: :lang
== Blog Sources: {year}-{month}-{day}-{title}.html (:prefix + :sources)
== View your site at "http://localhost:4567", "http://<IP_ADDRESS>:4567"
== Inspect your site configuration at "http://localhost:4567/__middleman", "http://<IP_ADDRESS>:4567/__middleman"

Mac OSX El Capitan 10.11.2

I'm not sure but my thought is it's related to; config.rb or some frontmatter?

@woodall Yeah, I'm not sure, I closed the issue here and posted it in the /middleman-blog repo because I realize it's actually coming from the plugin and not middleman core.


Added Installation scripts, Simplified README.

ReadMe easier to read, documented installation scripts created to avoid unnecessary detailing.

@kaushalvivek What if the user already has those packages installed? Then running those scripts will be futile. I suggest you let the original content of README as it is and maybe add this line somewhere that if the user does not have those packages, then run those scripts. Also, does your script handle it gracefully if the packages are already installed?

Hi @ankitshubham97 , fair point, I'll look into graceful error handling and other points you raised at the earliest opportunity I get.


added SkyDigest.app

cant login from a third party PDS, this needs more work, no idea what it even is for, never heard of nuzzel


Byte-wise addressing machine

Today the underlying zkasm specification operates on memory in terms of word-size slots. This is a nice property in that it does not permit for misaligned loads normally, but most of the contemporary architectures use byte addressing instead – it may be non-trivial to set up the backend to work with word-wise addressing scheme.
Additional complication is that wasm also supports byte addressing and misaligned loads are handled transparently. So for majority of memory accesses we would need to use MEM_ALIGN_RD/WR instructions that allow byte-addressing at a cost of an additional register argument.

This question has come up before we realized we’re looking to implement a compiler that can compile a wasm interpreter rather than arbitrary wasm modules that require a full runtime support.
With wasm interpreter in the play memory accesses can be emulated with the runtime implemented by the interpreter.


Simplify brute force

Why did you drop the repeats and the measuring time?

Because this is an example. The point is to show how to use brute force, and demonstrated that the interface is identical. Not to provide performance comparison for an aritifical example.

Then should we print the result and have a comment that say there is no guarantee in the ordering of values for a given predicate?

Done.


Update-VIPUsers-Watchlist-from-AzureAD-Group cannot retrieve the full user list

This refers to the playbook that can be found below:
https://github.com/Azure/Azure-Sentinel/tree/master/Playbooks/Update-VIPUsers-Watchlist-from-AzureAD-Group
https://techcommunity.microsoft.com/blog/microsoftsentinelblog/update-microsoft-sentinel-vip-users-watchlist-from-azure-ad-group-using-playbook/3100184
This playbook is not working correctly for the Entra ID group with more than 100 users.
The VIP users list is not being updated correctly. The VIP group has over 300 members and on the logic app step for 'HTTP - Get VIP Azure AD Group Members' only 100 users is returned.
It looks like the API is returning only 100 results due to paging.
https://learn.microsoft.com/en-us/graph/paging?tabs=http
There is a<EMAIL_ADDRESS>in the result of the initial call and the API call needs to keep on being repeated as long as nextlink is available to retrieve all users from the group.
Please update the template to overcome the paging problem that leads to incomplete VIP User List.

Hi @pixel559 , Thanks for flagging this issue, we will investigate this issue and get back to you with some updates. Thanks!

Hi @pixel559, we are working on this issue will update on this soon. Thanks!!


Mac: Cmd+Delete should trigger Don't Save in Save Changes dialog

This is the Mac OS X system default for save dialog boxes.

http://support.apple.com/en-us/HT201236

@jeremiahlee As a workaround you may use tab to go to the Don't Save button.

Closing as fixed


Export to file -> data file size is 0

Hi,
I try to export a specific index to a file. The export files are created as expected (data and meta file). The problem that I have is that the size of the data file is not constant.
The data file is after most executions empty (0 bytes). After some executions the size is 780kb (seems te be correct). After some executions the size is approx. 2300kb.
The size of the meta file is always equal, what seems te be correct.
I used the command:
node "D:\Program Files\node_modules\elasticsearch-exporter\exporter.js" -a es-server1 -p 9242 -i .kibana -g kibana-test-settings
The output of the exporter script:
Elasticsearch Exporter - Version 1.4.0
Reading source statistics from ElasticSearch
Reading mapping from ElasticSearch
Reading mapping from ElasticSearch
Storing index mapping in meta file kibana-test-settings.meta
Waiting for mapping on target host to be ready, queue length 10
Waiting for mapping on target host to be ready, queue length 20
Mapping is now ready. Starting with 20 queued hits.
Storing index mapping in meta file kibana-test-settings.meta
Mapping is now ready. Starting with 0 queued hits.
Number of calls:        4
Fetched Entries:        24 documents
Processed Entries:      24 documents
Source DB Size:         24 documents
I'm using nodejs version: v0.12.0
Any idea?

Hi Jasper, thanks for using the exporter.
First of all, I haven't tested the exporter on 0.12 yet, so I don't know if that has any impact. I don't expect it to, since the changes seem to not impact the parts of the API I'm using, but you never know.
Secondly, I'm currently doing a rewrite from scratch for version 2.0, which will give you a few more options on how to query data from ElasticSearch. Hopefully I will hunt down all bugs in that rewrite and this issue will be solved.
Now with that out of the way: I don't know what exactly seems to be the problem here. It could be either that ElasticSearch's scroll mechanism doesn't deliver all docs or that the exporter shuts down before all data is written.
What does the output look like when there is data missing? What version of ElasticSearch are you using? How big is you ElasticSearch cluster? Can you try and run a scroll request manually to see if there is data missing?

I have also tested on a 0.10 version of NodeJS. That gives me the same behaviour. I don't expect that it is related to a NodeJS version.
The result of a single execution (most of the time) a data file of 0kb (empty) and a meta(data) file of approx. 2500kb (content of metadata file is correct).
We are running a standalone Elasticsearch 1.4.3 that is almost empty and not heavily used (development environment). We only want to export a single index that contains 24 documents (that is also what the output of the exporter plugin says).
The server where the exporter script is running on is slow. On my faster development machine the results are better. Closing the exporter app too early (or something like that) could be a reason why the file is empty.
Is there a way to get more debug information while running the script (without adding it)?

Nope, that's all the output you get, but that's one of the new features in 2.0 ;)
My guess is that there is a problem because storing the meta data finishes after all documents have already been fetched and the actual export is never triggered. Although you said that there have been cases where only a partial file has been exported?

Sounds logic. Could be the issue.
I have 3 optional results after finishing the script:
Test done on 2 different machines.
meta file -> always size of 2500kb
Optional 1: data file size 0kb (machine 1: +- 80% of times, machine 2: +- 20% of times)
Optional 2: data file size 700kb (machine 1: +- 15% of times, machine 2: +- 75% of times)
Optional 3: data file size 2500kb (machine 1: +- 5% of times, machine 2: +- 5% of times)
I think that the data file of 700kb is a correct one because after making a small change to the index (add a little bit data) the size increased to 780kb. But with that in mind I can't explain why sometimes there is a larger file.
Maybe I can put a sleep in the script to wait before the IO is finished and check the results?

No I'm sorry, but after reviewing the code I just can't see where the timeout would help. Next step would be for me to try and replicate the behavior and then start debugging, but since this code will soon be superseded I'd rather not spend too much time on fixing old stuff (my time is unfortunately already pretty limited as it is).
The data file is nothing more than a zipped json file where the documents are separated by newlines (just like the bulk insert format), so you can take a look at which of the files should be the correct one. If 2500 kb is indeed more than what's in the database, I'd be curious to know what the rest of that data is.

I will check the file contents after the weekend.


Use standardrb for style and formatting

List of Changes

standardrb --fix
use globals for $stderr and $stdout
fix Lint/IncompatibleIoSelectWithFiberScheduler
fix  Performance/StringIdentifierArgument
Style/SlicingWithRange: Prefer ary[n..] over ary[n..-1]
fix Lint/NonDeterministicRequireOrder: Sort files before requiring them.

I recommend adding a .git-blame-ignore-revs file that includes the commit hash for these linting commits.
e.g. https://github.com/fastly/Northstar/blob/master/.git-blame-ignore-revs
top result blog post with details about git blame ignore revs


tkinter.TclError: no display name and no $DISPLAY environment variable

I am running the deepmedic in a server and I ran into some troubles for plotting the training progress part. When I entered ''' python plotTrainingProgress.py -logs examples/output/logs/trainSessionWithValidTinyCnn.txt -class 0 ''', it gave me the error message:
Traceback (most recent call last):
File "example.py", line 7, in
plt.scatter(x, y, s=20)
File "/home/USER/.virtualenvs/nnet/lib/python2.7/site-packages/matplotlib/pyplot.py", line 3241, in scatter
ax = gca()
File "/home/USER/.virtualenvs/nnet/lib/python2.7/site-packages/matplotlib/pyplot.py", line 928, in gca
return gcf().gca(**kwargs)
File "/home/USER/.virtualenvs/nnet/lib/python2.7/site-packages/matplotlib/pyplot.py", line 578, in gcf
return figure()
File "/home/USER/.virtualenvs/nnet/lib/python2.7/site-packages/matplotlib/pyplot.py", line 527, in figure
**kwargs)
File "/home/USER/.virtualenvs/nnet/lib/python2.7/site-packages/matplotlib/backends/backend_tkagg.py", line 84, in new_figure_manager
return new_figure_manager_given_figure(num, figure)
File "/home/USER/.virtualenvs/nnet/lib/python2.7/site-packages/matplotlib/backends/backend_tkagg.py", line 92, in new_figure_manager_given_figure
window = Tk.Tk()
File "/usr/local/lib/python2.7/lib-tk/Tkinter.py", line 1810, in init
self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: no display name and no $DISPLAY environment variable
What is happening here?
I appreciate for your assistance.

Hello poyukao,
First of all thanks a lot for your interest in my work and the feedback. Always appreciated :)
This is probably the classic error from matplotlib when you are logged on a remote machine (eg through ssh?) and try to display things. It cannot find the display device.
Solutions:
Very nice solutions explained in: http://stackoverflow.com/questions/3453188/matplotlib-display-plot-on-a-remote-machine . In my case (local and remote machine run ubuntu), if I ssh to remote via "ssh -X remoteMachineName", fixes the error.
Please let me know if one of these solutions fixes your problem ;) Or if any new ones arise. Any feedback highly appreciated!
Note: This plotting script is not well put together. I will try to assign some time to update it.
Kostas

Hello Kostas,
I appreciate your reply. The website and the solution you provided are very helpful. Finally, I ssh to remote via "ssh -X remoteMachineName" really fixed the error. I am able to get an beautiful plot now.
Thank you again for your assitance.
Best,
Po-Yu

Great, thanks a lot for letting me know. Hope you get some useful results out of it!
Issue closed.


Lime-79, Issue 46: Fix unused vars

Description
Stacked pull request on #158
Compiler detects unused variables, function parameters and a function that can be restricted to pure. I'll enumerate them here:
SavingsAccount.sol L209 —> _receivedToken is unused
SavingsAccount.sol L246 —> _receivedToken is unused
NoYield.sol L152 —> function parameter address _asset is unused
NoYield.sol L162 —> function parameter address _asset is unused
NoYield.sol L53 —> liquidityToken function visibility can be restricted to pure
Integrations Checklist

[x]  Have any function signatures changed? If yes, outline below.
[ ]  Have any features changed or been added? If yes, outline below.
[ ]  Have any events changed or been added? If yes, outline below.
[ ]  Has all documentation been updated?

Changelog

SavingsAccount.sol L209 —> _receivedToken is unused (Removed)
SavingsAccount.sol L246 —> _receivedToken is unused (Removed)
NoYield.sol L152 —> function parameter address _asset is unused (skipped: https://linear.app/sublime-finance/issue/LIME-79#comment-06824ec6)
NoYield.sol L162 —> function parameter address _asset is unused (skipped: https://linear.app/sublime-finance/issue/LIME-79#comment-06824ec6)
NoYield.sol L53 —> liquidityToken function visibility can be restricted to pure (Changed)

Event Signature Changes
Function Signature Changes

function liquidityToken(address _asset) external *pure* override returns (address _tokenAddress)

Features
Events

Codecov Report

Merging #159 (5b58e20) into lime-71 (a979565) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           lime-71     #159   +/-   ##
========================================
  Coverage    85.01%   85.01%
========================================
  Files           16       16
  Lines         1735     1735
  Branches       321      321
========================================
  Hits          1475     1475
  Misses         260      260

Impacted Files
Coverage Δ

contracts/SavingsAccount/SavingsAccount.sol
91.04% <100.00%> (ø)

contracts/yield/NoYield.sol
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Replace binary body-encoding in examples

The png-example in https://docs.astro.build/en/core-concepts/endpoints/#static-file-endpoints uses Buffer and deprecated binary encoder. There's a few other examples as well: https://github.com/search?q=repo%3Awithastro%2Fdocs encoding%3A 'binary'&type=code

APIRoute type expects body to be string, not Buffer.
binary BufferEncoding is deprecated in node AFAIK.

Suggestion:
// I'm not sure if `hex` or `base64` is the new preferred encoding
export async function get({ params, request }) {
  const response = await fetch("https://astro.build/assets/press/full-logo-light.png");
  const buffer = Buffer.from(await response.arrayBuffer());
  return {
    body: buffer.toString('hex'),
    encoding: 'hex',
  };
}

Good question,  Using hex here may lead to problems as it performs data truncation with some inconsistencies. For this example I would recommend if you are sending a image to use base64 encoding over hex when encoding binary data to be sent over the wire.
With your amended code sample:
export async function get({ params, request }) {
  const response = await fetch("https://astro.build/assets/press/full-logo-light.png");
  const buffer = Buffer.from(await response.arrayBuffer());
  return {
    body: buffer.toString('base64'),
    encoding: 'base64',
  };
}

https://nodejs.org/api/buffer.html#buffers-and-character-encodings

Found a downside. Both will break png in dev. 😞

@fflaten could you raise an issue for this on the main astro repo if possible, and we will get it on the board to get looked at, Thank you, 👊

After exploring the Node documentation, it seems that binary encoding is legacy, but not deprecated. Since this instructional example works and is a simpler way to explain the concept (returning a custom encoding), we'll leave it as-is.


Added notefy: A simple notes taking app

I added a simple note-taking app with add and delete feature
I hope you like it:)

I merged the current changes so has to not have any conflicts while merging my PR

Good work! @Welf06


[Enhancement] Preseve time speed during cycle reset

This PR adds an enhancement that will preserve the current time speed through a cycle reset. So you won't need to play the Inverted Song of Time after each reset if you prefer having a slower time speed.

Build Artifacts

2ship-mac.zip
2ship-linux.zip
2ship-windows.zip

This enhancement will also retain a time speed set through the Save Editor over a cycle reset.

May want an initial value for timeSpeedOffsetCopy for sanity's sake but it doesn't look like it should be necessary

I'll get an initial value set. I think I should have time to get it added later today.

Added an initial value of 0 to match what is set during a vanilla cycle reset.


SourceCodePro+Powerline+Awesome Not working in Chrome 55 on Win10

I'm trying to use the fonts with Secure Shell in Chrome, and they're not displaying properly.  At first I thought it was my installation/method of usage, but after setting my mono-spaced font to SourceCodePro+Powerline+Awesome in the Chrome preferences, I'm beginning to think this is a Chrome incompatibility.
It displays fine in the preferences preview:

But when it comes to actually displaying text on a page, it fails:

If this is a Chrome issue, then so be it, but other iterations of SouceCodePro work without an issue in hterm (Secure Shell), so I'm not 100% sure where the problem lies.  If there's anything else I should try, let me know.

I don't know if you still have this issue but I bet you have better chances at overriding the CSS classes of Secure Shell in Chrome that make the patched font work. The patched font is kind of an hack for situations where you cannot use multiple fonts at once. Browsers supports the usage of multiple fonts and with Tampermonkey you can customize the appearence of Secure Shell, you can inject a CSS rule that forces the browser to display a certain range of codepoints with a specified font
@font-face {
    font-family: Foobar;
    src: local('Times New Roman');
    unicode-range: U+61-6E;
}


[BUG] Unexpected token } in JSON at position 10688

Describe the bug
Not sure when, but after updating to 1.4.6. This happens with all playlist ID
To Reproduce
Steps to reproduce the behavior:
Use any playlist ID. I tested the one in the documentation "PLx65qkgCWNJIgVrndMrhsedBz1VDp0kfm"
And call getPlaylist(playlistId)
Expected behavior
You should get the following error:
Unexpected token } in JSON at position 10688
at JSON.parse ()
at Object.parseGetPlaylist (...\node_modules\scrape-yt\dist\common\parser.js:274:36)
at ...\node_modules\scrape-yt\dist\index.js:162:64
at step ...\node_modules\scrape-yt\dist\index.js:54:23)
at Object.next (...\node_modules\scrape-yt\dist\index.js:35:53)
at fulfilled (...\node_modules\scrape-yt\dist\index.js:26:58)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
Screenshots
Here is a test code that I used

Can replicate, getVideo seems to be broken too, fixing this ASAP.

Version 1.4.7 should fix this, please update the package and try again.
Thank you for reporting this issue. 😁