Inference using ONNX model with and without TRT

Hi,
I managed to make my own ONNX model and run it with TRT following  "jetson-inference/docs/pytorch-collect-detection.md".
(It was really fun to make my own model and run it, thank you for this usuful repo!)
Now I'm curious about inference speed difference between with TRT and without TRT in my environment.
So I want to know how to run this generated ONNX model directly from python without using TRT.
Is there anyone tried this?
What I found is to use ONNXRuntime in python, but I couldn't understand how I can use this with my ONNX model generated here...

This is the code not working correctly, it returns boxes and scores, but never returns correct results seen in jetson-inference.
import onnxruntime
import numpy as np
import cv2

def main(cam):
    # Load image
    ret, frame = cam.read()
    width, height = 300, 300
    frame = cv2.resize(frame, (300, 300))

    # HWC to NHWC
    image_data = np.expand_dims(frame.transpose((2, 0, 1)), 0).astype(np.float32)

    # 1. Make session
    session = onnxruntime.InferenceSession('./model/ssd/mb2-ssd-lite.onnx')

    # 2. Get input/output name
    input_name = session.get_inputs()[0].name   # 'image'
    output_name_scores = session.get_outputs()[0].name     # 'scores'
    output_name_boxes = session.get_outputs()[1].name   # 'boxes'

    # 3. Run
    outputs_index = session.run([], {input_name: image_data})

    # Result
    output_scores = outputs_index[0]
    output_boxes = outputs_index[1]

    # Check input/output name
    print(input_name, output_name_boxes, output_name_scores)

    for scores in output_scores[0]:
        max_index = np.argmax(scores)
        if max_index != 0:
            print(max_index)
            boxes = output_boxes[0][max_index]
            top = boxes[0] * height
            left = boxes[1] * width
            bottom = boxes[2] * height
            right = boxes[3] * width

            top = max(0, np.floor(top + 0.5).astype('int32'))
            left = max(0, np.floor(left + 0.5).astype('int32'))
            bottom = min(height, np.floor(bottom + 0.5).astype('int32'))
            right = min(width, np.floor(right + 0.5).astype('int32'))

            cv2.rectangle(frame, (left, top), (right, bottom), (255, 255, 0), 4)
        cv2.imshow('annotated', frame)

if __name__ == '__main__':
    cap = cv2.VideoCapture(0)
    while True:
        main(cap)
        if cv2.waitKey(0) & 0xff == ord('q'):
            break
    cv2.destroyAllWindows()
    cap.release()

They make warnings a lot so maybe this is the reason, but not sure how to fix.
What I got before inference is this;
2020-08-17 19:16:44.2335104 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.16.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2341353 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.18.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2347130 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.0.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2351802 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.17.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2356974 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.1.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2361732 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.12.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2366507 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.10.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2371097 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.1.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2374919 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.11.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2382034 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.7.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2388413 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'classification_headers.4.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2392517 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'extras.0.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2396451 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.11.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2401185 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.10.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2404994 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.10.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2412516 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.8.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2418114 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'classification_headers.1.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2422242 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.16.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2426082 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'classification_headers.2.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2433136 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.11.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2438395 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.12.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2442875 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'extras.1.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2448371 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.12.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2452333 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'regression_headers.4.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2456155 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.13.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2462784 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.17.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2468682 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.13.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2473696 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'extras.2.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2479610 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.13.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2485706 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.5.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2491866 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.16.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2499566 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.14.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2504068 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'extras.2.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2509461 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.9.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2513962 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.14.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2519410 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'extras.3.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2523425 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.14.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2529647 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.15.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2534155 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.15.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2539452 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.15.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2544189 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'extras.0.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2551279 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.3.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2555280 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.17.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2561316 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.2.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2565087 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'regression_headers.3.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2569393 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.2.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2573222 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.2.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2580875 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'extras.1.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2587102 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.3.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2592950 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.5.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2599697 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.3.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2604859 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.4.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2610230 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'extras.3.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2614735 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.4.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2620125 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.4.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2624624 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.5.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2629851 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.6.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2634761 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.6.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2640517 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.6.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2645179 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.7.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2650892 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'extras.0.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2655835 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.7.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2659828 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'extras.2.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2663736 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.8.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2670358 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.8.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2675041 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.9.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2680226 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'base_net.9.conv.4.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2684909 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'classification_headers.0.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2690436 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'regression_headers.1.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2694775 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'classification_headers.3.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2699381 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'extras.1.conv.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2703347 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'extras.3.conv.7.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2710270 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'regression_headers.0.1.num_batches_tracked'. It is not used by any node and should be removed from the model.
2020-08-17 19:16:44.2715208 [W:onnxruntime:, graph.cc:2709 onnxruntime::Graph::CleanUnusedInitializers] Removing initializer 'regression_headers.2.1.num_batches_tracked'. It is not used by any node and should be removed from the model.

Layers seemed to be removed?

Hello! I wanted to take a doubt that I didn't understand. why does the code force you to use the 300x300 size? another question is, within the detected boxes, how can i receive the object ID to relate to a label.txt?

Hello! I wanted to take a doubt that I didn't understand. why does the code force you to use the 300x300 size? another question is, within the detected boxes, how can i receive the object ID to relate to a label.txt?

Hi,
why I used 300x300 image is bc I noticed my onnx model accept that size
when I see the model using Netron app.
And, for the label, I couldn't get anything from the model but found out
the index of the list returned is important to find the label of boxes. I
noticed I can find correct label when I use that number and label.txt
together.
2021年1月22日(金) 20:10 Douglas Stehling<EMAIL_ADDRESS>
Hello! I wanted to take a doubt that I didn't understand. why does the
code force you to use the 300x300 size? another question is, within the
detected boxes, how can i receive the object ID to relate to a label.txt?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/dusty-nv/jetson-inference/issues/677#issuecomment-765328467,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMZ4Z5FJON4GN5Z4ZJPV4JLS3FMJLANCNFSM4P7KER2Q
.

Hi,
why I used 300x300 image is bc I noticed my onnx model accept that size
when I see the model using Netron app.
And, for the label, I couldn't get anything from the model but found out
the index of the list returned is important to find the label of boxes. I
noticed I can find correct label when I use that number and label.txt
together.
2021年1月22日(金) 20:10 Douglas Stehling<EMAIL_ADDRESS>
Hello! I wanted to take a doubt that I didn't understand. why does the
code force you to use the 300x300 size? another question is, within the
detected boxes, how can i receive the object ID to relate to a label.txt?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/dusty-nv/jetson-inference/issues/677#issuecomment-765328467,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMZ4Z5FJON4GN5Z4ZJPV4JLS3FMJLANCNFSM4P7KER2Q
.

why I used 300x300 image is bc I noticed my onnx model accept that size when I see the model using Netron app.

@AiueoABC @douglastehling that is correct, this is the resolution that the model was trained at.  For example, the default training resolution for ResNet/GoogleNet/Alexnet is 224x224.  Inception is 299x299.  SSD is 300x300.
In theory, you could change these in the training scripts before training the models, but I haven't tested it with alternative resolutions.

why I used 300x300 image is bc I noticed my onnx model accept that size when I see the model using Netron app.

@AiueoABC @douglastehling that is correct, this is the resolution that the model was trained at.  For example, the default training resolution for ResNet/GoogleNet/Alexnet is 224x224.  Inception is 299x299.  SSD is 300x300.
In theory, you could change these in the training scripts before training the models, but I haven't tested it with alternative resolutions.

@douglastehling
This is how the values look like inside scores. In this case, max_index in my code will be '2', and that should be objectID.

@douglastehling
This is how the values look like inside scores. In this case, max_index in my code will be '2', and that should be objectID.


Support Python 3.7

Python 3.7 stable was released on June 27, 2018.
Todo:

[x] Confirm working with Python 3.7
[x] Add Python 3.7 to classifiers in setup.py

I'll add one more step:

[ ] Change travis configuration to do CI against 3.7

At this time, however, Travis doesn't officially support 3.7 yet... https://github.com/travis-ci/travis-ci/issues/9815

its not well documented, but travis does support 3.7,  example https://github.com/capitalone/cloud-custodian/blob/master/.travis.yml

Tests are being run with 3.7 on Kokoro, and 3.7 has been added to setup.py.


Remove weird ssh pub key addition on root

The removed line was basically allowing a virtual machine to access its
hypervisor root account. It really doesn't sound right, and people should
consider cleaning up their /root/.ssh/authorized_keys asap.
If there's a real reason for such an access, it must be properly
documented, and if possible avoided.

+2
Slagle said "that was needed when we had sshuttle running for edpm->crc traffic, but we can remove it now"

/lgtm


Worker nodes not drained gracefully during RKE upgrade

Rancher Server Setup

Rancher version: v2.6.2
Installation option (Docker install/Helm Chart): Docker
Proxy/Cert Details:

Information about the Cluster

Kubernetes version: 1.20, upgrade to 1.21
Cluster Type (Local/Downstream): Downstream

Custom

Describe the bug

When upgrading a cluster via Rancher, the worker nodes aren't drained gracefully, despite force not being specified:

This is a deployment with rolling update configured:
    strategy:
      rollingUpdate:
        maxSurge: 25%
        maxUnavailable: 25%
      type: RollingUpdate

This cluster has 2 worker nodes - rancher-4 and rancher-5
To Reproduce

Create custom 1.20 cluster with at least 2 worker nodes
Configure cluster to drain nodes gracefully
Add deployment with rolling update
Update to 1.21
Observe pods are forcefully restarted

Result
Expected Result

Nodes gracefully drained, and pods restarted on other worker node gracefully
Screenshots

Added above
Additional context

Update:
After observing another upgrade, I could see that the first worker node (rancher-4) drained gracefully as expected. We can also see log output confirming this:
2021/11/09 09:24:12 [INFO] Draining node rancher-4 in c-9l7g4 with flags --delete-local-data=true --force=false --grace-period=-1 --ignore-daemonsets=true --timeout=120s

When rancher drained the second (last of the two) nodes, we again see this as a non-forced drain, however containers are forcefully killed on rancher-5 and scheduled on rancher-4. We can again see this appears to be a non-forced drain however:
2021/11/09 09:25:37 [INFO] Draining node rancher-5 in c-9l7g4 with flags --delete-local-data=true --force=false --grace-period=-1 --ignore-daemonsets=true --timeout=120s

I'm unsure why draining rancher-5 is causing all pods to be forcefully rescheduled immediately

The following events show that apachetest-56dcb44f78-ksf85 was killed (on rancher-4 as it was being drained) before pod/apachetest-56dcb44f78-zpx8z was scheduled on rancher-6
4m26s       Normal   Created                   pod/apachetest-56dcb44f78-ksf85    Created container apache
4m26s       Normal   Started                   pod/apachetest-56dcb44f78-ksf85    Started container apache
..snip..
30s         Normal   Killing                   pod/apachetest-56dcb44f78-ksf85    Stopping container apache
29s         Normal   Scheduled                 pod/apachetest-56dcb44f78-zpx8z    Successfully assigned default/apachetest-56dcb44f78-zpx8z to rancher-6
29s         Normal   Pulled                    pod/apachetest-56dcb44f78-zpx8z    Container image "docker.io/bitnami/apache:2.4.51-debian-10-r18" already present on machine
29s         Normal   Created                   pod/apachetest-56dcb44f78-zpx8z    Created container apache
28s         Normal   Started                   pod/apachetest-56dcb44f78-zpx8z    Started container apache
27s         Normal   TaintManagerEviction      pod/apachetest-56dcb44f78-zpx8z    Cancelling deletion of Pod default/apachetest-56dcb44f78-zpx8z

I can also confirm that this pod has a readiness probe

This was actually user error and not a rancher problem - we weren't using pod disruption budgets.


Mutex not being released on step completion

Summary
When using a variable within the mutex name, Mutex's aren't released until workflow-controller is restarted.
Within the example below, the workflow never completes and waits pending on the final unlock.
Additionally all other workflows aren't able to continue from the initial mutex locked (from gen-number-list).
Restarting the workflow-controller brings the workflow to life and all locks are released.
Diagnostics
GKE - v1.17.12-gke.1504
Argo version: v2.12.2
Workflow: https://gist.github.com/davidcollom/9c6f7d9d1819fe922d21b3a69e561754#file-workflow-yaml
Logs: https://gist.github.com/davidcollom/9c6f7d9d1819fe922d21b3a69e561754#file-logs

Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

@sarabala1979 ?

@sarabala1979 ?

I will look

I will look

@sarabala1979 Something I didn't highlight in my initial report was that one/some of the steps are daemon'd steps, I have a feeling that this could be a good line of investigation of this issue. (I haven't confirmed this)

@sarabala1979 Something I didn't highlight in my initial report was that one/some of the steps are daemon'd steps, I have a feeling that this could be a good line of investigation of this issue. (I haven't confirmed this)

Possibly related to https://github.com/argoproj/argo/pull/4835?

Possibly related to https://github.com/argoproj/argo/pull/4835?

Let me verify that. I am able to reproduce locally.  I am investigating

Let me verify that. I am able to reproduce locally.  I am investigating

@davidcollom I was able to reproduce my old codebase. I found a fix to do AddAfter on the nextWorkflow function.  But This is already fixed in the latest code and I am not able to reproduce it with the latest 2.12.3. Can you try with 2.12.3?
https://github.com/argoproj/argo/blob/6b3ce504508707472d4d31c6c522d1af02104b05/workflow/controller/controller.go#L295

@davidcollom I was able to reproduce my old codebase. I found a fix to do AddAfter on the nextWorkflow function.  But This is already fixed in the latest code and I am not able to reproduce it with the latest 2.12.3. Can you try with 2.12.3?
https://github.com/argoproj/argo/blob/6b3ce504508707472d4d31c6c522d1af02104b05/workflow/controller/controller.go#L295

@sarabala1979 We upgraded to 2.12.3 Upon its release, we came in this morning to see that the same workflow was locked with similar issues.
We are in the process of investigating if we can remove the daemon step to further rule out that this is the cause.
Something that we've noticed and put down to the daemon step/template was that the duration of the workflow continues to increase within the UI, however this issue has been more of a problem than that (will raise as separate issue if we find more info)

@sarabala1979 We upgraded to 2.12.3 Upon its release, we came in this morning to see that the same workflow was locked with similar issues.
We are in the process of investigating if we can remove the daemon step to further rule out that this is the cause.
Something that we've noticed and put down to the daemon step/template was that the duration of the workflow continues to increase within the UI, however this issue has been more of a problem than that (will raise as separate issue if we find more info)

@davidcollom  I have a fix. But I couldn't reproduce on my local. I build docker image docker pull sarabala1979/workflow-controller:mutex.
Is it possible to try it on your env and let me the details and logs?

@davidcollom  I have a fix. But I couldn't reproduce on my local. I build docker image docker pull sarabala1979/workflow-controller:mutex.
Is it possible to try it on your env and let me the details and logs?

I can take a look first thing Monday and see if we find / have this issue and report back after a few days? Thanks for taking a look, it is greatly appreciated!

I can take a look first thing Monday and see if we find / have this issue and report back after a few days? Thanks for taking a look, it is greatly appreciated!

@sarabala1979 I've deployed this release to the workflow-controller only in our cluster, will see how things get on over the next few days and report back.

@sarabala1979 I've deployed this release to the workflow-controller only in our cluster, will see how things get on over the next few days and report back.

@sarabala1979 We had another instance of the locks not being released this morning I'm afraid.
Unfortunately, I'm not able to provide examples without spending some considerable time to redact the output, I'll spend some time this morning to see if the example can reproduce the same issue.

@sarabala1979 We had another instance of the locks not being released this morning I'm afraid.
Unfortunately, I'm not able to provide examples without spending some considerable time to redact the output, I'll spend some time this morning to see if the example can reproduce the same issue.

If its of any use, the following was present in the status:
  synchronization:
    mutex:
      waiting:
      - holder: testproject/create-xxxxxxxxx-ztkw9/create-xxxxxxxx-ztkw9-3743669695
        mutex: xxxxx/Mutex/terraform-xxxxxx

with the workflow being delete-xxxxxxxxx-sknxg (within the same namespace)

If its of any use, the following was present in the status:
  synchronization:
    mutex:
      waiting:
      - holder: testproject/create-xxxxxxxxx-ztkw9/create-xxxxxxxx-ztkw9-3743669695
        mutex: xxxxx/Mutex/terraform-xxxxxx

with the workflow being delete-xxxxxxxxx-sknxg (within the same namespace)

If its of any use, the following was present in the status:
  synchronization:
    mutex:
      waiting:
      - holder: xxxxx/create-xxxxxxxxx-ztkw9/create-xxxxxxxx-ztkw9-3743669695
        mutex: xxxxx/Mutex/terraform-xxxxxx

with the workflow being delete-xxxxxxxxx-sknxg (within the same namespace)

If its of any use, the following was present in the status:
  synchronization:
    mutex:
      waiting:
      - holder: xxxxx/create-xxxxxxxxx-ztkw9/create-xxxxxxxx-ztkw9-3743669695
        mutex: xxxxx/Mutex/terraform-xxxxxx

with the workflow being delete-xxxxxxxxx-sknxg (within the same namespace)

If its of any use, the following was present in the status:
  synchronization:
    mutex:
      waiting:
      - holder: xxxxx/create-xxxxxxxxx-ztkw9/create-xxxxxxxx-ztkw9-3743669695
        mutex: xxxxx/Mutex/terraform-xxxxxx

with the workflow being delete-xxxxxxxxx-sknxg (within the same namespace) create-xxxxxxxxx-ztkw9 successfully completed a few hours before the delete-xxxxxxxxx-sknxg workflow was initialized.
Workflow controller logs referencing this mutext:
time="2021-01-11T16:37:16.386Z" level=info msg="xxxxx/Mutex/terraform-lizzytest2 acquired by xxxxx/create-xxxxxxxxx-ztkw9/create-xxxxxxxxx-ztkw9-3743669695 " mutex=xxxxx/Mutex/terraform-xxxxxx
time="2021-01-12T10:02:55.893Z" level=info msg="xxxxx/Mutex/terraform-lizzytest2 acquired by xxxxx/delete-xxxxxxxxx-sknxg/delete-xxxxxxxxx-sknxg-576744040 " mutex=xxxxx/Mutex/terraform-xxxxxx

The second, line is after restarting the workflow controller.

If its of any use, the following was present in the status:
  synchronization:
    mutex:
      waiting:
      - holder: xxxxx/create-xxxxxxxxx-ztkw9/create-xxxxxxxx-ztkw9-3743669695
        mutex: xxxxx/Mutex/terraform-xxxxxx

with the workflow being delete-xxxxxxxxx-sknxg (within the same namespace) create-xxxxxxxxx-ztkw9 successfully completed a few hours before the delete-xxxxxxxxx-sknxg workflow was initialized.
Workflow controller logs referencing this mutext:
time="2021-01-11T16:37:16.386Z" level=info msg="xxxxx/Mutex/terraform-lizzytest2 acquired by xxxxx/create-xxxxxxxxx-ztkw9/create-xxxxxxxxx-ztkw9-3743669695 " mutex=xxxxx/Mutex/terraform-xxxxxx
time="2021-01-12T10:02:55.893Z" level=info msg="xxxxx/Mutex/terraform-lizzytest2 acquired by xxxxx/delete-xxxxxxxxx-sknxg/delete-xxxxxxxxx-sknxg-576744040 " mutex=xxxxx/Mutex/terraform-xxxxxx

The second, line is after restarting the workflow controller.

@sarabala1979 We had another instance of the locks not being released this morning I'm afraid.

Is this instance using my eng build? Can you provide the workflow controller lock for this workflow?

@sarabala1979 We had another instance of the locks not being released this morning I'm afraid.

Is this instance using my eng build? Can you provide the workflow controller lock for this workflow?

@davidcollom

@davidcollom

Yes, we're using your eng build.

Yes, we're using your eng build.

@davidcollom ok. can I get the entire workflow controller log for this workflow?

@davidcollom ok. can I get the entire workflow controller log for this workflow?

@sarabala1979 Logs have been updated in my gist @ https://gist.github.com/davidcollom/9c6f7d9d1819fe922d21b3a69e561754#file-workflow-controller-logs-12-01-2021-txt

@sarabala1979 Logs have been updated in my gist @ https://gist.github.com/davidcollom/9c6f7d9d1819fe922d21b3a69e561754#file-workflow-controller-logs-12-01-2021-txt

@davidcollom I have added below extra log statement on eng build. Can you include it on your log. grep?
        s.log.Infof("Current Pending: %v", s.pending)
	s.log.Infof("Current Holder: %v", s.lockHolder)

@davidcollom I have added below extra log statement on eng build. Can you include it on your log. grep?
        s.log.Infof("Current Pending: %v", s.pending)
	s.log.Infof("Current Holder: %v", s.lockHolder)

Is this in a new release/image? as I'll need to restart the pod, I've not removed any lines in the previous log, only redacted infromation.

Is this in a new release/image? as I'll need to restart the pod, I've not removed any lines in the previous log, only redacted infromation.

@davidcollom  it is only in my eng build. Just I want to debug who is waiting and who is holding the lock.
Are you sure you are using my eng build?

@davidcollom  it is only in my eng build. Just I want to debug who is waiting and who is holding the lock.
Are you sure you are using my eng build?

$ k get deploy -n argo workflow-controller -o yaml | grep image:
        image: sarabala1979/workflow-controller:mutex

Yes, confirmed we're using your eng build.

$ k get deploy -n argo workflow-controller -o yaml | grep image:
        image: sarabala1979/workflow-controller:mutex

Yes, confirmed we're using your eng build.

@sarabala1979 As discussed in slack, the latest Eng Build shows some good signs of this being resolved.
The example workflow provided initially (which became stuck) completed from end to end without introversion from myself or the team.
We will continue running this build for a few days to ensure our production workflows don't show previous symptoms or any other issues ahead and report back (Monday?) with any findings.

@sarabala1979 As discussed in slack, the latest Eng Build shows some good signs of this being resolved.
The example workflow provided initially (which became stuck) completed from end to end without introversion from myself or the team.
We will continue running this build for a few days to ensure our production workflows don't show previous symptoms or any other issues ahead and report back (Monday?) with any findings.

@sarabala1979 Sorry for not getting back to you yesterday. We've had no issues over the last few days and not had to restart the workflow-controller so looks like the latest fix is working as expected! Thank you so much!

@sarabala1979 Sorry for not getting back to you yesterday. We've had no issues over the last few days and not had to restart the workflow-controller so looks like the latest fix is working as expected! Thank you so much!

@davidcollom Thanks for your update and help. PR is already in review. It will be released next upcoming release

@davidcollom Thanks for your update and help. PR is already in review. It will be released next upcoming release


Unable to see all of variable on inspection

Plugin version 1.10.0
PHP version 7.0.8

This applies in both local variable windows and watch windows

Solved this by increasing max_children and max_data in launch.json see https://github.com/felixfbecker/vscode-php-debug (the launch.json section)


dev.boringcrypto: 1.14.7b4 release

1.14.7 has a security fix:
https://github.com/golang/go/issues?q=milestone%3AGo1.14.7+label%3ACherryPickApproved
Can you give us some input on the timeline?
Thanks again for maintaining this great branch!
@katiehockman @FiloSottile

This has been done. Thanks.


Can I reset my OpenAI password?

Hi, I cannot remember my OpenAI password that I use to start Omega. Can I reset this password or delete the .json file that stores this password? I even tried to install Omega on a new env but it keeps asking for the password rather than setting up a new OpenAI key. Any help would be appreciated! Thanks.

That is a good idea, I will add this feature ASAP.
In the meantime, you can remove the corresponding JSON file in folder '~.omega_api_keys'.
This way it will ask again for the key and for a password.


question about get_rifke(positions) function?

 def get_rifke(positions):
        '''Local pose'''
        positions[..., 0] -= positions[:, 0:1, 0]
        positions[..., 2] -= positions[:, 0:1, 2]
        '''All pose face Z+'''
        positions = qrot_np(np.repeat(r_rot[:, None], positions.shape[1], axis=1), positions)
        return positions

This function  disentangles the global rotations and local rotation/position/velocity.
I plot the pose 0 (red) and pose 10(green) before  and after the function. The blue line means the facing direction.
This is pose[0] and pose[10] before the function:

and this is the visulization after the function:

The function align the root center to zeros and align the facing direction to Z+, but the facing direction is not parallel the Z+ strictly for the rest poses like pose[10] except the pose[0]?
I didn't figure out why?

Hi, I am also not so sure why it's not strictly z+. Is it a common or casual case?

 def get_rifke(positions):
        '''Local pose'''
        positions[..., 0] -= positions[:, 0:1, 0]
        positions[..., 2] -= positions[:, 0:1, 2]
        '''All pose face Z+'''
        positions = qrot_np(np.repeat(r_rot[:, None], positions.shape[1], axis=1), positions)
        return positions

This function disentangles the global rotations and local rotation/position/velocity.
I plot the pose 0 (red) and pose 10(green) before and after the function. The blue line means the facing direction. This is pose[0] and pose[10] before the function:  and this is the visulization after the function:  The function align the root center to zeros and align the facing direction to Z+, but the facing direction is not parallel the Z+ strictly for the rest poses like pose[10] except the pose[0]?
I didn't figure out why?

Hi, I met the same problem. Did you get the answer?

Hi, I get one solution to that, you can refer to #141.


Specification of spectral library files in param.txt (DDA)

Hi,
I have a suggestion in terms of specification of the spectral library files.
Currently, the spectral libraries are specified via the param.txt
library
msdial

Unfortunately, the tool "DDAscore.py" will currently look at a hard-coded location for a specific file name
python ~/Documents/work/software/MetaboKit/src/DDAscore.py
[('M+H', (1.007825, 1, '+')), ('M+Na', (22.989218, 1, '+')), ('M+K', (38.963158, 1, '+'))]
Traceback (most recent call last):
  File "/Users/alka/Documents/work/software/MetaboKit/src/DDAscore.py", line 336, in <module>
    lib_ent=get_cpds()
  File "/Users/alka/Documents/work/software/MetaboKit/src/DDAscore.py", line 286, in get_cpds
    lib_dict.update(read_lib(libpath))
  File "/Users/alka/Documents/work/software/MetaboKit/src/DDAscore.py", line 229, in read_lib
    it_cpd=iter(line.rstrip() for line in open(libpath))
FileNotFoundError: [Errno 2] No such file or directory: '/Users/alka/Documents/work/software/MetaboKit/src/libs/MSMS-Public-Pos-VS12.msp'

I downloaded a library with a different filename MSDIAL-InsilicoMSMS-Lipids-Pos.msp which could not be used, unless copying it to /Users/alka/Documents/work/software/MetaboKit/src/libs and rename the file to `MSMS-Public-Pos-VS12.msp'.
For making the tool more user friendly I would suggest that either the filename and/or the path+filename can be set in the param.txt.
e.g. new_param.txt
library
/Volumes/ExternalVolume/MetaboKIT/test/MSDIAL-InsilicoMSMS-Lipids-Pos.msp

edit: If the parsing is dependent on the type of library e.g. hmdb (.xml), msdial (.msp) - something like this might be sufficient to use without too much refactoring.
library
msdial /Volumes/ExternalVolume/MetaboKIT/test/MSDIAL-InsilicoMSMS-Lipids-Pos.msp

Hi,
first thank you for this nice and fast tool.
Is the issue closed and therefore possible to load own libraries in the next release?
Otherwise, is there a possibility to load custom libraries?
Could you share the code to generate the library files out of the *.msp files?


SwiftyRecordButton

Will you add the SwiftyRecordButton into the library as you have in the demo?

I have no intention on doing that. Maybe at some point in the future I will make a better version as a separate framework, but it won't be a part of SwiftyCam


grpc: 0.0.8-0 in 'lunar/distribution.yaml' [bloom]

Increasing version of package(s) in repository grpc to 0.0.8-0:

upstream repository: https://github.com/CogRob/catkin_grpc.git
release repository: https://github.com/CogRobRelease/catkin_grpc-release.git
distro file: lunar/distribution.yaml
bloom version: 0.6.4
previous version for package: 0.0.7-0

grpc
* Install grpcpp headers which was missing.
* Contributors: Shengye Wang

Duplicate: https://github.com/ros/rosdistro/pull/17529


contrib: Fix analyze_local_images when image has missing layers

This issue was originally addressed in #69, but looks to have been
reverted since then. As of right now, certain images that have missing
layers or layers that are not in the docker save output will cause an error
with the analyze_local_images command. Switching back to reading layers
from manifest.json file from docker save of the image.

Hey there,
It looks like this is (sadly) the best way to do this. I had reproduced a bug locally using this method, but it seems far less likely to occur than to have the command have missing layers.
Can you make your commit simply a git revert of e639367a3082c5a2067803e9c66f1258d4e2b919?

Ya sure, sorry should have thought to do that in the first place. Updated the branch, and you should see the revert only in PR now.


[5.6] Chained queue name and connection settings.

Allow managing chain queue an connections that will persist through the chain and can be changed at any time in the chain to persist from that point.  Does not break or affect current functionality.
https://github.com/laravel/framework/issues/21528

this could be rolled into 5.5 also, since it does not break the current functionality of the chained jobs.

@Artistan This would be a BC break in the 5.5 branch. Every method signature change of a contract or inheritable class/trait are a potential BC break.
Look, for example, that the Illuminate\Bus\Queueable trait is used in every queue job created. If for whatever reason people overloaded the chain() method in the job class this would break existing applications.
That said, this is fine for 5.6. 😃

Your formatting does not match the rest of the framework.

@taylorotwell - can you explain about the formatting please. I can refactor to be more consistent.

Updated formatting to be more consistent with the framework per @GrahamCampbell suggestions.

updated per @jmarcher suggestions.

@GrahamCampbell - can you check your change requests

updated again,  Not sure why @GrahamCampbell review is still there.

I can not see any of the changes I requested

@jmarcher -- this should be everything you mentioned.
https://github.com/laravel/framework/pull/21568/commits/ec8c3ab82a6b6edf85c6fecd408c3a40697d0705

@jmarcher -- additional commits added from your latest reviews. :) thanks!

There is still a lot of bad formatting in this. @themsaid maybe you can take a shot at supporting this stuff.

@taylorotwell here's my attempt on this: https://github.com/laravel/framework/pull/21765

I would greatly appreciate someone could explain "bad formatting" someday.  Seems to be more of a preference in naming?  Thanks for all the feedback.  I hope @themsaid can finish off the feature with good formatting 😁


3.8.1

Release 3.8.1
Bug fixes and other changes

Temporarily disable internal CSS in exported SVGs to fix CORS error when exporting images (#337)
Fix tests for Kedro 0.17 (#338)

Legal notice

[x] I acknowledge and agree that, by checking this box and clicking "Submit Pull Request":

I submit this contribution under the Apache 2.0 license and represent that I am entitled to do so on behalf of myself, my employer, or relevant third parties, as applicable.

I certify that (a) this contribution is my original creation and / or (b) to the extent it is not my original creation, I am authorised to submit this contribution on behalf of the original creator(s) or their licensees.

I certify that the use of this contribution as authorised by the Apache 2.0 license does not violate the intellectual property rights of anyone else.

Tests are failing because it's less than 100% coverage. The main problem is our tests are programmed against a specific project structure. When I made tests work for 0.17, I inadvertently had to remove one test for the previous version and it reduces coverage by 1.2%. Happy for Richard to merge to hotfix. I will rewrite the tests in the new year with the new API.


Use Reactive extensions on PowerToys Run input panel - waiting for the whole input to be typed before performing search

I noticed when using PowerToys Run that typing feels a bit laggy because it seems a query is performed every time you type a character.
Maybe the program could wait for the whole input to be typed before performing the search?

How would the program know if the whole input is typed? You mean to add a short delay?

How would the program know if the whole input is typed? You mean to add a short delay?

Yes a short delay in between characters would do it!

We may be able to actually accomplish this via Reactive extensions.  https://github.com/dotnet/reactive.  No matter what PT Run result list is as slow as the slowest plugin.  Why we have https://github.com/microsoft/PowerToys/issues/14495

I can help out with this if you still want to go with an Rx/debounce approach.

If you want to try it out, 100% please

I was just looking into debouncing for a plugin I'm writing, any progress on this shandsj?

PR is in main now.

I was just looking into debouncing for a plugin I'm writing, any progress on this @shandsj?

Throttle() is the function you’ll want to look into :)

I'm curious, is there support for async Query() plugin methods? I'm working on a Graph search plugin and its calls to the SDK are async. Currently I have to use .Result to get the result which is a bad practice, I'm wondering if there's support for true async Query implementations. If not, is that something we can add?

Is there anything keeping this open?


fix for vs2015 build

this fix enable build application without error with libuv.lib

Can you elaborate on what doesn't work for you?


Scroll to the bottom on switching Coder/Planner/Researcher tabs

Scroll to the bottom on switching Coder/Planner/Researcher tabs

[x] Scroll to the bottom of the tab panel whenever we switch between tabs

This issue has been resolved by PR - (#83)


[Feature Request] configurable amount of extended memory for BOTW Extended Memory pack

I'd like to be able to configure this pack to extend the amount of memory even further (4gb). A setting for this would be appreciated.

Particularly of note here are the new Draw Distance settings, which unfortunately can't all be maxed out simply because there is not enough memory to permit it.

Particularly of note here are the new Draw Distance settings, which unfortunately can't all be maxed out simply because there is not enough memory to permit it.

We can't extend the memory further then 4GBs of RAM since that's outside of 32 bit address range.
What is the problem with having both maxed out? From my testing it worked fine, but I guess that might depend on the area you're in.

We can't extend the memory further then 4GBs of RAM since that's outside of 32 bit address range.
What is the problem with having both maxed out? From my testing it worked fine, but I guess that might depend on the area you're in.

Using maxed out draw distance in combination with a large mod like Second Wind can start to cause issues


AttributeError when first session created is in a subthread

Using a ThreadPoolExecutor with a separate AWS session created for each thread, as per the recommendation (http://boto3.readthedocs.io/en/latest/guide/resources.html#multithreading-multiprocessing), I encountered a strange error that, if caught and suppressed, would no longer raise after the first time it was encountered.
def bucket_connect():
    session = boto3.Session(profile_name='bar')
    s3 = session.resource('s3')
    return s3.Bucket('baz')

def download(day):
    bucket = bucket_connect()
    return download_one(bucket, arg)

results = []
with ThreadPoolExecutor(max_workers=20) as pool:
    jobs = {pool.submit(download, x): x for x in args}
    for future in as_completed(jobs):
        try:
            results.append(future.result())
        except Exception as e:
            LOG.error(f'Error with {jobs[future]}')
            LOG.exception(e)

The error was that the six module didn't have a configparser.
__main__    : ERROR    module 'botocore.vendored.six.moves' has no attribute 'configparser'
Traceback (most recent call last):
  File "grab.py", line 69, in download
    results.append(future.result())
  File "/Users/mike/miniconda/envs/foo/lib/python3.6/concurrent/futures/_base.py", line 398, in result
    return self.__get_result()
  File "/Users/mike/miniconda/envs/foo/lib/python3.6/concurrent/futures/_base.py", line 357, in __get_result
    raise self._exception
  File "/Users/mike/miniconda/envs/foo/lib/python3.6/concurrent/futures/thread.py", line 55, in run
    result = self.fn(*self.args, **self.kwargs)
  File "grab.py", line 62, in download
    bucket = bucket_connect()
  File "grab.py", line 19, in bucket_connect
    session = boto3.Session(profile_name='bar')
  File "/Users/mike/miniconda/envs/foo/lib/python3.6/site-packages/boto3/session.py", line 80, in __init__
    self._setup_loader()
  File "/Users/mike/miniconda/envs/foo/lib/python3.6/site-packages/boto3/session.py", line 120, in _setup_loader
    self._loader = self._session.get_component('data_loader')
  File "/Users/mike/miniconda/envs/foo/lib/python3.6/site-packages/botocore/session.py", line 701, in get_component
    return self._components.get_component(name)
  File "/Users/mike/miniconda/envs/foo/lib/python3.6/site-packages/botocore/session.py", line 897, in get_component
    self._components[name] = factory()
  File "/Users/mike/miniconda/envs/foo/lib/python3.6/site-packages/botocore/session.py", line 181, in <lambda>
    lambda:  create_loader(self.get_config_variable('data_path')))
  File "/Users/mike/miniconda/envs/foo/lib/python3.6/site-packages/botocore/session.py", line 265, in get_config_variable
    elif self._found_in_config_file(methods, var_config):
  File "/Users/mike/miniconda/envs/foo/lib/python3.6/site-packages/botocore/session.py", line 286, in _found_in_config_file
    return var_config[0] in self.get_scoped_config()
  File "/Users/mike/miniconda/envs/foo/lib/python3.6/site-packages/botocore/session.py", line 348, in get_scoped_config
    profile_map = self._build_profile_map()
  File "/Users/mike/miniconda/envs/foo/lib/python3.6/site-packages/botocore/session.py", line 220, in _build_profile_map
    self._profile_map = self.full_config['profiles']
  File "/Users/mike/miniconda/envs/foo/lib/python3.6/site-packages/botocore/session.py", line 375, in full_config
    self._config = botocore.configloader.load_config(config_file)
  File "/Users/mike/miniconda/envs/foo/lib/python3.6/site-packages/botocore/configloader.py", line 106, in load_config
    parsed = raw_config_parse(config_filename)
  File "/Users/mike/miniconda/envs/foo/lib/python3.6/site-packages/botocore/configloader.py", line 147, in raw_config_parse
    cp = six.moves.configparser.RawConfigParser()
AttributeError: module 'botocore.vendored.six.moves' has no attribute 'configparser'

My solution was to simply create a session in the main thread before creating new sessions in the subthreads.
Python v3.6, Miniconda distribution.
Is there some sort of import cycle that's failing if I don't connect in the main thread?

We would have to do some further research as to why that may be happening. I have not seen that error before.
One question that I do have as we look into this is: Are you just using the threads to download an object from S3? I only ask this because while it is not recommended to share resource objects across threads, it is safe to share clients across threads. So something like this could potentially help you avoid the issue if you do not need to use the resource layer:
def download(client day):
    bucket = bucket_connect()
    return download_one(bucket, arg)

results = []

session = boto3.Session(profile_name='bar')
client = session.client('s3')
with ThreadPoolExecutor(max_workers=20) as pool:
    jobs = {pool.submit(download, client, x): x for x in args}
    for future in as_completed(jobs):
        try:
            results.append(future.result())
        except Exception as e:
            LOG.error(f'Error with {jobs[future]}')
            LOG.exception(e)

using the threads to download an object

Yes.
BTW, I changed tactics to call aws s3 sync via subprocess and found the downloads much faster. Or it might have been some random fluctuation of internet speed. Some days I feel like a cargo cult programmer.

share clients across threads

Your example shows the Session shared across threads, but the doc (http://boto3.readthedocs.io/en/latest/guide/resources.html#multithreading-multiprocessing) shows creating a new session per thread. Before I'd read the doc, I was sharing a session across threads and had not encountered the issue. Perhaps the solution is simply keeping a shared session?

Hi,
have the same issue, what I guess until now is a race condition in module six where moves is using a LazyModule.

This is a known issue in six<1.9.0: https://github.com/benjaminp/six/issues/98
I've opened PR #1214 to upgrade the vendored version of six.

Thanks for the pull request! I'll go ahead and close this issue for now. If anybody is still having this issue feel free to follow up!


There is a game view, which shows the cards of all the players on a playing board

closed by https://github.com/sopra-fs22-group-10/client/commit/afe46012f01c5f79c8e17a8b56a8288216ac00e0


Pass propsData in beforeRouteEnter's next callback and call it before mounting

So, after reading #779, #714 and running some tests of my own, I understand that the order of execution when using beforeRouteEnter is:

beforeRouteEnter
next
All component's lifecycle hooks starting from beforeCreate down to mounted
next's callback (which usually sets data on the vm)

So, if you're trying to display a nested property on your data object, you need to initialize it, otherwise you'll get runtime errors (e.g., cannot read property of null).
Sometimes it may be a little complicated/tedious to initialize data when it's structure is expected to be deep/complex, but it's often necessary if you're directly accessing nested properties in your template or computed properties. This can of course also be avoided by having something like {{ person.name}}, but it also makes your markup more verbose.
I feel like the way beforeRouteEnter should work, is after you run your async operations and have your data ready, you should be able to somehow pass propsData during the vm creation. This would feel more natural to me, since data is coming from outside and these components would be guaranteed their data is already there when it renders.
I'd love to be able to do something like this:
export default {
  props: {
    person: {
      type: Object,
      required: true
    }
  },
  beforeRouteEnter(to, from, next) {
    ...
    next({
      person: {
        name: 'Carlos'
      }
    });
  }
}

A couple of thoughts:

It could also be possible to pass a regular options object for further customization instead of just propsData.
This doesn't need to be a breaking change (if implemented). next could check whether the argument is a function or not. If not, treat as options.

is there any progress ?

No, right now the next callback waits for the next tick, that's why it's only called after the mounted hook

@posva: The next callback gets called after mounted but if we pass an Object as argument there's no need to put it at the end of the event loop and could resolve the async loading problem:
beforeEnter(to, from, next) {
   axios.get().then(data => next({props: {data}));
}

BUT! We than we need also a beforeUpdate() to be able to react to $param changes

Btw, this also works actually:
        props: function(to) {
          console.log('PROPS', to.meta.props);
          return to.meta.props;
        },
        beforeEnter(to, from, next) {
          console.log('before enter', to.meta);
          setTimeout(function() {
            to.meta.props = {
              id: to.params.id,
              test: "123"
            };
            next();
          },500);

@psi-4ward: Very interesting! It would kind of make route definitions rather verbose going with this approach, though. I feel like the general preference is in-component guards for this sort of thing.
Kind of off-topic, but I like Ember's approach where the route class has a model(params) hook where you return a Promise and after that resolves the controller is instantiated. If you configure it so, changing query params tied to route segments will also trigger the hook.
Returning promises allows for much cleaner code, IMO. Something like this would be cool:
export default {
  async model (to) {
    const { data } = await axios.get(`/api/items/${ to.params.id }`)
    return { item: data }
  },
  props: {
    item: {
      type: Object,
      required: true
    }
  }

I wrote a tiny module which does things with SSR
https://www.npmjs.com/package/vue-router-guard
FYR

As this is something that can be written in userland in a helper function and we don't want to overcomplicate apis and give even more solutions around data fetching, we will pass on this
Related #1923

Use Vuex to commit the data to the state, then get it in the component.
It is a not overcomplicate solution.


Converted Layout to use std::string and basic_string_view

Converted the Layout structure to use std::string and basic_string_view.
This change may fix obtuse and ill-defined ownership memory practices with cleaner code getting rid of old C memory allocations stuff for the Layout system.
Mostly changed in lib/ts/Layout.cc trying to get rid of char *.
There are some other files changed including functions reading directories in lib/record/RecCore.cc and some cleaning up changes from ats_scoped_str to std::string
Catch unit test for new Layout structure in lib/ts/unit-tests/test_layout.cpp

He is moving documentation into the system.
here is a text dump of the main documentation to help explain what all this is
Documentation for ts_runroot
Introduction:
This program is for the setup of traffic server runroot: TS_RUNROOT
It will create a runtime sandbox for any program of traffic server to run under
files in cmd/traffic_runroot
How it works:
1. create a sandbox directory for programs to run under
2. copy each build time directories & files over to the sandbox
3. emit a yaml file called "runroot_path.yaml" for other program to grab the information of the runroot layout.
Note:
Only works on Unix based system.
path to sandbox must be absolute path
Usage example:
version: ./traffic_runroot -V (--version)
- print out the version info of current running traffic server
help: ./traffic_runroot -h (--help)
- print the usage of traffic_runroot
- run individual switch to see example(./traffic_runroot init -h)
initialize: ./traffic_runroot init /path/to/sandbox (create the sandbox)
- if no path is found, it will find the ENV variable $TS_RUNROOT
remove: ./traffic_runroot rm /path/to/sandbox (remove the sandbox)
- remove the sandbox we created(check yaml file)
- if no path provided, it will find the ENV variable $TS_RUNROOT
- if $TS_RUNROOT not found, it will find bin executing path & current working directory
force: ./traffic_runroot --force init /path/to/sandbox (force create sandbox)
- overwrite existing directory
Runroot handling for each program:
usage example: trafficserver --run-root=/path/to/runroot
- this will use the path as runroot for trafficserver
- if no path provided, it will find the ENV variable $TS_RUNROOT
- if $TS_RUNROOT not found, it will find bin executing path & current working directory
implement details

traffic_runroot: the main executing program

call functions in engine.cc & file_system.cc

engine: structure for informaiton of the runroot passing around

details in engine.cc engine.h

filesystem: a simple filesystem supports mkdir(with parent), copy (recursively), remove (recursively)

details in file_system.cc file_system.h

runroot handling for all programs:

function & details in lib/ts/runroot.cc, some parsing details in lib/ts/ink_args.cc

The main point of this work is to solve few issues:

Improve the testability of the code.
A better fix to TS_ROOT with configuration that have hardcode path in the build time layout
allow a safe way to make changes and test them without modifying the default configs.

This should help with development, testing and Ops work.
The yaml file that defines layout structure can be modified by the user to control more custom layouts or to reduce what paths are overridden. This should provide fine grain control to easily setup runtime roots/sandboxes for various development, testing or operational needs

This needs to be multiple smaller commits to be reviewable.

@dragon512 Without spending a lot of time to break this apart, it's immediately clear that changing Layout to use std:string types could be an independent change. I just don't think you're going to get a thorough review with a giant commit where the reviewer has to reverse engineer the problem, solution and all the code changes.

The std::string was to fix obtuse and ill-defined ownership memory practices that would have caused a more complex impl of the layout to solve this problem we wanted to solve, Honestly working harder to make a fix vs smarter is not a KISS practice. The new code reduces the number of memory allocations, and as we move to using std::string and std/ts::string_view we will reduce more memory allocation and leaks with a solid RAII ownership clean policy of string memory. This code has "less" changes as it would require more code to impl this a C char* correctly with the YAML parser, etc
most of the complexity of the diff is from lack of better infrastructure code. honestly code such as:
print_var("INCLUDEDIR", ats_strdup(Layout::get()->includedir.c_str()), json, false);
would not show up if we had a better print_var() overload. In fact this is the case for most of the diff code are the addition of .c_str(). The rest is "new" code.
I can have the @chitianhao break out the new command line tool and documentation in to a separate request. keeping the core layout and cli fixes intact with unit testing. However anything else is adding complexity and risk to the stability of the code. I don't feel it is a good practice to break the tests from these fixes. This break up will add the feature in the core and then another diff to add tools and documentation and tests for this feature. This should break it up this diff in to 19 files. I cannot do better as the design has a "wonderful" copy paste pattern anti-pattern in all the command line tools. The second diff will then be 14+ file ( mostly new files, tests and updated makefile.am tweaks)

Now this pull request only contains the layout structure fix and changes. The traffic runroot stuff will be a separate pull request later. @jpeach @dragon512

[approve ci]

[approve ci]

@chitianhao Please read this blog post about commit messages. The commit message (and PR) should explain what you are doing, how and why. I suggest the commit subject should be "Converted Layout to use std::string and string_view." The following paragraph should discuss the benefits of doing this, the implications of what you changed and anything you think that future code readers would appreciate knowing. Describe your change to yourself in 6months when you have forgotten why you did everything :)

Some other changes of std::string and string_view. I will update the test later and squash the commits.

[approve ci]

[approve ci]

[approve ci]

The layout code is clean and got rid of all char *. Some functions in RecCore.cc are changed to using std::string. There are also some fixes to get rid of unnecessary ats_scoped_str. All temporary life time issues are fixed. @SolidWallOfCode @dragon512 @jpeach

It would be good to run ASAN leak sanitizer on this PR.

[approve ci]

[approve ci]

Memory leaks are fixed.

To clarify. This also fixed some small pre-existing leaks. I don't believe this has added any leaks at this point. There is a new function ats_stringdup() that should allow a stopping point of change propagation for std::string, etc when dealing with the existing "c" based code that duplicates memory and passes that back for someone else to delete. I am ready to approve this this request. @jpeach @SolidWallOfCode are there any issue that we cannot address in a different PR

[approve ci]

[approve ci]

@jpeach Can you Green light this so we can get to this in. I only have the intern for about another week or so.

@jpeach Can you please help move this forward.

[approve ci]

[approve ci]


Enforce contract runtime concurrency limit

Resolves #1899
This PR introduces a number of tweaks to the ContractRuntime's concurrency. The thinking is that the current thread ends up blocking the reactor, when many requests run simultaneously with the HTTP server producing many events.
Changes:

All calls to execute_finalized_block are executed in a new async task. In order to do this, ExecutionPreState and the exec_queue need to be shared to the task.
Calls to execute_finalized_block call into LMDB code. This PR introduces using tokio::task::unconstrained to prevent IO with LMDB from being continually interrupted by the tokio scheduler.

Empirically, I am able to reproduce the long long stalls on dev by hammering a node with transfers and simultaneously curl-ing the metrics endpoint
Results
$~/D/casper-node (dev)> time curl -s localhost:14101/metrics | grep pending
________________________________________________________
Executed in    8.43 secs   fish           external
   usr time    2.56 millis  1035.00 micros    1.53 millis
   sys time    8.97 millis  460.00 micros    8.51 millis

$~/D/casper-node (dev) [SIGINT|SIGINT]> time bash -c "curl -s localhost:14101/metrics | grep pending'
                                                  ^C
$~/D/casper-node (dev) [SIGINT|SIGINT]> time bash -c "curl -s localhost:14101/metrics | grep pending"
# HELP pending_deploy amount of pending deploys
# TYPE pending_deploy gauge
pending_deploy 2053

________________________________________________________
Executed in    5.16 secs   fish           external
   usr time   12.72 millis    0.00 micros   12.72 millis
   sys time    1.29 millis  912.00 micros    0.38 millis

$~/D/casper-node (dev)> time bash -c "curl -s localhost:14101/metrics | grep pending"
# HELP pending_deploy amount of pending deploys
# TYPE pending_deploy gauge
pending_deploy 1601

________________________________________________________
Executed in    3.13 secs   fish           external
   usr time    7.80 millis    0.00 micros    7.80 millis
   sys time    5.12 millis  803.00 micros    4.32 millis

With the changes in this PR, I am unable to reproduce a long stall.
$~/D/casper-node (contract-runtime-concurrency-limit)> time bash -c "curl -s localhost:14101/metrics | grep pending"
# HELP pending_deploy amount of pending deploys
# TYPE pending_deploy gauge
pending_deploy 5316

________________________________________________________
Executed in   21.41 millis    fish           external
   usr time    8.51 millis  823.00 micros    7.68 millis
   sys time    2.00 millis    0.00 micros    2.00 millis

$~/D/casper-node (contract-runtime-concurrency-limit)> time bash -c "curl -s localhost:14101/metrics | grep pending"
# HELP pending_deploy amount of pending deploys
# TYPE pending_deploy gauge
pending_deploy 0

________________________________________________________
Executed in   11.49 millis    fish           external
   usr time   10.10 millis  846.00 micros    9.25 millis
   sys time    2.21 millis    0.00 micros    2.21 millis

$~/D/casper-node (contract-runtime-concurrency-limit)> time bash -c "curl -s localhost:14101/metrics | grep pending"
# HELP pending_deploy amount of pending deploys
# TYPE pending_deploy gauge
pending_deploy 0

Looking good! I say we slap in fatal!s instead of those unwraps and this is good to go.

Talked about the unwrap()s; since this is a regression it is better to have this solution in place and remove the Mutex in a subsequent PR.

bors r+


Batch mode?

Hello!
I have just copied just about every save file I have from my old memory cards and I would like to extract them in batch since they are quite a lot of them. Both PS2 and PS1.
My goal:

Extract PS1 as .mcr so it can be imported using PSXGE.
Extract PS2 as $gameId folder, which can be used by PCSX2 for loading.

I wasn't able to find a command line usage yet which I could utilize for batch processing.
Have a great day and kind regards,
Ingwie

Hi Ingwie, there's no command line implementation and I'm not actively working on this project at this time.   I suggesting looking at something like AutoIt to enable you to batch process the files without needing any changes to PSV Exporter.


Change "Viruses" to "Bacteriophages" in Domain of Annotation Service

It is currently misleading, making people think that we have an annotation service for all viruses.

https://github.com/PATRIC3/p3_web/pull/969

Duplicate and on prod.


in-model config getting overwritten for packages

This is only occurring in development. If I set a default materialization for an entire project, this is overriding in-model materialization config. It should not, and it does not in 0.7.1.

oddly enough, the code that generates this has not changed in 8 months.

@drewbanin is there some model specificity here that i'm missing? comment in source config reads:
   64 │         Config resolution order:
   65 │
   66 │          if this is a dependency model:
   67 │            - own project config
   68 │            - in-model config
   69 │            - active project config
   70 │          if this is a top-level model:
   71 │            - active project config
   72 │            - in-model config
   73 │         """

@cmcarthur unsure -- tbh i think the current implementation makes sense! Can look into whether or not this is actually a regression

@drewbanin maybe it was not working properly before then? in any case, i think there's a specificity problem here. for example, I think it's weird that an own project config at the top level of a package like:
models:
  snowplow:
    materialized: view

would override an in-model config, however this one feels like it should override the in-model config for specific_model:
models:
   snowplow:
      specific_model:
        materialized: view

cc @jthandy are you expecting this to work like the second example?

I agree with @drewbanin that it has been working this way all along. There is a reasonable debate to be had about which of these two is better--I don't have an extremely strong opinion as there have been instances where I could see both sides. However, I don't think we should change this at the current time—it is not a regression IMO.

ok, closing this. I think it's part of the bigger topic of making model configurations less onerous


address incompatibility with py27

assure using py3

As of right now: master branch is (I think) py27 compatible, but the proposed updated version (branch: touch-ups), is not. To be determined whether we make a hard break on not supporting P27, or if we should go back in and make it 27 compatible.
I think if we do decide on Py3 only, the equivalent of this check can be covered by how we release on Pypi - though it might be useful to have this check in the code for anyone playing with the dev version.


Issues/589

closes #589

v12.1.0 has been released and contains a fix for the issue. Feel free to reopen the issue or to submit a new one if you meet any problems.


Skipgram.py typo

Hi fchollet!
Thanks for great software, which was successfully applied by me to train convnets! It really saved me much time and pain, which I definitely had if I had to learn Theano :-)
But when I tried to run keras to learn word embeddings, I had figured out, that you probably mean to say 'model.fit(X, labels)'  instead of 'model.train(X, labels)' ( in skipgram_word_embeddings.py, line 132 ). Because when I run this file as is, I'm getting this output:
Fit tokenizer...
0
Save tokenizer...
Build model...
Epoch 0
0
Traceback (most recent call last):
File "./skipgram_word_embeddings.py", line 143, in
loss = model.train(X, labels)
AttributeError: 'Sequential' object has no attribute 'train'

I also come across the same problem. Can anyone know why this will happen?

That example is long outdated and has been removed from Keras a while back.
The method you should be using is "train_on_batch", not "train".
On 16 January 2016 at 09:51, tingtinglu<EMAIL_ADDRESS>wrote:

I also come across the same problem. Can anyone know why this will happen?
—
Reply to this email directly or view it on GitHub
https://github.com/fchollet/keras/issues/643#issuecomment-172237802.

Thank you so much! And I have another question,
I define the model as follows:
def create_model():
model = Sequential()
model.add(Convolution2D(4, 1, 5, 5, border_mode='valid'))
model.add(Activation('relu'))

model.add(Convolution2D(8,4, 3, 3, border_mode='valid'))
model.add(Activation('relu'))
model.add(MaxPooling2D(poolsize=(2, 2)))

model.add(Convolution2D(16, 8, 3, 3, border_mode='valid'))
model.add(Activation('relu'))
model.add(MaxPooling2D(poolsize=(2, 2)))

model.add(Flatten())
model.add(Dense(16*4*4, 128, init='normal'))
model.add(Activation('relu'))
model.add(Dropout(0.2))

model.add(Dense(128, nb_class, init='normal'))
model.add(Activation('softmax'))
return model

But I obtain the exception: : Layer is not connected. Did you forget to set "input_shape"?
Could you help me to solve this problem? Thanks so much!


White bar in full screen

Describe the bug
When I connect in full screen from MacOS FreeRDP to Windows 10 (maybe other versions / OS) a white bar appears at the bottom and covers the Windows screen and that white part becomes inaccessible.

Application details
xfreerdp version 2.5.0
XQuartz version 8.1
OS version macOS Sierra 10.12.6
Command line used : sudo /opt/local/bin/xfreerdp /user:John /v:<IP_ADDRESS> /f
Output of xfreerdp /buildconfig :
This is FreeRDP version 2.5.0 (n/a)
Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_FLAG_SEARCH_PATHS_FIRST=1 HAVE_GETLOGIN_R=1 HAVE_INTTYPES_H=1 HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB= HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIBS= HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL= HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H= HAVE_SYS_FILIO_H=1 HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H=1 HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H= HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=OFF WITH_CAIRO=ON WITH_CCACHE=OFF WITH_CHANNELS=ON WITH_CLANG_FORMAT=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_URBDRC=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_DSP_FFMPEG=OFF WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=TRUE WITH_FFMPEG=TRUE WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_ICU=OFF WITH_JPEG=ON WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=OFF WITH_MACAUDIO=ON WITH_MACAUDIO_AVAILABLE=1 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_OPENCL=OFF WITH_OPENH264=OFF WITH_OPENSSL=ON WITH_PCSC=ON WITH_PROFILER=OFF WITH_PULSE=OFF WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SERVER=OFF WITH_SERVER_INTERFACE=ON WITH_SMARTCARD_INSPECT=OFF WITH_SOXR=OFF WITH_SSE2=ON WITH_SWSCALE=OFF WITH_THIRD_PARTY=OFF WITH_VAAPI=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_WINPR_TOOLS=ON WITH_X11=ON WITH_X264=OFF WITH_XCURSOR=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XV=ON WITH_ZLIB=ON
Build type:          MacPorts
CFLAGS:              -pipe -Os -DNDEBUG -I/opt/local/include -DWINPR_DLL
Compiler:            AppleClang, <IP_ADDRESS>00039
Target architecture: x64
Thanks!

@azeitegalo ok:

NEVER start xfreerdp with sudo! That is just wrong and opens up a security nightmare you don´t want.
mac is not known to have a fully working X11 environment, so without some more debug information (logs, ...) I can´t tell
There are some things that (might) be of interest though:

WITH_DSP_FFMPEG=OFF means you don´t have proper sound support
WITH_ICU=OFF means you don´t have proper unicode support (e.g. clipboard might fail)

Ok, just checked a custom build from 2.5.0, there is no white bar here.

XQartz 2.8.1 (xorg-server 1.20.11)
Mac OS 12.0.1

buildconfig:
This is FreeRDP version 2.5.0 (2.5.0)
Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_FLAG_SEARCH_PATHS_FIRST=1 HAVE_GETLOGIN_R=1 HAVE_GETPWUID_R=1 HAVE_INTTYPES_H=1 HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB= HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIBS= HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL= HAVE_STRNDUP=1 HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H= HAVE_SYS_FILIO_H=1 HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H=1 HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H= HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS= WITH_CAIRO=ON WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLANG_FORMAT=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CLIENT_MAC=OFF WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_EVENTS=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_URBDRC=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=ON WITH_DSP_FFMPEG=ON WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=TRUE WITH_FFMPEG=TRUE WITH_FREERDP_DEPRECATED=OFF WITH_FUSE=ON WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_ICU=ON WITH_JPEG=OFF WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=OFF WITH_MACAUDIO=ON WITH_MACAUDIO_AVAILABLE=1 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_NATIVE_SSPI=OFF WITH_NEON=ON WITH_OPENCL=OFF WITH_OPENH264=OFF WITH_OPENSC_PKCS11_LINKED=OFF WITH_OPENSSL=ON WITH_PCSC=ON WITH_PKCS11=OFF WITH_POLL=ON WITH_PROFILER=OFF WITH_PULSE=ON WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SERVER=OFF WITH_SERVER_INTERFACE=ON WITH_SMARTCARD_EMULATE=OFF WITH_SMARTCARD_INSPECT=OFF WITH_SMARTCARD_PCSC=ON WITH_SOXR=ON WITH_SSE2=OFF WITH_SWSCALE=ON WITH_THIRD_PARTY=OFF WITH_VAAPI=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_VERBOSE_WINPR_ASSERT=ON WITH_WINPR_DEPRECATED=OFF WITH_WINPR_TOOLS=ON WITH_X11=ON WITH_X264=OFF WITH_XCURSOR=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=OFF WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XV=ON WITH_ZLIB=ON
Build type:          Debug
CFLAGS:               -Wno-unused-parameter -Wno-unused-macros -Wno-padded -Wno-c11-extensions -Wno-gnu -Wno-unused-command-line-argument -Wno-deprecated-declarations -fno-omit-frame-pointer -DWINPR_DLL
Compiler:            Clang, <IP_ADDRESS>00029
Target architecture: ARM


how to get the result of instance segmentation?

how to get inference result of instance segmentation

We will release the ViT-L instance segmentation model in several days.


Api is not matching the one from bson - getTimestamp

getTimestamp should return the Date at the moment is returning the number

Can you submit a PR to fix this?

It's actually returning Date as of now, but is typed to return number. I'll make a quick PR to fix it. :)

The PR #46 broke all tests.  I am going to revert it in the interim.
I also noticed we need to merge this https://github.com/418sec/bson-objectid/pull/2.

This should be fixed now in v2.0.3


Config build.rustc-wrapper is unused.

Problem

I added build.rustc-wrapper = "sccache" to use the sccache in my builds, but when running any cargo command, it says that  build.rustc-wrapper is an unused key.
I found the key in The Cargo Book (https://doc.rust-lang.org/cargo/guide/build-cache.html).
Steps

Install sccache cargo install sccache
Add build.rustc-wrapper = "sccache" to Cargo config ($CARGO_HOME/config)
Run cargo build in any project

Notes
Output of cargo version: cargo 1.40.0 (bc8e4c8be 2019-11-22)

Rust version: 1.40.0
OS: Windows 10

Thanks, this has already been fixed via #7575

Hi, I still see the error message on cargo 1.44.0-nightly.

Hi, I still see the error message on cargo 1.44.0-nightly.

Can you show a sample config file that reproduces the issue and the text of the warning?  I can't seem to reproduce it.

@ehuss
I installed sccache with cargo install sccache, and have these contents in my ~/.cargo/config file:
[build]
rustc_wrapper = "sccache"

[expand]
theme = "Monokai Extended Origin"

where sccache is in the $PATH, I've also tried setting it to it's absolute path.
Then, when I run cargo build, cargo test, or cargo clippy, I always see the unused config key in build.rustc_wrapper warning.

It should be rustc-wrapper with a dash, not an underscore.

It should be rustc-wrapper with a dash, not an underscore.

@ehuss You're right! Thanks.


Verry high video latency

Hi Alexeyvasilyev,
Currently I am working on a project where I need a low latency (less than 200ms) video connection to a IP camera so I thought of using this library because it sayed that it can do that. However when I use the rtspsurfaceview with the kotlin code below it like in the example in the readme I get a latency of roughly 2 seconds. Am I doing something wrong or are there more settings that I can do to get a lower latency?
Kind regards,

@MrGaintsquirrel any luck with it? I'm looking at the same issue.

@doron2402 no unfortunately not. I did confirm that changing the android device to a more modern one doesn't fix the issue. at some moment i got the latency down to 500ms but that was using vlclib.

Latency can be caused by hardware decoder and can be Android device specific.

Try to use another Android device model.
Try to use software decoder instead. In VideoDecodeThread.kt and change to var decoder = try {  createVideoDecoderAndStart(DecoderType.HARDWARE) ...


SW-1350 Migrate to accession_collectors table 2/4

This is step 2 of a sequence of changes to move the collector names from
accessions.primary_collector_name and accession_secondary_collectors to a
new accession_collectors table.
In this step, we backfill accession_collectors from the existing data and
update the code to read from it instead of from the old locations. We continue
to write both locations so there isn't data inconsistency while this is in the
middle of being deployed and there are still requests being handled by the
previous code version.
Step 3 will stop writing to the old column and table, and step 4 will drop them.

Current dependencies on/for this PR:

main

PR #534

PR #535   👈

PR #536

PR #537

PR #538

This comment was auto-generated by Graphite.


[BUG] - Cardano Block producer Uptime never exceeds 48 hours

Internal/External
External
Area
Other
Summary
The block producer uptime resets every 18-48 hours. Could be the node restarting or the server crashing. Block producer has 16GB of RAM. Have seen this behavior ever since I run the stake pool. Cardano relay nodes do not show this problem.
System info (please complete the following information):
Ubuntu 20.04.3 LTS
Cardano node version: 1.32.1

Check the logs of the node. It will display useful information that will help you figure out why your node is crashing. Without a clear error message or triggers for the crash, a bug report on GitHub will not receive too much attention. The best place to discuss this issue is the Cardano Forum: https://forum.cardano.org/c/staking-delegation/operators-talk/119.


Hello

I won't your help

This is the bug tracker, I think you want the Blockly Games support group.
https://groups.google.com/forum/#!forum/blockly-games


Error When Creating an ERC20 Token

I've been going at it for hours trying to create my token, but everytime I click "create" on Remix, it says:
"Invalid JSON RPC response: {"id":11,"jsonrpc":"2.0","error":{"code":-32603}}".
I've done this before and it worked. I'm getting really annoyed! I hate using Truffle as well, so I try to use this.
I need all the help I can get. Thanks!

Invalid JSON RPC response: {"id":36,"jsonrpc":"2.0","error":{"code":-32603}}

no solution for me i try a lot time different network and pc


Closes #2327: update adlb template

Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.
Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the main branch until you have checked off each task.

[ ] Place Closes #<insert_issue_number> into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
[ ] Code is formatted according to the tidyverse style guide. Run styler::style_file() to style R and Rmd files
[ ] Updated relevant unit tests or have written new unit tests, which should consider realistic data scenarios and edge cases, e.g. empty datasets, errors, boundary cases etc. - See Unit Test Guide
[ ] If you removed/replaced any function and/or function parameters, did you fully follow the deprecation guidance?
[ ] Review the Cheat Sheet. Make any required updates to it by editing the file inst/cheatsheet/admiral_cheatsheet.pptx and re-upload a PDF version of it to the same folder.
[ ] Update to all relevant roxygen headers and examples, including keywords and families. Refer to the categorization of functions to tag appropriate keyword/family.
[ ] Run devtools::document() so all .Rd files in the man folder and the NAMESPACE file in the project root are updated appropriately
[ ] Address any updates needed for vignettes and/or templates
[ ] Update NEWS.md under the header # admiral (development version) if the changes pertain to a user-facing function (i.e. it has an @export tag) or documentation aimed at users (rather than developers)
[ ] Build admiral site pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.
[ ] Address or fix all lintr warnings and errors - lintr::lint_package()
[ ] Run R CMD check locally and address all errors and warnings - devtools::check()
[ ] Link the issue in the Development Section on the right hand side.
[ ] Address all merge conflicts and resolve appropriately
[ ] Pat yourself on the back for a job well done! Much love to your accomplishment!

@kaz462 could we get a quick news blurb on this tiny update.  Might be handy for us later on when trying to track down why this was updated.

@kaz462 I don't think this fixes the initial issue. The PARAM for PARAMCD = "BASO" defined on line 41 is ""Basophils (10^9/L)" which is different to the derived PARAMCD = "BASO" for PARAM on line 133 "Basophils Abs (10^9/L)". I think if you just updated PARAM on line 41 it will fix it. Likewise, line 60 and 146 for PARAMCD ="LYMPH" and how PARAM is defined.


Do a POC on serverless (lambda and cloudfare) with Go

Create a POC on serverless.

Going through docs of Go, will try completing this tomorrow.

This is completed


Insert full path to service command, add hhvm restart minute

This ensures that HHVM is restarted just once and not every minute between 2 and 3am. Also provides for full path to the service command.

Well that was a terrible bug. Thanks!


Fix the npe issue for old version of gray release rules

What's the purpose of this PR
Fix the npe issue for old version of gray release rules, e.g. [{"clientAppId":"appidA","clientIpList":["<IP_ADDRESS>"]}].
Which issue(s) this PR fixes:
Fixes #4380
Brief changelog

add default constructor for GrayReleaseRuleItemDTO so that clientIpList and clientLabelList will be initialized to empty set.

Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Read the Contributing Guide before making this pull request.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit tests to verify the code.
[x] Run mvn clean test to make sure this pull request doesn't break anything.
[x] Update the CHANGES log.

Codecov Report

Merging #4382 (9a282d3) into master (f929541) will decrease coverage by 0.00%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master    #4382      +/-   ##
============================================
- Coverage     53.19%   53.19%   -0.01%
  Complexity     2674     2674
============================================
  Files           489      489
  Lines         15275    15277       +2
  Branches       1580     1580
============================================
+ Hits           8125     8126       +1
- Misses         6595     6600       +5
+ Partials        555      551       -4

Impacted Files
Coverage Δ

...work/apollo/common/dto/GrayReleaseRuleItemDTO.java
0.00% <0.00%> (ø)

...framework/apollo/openapi/entity/ConsumerAudit.java
42.42% <0.00%> (-6.07%)
:arrow_down:

.../framework/apollo/spring/property/SpringValue.java
89.47% <0.00%> (+1.75%)
:arrow_up:

...rk/apollo/spring/property/SpringValueRegistry.java
89.18% <0.00%> (+5.40%)
:arrow_up:

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 f929541...9a282d3. Read the comment docs.


feat: fetch api

Description
This adds the payload and client methods for the new irn_fetchMessages and irn_batchFetchMessages RPC. See https://github.com/WalletConnect/walletconnect-docs/pull/459 for specs.
Note: The fetch_stream() API is actually covered with tests in the relay.
How Has This Been Tested?
Manually + relay integration tests.
Due Diligence

[ ] Breaking change
[ ] Requires a documentation update
[ ] Requires a e2e/integration test update

@farazdagi Yeah, I'm squash-merging. We should probably enforce it on the repo level.


CLOUD-45463 create default views

@mhmxs

Jenkins build finished, all tests passed.
Refer to this link for build results: http://ci.sequenceiq.com/job/ambari-rest-client-pull-request/115/

Jenkins build finished, all tests passed.
Refer to this link for build results: http://ci.sequenceiq.com/job/ambari-rest-client-pull-request/116/

Jenkins build finished, all tests passed.
Refer to this link for build results: http://ci.sequenceiq.com/job/ambari-rest-client-pull-request/117/


Uncaught Error: Not supported type to render on

Hello,I have encountered such problem like following.
https://jsfiddle.net/hb9nr62q/1/
I dont't know where is wrong,plz help me,thanks!

https://jsfiddle.net/hb9nr62q/263/   this's correct url

@lst94 target element should be svg or canvas, but not a div.

I have solve it,but it's not the reason, still thanks to you!


Crash with intrinsic measurements

I'm assuming inside the chart library you use Subcompose? Is there a recommended way to use the charts inside of a widget that grows to match its parent? (Flow layouts, lists, etc).
Using it inside a flow layout produces the following:
java.lang.IllegalStateException: Asking for intrinsic measurements of SubcomposeLayout layouts is not supported. This includes components that are built on top of SubcomposeLayout, such as lazy lists, BoxWithConstraints, TabRow, etc

Yes, they use SubcomposeLayout. This is a limitation in Compose. In the case of PieChart, it looks possible to use Layout instead of SubcomposeLayout, but for the other chart types, it won't be so easy. One workaround might be to put the chart in a Box and set it to a fixed size with a Modifier. But fixing the size of things comes with its own issues.