TeslaMate divides every drive into little parts

Describe the bug
Every one of my drives are divided into small parts and counted as individual drives

Expected behavior
Should be listed as one drive.

How to reproduce it (as minimally and precisely as possible):
Go driving
(I'm running on docker and did not bother installing the MQTT part...)
Relevant entries from the logs
Args: [#Function<3.4852099/1 in TeslaMate.Mqtt.PubSub.VehicleSubscriber.handle_info/2>, [is_preconditioning: false]]

14:22:17.846 [error] Task #PID<0.5210.0> started from #PID<0.5199.0> terminating
** (stop) exited in: GenServer.call(TeslaMate.Mqtt.Publisher, {:publish, "teslamate/cars/1/update_available", "false", [retain: true, qos: 1]}, 10000)
** (EXIT) an exception was raised:

    ** (ErlangError) Erlang error: :timeout_value

        (tortoise 0.9.5) lib/tortoise/connection.ex:328: Tortoise.Connection.connection/2

        (tortoise 0.9.5) lib/tortoise.ex:269: Tortoise.publish/4

        (teslamate 1.20.1) lib/teslamate/mqtt/publisher.ex:41: TeslaMate.Mqtt.Publisher.handle_call/3

        (stdlib 3.12.1) gen_server.erl:661: :gen_server.try_handle_call/4

        (stdlib 3.12.1) gen_server.erl:690: :gen_server.handle_msg/6

        (stdlib 3.12.1) proc_lib.erl:249: :proc_lib.init_p_do_apply/3

(elixir 1.10.4) lib/gen_server.ex:1023: GenServer.call/3

(elixir 1.10.4) lib/task/supervised.ex:90: Task.Supervised.invoke_mfa/2

(elixir 1.10.4) lib/task/supervised.ex:35: Task.Supervised.reply/5

(stdlib 3.12.1) proc_lib.erl:249: :proc_lib.init_p_do_apply/3

nction: &:erlang.apply/2
Args: [#Function<3.4852099/1 in TeslaMate.Mqtt.PubSub.VehicleSubscriber.handle_info/2>, [update_available: false]]

paste logs here

Screenshots

Data

Environment

TeslaMate version: 1.20.1
Type of installation: Docker
OS TeslaMate is installed on: Linux
User OS & Browser: Linux
Others:

I'm having the same issues. Once the car starts driving Teslamate starts receiving messages it chokes on. I haven't installed the MQTT  part either and have Teslamate running in docker.
@adriankumpf Can you tell me what info you still need?
 I forgot to set DISABLE_MQTT in the env variables. @rybber78 did you perhaps forget as well?

Yup, can confirm DISABLE_MQTT=true setting fixes it. Please close.

Where did you enter this variable?

When starting the docker container, it's set as an environment variable with the -e switch.
docker run -e DISABLE_MQTT=true teslamate/teslamate:latest

When starting the docker container, it's set as an environment variable with the -e switch.
docker run -e DISABLE_MQTT=true teslamate/teslamate:latest

Super! it finally works. Thank you

Hello,
since the last Update (1.20 -> 1.20.1), I have the same problem with the devided drives.
TeslaMate version: 1.20.1
Type of installation: Docker
OS TeslaMate is installed on: RaspBerry Stretch
User OS & Browser: Windows / Firefox

I've tried the workaround
docker run -e DISABLE_MQTT=true teslamate/teslamate:latest"
but it didn't work with my system.

Do you have some other ideas to fix the problem?
Thank you very much.

You'll need to include a few more environment variables than just MQTT_DISABLE such as DATABASE_USER, DATABASE_PASS, etc. As seen at https://docs.teslamate.org/docs/configuration/environment_variables/.  I just shortened my example down to the one variable for brevity. Each one will require its own -e switch.
docker run -e MQTT_DISABLE=true -e DATABASE_USER=the_user -e DATABASE_PASS=mypassword -e DATABASE_HOST=dbserver.org -e DATABASE_PORT=5432 -e DATABASE_NAME=mydb teslamate/teslamate:latest
There are a
If you're using the Docker compose method seen here https://docs.teslamate.org/docs/installation/docker then you'll want to add MQTT_DISABLE=true under the environment list, while removing MQTT_HOST=mosquitto.
-------- Original Message --------
From: Strobi-Boy<EMAIL_ADDRESS>Sent: November 21, 2020 9:56:14 a.m. MST
To: adriankumpf/teslamate<EMAIL_ADDRESS>Cc: Brendan Ward<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [adriankumpf/teslamate] TeslaMate divides every drive into little parts (#1063)
Hello,
since the last Update (1.20 -> 1.20.1), I have the same problem with the devided drives.
TeslaMate version: 1.20.1
Type of installation: Docker
OS TeslaMate is installed on: RaspBerry Stretch
User OS & Browser: Windows / Firefox

I've tried the workaround
docker run -e DISABLE_MQTT=true teslamate/teslamate:latest"
but it didn't work with my system.

Do you have some other ideas to fix the problem?
Thank you very much.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/adriankumpf/teslamate/issues/1063#issuecomment-731604907
Sent from my Android device

Thanks for the fast response.
I have replaced "MQTT_HOST=mosquitto" with " MQTT_DISABLE=true" and started the docker again "docker -compose up -d" - but it seems, that I have also other troubles?

What is going wrong with my TeslaMate?
I also have installed the openWB at this RaspBerry.
Thanks for your advice.

I'm experiencing the exact same problem as Strobi-Boy with waiting for Postgres at <IP_ADDRESS>...  And I'm also using the Docker version.  I am guessing I'm not stopping, pausing or "down"ing Docker in the right way.
My guess is the steps should be:

Stop Docker
Change docker-compose.yml
Start Docker

But I am too new at Docker to figure out what I am doing wrong.  (I'm still learning about Docker but I haven't come across the right ways to do this!)

You don't need to stop docker. Do a "docker-compose up" again after changing the file. It will update the configuration and restart any containers it needs to.

Hello,
I have changed the "compose.yml"...

...and restartet the Docker - but the problem with the splitted drives is already there:

Do you have any more tips to solve the problem?
Thank you.

Do anyone has any idea, how to fix the problem?
It was since the last TeslaMate - Update...

You'll need to add some logs from your container as well as the entire compose file and your currently running docker containers (docker ps) . There's not enough information right now to help.
If I had to guess one of the components is not running properly after you tried to install it twice.

Hello,
where do I find the logs from my container?
This is the compose file:
version: "3"
services:
teslamate:
image: teslamate/teslamate:latest

restart: always

environment:

  - DATABASE_USER=teslamate

  - DATABASE_PASS=secret

  - DATABASE_NAME=teslamate

  - DATABASE_HOST=database

  - MQTT_DISABLE=true

ports:

  - 4000:4000

volumes:

  - ./import:/opt/app/import

cap_drop:

  - all

database:
image: postgres:13

restart: always

environment:

  - POSTGRES_USER=teslamate

  - POSTGRES_PASSWORD=secret

  - POSTGRES_DB=teslamate

volumes:

  - teslamate-db:/var/lib/postgresql/data

grafana:
image: teslamate/grafana:latest

restart: always

environment:

  - DATABASE_USER=teslamate

  - DATABASE_PASS=secret

  - DATABASE_NAME=teslamate

  - DATABASE_HOST=database

ports:

  - 3000:3000

volumes:

  - teslamate-grafana-data:/var/lib/grafana

mosquitto:
image: eclipse-mosquitto:1.6

restart: always

ports:

  - 1883:1883

volumes:

  - mosquitto-conf:/mosquitto/config

  - mosquitto-data:/mosquitto/data

volumes:
teslamate-db:
teslamate-grafana-data:
mosquitto-conf:
mosquitto-data:
This are the runnig docker containers:
pi@RaspBerryPi:~ $ docker ps
CONTAINER ID        IMAGE                        COMMAND                  CREATED             STATUS              PORTS                    NAMES
8e97b234e274        postgres:13                  "docker-entrypoint.s…"   3 days ago          Up 3 days           5432/tcp                 pi_database_1
bb29a3dd2403        teslamate/grafana:latest     "/run.sh"                7 days ago          Up 3 days           <IP_ADDRESS>:3000->3000/tcp   default_grafana_1
ce006396bdf6        teslamate/teslamate:latest   "/sbin/tini -- /bin/…"   7 days ago          Up 4 hours          <IP_ADDRESS>:4000->4000/tcp   default_teslamate_1
2e99bd1e16ac        postgres:12                  "docker-entrypoint.s…"   7 days ago          Up 3 days           5432/tcp                 default_database_1

docker-comopose logs
oder
docker-comopose logs -f
Oder
docker-comopose logs teslamate

Here we go:
$ docker-compose logs
/usr/local/lib/python3.5/dist-packages/paramiko/transport.py:33: CryptographyDeprecationWarning: Python 3.5 support will be dropped in the next release ofcryptography. Please upgrade your Python.
from cryptography.hazmat.backends import default_backend
Attaching to pi_mosquitto_1, pi_grafana_1, pi_teslamate_1, pi_database_1
database_1   |
database_1   | PostgreSQL Database directory appears to contain a database; Skipping initialization
database_1   |
database_1   | 2020-11-21 17:47:13.459 UTC [1] LOG:  starting PostgreSQL 13.1 (Debian 13.1-1.pgdg100+1) on arm-unknown-linux-gnueabihf, compiled by gcc (Debian 8.3.0-6) 8.3.0, 32-bit
database_1   | 2020-11-21 17:47:13.459 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
database_1   | 2020-11-21 17:47:13.459 UTC [1] LOG:  listening on IPv6 address "::", port 5432
database_1   | 2020-11-21 17:47:13.474 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
database_1   | 2020-11-21 17:47:13.510 UTC [27] LOG:  database system was shut down at 2020-11-21 17:46:56 UTC
database_1   | 2020-11-21 17:47:13.560 UTC [1] LOG:  database system is ready to accept connections
database_1   | 2020-11-21 17:47:42.103 UTC [1] LOG:  received fast shutdown request
database_1   | 2020-11-21 17:47:42.404 UTC [1] LOG:  aborting any active transactions
database_1   | 2020-11-21 17:47:42.411 UTC [1] LOG:  background worker "logical replication launcher" (PID 33) exited with exit code 1
database_1   | 2020-11-21 17:47:42.415 UTC [28] LOG:  shutting down
database_1   | 2020-11-21 17:47:44.697 UTC [1] LOG:  database system is shut down
database_1   |
database_1   | PostgreSQL Database directory appears to contain a database; Skipping initialization
database_1   |
database_1   | 2020-11-21 17:49:50.717 UTC [1] LOG:  starting PostgreSQL 13.1 (Debian 13.1-1.pgdg100+1) on arm-unknown-linux-gnueabihf, compiled by gcc (Debian 8.3.0-6) 8.3.0, 32-bit
database_1   | 2020-11-21 17:49:50.719 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
database_1   | 2020-11-21 17:49:50.719 UTC [1] LOG:  listening on IPv6 address "::", port 5432
database_1   | 2020-11-21 17:49:50.740 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
database_1   | 2020-11-21 17:49:50.779 UTC [26] LOG:  database system was shut down at 2020-11-21 17:47:44 UTC
database_1   | 2020-11-21 17:49:50.938 UTC [1] LOG:  database system is ready to accept connections
$ docker-compose logs -f
/usr/local/lib/python3.5/dist-packages/paramiko/transport.py:33: CryptographyDeprecationWarning: Python 3.5 support will be dropped in the next release ofcryptography. Please upgrade your Python.
from cryptography.hazmat.backends import default_backend
Attaching to pi_mosquitto_1, pi_grafana_1, pi_teslamate_1, pi_database_1
database_1   |
database_1   | PostgreSQL Database directory appears to contain a database; Skipping initialization
database_1   |
database_1   | 2020-11-21 17:47:13.459 UTC [1] LOG:  starting PostgreSQL 13.1 (Debian 13.1-1.pgdg100+1) on arm-unknown-linux-gnueabihf, compiled by gcc (Debian 8.3.0-6) 8.3.0, 32-bit
database_1   | 2020-11-21 17:47:13.459 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
database_1   | 2020-11-21 17:47:13.459 UTC [1] LOG:  listening on IPv6 address "::", port 5432
database_1   | 2020-11-21 17:47:13.474 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
database_1   | 2020-11-21 17:47:13.510 UTC [27] LOG:  database system was shut down at 2020-11-21 17:46:56 UTC
database_1   | 2020-11-21 17:47:13.560 UTC [1] LOG:  database system is ready to accept connections
database_1   | 2020-11-21 17:47:42.103 UTC [1] LOG:  received fast shutdown request
database_1   | 2020-11-21 17:47:42.404 UTC [1] LOG:  aborting any active transactions
database_1   | 2020-11-21 17:47:42.411 UTC [1] LOG:  background worker "logical replication launcher" (PID 33) exited with exit code 1
database_1   | 2020-11-21 17:47:42.415 UTC [28] LOG:  shutting down
database_1   | 2020-11-21 17:47:44.697 UTC [1] LOG:  database system is shut down
database_1   |
database_1   | PostgreSQL Database directory appears to contain a database; Skipping initialization
database_1   |
database_1   | 2020-11-21 17:49:50.717 UTC [1] LOG:  starting PostgreSQL 13.1 (Debian 13.1-1.pgdg100+1) on arm-unknown-linux-gnueabihf, compiled by gcc (Debian 8.3.0-6) 8.3.0, 32-bit
database_1   | 2020-11-21 17:49:50.719 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
database_1   | 2020-11-21 17:49:50.719 UTC [1] LOG:  listening on IPv6 address "::", port 5432
database_1   | 2020-11-21 17:49:50.740 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
database_1   | 2020-11-21 17:49:50.779 UTC [26] LOG:  database system was shut down at 2020-11-21 17:47:44 UTC
database_1   | 2020-11-21 17:49:50.938 UTC [1] LOG:  database system is ready to accept connections
pi_mosquitto_1 exited with code 128
pi_teslamate_1 exited with code 128
pi_grafana_1 exited with code 128
$ docker-compose logs teslamate
/usr/local/lib/python3.5/dist-packages/paramiko/transport.py:33: CryptographyDeprecationWarning: Python 3.5 support will be dropped in the next release ofcryptography. Please upgrade your Python.
from cryptography.hazmat.backends import default_backend
Attaching to pi_teslamate_1

No idea why drives are splitted?
Charges will work correctly!

If there is no possibility to fix the problem, is it possible save the TeslaMate Data and to remove the TeslaMate / Docker installation completely?
How to restore the TeslaMate data after the reinstall?

Hello,
I have reinstalled my Raspberry with Stretch & openWB - I have the same problems with Teslamate.
All drives are devides into small parts.

The following logs are attached:
Teslamate Log.txt
Teslamge Logs.txt

docker ps

pi@raspberrypi:~ $ docker ps
CONTAINER ID        IMAGE                        COMMAND                  CREATED             STATUS                          PORTS                    NAMES
7c1467b5341b        teslamate/teslamate:latest   "/sbin/tini -- /bin/…"   2 minutes ago       Restarting (1) 28 seconds ago                            pi_teslamate_1
fdaaa48487e5        postgres:13                  "docker-entrypoint.s…"   3 days ago          Up 3 days                       5432/tcp                 pi_database_1
f509f707f65c        teslamate/grafana:latest     "/run.sh"                9 days ago          Up 8 days                       <IP_ADDRESS>:3000->3000/tcp   pi_grafana_1

I've tried a little bit and changed the mosquitto port from 1883 to 1882 and now it seems, that it work - but not 100% correct:

The old data ist gone - but the drives will be displayed correct - but without informations about the consumption:

Some informations in the drive details are also missing:

@Strobi-Boy your fist issue was caused by you accidentally installing teslamate twice. The remnants of the fist installation were reserving ports which caused the second installation to fail to start properly.
Your second issue seems to be caused by something holding on to the default port of mosquitto, Did you completely wipe your raspberry pi or are there still some docker images running from the previous installs?
You then changed the port mapping of your MQTT container, so any connection made to 1883 from the outside is going to go to 1882. This is fine as long as you instruct the MQTT process inside the container to also bind to 1882 which I don't see you doing. Resulting in any data sent by Teslamate to mosquitto:1883 to end up in a black hole. I'm actually surprised it's not causing a fatal error in Teslamate.

In the meantime I've tried several new installations (both with stretch and buster).

New installation:
sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade
sudo reboot
curl -sSL https://get.docker.com | sh
sudo usermod -aG docker pi
sudo reboot
docker run hello-world
sudo apt-get install -y libffi-dev libssl-dev
sudo apt-get install -y python3 python3-pip
sudo apt-get remove python-configparser
sudo apt install postgresql libpq-dev postgresql-client
sudo apt-get update && sudo apt-get upgrade
sudo pip3 -v install docker-compose
curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py && sudo python3 get-pip.py
sudo apt-get update && sudo apt-get install
sudo apt-get update && sudo apt-get dist-upgrade
sudo reboot
sudo nano docker-compose.yml (insert Script from https://docs.teslamate.org/docs/installation/docker/)
docker-compose up -d

Every time I first install TeslaMate and then OpenWB (to control the wallbox), TeslaMate splits the trips into small parts.
How can I check, which tools will connect to the default port of mosquitto? Because I have made some new & clean installs and it will take place every time. Teslamate is the only image which will run in docker.
How can I change the default-port of 1883 to another port (including MQTT process), so that Teslamate can work as it shoud?

In the meantime I've tried several new installations (both with stretch and buster).
Are you sure any traces of the old installations you tried are gone?

How can I check, which tools will connect to the default port of mosquitto?
lsof -i | grep LISTEN will probably work for this

Are you sure any traces of the old installations you tried are gone?

Yes - I installed a new and fresh Buster / Stretch (FULL) with the few steps i wrote.
So it was a clean installation with no old connections.
I changed the port so 1883:1833 and started Teslamate again:

lsof -i | grep LISTEN will probably work for this

It will show this:


Enhanced Edit (Pilot) unable to Save Count Rollup

If you attempt to create a rollup with the Count operation it fails to save with the error 'Required fields are missing: [Field to Aggregate]'. This is because this field is marked as required.
Workaround is to not use the Enhanced Edit and edit using the Standard Salesforce UI, placing any field in the Field to Aggregate (it is not used in a Count scenario).

So i think its best we close bugs on the old Custom Object VF UI for rollups. This issue relates to the drop downs on these pages, there is another enhancement to add these to the new custom metadata based VF page. I think effort should go into doing that, than fixing these. Happy to re-open these bugs if anyone disagrees. 👍


[iOS] google maps stuttering / sticking issue when controlling region changes with component state / onRegionChange

react-native version: 47.1
react-native-maps version: 0.16.2
Setting the region in the component state and using onRegionChange (and on RegionChangeComplete) to control the map region causes the map to stutter during touch events on iOS. Sometimes the map gets stuck completely.
This issue occurs when using Google Maps. It is not an issue when using Apple Maps. It also functions as expected on Android.

Did you resolve this? I'm experiencing the same thing.

I suggest not controlling region, use animateTo...
See example: https://github.com/react-community/react-native-maps/issues/209#issuecomment-350907665

@alvelig Then perhaps the documentation should be updated to not offer a poor solution?

@tmaly1980 could you make a PR that would improve the docs? 🤗

@rborn I unfortunately don't know what the solution is. I've switched to onRegionChangeComplete, but it only fires/refreshes once at the end after the drag is complete, so I'm not sure if that's a foolproof solution.

@tmaly1980 controlling state is still a legitimate solution but unfortunately I don't know how to solve this problem with this approach. I recommend using animateToRegion. That is what my experience says.

Everything is working fine on RNM 0.17.0. Once I went to 0.20.1 it started to stutter.

For the beginners who came here for the solution, check this out. :)


Fetch missions

The goal is to fetch data from the provided  Missions endpoint when a user navigates to the Missions section.
actions

Created action creators and reducers
Created a display for the fetched mission data

Good coding skills! It is ready to be merged!


[Bug]: OpenAI batch file format pydantic validation error

Your current environment
Collecting environment information...
PyTorch version: 2.3.0+cu121
Is debug build: False
CUDA used to build PyTorch: 12.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.4 LTS (x86_64)
GCC version: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Clang version: Could not collect
CMake version: version 3.30.0
Libc version: glibc-2.35

Python version: 3.10.14 (main, May  6 2024, 19:42:50) [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-<IP_ADDRESS>-microsoft-standard-WSL2-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: 12.1.105
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 4080 Laptop GPU
Nvidia driver version: 556.12
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture:                       x86_64
CPU op-mode(s):                     32-bit, 64-bit
Address sizes:                      39 bits physical, 48 bits virtual
Byte Order:                         Little Endian
CPU(s):                             32
On-line CPU(s) list:                0-31
Vendor ID:                          GenuineIntel
Model name:                         13th Gen Intel(R) Core(TM) i9-13900HX
CPU family:                         6
Model:                              183
Thread(s) per core:                 2
Core(s) per socket:                 16
Socket(s):                          1
Stepping:                           1
BogoMIPS:                           4838.39
Flags:                              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq vmx ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves avx_vnni umip waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize flush_l1d arch_capabilities
Virtualization:                     VT-x
Hypervisor vendor:                  Microsoft
Virtualization type:                full
L1d cache:                          768 KiB (16 instances)
L1i cache:                          512 KiB (16 instances)
L2 cache:                           32 MiB (16 instances)
L3 cache:                           36 MiB (1 instance)
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit:        Not affected
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Not affected
Vulnerability Retbleed:             Mitigation; Enhanced IBRS
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass:    Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:           Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:           Mitigation; Enhanced IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS SW sequence
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Not affected

Versions of relevant libraries:
[pip3] flashinfer==0.0.8+cu121torch2.3
[pip3] numpy==1.26.4
[pip3] nvidia-nccl-cu12==2.20.5
[pip3] torch==2.3.0
[pip3] torchvision==0.18.0
[pip3] transformers==4.42.3
[pip3] triton==2.3.0
[conda] flashinfer                0.0.8+cu121torch2.3          pypi_0    pypi
[conda] numpy                     1.26.4                   pypi_0    pypi
[conda] nvidia-nccl-cu12          2.20.5                   pypi_0    pypi
[conda] torch                     2.3.0                    pypi_0    pypi
[conda] torchvision               0.18.0                   pypi_0    pypi
[conda] transformers              4.42.3                   pypi_0    pypi
[conda] triton                    2.3.0                    pypi_0    pypi
ROCM Version: Could not collect
Neuron SDK Version: N/A
vLLM Version: 0.5.1
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled
GPU Topology:
GPU0    CPU Affinity    NUMA Affinity   GPU NUMA ID
GPU0     X                              N/A

Legend:

  X    = Self
  SYS  = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI)
  NODE = Connection traversing PCIe as well as the interconnect between PCIe Host Bridges within a NUMA node
  PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
  PXB  = Connection traversing multiple PCIe bridges (without traversing the PCIe Host Bridge)
  PIX  = Connection traversing at most a single PCIe bridge
  NV#  = Connection traversing a bonded set of # NVLinks

🐛 Describe the bug
Running this command to do batch inference through API, returns the following error. The input.jsonl is as per required format.
python -m vllm.entrypoints.openai.run_batch -i input.jsonl -o results.jsonl --model Granther/Gemma-2-9B-Instruct-4Bit-GPTQ --max_model_len 3000
Error Traceback:

[rank0]: Traceback (most recent call last):
[rank0]:   File "/home/arsal/anaconda3/envs/vllm/lib/python3.10/runpy.py", line 196, in _run_module_as_main
[rank0]:     return _run_code(code, main_globals, None,
[rank0]:   File "/home/arsal/anaconda3/envs/vllm/lib/python3.10/runpy.py", line 86, in _run_code
[rank0]:     exec(code, run_globals)
[rank0]:   File "/home/arsal/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/entrypoints/openai/run_batch.py", line 146, in
[rank0]:     asyncio.run(main(args))
[rank0]:   File "/home/arsal/anaconda3/envs/vllm/lib/python3.10/asyncio/runners.py", line 44, in run
[rank0]:     return loop.run_until_complete(main)
[rank0]:   File "/home/arsal/anaconda3/envs/vllm/lib/python3.10/asyncio/base_events.py", line 649, in run_until_complete
[rank0]:     return future.result()
[rank0]:   File "/home/arsal/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/entrypoints/openai/run_batch.py", line 130, in main
[rank0]:     responses = await asyncio.gather(*response_futures)
[rank0]:   File "/home/arsal/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/entrypoints/openai/run_batch.py", line 93, in run_request
[rank0]:     response=BatchResponseData(
[rank0]:   File "/home/arsal/anaconda3/envs/vllm/lib/python3.10/site-packages/pydantic/main.py", line 193, in init
[rank0]:     self.pydantic_validator.validate_python(data, self_instance=self)
[rank0]: pydantic_core._pydantic_core.ValidationError: 1 validation error for BatchResponseData
[rank0]: body
[rank0]:   Field required [type=missing, input_value={'status_code': 400, 'req...5c4a7799ad445a114ebff4'}, input_type=dict]
[rank0]:     For further information visit https://errors.pydantic.dev/2.8/v/missing

The "body" field should be Optional (e.g. when there are errors), let me send a fix.


what's the speed to detect a 720P image  with MaskRCNN model on the framework?

hi,
I have a question, what's the speed to detect a 720P image with MaskRCNN model on the framework?

SimpleDet mainly focuses on training speed. If you want to deploy the trained model, we recommend the tensor rt runtime which should be one-order faster than any detection framework.


Next.js example

Hello, would be cool to have a Next.js example in README showing how to combine clientside and server side fetching

Hi! It's been a long since I've used Next.js. Do you have any examples how it can be done?
In react applications I'm using awesome-graphql-client in combination with swr for client-side caching and cache revalidation.

@lynxtaa
something to start with:
import React, { useState } from 'react'
import { NextPage } from 'next'

type Props = { initialData: ... }

const Page: NextPage<Props> = ({ initialData }) => {
  const [data, setData] = useState(initialData)

  useEffect(() => {
    // do something
    setData(...)
  }, [something])

  return ...
}

Page.getInitialProps = async ({ req, res }) => {
  // do something

  return { initialData }
}

Solved in https://github.com/lynxtaa/awesome-graphql-client/pull/5


How can i get id of new saved entity?

Is possible to use like Entity framework?
using (var context = new MyContext())
{
context.MyEntities.Add(myNewObject);
context.SaveChanges();
int id = myNewObject.Id; // it's here
}

If I'm not wrong this is already there


Migrate off deprecated serviceList and over to IntrospectAndCompose

Latest versions of gateway have deprecated serviceList in favour of using IntrospectAndCompose.  Change example to use latest/up-to-date configuration options.
The `serviceList` option is deprecated and will be removed in a future version of `@apollo/gateway`. Please migrate to its replacement `IntrospectAndCompose`. More information on `IntrospectAndCompose` can be found in the documentation.
IntrospectAndCompose failed to update supergraph with the following error: Couldn't load service definitions for "shows" at http://localhost:8080/graphql: request to http://localhost:8080/graphql failed, reason: connect ECONNREFUSED <IP_ADDRESS>:8080
/Users/jc/dev/dgs-federation-example/apollo-gateway/node_modules/@apollo/gateway/dist/supergraphManagers/IntrospectAndCompose/loadServicesFromRemoteEndpoint.js:50
            throw new Error(errorMessage);
                  ^

Thanks for the pr that addressed this issue @theJC .


mmap() failed: Cannot allocate memory size

Since my two last release, I have several crashes about realm size file (according crash report):
Fatal error: 'try!' expression unexpectedly raised an error: Error Domain=io.realm Code=9 "mmap() failed: Cannot allocate memory size:<PHONE_NUMBER> offset: 0" UserInfo={NSLocalizedDescription=mmap() failed: Cannot allocate memory size:<PHONE_NUMBER> offset: 0, Error Code=9}: file
or
crash_info_entry_0 Fatal error: 'try!' expression unexpectedly raised an error: Error Domain=io.realm Code=2 "Unable to open a realm at path '/var/mobile/Containers/Data/Application/B30A63B7-0584-4841-860C-9B62844112ED/Documents/default.realm': Invalid top array (ref: 90691440, size: 0) Exception backtrace: 0 Realm 0x0000000106aeeea8 _ZNK5realm9SlabAlloc6verifyEv + 376 1 Realm 0x0000000106b8e778 _ZN5realm5Group18validate_top_arrayERKNS_5ArrayERKNS_9SlabAllocE + 1364 2 Realm 0x0000000106b96f94 _ZN5realm11SharedGroup7do_openERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEEbbNS_18SharedGroupOptionsE + 3224 3 Realm 0x0000000106ab5c58 _ZN5realm5_impl11RealmFriend13read_group_toERNS_5RealmENS_9VersionIDE + 4644 4 Realm 0x0000000106ab58ec _ZN5realm5_impl11RealmFriend13read_group_toERNS_5RealmENS_9VersionIDE + 3768 5 Realm 0x0000
At the first init of my realm instance.
I think it’s not possible the file size should be as big. We don’t save enough data to have this file size.
I don’t reproduce the issue, I just see it in the crash reporting.
I have to get the current user from the database in the application delegate. In the didFinishLaunchingWithOptions method.
Goals
Fetch data from DB
Expected Results
Get data from DB
Actual Results
Crash
Steps to Reproduce
I don’t reproduce the issue, I just see it on my crash report. I print my personal realm file size and I’ve 65536bytes.
Code Sample
In Appdelegate / didFinishLaunchingWithOptions
Realm.Configuration.defaultConfiguration = Realm.Configuration(schemaVersion: dbVersion, migrationBlock: { _, _ in })
realm = try! Realm()
let predicate = NSPredicate(format: "identifier == %@", argumentArray: [userId])
let currentUser = realm.objects(User.self).filter(predicate).first

The application crash at the initialization of the realm instance.
Version of Realm and Tooling
Xcode: 11.3.1
Realm Object Server version: N/A
RealmSwift: 4.3.1
Thanks for advances.

One of Realm's current limitations is that a Realm file cannot be larger than the amount of memory your application would be allowed to map in iOS. The exception you're seeing occurs when iOS denies Realm's attempt to map further memory, indicating that you've reached the maximum file size we support for that device. There are a few ways you can attempt to work around this limitation:

Split your data across multiple Realms, being sure to close those you're not actively using to minimize memory usage.

Compact your Realm file on launch, as described here

Be sure that all write actions are in autoreleasepool { ... }
If you can share further information about the types of data you're storing, or even a sample dataset, we can provide more specific advice. If you're not comfortable sharing this information publicly feel free to do so privately by emailing<EMAIL_ADDRESS>and referencing this GitHub issue.

我也遇到同样的问题了。不过我们的文件达到了6442450944 。以下是错误日志：
*** Terminating app due to uncaught exception 'RLMException', reason: 'mmap() failed: Cannot allocate memory size:<PHONE_NUMBER> offset: 0' *** First throw call stack: (0x1b99b896c 0x1b96d1028 0x10582d684 0x1057fdcbc 0x1057fef28 0x1057fec4c 0x1057fd618 0x104decde4 0x104c593b8 0x1bdaafc18 0x1bdab1a14 0x1bdab7340 0x1bd24fbec 0x1bd701518 0x1bd250724 0x1bd250154 0x1bd250540 0x1bd24fdc4 0x1bd254544 0x1bd71b39c 0x1bd62d7bc 0x1bd71b354 0x1bd25425c 0x1bd71b23c 0x1bd2540b8 0x1bd0bc434 0x1bd0baef8 0x1bd0bc164 0x1bdab5730 0x1bd64f6bc 0x1bebade10 0x1bebd4aa0 0x1bebb8ef4 0x1bebd4734 0x1b965dfd8 0x1b9660d1c 0x1bebfb254 0x1bebfaf00 0x1bebfb46c 0x1b9934108 0x1b993405c 0x1b99337c8 0x1b992e694 0x1b992df40 0x1c3bbe534 0x1bdab9580 0x1050ad9b8 0x1b97ace18)

Be sure that all write actions are in autoreleasepool { ... }

Really? That doesn't in the document.
I thought we only need it if we are using realm on worker thread.


nvidia-smi missing from tensorflow:latest-gpu-py3-jupyter docker container (TF 2.1.0)

Hey all,
I just upgraded my codebase to TF 2.1.0 and as such also started using the "latest" container instead of the 1.15.x container I was using before.
My pipeline relies on nvidia-smi to get information about the memory utilization of the GPUs and other things, but I was disappointed to see that the tool has been seemingly removed from the container in the newer versions.
Can anyone else confirm this? I just get a "no such file or directory" and I can't find the binary or symbolic link in /usr/bin/.
Thanks!

Actually it seem the problem is only with my specific setup. Because if I run:
docker run --gpus=all tensorflow/tensorflow:latest-gpu-py3-jupyter nvidia-smi

it works...
Could it be because I use docker-compose and set the default runtime to be nvidia?

Nevermind, I just had to clear all my cached images and build again. Somehow there were some leftovers that were messing with the base image.


Rendering issue of components with border style - components appear stretched while rendering a new screen

Description
After upgrading to 0.73.2 we've started observing a rendering issue of components that contain some border styles - when screens are rendered components like that are temporarily unnaturally stretched as the new screen enters the view area.
We didn't see issues like that using 0.72.6.
Sometimes it's the border, sometimes the background of the component and sometime the issue cannot be observed at all
In our app we have some other components, which would sometimes appear as stretched when entering new screen, but the sample project, with a list of components was the easiest way to reproduce it
Steps to reproduce

Install pods with yarn setup
Install the app on iOS emulator with yarn ios
Press Reload button on main screen or go to the next screen using + button in the top right corner
Observe how elements with border are initially stretched when a screen is rendering and then shows correctly

React Native Version
0.73.2
Affected Platforms
Runtime - iOS
Output of npx react-native info
System:
  OS: macOS 14.2.1
  CPU: (8) arm64 Apple M2
  Memory: 97.02 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 21.3.0
    path: /opt/homebrew/bin/node
  Yarn:
    version: 1.22.21
    path: /opt/homebrew/bin/yarn
  npm:
    version: 10.2.4
    path: /opt/homebrew/bin/npm
  Watchman:
    version: 2<IP_ADDRESS>
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.12.1
    path: /Users/jkosecki/.rbenv/shims/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.0
      - iOS 17.0
      - macOS 14.0
      - tvOS 17.0
      - watchOS 10.0
  Android SDK: Not Found
IDEs:
  Android Studio: 2023.1 AI-231.9392.1.2311.11255304
  Xcode:
    version: 15.0.1/15A507
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.9
    path: /usr/bin/javac
  Ruby:
    version: 2.7.6
    path: /Users/jkosecki/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.73.2
    wanted: 0.73.2
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: true

Stacktrace or Logs
None

Reproducer
https://github.com/jankosecki/rn-border-issue-repro/tree/main
Screenshots and Videos

https://github.com/facebook/react-native/assets/41573247/04c69f21-a532-40eb-adc7-0249a6bd31fd
https://github.com/facebook/react-native/assets/41573247/b2cf12c6-50e0-4d34-94f7-1cd104ae03e1

I had a look how borders are rendered and did some modifications  to invalidateLayer of RCTViewComponentView.mm and discovered some things:

setting useCoreAnimationBorderRendering to hard-coded true fixes the rendering issue of smudged components with borderWidth but it leads Separator component to disappear
changing logic to const bool useCoreAnimationBorderRendering = !(borderMetrics.borderWidths.top == 0 && borderMetrics.borderWidths.bottom == 1); (matches exactly the style of Separator), renders separators correctly + smudging doesn't happen

From the above, looks like the else block of condition on useCoreAnimationBorderRendering is required for some specific cases but it also leads to the issue. I wonder if the observed smudging comes then from _borderLayer (created when useCoreAnimationBorderRendering == false) being invalidated and re-rendered constantly as the view is re-rendered.
I don't see any direct changes in this part of the file that happened between v0.72.10 and 0.73.10 so possibly root cause lies somewhere else
diff --git a/node_modules/react-native/React/Fabric/Mounting/ComponentViews/View/RCTViewComponentView.mm b/node_modules/react-native/React/Fabric/Mounting/ComponentViews/View/RCTViewComponentView.mm
index d06b0aa..fad933a 100644
--- a/node_modules/react-native/React/Fabric/Mounting/ComponentViews/View/RCTViewComponentView.mm
+++ b/node_modules/react-native/React/Fabric/Mounting/ComponentViews/View/RCTViewComponentView.mm
@@ -588,16 +588,17 @@ - (void)invalidateLayer
   }

   // Stage 2. Border Rendering
-  const bool useCoreAnimationBorderRendering =
-      borderMetrics.borderColors.isUniform() && borderMetrics.borderWidths.isUniform() &&
-      borderMetrics.borderStyles.isUniform() && borderMetrics.borderRadii.isUniform() &&
-      borderMetrics.borderStyles.left == BorderStyle::Solid &&
-      (
-          // iOS draws borders in front of the content whereas CSS draws them behind
-          // the content. For this reason, only use iOS border drawing when clipping
-          // or when the border is hidden.
-          borderMetrics.borderWidths.left == 0 ||
-          colorComponentsFromColor(borderMetrics.borderColors.left).alpha == 0 || self.clipsToBounds);
+  // const bool useCoreAnimationBorderRendering =
+  //     borderMetrics.borderColors.isUniform() && borderMetrics.borderWidths.isUniform() &&
+  //     borderMetrics.borderStyles.isUniform() && borderMetrics.borderRadii.isUniform() &&
+  //     borderMetrics.borderStyles.left == BorderStyle::Solid &&
+  //     (
+  //         // iOS draws borders in front of the content whereas CSS draws them behind
+  //         // the content. For this reason, only use iOS border drawing when clipping
+  //         // or when the border is hidden.
+  //         borderMetrics.borderWidths.left == 0 ||
+  //         colorComponentsFromColor(borderMetrics.borderColors.left).alpha == 0 || self.clipsToBounds);
+  const bool useCoreAnimationBorderRendering = !(borderMetrics.borderWidths.top == 0 && borderMetrics.borderWidths.bottom == 1);

   if (useCoreAnimationBorderRendering) {
     layer.mask = nil;

@cortinico any suggestions where to look further into that? I tried to add RCTLog to understand better values being used in invalidateLayer but it's called way too many times to learn anything from there

@cortinico any suggestions where to look further into that? I tried to add RCTLog to understand better values being used in invalidateLayer but it's called way too many times to learn anything from there

Is this happening also on Android by any chance?
I see you have the New Architecture enabled on iOS. Does the issue reproduces also on Old Architecture?

No, the issue has never been observed on Android.
I can confirm that the issue is not reproducible on old architecture. And the issue started happening only after upgrading to 0.73 - on 0.72 everything was working fine.

@jankosecki Did you find any quick solution for this?

suffer from the same problem

Same here on 0.73.4 :/

any update?

We have the same problem

Great work @jankosecki 🥇
I can confirm that the patch fixes our issue! 🎉

iOS: Native (before / after)

Before
After

Fixed properly in 0.73.6 (https://github.com/facebook/react-native/commit/d9794916b0549330513fe530abf090fa48b8a776) instead of a patch which just reverts the changes.
We've been using the version for a while and no issues have been spotted so far.
@ikevin127 my patch simply reverts some unwanted changes but the code is considered to be computation heavy (that's why it was removed in the first place). You might want to upgrade to 0.73.6 instead of using my patch to bring an actual fix to the issue.

@jankosecki Sure, Expensify already has an open PR to upgrade to v0.74 which once merged will remove the patch.
I noticed that with the patch, first paint is not instant - but it fixes out issue for now so all good. Thanks again!


Develop Testing Plan for HIVE 3 uses (built around use cases)

Beginning with the assemblyQC protocol - test to see what is need to make this run and produce a dataset in HIVE 3, and can be digested by HIVE 3 APIS.

Testing will be completed by Millicent for the first couple rounds.

@millicentq I have moved all relevant tickets over to the Peacock Repo, and we have broken these down into smaller tasks. I will mark this as done and close this ticket.


Render graphs with jupyter book

Hi all,
Apart from the two commands below:
alt.data_transformers.enable('data_server')
alt.renderers.enable('mimetype')
Please also add the following if you want to render the graphs by jupyter book:
alt.renderers.enable('altair_saver', fmts=['vega-lite', 'svg'])

Archive this issue.


[ja] Localize Continuous Deployment (CD) for Japanese

Describe your changes
Localize Continuous Deployment (CD) for Japanese
Related issue number or link (ex: resolves #issue-number)
resolves #2694
Checklist before opening this PR (put x in the checkboxes)

[x] This PR does not contain plagiarism

don’t copy other people’s work unless you are quoting and contributing it to them.

[x] I have signed off on all commits

signing off (ex: git commit -s) is to affirm that commits comply DCO. If you are working locally, you could add an alias to your gitconfig by running git config --global alias.ci "commit -s".

@naonishijima
レビューありがとうございます、修正したので再度ご確認いただけると幸いです


Making path in HTML file indentical

Description
Make the path for every occurrence in the HTML file be ./src
Screenshots

Please add a screenshot if applicable

Hi @jomefavourite ! I have raised a PR resolving this. Can you look into it?
https://github.com/chryz-hub/chryz-hub.github.io/pull/137

Hi @jomefavourite ! I have raised a PR resolving this. Can you look into it?
https://github.com/chryz-hub/chryz-hub.github.io/pull/137

Okay, I'll go through it now


Fix multiple ScreenContexts on ScreenView events (close #495)

As described in the #495 issue the ScreenView events could be tracked with multiple ScreenContexts.
This is caused by the erroneous management of the list of state machines.
During the computation of the entities to add to the event, the tracker gets a list of state machines for the specific event schema, then it gets a list of state machines that can be used with each event (filter: "*"). Unfortunately, the latter was added directly to the first list causing duplication. More ScreenView tracked caused even more duplications.
I've fixed it making a clone of the list rather than using that directly.
The iOS tracker is not affected because it correctly makes a clone.

Thanks for your pull request. Is this your first contribution to a Snowplow open source project? Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
:memo: Please visit https://docs.snowplowanalytics.com/docs/contributing/contributor-license-agreement/ to learn more and sign.
Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.


index.php not loading.

Hi, I an not able to load the page, I know that the directory is working since I added a php info test page and it works. I ran all the loads here with no errors.
screen -dmS geth geth --rpcaddr <IP_ADDRESS> --rpcport 8983 --rpc --unlock COINBASE_ADDRESS
screen -dmS process_work php /var/www4/block_processing/process_work/index.php
screen -dmS block_processing php /var/www4/block_processing/index.php
screen -dmS update_calculator php /var/www4/block_processing/update_calculator/index.php
screen -dmS stats php /var/www4/block_processing/stats/index.php
but are getting this error here:
root#####:~/Pool# curl http://<IP_ADDRESS>:9846/check/
curl: (7) Failed to connect to <IP_ADDRESS> port 9846: Connection refused
I am running on Azure, and the port is open.
Is PHP 7 good?
on the config file...  'bdd' => 'database name goes here'?

Are you sure that you configured nginx server block for mainpage directory ? Why 9846?

I am using Apache. and it is configured correctly for main-page. I added the php test file there and tested it successfully.
9846 was in your test tile. I thought it was configured as that. Where for I check this configuration?

Maybe this can help see my issue...
root@ETHER:~/Pool/mainpage# sudo php index.php
PHP Warning:  include(/var/www4/BigInteger.php): failed to open stream: No such file or directory in /root/Pool/mainpage/index.php on line 3
PHP Warning:  include(): Failed opening '/var/www4/BigInteger.php' for inclusion (include_path='.:/usr/share/php') in /root/Pool/mainpage/index.php on line 3
PHP Fatal error:  Uncaught Error: Class 'Memcached' not found in /root/Pool/mainpage/index.php:17
Stack trace:
#0 {main}
  thrown in /root/Pool/mainpage/index.php on line 17

If your pool is not placed in /var/www4/ then you need to correct path of BigInteger.php in each file.

Thanks!

one more Question :) (for now)
On this line screen -dmS geth geth --rpcaddr <IP_ADDRESS> --rpcport 8983 --rpc --unlock XXXXXXXXXX
Can I use any wallet address or it has to be the one I got o server install?


Check ToObject() coercion semantics for Object built-ins

For example, in ES5.1 Object.getOwnPropertyNames(123) is a TypeError but it is treated by ES6 the same as Object.getOwnPropertyNames(Object(123)).
Go through all Object built-ins and check for ToObject() coercion changes.

I have a pull open for this but it kept breaking tests and I was too lazy to fix them, so... :)

Hmm, do you mean a branch and not a pull?

Sorry, thought this was the Linenoise pull :)

Right, #1028 could fix this behavior.

Yeah, #1028 is the pull.

Fixing this is bound to break testcases as you noted in #1028 so there's some trivia fixing to do.
Further, if this is implemented without config options for the behavior, it means you can't compile an ES5 compliant build from master because that throwing behavior is strictly mandatory in ES5/ES5.1. But maintaining variable ES5 and post-ES5 behavior is also awkward extra work. I've been able to skirt this issue to a reasonable extent so far but I guess it's decision time :-)
My preference would be to just keep master tracking the latest specification for all the implemented behavior - but make it possible to configure for ES5ish build where the bindings are from ES5 but semantics trivia like coercion behavior may be from ES6 or above. This should work for all users except those wanting exact ES5/ES5.1 compliance.
If taking the route of maintaining an ES5.1 build, test coverage will be needed for ES5.1 and ES-latest and it must be possible to write testcases targeting the ES5.1 variant vs. the ES-latest variant.

So to be clear, I think that ES5.1 variant issue needs to be thought out first before making the change. Otherwise there would be a de facto decision in master (= ES-latest only).

There's also a grey area issue for versioning when changes are made to align better with ES6: those changes can be thought of as fixing bugs in ES6 (or ES7 or whatever) support, but they can also be viewed as incompatible changes to ES5 support.
The practical concern is that with the latter interpretation any minute change to align with ES6 requires a major release. That might mean that most releases would be major releases because ES6 features are implemented in small parts.

I guess the question to ask is whether strict ES5 compliance is meaningful given the existence of later standards.
In the past you've described Ecmascript as a living standard.  To me that implies any changes made to the specification are meant to be retroactive - if you don't follow the current behavior then you're out of compliance.  This seems to be ECMA's intent as well, given the switch from explicit numbered versions to year-based ones ("ECMAScript 2015") as well as the fact that this page only links to the latest version (ES7 at the time of writing):
http://www.ecma-international.org/publications/standards/Ecma-262.htm
Even if one doesn't buy that "retroactive" reasoning, there's still the real-world issue that the legacy behavior will become surprising to JS developers as later specifications are adopted (case in point: https://github.com/svaarala/duktape/pull/1078#issuecomment-260234237 ;-).  As such it's questionable how often such an option would be utilized in practice.  IMO it's far more likely that those strapped for footprint will simply disable bindings to keep code size down while maintaining the ES-latest behavior.

I guess the question to ask is whether strict ES5 compliance is meaningful given the existence of later standards.

Well that's a very well defined target, and there are several reasons to want an ES5 compliant environment. It's widely supported, and there are multiple (even embedded) engines providing ES5 support so you can switch between engines relatively easily. For embedded environments it's a stable target which is good if you just want a stable scripting environment instead of constantly changing one: not everyone desires the latest and greatest :)
Duktape is currently described as an ES5/ES5.1 engine with some borrowed ES6/ES7 features. That more or less implies ES5.1 is the "dominant" specification while later features are borrowed. If master adopts a "target ES-latest" approach, this would need to be changed so that Duktape targets the latest specification (but is not a complete implementation of it, yet), but with an ES5-ish subset for low memory targets. This would be a pretty clear target too.

To me that implies any changes made to the specification are meant to be retroactive [...]

The changes in the specification are clearly "retroactive" in that they break existing behaviors and, potentially, existing code relying on those behaviors. But that doesn't really tell you what to do with versioning: semantic versioning guarantees are, on the face of it, pretty straightforward:
    MAJOR version when you make incompatible API changes,
    MINOR version when you add functionality in a backwards-compatible manner, and
    PATCH version when you make backwards-compatible bug fixes.

They're not always easy to interpret in practice IMO. For example, if you fix a bug it's perfectly possible someone was relying on that buggy behavior by accident, so that the fix is not backwards compatible in that case and a major version bump would be necessary to fix the bug.
Similarly, what does it mean to "add functionality" in concrete terms? Adding new global object bindings, for example, is not necessarily backwards compatible if some application already used a binding of that name. C API additions are much easier to understand: new functions don't matter if you don't call them.
Changing ES5 semantics already present in master automatically means a major version bump because it's not backwards compatible. This is easy to demonstrate with any piece of code that checks for the old vs. new behavior, and there's no telling if an application might rely on that behavior intentionally, or maybe more likely, by accident.
One can sort of fudge that situation by targeting "ES-latest" and treating any deviances as bugs. This means that if you install a minor upgrade, anything may change if a later specification version requires it. It's not very clean but it is practical.
Because semantic versioning is about managing expectations of changes in library versions, it's also important to state clearly what the functional target is. If the target is (a subset of) ES-latest, then it's not so surprising if things change to align better with later specifications.
It'd also be possible to just use semantic versioning conservatively and just make any release major if it changes any existing behaviors. That would, in practice, mean most releases would be major. But since we're not going to run out of numbers, that would be a viable approach too.

That retroactive argument does seem to hold some merit: ECMA describes earlier specifications as "historical", having been "replaced" by later editions:

The previous replaced "historical" editions of this Ecma Standard are available here [link].

Right, but where does semantic versioning allow that to mean incompatible changes can be made in minor versions?
It's about versioning expectations, and incompatible changes in minor versions are not expected.

This is from semver FAQ:

If even the tiniest backwards incompatible changes to the public API require a major version bump, won’t I end up at version 42.0.0 very rapidly?
This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you’ll think through the impact of your changes, and evaluate the cost/benefit ratio involved.

So it's considered a feature that incompatible changes require a major version number so you'd think about the changes before making them.
Unfortunately that doesn't work very well for tracking a "living standard" because quite a lot of changes will become major if one takes that literally. It's difficult to implement features piece by piece and releasing often.
I've tried to manage this problem earlier by describing which parts are under semver guarantees and which parts are not: http://duktape.org/guide.html#versioning. This works reasonably well for a static specification target which affects the C API and the Ecmascript bindings so that e.g. Object.getPrototypeOf() doesn't have a yearly changing behavior ;-) For example config options, debugger protocol, and bytecode dump/load format are not under semver guarantees because that would again make most changes major.
Regardless of the outcome for this issues, that guide section should describe what semver guarantees are in place, in order to provide clear expectations of what a patch version, a minor version, and a major version mean for Duktape. Semver is, after all, about expectations when seeing a library version be updated.

No, I get that, the argument I was making was re: whether or not to keep "strict ES5 behavior" as an option, I'm not disagreeing with the semantic versioning logic at all.  It seems we may have shifted gears somewhere along the way without me realizing it. :)

Ah, I see :) This is what I've been talking about (quoting myself):

The practical concern is that with the latter interpretation any minute change to align with ES6 requires a major release. That might mean that most releases would be major releases because ES6 features are implemented in small parts.

So the grey area concern is that changing Object.getPrototypeOf() coercing behavior is a major release if one reads semver literally.
That seems quite odd - but we could do that.
In essence that would mean that a release would be intended initially as a minor one, but the first commit to introduce a change to existing C or Ecmascript API behavior, regardless of how small, would cause the release to be major. That makes planning milestones in advance a bit difficult but I'm sure that can be worked around.

Regarding what to target, like I said above, I lean towards implementing newest features incrementally, but maintaining an ES5-like subset for low memory targets. The differences are small enough to often not matter (though I'm sure someone specifically wants ES5 compliance; I've been asked for that quite many times) and ES6+ is a bit too large for some embedded targets.
Then again, it would be equally possible to define the project target as: ES-latest, with the ability to configure subsets of it as necessary. For example, drop RegExps (ES5), but include WeakMap and symbols (ES6). There would then be no ES5 promise anymore, but instead a promise to be able to configure subsets reasonably well to control code and RAM footprint. This is already possible pretty well so maybe it would be enough as a target.

Just to recap why semver entered the discussion: with a fixed ES5.1 + extras target semver is reasonably straightforward at least for the ES5.1 part. With an ES-latest target semver becomes more difficult in practice because releases tend to be major releases - or one needs to relax on the semver interpretation a bit. So that's why these two issues are somewhat connected.
But that's just about semver specifics which may need further thought if the project goal is ES-latest "living standard" rather than a more fixed target. Semver is also not fixed in stone; if it doesn't work out well then it's of course possible to change versioning schemes.

Assuming the project goes with the ES-latest route and won't maintain a strict ES5 compliant configuration, the change in this issue (ToObject() coercions) should be done for 2.0 because they're backwards incompatible. The next opportunity for that would be 3.0.

Agreed.  Presumably in that case DUK_USE_ES6 would (eventually) be removed as well?

DUK_USE_ES6 doesn't mean "use ES6 semantics" but it's a placeholder config option for including ES6 bindings that don't have specific config options. It would still be needed for providing an ES5-ish environment, i.e. for footprint control.

Implemented by #1028. Master is also new ES5-ish w.r.t. versioning.


Tunnel hang w/ nested engines

If you use the v0.11.7 CLI and run e.g. dagger -m . call --source=.:default test custom --timeout=10m --run=TestModuleDaggerUp --pkg=./core/integration --race=true --parallel=8 on main you'll currently get a hang after the tests pass.

Note: this won't currently impact any users, it's only an issue on main atm when using v0.11.7 as the CLI

This is due to OTEL draining spans from the CLI's session attachable server (engine logs show waiting on TunnelListener/Listen). The CLI is getting killed ungracefully in those tests which causes the span to never end currently.
@vito has graceful shutdown for these processes implemented in https://github.com/dagger/dagger/pull/7532
Creating this issue to just make sure we either merge that PR before the next release or spin out the fixes from it to a separate smaller PR, don't want this to get lost in noise.

Will also note that technically this means there's still an issue in the case where a client does get ungracefully killed. There is a small patch that "fixes" that case by just getting rid of these spans:
diff --git a/engine/client/client.go b/engine/client/client.go
index 38753be80..80537f729 100644
--- a/engine/client/client.go
+++ b/engine/client/client.go
@@ -28,7 +28,6 @@ import (
        bksession "github.com/moby/buildkit/session"
        "github.com/moby/buildkit/session/auth/authprovider"
        "github.com/moby/buildkit/util/grpcerrors"
-       "github.com/moby/buildkit/util/tracing"
        "go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc"
        "go.opentelemetry.io/otel"
        "go.opentelemetry.io/otel/propagation"
@@ -442,13 +441,6 @@ func NewBuildkitSessionServer(ctx context.Context, conn net.Conn, attachables ..
                grpc.UnaryInterceptor(grpcerrors.UnaryServerInterceptor),
                grpc.StreamInterceptor(grpcerrors.StreamServerInterceptor),
        }
-       if span := trace.SpanFromContext(ctx); span.SpanContext().IsValid() {
-               statsHandler := tracing.ServerStatsHandler(
-                       otelgrpc.WithTracerProvider(span.TracerProvider()),
-                       otelgrpc.WithPropagators(propagation.NewCompositeTextMapPropagator(propagation.TraceContext{}, propagation.Baggage{})),
-               )
-               sessionSrvOpts = append(sessionSrvOpts, grpc.StatsHandler(statsHandler))
-       }

        srv := grpc.NewServer(sessionSrvOpts...)
        grpc_health_v1.RegisterHealthServer(srv, health.NewServer())

However, this really just masks the problem by not sending as many spans that rely on clients shutting down gracefully, as opposed to fixing the general problem of handling clients exiting ungracefully, so it should be more of a last resort.

Fixed by https://github.com/dagger/dagger/pull/7660


Issue with parsing 7-Zip version if alpha version is installed

Expand-7zipArchive helper function has an issue with parsing 7-Zip version information.
The function does not fail, but uses PowerShell built-in Expand-Archive commandlet instead.
This is not ideal, because Expand-Archive has an issue with paths over 260 charaters long.
That can lead to a different issue / error, which I will file separately.
The issue is triggered on systems where an unreleased version of 7-Zip is installed.
Tested with 7-Zip version: "21.01 alpha".
The problem is with this line of code:
$use7zip = [decimal]::Parse([System.Diagnostics.FileVersionInfo]::GetVersionInfo($7zipPath).FileVersion, [System.Globalization.CultureInfo]::InvariantCulture) -ge 19

The exception thrown is this one:
Exception calling "Parse" with "2" argument(s): "Input string was not in a correct format."
Version checking code was added as a solution for this issue: #1138
Proposed solution
Solution is to avoid parsing the file version information and use FileMajorPart property instead.
This line of code fixes the issue:
$use7zip = [System.Diagnostics.FileVersionInfo]::GetVersionInfo($7zipPath).FileMajorPart -ge 19

Pull request with a fix for this issue: #1914

Thanks for the PR - I have merged it.

I'm glad I was able to make a small contribution to an otherwise great tool.

Shipped in 2.0.12


0.8.2 Installation issue on Linux

Expected behavior
With gauge 0.8.2 gauge --install java should install the latest version of gauge-java.
Actual behavior
Failed to get configuration from Gauge properties file. Error: open /root/.gauge/config/gauge.properties: no such file or directory

Steps to reproduce

apt-get install -y gauge
gauge --install java

Gauge version
0.8.2
Looks like side affect of https://github.com/getgauge/gauge/issues/544

@haroon-sheikh Can you please check your GAUGE_ROOT environment variable? Make sure it's empty or points to the location where the gauge configurations are. By default, the configuration should be at $HOME/.gauge/config.

@BugDiver GAUGE_ROOT env variable is empty.

@haroon-sheikh The new installers copies gauge configuration files to $USER level.
Some steps which might resolve your issue:-

Run gauge_setup after installation.
check permissions for your .gauge dir. If  It or It,s children directories doesn't have user permissions, Please remove your .gauge repo and do the installation again.

v0.8.3 fixes this issue.


fix: npm releases failing to generate provenance (#3800)

Backport
This will backport the following commits from k8s-28/main to k8s-26/main:

fix: npm releases failing to generate provenance (#3800)

Questions ?
Please refer to the Backport tool documentation

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 3801

Questions ?
Please refer to the Backport tool documentation


TR should default to using TO API 5.0

This Improvement request (usability, performance, tech debt, etc.) affects these Traffic Control components:

Traffic Router

Current behavior:

TR defaults to using TO API 4.0 if it doesn't have any profile parameters specifying which API URLs to use.
New behavior:

TR should default to using TO API 5.0 if it doesn't have any profile parameters specifying which API URLs to use.

Update complete.


Metadata V15: Expose pallet documentation

This patch captures the pallet documentation declared on the pallet module.
The documentation added to this pallet is later on included in the runtime metadata.
The documentation can be defined in the following ways:
#[pallet::pallet]
/// Documentation for pallet 1
#[doc = "Documentation for pallet 2"]
#[doc = include_str!("../README.md")]
#[pallet_doc("../doc1.md")]
#[pallet_doc("../doc2.md")]
pub struct Pallet<T>(_);

The runtime metadata for this pallet contains the following

" Documentation for pallet 1" (captured from ///)
"Documentation for pallet 2"  (captured from #[doc])
content of ../README.md       (captured from #[doc] with include_str!)
content of "../doc1.md"       (captured from pallet_doc)
content of "../doc1.md"       (captured from pallet_doc)

doc attribute
The value of the doc attribute is included in the runtime metadata, as well as
expanded on the pallet module. The previous example is expanded to:
/// Documentation for pallet 1
/// Documentation for pallet 2
/// Content of README.md
pub struct Pallet<T>(_);

pallet_doc attribute
The pallet_doc attribute can only be provided with one argument,
which is the file path that holds the documentation to be added to the metadata.
Unlike the doc attribute, the documentation provided to the proc_macro attribute is
not inserted at the beginning of the module.
Testing Done
Besides the unit-test and UI tests from this patch:

added this on top of the final metadata V15 PR (from branch https://github.com/paritytech/substrate/tree/lexnv/md15_runtime_api_v1_docs_md_bk)
frame-metadata branch (https://github.com/paritytech/frame-metadata/tree/lexnv/md_v15_test_docs)
subxt (https://github.com/paritytech/subxt/tree/lexnv/md_v15_bk_md_docs)

    index: 36,
    docs: [
        "# Assets Module\n\nA simple, secure module ...",
        " Hello",
    ],

Part of https://github.com/paritytech/substrate/issues/12939.
Closes https://github.com/paritytech/frame-metadata/issues/47.
// CC @paritytech/tools-team

bot rebase

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:
https://forum.polkadot.network/t/polkadot-release-analysis-v0-9-40/2468/1

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:
https://forum.polkadot.network/t/stablising-v15-metadata/2819/1


Add websocket source

Related to #47
Just thinking from the top of my head:

maybe an Enum is better for the scheme, maybe add TCP_UDP (if empty, then try TCP before UDP)
some parsing error would be nice (e.g. pattern should be empty if TCP or UDP)

Will check asap

The code still does not fully compile (I didn't get what you want to do with name) but I took out most of the errors

Now we have a working implementation, happy to press merge anytime.
Can you confirm it works on your side?

@xoolive Yeah, it's working. Well done!


Add shortDOI to allowed formats in landing.js

Closes https://github.com/Impactstory/oadoi/issues/3

This requires more work on the backend to support shortDOI. See discussion on #3.


Fix coverage workflow

Codecov Report

Merging #845 (7367e40) into main (57dd3c1) will decrease coverage by 4.11%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #845      +/-   ##
==========================================
- Coverage   85.38%   81.27%   -4.12%
==========================================
  Files         320      348      +28
  Lines       29697    31200    +1503
==========================================
  Hits        25358    25358
- Misses       4339     5842    +1503

Impacted Files
Coverage Δ

cmd/pen/src/test_module_compiler.rs
0.00% <0.00%> (ø)

lib/infra/src/test_linker.rs
0.00% <0.00%> (ø)

cmd/pen/src/test_linker.rs
0.00% <0.00%> (ø)

cmd/pen/src/prelude_module_compiler.rs
0.00% <0.00%> (ø)

lib/infra/src/llvm_command_finder.rs
0.00% <0.00%> (ø)

cmd/pen/src/package_creator.rs
0.00% <0.00%> (ø)

lib/infra/src/command_runner.rs
0.00% <0.00%> (ø)

lib/infra/src/external_package_initializer.rs
0.00% <0.00%> (ø)

cmd/pen/src/infrastructure.rs
0.00% <0.00%> (ø)

cmd/pen/src/main_package_directory_finder.rs
0.00% <0.00%> (ø)

... and 18 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 c48eb13...7367e40. Read the comment docs.


TS 2.0.3 wrongly clears VS2015 "Find Symbol Results" panel

TypeScript Version: 2.0.3
When using "Find All References" in VS2015 in any language (e.g. C#) and the project has tsconfig.json, a typescript file, and any NPM @types package, then the "Find Symbol Results" panel is occasionally cleared for no obvious reason.
I've checked and this doesn't seem to happen when using typings or if there's no tsconfig.json
Steps To Reproduce

Create a new Web Application - MVC project (both MVC5 and ASP.NET Core seem to break for me, but I'll continue my steps with MVC5)
Add a tsconfig.json file to the root of the project, this only needs to contain the outer curly braces.
In a command line in the root of the website run npm install @types/jquery --save
Add a typescript file to the project (e.g. /Scripts/Site.ts)
Open a C# file with a class referenced in other files (e.g. /Models/AccountViewModels.cs") and close all other files.
Do a find all references on a symbol in that file (e.g. ExternalLoginConfirmationViewModel.Email)
Navigate through the list of results in the "Find Symbol Results" panel.
After a moment the "Find Symbol Results" panel clears

Expected behavior:
The results in the "Find Symbol Results" panel remains until a new "Find All References" is executed.
Actual behavior:
The results are cleared.

I do not see how this is related to TS or @types. The TS language service does not clear any windows. Roslyn is what drives this for both C# and TS. i would recommend filing this issue on https://github.com/dotnet/roslyn instead.

never mind. looks like we do clear the window. we should not do this.

Cool, thanks for confirming @mhegazy. I was a little skeptical of what the actual cause was even though everything thing I could see pointed to TypeScript, so it's good to know I'm not crazy.

Any news on a fix for this, it is pretty annoying?

I am experiencing this issue as well. I am using ts v2.0.6 in VS2015 since it was released, but I noticed my Symbol Results disappearing only a few weeks ago. Makes me wonder if I might have caused it with some setting change or something.
Any update on this would be appreciated.

Glad to see some repro steps for this. It happens regularly to me, usually while trying to scrutinize a long list of references. :( I never saw this behaviour until using typescript so that was my hunch too as the culprit.

I upgraded to version 2.2.2 for VS2015 and the reference list problem seems to be fixed. Awesomeness!
So this issue can probably be closed.

@mhegazy Any updates on this issue? It drives me nuts. It also happens in VS2017.2 (not only VS2015).

This bug is extremely aggravating, please address ASAP.

Offtopic: This bug, in addition to the painfully slow TypeScript IntelliSense in VS2017 actually forced me to switch to VS Code. Got used to it in a day. Very good stuff: chrome debugging (w/extension), blazing fast TypeScript support (IntelliSense and quick fixes are working instantly) and TypeScript linting (w/extension and tslint).

I just upgraded to VS2017 and was disappointed to see this bug is still there. (I know this has already been mentioned.) I too have been tinkering with VS Code off and on, although I still find it a bit limited in features. I agree it does a better job with "Find All References", though.

I'm having some trouble repro'ing this issue.  Should I expect to see it every time I run the steps above or only occasionally?  So far, I've tried in VS 2015 Update 3 and VS 2015 Update 3 (internal build).

@mhegazy Do you have any more details about where in the code the results list is being cleared?

As @mhegazy pointed out, we do in fact clear that window whenever a script project is updated or deleted (in a method called, logically enough, ClearFindSymbolPane).  This appears to affect both VS2015 and VS2017.  I have yet to determine what, specifically, is triggering the project changes, but, presumably, it's happening in the background and causing the results window to be cleared when it completes.

This is probably not exactly the same issue, but if you create a C# project and find all references to a C# symbol, adding a TS file to the project will clear the results.  There's no race - it happens every time.

I'm primarily working on a large project with both C# and TypeScript, I am also experiencing this problem, and I find this bug EXTREMELY frustrating.
Could the call to ClearFindSymbolPane be happening due to changes in the "TypeScript Virtual Projects" project? Would it be possible to ignore changes to that project for the purposes of calling ClearFindSymbolPane?

@slugworth that exactly matches my understanding of the problem.  However, I'm still trying to determine what the call was protecting against (I understood it was a crash, but I've been unable to repro it) and what other mitigation is required if we remove the call.

@amcasey Thanks for your reply. If it is possible for me to test a build that omits or handles the call, I would be thrilled to help.

Thanks, @slugworth, I'll do my best to keep this issue up-to-date with our progress.

@amcasey Hello! I was wondering if there has been any progress? This issue is very frustrating to those who want to use TypeScript while developing in a large code base. Thanks!

@jvernon-panopto We have a tentative fix in progress for VS 2015 (which would become available in an update to the TS SDK).  In VS 2017, we made a lot of changes to this part of the code and we're still investigating the best way forward.

@amcasey Awesome, thanks for the quick reply! My organization uses VS2015, so I am selfishly excited to hear that a fix for VS2015 sounds close. If there aren't any unforeseen testing issues, what's your timeline for a patch?

@jvernon-panopto For obvious reasons, we don't speculate about timelines. :wink:

We've submitted the VS 2015 fix, so it should be in an upcoming SDK update.

@amcasey Awesome! Thanks! Is there a way I can run a latest/nightly with this fix on my local VS2015 instance? Would "npm install -g typescript@next" suffice?

@jvernon-panopto, Unfortunately, this fix is on the VS side, so updating the npm package will not suffice.  I'll be sure to post here as soon as it's available. 😄

We now have a tentative fix for VS 2017 as well.  It should be available in a future update.

Hello! I see you have closed this issue. How can I retrieve a fix for VS2015? Thanks!

@jvernon-panopto, I think the fix made it into the RC of TS SDK 2.5: https://www.microsoft.com/en-us/download/details.aspx?id=48593


feat: Data consumers prefer text labels for download and viewer (#3465)

#3465

Reviewers
Functional:

Changes

Replaced the download and explore svg icon buttons with text buttons "Download" and "Explore" as per mock.
See slack discussions here and here for the following adjustments to requirements:

The text "Viewer" should be "Explore".
Remove the unwanted tooltip e.g. "Download" and "Explore". Note, the tooltip "Exploration is currently unavailable for datasets with more than 2 million cells" remains.
The update to the button styles (primary and primary outlined) will be reflected in other buttons such as "Publish" and "Add" on the collection page and "Save" in the create collection modal.
Table cell line height has been increased to 20px.
The "Delete Collection" button styles on the collection page has been updated to match the adjacent buttons.

Hey @frano-m thanks so much for the PR! I see that this is in draft, so probably not ready for review yet? Thank you 😄

Hey @tihuan, sorry I've only seen your message now... I was waiting for some confirmation on button positioning... It's good to go now thank you!


Topic with array of predefined size type message

Issue template

Hardware description: STM32F7
RTOS: FreeRTOS
Installation type: static library
Version or commit hash: foxy

Steps to reproduce the issue
I have defined a subscriber to a topic as usual on my client. the message type is
capra/Vector3 data[4]

I see the struct generated as follows
typedef struct capra__msg__Array
{
  capra__msg__Vector3 data[4];
} capra__msg__Array;

I can also see that there's a method generated on the functions.c, that would initialize the array of size 4 as it should.
My code compiles, I see the topic is announced, I see the correct data type, however, when the subscription is triggered, the message doesn't get filled and everything is full of 0's.
I couldn't find any example with a fixed size array.
Furthermore, one thing that got my attention is that all the array message types I found, have, besides the data member, a sequence member, which I don't have on my message. I guess this is because of the fixed size?
Anyways, I can't get my array to work. I'll try out using one of the built-in types to compare

Do you have both the publisher and the subscriber in the same micro-ROS node? Or the subscriber is in ROS 2? Can you describe the setup or share a snippet to replicate this?

The publisher is ROS2 (from the terminal) the subscriber is on micro-ROS.
I'll see if @anastasiapan can provide some snippet.

The publisher is: ros2 topic pub --once --qos-durability=transient_local --qos-reliability=best_effort /topic capra/msg/Array "{data : [{x: 1.0, y: 2.0, z: 3.0},{x: 1.0, y: 2.0, z: 3.0},{x: 1.0, y: 2.0, z: 3.0},{x: 1.0, y: 2.0, z: 3.0}]}"
and the initialization happens just before the rclc_executor_add_subscription. We are using classes and the subscription part of the node looks like that:
capra__msg__Array__init(&msg_);

  rclc_result = rclc_executor_add_subscription(
    &executor_, &subscriber_, &msg_,
    [](const void * msgin) {
      const capra__msg__Array * msg = (const capra__msg__Array *)msgin;
    },
    ON_NEW_DATA);

When I publish the message it hits the breakpoint inside the callback and everything is initialized correctly to 0 and once I step over the message still remains at all zeros.

Found bug, coming with solution in a while

Please retest your code when https://github.com/micro-ROS/rosidl_typesupport_microxrcedds/pull/29 merged

Will do, and thanks again for the quick response.

https://github.com/micro-ROS/rosidl_typesupport_microxrcedds/pull/29 merged, I'm closing this preventively bc I think that the new implementation for Namespaced Arrays in micro-ROS type support will solve the issue.
Do not hesitate to reopen if you have any problems related to this.

It did fix the issue, we can now receive messages as expected. Thanks!


.rvm files are not generated

Hi,
I called javamop on few examples (shipped with javamop). The program said .rvm files and .aj files were generated, but .rvm files are missing!
In one case, I saw that some .rvm files were generated in the output path, but once the execution of javamop finished, those files disappeared!
I am using an Ubuntu 14.04.
Any clues are much appreciated,
Reza

Could you please share the exact command that you ran and the output that you got?

root@reza:/home/reza/Desktop/MOP/javamop/examples/CFG/SafeFile# javamop SafeFile.mop
-Processing SafeFile.mop
SafeFile.rvm is generated
SafeFileMonitorAspect.aj is generated
-Processing SafeFile.rvm
SafeFileRuntimeMonitor.java is generated
root@reza:/home/reza/Desktop/MOP/javamop/examples/CFG/SafeFile# ll
total 56
drwxrwxr-x 4 reza reza  4096 Oct 24 16:17 ./
drwxrwxr-x 5 reza reza  4096 Oct 24 15:00 ../
drwxrwxr-x 2 reza reza  4096 Jul 11  2015 SafeFile_1/
drwxrwxr-x 2 reza reza  4096 Jul 11  2015 SafeFile_2/
-rw-r--r-- 1 root root 34282 Oct 24 16:17 SafeFileMonitorAspect.aj
-rw-rw-r-- 1 reza reza   971 Jul 11  2015 SafeFile.mop
root@reza:/home/reza/Desktop/MOP/javamop/examples/CFG/SafeFile#
As you can see, there are no .rvm file, the only generated output is the .aj file.

Try this: mkdir out; javamop -d out SafeFile.mop
Both the .rvm and .aj files should now be stored in the out directory when execution is complete.

Also, did you install JavaMOP from sources or from the binary?

Nope. I had tried to save the output files in a folder, but still as you see, only the the aspectJ related file is generated there:
root@reza-Veriton-M6620G:/home/reza/Desktop/MOP/javamop/examples/CFG/SafeFile# javamop -d out SafeFile.mop
-Processing SafeFile.mop
SafeFile.rvm is generated
SafeFileMonitorAspect.aj is generated
-Processing SafeFile.rvm
SafeFileRuntimeMonitor.java is generated
root@reza-Veriton-M6620G:/home/reza/Desktop/MOP/javamop/examples/CFG/SafeFile# ll out/
total 44
drwxr-xr-x 2 root root  4096 Oct 24 16:39 ./
drwxrwxr-x 5 reza reza  4096 Oct 24 16:39 ../
-rw-r--r-- 1 root root 34282 Oct 24 16:39 SafeFileMonitorAspect.aj
root@reza-Veriton-M6620G:/home/reza/Desktop/MOP/javamop/examples/CFG/SafeFile#
It's from the binaries.

The binaries are out of sync with the sources, hence my previous suggestion. With the binaries, the keepRVFiles option should work for you, like so:
javamop -keepRVFiles SafeFile.mop
You can see an explanation for the keepRVFiles by running:
javamop -help
May I ask what you usage scenario for JavaMOP is?
@kheradmand, can you please look into making another release of the binaries?

Now the output are two files: .js file and a .java file (the monitor: SafeFileRuntimeMonitor.java).
I have now another issue. I am now trying to weave the code using ajc, but it complains (5 errors):
root@reza-Veriton-M6620G:/home/reza/Desktop/MOP/javamop/examples/CFG/SafeFile# ajc -1.6 -d out/ out/SafeFileMonitorAspect.aj out/SafeFileRuntimeMonitor.java SafeFile_1/SafeFile_1.java
/home/reza/Desktop/MOP/javamop/examples/CFG/SafeFile/out/SafeFileRuntimeMonitor.java:20 [error] The type SafeFileMonitor_Set is already defined
final class SafeFileMonitor_Set extends com.runtimeverification.rvmonitor.java.rt.tablebase.AbstractMonitorSet {
^^^^^^^^^^^^^^^^^^
/home/reza/Desktop/MOP/javamop/examples/CFG/SafeFile/out/SafeFileRuntimeMonitor.java:108 [error] The type ISafeFileMonitor is already defined
interface ISafeFileMonitor extends IMonitor, IDisableHolder {
^^^^^^^^^^^^^^^
/home/reza/Desktop/MOP/javamop/examples/CFG/SafeFile/out/SafeFileRuntimeMonitor.java:111 [error] The type SafeFileDisableHolder is already defined
class SafeFileDisableHolder extends DisableHolder implements ISafeFileMonitor {
^^^^^^^^^^^^^^^^^^^^
/home/reza/Desktop/MOP/javamop/examples/CFG/SafeFile/out/SafeFileRuntimeMonitor.java:133 [error] The type SafeFileMonitor is already defined
class SafeFileMonitor extends com.runtimeverification.rvmonitor.java.rt.tablebase.AbstractSynchronizedMonitor implements Cloneable, com.runtimeverification.rvmonitor.java.rt.RVMObject, ISafeFileMonitor {
^^^^^^^^^^^^^^
/home/reza/Desktop/MOP/javamop/examples/CFG/SafeFile/out/SafeFileRuntimeMonitor.java:547 [error] The type SafeFileRuntimeMonitor is already defined
public final class SafeFileRuntimeMonitor implements com.runtimeverification.rvmonitor.java.rt.RVMObject {
^^^^^^^^^^^^^^^^^^^^^
5 errors
Any idea?
By the way, I am also interested in run-time verification, so i'm learning now.

What command did you run?

Sorry, I see it in your message.

No more ideas?
I am wondering if you could release some last version of binaries? I have issues with building, too, and currently the binaries suit me the best.
I'd appreciate it

I know this is an old issue, sorry for bringing it up but was this issue ever resolved? Im following the instructions in here to build the agent but the rvm files are not generated for me as well.

So i think there are a few issues at hand here.

In the instructions mvn package does not work due to not being able to locate rv-monitor during package time:
Caused by: org.apache.maven.project.DependencyResolutionException: Could not resolve dependencies for project javamop:javamop:jar:4.0-SNAPSHOT: Failed to collect dependencies at com.runtimeverification.rvmonitor:rv-monitor:jar:[1.4,)

Using javamop binary downloaded from the javamop website for some reason fails to generate the rvm files.

What I did (or at least whats worked for me)

Build rv-monitor jar and then use mvn local install to install the rv-monitor jar file built from source.
a. Building rv-monitor only worked when using an ubuntu machine for me see here. It results in version 1.4 being built.
b. pom.xml in javamop expects version 1.3 for rv-monitor. I changed it to 1.4

Not sure what sort of chaos this would cause down the road but I'm able to build the agent for now.


Fix 'Can't get tsserver to work #164'

Fix https://github.com/neovim/nvim-lsp/issues/164

Thanks for a review! Fixed and rebased! ✅

@igrep Thanks :)

Hi! I'm very sorry to step in this PR, but it seems that this fix broke any non windows integration. I created another PR to try to fix the issue in all platforms: https://github.com/neovim/nvim-lsp/pull/224

Oh... sorry! I've forgotten the behavior of Lua...

This pull request has been mentioned on Neovim Discourse. There might be relevant details there:
https://neovim.discourse.group/t/neovim-configs-and-windows/4734/3


[wip] @bentwire Embassy changes

Okay that looks like everything, let me know if it looks good @bentwire and I'll merge it in

@fmckeogh  Looks good to me!


fix: BaseBuilder::getCompiledDelete() runs real query

Description
Fixes  #4180
Checklist:

[x] Securely signed commits
[ ] Component(s) with PHPdocs
[x] Unit testing, with >80% coverage
[ ] User guide updated
[x] Conforms to style guide

Thank you @kenjis

Thank you @kenjis

Thank you @kenjis


Add post about my benchmarking comparison of Rust, Kotlin, and Python

This post compares the execution speed of a collision detection algorithm in Rust, Kotlin, and Python. The code discussed in it comes from my major projects from both this year and last year.
@devinmatte just as a heads up, the table formatting looked a bit off when I build this locally. You may want to modify the table CSS before this goes up so it's more readable. Thanks!

Content LGTM! Someone else may want to check the table formatting, since I can't build locally right now.

I've pushed a commit that fixes those typos. Thanks @csssuf for pointing them out.

I think it makes the most sense to hold off on merging this until the table CSS is fixed. Thanks for approving it though.

Do we want to bump the date?

@JoelEager If you could push the date up to tomorrow, I'll be ready to merge

The date is updated and the tables look good. Thanks for everyone's help on this.


Ux/loginpage

RTL login page
Issue #58

@swedishfrenchpress @diogorsergio
Can we adjust this to the attached?

@saubyk I love it! I updated the source and export files to better match the mockup. Is there anything else I can do to help resolve issue?

Looking good from my side too! Thanks the awesome work @swedishfrenchpress. Just figuring something out with Github before merging the request.