mission_raw example.

Has anyone used mission_raw in Python to upload parsed mission items that might have an example to share?
Thanks!

thanks @julianoes for adding the proper label. Do you know if anyone has actually implemented mission_raw in Python? I saw your post about it being available in all languages, but I understand it's relatively new and untested. We're trying to implement a basic mission with mission_item code below, but upon upload, we get a param error indicating one of the parameters is incorrect. If this function is known unsupported, we'll look for an alternate route and abandon mission_raw, but it would be great to be able to issue MAVLink commands.
Thanks for your inputs!

Any updates on this? I am also looking to use the raw command to perform the MAV_CMD_DO_ORBIT. All attempts at mission uploads result in 'INVALID_ARGUMENT' being returned. One item to note is that for params 5 and 6 on the orbit command it states that NaN will use the current position center. These parameters however are both int32_t's which causes an error.
Thanks for any help I can get!

Any updates on this? I am also looking to use the raw command to perform the MAV_CMD_DO_ORBIT. All attempts at mission uploads result in 'INVALID_ARGUMENT' being returned. One item to note is that for params 5 and 6 on the orbit command it states that NaN will use the current position center. These parameters however are both int32_t's which causes an error.
Thanks for any help I can get!

We were forced to go back to Dronekit. MAVSDK has VERY limited functionality and is riddled with bugs. We wasted a lot of time trying to update to the “better” platform. Hope they can get their act together. Would like to be using Python 3.x for other peripherals.
From: DoppleGangster<EMAIL_ADDRESS>Reply-To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Date: Tuesday, January 12, 2021 at 12:56 PM
To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Cc: paul caskey<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [mavlink/MAVSDK-Python] mission_raw example. (#237)
Any updates on this? I am also looking to use the raw command to perform the MAV_CMD_DO_ORBIT. All attempts at mission uploads result in 'INVALID_ARGUMENT' being returned. One item to note is that for params 5 and 6 on the orbit command it states that NaN will use the current position center. These parameters however are both int32_t's which causes an error.
Thanks for any help I can get!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/mavlink/MAVSDK-Python/issues/237#issuecomment-758832701, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFBUHSPVSXNK7TJ7I37AR5DSZSEMDANCNFSM4PIG7PVA.

We were forced to go back to Dronekit. MAVSDK has VERY limited functionality and is riddled with bugs. We wasted a lot of time trying to update to the “better” platform. Hope they can get their act together. Would like to be using Python 3.x for other peripherals.
From: DoppleGangster<EMAIL_ADDRESS>Reply-To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Date: Tuesday, January 12, 2021 at 12:56 PM
To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Cc: paul caskey<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [mavlink/MAVSDK-Python] mission_raw example. (#237)
Any updates on this? I am also looking to use the raw command to perform the MAV_CMD_DO_ORBIT. All attempts at mission uploads result in 'INVALID_ARGUMENT' being returned. One item to note is that for params 5 and 6 on the orbit command it states that NaN will use the current position center. These parameters however are both int32_t's which causes an error.
Thanks for any help I can get!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/mavlink/MAVSDK-Python/issues/237#issuecomment-758832701, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFBUHSPVSXNK7TJ7I37AR5DSZSEMDANCNFSM4PIG7PVA.

MAVSDK has VERY limited functionality and is riddled with bugs. We wasted a lot of time trying to update to the “better” platform. Hope they can get their act together.

@moonmotor: Thanks for the constructive feedback, it always feels heartwarming after spending so much free time (on top of the consequent investment from our employers) on an open source project :blush:!
I hope that the reason why I cannot find or remember bug reports (or any kind of contribution) from you is not because of the atmosphere we create around the project. I can ensure you that we do our best to be welcoming and to support users and contributors, even when it involves spending evenings and weekend (in our free time) for that. And I am sorry to read that you wasted time because of our free work, it was not our intention.
If, by any chance, you remember a few of those many bugs and can afford wasting a bit more time sharing them (in a reproducible way), I'm sure we will be happy to have a look, share ideas about how to fix them, and possibly even spend a Saturday afternoon doing it for you (though sometimes we ask those who report bugs to test our fixes, I hope that's fine).

MAVSDK has VERY limited functionality and is riddled with bugs. We wasted a lot of time trying to update to the “better” platform. Hope they can get their act together.

@moonmotor: Thanks for the constructive feedback, it always feels heartwarming after spending so much free time (on top of the consequent investment from our employers) on an open source project :blush:!
I hope that the reason why I cannot find or remember bug reports (or any kind of contribution) from you is not because of the atmosphere we create around the project. I can ensure you that we do our best to be welcoming and to support users and contributors, even when it involves spending evenings and weekend (in our free time) for that. And I am sorry to read that you wasted time because of our free work, it was not our intention.
If, by any chance, you remember a few of those many bugs and can afford wasting a bit more time sharing them (in a reproducible way), I'm sure we will be happy to have a look, share ideas about how to fix them, and possibly even spend a Saturday afternoon doing it for you (though sometimes we ask those who report bugs to test our fixes, I hope that's fine).

@DoppleGangster: It's very difficult for me to say without having code to reproduce the issue. Would you mind opening a new issue (I don't feel like answering to this one anymore) with a meaningful title (maybe "MissionRaw upload results in 'INVALID_ARGUMENT"?), sharing your setup and a small script reproducing your error? That would help, I think :+1:.

@DoppleGangster: It's very difficult for me to say without having code to reproduce the issue. Would you mind opening a new issue (I don't feel like answering to this one anymore) with a meaningful title (maybe "MissionRaw upload results in 'INVALID_ARGUMENT"?), sharing your setup and a small script reproducing your error? That would help, I think :+1:.

It’s coming back to me now. We had the same problem and each argument has to be correct (obviously), but the documentation is not clear and even contrary as to what each argument should be. It took many man-days to get it right, but we did get it right after some time. I’ll check my notes and see if I can find it.
From: Jonas Vautherin<EMAIL_ADDRESS>Reply-To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Date: Tuesday, January 12, 2021 at 1:45 PM
To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Cc: paul caskey<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [mavlink/MAVSDK-Python] mission_raw example. (#237)
@DoppleGangsterhttps://github.com/DoppleGangster: It's very difficult for me to say without having code to reproduce the issue. Would you mind opening a new issue (I don't feel like answering to this one anymore) with a meaningful title (maybe "MissionRaw upload results in 'INVALID_ARGUMENT"?), sharing your setup and a small script reproducing your error? That would help, I think 👍.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/mavlink/MAVSDK-Python/issues/237#issuecomment-758860581, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFBUHSIA6PGFMTOFAPE373TSZSKEPANCNFSM4PIG7PVA.

It’s coming back to me now. We had the same problem and each argument has to be correct (obviously), but the documentation is not clear and even contrary as to what each argument should be. It took many man-days to get it right, but we did get it right after some time. I’ll check my notes and see if I can find it.
From: Jonas Vautherin<EMAIL_ADDRESS>Reply-To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Date: Tuesday, January 12, 2021 at 1:45 PM
To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Cc: paul caskey<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [mavlink/MAVSDK-Python] mission_raw example. (#237)
@DoppleGangsterhttps://github.com/DoppleGangster: It's very difficult for me to say without having code to reproduce the issue. Would you mind opening a new issue (I don't feel like answering to this one anymore) with a meaningful title (maybe "MissionRaw upload results in 'INVALID_ARGUMENT"?), sharing your setup and a small script reproducing your error? That would help, I think 👍.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/mavlink/MAVSDK-Python/issues/237#issuecomment-758860581, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFBUHSIA6PGFMTOFAPE373TSZSKEPANCNFSM4PIG7PVA.

I changed my constants to include decimal places where the values required floats. This changed the error to unsupported.
Looks like I'll be writing my own orbit code.
Thanks for the responses!

I changed my constants to include decimal places where the values required floats. This changed the error to unsupported.
Looks like I'll be writing my own orbit code.
Thanks for the responses!

but the documentation is not clear and even contrary as to what each argument should be

So the documentation says:
    """
     Mission item exactly identical to MAVLink MISSION_ITEM_INT.
     Parameters
     ----------
     seq : uint32_t
          Sequence (uint16_t)
     frame : uint32_t
          The coordinate system of the waypoint (actually uint8_t)
     command : uint32_t
          The scheduled action for the waypoint (actually uint16_t)
     current : uint32_t
          false:0, true:1 (actually uint8_t)
     autocontinue : uint32_t
          Autocontinue to next waypoint (actually uint8_t)
     param1 : float
          PARAM1, see MAV_CMD enum
     param2 : float
          PARAM2, see MAV_CMD enum
     param3 : float
          PARAM3, see MAV_CMD enum
     param4 : float
          PARAM4, see MAV_CMD enum
     x : int32_t
          PARAM5 / local: x position in meters * 1e4, global: latitude in degrees * 10^7
     y : int32_t
          PARAM6 / y position: local: x position in meters * 1e4, global: longitude in degrees *10^7
     z : float
          PARAM7 / local: Z coordinate, global: altitude (relative or absolute, depending on frame)
     mission_type : uint32_t
          @brief Mission type (actually uint8_t)
     """

To me that's a one-to-one relationship with the MAVLink message MISSION_ITEM_INT.
Are you saying that you were using the correct arguments (i.e. generating a valid MAVLink message), but that MAVSDK was failing because of some bug, or are you saying that you had trouble figuring out how to actually use the MAVLink message?
In the former case, an idea would have been to share the failing code, such that we could have fixed the bug (that's how a community works: you get the work of others for free, and when you find a bug, you help reproducing it). In the latter case, maybe we should make it clearer in the documentation that the mission_raw plugin, just like mavlink_passthrough, is a lower-level abstraction made for more advanced users... Would it have saved you from trying it? The mission plugin is indeed more limited, but has a higher-level abstraction, which is convenient when you can't handle the MAVLink messages directly.

but the documentation is not clear and even contrary as to what each argument should be

So the documentation says:
    """
     Mission item exactly identical to MAVLink MISSION_ITEM_INT.
     Parameters
     ----------
     seq : uint32_t
          Sequence (uint16_t)
     frame : uint32_t
          The coordinate system of the waypoint (actually uint8_t)
     command : uint32_t
          The scheduled action for the waypoint (actually uint16_t)
     current : uint32_t
          false:0, true:1 (actually uint8_t)
     autocontinue : uint32_t
          Autocontinue to next waypoint (actually uint8_t)
     param1 : float
          PARAM1, see MAV_CMD enum
     param2 : float
          PARAM2, see MAV_CMD enum
     param3 : float
          PARAM3, see MAV_CMD enum
     param4 : float
          PARAM4, see MAV_CMD enum
     x : int32_t
          PARAM5 / local: x position in meters * 1e4, global: latitude in degrees * 10^7
     y : int32_t
          PARAM6 / y position: local: x position in meters * 1e4, global: longitude in degrees *10^7
     z : float
          PARAM7 / local: Z coordinate, global: altitude (relative or absolute, depending on frame)
     mission_type : uint32_t
          @brief Mission type (actually uint8_t)
     """

To me that's a one-to-one relationship with the MAVLink message MISSION_ITEM_INT.
Are you saying that you were using the correct arguments (i.e. generating a valid MAVLink message), but that MAVSDK was failing because of some bug, or are you saying that you had trouble figuring out how to actually use the MAVLink message?
In the former case, an idea would have been to share the failing code, such that we could have fixed the bug (that's how a community works: you get the work of others for free, and when you find a bug, you help reproducing it). In the latter case, maybe we should make it clearer in the documentation that the mission_raw plugin, just like mavlink_passthrough, is a lower-level abstraction made for more advanced users... Would it have saved you from trying it? The mission plugin is indeed more limited, but has a higher-level abstraction, which is convenient when you can't handle the MAVLink messages directly.

Thanks for telling me how a community works – I was unclear about that. I posted several things with no response. You also keep referring to the firmware as “free”. Anything that takes dozens of man-hours to make work isn’t free in my opinion. The MAVADK website touts it as the greatest new API for Mavlink, used in “hundreds of enterprise applications” (or something to that effect), and that’s a load of crap. We couldn’t even connect to the drone using your documentation. By pure trial and error, we found we needed to add a triple slash to the USB port connection string. That was the first bug we found after dozens of wasted hours. That begs the question: who are these hundreds of companies using MAVSDK if nobody has even been able to connect over USB telemetry? It’s one thing to say we’re a group of guys trying to write an API, it’s another to pretend you’re a sophisticated group with a working API.
Whatever – keep your little comments to yourself. I’ll try to DG because it sounds like he’s gonna keep struggling with MAVPOS.
From: Jonas Vautherin<EMAIL_ADDRESS>Reply-To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Date: Wednesday, January 13, 2021 at 2:07 AM
To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Cc: paul caskey<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [mavlink/MAVSDK-Python] mission_raw example. (#237)
but the documentation is not clear and even contrary as to what each argument should be
So the documentationhttps://github.com/mavlink/MAVSDK-Python/blob/main/mavsdk/mission_raw.py#L84-L128 says:
"""

 Mission item exactly identical to MAVLink MISSION_ITEM_INT.

 Parameters

 ----------

 seq : uint32_t

      Sequence (uint16_t)

 frame : uint32_t

      The coordinate system of the waypoint (actually uint8_t)

 command : uint32_t

      The scheduled action for the waypoint (actually uint16_t)

 current : uint32_t

      false:0, true:1 (actually uint8_t)

 autocontinue : uint32_t

      Autocontinue to next waypoint (actually uint8_t)

 param1 : float

      PARAM1, see MAV_CMD enum

 param2 : float

      PARAM2, see MAV_CMD enum

 param3 : float

      PARAM3, see MAV_CMD enum

 param4 : float

      PARAM4, see MAV_CMD enum

 x : int32_t

      PARAM5 / local: x position in meters * 1e4, global: latitude in degrees * 10^7

 y : int32_t

      PARAM6 / y position: local: x position in meters * 1e4, global: longitude in degrees *10^7

 z : float

      PARAM7 / local: Z coordinate, global: altitude (relative or absolute, depending on frame)

 mission_type : uint32_t

      @brief Mission type (actually uint8_t)

 """

To me that's a one-to-one relationship with the MAVLink message MISSION_ITEM_INThttp://mavlink.io/en/messages/common.html#MISSION_ITEM_INT.
Are you saying that you were using the correct arguments (i.e. generating a valid MAVLink message), but that MAVSDK was failing because of some bug, or are you saying that you had trouble figuring out how to actually use the MAVLink message?
In the former case, an idea would have been to share the failing code, such that we could have fixed the bug (that's how a community works: you get the work of others for free, and when you find a bug, you help reproducing it). In the latter case, maybe we should make it clearer in the documentation that the mission_raw plugin, just like mavlink_passthrough, is a lower-level abstraction made for more advanced users... Would it have saved you from trying it? The mission plugin is indeed more limited, but has a higher-level abstraction, which is convenient when you can't handle the MAVLink messages directly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/mavlink/MAVSDK-Python/issues/237#issuecomment-759252301, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFBUHSM43KYSPO6BBSTHPNLSZVBC5ANCNFSM4PIG7PVA.

Thanks for telling me how a community works – I was unclear about that. I posted several things with no response. You also keep referring to the firmware as “free”. Anything that takes dozens of man-hours to make work isn’t free in my opinion. The MAVADK website touts it as the greatest new API for Mavlink, used in “hundreds of enterprise applications” (or something to that effect), and that’s a load of crap. We couldn’t even connect to the drone using your documentation. By pure trial and error, we found we needed to add a triple slash to the USB port connection string. That was the first bug we found after dozens of wasted hours. That begs the question: who are these hundreds of companies using MAVSDK if nobody has even been able to connect over USB telemetry? It’s one thing to say we’re a group of guys trying to write an API, it’s another to pretend you’re a sophisticated group with a working API.
Whatever – keep your little comments to yourself. I’ll try to DG because it sounds like he’s gonna keep struggling with MAVPOS.
From: Jonas Vautherin<EMAIL_ADDRESS>Reply-To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Date: Wednesday, January 13, 2021 at 2:07 AM
To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Cc: paul caskey<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [mavlink/MAVSDK-Python] mission_raw example. (#237)
but the documentation is not clear and even contrary as to what each argument should be
So the documentationhttps://github.com/mavlink/MAVSDK-Python/blob/main/mavsdk/mission_raw.py#L84-L128 says:
"""

 Mission item exactly identical to MAVLink MISSION_ITEM_INT.

 Parameters

 ----------

 seq : uint32_t

      Sequence (uint16_t)

 frame : uint32_t

      The coordinate system of the waypoint (actually uint8_t)

 command : uint32_t

      The scheduled action for the waypoint (actually uint16_t)

 current : uint32_t

      false:0, true:1 (actually uint8_t)

 autocontinue : uint32_t

      Autocontinue to next waypoint (actually uint8_t)

 param1 : float

      PARAM1, see MAV_CMD enum

 param2 : float

      PARAM2, see MAV_CMD enum

 param3 : float

      PARAM3, see MAV_CMD enum

 param4 : float

      PARAM4, see MAV_CMD enum

 x : int32_t

      PARAM5 / local: x position in meters * 1e4, global: latitude in degrees * 10^7

 y : int32_t

      PARAM6 / y position: local: x position in meters * 1e4, global: longitude in degrees *10^7

 z : float

      PARAM7 / local: Z coordinate, global: altitude (relative or absolute, depending on frame)

 mission_type : uint32_t

      @brief Mission type (actually uint8_t)

 """

To me that's a one-to-one relationship with the MAVLink message MISSION_ITEM_INThttp://mavlink.io/en/messages/common.html#MISSION_ITEM_INT.
Are you saying that you were using the correct arguments (i.e. generating a valid MAVLink message), but that MAVSDK was failing because of some bug, or are you saying that you had trouble figuring out how to actually use the MAVLink message?
In the former case, an idea would have been to share the failing code, such that we could have fixed the bug (that's how a community works: you get the work of others for free, and when you find a bug, you help reproducing it). In the latter case, maybe we should make it clearer in the documentation that the mission_raw plugin, just like mavlink_passthrough, is a lower-level abstraction made for more advanced users... Would it have saved you from trying it? The mission plugin is indeed more limited, but has a higher-level abstraction, which is convenient when you can't handle the MAVLink messages directly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/mavlink/MAVSDK-Python/issues/237#issuecomment-759252301, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFBUHSM43KYSPO6BBSTHPNLSZVBC5ANCNFSM4PIG7PVA.

Digging trough my old notes now. I think I got so frustrated with MAVPOS that I threw my notebook away, but I’ll keep looking through emails and trying to remember what the problem was. I remember one problem was that sequence could not start with zero – had to start at 1. But I’ll send what I can find.
From: DoppleGangster<EMAIL_ADDRESS>Reply-To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Date: Tuesday, January 12, 2021 at 9:34 PM
To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Cc: paul caskey<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [mavlink/MAVSDK-Python] mission_raw example. (#237)
I changed my constants to include decimal places where the values required floats. This changed the error to unsupported.
Looks like I'll be writing my own orbit code.
Thanks for the responses!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/mavlink/MAVSDK-Python/issues/237#issuecomment-759163938, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFBUHSMYDJUFURJKVEUMFI3SZUBDJANCNFSM4PIG7PVA.

Digging trough my old notes now. I think I got so frustrated with MAVPOS that I threw my notebook away, but I’ll keep looking through emails and trying to remember what the problem was. I remember one problem was that sequence could not start with zero – had to start at 1. But I’ll send what I can find.
From: DoppleGangster<EMAIL_ADDRESS>Reply-To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Date: Tuesday, January 12, 2021 at 9:34 PM
To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Cc: paul caskey<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [mavlink/MAVSDK-Python] mission_raw example. (#237)
I changed my constants to include decimal places where the values required floats. This changed the error to unsupported.
Looks like I'll be writing my own orbit code.
Thanks for the responses!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/mavlink/MAVSDK-Python/issues/237#issuecomment-759163938, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFBUHSMYDJUFURJKVEUMFI3SZUBDJANCNFSM4PIG7PVA.

OK, DG I think this is an upload that worked.
Not sure if seq can start with zero or has to be 1. Param4 has to be floast(nan) and for some really odd reason the cords have to be nine-digit integers.
Hope this helps. MM
(MissionItem(
1,                     #seq
6,                      #frame
16,                     #command
0,                      #current
1,                      #autocontinue
0,                     #param1
10,                      #param2
0,                      #param3
float('nan'),           #param4
402603986                #param5
-754579572,             #param6
20,                      #param7
0))                     #mission_type
From: DoppleGangster<EMAIL_ADDRESS>Sent: Tuesday, January 12, 2021 9:34 PM
To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Cc: Paul skyphilly.com<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [mavlink/MAVSDK-Python] mission_raw example. (#237)
I changed my constants to include decimal places where the values required floats. This changed the error to unsupported.
Looks like I'll be writing my own orbit code.
Thanks for the responses!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/mavlink/MAVSDK-Python/issues/237#issuecomment-759163938, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFBUHSMYDJUFURJKVEUMFI3SZUBDJANCNFSM4PIG7PVA.

OK, DG I think this is an upload that worked.
Not sure if seq can start with zero or has to be 1. Param4 has to be floast(nan) and for some really odd reason the cords have to be nine-digit integers.
Hope this helps. MM
(MissionItem(
1,                     #seq
6,                      #frame
16,                     #command
0,                      #current
1,                      #autocontinue
0,                     #param1
10,                      #param2
0,                      #param3
float('nan'),           #param4
402603986                #param5
-754579572,             #param6
20,                      #param7
0))                     #mission_type
From: DoppleGangster<EMAIL_ADDRESS>Sent: Tuesday, January 12, 2021 9:34 PM
To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Cc: Paul skyphilly.com<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [mavlink/MAVSDK-Python] mission_raw example. (#237)
I changed my constants to include decimal places where the values required floats. This changed the error to unsupported.
Looks like I'll be writing my own orbit code.
Thanks for the responses!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/mavlink/MAVSDK-Python/issues/237#issuecomment-759163938, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFBUHSMYDJUFURJKVEUMFI3SZUBDJANCNFSM4PIG7PVA.

By pure trial and error, we found we needed to add a triple slash to the USB port connection string. That was the first bug we found after dozens of wasted hours.

I'm assuming that the documentation of System.connect() is not clear enough:
        system_address: str
            The address of the remote system. If None, it will
            default to udp://:14540. Supported URL formats:
                - Serial: serial:///path/to/serial/dev[:baudrate]
                - UDP: udp://[bind_host][:bind_port]
                - TCP: tcp://[server_host][:server_port]

Or did you start mavsdk_server manually?
% ./mavsdk_server -h
Usage: ./mavsdk_server [-h | --help]
       ./mavsdk_server [-p mavsdk_server_port] [Connection URL]

Connection URL format should be:
  Serial: serial:///path/to/serial/dev[:baudrate]
  UDP:    udp://[bind_host][:bind_port]
  TCP:    tcp://[server_host][:server_port]

But that's not exactly a bug, rather a documentation issue. Would you have suggestions about improving that?

That begs the question: who are these hundreds of companies using MAVSDK if nobody has even been able to connect over USB telemetry?

I think that those who fail to connect generally ask us after a few minutes, either on GitHub or on Slack. That's the kind of error we spot in seconds. Again, sorry if we failed to answer in that case.

I remember one problem was that sequence could not start with zero – had to start at 1.

You mean for the mission items? There is a difference in the MAVLink implementation between Ardupilot and PX4, I think. That's one of the issues of the mission_raw plugin unfortunately: you have to figure out the MAVLink implementation before using it. The mission plugin abstracts that away. Again, not a bug, rather a low-level protocol definition (MAVSDK has nothing to do with that).

for some really odd reason the cords have to be nine-digit integers.

Protocol definition, again, see here. The mission plugin abstracts this away, again:
     Parameters
     ----------
     latitude_deg : double
          Latitude in degrees (range: -90 to +90)
     longitude_deg : double
          Longitude in degrees (range: -180 to +180)

I’ll try to help DG because it sounds like he’s gonna keep struggling with MAVPOS.

@DoppleGangster opened an issue here, that's the place for further answers on that regard.
I don't think we'll get anything constructive out of this thread, let me close it. If you have suggestions regarding how we could fix those documentation bugs you mentioned, by all means, please open issues or PRs :pray:. Note that the documentation is generated from the proto files here. If that's unclear, feel free to describe your proposed changes in an issue, and we can create the corresponding pull requests.

By pure trial and error, we found we needed to add a triple slash to the USB port connection string. That was the first bug we found after dozens of wasted hours.

I'm assuming that the documentation of System.connect() is not clear enough:
        system_address: str
            The address of the remote system. If None, it will
            default to udp://:14540. Supported URL formats:
                - Serial: serial:///path/to/serial/dev[:baudrate]
                - UDP: udp://[bind_host][:bind_port]
                - TCP: tcp://[server_host][:server_port]

Or did you start mavsdk_server manually?
% ./mavsdk_server -h
Usage: ./mavsdk_server [-h | --help]
       ./mavsdk_server [-p mavsdk_server_port] [Connection URL]

Connection URL format should be:
  Serial: serial:///path/to/serial/dev[:baudrate]
  UDP:    udp://[bind_host][:bind_port]
  TCP:    tcp://[server_host][:server_port]

But that's not exactly a bug, rather a documentation issue. Would you have suggestions about improving that?

That begs the question: who are these hundreds of companies using MAVSDK if nobody has even been able to connect over USB telemetry?

I think that those who fail to connect generally ask us after a few minutes, either on GitHub or on Slack. That's the kind of error we spot in seconds. Again, sorry if we failed to answer in that case.

I remember one problem was that sequence could not start with zero – had to start at 1.

You mean for the mission items? There is a difference in the MAVLink implementation between Ardupilot and PX4, I think. That's one of the issues of the mission_raw plugin unfortunately: you have to figure out the MAVLink implementation before using it. The mission plugin abstracts that away. Again, not a bug, rather a low-level protocol definition (MAVSDK has nothing to do with that).

for some really odd reason the cords have to be nine-digit integers.

Protocol definition, again, see here. The mission plugin abstracts this away, again:
     Parameters
     ----------
     latitude_deg : double
          Latitude in degrees (range: -90 to +90)
     longitude_deg : double
          Longitude in degrees (range: -180 to +180)

I’ll try to help DG because it sounds like he’s gonna keep struggling with MAVPOS.

@DoppleGangster opened an issue here, that's the place for further answers on that regard.
I don't think we'll get anything constructive out of this thread, let me close it. If you have suggestions regarding how we could fix those documentation bugs you mentioned, by all means, please open issues or PRs :pray:. Note that the documentation is generated from the proto files here. If that's unclear, feel free to describe your proposed changes in an issue, and we can create the corresponding pull requests.

Uhhhh…who do you think found the serial:/// bug? I see you updated your documentation to reflect the bug I found. Good for you buddy boy!
From: Jonas Vautherin<EMAIL_ADDRESS>Reply-To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Date: Wednesday, January 13, 2021 at 11:26 AM
To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Cc: paul caskey<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [mavlink/MAVSDK-Python] mission_raw example. (#237)
By pure trial and error, we found we needed to add a triple slash to the USB port connection string. That was the first bug we found after dozens of wasted hours.
I'm assuming that the documentationhttps://github.com/mavlink/MAVSDK-Python/blob/main/mavsdk/system.py#L62-L68 of System.connect() is not clear enough:
    system_address: str

        The address of the remote system. If None, it will

        default to udp://:14540. Supported URL formats:

            - Serial: serial:///path/to/serial/dev[:baudrate]

            - UDP: udp://[bind_host][:bind_port]

            - TCP: tcp://[server_host][:server_port]

Or did you start mavsdk_server manually?
% ./mavsdk_server -h
Usage: ./mavsdk_server [-h | --help]
   ./mavsdk_server [-p mavsdk_server_port] [Connection URL]

Connection URL format should be:
Serial: serial:///path/to/serial/dev[:baudrate]
UDP:    udp://[bind_host][:bind_port]
TCP:    tcp://[server_host][:server_port]
But that's not exactly a bug, rather a documentation issue. Would you have suggestions about improving that?
That begs the question: who are these hundreds of companies using MAVSDK if nobody has even been able to connect over USB telemetry?
I think that those who fail to connect generally ask us after a few minutes, either on GitHub or on Slack. That's the kind of error we spot in seconds. Again, sorry if we failed to answer in that case.
I remember one problem was that sequence could not start with zero – had to start at 1.
You mean for the mission items? There is a difference in the MAVLink implementation between Ardupilot and PX4, I think. That's one of the issues of the mission_raw plugin unfortunately: you have to figure out the MAVLink implementation before using it. The mission plugin abstracts that away. Again, not a bug, rather a low-level protocol definition (MAVSDK has nothing to do with that).
for some really odd reason the cords have to be nine-digit integers.
Protocol definition, again, see herehttp://mavlink.io/en/messages/common.html#MISSION_ITEM_INT. The missionhttps://github.com/mavlink/MAVSDK-Python/blob/main/mavsdk/mission.py#L20-L24 plugin abstracts this away, again:
 Parameters

 ----------

 latitude_deg : double

      Latitude in degrees (range: -90 to +90)

 longitude_deg : double

      Longitude in degrees (range: -180 to +180)

I’ll try to help DG because it sounds like he’s gonna keep struggling with MAVPOS.
@DoppleGangsterhttps://github.com/DoppleGangster opened an issue herehttps://github.com/mavlink/MAVSDK-Python/issues/297, that's the place for further answers on that regard.
I don't think we'll get anything constructive out of this thread, let me close it. If you have suggestions regarding how we could fix those documentation bugs you mentioned, by all means, please open issues or PRs 🙏. Note that the documentation is generated from the proto files herehttps://github.com/mavlink/MAVSDK-Proto. If that's unclear, feel free to describe your proposed changes in an issue, and we can create the corresponding pull requests.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/mavlink/MAVSDK-Python/issues/237#issuecomment-759562999, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFBUHSKW4WWYGGVDVP6CFOTSZXCTDANCNFSM4PIG7PVA.

Uhhhh…who do you think found the serial:/// bug? I see you updated your documentation to reflect the bug I found. Good for you buddy boy!
From: Jonas Vautherin<EMAIL_ADDRESS>Reply-To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Date: Wednesday, January 13, 2021 at 11:26 AM
To: mavlink/MAVSDK-Python<EMAIL_ADDRESS>Cc: paul caskey<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [mavlink/MAVSDK-Python] mission_raw example. (#237)
By pure trial and error, we found we needed to add a triple slash to the USB port connection string. That was the first bug we found after dozens of wasted hours.
I'm assuming that the documentationhttps://github.com/mavlink/MAVSDK-Python/blob/main/mavsdk/system.py#L62-L68 of System.connect() is not clear enough:
    system_address: str

        The address of the remote system. If None, it will

        default to udp://:14540. Supported URL formats:

            - Serial: serial:///path/to/serial/dev[:baudrate]

            - UDP: udp://[bind_host][:bind_port]

            - TCP: tcp://[server_host][:server_port]

Or did you start mavsdk_server manually?
% ./mavsdk_server -h
Usage: ./mavsdk_server [-h | --help]
   ./mavsdk_server [-p mavsdk_server_port] [Connection URL]

Connection URL format should be:
Serial: serial:///path/to/serial/dev[:baudrate]
UDP:    udp://[bind_host][:bind_port]
TCP:    tcp://[server_host][:server_port]
But that's not exactly a bug, rather a documentation issue. Would you have suggestions about improving that?
That begs the question: who are these hundreds of companies using MAVSDK if nobody has even been able to connect over USB telemetry?
I think that those who fail to connect generally ask us after a few minutes, either on GitHub or on Slack. That's the kind of error we spot in seconds. Again, sorry if we failed to answer in that case.
I remember one problem was that sequence could not start with zero – had to start at 1.
You mean for the mission items? There is a difference in the MAVLink implementation between Ardupilot and PX4, I think. That's one of the issues of the mission_raw plugin unfortunately: you have to figure out the MAVLink implementation before using it. The mission plugin abstracts that away. Again, not a bug, rather a low-level protocol definition (MAVSDK has nothing to do with that).
for some really odd reason the cords have to be nine-digit integers.
Protocol definition, again, see herehttp://mavlink.io/en/messages/common.html#MISSION_ITEM_INT. The missionhttps://github.com/mavlink/MAVSDK-Python/blob/main/mavsdk/mission.py#L20-L24 plugin abstracts this away, again:
 Parameters

 ----------

 latitude_deg : double

      Latitude in degrees (range: -90 to +90)

 longitude_deg : double

      Longitude in degrees (range: -180 to +180)

I’ll try to help DG because it sounds like he’s gonna keep struggling with MAVPOS.
@DoppleGangsterhttps://github.com/DoppleGangster opened an issue herehttps://github.com/mavlink/MAVSDK-Python/issues/297, that's the place for further answers on that regard.
I don't think we'll get anything constructive out of this thread, let me close it. If you have suggestions regarding how we could fix those documentation bugs you mentioned, by all means, please open issues or PRs 🙏. Note that the documentation is generated from the proto files herehttps://github.com/mavlink/MAVSDK-Proto. If that's unclear, feel free to describe your proposed changes in an issue, and we can create the corresponding pull requests.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/mavlink/MAVSDK-Python/issues/237#issuecomment-759562999, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFBUHSKW4WWYGGVDVP6CFOTSZXCTDANCNFSM4PIG7PVA.


Long inputs with line breaks

I have a use-case where my input is a long string (a document) with line breaks. dsp.Template seems to remove the line breaks and swaps them for spaces. However, in my use case the line breaks do contain important information. I tried some quick fixes like replacing '\n' with '|' but the quality of the LM response went down significantly.
Any ideas how to deal with this with DSPy?

I found the answer to my question. The InputField has a format parameter which allows to pass a function to be applied on the input when generating the template.


Update title on Standings page

In the browser, when viewing the Standings page, the title in the tab is displayed as Document.
I would propose changing this to read Standings instead, and can contribute the fix towards this.

Hello !! I would like to work on this issue, can you pls assign it to me

Hey! I would love to work on this and get it done as fast as possible. Please assign the issue to me.


High Code Helper (Renderer) CPU Utilization

On macOS BigSur (11.1) running the current version of Visual Studio Code (1.52), if the StreamDeck is not connected to the Mac (M1 Air), the Code Helper (Renderer) process begins to idle at 95%. If you disable the Stream Deck for Visual Studio Code (v4.1.5) extension, the CPU for this process immediately drops to 0.

Hi,
My macOS VM doesn't boot anymore after a processor upgrade so could you profile the extension and send me the CPU profile?
Open the process explorer (Help -> Open Process Explorer) and look if the extension host is the one with high CPU usage.
Start extension profile:

Find "Stream Deck for Visual Studio Code" (right-click) -> Start Extension Host Profile.
Try using some of the extension features and let the profiler record the data.
Stop the profiler and save it.

Hi,
My macOS VM doesn't boot anymore after a processor upgrade so could you profile the extension and send me the CPU profile?
Open the process explorer (Help -> Open Process Explorer) and look if the extension host is the one with high CPU usage.
Start extension profile:

Find "Stream Deck for Visual Studio Code" (right-click) -> Start Extension Host Profile.
Try using some of the extension features and let the profiler record the data.
Stop the profiler and save it.

I noticed that the extension was getting errors. This might be related to my VSCode sync. My MacBook Pro is connected to the StreamDeck 99% of the time. My Air is where I am noticing this issue (have to see if the same thing happens with the Pro unconnected). VSCode settings sync added the extension to my AIr.

Issue Type: Bug
Extension Name: vscode-streamdeck
Extension Version: 4.1.5
OS Version: Darwin x64 20.2.0
VSCode version: 1.52.1

{
	"messages": [],
	"activationTimes": {
		"codeLoadingTime": 33,
		"activateCallTime": 15,
		"activateResolvedTime": 0,
		"activationReason": {
			"startup": false,
			"extensionId": {
				"value": "nicollasr.vscode-streamdeck",
				"_lower": "nicollasr.vscode-streamdeck"
			},
			"activationEvent": "*"
		}
	},
	"runtimeErrors": [
		{
			"name": "Error",
			"message": "WebSocket is not open: readyState 0 (CONNECTING)"
		},
		{
			"name": "Error",
			"message": "WebSocket is not open: readyState 0 (CONNECTING)"
		},
		{
			"name": "Error",
			"message": "WebSocket is not open: readyState 0 (CONNECTING)"
		}
	]
}

I noticed that the extension was getting errors. This might be related to my VSCode sync. My MacBook Pro is connected to the StreamDeck 99% of the time. My Air is where I am noticing this issue (have to see if the same thing happens with the Pro unconnected). VSCode settings sync added the extension to my AIr.

Issue Type: Bug
Extension Name: vscode-streamdeck
Extension Version: 4.1.5
OS Version: Darwin x64 20.2.0
VSCode version: 1.52.1

{
	"messages": [],
	"activationTimes": {
		"codeLoadingTime": 33,
		"activateCallTime": 15,
		"activateResolvedTime": 0,
		"activationReason": {
			"startup": false,
			"extensionId": {
				"value": "nicollasr.vscode-streamdeck",
				"_lower": "nicollasr.vscode-streamdeck"
			},
			"activationEvent": "*"
		}
	},
	"runtimeErrors": [
		{
			"name": "Error",
			"message": "WebSocket is not open: readyState 0 (CONNECTING)"
		},
		{
			"name": "Error",
			"message": "WebSocket is not open: readyState 0 (CONNECTING)"
		},
		{
			"name": "Error",
			"message": "WebSocket is not open: readyState 0 (CONNECTING)"
		}
	]
}

CPU-20210113T232845.493Z.cpuprofile.txt

CPU-20210113T232845.493Z.cpuprofile.txt

Thank you for sharing the CPU profile.
For some reason, it is losing the connection with the WebSocket server. Most of the time spent by the extension was reconnecting to the server.
Could you please share the extension output:

Is the Mac Air connected through WSL or SSH?

Are you using the default extension settings?

  "streamdeck.serverHost": "<IP_ADDRESS>",
  "streamdeck.serverPort": 48969

Thank you for sharing the CPU profile.
For some reason, it is losing the connection with the WebSocket server. Most of the time spent by the extension was reconnecting to the server.
Could you please share the extension output:

Is the Mac Air connected through WSL or SSH?

Are you using the default extension settings?

  "streamdeck.serverHost": "<IP_ADDRESS>",
  "streamdeck.serverPort": 48969

Thanks for the log file path. That turned the lightbulb on in my head. So I just swapped out to the M1 Air from an Intel Air. I have never installed StreamDeck yet on this M1 Air -- I did on the old Intel Air. I have VSCode settings sync turned on so Pro, Air, and PC are all in sync with VS Code. That includes extensions. So when I fired up VS Code the first time on the M1 Air, the StreamDeck extension is installed by the settings sync and I start noticing the high CPU. I will test for the same behavior on my Pro disconnected from the StreamDeck. I will open a new issue if that is the case.

Thanks for the log file path. That turned the lightbulb on in my head. So I just swapped out to the M1 Air from an Intel Air. I have never installed StreamDeck yet on this M1 Air -- I did on the old Intel Air. I have VSCode settings sync turned on so Pro, Air, and PC are all in sync with VS Code. That includes extensions. So when I fired up VS Code the first time on the M1 Air, the StreamDeck extension is installed by the settings sync and I start noticing the high CPU. I will test for the same behavior on my Pro disconnected from the StreamDeck. I will open a new issue if that is the case.

I don't see the extension or settings be synced across all your devices to be the problem I, too have everything synced.
The only thing I could think of is a problem in the WebSocket server (which is running in the Stream Deck side, that's why I asked for the log) not able to accept connections (each vscode instance).

I don't see the extension or settings be synced across all your devices to be the problem I, too have everything synced.
The only thing I could think of is a problem in the WebSocket server (which is running in the Stream Deck side, that's why I asked for the log) not able to accept connections (each vscode instance).


[Feature] Exclude unit tests from running when using "dbt test" command

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature
This is somewhat of an extension of a previous issue: https://github.com/dbt-labs/dbt-core/issues/9237
Currently, including "unit_test" in the DBT_EXCLUDE_RESOURCE_TYPES env variable will prevent units from running when using the dbt build, list and clone commands. No other commands are affected by this env variable.
However, I want to extend this to include the dbt test command.
The use case is something that we're hitting currently, where we run dbt on our airflow instances; We do not want to run unit tests on our Prod airflow instances. This is recommended in the dbt docs here: https://docs.getdbt.com/docs/build/unit-tests#when-to-run-unit-tests
Some of our legacy dags / code do not utilise dbt build. Rather, they use dbt run and dbt test as separate commands.
I know that there are ways to limit what is run using specific cli commands, but I think an env variable would be much cleaner, and would prevent us from having to change our code in (potentially) multiple places.
Looking at the ticket I posted above, there seems to be an assumption that no one would want to prevent unit tests on a dbt project level, which I think is true. However, as it currently stands, preventing unit_tests on an environment level is not yet 100% achievable across all functions of dbt.
It would be ideal if we could prevent all our dbt commands from running unit tests with a single env variable, that we could set on whatever airflow instances we need.
Describe alternatives you've considered
We could change all our dags to use dbt build instead of dbt run and dbt test separately.
I believe we could also add an argument to our dbt command to something like this: dbt test --select "test_type:data".
With both these cases, we'd have to change the way we use dbt. Ideally, a global exclusion of a resource_type should be applicable to all functions of dbt.
Who will this benefit?
Anyone who wants to prevent unit tests from running on a per environment basis.
Are you interested in contributing this feature?
I am just about to create a PR for this.
Anything else?
No response

Makes sense @TowardOliver 💡
Thanks for opening a PR for this too!

Opened a new issue in dbt-labs/docs.getdbt.com: https://github.com/dbt-labs/docs.getdbt.com/issues/6101


Module cannot be imported by newer swift compiler, please enable Build Libraries for Distribution

I downloaded the Azure SDK binary release from here: https://github.com/Azure/azure-sdk-for-ios/releases
I'm building a macOS command line utility using XCode 11.2.1
I added AzureCore and AzureStorage to my project, then added import AzureCore to my main.swift file
I receive the following error
Module compiled with Swift 5.0.1 cannot be imported by the Swift 5.1.2 compiler: /Users/orione/Dev/MyApp/external/AzureCore.framework/Modules/AzureCore.swiftmodule/x86_64.swiftmodule

Swift 5 provides module stability, however the modules must explicitly opt into this by setting BUILD_LIBRARY_FOR_DISTRIBUTION = YES; in the pbxproj (or associated GUI setting)
https://stackoverflow.com/questions/58654714/module-compiled-with-swift-5-1-cannot-be-imported-by-the-swift-5-1-2-compiler/58656323?noredirect=1#comment105165590_58656323
It looks like the Azure libraries aren't compiled with this flag. (Evidence is that under the AzureCore.swiftmodule folder there is a .swiftdoc and a .swiftmodule but NOT a .swiftinterface, which is required for module stability)

Closing as wontfix, we are preparing for a release of the Track 2 SDK libraries which are based on a different codebase. We will ensure that Track 2 SDK libraries include this build setting, thank you for the report!


Calling TryRead::read(..) on a closed NonBlock<TcpStream> succeeds ?

As a minimal example:
use mio::TryRead;

extern crate mio;

fn main() {
    let listener = ::mio::tcp::listen(&"<IP_ADDRESS>:8000".parse().unwrap()).unwrap();

    let mut socket;

    loop {
        match listener.accept() {
            Ok(Some(s)) => { socket = s; break; }
            Ok(None) => {},
            Err(e) => panic!("{}", e)
        }
    }

    let mut buffer = ::mio::buf::RingBuf::new(1024);

    loop {
        match socket.read(&mut buffer) {
            Ok(Some(n)) => println!("Read {} bytes.", n),
            Ok(None) => {},
            Err(e) => panic!("{}", e)
        }
    }
}

Connection to the server described above works (I'm doing it with nc from command line), writing text to it works (I get several Read n bytes. lines), but once the client closes the connexion, it keeps looping on Read 0 bytes. forever.
Shouldn't socket.read(..) return something like Err(EndOfFile), or something like that ?
if not, how do you check if the connexion has been closed by client ?

This is expected behavior. Posix signals a closed socket by returning 0 from a read. I just maintained the posix api for now. std::io does the same. I would think keeping the same behavior across all these systems would be the least confusing?

Ok, I see, should have searched a little more before asking.
That's why it also keeps triggering the readable event I guess.
That makes sense, given the "nothing to read yet" is handled by the WouldBlock mecanism.
So the read returning 0 always means that the socket is closed ? (assuming there is space left in the target buffer).

zero indicates of file
I'll close this for now :smile:


how itk.CudaImage convert to itk.Image?

You the mailing list for user questions. A CudaImage is an Image by inheritance.


docker run --tmpfs through remote api

Hi, are there plans to support this in the future? This can be very helpful for example when running containers using docker maven plugin.

Can you explain what you are asking for? You can add tmpfs mounts using the API - everything the CLI does is performed via the API.

Thanks for your reply, I've tried the forums, and IRC channel, but had no luck so far. I want to be able to run a mysql container that has /var/lib/mysql mounted as tmpfs. I'm running this through docker maven plugin.
If it is possible to do this using the remote api, can you give me an example so I can pass it on to the developer so he can add it to the plugin? The last time I asked he said it isn't implemented yet.

Here: https://github.com/docker/docker/blob/9f0593990f6d8ac95a5dde312e0b7401b472cfb9/api/types/container/host_config.go#L308
key is a mount point and value is a mount option string passed to the mount syscall (can be empty)
Maybe not documented yet?

Thanks, I will pass it on! I have the feeling it is not documented.

If it's not documented indeed, could you open a separate issue for that? (Or perhaps a pull request)
Let me close this issue,  because the original problem seems to be resolved, but feel free to continue the discussion


Merge main into live

Docs Build status updates of commit bcbbe70:
:warning: Validation status: warnings

File
Status
Preview URL
Details

IIS-Administration/configuration/appsettings.json.md
:warning:Warning
View
Details

IIS-Administration/index.md
:warning:Warning
View
Details

IIS-Administration/security/integrated/web.config.md
:bulb:Suggestion
View
Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

IIS-Administration/api/applications.md
:white_check_mark:Succeeded
View

IIS-Administration/api/virtual-directories.md
:white_check_mark:Succeeded
View

IIS-Administration/getting-started.md
:white_check_mark:Succeeded
View

IIS-Administration/configuration/appsettings.json.md

Line 2, Column 1: [Warning: title-missing - See documentation] Missing required attribute: 'title'. Add a title string to show in search engine results.
Line 2, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

IIS-Administration/index.md

Line 2, Column 1: [Warning: title-missing - See documentation] Missing required attribute: 'title'. Add a title string to show in search engine results.
Line 2, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

IIS-Administration/security/integrated/web.config.md

Line 3, Column 14: [Suggestion: duplicate-descriptions - See documentation] Attribute 'description' with value 'This article is deprecated as of IIS Administration 2.0.0.' is duplicated in 'security/integrated/web.config.md(3,14)', 'security/integrated/windows.md(3,14)'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


rationalization: Makefile

This patch introduce a Makefile that is meant to replace the compile_all.sh script, and do more.
I import it as is from the Debian material, module refreshments.
By default, it does nothing (yet).
It contains the default targets: build, install, uninstall, clean, distclean.
It also contain the maintainer target maintainer-clean.
The other target are more specific to the project itself: jarbuild, jarclean.
The target default-info is meant to echo some key data.
Otherwise, the composition itself (TeX stuff) is highly inspire by the script: if I remember well, I added some option here and there for compatibility reasons.
Summary:
to build: make build
to clean: make clean
to build the jar: jarbuild
to clean the jar: jarclean
and so forth.
Note that it assume some data that I may bring later.
The optional MaKe data file maint.mk is meant to contained local setup, and so to be ignored by GIT.
Sample:
==8><--------------------------------------------------
include $(HOME)/etc/maint.mk
JARDIR = $(HOME)/Surfer/Galleries/pool/jar/
----------------------------------><8============
[[on my box, I play with make version 4 (Jessie and later); it is written with GNU make in mind]]

IMPORTANT NOTE: this request  interfere with
https://github.com/IMAGINARY/SURFER-Galleries/pull/30

The GNUmake is menat to be ignored by GIT: add in
.git/info/exclude
GNUmakefile
This version contains itself and a simple local gitmaint.mk that is meant to contain local material
(and to be personalized wrt you habits and taste)
THIS VERSION is NEUTRALIZED: it may not modify anything.
Sample usage:
stamp the changelog file:
make  gitmaintainer-release-changelog
tag
make gitmaintainer-release-tag
make a release
gitmaintainer-release
[[to get the list of target, consider BASH completion:
make gitmaintainer- + TAB

To build in parallel:
make build -j4

PLease let me know if some clarification is needed.

I have to look into it in detail. I this urgent? I would like to finish something different beforehand.

It is not urgent. But it shows what it can be easily done with make, and it may help to reorganize the master branch.


rio up fails with invalid: metadata.ownerReferences if there are more than 8 services

Describe the bug
A clear and concise description of what the bug is.
rio -n testx up --name some --file Riofile --answers Riofile-answers
FATA[0035] failed to create testx/web4 rio.cattle.io/v1, Kind=Service for  testx/some: Service.rio.cattle.io "web4" is invalid: metadata.ownerReferences: Invalid value: []v1.OwnerReference{v1.OwnerReference{APIVersion:"rio.cattle.io/v1", Kind:"Stack", Name:"some", UID:"660e9eaf-02a7-11ea-bdf1-021078f9eec5", Controller:(*bool)(0xc0137041b0), BlockOwnerDeletion:(*bool)(0xc0137041b1)}, v1.OwnerReference{APIVersion:"rio.cattle.io/v1", Kind:"Stack", Name:"some", UID:"660e9eaf-02a7-11ea-bdf1-021078f9eec5", Controller:(*bool)(0xc0137041b2), BlockOwnerDeletion:(*bool)(0xc0137041b3)}}: Only one reference can have Controller set to true. Found "true" in references for some and some, failed to create testx/web8 rio.cattle.io/v1, Kind=Service for  testx/some: Service.rio.cattle.io "web8" is invalid: metadata.ownerReferences: Invalid value: []v1.OwnerReference{v1.OwnerReference{APIVersion:"rio.cattle.io/v1", Kind:"Stack", Name:"some", UID:"660e9eaf-02a7-11ea-bdf1-021078f9eec5", Controller:(*bool)(0xc00df387e0), BlockOwnerDeletion:(*bool)(0xc00df387e1)}, v1.OwnerReference{APIVersion:"rio.cattle.io/v1", Kind:"Stack", Name:"some", UID:"660e9eaf-02a7-11ea-bdf1-021078f9eec5", Controller:(*bool)(0xc00df387e2), BlockOwnerDeletion:(*bool)(0xc00df387e3)}}: Only one reference can have Controller set to true. Found "true" in references for some and some
To Reproduce
Steps to reproduce the behavior:

Try the attached Riofile, you should be able to reproduce the issue (it is renamed as Riofile.txt to allow uploading here to git issue)
Now try it again after commenting out from web9 onwards, it will work. So the only workaround is to create multiple Riofiles with less than 8 services, not ideal if you want to watch Riofile
Riofile.txt

Expected behavior
Kubernetes version & type (GKE, on-prem): kubectl version
Client Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.7-eks-1861c5", GitCommit:"1861c597586f84f1498a9f2151c78d8a6bf47814", GitTreeState:"clean", BuildDate:"2019-09-24T22:12:08Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.6-eks-5047ed", GitCommit:"5047edce664593832e9b889e447ac75ab104f527", GitTreeState:"clean", BuildDate:"2019-08-21T22:32:40Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

Type:
Rio version: rio info
Rio Version: v0.6.0-alpha.4 (969baf29)
Rio CLI Version: v0.6.0-alpha.4 (969baf29)
Cluster Domain: 3fbqj3.on-rio.io
Cluster Domain IPs:
System Namespace: rio-system
Wildcard certificates: true

Additional context
rio systemlogs
output:
rio-controller | time="2019-11-09T04:09:51Z" level=info msg="Starting rio-controller, version: v0.6.0-alpha.4, git commit: 969baf29"
rio-controller | time="2019-11-09T04:09:51Z" level=info msg="Updating CRD services.rio.cattle.io"
rio-controller | time="2019-11-09T04:09:51Z" level=info msg="Updating CRD stacks.rio.cattle.io"
rio-controller | time="2019-11-09T04:09:51Z" level=info msg="listening at :443"
rio-controller | I1109 04:09:51.960145       1 leaderelection.go:241] attempting to acquire leader lease  rio-system/rio...
rio-controller | I1109 04:09:51.967315       1 leaderelection.go:251] successfully acquired lease rio-system/rio
rio-controller | time="2019-11-09T04:09:53Z" level=info msg="Starting /v1, Kind=ConfigMap controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting apps/v1, Kind=Deployment controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting /v1, Kind=Secret controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting gitwatcher.cattle.io/v1, Kind=GitCommit controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting rio.cattle.io/v1, Kind=Stack controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting admin.rio.cattle.io/v1, Kind=ClusterDomain controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting apps/v1, Kind=StatefulSet controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting /v1, Kind=Service controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting rio.cattle.io/v1, Kind=ExternalService controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting apps/v1, Kind=DaemonSet controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting rbac.authorization.k8s.io/v1, Kind=ClusterRole controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting rio.cattle.io/v1, Kind=Service controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting tekton.dev/v1alpha1, Kind=TaskRun controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting gloo.solo.io/v1, Kind=Settings controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting cert-manager.io/v1alpha2, Kind=Certificate controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting extensions/v1beta1, Kind=Ingress controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting /v1, Kind=Endpoints controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting admin.rio.cattle.io/v1, Kind=PublicDomain controller"
rio-controller | time="2019-11-09T04:09:56Z" level=info msg="Starting rio.cattle.io/v1, Kind=Router controller"

Reproduced using rio v0.6.0-alpha.4 in a k3s v0.10.2 cluster.  @StrongMonkey @daxmc99

thanks for reporting @lucidprogrammer

available to test in v0.6.0-alpha5.

tested in v0.6.0-alpha5. it is fixed


Introduce vesting offsets

Closes #3090

The change solves the issue I reported in #3090 to allow for partially vested balances at genesis, but still has the complication reported above ^^
The most minimal fix would be to allow begin to be an i64 which would allow the offset to be lower than the balance at genesis by allowing begin to be negative. This might be less safe.
Another change would involve changing the VestingSchedule struct and the logic for locked_at
pub struct VestingSchedule<Balance, BlockNumber>  {
    pub vested_amount: Balance,
    pub begin: BlockNumber,
    pub length: BlockNumber,
}

which would then just calculate the slope on the fly whenever vested_balance is called for an account.

The issue is simply that there's too many degrees of freedom to encoding in a straight y=mx+c curve.
I'm not planning on making the curve any more complex and this feature is non-negotiable, so it's just up to the user to be aware of how the two parameters play together in the genesis config.
I could maybe require that only one is used, I guess.

@gavofyork @lsaether I have introduced a small-ish rewrite the logic around vesting. The genesis config API is unchanged, but the VestingSchedule which is generated now looks like:
pub struct VestingSchedule<Balance, BlockNumber> {
	/// Locked amount at genesis.
	pub locked: Balance,
	/// Amount that gets unlocked every block from genesis.
	pub per_block: Balance,
	/// Starting block for vesting.
	pub starting_block: BlockNumber,
}

So rather than calculating an offset, we keep track of the locked amount and the block when vesting starts.
This means that a user can will have access to any amount of funds which is greater than the locked amount. Funds from locked start to vest only after starting_block, with per_block being unlocked per block.
This means a user can have some liquid funds on genesis and also have a vesting schedule that starts after block 0. Furthermore, any user can accumulate funds in their account before vesting starts, and spend those funds, whereas before a user might not be able to spend additional funds they receive because offset was "extra negative".
I will write tests for some of these extra scenarios, but wanted you to look at the design now.

This is ready for review

Someone else should review. @keorn ?


Crash on open link into tabs

Hi i have the latest version 3.3.9
In this tab:
https://tabslite.com/tabs/832924 "Poprocks And Coke bt Green Day"
This  is link to youtube, but when i click the app crash and close
Thanks

Confirmed this issue, thanks for reporting.  I'll try to get this fixed in the next update.

Fixed in code, pending testing and push to prod.  New fix: If opening link directly fails, copy to clipboard


Fix to accommodate freezing a TensorFlow Hub Keras

Signed-off-by: Om Thakkar<EMAIL_ADDRESS>Existing Sample Changes
Description
While trying to freeze a (re-trained) TFHub keras model exported in the SavedModel format, the existing script was unable to convert the Identity (and similar) ops to Const, which resulted into issues like fusions not happening in optimize_for_inference.

Added a constant folding grappler pass before calling optimize_for_inference.

Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Command Line:
python3 freeze_optimize_v2.py --input_saved_model_dir=<path-to-saved-model> --output_saved_model_dir=<path-to-generate-frozen-model>

@louie-tsai please review. Thanks!

@jimmytwei  @IgorOchocki
Could you both help to approve the PR?
thanks

@praveenkk123 @yinghu5
Possible to review the PR and approve it if all look good to you?


chore(driver): allow kmod and bpf drivers different components

What type of PR is this?
/kind cleanup
Any specific area of the project related to this PR?
/area build
/area driver-kmod
/area driver-bpf
Does this PR require a change in the driver versions?
What this PR does / why we need it:
This PR has a main scope: allow to install kmod and bpf under different components.
Also, now the ebpf probe gets built under CMAKE_CURRENT_BINARY_DIR instead of CMAKE_CURRENT_SOURCE_DIR, in a similar way to kmod.
Moreover, to properly build the bpf probe, all the driver/*.h header files are copied under CMAKE_CURRENT_BINARY_DIR for bpf and get eventually installed when issuing make install.
It has the main advantage that in the future we might want to split up falco-kmod and falco-bpf packages, BUT still retain the possibility to build the bpf probe under /usr/src/driverversion/bpf/ folder.
An example of the aforementioned issue is the current behavior if we configure libs using:
-DENABLE_DKMS=Off -DBUILD_DRIVER=Off -DBUILD_BPF=On ..

and then make install it. Under /usr/src/$version/ we will just have a bpf folder, and if we move under it, we cannot build the bpf probe because its sources include headers from the parent (that was not installed).
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

driver/OWNERS [FedeDP]

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

/milestone 0.15.0

Driverkit / build-drivers (linux-4.x) (pull_request) Failing after 33s

Need to fix bpf build under driverkit :/

Driverkit 0.17.0 was released, and driverkit related tests now pass fine.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

driver/OWNERS [FedeDP,leogr]

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

/cc @jasondellaluce

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, jasondellaluce, leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

driver/OWNERS [FedeDP,jasondellaluce,leogr]

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


文档里为什么没有数据库的说明？

Why no databases documents for rbac

This module provides no DB integration - DB integration is to be implemented by implementing a custom https://github.com/zendframework/zend-permissions-rbac/blob/98252acae03f52e83e937150efe81f621e15891c/src/Rbac.php that reads from the DB instead of performing in-memory operations.
Closing as duplicate of https://github.com/zendframework/zend-permissions-rbac/issues/28


NullPointer exception on mapModel

What version of the library are you using?  -> 3.0.0
What kind of issue is this? -> Bug, Regression
When browsing v3/api-docs?group=api I get a Nullpointer Exception in SchemaMapper.java line 97. It seems like the mapFrom function returns null.
java.lang.NullPointerException: null
	at springfox.documentation.oas.mappers.SchemaMapper.model(SchemaMapper.java:97) ~[springfox-oas-3.0.0.jar:3.0.0]
	at springfox.documentation.oas.mappers.SchemaMapper.mapModel(SchemaMapper.java:85) ~[springfox-oas-3.0.0.jar:3.0.0]
	at springfox.documentation.oas.mappers.ServiceModelToOpenApiMapperImpl.fromRepresentation(ServiceModelToOpenApiMapperImpl.java:187) ~[springfox-oas-3.0.0.jar:3.0.0]
	at springfox.documentation.oas.mappers.ServiceModelToOpenApiMapper.map(ServiceModelToOpenApiMapper.java:216) ~[springfox-oas-3.0.0.jar:3.0.0]
	at springfox.documentation.oas.mappers.ServiceModelToOpenApiMapperImpl.mapOperation(ServiceModelToOpenApiMapperImpl.java:113) ~[springfox-oas-3.0.0.jar:3.0.0]
	at springfox.documentation.oas.mappers.ServiceModelToOpenApiMapper.mapOperations(ServiceModelToOpenApiMapper.java:283) ~[springfox-oas-3.0.0.jar:3.0.0]
	at springfox.documentation.oas.mappers.ServiceModelToOpenApiMapper.lambda$mapPaths$4(ServiceModelToOpenApiMapper.java:264) ~[springfox-oas-3.0.0.jar:3.0.0]
	at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) ~[?:?]
	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655) ~[?:?]
	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) ~[?:?]
	at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:274) ~[?:?]
	at java.util.TreeMap$ValueSpliterator.forEachRemaining(TreeMap.java:2890) ~[?:?]
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) ~[?:?]
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) ~[?:?]
	at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) ~[?:?]
	at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) ~[?:?]
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
	at java.util.stream.ReferencePipeline.forEachOrdered(ReferencePipeline.java:502) ~[?:?]
	at springfox.documentation.oas.mappers.ServiceModelToOpenApiMapper.mapPaths(ServiceModelToOpenApiMapper.java:260) ~[springfox-oas-3.0.0.jar:3.0.0]
	at springfox.documentation.oas.mappers.ServiceModelToOpenApiMapperImpl.mapDocumentation(ServiceModelToOpenApiMapperImpl.java:83) ~[springfox-oas-3.0.0.jar:3.0.0]
	at springfox.documentation.oas.web.OpenApiControllerWebMvc.getDocumentation(OpenApiControllerWebMvc.java:88) ~[springfox-oas-3.0.0.jar:3.0.0]

Variables at that time:
source=ModelSpecification[scalar=null, compound=null, collection=null, map=null, reference=ReferenceModelSpecification{modelKey=ModelKey{qualifiedModelName=ModelName{namespace='', name='null'}, viewDiscriminator=null, validationGroupDiscriminators=[], isResponse=true}}, facets=null, name='null']
facets=Optional.empty
The v2/api-docs?group=api endpoint is working and it worked before upgrading to version 3.0.0.
Following operation/rest controller seems to trigger this (kotlin):
import io.swagger.annotations.Api
import io.swagger.annotations.ApiOperation
import io.swagger.annotations.ApiParam
import org.springframework.http.HttpStatus
import org.springframework.http.MediaType.APPLICATION_JSON_VALUE
import org.springframework.web.bind.annotation.RequestBody
import org.springframework.web.bind.annotation.RequestMapping
import org.springframework.web.bind.annotation.RequestMethod.POST
import org.springframework.web.bind.annotation.ResponseStatus
import org.springframework.web.bind.annotation.RestController

@RestController
@Api(tags = ["some tag"])
@Deprecated("no longer supported. ")
class RestController(private val service: SomeService) {
    @RequestMapping(path = [URL_CALL], method = [POST], consumes = [APPLICATION_JSON_VALUE])
    @ApiOperation(value = "Logs and stores a message")
    @ResponseStatus(value = HttpStatus.NO_CONTENT)
    fun call(
            @RequestBody
            @ApiParam(name = "call", value = "data to be stored")
            call: MutableMap<String, Any?>) {
        service.log(call)
    }

    companion object {
        const val URL_CALL = "api" + "/calls"
    }
}```

I could reproduce the NullPointerException problem with the following minimal controller:
import io.swagger.annotations.ApiOperation;
import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class TestController {

    @ApiOperation("an endpoint")
    @PostMapping(value = "/endpoint/", consumes = MediaType.APPLICATION_JSON_VALUE)
    public void endpoint () {
        // do stuff here
    }

}

From my experiments, it seems consumes at @PostMapping is not handled well with DocumentationType.OAS_30, even though it was OK with DocumentationType.SWAGGER_2. So, if you take this argument off, the exception is not thrown; however, this is not a workaround.
Just in case, here is the Application I used:
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import springfox.documentation.spi.DocumentationType;
import springfox.documentation.spring.web.plugins.Docket;

@SpringBootApplication
public class Application {

    public static void main (String[] args) {
        SpringApplication.run(Application.class, args);
    }

    @Bean
    public Docket docket () {
        return new Docket(DocumentationType.OAS_30);
    }

}

Confirming, experiencing the same. Issue happens only when providing "@ApiOperation". Without it, everything works.
Any ETA for fix?

BTW, workaround is to return ResponseEntity instead of void, like this:
@RestController
public class TestController {

    @ApiOperation("an endpoint")
    @PostMapping(value = "/endpoint/", consumes = MediaType.APPLICATION_JSON_VALUE)
    public ResponseEntity<String> endpoint () {
        // do stuff here
       return ResponseEntity.ok().build();
    }
}

I confirm that returning ResponseEntity instead of void is a working workaround.
It is best to return ResponseEntity<Void>.
You can return it with ResponseEntity.noContent().build()

So if I’m not mistaken, now, to specify a 201 with location header, without 200 OK, I must :

specify a 201 @ApiResponse with the location header
Return ResponseEntity.created
Specify @ResponseStatus(HttpStatus.CREATED) to avoid 200 OK in Springfox contract

It seems a bit redundant... With previous Springfox versions and void methods, there was no need of the ResponseEntity.created...

So if I’m not mistaken, now, to specify a 201 with location header, without 200 OK, I must :

specify a 201 @ApiResponse with the location header
Return ResponseEntity.created
Specify @ResponseStatus(HttpStatus.CREATED) to avoid 200 OK in Springfox contract

It seems a bit redundant... With previous Springfox versions and void methods, there was no need of the ResponseEntity.created...

For anyone else facing this issue:
This was also frustrating us, a less invasive workaround I was able to get working was to override the automatically derived data type on the ApiOperation by setting the response = String.class, this resolved the NPE

I confirm that returning ResponseEntity instead of void is a working workaround.
It is best to return ResponseEntity<Void>. You can return it with ResponseEntity.noContent().build().
I did some debugging and SchemaMapper fails when it tries to map response code 200. But there should not be that code at all. Void methods use result code 204 to indicate success.

Seems that return void body still incurs another small problem: Error-ModelName{namespace='java.lang', name='Void'}
https://github.com/springfox/springfox/issues/3476


User BTC withdraw are auto-rejected?

Trying to figure out if there is a setting somewhere as to why when a user withdraws BTC, these requests are automatically rejected?
Tried withdrawing 1 BTC & 0.01 BTC (dosen't seem to be the amount, nor the verification status of the user, as that user is verified)
Client Side:

Admin:

Hello @Sambusik
There are multiple cases why transaction may be rejected. Consider reading app/models/withdraw && app/models/workers/withdraw_coin.rb

thanks @yivo ;)


Live migrations page bandwidth consumption chart

Signed-off-by: Aviv Turgeman<EMAIL_ADDRESS>📝 Description
Adding a chart to show data processed by the migrations in a cluster scope.
NOTE: the UX design may change
issue
sub-task
UX design
🎥 Demo
https://user-images.githubusercontent.com/67270715/186694210-4ba51117-3e7d-410c-8a7a-6576977d2b72.mp4

/lgtm
If the design changes it can be fixed in a separate PR. =)


[Bug] type: 'line', using sampling = 'lttb'. None of the downmined points display the tooltip properly using showTip.

Version
5.5.1
Link to Minimal Reproduction
https://codepen.io/gpcwhitecap/pen/abeQOyK
Steps to Reproduce
Enter the index of a sampled point in the input box and click Show Tooltip. The sampled point is not displayed properly.
Current Behavior
I plotted a rather complex big data line chart via echarts, and at the same time I took over the display of the tooltip manually (mousemove, calculate dataIndex).
However, I found that the tooltip doesn't display when the dataIndex is a point that has been down-mined.
For my needs, I just want the tooltip.formatter to be triggered properly, and I only need an index for the params passed by the formatter, because I'm completely taking over the content of the formatter (which is looked up by index).
This problem causes the tooltip to be incomplete even when multiple charts are linked.
The function I'm using is
chart.dispatchAction({
type: 'showTip',
seriesIndex: 0,
dataIndex: 100
});
I've taken a closer look at the source code, and it seems that the dataByCoordSys of the sampled points cannot be calculated
How can I solve this problem? Or how to avoid it?
Expected Behavior
showTip is able to show the downgraded tooltip instead of having to go through doomZoom.
Environment
- OS:
- Browser:
- Framework:

Any additional comments?
No response

Isn't the purpose of lttb to exclude points ? Why expect that all points would be there ? Demo
📌 please close issue if problem solved.

showTip

I can understand that the purpose of Lttb is to exclude points, assuming that there is a longer section of line that is all one value (30%), and when those points are excluded tooltip will not work properly in that section. This would be a disaster for business, at the moment I'm planning to completely rewrite tooltip by using mousemove, but it's a pain in the ass.
The actual business is that when 2 charts are linked, A tooltip's 20th point B's 20th point is excluded, and showTip can't display the excluded points. And my business thinks that if your charts are linked, why don't you show them below, they will be considered as missing points.
Translated with DeepL.com (free version)

same problem!!!

same problem ! . is there any solution for this ?


mqtt_connack_sent - Out of Date Prometheus Metric Docs

Environment

VerneMQ Version: 1.7.1-1 (vernemq version returns empty)
OS: 16.04.1-Ubuntu (Docker Container Base)

Expected behavior

The metrics match the docs: https://docs.vernemq.com/monitoring/introduction
The dashboards we've tied into the following reported metrics are correct

mqtt_connack_accepted_sent
mqtt_connack_bad_credentials_sent
mqtt_connack_not_authorized_sent
mqtt_server_unavailable_sent
mqtt_connack_unacceptable_protocol_sent
mqtt_connack_identifier_rejected_sent

Actual behaviour

They don't match the docs
The metrics we've tied our dashboards into always report 0.
It looks like the metrics were changed to be labels on a single metric, called mqtt_connack_sent. I'm not sure if this was the intended behavior, and if the previously collected metrics were supposed to be updated as well as this new one, or if the intent was to replace the previously existing metrics.
It looks like the same thing is true for mqtt_puback_sent and mqtt_pubcomp_sent. All the metrics have been condensed into a single metric. There's a ton of labels on it that we were unaware existed as they weren't documented.
It would also be nice to have documentation around what each of the metrics mean, as we're just guessing right now.

Looking more into it, it seems like even the mqtt_connack_sent has two sets of labels, one used and one unused. The return_code labeled metrics seems to be returning correctly, but the reason_code labeled ones all seem to be returning 0.

@JohnCMcDonough thanks for reporting!
Just for reference: it's in the changelog of release 1.6: https://github.com/vernemq/vernemq/releases/tag/1.6.0
Maybe @larshesel can comment on the intended behaviour related to the switch to labels, and/or confirm there are possibly issues with the reason_codes returned for those metrics.
As a miminum, I guess the documentation needs some love & attention.

Thanks for the quick response @ioolkos! For now I'm rebuilding based on the mqtt_connack_sent with the return_code label. Let me know if I should be using something else though!

Hi,
The change with mapping the mqtt_connack_xxxx_sent to mqtt_connack_sent with labels happened in VerneMQ 1.6.0, as mentioned above. For MQTT 3.1.1 the they are mapped to return_code (as that's what they're called in that version) all the ones with reason_code are for MQTT v5.0.
We've completely forgotten to update the metrics in the docs and I'll do that in a short while. Notice that you can use vmq-admin metrics show -d to output all metrics with as short description about what they are about.
I've just updated the docs to mention the old metrics and the new labels as well as removed the list of metrics (as this will almost always be outdated).


Dropping Windows patch

Is this patch still needed?

@msarahan, looks like this goes all the way back to when this recipe was added to conda-forge. Do you think we can drop it or is this still needed? Thinking about making this noarch: python 🙂

Made it noarch:python

We should probably delete the patch file as well


Improve logging consistency for entity despawning

Move the despawn debug log from World::despawn to EntityMut::despawn.
Move the despawn non-existent warning log from Commands::despawn to World::despawn.

This should make logging consistent regardless of which of the three despawn methods is used.

Prevents repeated logging from entities that were already despawned

this duplicate log is useful as it allows the user to track where they are making those calls with spans from tracing

I moved the warning in the Despawn command to World::despawn for consistency.

bors r+


Bluetooth: Convert the HCI driver API to be a real Zephyr driver API

Is your enhancement proposal related to a problem? Please describe.
The current Zephyr HCI driver API is a bit of an oddball, in that it portrays itself as a driver API, yet isn't one in the traditional Zephyr sense where you have driver callbacks, DTS node instances etc. Lack of DTS nodes means that we don't have a natural way of associating together the HCI driver and the physical transport it's using (e.g. it'd make sense to have a phandle property for the driver to reference a UART or SPI controller, or whatever physical device is used as the transport.
Describe the solution you'd like
HCI drivers should become a first-class Zephyr driver API along with drivers having a DTS compat string as well as associated DTS nodes. The bt_recv() and bt_recv_prio() APIs might make more sense as callbacks that the host passes to the driver when it calls drv->open().

As for how the Bluetooth host picks a driver to use, maybe using the DTS chosen node convention might make sense?


Add otel-cloud-stack chart

Why make this?
This PR serves to finally close #562. This PR creates a helm chart that takes some inspiration from the kube-prometheus-stack chart from the prometheus community repo to create a fully-fledged collector starter for Kubernetes. Prometheus services and CRDs are optionally included to allow users a near-drop-in replacement for the prometheus experience. For non-prometheus users, this provides an easy way to get started with opentelemetry's Kubernetes offerings. This is accomplished by utilizing some clever templating for the configuration for the collector, which I found to be easier to reason about than embedding config in a helper tpl.
Features

Centralized tracing collector
Autoinstrumentation
Infrastructure metrics and logs collector
standalone kubernetes cluster stats collector
Allows for drop-in replacement for kube-prometheus-stack with a sharded statefulset collector
Allows for custom collectors to be set and validated against an exhaustive schema

Next steps

end to end testing to verify telemetry appears as expected between versions
documentation for what to expect OOTB
documentation for example configs (i include two samples below that are specific for my company)

For a config that gets you tracing, infra logs and metrics, kube cluster stats

clusterName: jacob-kind
opentelemetry-operator:
  enabled: true
collectors:
  tracing:
    env:
      - name: LS_TOKEN
        valueFrom:
          secretKeyRef:
            key: LS_TOKEN
            name: otel-collector-secret
    config:
      exporters:
        otlp:
          endpoint: ingest.lightstep.com:443
          headers:
            "lightstep-access-token": "${LS_TOKEN}"
      service:
        pipelines:
          traces:
            exporters: [otlp]
  daemon:
    env:
      - name: LS_TOKEN
        valueFrom:
          secretKeyRef:
            key: LS_TOKEN
            name: otel-collector-secret
    config:
      exporters:
        otlp:
          endpoint: ingest.lightstep.com:443
          headers:
            "lightstep-access-token": "${LS_TOKEN}"
      service:
        pipelines:
          metrics:
            exporters: [otlp]
          logs:
            exporters: [otlp]
  cluster:
    env:
      - name: LS_TOKEN
        valueFrom:
          secretKeyRef:
            key: LS_TOKEN
            name: otel-collector-secret
    config:
      exporters:
        otlp:
          endpoint: ingest.lightstep.com:443
          headers:
            "lightstep-access-token": "${LS_TOKEN}"
      service:
        pipelines:
          metrics:
            exporters: [otlp]
opAMPBridge:
  enabled: false

For a config that's a near drop in for kube-prometheus-stack

clusterName: jacob-kind
opentelemetry-operator:
  enabled: true
  manager:
    serviceMonitor:
      enabled: true
    extraArgs:
      - "--feature-gates=operator.observability.prometheus"
    image:
      tag: "v0.95.0"
collectors:
  tracing:
    enabled: false
  daemon:
    enabled: false
  cluster:
    enabled: false
  metrics:
    enabled: true
    targetAllocator:
      observability:
        metrics:
          enableMetrics: true
    observability:
      metrics:
        enableMetrics: true
    env:
      - name: LS_TOKEN
        valueFrom:
          secretKeyRef:
            key: LS_TOKEN
            name: otel-collector-secret
    config:
      exporters:
        otlp:
          endpoint: ingest.lightstep.com:443
          headers:
            "lightstep-access-token": "${LS_TOKEN}"
      service:
        pipelines:
          metrics:
            exporters: [otlp]
opAMPBridge:
  enabled: false
prometheus:
  customResources:
    enabled: true
kubernetesServiceMonitors:
  enabled: true
kubeApiServer:
  enabled: true
kubelet:
  enabled: true
kubeControllerManager:
  enabled: true
kubeDns:
  enabled: true
kubeEtcd:
  enabled: true
kubeScheduler:
  enabled: true
kubeProxy:
  enabled: true
kubeStateMetrics:
  enabled: true
nodeExporter:
  enabled: true

okay. so now this thing actually does something!! Next week I have to test out the kube-otel-stack functionality. But you can try for yourself by layering this values file over the existing values. (obviously this works for LS and youll needd to change to your vendor of choice ;))

Here's that config

```yaml
clusterName: jacob-kind
opentelemetry-operator:
  enabled: true
collectors:
  tracing:
    env:
      - name: LS_TOKEN
        valueFrom:
          secretKeyRef:
            key: LS_TOKEN
            name: otel-collector-secret
    config:
      exporters:
        otlp:
          endpoint: ingest.lightstep.com:443
          headers:
            "lightstep-access-token": "${LS_TOKEN}"
      service:
        pipelines:
          traces:
            exporters: [otlp]
  daemon:
    env:
      - name: LS_TOKEN
        valueFrom:
          secretKeyRef:
            key: LS_TOKEN
            name: otel-collector-secret
    config:
      exporters:
        otlp:
          endpoint: ingest.lightstep.com:443
          headers:
            "lightstep-access-token": "${LS_TOKEN}"
      service:
        pipelines:
          metrics:
            exporters: [otlp]
          logs:
            exporters: [otlp]
  cluster:
    env:
      - name: LS_TOKEN
        valueFrom:
          secretKeyRef:
            key: LS_TOKEN
            name: otel-collector-secret
    config:
      exporters:
        otlp:
          endpoint: ingest.lightstep.com:443
          headers:
            "lightstep-access-token": "${LS_TOKEN}"
      service:
        pipelines:
          metrics:
            exporters: [otlp]
opAMPBridge:
  enabled: false
</details>

@jaronoff97 it would be nice to have some self-monitoring of the operator and collectors? Not sure what form that would take (e.g. ServiceMonitor or static scrape job).

this is actually already possible and you can take a look at that in my sample configs in the For a config that's a near drop in for kube-prometheus-stack section :)

@jaronoff97 I see you can bring your own ServiceAccount for your collector and target allocator. However, the ClusterRoleBinding is using the ServiceAccount that the operator is generating, not your override.

@TylerHelmuth i think i could split this up in to the following sections:

hierarchical things (chart.yaml, unfilled values-yaml, some templates with nothing)
embed operator deployment
default collector configuration
autoinstrumentation
opamp bridge
prometheus features
some sample collector configurations for a true quickstart

do i need to also make a rendered folder to test that?

@jaronoff97 I like that approach.

some sample collector configurations for a true quickstart

We can handle this via an example folder like the other charts.

@TylerHelmuth I see, so we would have some files like example/kube-prom-stack which has the values files overrides for doing that? This, rather than baking in these defaults?

i see, in this case the chart is meant to serve as a quickstart with opentelemetry. Hopefully giving users full visibility in to their kube clusters the "otel" way. Or allowing people on prometheus with the kube-prometheus-stack a near exact replica but with the collector

@jaronoff97 yup, I was referring to those yaml files. I may not understand what you meant by rendered folder.
Regardless, let's move forward with incremental PRs.

Closing this for now in favor of the approach specified here


Error when trying to use requester pays buckets

Testing whether or not I can use dsub on files stored in a requester pays bucket returned the following error:
[u'Error in job wc--jslagel--171129-194301-06 - code 5: 9: Failed to localize files: failed to copy the following files: "gs://xxx-test-requester-pay/xxx.txt -> /mnt/datadisk/input/gs/xxx-test-requester-pay/xxx.txt (cp failed: gsutil -q -m cp gs://xxx-test-requester-pay/xxx.txt /mnt/datadisk/input/gs/xxx-test-requester-pay/xxx.txt, command failed: BadRequestException: 400 Bucket is requester pays bucket but no user project provided.\nCommandException: 1 file/object could not be transferred.\n)"']
JobExecutionError: One or more jobs finished with status FAILURE or CANCELED during wait.
On the surface it appears that the gsutil command is missing the new '-u ' argument.

Hi Joe,
Pipelines API does not yet support Requester Pays buckets. Once it does, dsub will be able to.
-Matt

Anybody we can prod to get it to support it? is there an issue for it already?

I have updated the issue I had filed to reference this request. It is one of our top priority requests.

Tx!
On Wed, Nov 29, 2017 at 1:29 PM, Matt Bookman<EMAIL_ADDRESS>wrote:

I have updated the issue I had filed to reference this request. It is one
of our top priority requests.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/googlegenomics/dsub/issues/99#issuecomment-348002356,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKBQyCqI8gfuVdaUsK24IpH_zqP8MTz7ks5s7czLgaJpZM4Qvpd5
.

--
Joe Slagel
Institute for Systems Biology
<EMAIL_ADDRESS>

Hi @slagelwa, thanks for your note! RP will be supported in Pipelines API v2, which will be available in early Q1 2018.

Hi @sheffi (or anyone else) -- is there a plan/schedule for getting all of the great new Pipelines v2 functionality to be supported from dsub?

Hi @smrgit! @mbookman can say more about their team's timeline for supporting Pipelines v2.

@mbookman do you know what the status is on accessing data in requester-pays buckets? (I just skimmed over the latest dsub documentation and didn't see anything, but I might have missed it.)  Thanks!

We can now add this in the google-v2 provider. With all the preliminaries taken care of, this is next on the feature list to be implemented.

Support for Requester Pays buckets is now available (Release v0.2.2) for both the google-v2 and local providers.


module_view not working as expected

Please follow the guide below

Issues submitted without this template format will be ignored.
Please read the questions carefully and answer completely.
Do not post screenshots of error messages or code.
Put an x into all the boxes [ ] relevant to your issue (==> [x] NO spaces).
Use the Preview tab to see how your issue will actually look like.
Issues about reverse engineering is out of scope and will be closed without response.
Any mention of spam-like actions or spam-related tools/libs/etc is strictly not allowed.

Before submitting an issue, make sure you have:

[x] Updated to the lastest version v1.6.0
[x] Read the README and docs
[x] Searched the bugtracker for similar issues including closed ones
[x] Reviewed the sample code in tests and examples

Which client are you using?

[x] app (instagram_private_api/)
[ ] web (instagram_web_api/)

Describe the Bug/Error:
I was trying to update view count for a media. it looks like that like and view have the same endpoints. As I understand passing the module name video_view should update the view count of a media instead of its like count. so I tried it and it only liked the media instead of updating the view count.

Paste the output of python -V here:
Code:
# Example code that will produce the error reported
from instagram_private_api import Client, ClientCompatPatch

user_name = '---------'
password = '----------'

api = Client(user_name, password)
results = api.post_like("1986230217740718131_5685779641", "video_view")

print(results)

Error/Debug Log:
there is no error. it returns {'status':'ok'} which is ok. but not the expected result IMHO.

How do you make the mental jump to think that a method called post_like has anything to do video counts?
The docs, which you have supposedly read, clearly states what the method is for.

Oh, attitude!

do you have any idea how to do it?