Surprising behaviour with distributed Tensorflow

Hello, I'm observing some surprising behaviour with distributed Tensorflow, in terms of performance. In short, for the exact same Graph, I get a very different performance based on the machine I connect my tf.Session to.
In my experiments, I have two machines A and B in a cluster. Machine A has a GPU with cuDNN. I declare a graph that executes the cifar10 gpu example exclusively on machine A. No operators (including the variables) are declared on machine B. I log the device placement and Tensorboard does not see any operators associated with anything other device than machine A.
When I execute the graph, starting my session using tf.Session("grpc://machineA:2222", ... results in significantly better performance than using tf.Session("grpc://machineB:2222", .... It is also not just a constant overhead, as I increase the batch size, the difference seems to scale linearly:

Batch Size
Connect to machine A
Connect to machine B

128
0.19s
0.50s

256
0.38s
1.00s

512
0.74s
1.78s

1024
1.42s
3.38s

(Averaged over 10 iterations not including the first two)
When looking at the output of top on machine B, it does seem like python is doing some work when I connect to machine B as it averages around 30% CPU vs ~0% otherwise, but I cannot tell what that is/how to prevent it.
I am working with Tensorflow installed from source with commit ed1a947d5b306d74af24821110dc2eb2f36c038a.

Hi Valentin :).
So it sounds like you have three processes: a client (on machine A or B? or a third machine?), and two TensorFlow servers (one on machine A and one on machine B). If you connect to machine A and all of the ops are on machine A then all of the master<->worker traffic will be local; whereas if you connect to machine B and all of the ops are on machine A then all of the master<->worker traffic will cross the network. (I'm not sure about the client<->master traffic, because you didn't mention where the client is running. You might want to try putting the client in the same process as the machine A master, as I would expect that to give the best performance. That's the configuration we typically use for distributed TF.)
In the latter case, it's possible that 30% of machine B is being consumed by proxying RPCs between the client and machine A. You might be seeing latency because the "queue runners" that prefetch input data run sequentially and now have two network round trips per record, and you're now "I/O bound" (not actually bound by the disk, but by the steps that have to run to populate the input queues). You could try adding prefetching threads to the input pipeline to see if that improves things. (I'm assuming you're using a version of cifar10_multi_gpu_train.py, so no data is being fed or fetched in each training step.)
The input pipeline "protocol" is very chatty on the network, and we've been relying on most of the interactions happening in-process. Thanks for digging into this: it might give us good motivation to improve the batching etc.!

Hi Derek!
Thanks! That makes a lot of sense. Regarding the client location, I had tried either on machine A or B with little or no change in performance. So I had always left it on machine B so that the instructions were given from 1-hop away from the computes, although the batching may be different between client<->master and master<->worker?
I am still a little puzzled though because I just re-ran some experiments with a larger network (the second layer 64->2048 neurons) but I still get the same 2.5X ish drop in performance, even though the number of RPCs should be constant?
Here were the results:

Batch Size
Connect to machine A
Connect to machine B

128
2.06s
5.26s

256
3.76s
10.17s

The client was always on machine B again. It seemed like python was doing less work on top. I tried to change num_preprocess_threads in cifar10_input.py to 32 and 64 with no real change in performance.

That's surprising. Are you fetching anything in the call to sess.run() that you're measuring?

It's the train_op for the multi_gpu example. (The whole program is a slightly modified version of cifar10_multi_gpu_train.py)

Hello, just to say that I still get the same behaviour after updating to 0.8. I also had a look at the network traffic with tcpdump but it seemed similar in both settings. Any ideas on what could be going on?

I think what is going on is that when I connect the client to machine B, the operations of machine A don't get scheduled on the GPU. At least, I get the exact same behaviour when scheduling operations on the CPU. I wish I could make sure nothing is running on the GPU but nvidia-smi does not support my graphics card (GTX 780). But the behaviours do really match for multiple workloads.
I am not sure how to see why that would happen. Again, tensorboard tells me the operations are on the GPU.

Hmm, how are you determining that the operations are actually running on the GPU? The cifar10_multi_gpu_train.py example has allow_soft_placement=True, so there's a possibility that the code is being silently placed on the CPU instead of the GPU (not sure if that would account for the slowdown, as I'm not 100% familiar with the performance of that model, but it seems plausible). If you pass the flag --log_device_placement=True, what device does it show for the ops?

Indeed passing --log_device_placement=True shows the operations are not scheduled on the gpu. I've attached the two logs depending on which machine I use as master. ran(Machine A) has a gpu but trothy(Machine B) doesn't. Operations that should get scheduled on the gpu are under name scope ran_gpu.
Any idea on how I could use the gpu remotely without risking to break things with allow_soft_placement=False?
from_ran.txt
from_trothy.txt

Have you installed the GPU version on both machines? I think the placer uses information about the locally registered kernels to make placement decisions, so if you connect your session to a process that only has the CPU kernels, it won't use a GPU anywhere. (This is a bit embarrassing, and we should fix it....)

Ah that makes sense! No it was only the CPU version. Will it work for me to install the GPU version without cuda on the machine?

I believe it should... if not, let me know and we'll have to build a workaround!

Didn't work :-(

bazel build -c opt --config=cuda //tensorflow/tools/pip_package:build_pip_package
WARNING: Output base '/auto/homes/vd241/.cache/bazel/_bazel_vd241/bd4752ce1a8928ERROR: /local/scratch/vd241/tensorflow/third_party/gpus/cuda/BUILD:187:1: declared output 'third_party/gpus/cuda/cuda.config' is a dangling symbolic link.
ERROR: /local/scratch/vd241/tensorflow/third_party/gpus/cuda/BUILD:187:1: not all outputs were created.
ERROR: /local/scratch/vd241/tensorflow/third_party/gpus/cuda/BUILD:187:1: declared output 'third_party/gpus/cuda/cuda.config' is a dangling symbolic link.
ERROR: /local/scratch/vd241/tensorflow/third_party/gpus/cuda/BUILD:187:1: not all outputs were created.
Target //tensorflow/tools/pip_package:build_pip_package failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 37.604s, Critical Path: 6.99s

But actually, this means it shouldn't really be a problem as long as, whenever I have GPUs, my client connects to a machine with a GPU.
Thank you so much for all your help!

Hi, VDalibard：
I'm a freshman on tensorflow. Now I'm trying to establish a distributed tensorflow on two Ubuntu servers. I've used the code on tersorflow.org and ran the following codes
CUDA_VISIBLE_DEVICES='' python distribute.py --ps_hosts=<IP_ADDRESS>:2223 --worker_hosts=<IP_ADDRESS>:2224,<IP_ADDRESS>:2224 --job_name=ps --task_index=0
to setup the parameter server. And
CUDA_VISIBLE_DEVICES=0 python distribute.py --ps_hosts=<IP_ADDRESS>:2223 --worker_hosts=<IP_ADDRESS>:2224,<IP_ADDRESS>:2224 --job_name=worker --task_index=0
to create a worker node and
--task_index=1
for the other node. Whereas when I ran the last two commands, the terminal told me that
wmfs-MacBook-Pro-2:TensorFlow Murphy$ CUDA_VISIBLE_DEVICES=0 python distribute.py --ps_hosts=<IP_ADDRESS>:2223 --worker_hosts=<IP_ADDRESS>:2223,<IP_ADDRESS>:2224 --job_name=worker --task_index=0 I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:206] Initialize HostPortsGrpcChannelCache for job ps -> {<IP_ADDRESS>:2223} I tensorflow/core/distributed_runtime/rpc/grpc_channel.cc:206] Initialize HostPortsGrpcChannelCache for job worker -> {localhost:2223, <IP_ADDRESS>:2224} I tensorflow/core/distributed_runtime/rpc/grpc_server_lib.cc:202] Started server with target: grpc://localhost:2223 E0112 00:40:14.185396000<PHONE_NUMBER>04800 tcp_client_posix.c:191] failed to connect to 'ipv4:<IP_ADDRESS>:2223': timeout occurred E0112 00:40:14.185566000<PHONE_NUMBER>32416 tcp_client_posix.c:191] failed to connect to 'ipv4:<IP_ADDRESS>:2224': timeout occurred
So I wanna know if I need to start some kind of service on machine B?


[Gratitude] Thank you, Team Rizu

This isn't a bug report. I just wanted to say thanks to the entire TeamRizu team for working on modernizing Stepmania. I started my love of dance rhythm games when I first discovered DDR on the PS2 at age 13. The recent COVID quarantines recently got me looking into cardio exercises that can be done at home and I found out about Stepmania.
After playing on Stepmania for a few months, I discovered the OutFox fork and downloaded it instead. My fiancee and I have been playing multiple times a week and it's our main source of working out and having a good time dancing to funky songs.
I wanted to say thanks to the entire team for doing this for free. Is there any way we can support you all (i.e. a Patreon, BuyMeACoffee)?

Is there any way we can support you all (i.e. a Patreon, BuyMeACoffee)?

If you look at the site (https://projectmoon.dance/), there is a Patreon icon at the top right (https://www.patreon.com/TeamRizu).

Thanks! I just signed up to become a Patron.
p.s. On the main website, Content -> Music currently links to a broken page.

Thanks for your support!
We have been told by a lot of our players in the discord server that our 'timing' on going public with the alphas just before the pandemic hit has helped a lot of folks, which has been awesome.
We are continuing to work and thrash out the bugs, so do check back for updates and bugfixes, 4.9.5 is being prepared as we speak.
thanks a lot for your positive comments, it's nice to hear from you!


Transcribe files using Whisper AI

Is there any plan for having the ability to transcribe other files using the Whisper AI using this app? I love everything about this app but I want to be able to transcribe other files, not just my own recordings made with the app. I am even willing to pay for a $25 coffee for this feature to be implemented.

There are many other applications that can handle this effortlessly. You can also transcribe it directly in OpenAI's Playground.

There are many other applications that can handle this effortlessly.

Can you point me to some? I've been searching and trying to find something but I can't

You can also transcribe it directly in OpenAI's Playground.
I want to do this within a Windows app if possible.


[Other issue]: dockerised fleet_adapter unable to find dockerised RMF Core

Before proceeding, is there an existing issue or discussion for this?

[X] I have done a search for similar issues and discussions.

Description
Issue Description :spiral_notepad:
In an attempt to dockerise fleet_adapter_template as well as RMF Core in order to have these 2 RMF components talk to each other from different environment, the following error is encountered:
Error Abstract :eye:
what():  Invalid rmf_traffic_msgs/ScheduleQuerySpacetime type [0]

Raw

Click here for more details
[rmf_traffic_schedule-1] terminate called after throwing an instance of 'std::runtime_error'
[rmf_traffic_schedule-1]   what():  Invalid rmf_traffic_msgs/ScheduleQuerySpacetime type [0]
[rmf_traffic_schedule-1] Stack trace (most recent call last):
[rmf_traffic_schedule-1] #23   Object "", at 0xffffffffffffffff, in
[rmf_traffic_schedule-1] #22   Object "/opt/rmf/install/rmf_traffic_ros2/lib/rmf_traffic_ros2/rmf_traffic_schedule", at 0x402214, in start
[rmf_traffic_schedule-1] #21   Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7ef3e21b1e3f, in libc_start_main
[rmf_traffic_schedule-1] #20   Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7ef3e21b1d8f, in
[rmf_traffic_schedule-1] #19   Object "/opt/rmf/install/rmf_traffic_ros2/lib/rmf_traffic_ros2/rmf_traffic_schedule", at 0x402536, in main
[rmf_traffic_schedule-1] #18   Object "/opt/ros/humble/lib/librclcpp.so", at 0x7ef3e26edc8e, in rclcpp::spin(std::shared_ptrrclcpp::Node)
[rmf_traffic_schedule-1] #17   Object "/opt/ros/humble/lib/librclcpp.so", at 0x7ef3e26edb94, in rclcpp::spin(std::shared_ptrrclcpp::node_interfaces::NodeBaseInterface)
[rmf_traffic_schedule-1] #16   Object "/opt/ros/humble/lib/librclcpp.so", at 0x7ef3e26ed97f, in rclcpp::executors::SingleThreadedExecutor::spin()
[rmf_traffic_schedule-1] #15   Object "/opt/ros/humble/lib/librclcpp.so", at 0x7ef3e26e60c5, in rclcpp::Executor::execute_any_executable(rclcpp::AnyExecutable&)
[rmf_traffic_schedule-1] #14   Object "/opt/ros/humble/lib/librclcpp.so", at 0x7ef3e26e5d59, in rclcpp::Executor::execute_service(std::shared_ptrrclcpp::ServiceBase)
[rmf_traffic_schedule-1] #13   Object "/opt/ros/humble/lib/librclcpp.so", at 0x7ef3e26e8375, in
[rmf_traffic_schedule-1] #12   Object "/opt/rmf/install/rmf_traffic_ros2/lib/librmf_traffic_ros2.so", at 0x7ef3e310e74b, in rclcpp::Service<rmf_traffic_msgs::srv::RegisterQuery>::handle_request(std::shared_ptr<rmw_request_id_s>, std::shared_ptr)
[rmf_traffic_schedule-1] #11   Object "/opt/rmf/install/rmf_traffic_ros2/lib/librmf_traffic_ros2.so", at 0x7ef3e311082f, in rclcpp::AnyServiceCallback<rmf_traffic_msgs::srv::RegisterQuery>::dispatch(std::shared_ptr<rclcpp::Service<rmf_traffic_msgs::srv::RegisterQuery> > const&, std::shared_ptr<rmw_request_id_s> const&, std::shared_ptr<rmf_traffic_msgs::srv::RegisterQuery_Request<std::allocator > >)
[rmf_traffic_schedule-1] #10   Object "/opt/rmf/install/rmf_traffic_ros2/lib/librmf_traffic_ros2.so", at 0x7ef3e30fe23d, in std::Function_handler<void (std::shared_ptr<rmw_request_id_s>, std::shared_ptr<rmf_traffic_msgs::srv::RegisterQuery_Request<std::allocator > >, std::shared_ptr<rmf_traffic_msgs::srv::RegisterQuery_Response<std::allocator > >), rmf_traffic_ros2::schedule::ScheduleNode::setup_query_services()::$2>::M_invoke(std::Any_data const&, std::shared_ptr<rmw_request_id_s>&&, std::shared_ptr<rmf_traffic_msgs::srv::RegisterQuery_Request<std::allocator > >&&, std::shared_ptr<rmf_traffic_msgs::srv::RegisterQuery_Response<std::allocator > >&&)
[rmf_traffic_schedule-1] #9    Object "/opt/rmf/install/rmf_traffic_ros2/lib/librmf_traffic_ros2.so", at 0x7ef3e30f18e1, in rmf_traffic_ros2::schedule::ScheduleNode::register_query(std::shared_ptr<rmw_request_id_s> const&, std::shared_ptr<rmf_traffic_msgs::srv::RegisterQuery_Request<std::allocator > > const&, std::shared_ptr<rmf_traffic_msgs::srv::RegisterQuery_Response<std::allocator > > const&)
[rmf_traffic_schedule-1] #8    Object "/opt/rmf/install/rmf_traffic_ros2/lib/librmf_traffic_ros2.so", at 0x7ef3e31f6710, in rmf_traffic_ros2::convert(rmf_traffic_msgs::msg::ScheduleQuery_<std::allocator > const&)
[rmf_traffic_schedule-1] #7    Object "/opt/rmf/install/rmf_traffic_ros2/lib/librmf_traffic_ros2.so", at 0x7ef3e31f57d3, in rmf_traffic_ros2::convert(rmf_traffic_msgs::msg::ScheduleQuerySpacetime_<std::allocator > const&)
[rmf_traffic_schedule-1] #6    Object "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30", at 0x7ef3e24814d7, in __cxa_throw
[rmf_traffic_schedule-1] #5    Object "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30", at 0x7ef3e2481276, in std::terminate()
[rmf_traffic_schedule-1] #4    Object "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30", at 0x7ef3e248120b, in
[rmf_traffic_schedule-1] #3    Object "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30", at 0x7ef3e2475b9d, in
[rmf_traffic_schedule-1] #2    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7ef3e21b07f2, in abort
[rmf_traffic_schedule-1] #1    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7ef3e21ca475, in raise
[rmf_traffic_schedule-1] #0    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7ef3e221e9fc, in pthread_kill
[rmf_traffic_schedule-1] Aborted (Signal sent by tkill() 78 0)
[ERROR] [rmf_traffic_schedule-1]: process has died [pid 78, exit code -6, cmd '/opt/rmf/install/rmf_traffic_ros2/lib/rmf_traffic_ros2/rmf_traffic_schedule --ros-args -r __node:=rmf_traffic_schedule_primary --params-file /tmp/launch_params_9tc49n51'].
[schedule_visualizer_node-4] [INFO] [1718244053.828736221] [schedule_data_node]: Requesting new schedule update because update timed out
[schedule_visualizer_node-4] [INFO] [1718244053.828795097] [schedule_data_node]: [rmf_traffic_ros2::MirrorManager::request_update] Requesting changes for query ID [1] since beginning of recorded history
[schedule_visualizer_node-4] [WARN] [1718244053.828830466] [schedule_data_node]: [MirrorManager::request_update] Waiting for change request service to reconnect for [727748c5-e9c3-4fa5-98e0-bd10cfd28bfd] before sending a change request.

Steps To Reproduce :books:
Follow the steps to recreate the error encountered:
Environment :bookmark_tabs:

Ubuntu 22.04.4 LTS
ROS 2 Humble
Docker version 26.1.3, build b72abbb

Create the following directory with the files below:

cd $HOME

mkdir -p test_docker_rmf_core_fleet_adapter/map && cd test_docker_rmf_core_fleet_adapter/map

Create or Download the following files into the directory /map:

test.building.yaml :file_folder:
coordinate_system: reference_image
crowd_sim:
  agent_groups:
    - {agents_name: [], agents_number: 0, group_id: 0, profile_selector: external_agent, state_selector: external_static, x: 0, y: 0}
  agent_profiles:
    - {ORCA_tau: 1, ORCA_tauObst: 0.40000000000000002, class: 1, max_accel: 0, max_angle_vel: 0, max_neighbors: 10, max_speed: 0, name: external_agent, neighbor_dist: 5, obstacle_set: 1, pref_speed: 0, r: 0.25}
  enable: 0
  goal_sets: []
  model_types: []
  obstacle_set: {class: 1, file_name: L1_navmesh.nav, type: nav_mesh}
  states:
    - {final: 1, goal_set: -1, name: external_static, navmesh_file_name: ""}
  transitions: []
  update_time_step: 0.10000000000000001
graphs:
  {}
levels:
  L1:
    doors:
      - [17, 18, {motion_axis: [1, start], motion_degrees: [3, 90], motion_direction: [2, 1], name: [1, bathroom_door], plugin: [1, normal], right_left_ratio: [3, 1], type: [1, hinged]}]
      - [11, 10, {motion_axis: [1, start], motion_degrees: [3, 90], motion_direction: [2, -1], name: [1, bedroom_door], plugin: [1, normal], right_left_ratio: [3, 1], type: [1, hinged]}]
      - [12, 19, {motion_axis: [1, start], motion_degrees: [3, 90], motion_direction: [2, 1], name: [1, bedroom_doord], plugin: [1, normal], right_left_ratio: [3, 1], type: [1, hinged]}]
      - [2, 7, {motion_axis: [1, start], motion_degrees: [3, 90], motion_direction: [2, -1], name: [1, hall_door], plugin: [1, normal], right_left_ratio: [3, 1], type: [1, hinged]}]
    drawing:
      filename: default_floor_layout.png
    elevation: 0
    floors:
      - parameters: {ceiling_scale: [3, 1], ceiling_texture: [1, blue_linoleum], indoor: [2, 0], texture_name: [1, blue_linoleum], texture_rotation: [3, 0], texture_scale: [3, 1]}
        vertices: [3, 2, 18, 17, 16, 15]
      - parameters: {ceiling_scale: [3, 1], ceiling_texture: [1, blue_linoleum], indoor: [2, 0], texture_name: [1, blue_linoleum], texture_rotation: [3, 0], texture_scale: [3, 1]}
        vertices: [8, 14, 13, 11, 10, 9]
      - parameters: {ceiling_scale: [3, 1], ceiling_texture: [1, blue_linoleum], indoor: [2, 0], texture_name: [1, blue_linoleum], texture_rotation: [3, 0], texture_scale: [3, 1]}
        vertices: [14, 6, 20, 19, 12, 13]
      - parameters: {ceiling_scale: [3, 1], ceiling_texture: [1, blue_linoleum], indoor: [2, 0], texture_name: [1, blue_linoleum], texture_rotation: [3, 0], texture_scale: [3, 1]}
        vertices: [20, 19, 12, 4, 5]
      - parameters: {ceiling_scale: [3, 1], ceiling_texture: [1, blue_linoleum], indoor: [2, 0], texture_name: [1, blue_linoleum], texture_rotation: [3, 0], texture_scale: [3, 1]}
        vertices: [16, 4, 15]
      - parameters: {ceiling_scale: [3, 1], ceiling_texture: [1, blue_linoleum], indoor: [2, 0], texture_name: [1, blue_linoleum], texture_rotation: [3, 0], texture_scale: [3, 1]}
        vertices: [2, 7, 8, 9, 16, 17, 18]
      - parameters: {ceiling_scale: [3, 1], ceiling_texture: [1, blue_linoleum], indoor: [2, 0], texture_name: [1, blue_linoleum], texture_rotation: [3, 0], texture_scale: [3, 1]}
        vertices: [16, 9, 4]
      - parameters: {ceiling_scale: [3, 1], ceiling_texture: [1, blue_linoleum], indoor: [2, 0], texture_name: [1, blue_linoleum], texture_rotation: [3, 0], texture_scale: [3, 1]}
        vertices: [9, 10, 4]
      - parameters: {ceiling_scale: [3, 1], ceiling_texture: [1, blue_linoleum], indoor: [2, 0], texture_name: [1, blue_linoleum], texture_rotation: [3, 0], texture_scale: [3, 1]}
        vertices: [10, 11, 4]
      - parameters: {ceiling_scale: [3, 1], ceiling_texture: [1, blue_linoleum], indoor: [2, 0], texture_name: [1, blue_linoleum], texture_rotation: [3, 0], texture_scale: [3, 1]}
        vertices: [11, 12, 4]
    lanes:
      - [23, 24, {bidirectional: [4, true], demo_mock_floor_name: [1, ""], demo_mock_lift_name: [1, ""], graph_idx: [2, 0], orientation: [1, ""], speed_limit: [3, 0]}]
      - [24, 25, {bidirectional: [4, true], demo_mock_floor_name: [1, ""], demo_mock_lift_name: [1, ""], graph_idx: [2, 0], orientation: [1, ""], speed_limit: [3, 0]}]
      - [25, 26, {bidirectional: [4, true], demo_mock_floor_name: [1, ""], demo_mock_lift_name: [1, ""], graph_idx: [2, 0], orientation: [1, ""], speed_limit: [3, 0]}]
      - [26, 23, {bidirectional: [4, true], demo_mock_floor_name: [1, ""], demo_mock_lift_name: [1, ""], graph_idx: [2, 0], orientation: [1, ""], speed_limit: [3, 0]}]
    layers:
      test_apartment:
        color: [1, 0, 0, 0.5]
        filename: ""
        transform:
          scale: 0.01
          translation_x: 0
          translation_y: 0
          yaw: 0
        visible: false
    measurements:
      - [0, 1, {distance: [3, 4]}]
    models:
      - {dispensable: false, model_name: OpenRobotics/OfficeChairGrey, name: OpenRobotics/OfficeChairGrey, static: true, x: 358.392, y:<PHONE_NUMBER>0000001, yaw: -3.1183000000000001, z: 0}
      - {dispensable: false, model_name: OpenRobotics/OfficeChairGrey, name: OpenRobotics/OfficeChairGrey, static: true, x: 402.839, y:<PHONE_NUMBER>9999997, yaw: -3.1246, z: 0}
      - {dispensable: false, model_name: OpenRobotics/Table, name: OpenRobotics/Table, static: true, x:<PHONE_NUMBER>9999997, y:<PHONE_NUMBER>9999998, yaw: -3.1328, z: -0.29999999999999999}
    vertices:
      - [32.286000000000001, 47.747999999999998, 0, ""]
      - [204.05600000000001, 47.747999999999998, 0, ""]
      - [35.155999999999999,<PHONE_NUMBER>9999999, 0, ""]
      - [33.683999999999997, 31.550999999999998, 0, ""]
      - [495.28500000000003, 31.550999999999998, 0, ""]
      - [495.28500000000003,<PHONE_NUMBER>9999999, 0, ""]
      - [32.947000000000003,<PHONE_NUMBER>9999999, 0, ""]
      - [32.947000000000003,<PHONE_NUMBER>9999999, 0, ""]
      - [33.683999999999997,<PHONE_NUMBER>0000001, 0, ""]
      - [228.77799999999999,<PHONE_NUMBER>0000001, 0, ""]
      - [228.77799999999999,<PHONE_NUMBER>0000001, 0, ""]
      - [229.51499999999999,<PHONE_NUMBER>0000003, 0, ""]
      - [229.51499999999999,<PHONE_NUMBER>0000002, 0, ""]
      - [227.30600000000001,<PHONE_NUMBER>0000001, 0, ""]
      - [33.683999999999997,<PHONE_NUMBER>0000001, 0, ""]
      - [204.803, 33.387, 0, ""]
      - [204.803,<PHONE_NUMBER>0000001, 0, ""]
      - [198.18899999999999,<PHONE_NUMBER>0000001, 0, ""]
      - [149.24600000000001,<PHONE_NUMBER>9999999, 0, ""]
      - [229.71899999999999,<PHONE_NUMBER>9999998, 0, ""]
      - [229.71899999999999,<PHONE_NUMBER>0000005, 0, ""]
      - [475.67700000000002,<PHONE_NUMBER>9999996, 0, ""]
      - [432.447,<PHONE_NUMBER>9999996, 0, ""]
      - [292.07600000000002,<PHONE_NUMBER>0000002, 0, ""]
      - [288.548,<PHONE_NUMBER>0000003, 0, ""]
      - [448.69600000000003,<PHONE_NUMBER>0000002, 0, ""]
      - [450.81200000000001,<PHONE_NUMBER>0000002, 0, ""]
    walls:
      - [2, 3, {alpha: [3, 1], texture_height: [3, 2.5], texture_name: [1, default], texture_scale: [3, 1], texture_width: [3, 1]}]
      - [3, 4, {alpha: [3, 1], texture_height: [3, 2.5], texture_name: [1, default], texture_scale: [3, 1], texture_width: [3, 1]}]
      - [4, 5, {alpha: [3, 1], texture_height: [3, 2.5], texture_name: [1, default], texture_scale: [3, 1], texture_width: [3, 1]}]
      - [5, 6, {alpha: [3, 1], texture_height: [3, 2.5], texture_name: [1, default], texture_scale: [3, 1], texture_width: [3, 1]}]
      - [6, 7, {alpha: [3, 1], texture_height: [3, 2.5], texture_name: [1, default], texture_scale: [3, 1], texture_width: [3, 1]}]
      - [8, 9, {alpha: [3, 1], texture_height: [3, 2.5], texture_name: [1, default], texture_scale: [3, 1], texture_width: [3, 1]}]
      - [9, 10, {alpha: [3, 1], texture_height: [3, 2.5], texture_name: [1, default], texture_scale: [3, 1], texture_width: [3, 1]}]
      - [11, 12, {alpha: [3, 1], texture_height: [3, 2.5], texture_name: [1, default], texture_scale: [3, 1], texture_width: [3, 1]}]
      - [13, 14, {alpha: [3, 1], texture_height: [3, 2.5], texture_name: [1, default], texture_scale: [3, 1], texture_width: [3, 1]}]
      - [15, 16, {alpha: [3, 1], texture_height: [3, 2.5], texture_name: [1, default], texture_scale: [3, 1], texture_width: [3, 1]}]
      - [16, 17, {alpha: [3, 1], texture_height: [3, 2.5], texture_name: [1, default], texture_scale: [3, 1], texture_width: [3, 1]}]
      - [2, 18, {alpha: [3, 1], texture_height: [3, 2.5], texture_name: [1, default], texture_scale: [3, 1], texture_width: [3, 1]}]
      - [19, 20, {alpha: [3, 1], texture_height: [3, 2.5], texture_name: [1, default], texture_scale: [3, 1], texture_width: [3, 1]}]
lifts: {}
name: test_workspace

Run dockerised RMF Core using the commands below:

cd $HOME/test_docker_rmf_core_fleet_adapter

docker run -it --rm \
--name rmf_core_c \
-v $(pwd)/map:/opt/rmf/map \
ghcr.io/open-rmf/rmf_deployment_template/rmf-simulation:latest \
bash -c "ros2 launch rmf_demos common.launch.xml \
config_file:=/opt/rmf/map/default.building.yaml \
headless:=1 \
use_rmf_panel:=0 \
server_uri:=ws://localhost:8000/_internal"

Prepare the fleet_adapter_template using the commands below:

cd $HOME/test_docker_rmf_core_fleet_adapter

git clone https://github.com/open-rmf/fleet_adapter_template --branch humble --single-branch --depth 1

Create file Dockerfile in the newly created directory /fleet_adapter_template:

cd $HOME/test_docker_rmf_core_fleet_adapter/fleet_adapter_template

Dockerfile :file_folder:
FROM ghcr.io/open-rmf/rmf/rmf_demos:latest

RUN apt-get update \
  && apt-get remove python3-starlette -y \
  && apt-get install -y \
    cmake \
    curl \
    git \
    python3-colcon-common-extensions \
    python3-vcstool \
    qtbase5-dev qtchooser qt5-qmake qtbase5-dev-tools \
    wget \
    python3-pip \
  && pip3 install flask-socketio fastapi uvicorn nudged \
  && rm -rf /var/lib/apt/lists/*

# setup keys
WORKDIR /fleet_adapter_ws
COPY . src
RUN rosdep update --rosdistro $ROS_DISTRO

# This replaces: wget https://raw.githubusercontent.com/open-rmf/rmf/main/rmf.repos
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update \
    && apt-get upgrade -y \
    && rosdep update \
    && rosdep install --from-paths src --ignore-src --rosdistro $ROS_DISTRO -yr \
    && rm -rf /var/lib/apt/lists/*

# colcon compilation
RUN . /opt/ros/$ROS_DISTRO/setup.sh \
  && colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release

# cleanup
RUN sed -i '$isource "/fleet_adapter_ws/install/setup.bash"' /ros_entrypoint.sh

ENTRYPOINT ["/ros_entrypoint.sh"]
CMD ros2 run fleet_adapter_template fleet_adapter -c /fleet_adapter_ws/src/fleet_adapter_template/config.yaml -n /fleet_adapter_ws/src/fleet_adapter_template/0.yaml -s ws://localhost:8000

Create file 0.yaml navigation graph file in the following directory /fleet_adapter_template/:

cd $HOME/test_docker_rmf_core_fleet_adapter/fleet_adapter_template/

0.yaml :file_folder:
building_name: dummy
levels:
  L1:
    lanes:
    - - 0
      - 1
      - {door_name: lab_entrance_door_right, is_bidirectional: false, speed_limit: 0}
    - - 1
      - 2
      - {is_bidirectional: false, speed_limit: 0}
    - - 2
      - 3
      - {door_name: lab_entrance_door_left, is_bidirectional: false, speed_limit: 0}
    - - 3
      - 0
      - {is_bidirectional: false, speed_limit: 0}
    vertices:
    - - 1.7782732024514007
      - -6.948913915578813
      - {name: ''}
    - - 24.08566297204254
      - -6.872960068283951
      - {name: ''}
    - - 24.11095590340457
      - -7.480665899851638
      - {name: ''}
    - - 1.7782732024514007
      - -7.607243136474944
      - {name: ''}

Build dockerised fleet_adapter_template using commands below:

cd $HOME/test_docker_rmf_core_fleet_adapter/fleet_adapter_template

docker build -t fleet_adapter_template:latest .

Run dockerised fleet_adapter_template using commands below:

docker run -it --rm  \
--network host \
--name fleet_adapter_template_c \
fleet_adapter_template:latest

Expected Behaviour :green_circle:
fleet_adapter_template is able to find RMF Schedule Core but gives error being unable to connect to connect to non-existent robot API server at http://<IP_ADDRESS>:8080, as specified in config.yaml.
Actual Behaviour :red_circle:
Upon running dockerised fleet_adapter_template using the steps above, dockerised RMF Core crashes with the aforementioned error.
Remarks
Appreciate any constructive help/feedback on this issue. :blush: :pray:
The rationale for this form of setup is for better system scalability where an RMF Deployment would have a robot's fleet adapter running in a different environment and server from RMF Core which should be running in cloud with Dashboard and API Server. This is in contrast to the many online tutorial examples of RMF deployment which assumes fleet adapter is always running in the same environment as RMF Core.

Update :speech_balloon:
Been continuing to debug on this issue myself for the past week. Arrived at a short-term conclusion with a Dirty Workaround to avoid the issue as well as narrowing of the Cause of Issue.
Cause of Issue
The Cause of Issue has been narrowed down by incrementally shaving away at instantiated ROS 2 packages in common.launch.xml under rmf_demos. The following is a minimal common.launch.xml file which gives the core error reported as stated above.
<?xml version='1.0' ?>

<launch>

  <arg name="use_sim_time" default="false" description="Use the /clock topic for time to sync with simulation"/>

  <!-- Traffic Schedule  -->
  <node pkg="rmf_traffic_ros2" exec="rmf_traffic_schedule" output="both" name="rmf_traffic_schedule_primary">
    <param name="use_sim_time" value="$(var use_sim_time)"/>
  </node>

</launch>

Comparing this to a working example of .launch.xml that launches RMF Core in a manner that does not crash upon the launch of fleet_adapter_template, there is no difference in the way rmf_traffic_schedule was called.
Cause of Issue (Deduced) :eye_speech_bubble:
Therefore, the only difference between Faulty Setup and Working Setup seems to :red_circle:  due to the base docker image used :red_circle: .
Working Setup uses ghcr.io/open-rmf/rmf/rmf_demos:latest when it was still based in ROS 2 Humble.
Faulty Setup uses ghcr.io/open-rmf/rmf_deployment_template/rmf-simulation:latest which is based in ROS 2 Humble.
The rmf_traffic_schedule used in ghcr.io/open-rmf/rmf_deployment_template/rmf-simulation:latest, for lack of better explaination, is just different and should not be used, at least as of this writing and author's personal understanding.
Dirty Workaround :adhesive_bandage:
To avoid the core error reported in this thread, would recommend to use ghcr.io/open-rmf/rmf/rmf_demos:latest as a base docker image to quickly instantiate an RMF Core for development purposes.
Closing since resolving this issue may not be useful in long run, given developers are probably not going to use ghcr.io/open-rmf/rmf_deployment_template/rmf-simulation:latest for their official deployment of an RMF Core.


Cannot launch Malmo on linux server without GUI

I followed the instructions in #291 (both set of instructions appearing in the discussions separately) ;
However, Malmo fails to launch with the following stack trace: (sorry, too long, I copied the entire launch sequence output.)
$ DISPLAY=:0.0 ./launchClient.sh
****************************
 Powered By MCP:
 http://modcoderpack.com/
 Searge, ProfMobius, Fesh0r,
 R4wk, ZeuX, IngisKahn, bspkrs
 MCP Data version : 9.10
****************************
:deobfCompileDummyTask
:deobfProvidedDummyTask
:getVersionJson
:extractUserdev UP-TO-DATE
:extractMcpData SKIPPED
:extractMcpMappings SKIPPED
:genSrgs SKIPPED
:downloadClient SKIPPED
:downloadServer SKIPPED
:splitServerJar SKIPPED
:mergeJars SKIPPED
:deobfMcSRG SKIPPED
:getFernFlower SKIPPED
:decompileMc SKIPPED
:fixMcSources SKIPPED
:applySourcePatches SKIPPED
:remapMcSources SKIPPED
:recompileMc SKIPPED
:extractNatives SKIPPED
:getAssetIndex UP-TO-DATE
:getAssets
Current status: 716/734   97%
:makeStart SKIPPED
:setupDecompWorkspace

BUILD SUCCESSFUL

Total time: 28.988 secs

This build could be faster, please consider using the Gradle Daemon: https://docs.gradle.org/2.11/userguide/gradle_daemon.html
****************************
 Powered By MCP:
 http://modcoderpack.com/
 Searge, ProfMobius, Fesh0r,
 R4wk, ZeuX, IngisKahn, bspkrs
 MCP Data version : 9.10
****************************
:deobfCompileDummyTask
:deobfProvidedDummyTask
:compileApiJava UP-TO-DATE
:processApiResources UP-TO-DATE
:apiClasses UP-TO-DATE
:copyModToClient
:copyModToServer
:deleteSchemas
:copySchemas
:jaxb UP-TO-DATE
:sourceMainJava UP-TO-DATE
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:extractMcpData SKIPPED
:extractMcpMappings SKIPPED
:getVersionJson
:extractUserdev UP-TO-DATE
:genSrgs SKIPPED
:reobfJar
:assemble
:check UP-TO-DATE
:build

BUILD SUCCESSFUL

Total time: 8.577 secs

This build could be faster, please consider using the Gradle Daemon: https://docs.gradle.org/2.11/userguide/gradle_daemon.html
****************************
 Powered By MCP:
 http://modcoderpack.com/
 Searge, ProfMobius, Fesh0r,
 R4wk, ZeuX, IngisKahn, bspkrs
 MCP Data version : 9.10
****************************
:deobfCompileDummyTask
:deobfProvidedDummyTask
:compileApiJava UP-TO-DATE
:processApiResources UP-TO-DATE
:apiClasses UP-TO-DATE
:copyModToClient
:copyModToServer
:deleteSchemas
:copySchemas
:jaxb UP-TO-DATE
:sourceMainJava UP-TO-DATE
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar
:getVersionJson
:extractNatives SKIPPED
:extractUserdev UP-TO-DATE
:getAssetIndex UP-TO-DATE
:getAssets
Current status: 715/734   97%
:makeStart SKIPPED
:runClient
[14:14:48] [main/INFO] [GradleStart]: Extra: []
[14:14:48] [main/INFO] [GradleStart]: Running with arguments: [--userProperties, {}, --assetsDir, /home/<user>/.gradle/caches/minecraft/assets, --assetIndex, 1.8, --accessToken{REDACTED}, --version, 1.8, --tweakClass, net.minecraftforge.fml.common.launcher.FMLTweaker]
[14:14:49] [main/INFO] [LaunchWrapper]: Loading tweak class name net.minecraftforge.fml.common.launcher.FMLTweaker
[14:14:49] [main/INFO] [LaunchWrapper]: Using primary tweak class name net.minecraftforge.fml.common.launcher.FMLTweaker
[14:14:49] [main/INFO] [LaunchWrapper]: Calling tweak class net.minecraftforge.fml.common.launcher.FMLTweaker
[14:14:49] [main/INFO] [FML]: Forge Mod Loader version <IP_ADDRESS>3 for Minecraft 1.8 loading
[14:14:49] [main/INFO] [FML]: Java is Java HotSpot(TM) 64-Bit Server VM, version 1.8.0_121, running on Linux:amd64:3.13.0-113-generic, installed at /usr/lib/jvm/java-8-oracle/jre
[14:14:49] [main/INFO] [FML]: Managed to load a deobfuscated Minecraft name- we are in a deobfuscated environment. Skipping runtime deobfuscation
[14:14:49] [main/INFO] [FML]: Found a command line coremod : com.microsoft.Malmo.OverclockingPlugin
[14:14:49] [main/WARN] [FML]: The coremod com.microsoft.Malmo.OverclockingPlugin does not have a MCVersion annotation, it may cause issues with this version of Minecraft
[14:14:49] [main/INFO] [LaunchWrapper]: Loading tweak class name net.minecraftforge.fml.common.launcher.FMLInjectionAndSortingTweaker
[14:14:49] [main/INFO] [LaunchWrapper]: Loading tweak class name net.minecraftforge.fml.common.launcher.FMLDeobfTweaker
[14:14:49] [main/INFO] [LaunchWrapper]: Calling tweak class net.minecraftforge.fml.common.launcher.FMLInjectionAndSortingTweaker
[14:14:49] [main/INFO] [LaunchWrapper]: Calling tweak class net.minecraftforge.fml.common.launcher.FMLInjectionAndSortingTweaker
[14:14:49] [main/INFO] [LaunchWrapper]: Calling tweak class net.minecraftforge.fml.relauncher.CoreModManager$FMLPluginWrapper
[14:14:49] [main/ERROR] [FML]: The binary patch set is missing. Either you are in a development environment, or things are not going to work!
[14:14:50] [main/ERROR] [FML]: FML appears to be missing any signature data. This is not a good thing
[14:14:50] [main/INFO] [LaunchWrapper]: Calling tweak class net.minecraftforge.fml.relauncher.CoreModManager$FMLPluginWrapper
[14:14:50] [main/INFO] [LaunchWrapper]: Calling tweak class net.minecraftforge.fml.relauncher.CoreModManager$FMLPluginWrapper
[14:14:50] [main/INFO] [LaunchWrapper]: Calling tweak class net.minecraftforge.fml.common.launcher.FMLDeobfTweaker
[14:14:50] [main/INFO] [LaunchWrapper]: Loading tweak class name net.minecraftforge.fml.common.launcher.TerminalTweaker
[14:14:50] [main/INFO] [LaunchWrapper]: Calling tweak class net.minecraftforge.fml.common.launcher.TerminalTweaker
[14:14:50] [main/INFO] [LaunchWrapper]: Launching wrapped minecraft {net.minecraft.client.main.Main}
[14:14:50] [main/INFO] [STDOUT]: [com.microsoft.Malmo.OverclockingClassTransformer:transform:52]: MALMO: Attempting to transform MinecraftServer
[14:14:50] [main/INFO] [STDOUT]: [com.microsoft.Malmo.OverclockingClassTransformer:overclockRenderer:147]: MALMO: Found Minecraft, attempting to transform it
[14:14:50] [main/INFO] [STDOUT]: [com.microsoft.Malmo.OverclockingClassTransformer:overclockRenderer:153]: MALMO: Found Minecraft.runGameLoop() method, attempting to transform it
[14:14:50] [main/INFO] [STDOUT]: [com.microsoft.Malmo.OverclockingClassTransformer:overclockRenderer:168]: MALMO: Hooked into call to Minecraft.updateDisplay()
Invalid MIT-MAGIC-COOKIE-1 key[14:14:51] [main/ERROR] [LaunchWrapper]: Unable to launch
java.lang.reflect.InvocationTargetException
Exception in thread "main"      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_121]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_121]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_121]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_121]
        at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.12.jar:?]
        at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_121]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_121]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_121]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_121]
        at net.minecraftforge.gradle.GradleStartCommon.launch(Unknown Source) [start/:?]
        at GradleStart.main(Unknown Source) [start/:?]
Caused by: java.awt.AWTError: Can't connect to X11 window server using ':0.0' as the value of the DISPLAY variable.
        at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) ~[?:1.8.0_121]
        at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65) ~[?:1.8.0_121]
        at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:115) ~[?:1.8.0_121]
        at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_121]
        at sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:74) ~[?:1.8.0_121]
        at java.lang.Class.forName0(Native Method) ~[?:1.8.0_121]
        at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_121]
        at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:103) ~[?:1.8.0_121]
        at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:82) ~[?:1.8.0_121]
        at sun.awt.X11.XToolkit.<clinit>(XToolkit.java:126) ~[?:1.8.0_121]
        at java.lan.forName0(Native Method) ~[?:1.8.0_121]
        at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_121]
        at java.awt.Toolkit$2.run(Toolkit.java:860) ~[?:1.8.0_121]
        at java.awt.Toolkit$2.run(Toolkit.java:855) ~[?:1.8.0_121]
        at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_121]
        at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:854) ~[?:1.8.0_121]
        at org.lwjgl.LinuxSysImplementation.<clinit>(LinuxSysImplementation.java:50) ~[lwjgl-2.9.1.jar:?]
        at org.lwjgl.Sys.createImplementation(Sys.java:126) ~[lwjgl-2.9.1.jar:?]
        at org.lwjgl.Sys.<clinit>(Sys.java:111) ~[lwjgl-2.9.1.jar:?]
        at net.minecraft.client.Minecraft.getSystemTime(Unknown Source) ~[Minecraft.class:?]
        at net.minecraft.client.main.Main.main(Unknown Source) ~[Main.class:?]
        ... 12 more
[14:14:51] [main/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: java.lang.reflect.InvocationTargetException
[14:14:51] [main/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]:  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[14:14:51] [main/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]:  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[14:14:51] [main/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]:  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[14:14:51] [main/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]:  at java.lang.reflect.Method.invoke(Method.java:498)
[14:14:51] [main/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]:  at net.minecraftforge.gradle.GradleStartCommon.launch(Unknown Source)
[14:14:51] [main/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]:  at GradleStart.main(Unknown Source)
[14:14:51] [main/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: Caused by: net.minecraftforge.fml.relauncher.FMLSecurityManager$ExitTrappedException
[14:14:51] [main/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]:  at net.minecraftforge.fml.relauncher.FMLSecurityManager.checkPermission(Unknown Source)
[14:14:51] [main/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]:  at java.lang.SecurityManager.checkExit(SecurityManager.java:761)
[14:14:51] [main/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]:  at java.lang.Runtime.exit(Runtime.java:107)
[14:14:51] [main/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]:  at java.lang.System.exit(System.java:971)
[14:14:51] [main/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]:  at net.minecraft.launchwrapper.Launch.launch(Launch.java:138)
[14:14:51] [main/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]:  at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
[14:14:51] [main/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]:  ... 6 more
:runClient FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':runClient'.
> Process 'command '/usr/lib/jvm/java-8-oracle/bin/java'' finished with non-zero exit value 1

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 11.564 secs

Hmm, have never seen this before. What flavour of Linux are you using?
From a brief bit of poking around on the internet, other people have had a similar issue, often to do with permissions - maybe you can find some pointers here or here?

We are running Ubuntu 14.04 server 64 bit with some bare minimal XFCE installed for few RDP tasks.
I installed gdm as well as per the conversation on #291 .
I have tried the steps in both links provided above. Doesn't help.
Just to check, I logged in to the system using RDP, tried to launch the client as per #351; but that gave me the following error:
[17:54:24] [Thread-7/ERROR] [FML]: Splash thread Exception
org.lwjgl.LWJGLException: X Error - disp: 0x7fcd6d0a6bb0 serial: 1623 error: GLXBadLargeRequest request_code: 148 minor_code: 2
        at org.lwjgl.opengl.LinuxDisplay.globalErrorHandler(LinuxDisplay.java:321) ~[lwjgl-2.9.1.jar:?]
        at org.lwjgl.opengl.LinuxEvent.getPending(Native Method) ~[lwjgl-2.9.1.jar:?]
        at org.lwjgl.opengl.LinuxDisplay.processEvents(LinuxDisplay.java:850) ~[lwjgl-2.9.1.jar:?]
        at org.lwjgl.opengl.LinuxDisplay.update(LinuxDisplay.java:912) ~[lwjgl-2.9.1.jar:?]
        at org.lwjgl.opengl.Display.processMessages(Display.java:600) ~[lwjgl-2.9.1.jar:?]
        at org.lwjgl.opengl.Display.update(Display.java:666) ~[lwjgl-2.9.1.jar:?]
        at org.lwjgl.opengl.Display.update(Display.java:628) ~[lwjgl-2.9.1.jar:?]
        at net.minecraftforge.fml.client.SplashProgress$3.run(Unknown Source) ~[SplashProgress$3.class:?]
        at java.lang.Thread.run(Thread.java:745) [?:1.8.0_121]
[17:54:24] [Client thread/ERROR] [LaunchWrapper]: Unable to launch
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_121]
Exception in thread "Client thread"     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_121]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_121]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_121]
        at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.12.jar:?]
        at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_121]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_121]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_121]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_121]
        at net.minecraftforge.gradle.GradleStartCommon.launch(Unknown Source) [start/:?]
        at GradleStart.main(Unknown Source) [start/:?]
Caused by: java.lang.NullPointerException
        at net.minecraft.crash.CrashReportCategory.firstTwoElementsOfStackTraceMatch(Unknown Source) ~[CrashReportCategory.class:?]
        at net.minecraft.crash.CrashReport.makeCategoryDepth(Unknown Source) ~[CrashReport.class:?]
        at net.minecraft.crash.CrashReport.makeCategory(Unknown Source) ~[CrashReport.class:?]
        at net.minecraft.client.Minecraft.run(Unknown Source) ~[Minecraft.class:?]
        at net.minecraft.client.main.Main.main(Unknown Source) ~[Main.class:?]
        ... 12 more

Please let me know if I have to try anything else additionally.

Hi @okkhoy,
thank you for trying the above suggestions and providing the additional details above. As a sanity check, can you double check that your call to xinit has actually started xterm, e.g., using ps? You can also try starting with a different display number, e.g., using xinit -display :0.1 and connect to this (e.g., in case someone else is already runnning xterm on display 0.

@katja-hofmann doesn't seem so :-/
when I run xinit I get the following error after a short while:
xinit: giving up
xinit: unable to connect to X server: Resource temporarily unavailable
xinit: server error

@katja-hofmann @DaveyBiggers err.. this is weird,
I tried:
nohup xinit -- :<FREE_DISPLAY_NUMBER> &
DISPLAY=:<FREE_DISPLAY_NUMBER>.0 ./launchClient.sh

With some random number for <FREE_DISPLAY_NUMBER> inside a screen session, it seems to be working now, (though earlier it didn't work!)
I installed gdm recently after my first try, will that affect? Just curious!

The same problem.
Still do not work.
Even after the installation of gdm.

what happened just yesterday is even stranger; with the same steps as above:
nohup xinit -- :<FREE_DISPLAY_NUMBER> &
DISPLAY=:<FREE_DISPLAY_NUMBER>.0 ./launchClient.sh

it is not working again! I get the same stack trace as mentioned earlier
org.lwjgl.LWJGLException: X Error - disp: 0x7fcd6d0a6bb0 serial: 1623 error: GLXBadLargeRequest request_code: 148 minor_code: 2
        at org.lwjgl.opengl.LinuxDisplay.globalErrorHandler(LinuxDisplay.java:321) ~[lwjgl-2.9.1.jar:?]
        at org.lwjgl.opengl.LinuxEvent.getPending(Native Method) ~[lwjgl-2.9.1.jar:?]
        at org.lwjgl.opengl.LinuxDisplay.processEvents(LinuxDisplay.java:850) ~[lwjgl-2.9.1.jar:?]
        at org.lwjgl.opengl.LinuxDisplay.update(LinuxDisplay.java:912) ~[lwjgl-2.9.1.jar:?]
        at org.lwjgl.opengl.Display.processMessages(Display.java:600) ~[lwjgl-2.9.1.jar:?]
        at org.lwjgl.opengl.Display.update(Display.java:666) ~[lwjgl-2.9.1.jar:?]
        at org.lwjgl.opengl.Display.update(Display.java:628) ~[lwjgl-2.9.1.jar:?]
        at net.minecraftforge.fml.client.SplashProgress$3.run(Unknown Source) ~[SplashProgress$3.class:?]
        at java.lang.Thread.run(Thread.java:745) [?:1.8.0_121]

Sorry, I am unable to get to the actual problem.
What is more  puzzling is, what worked earlier doesn't work any more.
The server is configured to auto-update security updates; can you think of anything with the server updates that may mess up things for Malmo? (or am I thinking too much?)

Did you ever get to the bottom of this?
Is this issue relevant? https://github.com/Microsoft/malmo/issues/601

@DaveyBiggers Nope. I got busy with some writing in between. I am resuming working on this now. So will update at the earliest.
It doesn't seem to be relevant to #601 since my setup doesn't involve NVIDIA cards.


chore(deps): bump https://github.com/jenkins-x/jx-cli to 3.0.188

Update jenkins-x/jx-cli to 3.0.188
Command run was ./promote/main

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign garethjevans
You can assign the PR to them by writing /assign @garethjevans in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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


Django mechanism should not log PermissionDenied

Raising PermissionDenied in django is a shortcut to returning 403.
This shouldn't be logged by default, since it's normal behaviour. It does get logged however.
Also, my event has no logger, so I'm not even sure how to manually ignore it.

We are only listening on https://docs.djangoproject.com/en/2.2/ref/signals/#got-request-exception and in a regular application this signal doesn't fire on 403s. Here is the code that shortcuts for PermissionDenied: https://github.com/django/django/blob/03dbdfd9bbbbd0b0172aad648c6bbe3f39541137/django/core/handlers/exception.py#L49-L55
Two possibilities come to mind:

You have another exception that just happens to be called the same
A extension on top of Django triggers this hook. I tested this theory with Django Rest Framework and it seems to work as expected, so I am not sure what that could be.

@WhyNotHugo I am not really sure how to reproduce this.

You have another exception that just happens to be called the same

Actually, yes, I've two exceptions with that name:
from rest_framework.exceptions import PermissionDenied as one
from django.core.exceptions import PermissionDenied as two

one == two  # False

I didn't have any logs for this issue in the last 90 days, but just confirmed that raising the former results in sentry logging it.
However, I'm raising the DRF exception on a non-DRF view, so I'd say my code is wrong and sentry is right here.

Thanks for the clues to figuring this one out, sorry for the false lead!

oh, that was unexpected! nice find


Restore event datasets to visual images

Thanks for your greatful work.
Thank you very much for answering my previous  question. #6
I would like to ask how to restoren event dataset to visualized images, that is, obtain the captured image represented by the event camera dataset.
It would be even better if there are relevant ideas and open-source codes.

There is no easy way to do this, as when you get events from images, you are losing information (e.g. RGB color information). There are some works in the event to video reconstruction field that try to reconstruct grayscale videos from events, which you may be interested. A famous work is E2VID.


Backport "SimplePattern errors should now be recovered as wildcard instead of unimplemented expr" to LTS

Backports #21438 to the 3.3.5.
PR submitted by the release tooling.
[skip ci]

No regressions detected in the community build up to backport-lts-3.3-21857.
Reference


ASK - What is the difference of this plugin compared to rollup-plugin-css-only?

I am sorry. This plugin is good. But, there are another plugin with the same functionality. What is your motivation for making this plugin?
If there is a difference between the both plugin, please affirm the differences in README.md file. Some people little confused to choose between the two.

Hi @lamualfa, there is a difference between the plugins. This plugin lets you import your css as a variable and import it to be written to a css bundle. The plugin you mentioned is only capable of importing css to be written to a css bundle. The functionality is similar but this plugin adds some extra functionality. There are however other plugins that offer this functionality as well but they often include a lot of dependencies while this one does not. I believe the README already states what features this plugin enables but i can add something comparing it to the plugin you mentioned.


why inference slow in A100 ?

when I inference 1024*1024 image , [Tiled VAE]: the input size is tiny and unnecessary to tile. [Tiled VAE]: Done in 12.476s, max VRAM alloc 5802.607 MB
But I want to use more gpu and fast than now , how to solve it ?
And inference once some model offload in gpu

when I inference 1024*1024 image , [Tiled VAE]: the input size is tiny and unnecessary to tile. [Tiled VAE]: Done in 12.476s, max VRAM alloc 5802.607 MB But I want to use more gpu and fast than now , how to solve it ? And inference once some model offload in gpu

12.476s is not slow for a stable-diffusion based method. You can try to test the same thing in StableSR or DiffBIR.


[Proposal] Stateless Material-UI

After seeing a huge number of regressions and bugs introduced only because there are 2 sources of truth for most components (state and prop) I have come to the conclusion that state is bad for business.
The Problem
Take a look at all the bugs. I can argue that more than half of them is caused by the complexity of internal logic of the components. And the biggest reason is keeping the state up-to-date with props.
The Solution
No more support for uncontrolled behavior!
How about forms?

A simple wrapper can do the trick:

<Stateful ref='input' defaultValue={/*...*/}>
  <CheckBox/>
</Stateful>

you can then call imperative methods on this.refs.input. or handle the on change. This will require standard callback signatures which is a must even without this.
2. Third party projects like Fromsy can solve this issue
3. HOC on user-side. I don't think it is that hard to implement anyway.
Roamap

[ ] Remove imperative methods from the library (except for focus, damn focus)
[x] Do something about theme handling to remove all the redundant codes
[ ] Standardize the API, i.e. value + onChange(event, value) [debatable] and no more!
[x] Implement a wrapper that consumes the standard API to easily support form actions
[ ] Brag about the awesomeness of controlled components
[ ] Remove support for uncontrolled components

@oliviertassinari @mbrookes @newoga I would like to hear your insight on this. Thanks :+1: :+1:

Not that formsy-material-ui is particularly complex (and there is plenty of room for improvement - HOC not mixin, ES6 classes, ES6 modules), but from my perspective, if the API was standardised, it would have made implementation much simpler still.
Across the form components, there are at least three variations of the onChange callback parameter order / content, and a mix of whether components can be uncontrolled, or should be controlled - and this isn't stable across releases of material-ui.
So, I am supportive of the idea, but I'm conscious that it would be a breaking change. If it's going to happen, then sooner is better than later I think.

then sooner is better than later I think.

I love the sound of that. The sooner it happens I'll have less code to worry about. But if we ease into it everyone will have time to slowly adept and make smaller changes per release.
I you ask me I'm all in for sooner. But i'm not the only user of this library ( ^_^ )

But if we ease into it everyone will have time to slowly adept and make smaller changes per release.

Yeah, let's wait a bit :grin:.
In the mean time, I think that we have 3 more important stuffs to take care of that shouldn't require breaking changes :tada:

the inline style
the theming
the should component update

I agree with you, the simpler our component are, the best it's. Going in this directino sounds like a good idea :+1:.

I'm very much in agreement with this direction (probably not much of a surprise :smile:). I think it makes a lot of sense to externalize the state and allow the developer to decide where they want state stored. I'd very much like to write some tooling to better integrate material-ui with redux in some of my personal projects and this would certainly help. :+1:

I have just discovered https://github.com/acdlite/recompose. That's preaty interesting!

@oliviertassinari Yeah that's a cool toolset. I ran into it earlier and thought it might be useful too. Also that post on performance is very interesting!

I really like how Recompose addresses such issues :+1: :+1:
But... We still have 2 concerns with Recompose:

They are all function components, you can't ref 'em, for apps it's ok, but for libs that's scary to users.
Imperative methods are not forwarded. sure we wanna remove all the imperative methods. but focus guys!

the should component update
the inline style
the theming
ES6 class definition of component
versioning the documentation
Yeah I think code quality matters too :+1: :+1: I want to address the theme for now, We have clean up a whole lot of components. I don't think I can continue with my previous huge PR.
@oliviertassinari So have we decided on Radium? Do you think how they traverse the tree can impact performance that badly? :grin:
P.S. We can still consider inheritance. I'll continue my work so we can see how it would turn out :grin:

They are all function components, you can't ref 'em, for apps it's ok, but for libs that's scary to users.

That's not true, for performance reason they are using a class under the hood for soom recompose function. That's not yet documented.
Plus, they expose a toClass:
Converts a function component to a class component, e.g. so it can be givena ref.
Returns class components as is.

sure we wanna remove all the imperative methods.

Yes, that would be awesome.

but focus guys!

I guess we can use
this.refs.input.refs.input.focus().

instead of
this.refs.input.focus().

Alright, I'll study Recompose a bit more.
And I agree with Radium too. It's got good stuff :grin:

By the way, radium and react-look are using the HOC like approach :grin:.

@oliviertassinari Yeah I guess -_- This is getting hard :tired_face: I have to give it a lot of thought. @newoga You think about this too :grin:

@alitaheri @oliviertassinari  Will do. I starting writing a long response earlier before deciding it was too long and most likely wasn't worth the read :laughing:. I'm certainly continuing to give this thought. Like we said before, I believe if we continue to refactor/clean up code in the more obvious areas, things will become clearer and we'll have a better "playground" to experiment with these different approaches and libraries.
I have some more specific thoughts maybe in which the order we can start doing some of the activities on the roadmap. I'll jot some ideas down later and share for feedback.

@newoga Sounds good to me, I agree that we should focus on the quality of the code and get rid of all the magic in the code before we can actually work on something new :+1: :+1:

Related: #2957

With the move to a (more) stateless implementation the react alternative preact might be usable, which would bring in a very low bundle footprint of only 3kb: preact.

With the move to a (more) stateless implementation the react alternative preact might be usable, which would bring in a very low bundle footprint of only 3kb: preact.

@Kosta-Github That's an interesting point. Moving to functional components that return JSX technically opens up the possibility for material-ui to be used with frameworks outside of React that use JSX, like preact. :+1:

I really like the idea of separating between stateless & stateful component! :heart:

How do you imagine the directory structure? We could split it the directories pure & stateful in the same repository/package.

Some components have very complex state management. Especially when keyboard navigation is managed (see Datepicker Code). Making them pure would probably require to introduce new function to get to a sensible way of managing what was internal state before e.g. _addSelectedDays in DatePicker should probably become a public callback. The more I think about it, the more I like it. What are your thoughts?

I would love to see the API normalised as @alitaheri suggested. I'm wondering what you think about replacing onChange with something else?
Explanation: onChange is native to React and is called with SynteticEvent that contains the value inside the target. By having onChange(value) or onChange(event, value) we break with the signature of React's onChange API and newcomers need to learn that. It's not a huge big of a deal, but consistent APIs improve the developer experience long term. Why shouldn't we do onChange(event): because we would need to create SynteticEvents while in most cases people only want the value. I suggest onUpdate({ value: <here the real value> }). Having an object with value inside allows us to extend it without breaking the API in the future.

@nikgraf Thanks for taking part in the discussion :+1: The more brain power we have the better the decision we make :grin:

I was thinking more like material-ui/Snackbar and material-ui/Snackbar/stateful. But that's open to discussion we might have more versions than we think O.o
I'm working on a library to keep all controlled props inside a wrapper that will wok like this:
<Wrapper wrap={['value', 'open', 'etc']} ><Component/></Wrapper> it will create a class with onValueChange, onOpenChange, onEtcChange, defaultValue, defaultOpen, defaultEtc props and clearValue, setValue, getValue, ... methods. That way all we need to to is write a file with a wrapper in it :grin:
I'm thinking even a more standard manner. like: onValueChange as I mentioned above.

That wasn't the original reason. it's for integration with the Wrapper. we still pass the event. it won't break their previous knowledge. the thing about passing an object is that it's very uncommon and a bit hard to document and keep track of, but it's something workth discussing :+1: Thanks fo your awesome feedback :smile:

Reading the roadmap, being farily new to React and all, I found this issue and wondered why this.refs was being recommended? Isn't this ignoring React's own warning about Don't Overuse Refs?

why this.refs was being recommended?

@yanickrochon This thread is almost 1-year-old. Things have changed in the ecosystem since then.
That's why. One interesting approach is to allow parent having access to the children is by adding a rootRef callback property, E.g.

I have come to the conclusion that state is bad for business.

@alitaheri I 100% agree, we have removed as much as state as possible in the component migrated to the v1-alpha branch. I think that we can close it, we have learned from our mistakes :).


Windows BSOD with ollama and deepseek

What is the issue?
Ollama kept crashing GPU and getting flickers with my pc while working with VScode and Continue extension.
Works fine for about an hour then throws message about not connecting properly to port.. then resets GPU config.. then BSOD.
When disabling Ollama and Continue, vsCode works fine. Is there any other extension to try?
PC:
Ryzen 5900X
Radeon 6800XT - 24.08.01 drivers
Ollama - latest
Continue - lastest
OS
Windows
GPU
AMD
CPU
AMD
Ollama version
0.3.9

deepseek has always been a problematic family of models, search for deepseek in the issues tracker and you will see a whole bunch of tickets.  A possible workaround was mentioned a little while ago so that's something you could try.  Failing that, there are plenty of other models that are code-aware, you could pull some of those and try them out.

Sorry this isn't more stable, we'll work on improving it. @rick-github summarized this well (thanks!!)

I just wanted to toss in qwen2.5-coder:7b is doing the same thing. In fact it's worse.

Server logs would aid in debugging.

In theory this is from those crashes...
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  11:                     llama.embedding_length u32              = 4096
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  12:                  llama.feed_forward_length u32              = 14336
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  13:                 llama.attention.head_count u32              = 32
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  14:              llama.attention.head_count_kv u32              = 8
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  15:                       llama.rope.freq_base f32              =<PHONE_NUMBER>00
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  16:     llama.attention.layer_norm_rms_epsilon f32              = 0.000010
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  17:                          general.file_type u32              = 2
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  18:                           llama.vocab_size u32              = 128256
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  19:                 llama.rope.dimension_count u32              = 128
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  20:                       tokenizer.ggml.model str              = gpt2
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  21:                         tokenizer.ggml.pre str              = llama-bpe
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  22:                      tokenizer.ggml.tokens arr[str,128256]  = ["!", "\"", "#", "$", "%", "&", "'", ...
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  23:                  tokenizer.ggml.token_type arr[i32,128256]  = [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, ...
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  24:                      tokenizer.ggml.merges arr[str,280147]  = ["Ġ Ġ", "Ġ ĠĠĠ", "ĠĠ ĠĠ", "...
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  25:                tokenizer.ggml.bos_token_id u32              = 128000
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  26:                tokenizer.ggml.eos_token_id u32              = 128009
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  27:                    tokenizer.chat_template str              = {{- bos_token }}\n{%- if custom_tools ...
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - kv  28:               general.quantization_version u32              = 2
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - type  f32:   66 tensors
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - type q4_0:  225 tensors
Sep 20 16:35:42 pillar ollama[503765]: llama_model_loader: - type q6_K:    1 tensors
Sep 20 16:35:42 pillar ollama[503765]: time=2024-09-20T16:35:42.376-06:00 level=INFO source=server.go:625 msg="waiting for server to become available" status="llm server loading model"
Sep 20 16:35:42 pillar ollama[503765]: llm_load_vocab: special tokens cache size = 256
Sep 20 16:35:42 pillar ollama[503765]: llm_load_vocab: token to piece cache size = 0.7999 MB
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: format           = GGUF V3 (latest)
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: arch             = llama
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: vocab type       = BPE
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_vocab          = 128256
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_merges         = 280147
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: vocab_only       = 0
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_ctx_train      = 131072
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_embd           = 4096
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_layer          = 32
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_head           = 32
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_head_kv        = 8
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_rot            = 128
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_swa            = 0
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_embd_head_k    = 128
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_embd_head_v    = 128
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_gqa            = 4
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_embd_k_gqa     = 1024
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_embd_v_gqa     = 1024
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: f_norm_eps       = 0.0e+00
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: f_norm_rms_eps   = 1.0e-05
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: f_clamp_kqv      = 0.0e+00
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: f_max_alibi_bias = 0.0e+00
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: f_logit_scale    = 0.0e+00
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_ff             = 14336
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_expert         = 0
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_expert_used    = 0
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: causal attn      = 1
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: pooling type     = 0
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: rope type        = 0
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: rope scaling     = linear
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: freq_base_train  = 500000.0
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: freq_scale_train = 1
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: n_ctx_orig_yarn  = 131072
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: rope_finetuned   = unknown
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: ssm_d_conv       = 0
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: ssm_d_inner      = 0
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: ssm_d_state      = 0
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: ssm_dt_rank      = 0
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: model type       = 8B
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: model ftype      = Q4_0
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: model params     = 8.03 B
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: model size       = 4.33 GiB (4.64 BPW)
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: general.name     = Meta Llama 3.1 8B Instruct
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: BOS token        = 128000 '<|begin_of_text|>'
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: EOS token        = 128009 '<|eot_id|>'
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: LF token         = 128 'Ä'
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: EOT token        = 128009 '<|eot_id|>'
Sep 20 16:35:42 pillar ollama[503765]: llm_load_print_meta: max token length = 256
Sep 20 16:35:42 pillar ollama[503765]: ggml_cuda_init: GGML_CUDA_FORCE_MMQ:    no
Sep 20 16:35:42 pillar ollama[503765]: ggml_cuda_init: GGML_CUDA_FORCE_CUBLAS: no
Sep 20 16:35:42 pillar ollama[503765]: ggml_cuda_init: found 2 CUDA devices:
Sep 20 16:35:42 pillar ollama[503765]:   Device 0: NVIDIA GeForce GTX 1060 6GB, compute capability 6.1, VMM: yes
Sep 20 16:35:42 pillar ollama[503765]:   Device 1: NVIDIA GeForce GTX 1660, compute capability 7.5, VMM: yes
Sep 20 16:35:42 pillar ollama[503765]: llm_load_tensors: ggml ctx size =    0.41 MiB
Sep 20 16:35:43 pillar ollama[503765]: llm_load_tensors: offloading 32 repeating layers to GPU
Sep 20 16:35:43 pillar ollama[503765]: llm_load_tensors: offloading non-repeating layers to GPU
Sep 20 16:35:43 pillar ollama[503765]: llm_load_tensors: offloaded 33/33 layers to GPU
Sep 20 16:35:43 pillar ollama[503765]: llm_load_tensors:        CPU buffer size =   281.81 MiB
Sep 20 16:35:43 pillar ollama[503765]: llm_load_tensors:      CUDA0 buffer size =  1989.54 MiB
Sep 20 16:35:43 pillar ollama[503765]: llm_load_tensors:      CUDA1 buffer size =  2166.46 MiB
Sep 20 16:35:45 pillar ollama[503765]: llama_new_context_with_model: n_ctx      = 8192
Sep 20 16:35:45 pillar ollama[503765]: llama_new_context_with_model: n_batch    = 512
Sep 20 16:35:45 pillar ollama[503765]: llama_new_context_with_model: n_ubatch   = 512
Sep 20 16:35:45 pillar ollama[503765]: llama_new_context_with_model: flash_attn = 0
Sep 20 16:35:45 pillar ollama[503765]: llama_new_context_with_model: freq_base  = 500000.0
Sep 20 16:35:45 pillar ollama[503765]: llama_new_context_with_model: freq_scale = 1
Sep 20 16:35:45 pillar ollama[503765]: llama_kv_cache_init:      CUDA0 KV buffer size =   544.00 MiB
Sep 20 16:35:45 pillar ollama[503765]: llama_kv_cache_init:      CUDA1 KV buffer size =   480.00 MiB
Sep 20 16:35:45 pillar ollama[503765]: llama_new_context_with_model: KV self size  = 1024.00 MiB, K (f16):  512.00 MiB, V (f16):  512.00 MiB
Sep 20 16:35:45 pillar ollama[503765]: llama_new_context_with_model:  CUDA_Host  output buffer size =     2.02 MiB
Sep 20 16:35:45 pillar ollama[503765]: llama_new_context_with_model: pipeline parallelism enabled (n_copies=4)
Sep 20 16:35:45 pillar ollama[503765]: llama_new_context_with_model:      CUDA0 compute buffer size =   640.01 MiB
Sep 20 16:35:45 pillar ollama[503765]: llama_new_context_with_model:      CUDA1 compute buffer size =   640.02 MiB
Sep 20 16:35:45 pillar ollama[503765]: llama_new_context_with_model:  CUDA_Host compute buffer size =    72.02 MiB
Sep 20 16:35:45 pillar ollama[503765]: llama_new_context_with_model: graph nodes  = 1030
Sep 20 16:35:45 pillar ollama[503765]: llama_new_context_with_model: graph splits = 3
Sep 20 16:35:45 pillar ollama[671265]: INFO [main] model loaded | tid="128451186053120" timestamp=1726871745
Sep 20 16:35:46 pillar ollama[503765]: time=2024-09-20T16:35:46.136-06:00 level=INFO source=server.go:630 msg="llama runner started in 4.01 seconds"
Sep 20 16:35:46 pillar ollama[503765]: [GIN] 2024/09/20 - 16:35:46 | 200 |  4.255382639s |       <IP_ADDRESS> | POST     "/api/chat"
Sep 20 16:36:13 pillar ollama[503765]: [GIN] 2024/09/20 - 16:36:13 | 200 |  5.705392865s |       <IP_ADDRESS> | POST     "/api/chat"
Sep 20 16:36:17 pillar ollama[503765]: [GIN] 2024/09/20 - 16:36:17 | 200 |  1.016583332s |       <IP_ADDRESS> | POST     "/api/chat"
Sep 20 16:36:23 pillar ollama[503765]: [GIN] 2024/09/20 - 16:36:23 | 200 |  1.116937633s |       <IP_ADDRESS> | POST     "/api/chat"
Sep 20 16:36:47 pillar ollama[503765]: [GIN] 2024/09/20 - 16:36:47 | 200 | 14.711946452s |       <IP_ADDRESS> | POST     "/api/chat"
Sep 20 16:37:51 pillar ollama[503765]: [GIN] 2024/09/20 - 16:37:51 | 200 |  5.752310231s |       <IP_ADDRESS> | POST     "/api/chat"
Sep 20 16:46:56 pillar ollama[503765]: [GIN] 2024/09/20 - 16:46:56 | 200 |        17.2µs |       <IP_ADDRESS> | HEAD     "/"
Sep 20 16:46:56 pillar ollama[503765]: [GIN] 2024/09/20 - 16:46:56 | 404 |      63.449µs |       <IP_ADDRESS> | POST     "/api/show"
Sep 20 16:46:58 pillar ollama[503765]: time=2024-09-20T16:46:58.809-06:00 level=INFO source=download.go:175 msg="downloading 78b0a71988a5 in 16 294 MB part(s)"
Sep 20 16:48:21 pillar ollama[503765]: [GIN] 2024/09/20 - 16:48:21 | 200 |         1m24s |       <IP_ADDRESS> | POST     "/api/pull"
Sep 20 16:48:26 pillar ollama[503765]: [GIN] 2024/09/20 - 16:48:26 | 200 |       17.85µs |       <IP_ADDRESS> | HEAD     "/"
Sep 20 16:48:26 pillar ollama[503765]: [GIN] 2024/09/20 - 16:48:26 | 500 |     122.689µs |       <IP_ADDRESS> | DELETE   "/api/delete"
Sep 20 16:59:47 pillar ollama[503765]: [GIN] 2024/09/20 - 16:59:47 | 200 |      16.801µs |       <IP_ADDRESS> | HEAD     "/"
Sep 20 16:59:47 pillar ollama[503765]: [GIN] 2024/09/20 - 16:59:47 | 404 |        47.8µs |       <IP_ADDRESS> | POST     "/api/show"

This looks like llama3.1:8b-instruct-q4_0, not qwen2.5 or deepseek.  Do you have a sample query that causes crashes with qwen2.5?  That would make it easier to test on a local model and would speed debugging.

After a crash of asking where it came up with those options I tried to expedite the question. After the initial crash asking it the following it would get half a word on screen and core dump.
"I had asked you for help with .ctwmrc and you suggested two options, refocus and refocusonclose, neither of which exist in the docs. So where did you come up with that?"

OK, if the new version crashes, set OLLAMA_DEBUG=1, capture some log files from the crash and that will help in resolving the issue.

I'll try but I suspect this is chasing a ghost.

I think we're mixing two different issues in here...  @pitziro mentioned flickering and a BSOD on AMD.  Other logs are showing what I believe is an Ollama crash on NVIDIA.  Let's focus this issue on the AMD OS level crash, and move the discussion of Ollama app crashes to another issue. (please check our backlog for others reporting crashes on the same model and/or GPU before submitting a new one)

Well @pdevine marked my report as a dupe of this Core Dump | applicationError #6882 when I'm nVidia, he's AMD and even more "distance" between things is he's on Windows, I'm on Linux.

@nPHYN1T3 sorry, man. If you think it's a different bug and I close it incorrectly, we can always reopen. I try to get the LLM to find the dupes using embeddings and then go through any matches manually to see if they look the same.

Heh I'm not upset, just with the whole "keep it on the AMD / Win issue" that kinda then separates my report. That said I'm not like O M G FIX NOW MUST HAV! I've found ollama useful here and there but stability aside any model I try hallucinates, ignores details or just spews non-sense so really crashes are almost the least of the issues. I can image there is a large degree of aggravation in figuring out if issues are ollama based or the models fault. I'd love to have a little "buddy" on my machine I can ask questions to expedite various tasks but between the brutally out of date training data (for technical stuff) and the fun little lies it's going to be a good many years before I see any of this having real functionality.

@pitziro in general a BSOD is typically going to be a bug the driver vendor has to fix, so on first boot after the BSOD, you should submit the bug report when prompted if you're OK with sharing that.  It's been a while since you filed this issue, so the crash data may no longer be saved on your system, but if you start up the Radeon Settings, try clicking on the bug icon and see if it has data to upload

I was trying llama 3.1 and qwen 2.5. Both still failing after some hours.
I have given up. Currently using another completion tool and disabled both Ollama and Continue.

Sorry to hear that.

Both still failing after some hours.

Was this still a BSOD OS level crash, or is the failure only a crash of ollama itself?

it was a failure in the Ollama/Continue application that caused my screen to freeze and stutter like it was installing graphic drivers. It only stopped when killing ollama process.

hey @pitziro,
Could you please try DDU and see if it improves anything ? use DDU (better to be in safe mode) to wipe your current driver and reinstall the 24.8.1 driver and if you can still reproduce the issue:
- please submit a BRT report if your OS crashed as mentioned above by Daniel
- please submit share a detailed steps for how we can reproduce the issue on our side: including the code if possible
- take a video, pictures could help a lot as well.
- also please include your OS version, monitor model etc.


refactor alerts/signs store

Refactored stores so that activeAlert is now merged into alerts store (same for signs).
This got caught up in some eslint fixes so there's a bunch of let -> const noice.  Sorry about that.

@trevorgerhardt most relevant files:
https://github.com/conveyal/datatools-manager/pull/43/commits/818dbea985acac1051e33015c614330f9d630746#diff-e5d3fa7d1f1bd2f65e1ffd13dae91d37
https://github.com/conveyal/datatools-manager/pull/43/commits/818dbea985acac1051e33015c614330f9d630746#diff-677e68aa847fdf6ebe74d5fbfaae338b

Codecov Report

Merging #43 into dev will decrease coverage by -0.02%.
The diff coverage is 0%.

@@           Coverage Diff            @@
##             dev     #43      +/-   ##
========================================
- Coverage   0.03%   0.02%   -0.02%
========================================
  Files        278     276       -2
  Lines      10580    8100    -2480
  Branches    3212       0    -3212
========================================
- Hits           4       2       -2
+ Misses     10576    8098    -2478

Impacted Files
Coverage Δ

...main/client/alerts/containers/ActiveAlertEditor.js
0% <ø> (ø)
:white_check_mark:

...c/main/client/signs/containers/ActiveSignEditor.js
0% <ø> (ø)
:white_check_mark:

src/main/client/alerts/actions/activeAlert.js
0% <ø> (ø)
:white_check_mark:

src/main/client/signs/actions/signs.js
0% <ø> (ø)
:white_check_mark:

src/main/client/signs/reducers/signs.js
0% <ø> (ø)
:white_check_mark:

...main/client/alerts/containers/VisibleAlertsList.js
0% <ø> (ø)
:white_check_mark:

src/main/client/signs/reducers/active.js
0% <ø> (ø)
:white_check_mark:

src/main/client/alerts/components/AlertPreview.js
0% <ø> (ø)
:white_check_mark:

src/main/client/signs/components/AffectedEntity.js
0% <ø> (ø)
:white_check_mark:

src/main/client/signs/actions/activeSign.js
0% <ø> (ø)
:white_check_mark:

... and 238 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 cf263c8...8ee89d3. Read the comment docs.


NoClassDefFoundError: kotlin.jvm.internal.Intrinsics

I use fuel for my android project. If I use api level 21 or more it is okey however if I use api level 19 or lower it have "NoClassDefFoundError" issue.

Had the same error when building for JVM, and I was able to solve it by building as a Shadow jar. So it was just a case of not all dependencies being included in the build for some reason.

Closing the issue as fixed.


Feature Proposal: Track errors per field

Report the full errors, not only the numbers of them
Process errors' position and associate it with field-level insights

Thanks @XiNiHa .
@kamilkisiela @n1ru4l If I understand correctly, to achieve this, we first need send the errrors[].path, and not just the count (from Hive agent)?

Yes, but the errors won't have any context (no request/session id, sub-calls to subgraphs or other data sources), we will just know they occurred.


Support node 4.x and higher

Some parts of code are not compatible with node 4.x and higher. Like inappropriate using the Buffer length property which is now readonly. Any possibilities that could be resolved?

Aha. To confirm I just ran the (amazingly thorough) test suite and see some of the tests  of .xlsx failing on node 4.1 on a clean clone.
$> make test

1) should parse test files AutoFilter.xlsb [.xlsb]:
     Error: Unexpected record 0 BrtRowHdr
      at hopper_sty (/Users/me/Dev/js-xlsx/xlsx.js:4915:41)
      at recordhopper (/Users/pieter/Dev/js-xlsx/xlsx.js:1693:6)
      at parse_sty_bin (/Users/me/Dev/js-xlsx/xlsx.js:4856:2)
      at parse_sty (/Users/me/Dev/js-xlsx/xlsx.js:8436:67)
      at parse_zip (/Users/me/Dev/js-xlsx/xlsx.js:11176:26)
      at read_zip (/Users/me/Dev/js-xlsx/xlsx.js:11380:9)
      at Object.readSync [as read] (/Users/me/Dev/js-xlsx/xlsx.js:11396:11)
      at Context.<anonymous> (/Users/me/Dev/js-xlsx/test.js:193:20)
...

and if I comment out tests of xlsb files then get
  1) should parse test files biff5/NumberFormatCondition.xls:
     TypeError: Cannot set property length of [object Object] which has only a getter
      at sbcs_d (/Users/me/Dev/js-xlsx/dist/cpexcel.js:909:20)
      at Object.decode (/Users/me/Dev/js-xlsx/dist/cpexcel.js:1197:40)
      at _gc2 (/Users/me/Dev/js-xlsx/xlsx.js:28:24)
      at Buffer.ReadShift [as read_shift] (/Users/me/Dev/js-xlsx/xlsx.js:1623:13)
      at parse_ShortXLUnicodeString (/Users/me/Dev/js-xlsx/xlsx.js:3082:21)
      at Object.parse_Font [as f] (/Users/me/Dev/js-xlsx/xlsx.js:3470:13)
      at slurp (/Users/me/Dev/js-xlsx/xlsx.js:9229:11)
      at parse_workbook (/Users/me/Dev/js-xlsx/xlsx.js:9350:15)
      at parse_xlscfb (/Users/me/Dev/js-xlsx/xlsx.js:9827:27)
      at readSync (/Users/me/Dev/js-xlsx/xlsx.js:11391:11)
     ...

node_modules\xlsx\dist\cpexcel.js:909
mdb.length = 2 * len;
^
TypeError: Cannot set property length of [object Object] which has only a getter
To correct you need "mdb = new Buffer(mdl)" to change  "mdb = Array(mdl)"
Can anyone make corrections to the repository ?

It appears @fluciotto has a robust fix for this issue as opposed to just commenting out the line as others have. Is this something that you will try to merge into master or should I just use @fluciotto's fork?

@blakehagen that's fantastic news. I'd prefer to merge, will have time next week.  If your work is more urgent, use the other fork, and we can connect in a bit.

Fixed in 0.8.1, test suite currently runs against node versions 0.8 0.9 0.10 0.12 4.2 5 6 7
If you find any issues where something works in the latest iteration of one node version but not another, it is a bug and please open a new issue.


[test] Increase GROMACS sanity check tolerance to 0.01%

@victorusu Is the PR title correct? I had the impression the old threshold was at 0.05%.


[Feature] Kuberay MultiKueue adapter

What type of PR is this?
/kind feature

What this PR does / why we need it:
We want to be bale to run Kuberay workloads (RayJob, RayCluster) in MultiKueue.
Which issue(s) this PR fixes:

Relates to  #3822
Special notes for your reviewer:
Does this PR introduce a user-facing change?

NONE

/ok-to-test

In the current stage I need to add RayCluster e2e test

/retest

/retest


Use Tailscale for networking

Rather than needing to creating/delete an A record in my DNS provider, it would be nicer if the server could automatically join my Tailnet.

Create an ephemeral, reusable token for the host to use
Specify a static hostname so using MagicDNS is reliable (I can probably CNAME terraria.nicholas.cloud to the MagicDNS record

This has been implemented over https://github.com/nchlswhttkr/terrarium/compare/bab435aae92f6ff7d950073b8cc24a4712db0c3a...f4a715f630c22e30cc0f66a13393dff579f0ea7f.


ram optimising

hello
instead of Keyboard.print("hello world");
can you make it do Keyboard.print(F("hello world));
so that the print will not get stored in the ram and instead go in the flash memory making longer line scripts possible
the foto is of a verry long script
without the (F()) it uses around 8k ram
with the (F()) it uses only 220

This is something I used in the original version of Duckuino, but it seems to have gotten lost in translation. However, writing everything to flash may not be the best way of doing things, otherwise, it would probably be the default, I'll need to look into this more

Oooh ok thnx for the responce

@Plazmaz You could add it in your post-processor :D Or we could add a checkbox to let the user decide ^^

Uuuu that whould be nice!

I think that sounds good. I like the idea of being able to disable it.

Haha best software on github!

@Flambello if you think it's good now, get ready for v2.

No problem im glad my suggestion helps!!!

@Flambello @Plazmaz
I have about 5 scripts i need to use this for. I am still learning .js and jquery at the moment
Where in the code could i make this change temporarily?
I searched through the code but nothing stuck out to a novice like myself to make this change without some expert advice,
Thanks in advance!

@bytedeez consider it done.

Since v2 is here and this disappeared, I'm reopening this, @Plazmaz should release the Ram Optimization update some days :D

@Nurrl nope, this is something different. This issue is asking for the use of Fstrings instead of normal strings. Should be an easy fix 😄

Yep ^^ But it Optimizes ram x)


[BANDWIDTH_THROTTLING] Add missing quotaChargeCallback for batch operations and for background deletes.

There are few places in batch operations (ttl update and delete of a composite blob), and in background deletes, where QuotaChargeCallback is null. It leads to inaccurate quota charging for these operations. This PR fixes that issue.

Codecov Report

Merging #2105 (3595c41) into master (73cb245) will increase coverage by 69.88%.
The diff coverage is 96.00%.

@@              Coverage Diff              @@
##             master    #2105       +/-   ##
=============================================
+ Coverage          0   69.88%   +69.88%
- Complexity        0     9569     +9569
=============================================
  Files             0      721      +721
  Lines             0    54761    +54761
  Branches          0     6766     +6766
=============================================
+ Hits              0    38267    +38267
- Misses            0    14374    +14374
- Partials          0     2120     +2120

Impacted Files
Coverage Δ

...va/com/github/ambry/router/TtlUpdateOperation.java
85.54% <ø> (ø)

...ava/com/github/ambry/router/UndeleteOperation.java
82.51% <ø> (ø)

...a/com/github/ambry/router/OperationController.java
76.40% <75.00%> (ø)

...m/github/ambry/router/BackgroundDeleteRequest.java
100.00% <100.00%> (ø)

...ava/com/github/ambry/router/NonBlockingRouter.java
80.90% <100.00%> (ø)

.../main/java/com/github/ambry/router/PutManager.java
87.27% <100.00%> (ø)

...ain/java/com/github/ambry/router/PutOperation.java
91.07% <100.00%> (ø)

...n/java/com/github/ambry/router/RouterCallback.java
100.00% <100.00%> (ø)

...java/com/github/ambry/router/TtlUpdateManager.java
85.10% <100.00%> (ø)

.../java/com/github/ambry/router/UndeleteManager.java
82.65% <100.00%> (ø)

... and 722 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 73cb245...3595c41. Read the comment docs.


v1.4.0 errors during test

With the latest release, I found that tzatziki-spring test throws error during steps "we can mock a real url #n"
Error:  that calling "http://backend/greeting" will retu2023-12-07 15:53:33,267 [ERROR] [http-nio-auto-1-exec-8] o.a.c.c.C.[.[.[.[dispatcherServlet] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: org.springframework.web.client.ResourceAccessException: I/O error on GET request for "http://backend/greeting": backend] with root cause
https://github.com/Decathlon/tzatziki/actions/runs/7129555103/job/19417360696#step:5:8097

Exception is thrown by spring controller than catch as a 500 by default spring handler.
Closing this issue


[Feature]: Need a way to terminate actions that are run automatically or indefinitely

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
Currently, when any action causes an app to go into an unusable state, there is no way to terminate code execution from front end i.e. UI. This causes users to contact support and request a resolution which is done by either tweaking backend or getting on a call to debug the issue requiring manual intervention each time a user hits a dead-end with their app due to faulty code.
Instead, having a UI capability will allow users themselves to debug and salvage any code that's causing the issue. This improves debugging experience and saves user some time if support isn't available at that moment.
Another reason to terminate automatically set actions is when a user is simply testing out new changes on their app and causes any API calls being accounted for and charged to the user
Potential solution

Provide a UI, like a button or a keyboard shortcut that opens up a terminate action modal making it easier for users to debug their app on their own

Edit the app in debugging mode so the user can paly around even on an app that's gone into a bad state (making changes, discarding changes on git for a git-connected app isn't the most elegant solution but is the current workaround for users)

Why should this be worked on?
A couple of scenarios when app goes into an unusable state and needs support to salvage it:

Infinite loop on custom code caused by a trigger field causing the app to hang and be inaccessible (sample app)
Using navigateTo() on the landing page causing a redirect each time user opens the app
Any other actions performed like copy, merge, duplicate that could cause the app to go into an error state

I have the same problem and i just renamed the target page so navigateTo() did not work,
then i just fix the problem on the problematic page.


Add router level metadata

We can already add metadata to specific routes as outlined in the documentation:
const c = initContract();
export const contract = c.router({
    getPosts: {
        ...,
        metadata: { role: 'guest' } as const,
    }
});

It would be nice if we can set router level metadata by adding it to RouterOptions. This would be useful for auth or other useful data for example:
const c = initContract();
export const contract = c.router({
    getPosts: { ... },
    getComments: { ... }
}, {
    metadata: { role: 'guest' } as const,
});

This can work similarly to validateResponseOnClient which can be set on both Router or AppRoute level.

Resolved in #581


Aggregate and publish testimonial/highlight content from collabs/core users

This issue is one of the prioritized recommendations in the Q1 2020 IPFS Ecosystem Audit for execution in Q2/Q3 2020. Tagging it with $auditrecommendation means it's searchable! See all tagged issues in this repo.
(NOTE: Some of this is likely to have been sourced via other efforts by the IPFS ecosystem team. If so, let's make sure to use that content.)
Sourcing, collecting and sharing testimonials/reviews of IPFS can speak to a very wide variety of stakeholders (devs, potential collabs, c-suiters, tech leads, hobbyists, investors, etc) and also serves a large number of workstreams gathered in our ecosystem audit, including:

See what others think about IPFS
Learn who else is using IPFS
Get an idea of how long it'll be before adoption of IPFS hits critical mass
See what other technologies play well with IPFS
etc.

This issue is to gather in a central location testimonial/highlight content from collaborators, core users, media, etc, for repurposing and distributing via a variety of channels:

ipfs.io website
newsletter and blog posts
periodic social media sharing
in-person events, conferences, meetings, etc

IMHO this should be part of the outcomes from the collabs interviews led by @renrutnnej and @andrew.

@momack2 - yes. Adding you for the sake of any similar content that may get generated in 0.5 launch work, though.


At the Speed of Light x Rap God by Dimrain47

Song Name
At the Speed of Light x Rap God
Artist Name
Dimrain47
Source
Youtube
Youtube Link
qMw1TjgDnj33hAFs
Direct File Link
No response
Song ID
467339
Start Offset [ms]
0
Extra
Created from Auto Nong.

accept

reject
invalid YouTube link


move macro define youki_version to use before

Fixes: https://github.com/containers/youki/issues/2812

kind/cleanup

@YJDoc2 Can you help me review this PR? thanks ~


[ServiceBus] Use Servicebus AAD audience instead of letting user supply

Use Servicebus AAD audience instead of letting user supply the audience

@neekam is added to the review. #Closed


[docs] add FedNdarrayDataLoader.ipynb doc in English

Type of change

[ ] Add new papers (Please tell us why you think this paper is awesome!)
[x] Fix the category of an existing paper/papers (Please tell us the reasons)
[ ] Add a new tool/primitive/application with a new markdown page (Thank you! Also, please tell us more about this awesome thing!)

Description

Please include a summary of the change and the relevant motivation.


Update placeholder when placeholderColor is set

Fixes an issue where setting placeholderColor in Interface Builder would not have any effect since the placeholderColor was set after the placeholderText.

thanks!

This is not fixed. I changed placeholderColor in interface builder but it doesn't have any effect...still light gray!

@axiom88-guru I don't think the cocoapod has been updated in a year. If you install from github master it should work.

Thanks for the nudge -- As @ndrewh said, I think I had this fixed in master, but just hadn't pushed out a cocoapod update.
I just released a 1.2.0 version of the cocoapod. Let me know if that update fixes the issue for you.