"bower install" failed when extracting bower-angular-cookie

<EMAIL_ADDRESS>install /Users/jianwu/angularjs/gitrepos/angular-material-dashboard-1
bower install

bower angular-animate#~1.3.4    cached git://github.com/angular/bower-angular-animate.git#1.3.8
bower angular-animate#~1.3.4  validate 1.3.8 against git://github.com/angular/bower-angular-animate.git#~1.3.4
bower angular-cookies#~1.3.4    cached git://github.com/angular/bower-angular-cookies.git#1.3.8
bower angular-cookies#~1.3.4  validate 1.3.8 against git://github.com/angular/bower-angular-cookies.git#~1.3.4
bower angular-sanitize#~1.3.4   cached git://github.com/angular/bower-angular-sanitize.git#1.3.8
bower angular-sanitize#~1.3.4 validate 1.3.8 against git://github.com/angular/bower-angular-sanitize.git#~1.3.4
bower jquery#~2.1.1             cached git://github.com/jquery/jquery.git#2.1.4
bower jquery#~2.1.1           validate 2.1.4 against git://github.com/jquery/jquery.git#~2.1.1
bower angular-touch#~1.3.4      cached git://github.com/angular/bower-angular-touch.git#1.3.8
bower angular-touch#~1.3.4    validate 1.3.8 against git://github.com/angular/bower-angular-touch.git#~1.3.4
bower angular#1.3.15            cached git://github.com/angular/bower-angular.git#1.3.15
bower angular#1.3.15          validate 1.3.15 against git://github.com/angular/bower-angular.git#1.3.15
bower angular-ui-router#~0.2.13 cached git://github.com/angular-ui/ui-router.git#0.2.15
bower angular-ui-router#~0.2.13         validate 0.2.15 against git://github.com/angular-ui/ui-router.git#~0.2.13
bower angular-material#~0.10.0            cached git://github.com/angular/bower-material.git#0.10.0
bower angular-material#~0.10.0          validate 0.10.0 against git://github.com/angular/bower-material.git#~0.10.0
bower angular-mocks#~1.3.4                cached git://github.com/angular/bower-angular-mocks.git#1.3.17
bower angular-mocks#~1.3.4              validate 1.3.17 against git://github.com/angular/bower-angular-mocks.git#~1.3.4
bower angular-nvd3#1.0.0-rc.2             cached git://github.com/krispo/angular-nvd3.git#1.0.0-rc.2
bower angular-nvd3#1.0.0-rc.2           validate 1.0.0-rc.2 against git://github.com/krispo/angular-nvd3.git#1.0.0-rc.2
bower angular-sanitize#~1.3.4                new version for git://github.com/angular/bower-angular-sanitize.git#~1.3.4
bower angular-sanitize#~1.3.4            resolve git://github.com/angular/bower-angular-sanitize.git#~1.3.4
bower angular-touch#~1.3.4                   new version for git://github.com/angular/bower-angular-touch.git#~1.3.4
bower angular-touch#~1.3.4               resolve git://github.com/angular/bower-angular-touch.git#~1.3.4
bower angular-animate#~1.3.4                 new version for git://github.com/angular/bower-angular-animate.git#~1.3.4
bower angular-animate#~1.3.4             resolve git://github.com/angular/bower-angular-animate.git#~1.3.4
bower angular-cookies#~1.3.4                 new version for git://github.com/angular/bower-angular-cookies.git#~1.3.4
bower angular-cookies#~1.3.4             resolve git://github.com/angular/bower-angular-cookies.git#~1.3.4
bower angular-sanitize#~1.3.4           download https://github.com/angular/bower-angular-sanitize/archive/v1.3.17.tar.gz
bower angular-touch#~1.3.4              download https://github.com/angular/bower-angular-touch/archive/v1.3.17.tar.gz
bower angular-animate#~1.3.4            download https://github.com/angular/bower-angular-animate/archive/v1.3.17.tar.gz
bower angular-cookies#~1.3.4            download https://github.com/angular/bower-angular-cookies/archive/v1.3.17.tar.gz
bower angular-animate#^1.3.0 || >1.4.0-beta.0           cached git://github.com/angular/bower-angular-animate.git#1.3.8
bower angular-animate#^1.3.0 || >1.4.0-beta.0         validate 1.3.8 against git://github.com/angular/bower-angular-animate.git#^1.3.0 || >1.4.0-beta.0
bower angular-animate#^1.3.0 || >1.4.0-beta.0              new version for git://github.com/angular/bower-angular-animate.git#^1.3.0 || >1.4.0-beta.0
bower angular-animate#^1.3.0 || >1.4.0-beta.0          resolve git://github.com/angular/bower-angular-animate.git#^1.3.0 || >1.4.0-beta.0
bower nvd3#^1.7.1                                   not-cached git://github.com/novus/nvd3.git#^1.7.1
bower nvd3#^1.7.1                                      resolve git://github.com/novus/nvd3.git#^1.7.1
bower d3#^3.3.13                                        cached git://github.com/mbostock/d3.git#3.3.13
bower d3#^3.3.13                                      validate 3.3.13 against git://github.com/mbostock/d3.git#^3.3.13
bower angular-animate#^1.3.0 || >1.4.0-beta.0         download https://github.com/angular/bower-angular-animate/archive/v1.4.3.tar.gz
bower angular#1.3.17                                    cached git://github.com/angular/bower-angular.git#1.3.17
bower angular#1.3.17                                  validate 1.3.17 against git://github.com/angular/bower-angular.git#1.3.17
bower angular-aria#^1.3.15 || >1.4.0-beta.0             cached git://github.com/angular/bower-angular-aria.git#1.4.3
bower angular-aria#^1.3.15 || >1.4.0-beta.0           validate 1.4.3 against git://github.com/angular/bower-angular-aria.git#^1.3.15 || >1.4.0-beta.0
bower nvd3#^1.7.1                                     download https://github.com/novus/nvd3/archive/v1.8.1.tar.gz
bower angular-cookies#~1.3.4                           extract archive.tar.gz
bower angular-touch#~1.3.4                             extract archive.tar.gz
bower angular-sanitize#~1.3.4                          extract archive.tar.gz
bower d3#^3.3.13                                           new version for git://github.com/mbostock/d3.git#^3.3.13
bower d3#^3.3.13                                       resolve git://github.com/mbostock/d3.git#^3.3.13
bower d3#^3.3.13                                      download https://github.com/mbostock/d3/archive/v3.5.6.tar.gz
bower angular-animate#~1.3.4                           extract archive.tar.gz
bower angular-animate#^1.3.0 || >1.4.0-beta.0          extract archive.tar.gz
bower nvd3#^1.7.1                                      extract archive.tar.gz
bower d3#^3.3.13                                       extract archive.tar.gz
bower angular-cookies#~1.3.4                            EACCES EACCES, rename '/var/folders/z7/zt2wlkbj59z3k0vxs3f9182r0000gn/T/jianwu/bower/angular-cookies-5547-2SR0eD'
Stack trace:
Error: EACCES, rename '/var/folders/z7/zt2wlkbj59z3k0vxs3f9182r0000gn/T/jianwu/bower/angular-cookies-5547-2SR0eD'
Console trace:
Error
at StandardRenderer.error (/usr/local/lib/node_modules/bower/lib/renderers/StandardRenderer.js:82:37)
at Logger. (/usr/local/lib/node_modules/bower/bin/bower:110:22)
at Logger.EventEmitter.emit (events.js:95:17)
at Logger.emit (/usr/local/lib/node_modules/bower/node_modules/bower-logger/lib/Logger.js:29:39)
at /usr/local/lib/node_modules/bower/lib/commands/index.js:45:20
at _rejected (/usr/local/lib/node_modules/bower/node_modules/q/q.js:844:24)
at /usr/local/lib/node_modules/bower/node_modules/q/q.js:870:30
at Promise.when (/usr/local/lib/node_modules/bower/node_modules/q/q.js:1122:31)
at Promise.promise.promiseDispatch (/usr/local/lib/node_modules/bower/node_modules/q/q.js:788:41)
at /usr/local/lib/node_modules/bower/node_modules/q/q.js:604:44
System info:
Bower version: 1.4.1
Node version: 0.10.28
OS: Darwin 14.0.0 x64
npm ERR! Darwin 14.0.0
npm ERR! argv "node" "/usr/local/bin/npm" "install"
npm ERR! node v0.10.28
npm ERR! npm  v2.13.4
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>install: bower install
npm ERR! Exit status 1

@jianwu-github seems like a problem with your environment/setup.
Just tried to do the same on Windows - everything worked well
@micrum ideas?

@jianwu-github installation failed due to permissions problem on your machine.
Anyway, you don't need to call 'bower install' comand, as this command added as post-script to 'npm install'.
To install dependencies just call 'npm install'

I was building it on Mac OS X, and "bower install" was called from "npm install", I just copied log output from "bower install" to the point of failure as the full log would be too long

Would it be possible to create a "distributed" or "released" edition including all the dependencies?
I would argue that either "bower" or "npm" is not robust build-tool if you compare with ant, maven, and gradle and it is hard for new people to debug once these tools failed in certain environment.

@jianwu-github maybe you want to try the same command with sudo ?

@jianwu-github please have a look at similar problem on http://stackoverflow.com/questions/22257726/eacces-error-with-bower-install

@okendoken I tried and bower gave me warning saying I should not use sudo to do "bower install" as it is a local install, which is different from "npm" install globally.
@micum Thanks for the info! I'll take a look


Use the xapi-datamodel ocamlfind package rather than path/to/cmxa

Signed-off-by: Jon Ludlam<EMAIL_ADDRESS>

Looks ok, merging.


Support table migration with autoindexes

Not sure this is the correct solution but it seems that autoindexes are always derived from the CREATE TABLE statement/constraints and should not be migrated by manually.

I agree with your changes, thanks!
The failures seem to come from the analysis server suddenly complaining about generated files, so I'll merge and take a look at that later.


Parameter  input_base_frame not working: base -> camera transform not taken into account?

Hi, first of all many thanks for sharing this great repository! Unfortunately I am having some issues obtaining odometry messages that account for the transformation between the robot and camera coordinate frames.
I am currently working with a ground robot and trying to track its position using a Realsense camera positioned on top of the robot, looking slightly down as so:

From the documentation, I seem to understand that your implementation is designed to allow tracking successive poses of the robot (i.e. frame base_link), despite computing these poses in the camera frame (i.e. frame front_camera_link). Namely, the Visual Odometry node parameter input_base_frame seems to be responsible for this:

input_base_frame: Name of the frame (baselink) to calculate transformation between the baselink and the left camera. Default is empty, which means the value of the base_frame will be used. If input_base_frame and base_frame are both empty, the left camera is assumed to be in the robot's center.

However, by launching the node with 'input_base_frame': 'base_link' as follows:
    visual_slam_node = ComposableNode(
        name='visual_slam_node',
        namespace='front_camera',
        package='isaac_ros_visual_slam',
        plugin='isaac_ros::visual_slam::VisualSlamNode',
        parameters=[{
                    'enable_rectified_pose': True,
                    'denoise_input_images': False,
                    'rectified_images': True,
                    'enable_debug_mode': False,
                    'debug_dump_path': '/tmp/elbrus',
                    'enable_slam_visualization': True,
                    'enable_landmarks_view': True,
                    'enable_observations_view': True,
                    'publish_tf': False,
                    'map_frame': 'map',
                    'odom_frame': 'odom',
                    'base_frame': 'base_link',
                    'input_base_frame': 'base_link',
                    'input_left_camera_frame': 'front_camera_infra1_frame',
                    'input_right_camera_frame': 'front_camera_infra2_frame',
                    }],
        remappings=[('stereo_camera/left/image', 'infra1/image_rect_raw'),
                    ('stereo_camera/left/camera_info', 'infra1/camera_info'),
                    ('stereo_camera/right/image', 'infra2/image_rect_raw'),
                    ('stereo_camera/right/camera_info', 'infra2/camera_info')]
    )

the camera position with respect to the robot frame does not seem to be taken into account. As a matter of fact, unless I am mistaken it seems that the ROS parameter input_base_frame is not used at all in the source code.
Here is an example where I start the VO tracking, and move the hand-held camera straight forward (positive X direction in the front_camera_link frame):

Overlooking the jitter caused by my hand motion, I would expect the odometry arrows to be directed "into to ground" / co-linear to the front_camera_frame's X axis. Instead, the arrows seem to be directed along the X axis of the base_link frame i.e. the VO node considers the camera to be position at the robot's center?
Have I misunderstood the usage of the node's parameters or am I overlooking something? How can I track the motion of the robot instead of the camera's? Any help would be greatly appreciate! Thanks in advance.

Isaac ROS Visual SLAM will report odometry in the base_link frame. If you want to track the camera pose, leave both input_base_frame and base_frame are both empty and the left camera will be assumed to be the robot's "center."

I am having a problem and findings similar to what @GuillaumeLaine described.
Note: I am using version 0.9.3-ea3 because we are running ROS2 Galactic (we have not yet migrated to Humble). If this issue has been fixed in a later version (which I am currently unable to test without creating a separate test setup), I would greatly appreciate any instructions on how to backport the fix into a galactic-compatible version.
Here's my situation: We have a robot with 4 Realsense cameras (front, back and both sides), all looking in a horizontal direction. The current goal is to run the Visual Slam nodes for the two side cameras and get the odometries all reported for the movement of the base_link frame. Here are the settings that I'm using for the visual slam nodes:
visual_slam_node = ComposableNode(
    name=f"visual_slam_node",
    namespace=f"camera_{camera_count}",
    package="isaac_ros_visual_slam",
    plugin="isaac_ros::visual_slam::VisualSlamNode",
    extra_arguments=[{"use_intra_process_comms": True}],
    parameters=[
        {
            "enable_rectified_pose": True,
            "denoise_input_images": False,
            "rectified_images": True,
            "enable_debug_mode": False,
            "debug_dump_path": f"/tmp/elbrus_{camera_count}",
            "enable_slam_visualization": True,
            "enable_landmarks_view": True,
            "enable_observations_view": True,
            "publish_tf": False,
            "map_frame": "map",
            "odom_frame": "odom",
            "base_frame": "base_link",
            "input_base_frame": "base_link",
            "input_left_camera_frame": f"camera_{camera_count}_infra1_frame",
            "input_right_camera_frame": f"camera_{camera_count}_infra2_frame",
        }
    ],
    remappings=[
        ("stereo_camera/left/image", "infra1/image_rect_raw"),
        ("stereo_camera/left/camera_info", "infra1/camera_info"),
        ("stereo_camera/right/image", "infra2/image_rect_raw"),
        ("stereo_camera/right/camera_info", "infra2/camera_info"),
    ],
)

In my first setup tests, I am driving the robot straight forward for a distance of about 3 meters (within accuracy of about 5-10 cm). The expected result is that both visual odometries would report about a 3m movement forward (in the positive x-direction of the base_link frame). Instead, what I'm seeing is this, white being wheel-odometry for reference - it is fairly accurate, green being odometry from the left camera and red from the right camera (it also seems that the visual slam nodes report distances of roughly half of the true one, but that I expect to be a separate issue that might also be due to our camera settings etc.):

I have also ran the test with several other frame configurations for the two base frames, such as
"base_frame": "",
"input_base_frame": "",

"base_frame": f"camera_{camera_count}_link",
"input_base_frame": "",

and
"base_frame": "base_link",
"input_base_frame": f"camera_{camera_count}_link",

with them all giving the same output for odometry poses. Thus, it seems clear to me that the pose in the odometry output of the visual slam node is not correctly transformed to reflect the movement of the base_link frame but rather always represents the movement of (likely) the input_left_camera_frame.
I did find out that the twist part of the odometry does seem to be correctly oriented and that the frame settings do affect to it. However, it does seem (based on some other tests) that there is something wrong in the translation part of the twist (when driving in a curve, the camera towards the turn gives shorter distance than the one on the outside of the curve), but unfortunately I do not have an easily visualizable dataset to clearly show this.
I also tried running the node for the front camera, and for that the odometry pose path looks more reasonable, with the exception of the length of path (yellow poses are from the front camera):

@GuillaumeLaine Did you find a solution to your problem? I am considering a temporary workaround by writing a separate wrapper or node etc. to just do the necessary transformations "manually" before using the odometry, but would appreciate any alternatives if you have found a fix.

@GuillaumeLaine and @tanelikor, I have looked into your launch files, and it looks like you have "publish_tf": False. Could you try with "publish_tf": True and keep the input_base_frame: "base_link" ?

@swapnesh-wani-nvidia Thank you for the reply and suggestion. I tried it out, even though I was quite convinced that setting "publish_tf": True would not solve the issue. More thoughts on this later, first the results.
The launch config of the visual slam nodes now looks like this:
visual_slam_node = ComposableNode(
    name=f"visual_slam_node",
    namespace=f"camera_{camera_count}",
    package="isaac_ros_visual_slam",
    plugin="isaac_ros::visual_slam::VisualSlamNode",
    extra_arguments=[{"use_intra_process_comms": True}],
    parameters=[
        {
            "enable_rectified_pose": True,
            "denoise_input_images": False,
            "rectified_images": True,
            "enable_debug_mode": False,
            "debug_dump_path": f"/tmp/elbrus_{camera_count}",
            "enable_slam_visualization": True,
            "enable_landmarks_view": True,
            "enable_observations_view": True,
            "publish_tf": True,
            "map_frame": "map",
            "odom_frame": "odom",
            "base_frame": "base_link",
            "input_base_frame": "base_link",
            "input_left_camera_frame": f"camera_{camera_count}_infra1_frame",
            "input_right_camera_frame": f"camera_{camera_count}_infra2_frame",
        }
    ],
    remappings=[
        ("stereo_camera/left/image", "infra1/image_rect_raw"),
        ("stereo_camera/left/camera_info", "infra1/camera_info"),
        ("stereo_camera/right/image", "infra2/image_rect_raw"),
        ("stereo_camera/right/camera_info", "infra2/camera_info"),
    ],
)

The result looks like this. (As a side note, the speed/distance mismatch was indeed due to bad camera configs but that I have since fixed).

Here's also a video about the drive.
https://user-images.githubusercontent.com/81684354/191219915-4693273a-7a5d-4b4f-8ed3-7c86d3b0e6a9.mp4
I then also tried this with "input_base_frame": f"camera_{camera_count}_link" with the following result.

https://user-images.githubusercontent.com/81684354/191220138-f6632384-fb60-4f70-875a-fc8cbe0f0eb5.mp4
If I understand correctly (and please correct me if I'm mistaken), setting "publish_tf": True simply makes the node publish the transform between odom and base_link frames, but doesn't affect to any other operations (transforms to the odometry data etc) done by the visual slam nodes. In my application, I definitely do not want to publish tfs from the visual slam nodes: Since I'm running two visual slam nodes and a node that publishes wheel-based odometry, publishing tf's from multiple nodes will create competing transforms and potentially cause oscillation (even if the odometries are transformed correctly), which can also be seen happening on the videos above. The actual end goal for me is to fuse all the odom sources and publish tfs based on the fused odometry.

@Parosi As a temporary solution until a proper fix is made, I ended up just writing a separate node that

looks up the transform between the camera and robot base frames,
transforms the odometry data (including covariances) given by the visual slam nodes to describe the movement of the robot frame instead of that of the cameras, and
relays the new odometry data to a separate topic that we then use elsewhere.

Its not an ideal solution as it does add some extra overhead, but so far it has been good enough for our purposes.

@Parosi As a temporary solution until a proper fix is made, I ended up just writing a separate node that
* looks up the transform between the camera and robot base frames,

* transforms the odometry data (including covariances) given by the visual slam nodes to describe the movement of the robot frame instead of that of the cameras, and

* relays the new odometry data to a separate topic that we then use elsewhere.

Its not an ideal solution as it does add some extra overhead, but so far it has been good enough for our purposes.

Thanks @tanelikor , I was also thinking something like that. Did you publish the code for the additional node somewhere? This is a big problem and having a working node to fix it would be very appreciated!

@Parosi We have not published it because it is meant as a short-time temporary fix/workaround. The full version is also only in Python for the same reason (has been good enough for now).
However, we could make a public version of it as there seems to be a need for it. This will require a small amount of work to remove dependencies to our internal utilities, but I think I could get it done next week or so. So if there is interest in it, I'll make it happen. Could also then maybe post a link to it here if that is allowed, or just let you know about it otherwise.

@tanelikor Yes I think it will be very useful and it can help many developers interested in this package!
I'm not sure, but I think it is possible to link here the repo with the fix.
Thank you very much!

@Parosi Alright, I'll let you know when the public version of the node is ready.

@Parosi The workaround is now published. I didn't find any mention of not being allowed to link different repos here, so you can find it at https://github.com/Karelics/odom_transformer.

@tanelikor I will test it tomorrow or next week.
Thank you very much!

I have same problem
my config is
'base_frame': 'base_link',
'input_base_frame': 'camera_link'
it is not nature when rotation.

Hi, I am having the same problem with Isaac 2.0. Has there been any news about this issue?

Hi @pimientofrito and @tuch77731 (apologies, I had totally missed your comment).
On our side, it seems like this was fixed at some point in the Humble version since migrating to that a couple months ago fixed the issue for us and we haven't needed the self-crafted transforming since. I'm not sure why there hasn't been any reports by the maintainers about that in this issue. I had plans to take some recording of this and post it here, but haven't found the time to do that thus far.
If you use a version where this has been fixed, then you should likely set the frames to be
"base_frame": "base_link",
"input_base_frame": "base_link"  # or ""

If you use a version where this has not been fixed (I do not know which ones those are exactly and it seems really difficult to decipher that from the release / update notes of the package) and wish to use the odom_transformer package that I linked above, then you should probably set both base_frame and input_base_frame to the value of the left camera frame. This could be "camera_link" or "camera_infra1_frame" etc, depending on which cameras you are using.
I hope this helps.

Thanks for your quick response @tanelikor! I'm using a corrected version, if I'm not mistaken.  In fact, I just became aware that the pose is indeed transforming to base_frame, but I noticed it in one particular case.
I'm testing visual odometry with real drone flights (from before takeoff to landing) and a setup of two pairs of cameras, one looking forward and one looking back with a -45 degree pitch turn (looking slightly down), my problem is with this one. If I launch the odometry with the camera looking backwards, the trajectory comes out rotated -45 degrees, this is why I thought it was not published in base_link.  But if I launch it once the drone is flying and there is no movement in altitude, the estimated trajectory is what I expected.
I'm not sure if I should open another issue for this, but is this a normal behavior? is it possible that the takeoff is affecting the estimation?

@pimientofrito Sounds odd to me. If you have the frames set correctly and the necessary transforms are available, the transposing should work regardless of when you launch the node.
One point that does come to mind is the following: In our application, the cameras can sometimes have a highly obstructed view, which I have found to routinely cause the position estimate of the vslam node to go crazy (makes sense if the camera can't see anything). This does get fixed as soon as the visibility returns though, and I haven't seen it to cause problems with transforming to the base frame. Also, this doesn't matter much for us as we only use the velocity part of the odometry in sensor fusion with other sources that are not affected by visibility.
So, if the camera is pointing to the ground and close to it and you rely on the pose information given by vslam, you might want to investigate the effect of the camera not seeing properly at launch. But if the issue is of the type that the base frame (drone) is reported to move backwards (in its own frame) when it is in reality moving forward, then I cannot quickly think of a sensible reason for this. Also, if it works fine with the front camera but not with the rear one, then it sounds like something that could relate to this issue (or at least it shows similar symptoms).
If you cannot find the reason for the problems, its probably a good idea to share some screenshots etc about how the problem looks like, either in this issue or in a separate one. At least I find it difficult to be exactly sure what the issue looks like based on just a text form description. :slightly_smiling_face:

@tanelikor Great, thank you for your feedback. In the video you will be able to see the behavior of the odometry. This should give a clearer idea of the problem I'm encountering. First, I launch both odometries, and at some point I restart the one with the camera pointing backwards (i.e., kill the node and relaunch it).
The frames I'm using are:
                    'map_frame': 'map',
                    'odom_frame': 'odom',
                    "base_frame": "base_link",
                    "input_base_frame": "base_link",
                    'input_imu_frame': 'camera_rs_back_gyro_optical_frame',
                    'input_left_camera_frame': 'camera_rs_back_infra1_frame',
                    # 'input_right_camera_frame': '',

                    'map_frame': 'map',
                    'odom_frame': 'odom',
                    "base_frame": "base_link",
                    "input_base_frame": "base_link",
                    'input_imu_frame': 'camera_rs_front_gyro_optical_frame',
                    'input_left_camera_frame': 'camera_rs_front_infra1_frame',
                    # 'input_right_camera_frame': '',

TFs are being published by the RealSense node, and the link with base is like this:
    base2frontsensor = Node(
        package = "tf2_ros",
        executable = "static_transform_publisher",
        arguments = ["0.18", "0.005", "-0.035",
                    "0", "0", "0", "1",
                    "base_link", "camera_rs_front_link"])

    base2backsensor = Node(
        package = "tf2_ros",
        executable = "static_transform_publisher",
        arguments = ["-0.18", "-0.005", "-0.035",
                    "-0.3826834", "0", "0.9238795", "0",
                    "base_link", "camera_rs_back_link"]
    )

blue: front camera
red:  back camera
https://github.com/NVIDIA-ISAAC-ROS/isaac_ros_visual_slam/assets/56796302/8e793730-9906-458e-9e80-dc9114b86d18
It is true that it starts very close to the ground, so I understand that this is a problem. Thank you again!

@pimientofrito Thanks for the video. To me this, looks like it is clearly an issue with the camera being blocked when the drone is on the ground. Observations that point to this:

The movement direction seems correct in both odometries: when the drone flies forward, the odom arrows progress forward (in the direction of the arrow) etc, so the velocity information looks correct. This suggests that the camera transforms are correctly accounted for.
Rviz displays large covariance for the pose estimate (the purple sphere for position and the yellow cones for orientation) at the beginning. This is likely from the rear camera not seeing properly (you might want to check in Rviz whether the large covariance is only from the rear camera or from both). Might be that the ground is closer than the minimum detection distance of the camera (check you camera specs for this) or close to it, or that the floor texture is not clear enough for vslam, combination of the two or something else.

Thus, it looks like the orientation of the rear vslam just gets messed up at the start when the camera doesn't see well.
The way to solve this depends on what you want to use the vslam for. If you want (combined) odometry from both cameras, I would suggest looking into some sensor fusion and utilizing only the velocity data at least from the worse camera. If you want them for slam, it might be better to just use the front camera.

@tanelikor I take note of your impressions. Thank you very much for your patience and advice :smile:

Hi @pimientofrito and @tuch77731 (apologies, I had totally missed your comment).
On our side, it seems like this was fixed at some point in the Humble version since migrating to that a couple months ago fixed the issue for us and we haven't needed the self-crafted transforming since. I'm not sure why there hasn't been any reports by the maintainers about that in this issue. I had plans to take some recording of this and post it here, but haven't found the time to do that thus far.
If you use a version where this has been fixed, then you should likely set the frames to be
"base_frame": "base_link",
"input_base_frame": "base_link"  # or ""

If you use a version where this has not been fixed (I do not know which ones those are exactly and it seems really difficult to decipher that from the release / update notes of the package) and wish to use the odom_transformer package that I linked above, then you should probably set both base_frame and input_base_frame to the value of the left camera frame. This could be "camera_link" or "camera_infra1_frame" etc, depending on which cameras you are using.
I hope this helps.

It's very helpful to me!
Thank you!

Thank you all for the active discussion. This is a long discussion. Could you folks try with the latest release of Isaac ROS.

@swapnesh-wani-nvidia Sorry for the late reply. I will try it out next week if I can spare the time.

Hi @swapnesh-wani-nvidia. It took me a bit longer than anticipated due to a very busy December, but I finally got to test this with version 2.1.0, and it seems to work as it should. So, as far as I'm concerned this issue can be closed.
I did find a different issue in that the new version does not work with intra-process communication, but I will create a separate issue about that.

I have been trying to solve a similar issue, it's not clear to me what the difference between "input_base_frame" and "left_camera_frame" since in the documentation both do the same thing(transform the base frame to the left_camera_frame). TF2 Names I'm assuming refer to the child.


Support nsm namespace for Azure, GKE and packet deployments

This should be a follow up of #770 and required for closing #754
The CI for Azure, GKE and packet deployments was failing with
Post <server-ip>:<port>api/v1/namespaces: stream error: stream ID 1; INTERNAL_ERROR

This might be an RBAC issue.
Fixing is important, as the infra deployment now operates in nsm-system namespace, which will fail to be created for those environments.
As a temporary solution NSM_NAMESPACE can be set empty of "default" for Azure and GKE.

I suggest we remove v0.1.0 label here.

@ivanayov we do not use default namespaces right now. I've not seed any issues like this in latest version.


Bad address index error at @implicit_new

Godot version
4.0.1
System information
Windows 10, RTX 2060, Vulkan
Issue description
I'm currently working on a game with a lot of class inheritance where each child class adds more instance variables on top of its parent. It seems that once the inheritance tree gets complex enough Godot starts throwing errors on variable declarations while instancing objects. Here is a screenshot of an error that occurs when a resource is loaded from a file:

This seems to happen somewhat randomly, sometimes it has no issue instancing an object and other times it throws an error (seems to only happen on the most complex objects/the ones with the deepest inheritance trees). Tool scripts and whether or not a variable is exported makes no difference.
Steps to reproduce
I think this error is caused by Godot not handling large projects with deep inheritance trees very well. I can't pinpoint exactly what causes it, but it seems to have something to do with the amount of variables/identifiers a class has.
Minimal reproduction project
I wasn't able to reproduce this in a test project when I copied all of my class code and deleted all functions. It seems to require a fairly complex codebase to reproduce, and for multiple reasons I don't want to post my entire game.

It's from here:
https://github.com/godotengine/godot/blob/dbf1a7277f70c63b2012e40d6850bc45e67fb35f/modules/gdscript/gdscript_vm.cpp#L633
Not sure what causes it though

Related: #74253

With more testing I think this error is caused by a indirect loops in class references. Seems like the error message could use some work or the parser could be improved to handle these kinds of loops.

Duplicate of https://github.com/godotengine/godot/issues/74253.


fix: move manifest.yaml tweaks to before updating pkged.go

Signed-off-by: Lance Ball<EMAIL_ADDRESS>

/approve
/lgtm


ARP enumeration code can fail if strings are not proper UTF-16

Brief description of your issue
New Features(upgrade,uninstall,list) can't work.

Steps to reproduce
add these into settings.json
"visual": {
        "progressBar": "accent"
    },
    "experimentalFeatures": {
        "uninstall": true,
        "list": true,
        "upgrade": true
    }

and then type winget upgrade Git to the cmd

Expected behavior
Git on my computer should be updated in the CMD.

Actual behavior
打开预定义源失败; 请向 winget 维护人员报告。
执行此命令时发生意外错误：
0x8007139f : �����Դ��״̬����ִ�������������ȷ״̬��

The above translation is
Failed to open predefined source; please report to Winget maintenance.

An unexpected error occurred while executing this command:

0x8007139f : �����Դ��״̬����ִ�������������ȷ״̬��

Environment
[winget --info]
Windows Package Manager v0.2.10191 Preview
Windows: Windows.Desktop v10.0.19042.804
Package: Microsoft.DesktopAppInstaller v1.11.10191.0

There are still some challenges with upgrade. What does the system show when you execute winget upgrade? Is git displayed in the list?

C:\Users\dell# winget upgrade

Failed to open predefined source; please report to Winget maintenance.

An unexpected error occurred while executing this command:

0x8007139f

Take a look at #764
I've put a possible work around in that issue.
Let me know what kind of results you see please.

C:\Users\dell# winget --info
Windows Package Manager v0.2.10191 Preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19042.804
Package: Microsoft.DesktopAppInstaller v1.11.10191.0

One of the log messages is as follow
[log]
2021-2-25 12:33:38.519 [CORE] WinGet, version [0.2.10191], activity [{B9AA13A2-99AE-4881-97B8-D57BF91A5BEC}]
2021-2-25 12:33:38.520 [CORE] OS: Windows.Desktop v10.0.19042.804
2021-2-25 12:33:38.520 [CORE] Command line Args: winget  --info
2021-2-25 12:33:38.520 [CORE] Package: Microsoft.DesktopAppInstaller v1.11.10191.0
2021-2-25 12:33:38.550 [CLI ] WinGet invoked with arguments: '--info'
2021-2-25 12:33:38.550 [CLI ] Leaf command to execute: root
2021-2-25 12:33:38.550 [CORE] Setting action: Get, Type: UserFile, Name: settings.json
2021-2-25 12:33:38.576 [CORE] Settings loaded from settings.json
2021-2-25 12:33:38.576 [CORE] Valid setting Field: .visual.progressBar Value: accent
2021-2-25 12:33:38.576 [CORE] Valid setting Field: .source.autoUpdateIntervalInMinutes Value: 3
2021-2-25 12:33:38.576 [CORE] Setting .experimentalFeatures.experimentalCmd not found. Using default
2021-2-25 12:33:38.576 [CORE] Setting .experimentalFeatures.experimentalArg not found. Using default
2021-2-25 12:33:38.576 [CORE] Setting .experimentalFeatures.experimentalMSStore not found. Using default
2021-2-25 12:33:38.576 [CORE] Valid setting Field: .experimentalFeatures.list Value: 1
2021-2-25 12:33:38.576 [CORE] Valid setting Field: .experimentalFeatures.upgrade Value: 1
2021-2-25 12:33:38.576 [CORE] Valid setting Field: experimentalFeatures.uninstall Value: 1
2021-2-25 12:33:38.576 [CLI ] Executing command: root
2021-2-25 12:33:38.632 [CLI ] Leaf command succeeded: root

The firewall is turned off and there is no VPN
C:\Users\dell# winget source update
正在更新所有源...
正在更新源: winget...
  ██████████████████████████████  100%
完成

Logs are as bellow
2021-2-25 12:36:32.723 [CORE] WinGet, version [0.2.10191], activity [{553515C4-F510-4125-A0EE-33968777A9C6}]
2021-2-25 12:36:32.724 [CORE] OS: Windows.Desktop v10.0.19042.804
2021-2-25 12:36:32.724 [CORE] Command line Args: winget  source update
2021-2-25 12:36:32.724 [CORE] Package: Microsoft.DesktopAppInstaller v1.11.10191.0
2021-2-25 12:36:32.756 [CLI ] WinGet invoked with arguments: 'source' 'update'
2021-2-25 12:36:32.756 [CLI ] Found subcommand: source
2021-2-25 12:36:32.756 [CLI ] Found subcommand: update
2021-2-25 12:36:32.756 [CLI ] Leaf command to execute: root:source:update
2021-2-25 12:36:32.756 [CORE] Setting action: Get, Type: UserFile, Name: settings.json
2021-2-25 12:36:32.783 [CORE] Settings loaded from settings.json
2021-2-25 12:36:32.783 [CORE] Valid setting Field: .visual.progressBar Value: accent
2021-2-25 12:36:32.783 [CORE] Valid setting Field: .source.autoUpdateIntervalInMinutes Value: 3
2021-2-25 12:36:32.783 [CORE] Setting .experimentalFeatures.experimentalCmd not found. Using default
2021-2-25 12:36:32.783 [CORE] Setting .experimentalFeatures.experimentalArg not found. Using default
2021-2-25 12:36:32.783 [CORE] Setting .experimentalFeatures.experimentalMSStore not found. Using default
2021-2-25 12:36:32.783 [CORE] Valid setting Field: .experimentalFeatures.list Value: 1
2021-2-25 12:36:32.783 [CORE] Valid setting Field: .experimentalFeatures.upgrade Value: 1
2021-2-25 12:36:32.783 [CORE] Valid setting Field: experimentalFeatures.uninstall Value: 1
2021-2-25 12:36:32.783 [CLI ] Executing command: update
2021-2-25 12:36:32.783 [CORE] Setting action: Get, Type: Secure, Name: user_sources
2021-2-25 12:36:32.785 [CORE] Setting action: Get, Type: Standard, Name: sources_metadata
2021-2-25 12:36:32.808 [CORE] Setting action: Get, Type: Secure, Name: user_sources
2021-2-25 12:36:32.809 [CORE] Setting action: Get, Type: Standard, Name: sources_metadata
2021-2-25 12:36:32.809 [REPO] Named source to be updated, found: winget
2021-2-25 12:36:32.823 [CORE] Examining extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2021-2-25 12:36:32.823 [CORE] Found matching extension.
2021-2-25 12:36:35.584 [CORE] Downloading to path: C:\Users\dell\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix
2021-2-25 12:36:35.586 [CORE] Started applying motw to C:\Users\dell\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix with zone: 3
2021-2-25 12:36:35.590 [CORE] Finished applying motw
2021-2-25 12:36:35.590 [CORE] Downloading from url: https://winget.azureedge.net/cache/source.msix
2021-2-25 12:36:37.034 [CORE] Download completed.
2021-2-25 12:36:37.035 [CORE] Starting AddPackage operation #0: file:///C:/Users/dell/AppData/Local/Packages/Microsoft.DesktopAppInstaller_8wekyb3d8bbwe/TempState/WinGet/Microsoft.Winget.Source_8wekyb3d8bbwe.msixSkipSmartScreen: 1
2021-2-25 12:36:37.038 [CORE] Begin waiting for deployment #0
2021-2-25 12:36:37.038 [CORE] Begin blocking for deployment #0
2021-2-25 12:36:38.581 [CORE] Successfully deployed #0
2021-2-25 12:36:38.581 [CORE] Setting action: Set, Type: Standard, Name: sources_metadata
2021-2-25 12:36:38.583 [CLI ] Leaf command succeeded: root:source:update

C:\Users\dell# ping winget.azureedge.net

正在 Ping cs9.wpc.v0cdn.net [<IP_ADDRESS>] 具有 32 字节的数据:
来自 <IP_ADDRESS> 的回复: 字节=32 时间=195ms TTL=51
来自 <IP_ADDRESS> 的回复: 字节=32 时间=100ms TTL=51
来自 <IP_ADDRESS> 的回复: 字节=32 时间=98ms TTL=51
来自 <IP_ADDRESS> 的回复: 字节=32 时间=99ms TTL=51

<IP_ADDRESS> 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 98ms，最长 = 195ms，平均 = 123ms

seems that there is no problem with my network

When I do this,it does'nt work

When I do winget upgrade Git it fail.
Logs are as below
2021-2-25 12:50:25.374 [CORE] WinGet, version [0.2.10191], activity [{AF58511C-B8BE-4DB1-9CB3-2A4429516F66}]
2021-2-25 12:50:25.375 [CORE] OS: Windows.Desktop v10.0.19042.804
2021-2-25 12:50:25.375 [CORE] Command line Args: winget  upgrade Git
2021-2-25 12:50:25.375 [CORE] Package: Microsoft.DesktopAppInstaller v1.11.10191.0
2021-2-25 12:50:25.406 [CLI ] WinGet invoked with arguments: 'upgrade' 'Git'
2021-2-25 12:50:25.406 [CORE] Setting action: Get, Type: UserFile, Name: settings.json
2021-2-25 12:50:25.432 [CORE] Settings loaded from settings.json
2021-2-25 12:50:25.432 [CORE] Valid setting Field: .visual.progressBar Value: accent
2021-2-25 12:50:25.432 [CORE] Valid setting Field: .source.autoUpdateIntervalInMinutes Value: 3
2021-2-25 12:50:25.434 [CORE] Setting .experimentalFeatures.experimentalCmd not found. Using default
2021-2-25 12:50:25.434 [CORE] Setting .experimentalFeatures.experimentalArg not found. Using default
2021-2-25 12:50:25.434 [CORE] Setting .experimentalFeatures.experimentalMSStore not found. Using default
2021-2-25 12:50:25.434 [CORE] Valid setting Field: .experimentalFeatures.list Value: 1
2021-2-25 12:50:25.434 [CORE] Valid setting Field: .experimentalFeatures.upgrade Value: 1
2021-2-25 12:50:25.434 [CORE] Valid setting Field: experimentalFeatures.uninstall Value: 1
2021-2-25 12:50:25.434 [CLI ] Found subcommand: upgrade
2021-2-25 12:50:25.434 [CLI ] Leaf command to execute: root:upgrade
2021-2-25 12:50:25.434 [CLI ] Executing command: upgrade
2021-2-25 12:50:25.435 [CORE] Setting action: Get, Type: Secure, Name: user_sources
2021-2-25 12:50:25.436 [CORE] Setting action: Get, Type: Standard, Name: sources_metadata
2021-2-25 12:50:25.436 [REPO] Default source requested, only 1 source available, using the only source: winget
2021-2-25 12:50:25.436 [CORE] Setting action: Get, Type: Secure, Name: user_sources
2021-2-25 12:50:25.437 [CORE] Setting action: Get, Type: Standard, Name: sources_metadata
2021-2-25 12:50:25.437 [REPO] Named source requested, found: winget
2021-2-25 12:50:25.437 [REPO] Source past auto update time [3 mins]; it has been at least 5 mins
2021-2-25 12:50:25.451 [CORE] Examining extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2021-2-25 12:50:25.452 [CORE] Found matching extension.
2021-2-25 12:50:28.222 [REPO] Remote source data was not newer than existing, no update needed
2021-2-25 12:50:28.229 [CORE] Setting action: Set, Type: Standard, Name: sources_metadata
2021-2-25 12:50:28.237 [CORE] Examining extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2021-2-25 12:50:28.237 [CORE] Found matching extension.
2021-2-25 12:50:28.273 [REPO] Opening SQLite Index for ImmutableRead at 'C:\Program Files\WindowsApps\Microsoft.Winget.Source_2<IP_ADDRESS>1_neutral__8wekyb3d8bbwe\Public\index.db'
2021-2-25 12:50:28.273 [SQL ] Opening SQLite connection: 'file:/C:/Program Files/WindowsApps/Microsoft.Winget.Source_2<IP_ADDRESS>1_neutral__8wekyb3d8bbwe/Public/index.db?immutable=1' [1, 40]
2021-2-25 12:50:28.274 [REPO] Opened SQLite Index with version [1.1], last write [2021-2-25 08:22:35.000]
2021-2-25 12:50:28.460 [REPO] Creating PredefinedInstalledSource with filter [None]
2021-2-25 12:50:28.460 [REPO] Creating new SQLite Index [4294967295.4294967295] at ':memory:'
2021-2-25 12:50:28.460 [SQL ] Opening SQLite connection: ':memory:' [6, 0]
2021-2-25 12:50:28.466 [REPO] Examining ARP entries for Machine | X64
2021-2-25 12:50:28.466 [REPO] Adding manifest for [7-Zip, 19.00] at relative path [7-Zip]
2021-2-25 12:50:28.466 [REPO] Did not find an Id { 7-Zip }
2021-2-25 12:50:28.468 [REPO] Adding manifest for [7F099398EDCBBC90F1BC80073B362E20B4011D64, 08/23/2013 8.0.0001.0302] at relative path [7F099398EDCBBC90F1BC80073B362E20B4011D64]
2021-2-25 12:50:28.469 [REPO] Did not find an Id { 7F099398EDCBBC90F1BC80073B362E20B4011D64 }
2021-2-25 12:50:28.470 [REPO] Adding manifest for [BC3D821C-7EFA-41F8-B1C2-8A55DDFE5A67_is1, <IP_ADDRESS>] at relative path [BC3D821C-7EFA-41F8-B1C2-8A55DDFE5A67_is1]
2021-2-25 12:50:28.470 [REPO] Did not find an Id { BC3D821C-7EFA-41F8-B1C2-8A55DDFE5A67_is1 }
2021-2-25 12:50:28.472 [REPO] Adding manifest for [BC3D821C-7EFA-41F8-B1C2-8A55DDFE5A90_is1, <IP_ADDRESS>] at relative path [BC3D821C-7EFA-41F8-B1C2-8A55DDFE5A90_is1]
2021-2-25 12:50:28.472 [REPO] Did not find an Id { BC3D821C-7EFA-41F8-B1C2-8A55DDFE5A90_is1 }
2021-2-25 12:50:28.474 [REPO] Adding manifest for [CCleaner, 5.68] at relative path [CCleaner]
2021-2-25 12:50:28.474 [REPO] Did not find an Id { CCleaner }
2021-2-25 12:50:28.475 [REPO] Adding manifest for [CPUID CPU-Z_is1, 1.93] at relative path [CPUID CPU-Z_is1]
2021-2-25 12:50:28.475 [REPO] Did not find an Id { CPUID CPU-Z_is1 }
2021-2-25 12:50:28.476 [REPO] Adding manifest for [Git_is1, 2.30.1] at relative path [Git_is1]
2021-2-25 12:50:28.476 [REPO] Did not find an Id { Git_is1 }
2021-2-25 12:50:28.478 [REPO] Adding manifest for [HomeStudent2019Retail - zh-cn, 16.0.13628.20448] at relative path [HomeStudent2019Retail - zh-cn]
2021-2-25 12:50:28.478 [REPO] Did not find an Id { HomeStudent2019Retail - zh-cn }
2021-2-25 12:50:28.479 [REPO] Adding manifest for [HuorongSysdiag, 5.0] at relative path [HuorongSysdiag]
2021-2-25 12:50:28.479 [REPO] Did not find an Id { HuorongSysdiag }
2021-2-25 12:50:28.481 [REPO] Adding manifest for [Maxon Cinema 4D S22, S22] at relative path [Maxon Cinema 4D S22]
2021-2-25 12:50:28.481 [REPO] Did not find an Id { Maxon Cinema 4D S22 }
2021-2-25 12:50:28.483 [REPO] Adding manifest for [PotPlayer64, 201209] at relative path [PotPlayer64]
2021-2-25 12:50:28.483 [REPO] Did not find an Id { PotPlayer64 }
2021-2-25 12:50:28.484 [REPO] Adding manifest for [Steam App 220200, Unknown] at relative path [Steam App 220200]
2021-2-25 12:50:28.485 [REPO] Did not find an Id { Steam App 220200 }
2021-2-25 12:50:28.487 [REPO] Adding manifest for [Steam App 246620, Unknown] at relative path [Steam App 246620]
2021-2-25 12:50:28.487 [REPO] Did not find an Id { Steam App 246620 }
2021-2-25 12:50:28.489 [REPO] Adding manifest for [Steam App 271590, Unknown] at relative path [Steam App 271590]
2021-2-25 12:50:28.489 [REPO] Did not find an Id { Steam App 271590 }
2021-2-25 12:50:28.491 [REPO] Adding manifest for [Steam App 322330, Unknown] at relative path [Steam App 322330]
2021-2-25 12:50:28.491 [REPO] Did not find an Id { Steam App 322330 }
2021-2-25 12:50:28.492 [REPO] Adding manifest for [Steam App 365450, Unknown] at relative path [Steam App 365450]
2021-2-25 12:50:28.492 [REPO] Did not find an Id { Steam App 365450 }
2021-2-25 12:50:28.494 [REPO] Adding manifest for [Steam App 431960, Unknown] at relative path [Steam App 431960]
2021-2-25 12:50:28.494 [REPO] Did not find an Id { Steam App 431960 }
2021-2-25 12:50:28.495 [REPO] Adding manifest for [Steam App 477160, Unknown] at relative path [Steam App 477160]
2021-2-25 12:50:28.495 [REPO] Did not find an Id { Steam App 477160 }
2021-2-25 12:50:28.498 [REPO] Adding manifest for [Steam App 480, Unknown] at relative path [Steam App 480]
2021-2-25 12:50:28.498 [REPO] Did not find an Id { Steam App 480 }
2021-2-25 12:50:28.499 [REPO] Adding manifest for [Steam App 503560, Unknown] at relative path [Steam App 503560]
2021-2-25 12:50:28.500 [REPO] Did not find an Id { Steam App 503560 }
2021-2-25 12:50:28.501 [REPO] Adding manifest for [Steam App 551110, Unknown] at relative path [Steam App 551110]
2021-2-25 12:50:28.502 [REPO] Did not find an Id { Steam App 551110 }
2021-2-25 12:50:28.504 [REPO] Adding manifest for [Steam App 644560, Unknown] at relative path [Steam App 644560]
2021-2-25 12:50:28.504 [REPO] Did not find an Id { Steam App 644560 }
2021-2-25 12:50:28.505 [REPO] Adding manifest for [Steam App 668630, Unknown] at relative path [Steam App 668630]
2021-2-25 12:50:28.505 [REPO] Did not find an Id { Steam App 668630 }
2021-2-25 12:50:28.507 [REPO] Adding manifest for [Steam App 730, Unknown] at relative path [Steam App 730]
2021-2-25 12:50:28.507 [REPO] Did not find an Id { Steam App 730 }
2021-2-25 12:50:28.508 [REPO] Adding manifest for [Steam App 736190, Unknown] at relative path [Steam App 736190]
2021-2-25 12:50:28.508 [REPO] Did not find an Id { Steam App 736190 }
2021-2-25 12:50:28.511 [REPO] Adding manifest for [Steam App 774171, Unknown] at relative path [Steam App 774171]
2021-2-25 12:50:28.511 [REPO] Did not find an Id { Steam App 774171 }
2021-2-25 12:50:28.512 [REPO] Adding manifest for [Vim 8.2, 8.2] at relative path [Vim 8.2]
2021-2-25 12:50:28.512 [REPO] Did not find an Id { Vim 8.2 }
2021-2-25 12:50:28.514 [REPO] Adding manifest for [VLC media player, 3.0.12] at relative path [VLC media player]
2021-2-25 12:50:28.514 [REPO] Did not find an Id { VLC media player }
2021-2-25 12:50:28.515 [REPO] Adding manifest for [WinRAR archiver, 5.91.0] at relative path [WinRAR archiver]
2021-2-25 12:50:28.515 [REPO] Did not find an Id { WinRAR archiver }
2021-2-25 12:50:28.517 [REPO] Adding manifest for [{046F527E-3DE6-4D0D-9FEA-053099931721}, 13.1.4001.0] at relative path [{046F527E-3DE6-4D0D-9FEA-053099931721}]
2021-2-25 12:50:28.517 [REPO] Did not find an Id { {046F527E-3DE6-4D0D-9FEA-053099931721} }
2021-2-25 12:50:28.519 [REPO] Adding manifest for [{071c9b48-7c32-4621-a0ac-3f809523288f}, 8.0.56336] at relative path [{071c9b48-7c32-4621-a0ac-3f809523288f}]
2021-2-25 12:50:28.519 [REPO] Did not find an Id { {071c9b48-7c32-4621-a0ac-3f809523288f} }
2021-2-25 12:50:28.521 [REPO] Adding manifest for [{18469ED8-8C36-4CF7-BD43-0FC9B1931AF8}, 3.7.0] at relative path [{18469ED8-8C36-4CF7-BD43-0FC9B1931AF8}]
2021-2-25 12:50:28.521 [REPO] Did not find an Id { {18469ED8-8C36-4CF7-BD43-0FC9B1931AF8} }
2021-2-25 12:50:28.523 [REPO] Adding manifest for [{1A726640-2F1F-4820-AC82-B7179DD11893}, 1.15.7] at relative path [{1A726640-2F1F-4820-AC82-B7179DD11893}]
2021-2-25 12:50:28.523 [REPO] Did not find an Id { {1A726640-2F1F-4820-AC82-B7179DD11893} }
2021-2-25 12:50:28.525 [REPO] Adding manifest for [{1CEAC85D-2590-4760-800F-8DE5E91F3700}, 19<IP_ADDRESS>9] at relative path [{1CEAC85D-2590-4760-800F-8DE5E91F3700}]
2021-2-25 12:50:28.525 [REPO] Did not find an Id { {1CEAC85D-2590-4760-800F-8DE5E91F3700} }
2021-2-25 12:50:28.526 [REPO] Adding manifest for [{1D8E6291-B0D5-35EC-8441-6616F567A0F7}, 10.0.40219] at relative path [{1D8E6291-B0D5-35EC-8441-6616F567A0F7}]
2021-2-25 12:50:28.526 [REPO] Did not find an Id { {1D8E6291-B0D5-35EC-8441-6616F567A0F7} }
2021-2-25 12:50:28.528 [REPO] Adding manifest for [{23170F69-40C1-2702-1900-000001000000}, <IP_ADDRESS>] at relative path [{23170F69-40C1-2702-1900-000001000000}]
2021-2-25 12:50:28.528 [REPO] Did not find an Id { {23170F69-40C1-2702-1900-000001000000} }
2021-2-25 12:50:28.533 [REPO] Adding manifest for [{26A24AE4-039D-4CA4-87B4-2F64180241F0}, 8.0.2410.7] at relative path [{26A24AE4-039D-4CA4-87B4-2F64180241F0}]
2021-2-25 12:50:28.533 [REPO] Did not find an Id { {26A24AE4-039D-4CA4-87B4-2F64180241F0} }
2021-2-25 12:50:28.535 [REPO] Adding manifest for [{291E1E02-92A8-4D67-B74A-4A920D759895}, 11.201.0110] at relative path [{291E1E02-92A8-4D67-B74A-4A920D759895}]
2021-2-25 12:50:28.535 [REPO] Did not find an Id { {291E1E02-92A8-4D67-B74A-4A920D759895} }
2021-2-25 12:50:28.536 [REPO] Adding manifest for [{2A0E068A-6121-43D5-93F4-411B0E16BE16}, 14.13.1] at relative path [{2A0E068A-6121-43D5-93F4-411B0E16BE16}]
2021-2-25 12:50:28.537 [REPO] Did not find an Id { {2A0E068A-6121-43D5-93F4-411B0E16BE16} }
2021-2-25 12:50:28.539 [REPO] Adding manifest for [{409CB30E-E457-4008-9B1A-ED1B9EA21140}, <IP_ADDRESS>1] at relative path [{409CB30E-E457-4008-9B1A-ED1B9EA21140}]
2021-2-25 12:50:28.539 [REPO] Did not find an Id { {409CB30E-E457-4008-9B1A-ED1B9EA21140} }
2021-2-25 12:50:28.541 [REPO] Adding manifest for [{41D2D254-D869-4CD8-B440-5DF49083C4BA}, 4.1.0] at relative path [{41D2D254-D869-4CD8-B440-5DF49083C4BA}]
2021-2-25 12:50:28.541 [REPO] Did not find an Id { {41D2D254-D869-4CD8-B440-5DF49083C4BA} }
2021-2-25 12:50:28.543 [REPO] Adding manifest for [{58BDEF15-554A-4AF7-969F-C34918026641}, 5.1.321.7308] at relative path [{58BDEF15-554A-4AF7-969F-C34918026641}]
2021-2-25 12:50:28.543 [REPO] Did not find an Id { {58BDEF15-554A-4AF7-969F-C34918026641} }
2021-2-25 12:50:28.545 [REPO] Adding manifest for [{5FCE6D76-F5DC-37AB-B2B8-22AB8CEDB1D4}, 9.0.30729.6161] at relative path [{5FCE6D76-F5DC-37AB-B2B8-22AB8CEDB1D4}]
2021-2-25 12:50:28.545 [REPO] Did not find an Id { {5FCE6D76-F5DC-37AB-B2B8-22AB8CEDB1D4} }
2021-2-25 12:50:28.546 [REPO] Adding manifest for [{6F320B93-EE3C-4826-85E0-ADF79F8D4C61}, 2.8.3077.1211] at relative path [{6F320B93-EE3C-4826-85E0-ADF79F8D4C61}]
2021-2-25 12:50:28.547 [REPO] Did not find an Id { {6F320B93-EE3C-4826-85E0-ADF79F8D4C61} }
2021-2-25 12:50:28.548 [REPO] Adding manifest for [{8220EEFE-38CD-377E-8595-13398D740ACE}, 9.0.30729] at relative path [{8220EEFE-38CD-377E-8595-13398D740ACE}]
2021-2-25 12:50:28.548 [REPO] Did not find an Id { {8220EEFE-38CD-377E-8595-13398D740ACE} }
2021-2-25 12:50:28.549 [REPO] Adding manifest for [{8D646799-DB00-4000-AE7A-756A05A4F1D8}, 5.4.72] at relative path [{8D646799-DB00-4000-AE7A-756A05A4F1D8}]
2021-2-25 12:50:28.549 [REPO] Did not find an Id { {8D646799-DB00-4000-AE7A-756A05A4F1D8} }
2021-2-25 12:50:28.550 [REPO] Adding manifest for [{95096479-66A1-454B-9378-234DF3B31727}, 16.1.0] at relative path [{95096479-66A1-454B-9378-234DF3B31727}]
2021-2-25 12:50:28.550 [REPO] Did not find an Id { {95096479-66A1-454B-9378-234DF3B31727} }
2021-2-25 12:50:28.551 [REPO] Adding manifest for [{9668B1BB-D0FE-4C0C-800C-B1555E069A62}, 3.1.940] at relative path [{9668B1BB-D0FE-4C0C-800C-B1555E069A62}]
2021-2-25 12:50:28.551 [REPO] Did not find an Id { {9668B1BB-D0FE-4C0C-800C-B1555E069A62} }
2021-2-25 12:50:28.552 [REPO] Adding manifest for [{986898D9-7C26-4E7F-814C-9B5472FA3209}, <IP_ADDRESS>] at relative path [{986898D9-7C26-4E7F-814C-9B5472FA3209}]
2021-2-25 12:50:28.552 [REPO] Did not find an Id { {986898D9-7C26-4E7F-814C-9B5472FA3209} }
2021-2-25 12:50:28.553 [REPO] Adding manifest for [{99FAF70F-9B61-4AB0-9EC0-B31F98FFDC4A}, <IP_ADDRESS>] at relative path [{99FAF70F-9B61-4AB0-9EC0-B31F98FFDC4A}]
2021-2-25 12:50:28.553 [REPO] Did not find an Id { {99FAF70F-9B61-4AB0-9EC0-B31F98FFDC4A} }
2021-2-25 12:50:28.554 [REPO] Adding manifest for [{9F0CBE43-690B-4C03-8845-6AC2CDB29815}}_is1, 1.20.0] at relative path [{9F0CBE43-690B-4C03-8845-6AC2CDB29815}}_is1]
2021-2-25 12:50:28.554 [REPO] Did not find an Id { {9F0CBE43-690B-4C03-8845-6AC2CDB29815}}_is1 }
2021-2-25 12:50:28.556 [REPO] Adding manifest for [{ad8a2fa1-06e7-4b0d-927d-6e54b3d31028}, 8.0.61000] at relative path [{ad8a2fa1-06e7-4b0d-927d-6e54b3d31028}]
2021-2-25 12:50:28.556 [REPO] Did not find an Id { {ad8a2fa1-06e7-4b0d-927d-6e54b3d31028} }
2021-2-25 12:50:28.557 [REPO] Adding manifest for [{B2FE1952-0186-46C3-BAEC-A80AA35AC5B8}_Display.Driver, 461.40] at relative path [{B2FE1952-0186-46C3-BAEC-A80AA35AC5B8}_Display.Driver]
2021-2-25 12:50:28.557 [REPO] Did not find an Id { {B2FE1952-0186-46C3-BAEC-A80AA35AC5B8}_Display.Driver }
2021-2-25 12:50:28.558 [REPO] Adding manifest for [{B2FE1952-0186-46C3-BAEC-A80AA35AC5B8}_Display.GFExperience, <IP_ADDRESS>] at relative path [{B2FE1952-0186-46C3-BAEC-A80AA35AC5B8}_Display.GFExperience]
2021-2-25 12:50:28.558 [REPO] Did not find an Id { {B2FE1952-0186-46C3-BAEC-A80AA35AC5B8}_Display.GFExperience }
2021-2-25 12:50:28.560 [REPO] Adding manifest for [{B2FE1952-0186-46C3-BAEC-A80AA35AC5B8}_Display.PhysX, 9.19.0218] at relative path [{B2FE1952-0186-46C3-BAEC-A80AA35AC5B8}_Display.PhysX]
2021-2-25 12:50:28.560 [REPO] Did not find an Id { {B2FE1952-0186-46C3-BAEC-A80AA35AC5B8}_Display.PhysX }
2021-2-25 12:50:28.561 [REPO] Adding manifest for [{B2FE1952-0186-46C3-BAEC-A80AA35AC5B8}_FrameViewSdk, 1.1.4923.29548709] at relative path [{B2FE1952-0186-46C3-BAEC-A80AA35AC5B8}_FrameViewSdk]
2021-2-25 12:50:28.561 [REPO] Did not find an Id { {B2FE1952-0186-46C3-BAEC-A80AA35AC5B8}_FrameViewSdk }
2021-2-25 12:50:28.564 [REPO] Adding manifest for [{B5D244EF-C3DE-42BE-8DCC-8263A0D3750F}, 15.0.1200.24] at relative path [{B5D244EF-C3DE-42BE-8DCC-8263A0D3750F}]
2021-2-25 12:50:28.564 [REPO] Did not find an Id { {B5D244EF-C3DE-42BE-8DCC-8263A0D3750F} }
2021-2-25 12:50:28.565 [REPO] Adding manifest for [{BBCDB523-F5B7-4E53-A911-C85191E3BDF0}, 10.0.2606] at relative path [{BBCDB523-F5B7-4E53-A911-C85191E3BDF0}]
2021-2-25 12:50:28.565 [REPO] Did not find an Id { {BBCDB523-F5B7-4E53-A911-C85191E3BDF0} }
2021-2-25 12:50:28.566 [REPO] Adding manifest for [{C5A70974-2F89-4BE0-90F7-749E62468C4D}, <IP_ADDRESS>] at relative path [{C5A70974-2F89-4BE0-90F7-749E62468C4D}]
2021-2-25 12:50:28.566 [REPO] Did not find an Id { {C5A70974-2F89-4BE0-90F7-749E62468C4D} }
2021-2-25 12:50:28.567 [REPO] Adding manifest for [{C81FD018-F151-460F-B4F9-0D58039503E2}, <IP_ADDRESS>02] at relative path [{C81FD018-F151-460F-B4F9-0D58039503E2}]
2021-2-25 12:50:28.567 [REPO] Did not find an Id { {C81FD018-F151-460F-B4F9-0D58039503E2} }
2021-2-25 12:50:28.568 [REPO] Adding manifest for [{EA457B21-F73E-494C-ACAB-524FDE069978}_is1, 1.42.0] at relative path [{EA457B21-F73E-494C-ACAB-524FDE069978}_is1]
2021-2-25 12:50:28.569 [REPO] Did not find an Id { {EA457B21-F73E-494C-ACAB-524FDE069978}_is1 }
2021-2-25 12:50:28.570 [REPO] Examining ARP entries for Machine | X86
2021-2-25 12:50:28.570 [REPO] Adding manifest for [1acdd5fe, 16.8.31019.35] at relative path [1acdd5fe]
2021-2-25 12:50:28.570 [REPO] Did not find an Id { 1acdd5fe }
2021-2-25 12:50:28.572 [REPO] Adding manifest for [8c97ca59, 15.9.28307.1401] at relative path [8c97ca59]
2021-2-25 12:50:28.572 [REPO] Did not find an Id { 8c97ca59 }
2021-2-25 12:50:28.574 [REPO] Adding manifest for [Adobe Creative Cloud, <IP_ADDRESS>0] at relative path [Adobe Creative Cloud]
2021-2-25 12:50:28.574 [REPO] Did not find an Id { Adobe Creative Cloud }
2021-2-25 12:50:28.575 [REPO] Adding manifest for [Adobe Flash Player PPAPI, <IP_ADDRESS>3] at relative path [Adobe Flash Player PPAPI]
2021-2-25 12:50:28.576 [REPO] Did not find an Id { Adobe Flash Player PPAPI }
2021-2-25 12:50:28.577 [REPO] Adding manifest for [AEFT_17_7, 17.7] at relative path [AEFT_17_7]
2021-2-25 12:50:28.577 [REPO] Did not find an Id { AEFT_17_7 }
2021-2-25 12:50:28.578 [REPO] Adding manifest for [AIDA64 Extreme_is1, 6.32] at relative path [AIDA64 Extreme_is1]
2021-2-25 12:50:28.578 [REPO] Did not find an Id { AIDA64 Extreme_is1 }
2021-2-25 12:50:28.581 [REPO] Adding manifest for [alieditplus, <IP_ADDRESS>] at relative path [alieditplus]
2021-2-25 12:50:28.581 [REPO] Did not find an Id { alieditplus }
2021-2-25 12:50:28.582 [REPO] Adding manifest for [AME_14_9, 14.9] at relative path [AME_14_9]
2021-2-25 12:50:28.582 [REPO] Did not find an Id { AME_14_9 }
2021-2-25 12:50:28.583 [REPO] Adding manifest for [ASIO4ALL, 2.14] at relative path [ASIO4ALL]
2021-2-25 12:50:28.583 [REPO] Did not find an Id { ASIO4ALL }
2021-2-25 12:50:28.585 [REPO] Adding manifest for [AUDT_13_0_13, 13.0.13] at relative path [AUDT_13_0_13]
2021-2-25 12:50:28.585 [REPO] Did not find an Id { AUDT_13_0_13 }
2021-2-25 12:50:28.586 [REPO] Adding manifest for [B5CSGO, <IP_ADDRESS>] at relative path [B5CSGO]
2021-2-25 12:50:28.586 [REPO] Did not find an Id { B5CSGO }
2021-2-25 12:50:28.587 [REPO] Adding manifest for [BandiMPEG1, 0.0.1] at relative path [BandiMPEG1]
2021-2-25 12:50:28.588 [REPO] Did not find an Id { BandiMPEG1 }
2021-2-25 12:50:28.590 [REPO] Adding manifest for [FileZilla Client, 3.46.3] at relative path [FileZilla Client]
2021-2-25 12:50:28.590 [REPO] Did not find an Id { FileZilla Client }
2021-2-25 12:50:28.591 [REPO] Adding manifest for [FL Studio 20, Unknown] at relative path [FL Studio 20]
2021-2-25 12:50:28.591 [REPO] Did not find an Id { FL Studio 20 }
2021-2-25 12:50:28.592 [REPO] Adding manifest for [FL Studio ASIO, Unknown] at relative path [FL Studio ASIO]
2021-2-25 12:50:28.592 [REPO] Did not find an Id { FL Studio ASIO }
2021-2-25 12:50:28.593 [REPO] Adding manifest for [FormatFactory, <IP_ADDRESS>] at relative path [FormatFactory]
2021-2-25 12:50:28.593 [REPO] Did not find an Id { FormatFactory }
2021-2-25 12:50:28.594 [REPO] Adding manifest for [GoLink, <IP_ADDRESS>] at relative path [GoLink]
2021-2-25 12:50:28.594 [REPO] Did not find an Id { GoLink }
2021-2-25 12:50:28.595 [REPO] Adding manifest for [HeyboxAcc, 1.0.99] at relative path [HeyboxAcc]
2021-2-25 12:50:28.595 [REPO] Did not find an Id { HeyboxAcc }
2021-2-25 12:50:28.597 [REPO] Adding manifest for [HuyaClient, Unknown] at relative path [HuyaClient]
2021-2-25 12:50:28.597 [REPO] Did not find an Id { HuyaClient }
2021-2-25 12:50:28.599 [REPO] Adding manifest for [IL Download Manager, Unknown] at relative path [IL Download Manager]
2021-2-25 12:50:28.599 [REPO] Did not find an Id { IL Download Manager }
2021-2-25 12:50:28.600 [REPO] Adding manifest for [InstallShield_{2D76AF66-6E44-4AD8-91B4-CBD509588E99}, 6.0.0089] at relative path [InstallShield_{2D76AF66-6E44-4AD8-91B4-CBD509588E99}]
2021-2-25 12:50:28.600 [REPO] Did not find an Id { InstallShield_{2D76AF66-6E44-4AD8-91B4-CBD509588E99} }
2021-2-25 12:50:28.601 [REPO] Adding manifest for [InstallShield_{EB1AAB19-5EE8-46BD-86CC-146BF85DC170}, 6.0.0193] at relative path [InstallShield_{EB1AAB19-5EE8-46BD-86CC-146BF85DC170}]
2021-2-25 12:50:28.601 [REPO] Did not find an Id { InstallShield_{EB1AAB19-5EE8-46BD-86CC-146BF85DC170} }
2021-2-25 12:50:28.603 [REPO] Adding manifest for [KBRG_11_0_1, 11.0.1] at relative path [KBRG_11_0_1]
2021-2-25 12:50:28.603 [REPO] Did not find an Id { KBRG_11_0_1 }
2021-2-25 12:50:28.605 [REPO] Adding manifest for [MarkdownPad 2 <IP_ADDRESS>920, <IP_ADDRESS>920] at relative path [MarkdownPad 2 <IP_ADDRESS>920]
2021-2-25 12:50:28.605 [REPO] Did not find an Id { MarkdownPad 2 <IP_ADDRESS>920 }
2021-2-25 12:50:28.606 [REPO] Adding manifest for [Microsoft Edge, 88.0.705.74] at relative path [Microsoft Edge]
2021-2-25 12:50:28.607 [REPO] Did not find an Id { Microsoft Edge }
2021-2-25 12:50:28.608 [REPO] Adding manifest for [Microsoft Edge Dev, 90.0.803.0] at relative path [Microsoft Edge Dev]
2021-2-25 12:50:28.608 [REPO] Did not find an Id { Microsoft Edge Dev }
2021-2-25 12:50:28.609 [REPO] Adding manifest for [Microsoft Edge Update, <IP_ADDRESS>] at relative path [Microsoft Edge Update]
2021-2-25 12:50:28.610 [REPO] Did not find an Id { Microsoft Edge Update }
2021-2-25 12:50:28.611 [REPO] Adding manifest for [MouseClick, <IP_ADDRESS>] at relative path [MouseClick]
2021-2-25 12:50:28.611 [REPO] Did not find an Id { MouseClick }
2021-2-25 12:50:28.612 [REPO] Adding manifest for [OBS Studio, 24.0.3] at relative path [OBS Studio]
2021-2-25 12:50:28.612 [REPO] Did not find an Id { OBS Studio }
2021-2-25 12:50:28.613 [REPO] Adding manifest for [Open Codecs, 0.85.17777] at relative path [Open Codecs]
2021-2-25 12:50:28.614 [REPO] Did not find an Id { Open Codecs }
2021-2-25 12:50:28.615 [REPO] Adding manifest for [Origin, <IP_ADDRESS>868] at relative path [Origin]
2021-2-25 12:50:28.615 [REPO] Did not find an Id { Origin }
2021-2-25 12:50:28.616 [REPO] Adding manifest for [PHSP_22_2, <IP_ADDRESS>] at relative path [PHSP_22_2]
2021-2-25 12:50:28.616 [REPO] Did not find an Id { PHSP_22_2 }
2021-2-25 12:50:28.618 [REPO] Adding manifest for [PPRO_14_9, 14.9] at relative path [PPRO_14_9]
2021-2-25 12:50:28.619 [REPO] Did not find an Id { PPRO_14_9 }
2021-2-25 12:50:28.620 [REPO] Adding manifest for [qBittorrent, 4.3.3] at relative path [qBittorrent]
2021-2-25 12:50:28.620 [REPO] Did not find an Id { qBittorrent }
2021-2-25 12:50:28.621 [REPO] Adding manifest for [QeeYou5.1.0, 6.2.0] at relative path [QeeYou5.1.0]
2021-2-25 12:50:28.622 [REPO] Did not find an Id { QeeYou5.1.0 }
2021-2-25 12:50:28.623 [REPO] Adding manifest for [QQ游戏, 5.22.57218.0] at relative path [QQ游戏]
2021-2-25 12:50:28.623 [REPO] Did not find an Id { QQ游戏 }
2021-2-25 12:50:28.624 [REPO] Adding manifest for [Rockstar Games Launcher, <IP_ADDRESS>0] at relative path [Rockstar Games Launcher]
2021-2-25 12:50:28.624 [REPO] Did not find an Id { Rockstar Games Launcher }
2021-2-25 12:50:28.626 [REPO] Adding manifest for [Rockstar Games Social Club, <IP_ADDRESS>] at relative path [Rockstar Games Social Club]
2021-2-25 12:50:28.626 [REPO] Did not find an Id { Rockstar Games Social Club }
2021-2-25 12:50:28.626 [REPO] Adding manifest for [Sogou Input, <IP_ADDRESS>46] at relative path [Sogou Input]
2021-2-25 12:50:28.627 [REPO] Did not find an Id { Sogou Input }
2021-2-25 12:50:28.628 [REPO] Adding manifest for [Steam, <IP_ADDRESS>] at relative path [Steam]
2021-2-25 12:50:28.628 [REPO] Did not find an Id { Steam }
2021-2-25 12:50:28.629 [REPO] Adding manifest for [Synology Assistant, 6.1-15030] at relative path [Synology Assistant]
2021-2-25 12:50:28.629 [REPO] Did not find an Id { Synology Assistant }
2021-2-25 12:50:28.630 [REPO] Adding manifest for [TalkLine,<PHONE_NUMBER>36_master(5.14.1)_<IP_ADDRESS>] at relative path [TalkLine]
2021-2-25 12:50:28.631 [REPO] Did not find an Id { TalkLine }
2021-2-25 12:50:28.632 [REPO] Adding manifest for [TDM-GCC, 1.2001.0] at relative path [TDM-GCC]
2021-2-25 12:50:28.632 [REPO] Did not find an Id { TDM-GCC }
2021-2-25 12:50:28.633 [REPO] Adding manifest for [thunder_is1, <IP_ADDRESS>4] at relative path [thunder_is1]
2021-2-25 12:50:28.633 [REPO] Did not find an Id { thunder_is1 }
2021-2-25 12:50:28.636 [REPO] Adding manifest for [UltraISO_is1, Unknown] at relative path [UltraISO_is1]
2021-2-25 12:50:28.636 [REPO] Did not find an Id { UltraISO_is1 }
2021-2-25 12:50:28.638 [REPO] Adding manifest for [Uplay, 102.0] at relative path [Uplay]
2021-2-25 12:50:28.638 [REPO] Did not find an Id { Uplay }
2021-2-25 12:50:28.640 [REPO] Adding manifest for [Uplay Install 46, Unknown] at relative path [Uplay Install 46]
2021-2-25 12:50:28.640 [REPO] Did not find an Id { Uplay Install 46 }
2021-2-25 12:50:28.642 [REPO] Adding manifest for [WeChat, <IP_ADDRESS>] at relative path [WeChat]
2021-2-25 12:50:28.642 [REPO] Did not find an Id { WeChat }
2021-2-25 12:50:28.644 [REPO] Adding manifest for [WeGame, Unknown] at relative path [WeGame]
2021-2-25 12:50:28.644 [REPO] Did not find an Id { WeGame }
2021-2-25 12:50:28.646 [REPO] Adding manifest for [WeMeet, <IP_ADDRESS>5] at relative path [WeMeet]
2021-2-25 12:50:28.646 [REPO] Did not find an Id { WeMeet }
2021-2-25 12:50:28.647 [REPO] Adding manifest for [WinPcapInst, <IP_ADDRESS>1] at relative path [WinPcapInst]
2021-2-25 12:50:28.647 [REPO] Did not find an Id { WinPcapInst }
2021-2-25 12:50:28.651 [FAIL] C:\BA\246\s\external\pkg\src\AppInstallerCommonCore\Registry.cpp(15)\AppInstallerCLI.exe!00007FF7BDCC3218: (caller: 00007FF7BDCC24F7) Exception(1) tid(513c) 8007139F 组或资源的状态不是执行请求操作的正确状态。

2021-2-25 12:50:28.875 [CLI ] Caught wil::ResultException:

This is a bug in our registry reading code that I thought was fixed, but somehow was not.  It actually suggests that it is bad data in the registry, but we should handle that as best as we can.
There is some registry value that has an odd number of bytes despite being a wide string.  We will probably be best served to change the code to remove any stray bytes rather than failing here.  Then things will work except for these instances where the name or publisher data may be garbled at the end.
It will probably be hard to get the data to help debug your exact situation, but the entry after WinPcapInst under:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall

Contains the value in question.

this my reg of HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
myreg.txt
My English is bad,and Chinese translation software is very difficult to use.
can you help me to solve this problem?
thanks

Reactivating to track the bug.

我卸载[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\zsspeed]所对应的软件后，winget一切正常

Duplicate of #728


Removed Generated zconf.h

This file is already ignored but was left in by mistake. It gets quite annoying as I have SDL_image as a submodule and SourceTree keeps complaining that the project is changed as building with CMake deletes this file.

@slouken: This will make android builds to fail: I suggest reverting.


De-duplicate S^z implementation

Summary
A very minor thing as this simply avoids to re-implement the $S^z$ operator.
It also minorly improves the Magnetization docs.
Details and comments

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.001%) to 86.742%

Totals

Change from base Build<PHONE_NUMBER>:
-0.001%

Covered Lines:
8767

Relevant Lines:
10107

💛  - Coveralls


[ADAM-1342] Update CLI docs after #1288 merged.

Resolves #1342. Adds validation stringency documentation for vcf2adam and adam2vcf. Removes mention of the anno2adam and flatten commands, which were removed in #1288.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/1723/
Test PASSed.

Rebased and addressed comment.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/1724/
Test PASSed.

Thank you, @fnothaft


Bug TLS connection from android sdk

This has reference to issue 604
I am using my own own built endpoint to forward the requests to speech endpoint
I am connecting from Android SDK and i am getting TLS verify fail using mocrosoft SDK
I am conncting from Destop SDK and i am not getting TLS ISSUE. It succeeds.
Log file is given in issue 604
If the certificate was the issue the desktop sdk should also have rejected thr connection.
Also need to know how i can increase the log level for the logging in android sdk

Can you send us the URL or the certificate's public information in .cer format to inspect?
And what Android version you're using.

Android 7.1.1
Model AZUS_Z01BDB

Any updates

@viju2008 sorry for the radio silence.
Could you please email your URL to oliversc_at_microsoft.com (replace at with @).
We'll see what we can do.


Parallel transpiling (build)

Description of the change
This PR parallelizes the transpiling part of the build, so they run on different threads. This is built on top of #21308 and uses threads as its script-runner. The changes to the scripts/lib are very minimal. The build script is changed to support running the threads.
Note: This PR is part of the series that speed up the build/bootstrap of Atom #21308 #21342 #21398 and more PRs that are coming (such as parallelizing copy assets, clean, etc). See https://github.com/atom-ide-community/atom/pull/155.
Verification
The local builds/CI pass all the tests,
Benefits
Results in a faster building of Atom locally or in the CI.
Release Notes
Faster building by using threads for transpiling.
Requires #21308

@aminya This PR now has conflicts. Do you mind resolving them before I give it a second look?

@aminya This PR now has conflicts. Do you mind resolving them before I give it a second look?

Thanks for the PR!
That would definitely be a useful addition to our build process. However, it is not something that is within the scope that we have envisioned for Atom. We are not planning to make any major improvements to our build process for the time being. We are focused on fixing user-facing bugs. For that reason, I'm going to close this.
Thanks again for contributing to Atom :+1:


The Tabs bar cannot load

react-native, react and native-base version
"native-base": "^2.0.8",
"react": "15.4.2",
"react-native": "0.41.2"
i am getting this error : "Invariant Violation" with this description below even after i using the latest master github repo. Any idea? I tried googling around but i can't find any possible solution.
"Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object. Check the render method of 'ResumeHome'"
My sample code:
render() {
        return (
            <Container>
                    <Header>
                        <Left>
                            <Button transparent onPress={Actions.pop}>
                               <Icon ios='ios-arrow-back' android='md-arrow-back'/>
                            </Button>
                        </Left>
                        <Body>
                            <Title>Resume</Title>
                        </Body>
                        <Right/>
                    </Header>

                    <Content>
                        <StyleProvider style={getTheme(customTheme)}>
                             <Tabs>
                                <Tab heading="View">
                                    <TabOne />
                                </Tab>
                                <Tab heading="Configure">
                                    <TabTwo />
                                </Tab>
                            </Tabs>
                        </StyleProvider>
                    </Content>
                </Container>
        )
    }

I tried removing the <Tabs> and it works but it links back to issue #541 (I'm using the latest github commit)
Below is the warning message shown when I tried to navigate to the Tabs page.

Ideally the tab should be outside Content

Nope it's nothing do with <Content>
Any specific adjustment on <Tabs>?  cause  <Tabs> is the one making all this behind.

"native-base": "^2.0.8",
"react": "15.4.2",
"react-native": "0.41.2"
Yes i did upgrade from an older version of native-base and i also eject the variables based on the instructions by running ejectTheme.js
Is there anymore links that i can refer on ejecting variables?

Some variables have been updated. You might have to eject again for it to work properly.

I followed the docs page instructions exactly. (http://nativebase.io/docs/v2.0.0/components#tabs)
Mind explaining the eject part? :) Thanks!

Run node node_modules/native-base/ejectTheme.js again. It copies the theme variables and styles to the root folder. Please keep in mind that if you have changed some variables or theme styles, you might have to do it again.

Fixed in #541.


Ensure consistent timestamp precision

The code below was failing because Timestamps had sub-second precision when created with Timestamp::now but changed to whole seconds when serialized as JSON. This was partly a regression from https://github.com/iotaledger/identity.rs/pull/122 - there was also a case where timestamps could be parsed directly with sub-second precision.
/// Deserializes a Document from a JSON string.
pub fn from_json(json: &String) -> Result<Document, CoreError> {
    match Document::from_json(&json) {
        Ok(document) => Ok(document),
        Err(e) => Err(e),
    }
}

/// Serializes an Document into a JSON string.
pub fn to_json(document: &Document) -> Result<String, CoreError> {
    match document.to_json() {
        Ok(document) => Ok(document),
        Err(e) => Err(e),
    }
}

/// Creates a new Document
pub fn create_did_document() -> Result<Document, IotaError> {
    let keypair: KeyPair = KeyPair::new_ed25519()?;
    let mut document: Document = Document::from_keypair(&keypair)?;
    match document.sign(keypair.secret()) {
        Ok(()) => Ok(document),
        Err(e) => Err(e),
    }
}

#[test]
fn test_functions() {
    let doc1 = create_did_document().unwrap();
    let doc2 = from_json(&to_json(&doc1).unwrap()).unwrap();
    assert_eq!(doc1, doc2);
}

We are dropping ms precision for this, right? I don't think we need it, but it's good to be aware of. As per the DID standard:

The value of the property MUST be a string formatted as an XML Datetime normalized to UTC 00:00:00 and without sub-second decimal precision. For example: 2020-12-20T19:17:47Z.

So this is actually more aligned with the standard, right?


Expose a test suite

It would be nice to have a test suite that test an implementation of Buf and BufMut. It's would avoid everybody to write they own test, also, I expect bytes test would be way more exhaustive.

Having a bytes-test crates ?
Expose it in bytes ?
Other solution ?

This is a pretty decent idea. It's kind of like the "contracts" you may find in Scala/Haskell, where after you implement a typeclass, you can check to make sure you followed all the expected properties. I suppose a next step would be a formal proposal of all that it would check?

I suppose a next step would be a formal proposal of all that it would check?

I'm not sure it's necessary, that may be ask too much. Just a entry api that say "look ok" would be amazing the next level would be "not ok here what doesn't work" like named test.
My motivation is for circbuf that implement a circular buffer that I use for tokio. I just have the idea to have more solid test than https://github.com/jeromefroe/circbuf-rs/blob/master/src/lib.rs#L557.


Aimbot and skinchanger are broken due to the new Osiris update.

Title says everything.

yep, aimbot works for rifles only i think but skin changer is totally broken it seems.

yep, aimbot works for rifles only i think but skin changer is totally broken it seems.

nevermind, hes fixed it.


Test Cafe Requires Permission To Record Screen -> but permission is already granted on MAC

What is your Test Scenario?

To be able to record the screen on failures
What is the Current behavior?

Copying from #4684 (which is closed & locked)
I recently upgraded my mac to Big Sur, and installed the latest alpha version of TestCafe (1.15.0-aplpha.1). When trying to run testcafe I get
TestCafe requires permission to record the screen. Open 'System Preferences > Security & Privacy > Privacy > Screen Recording' and check 'TestCafe Browser Tools' in the application list.

Press any key to retry.
ERROR UnableToAccessScreenRecordingAPIError: The find-window process cannot access the Screen Recording API.
    at runFindWindowBinary

Screen Recording Permission has already been granted for TestCafe... following the advice in #4684, I have unchecked and rechecked TestCafe Browser Tools + restarted my Mac

Your complete configuration file (if any):

{
  "browsers": ["chrome:headless:emulation:device=iPhone X"],
  "src": "./tests/**/*.js",
  "clientScripts":[
    {
      "module":"axe-core/axe.min.js"
    }
  ],

  "assertionTimeout": 15000,
  "pageLoadTimeout": 30000,
  "selectorTimeout": 15000,

  "disableMultipleWindows": false,

  "quarantineMode": false,
  "skipJsErrors": true,

  "disablePageCaching": true,

  "reporter": [
    {
      "name": "xunit",
      "output": "artifacts/test-results/results.xml"
    },
    {
      "name": "spec"
    }
  ],

  "screenshots": {
    "fullPage": true,
    "takeOnFails": true,
    "pathPattern": "${TEST_ID}/${RUN_ID}_${FILE_INDEX}.png",
    "path": "artifacts/screenshots"
  }
}

Your complete test report:

The "quarantineMode" option from the configuration file will be ignored.
TestCafe requires permission to record the screen. Open 'System Preferences > Security & Privacy > Privacy > Screen Recording' and check 'TestCafe Browser Tools' in the application list.

Press any key to retry.
ERROR UnableToAccessScreenRecordingAPIError: The find-window process cannot access the Screen Recording API.
    at runFindWindowBinary (/Users/rcooper/work/github.com/change/regression-qaa/node_modules/testcafe-browser-tools/src/api/find-window.js:36:19)

Type "testcafe -h" for help.

Screenshots:

<img width="905" alt="Screenshot 2021-05-01 at 3 57 52 PM" src="https://user-images.githubusercontent.com/37812673/116797143-4804f480-aa97-11eb-9f77-2a131a995d76.png">

Steps to Reproduce:

Using Big Sur MacOS, run: testcafe chrome -q passCount=1
Your Environment details:

testcafe version:   1.15.0-alpha.1
node.js version:   12.14.1
command-line arguments:  testcafe chrome -q passCount=1
browser name and version: chrome 90.0
platform and version:  MacOS Big Sur 11.3
other:

Please also try removing TestCafe Browser Tools from the list. Use the "minus" button to remove the item and then run a test that takes a screenshot. macOS will request recording permissions and, once you confirm the request, it will grant them from scratch.

Ahh sorry, this should have been a StackOverflow question instead of a bug 🤦🏻 . Thanks for answering

Using the minus sign was very important. I do wish this tip were in the message that TestCafe logs to the console.

It looks like not every testcafe command will reset the permissions. I ran the following one and it worked testcafe chrome -q passCount=1. The thing to notice is that the command I was trying to run to trigger the reset did not work.

This did not work for me. I have tried removing with the minus sign. Any other suggestions? The permissions dialog just keeps popping up every time 😱
MAC OS - Big Sur 11.6.1
Node v16.13.0
testcafe v1.17.1
Testcafe was working fine on one project. This problem appeared when I added testcafe to a brand new project on the same computer.

Solved it.
it happens when you grant permission to the globally installed testcafe, instead of the one installed in your node_modules.
You can grant permissions to the testcafe under:
node_modules/testcafe-browser-tools/bin/mac/TestCafe Browser Tools.app
it fixed it for me.


on 'subscribe' event

Hi there
Quick question for yall
is there an on('subscribe') event?
or should I do this instead?
var EE = require('events');
var ee = new EE();

var sub = new Redis();

sub.subscribe('xyz',function(err){
     if(err){
           ee.emit('error', {});
       }
      else{
           ee.emit('subscribe','xyz');
    }
});

The callback of subscribe command is invoked when all channels are subscribed successfully. ioredis won't emit subscribe event, so your code seems to be a solution.

humma, it seems like an on('subscribe') event would be useful to have in the library itself...am I missing something?

Yes, that makes sense.

ok thanks for understanding, I look forward to the feature and let me know if you wish for me to make a PR

any update on this one? thanks for your help

A little busy these days, will get time to implement it this weekend. Pull request is welcome before that.

for sure, will give it a shot
On Jan 25, 2016 7:17 PM, "Zihua Li"<EMAIL_ADDRESS>wrote:

A little busy these days, will get time to implement it this weekend. Pull
request is welcome before that.
—
Reply to this email directly or view it on GitHub
https://github.com/luin/ioredis/issues/232#issuecomment-174796667.


--segment error for both models

Both PRs for lesion segmentation (#11) and spinal cord segmentation (#19) list the steps to be taken to use / reproduce the models in the main comment. All steps until the last step work succesfully. However, the last step, segmenting the entire dataset with --segment, fails for both with different errors.
After following all of the steps laid out for spinal cord segmentation, running --segment yields
(um_main) uzmac@romane:~/test/model_seg_ms_mp2rage$ ivadomed --segment -c config/seg_sc.json
2021-12-21 08:34:43.639 | INFO     | ivadomed.utils:init_ivadomed:408 -
ivadomed (git-master-93ba03df76d229d8a190c694f757da6c00efa545*)

2021-12-21 08:34:43.641 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-21 08:34:43.641 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     log_file: log
2021-12-21 08:34:43.641 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     loader_parameters: is_input_dropout: False
2021-12-21 08:34:43.641 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     split_dataset: split_method: participant_id
2021-12-21 08:34:43.641 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     split_dataset: data_testing: {'data_type': None, 'data_value': []}
2021-12-21 08:34:43.641 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-21 08:34:43.641 | INFO     | ivadomed.utils:get_path_output:371 - CLI flag --path-output not used to specify output directory. Will check config file for dir
ectory...
2021-12-21 08:34:43.641 | INFO     | ivadomed.utils:get_path_data:383 - CLI flag --path-data not used to specify BIDS data directory. Will check config file for dire
ctory...
2021-12-21 08:34:43.641 | INFO     | ivadomed.main:set_output_path:207 - Output path already exists: seg_sc_output
2021-12-21 08:34:43.799 | INFO     | ivadomed.utils:define_device:129 - Cuda is not available.
2021-12-21 08:34:43.799 | INFO     | ivadomed.utils:define_device:130 - Working on cpu.
2021-12-21 08:34:43.799 | INFO     | ivadomed.utils:display_selected_model_spec:145 - Selected architecture: Modified3DUNet, with the following parameters:
2021-12-21 08:34:43.799 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   dropout_rate: 0.3
2021-12-21 08:34:43.799 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   bn_momentum: 0.1
2021-12-21 08:34:43.800 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   depth: 4
2021-12-21 08:34:43.800 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   is_2d: False
2021-12-21 08:34:43.800 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   final_activation: sigmoid
2021-12-21 08:34:43.800 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   folder_name: seg_sc_model
2021-12-21 08:34:43.800 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   applied: True
2021-12-21 08:34:43.800 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   length_3D: [256, 256, 256]
2021-12-21 08:34:43.800 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   stride_3D: [256, 256, 256]
2021-12-21 08:34:43.800 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   attention: False
2021-12-21 08:34:43.800 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   n_filters: 8
2021-12-21 08:34:43.800 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   in_channel: 1
2021-12-21 08:34:43.800 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   out_channel: 1
2021-12-21 08:34:44.148 | INFO     | ivadomed.loader.bids_dataframe:save:289 - Dataframe has been saved in seg_sc_output/bids_dataframe.csv.
Traceback (most recent call last):
  File "/home/GRAMES.POLYMTL.CA/uzmac/.local/bin/ivadomed", line 11, in <module>
    load_entry_point('ivadomed', 'console_scripts', 'ivadomed')()
  File "/home/GRAMES.POLYMTL.CA/uzmac/ivadomed/ivadomed/main.py", line 589, in run_main
    run_command(context=context,
  File "/home/GRAMES.POLYMTL.CA/uzmac/ivadomed/ivadomed/main.py", line 362, in run_command
    run_segment_command(context, model_params)
  File "/home/GRAMES.POLYMTL.CA/uzmac/ivadomed/ivadomed/main.py", line 289, in run_segment_command
    pred_list, target_list = imed_inference.segment_volume(str(path_model),
  File "/home/GRAMES.POLYMTL.CA/uzmac/ivadomed/ivadomed/inference.py", line 368, in segment_volume
    fname_model, fname_model_metadata = imed_models.get_model_filenames(folder_model)
  File "/home/GRAMES.POLYMTL.CA/uzmac/ivadomed/ivadomed/models.py", line 1506, in get_model_filenames
    raise FileNotFoundError(fname_model)
FileNotFoundError: seg_sc_output/seg_sc_model/seg_sc_model.pt

After following all of the steps laid out for lesion segmentation, running --segment yields
(um_main) uzmac@romane:~/test/model_seg_ms_mp2rage$ ivadomed --segment -c config/seg_lesion.json
2021-12-21 08:36:19.382 | INFO     | ivadomed.utils:init_ivadomed:408 -
ivadomed (git-master-93ba03df76d229d8a190c694f757da6c00efa545*)

2021-12-21 08:36:19.384 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-21 08:36:19.384 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     log_file: log
2021-12-21 08:36:19.384 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     loader_parameters: is_input_dropout: False
2021-12-21 08:36:19.384 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     split_dataset: split_method: participant_id
2021-12-21 08:36:19.384 | INFO     | ivadomed.config_manager:deep_dict_compare:44 -     split_dataset: data_testing: {'data_type': None, 'data_value': []}
2021-12-21 08:36:19.384 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-21 08:36:19.384 | INFO     | ivadomed.utils:get_path_output:371 - CLI flag --path-output not used to specify output directory. Will check config file for directory...
2021-12-21 08:36:19.384 | INFO     | ivadomed.utils:get_path_data:383 - CLI flag --path-data not used to specify BIDS data directory. Will check config file for directory...
2021-12-21 08:36:19.384 | INFO     | ivadomed.main:set_output_path:207 - Output path already exists: seg_lesion_output
2021-12-21 08:36:19.558 | INFO     | ivadomed.utils:define_device:129 - Cuda is not available.
2021-12-21 08:36:19.558 | INFO     | ivadomed.utils:define_device:130 - Working on cpu.
2021-12-21 08:36:19.558 | INFO     | ivadomed.utils:display_selected_model_spec:145 - Selected architecture: Modified3DUNet, with the following parameters:
2021-12-21 08:36:19.559 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   dropout_rate: 0.3
2021-12-21 08:36:19.559 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   bn_momentum: 0.1
2021-12-21 08:36:19.559 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   depth: 4
2021-12-21 08:36:19.559 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   is_2d: False
2021-12-21 08:36:19.559 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   final_activation: sigmoid
2021-12-21 08:36:19.559 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   folder_name: seg_lesion_model
2021-12-21 08:36:19.559 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   applied: True
2021-12-21 08:36:19.559 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   length_3D: [32, 64, 128]
2021-12-21 08:36:19.559 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   stride_3D: [32, 64, 128]
2021-12-21 08:36:19.559 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   attention: False
2021-12-21 08:36:19.559 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   n_filters: 8
2021-12-21 08:36:19.559 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   in_channel: 1
2021-12-21 08:36:19.560 | INFO     | ivadomed.utils:display_selected_model_spec:148 -   out_channel: 1
2021-12-21 08:36:19.919 | INFO     | ivadomed.loader.bids_dataframe:save:289 - Dataframe has been saved in seg_lesion_output/bids_dataframe.csv.
2021-12-21 08:36:19.921 | INFO     | ivadomed.config_manager:_display_differing_keys:153 - Adding the following keys to the configuration file
2021-12-21 08:36:19.922 | INFO     | ivadomed.config_manager:_display_differing_keys:155 -

2021-12-21 08:36:19.922 | WARNING  | ivadomed.inference:segment_volume:402 - fname_roi has not been specified, then the entire volume is processed.
2021-12-21 08:36:19.943 | INFO     | ivadomed.inference:segment_volume:435 - Loaded 1 axial volumes of shape [32, 64, 128].
2021-12-21 08:36:19.952 | INFO     | ivadomed.utils:define_device:129 - Cuda is not available.
2021-12-21 08:36:19.952 | INFO     | ivadomed.utils:define_device:130 - Working on cpu.
2021-12-21 08:36:19.952 | DEBUG    | ivadomed.inference:get_preds:88 - Likely ONNX model detected at: seg_lesion_output/seg_lesion_model/seg_lesion_model.onnx
2021-12-21 08:36:19.952 | DEBUG    | ivadomed.inference:get_preds:89 - Conduct ONNX model inference...
2021-12-21 08:36:20.098 | DEBUG    | ivadomed.inference:get_preds:92 - Sending predictions to CPU
Traceback (most recent call last):
  File "/home/GRAMES.POLYMTL.CA/uzmac/.local/bin/ivadomed", line 11, in <module>
    load_entry_point('ivadomed', 'console_scripts', 'ivadomed')()
  File "/home/GRAMES.POLYMTL.CA/uzmac/ivadomed/ivadomed/main.py", line 589, in run_main
    run_command(context=context,
  File "/home/GRAMES.POLYMTL.CA/uzmac/ivadomed/ivadomed/main.py", line 362, in run_command
    run_segment_command(context, model_params)
  File "/home/GRAMES.POLYMTL.CA/uzmac/ivadomed/ivadomed/main.py", line 298, in run_segment_command
    filename = subject.split('.')[0] + target + "_pred" + ".nii.gz"
TypeError: can only concatenate str (not "list") to str
(um_main) uzmac@romane:~/test/model_seg_ms_mp2rage$

[x] Find a fix for --segment with spinal cord segmentation.

see this comment

[x] Find a fix for --segment with lesion segmentation.

see this PR

Hi @uzaymacar!
Do you have multiple raters? If yes, the second error looks a lot like a known issue here: https://github.com/ivadomed/ivadomed/issues/816

Hey @mariehbourget, yes we have multiple raters. Thanks for your help, this is great! I can take a look at this issue as well since I think it is critical for this project (as we will deploy the model).

I realized that the FileNotFoundError: seg_sc_output/seg_sc_model/seg_sc_model.pt error for spinal cord (SC) segmentation was because I prematuraly ended the training with CTRL+C. It seems that when an ivadomed training prematuraly ends, <PATH_OUTPUT>/<MODEL_NAME>/ (e.g. seg_sc_output/seg_sc_model/ here) directory only contains the <MODEL_NAME>.json (e.g. seg_sc_model.json here) but NOT the <MODEL_NAME>.onnx (e.g. seg_sc_model.onnx). When this .onnx file is not present, --test works w/o a problem BUT --segment fails as we see in this issue.
Therefore, the issue with --segment for SC segmentation is independent from the issue of --segment with multiple raters failing. For SC we only have one GT, and the FileNotFoundError: seg_sc_output/seg_sc_model/seg_sc_model.pt error was solved when I trained the model to the end (i.e. either when num_epochs is reached or when early stopping occurs).

When this .onnx file is not present, --test works w/o a problem BUT --segment fails as we see in this issue.
Therefore, the issue with --segment for SC segmentation is independent from the issue of --segment with multiple raters failing. For SC we only have one GT, and the FileNotFoundError: seg_sc_output/seg_sc_model/seg_sc_model.pt error was solved when I trained the model to the end (i.e. either when num_epochs is reached or when early stopping occurs).

Hi @uzaymacar!
That makes a lot of sense. --test uses the the best_model.pt file directly in path_output. For --segment, an alternative with an incomplete training is to copy the best_model.pt file to the model_name folder and rename it to match the json file (here seg_sc_output/seg_sc_model/seg_sc_model.pt).
Somewhat related is this issue that describes both type of model (onnx and pt) behaviors.

Thanks @mariehbourget, that is very useful explanation and info as always 🙂. I like that we are finding problems in this project that are related to open issues in ivadomed; it gives us a chance to re-activate these issues! I will try to read the issue you linked and see if I have something to add.

Closing this issue as this comment fixes the --segment error for SC segmentation and PR #1043 in ivadomed fixes the --segment error for lesion segmentation.


Fix create view operation

Description
CREATE VIEW <> is failing with spark.
Fixes # (issue)
add support of catalog properties for view.
Type of change
Please delete options that are not relevant.

[*] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Tested with unit tests.

Thanks @nk1506 for the fix. Thanks @ebyhr @eric-maynard @RussellSpitzer for the review.