How to send message to QGC or other UAVs?

Hi, Everyone,
I have been using dronekit-python happily, but recently there is a need to send mavlink messages from my dronekit to QGC or UAVs other than the one that is connected with my dronekit. For example, two UAVs and QGC are connected as follows:
Dronekit<==>UAV1  <--- mavlink ---->  UAV2 <--- mavlink ---> QGC
Could someone tell me how to send a message from Dronekit to UAV2 or GGC?  I have been trying to modify the code of dronekit-python to do this but without any success. Any help would be greatly appreciated.  Thanks!

I managed to forward the MAVLink messages coming from an UAV connected to a serial port through DroneKit to QGroundControl.
UAV (PX4) <==== (serial) ====> DroneKit <==== (MAVLink UDP stream) ====> QGroundControl
The code to do so is already present in DroneKit. Look into the mavlink.py file for the mavudpin_multi class and for the MAVConnection.pipe() method.
The code I used is:
vehicle = dronekit.connect('/dev/ttyS0')  # ... and other connection options
udp_conn = MAVConnection('udpin:<IP_ADDRESS>:15667', source_system=1)
vehicle._handler.pipe(udp_conn)
udp_conn.master.mav.srcComponent = 1  # needed to make QGroundControl work!
udp_conn.start()

This code starts a listener on UDP port 15667 which automatically establishes the necessary connections with clients. All MAVLink messages coming from the vehicle are forwarded on the UDP clients, and all the messages coming from the UDP clients are forwarded to the client.
To make the forwarding work I had to alter the source component ID.
Then I configured QGroundControl to contact the host running DroneKit via UDP on port 15667. QGroundControl itself should listen on another port.
Here's an example configuration:

@pietrodn ,
Thanks for your nice and quick post! I immediately tried it but not yet get it working. Here is what I did to send PING messages from my dronekit to QGC:
====================
self.vehicle = connect('<IP_ADDRESS>:14540', 57600) # wait_ready=True, heartbeat_timeout=60
udp_conn = MAVConnection('udpin:<IP_ADDRESS>:15667', source_system=1)
self.vehicle._handler.pipe(udp_conn)
udp_conn.master.mav.srcComponent = 1  # needed to make QGroundControl work!
udp_conn.start()
self.vehicle.add_message_listener('PING', listen_msg_src)  # listen on PING msg
self.msg1 = self.vehicle.message_factory.ping_encode(1000,1,255,1) # prepare a PING to QGC
self.vehicle.send_mavlink(self.msg1)    # send the PING to QGC
On QGC, I connected, as you shown, <IP_ADDRESS>:15667. I was hoping to see the PING messages at QGC, but they did not show up. Also, I tried the same thing to PING another UAV with target_system=2, and no luck.
Could you please let me know what I did not do right? In addition, could you please post your minimal but complete code so that we can try exactly what you did? For example, what messages did you send? What are the results you see at QGC? Other small differences include: you used 'udpin:<IP_ADDRESS>:15667', I used 'udpin:<IP_ADDRESS>:15667'. Yours is connect('/dev/ttyS0'), mine connect('<IP_ADDRESS>:14540') for a PX4 SITL. I don't know if these make any differences. Have you tried it on a PX4 SITL? Thanks for your help!

I tried exclusively on the PX4 firmware.
For the “udpin” connection string, the IP tells on which interfaces DroneKit should be listening for incoming connections. <IP_ADDRESS> means “all interfaces”, so I recommend using that until you get the forwarding to work.
Also, check if you have a firewall blocking some ports.
I didn’t need to manually send any message: I clicked on “connect” on QGC and the software displayed me the full status of the drone (battery, sensors, parameters, etc.)
Are QGC and PX4 running on the same host?

And yes, I tried both on a real UAV and on a PX4 SITL. On the SITL, however, I had to disable the automatic listening on UDP port 14540 on QGC, otherwise QGC will try to connect directly to the SITL and not to the forwarded connection.

Oh, and don’t use 14540 or 14550 as a listening port on QGC... use something random, not related to the SITL. Otherwise it will complain that the port is already bound by another application.

Thanks for your detailed replies! I am almost there but have one more question. I have my QGC connected to 15667 first, but when I started my dronekit after that, dronekit complains that 15667 is already in use. But if I first connect dronekit on 15667, then QGC will complain that 15667 is already in use when I clink connect there. What did I miss?

Probably you set 15667 as the "listening port" in QGC. Try to use another port. Otherwise, there is another process running...

For the formatting thing, GitHub supports a simple markup language called “GitHub flavored Markdown”. Google it :-)
To avoid the fix_targets correction, I’m afraid you’ll have to monkey-patch the MAVConnection class:
def my_new_fix_targets(self, message):
    # your code

udp_conn.fix_targets = my_new_fix_targets

Where your new method may as well be a no-op.
Or, if you always want the same target to be set, you can set the udp_conn.target_system attribute so that fix_target will write what you want.

Thanks for your suggestion and I have tried the following code for many times. All is fine except line 2.2 runs into an error "Address already in use". Can you see any obvious mistakes? I have a question how a udp connection is made. For example, between two parties (say d1 and d2 below), if d1 is already listening on port 15667, should d2 just call mavudp and connect to 15667 and be done with it? Why it complains "address already in use"?
On DroneKit_1 (d1):
1.1. vehicle1 = dronekit.connect('ip_for_PX4_1',source_system=1)  # connect d1 to PX4_1
1.2. udp_pipe_to_d2 = MAVConnection('udpin:<IP_ADDRESS>:15667', source_system=1)
1.3. vehicle1._handler.pipe(udp_pipe_to_d2)
1.4. udp_pipe_to_d2.master.mav.srcComponent = 1
1.5. udp_pipe_to_d2.start() # start the pipe to DroneKit_2
On DroneKit_2 (d2):
2.1. vehicle2 = dronekit.connect('ip_for_PX4_2',source_system=2)  # connect d2 to PX4_2
2.2. udpconn_to_d1 = mavutil.mavudp(<IP_ADDRESS>:15667, source_system=2, source_component=1) # connect d1
Line 2.2. runs into an error "Address already in use". Did I use the function mavudp correctly? Please help!

d1 and d2 are now connected, but d2 does not seem to receive any messages sent from d1.  Suggestions?

Sorry, they still do not connect when the same port is used. Same error “Address already in use”.

Hi, @pietrodn,
Finally, it is working!!!  Here is the good Line 2.2:
2.2. udpconn_to_d1 = connect(udpout:<IP_ADDRESS>:15667, source_system=2)
After this, d2 can listen to the PING messages sent from d1 on udpconn_to_d1 as follows:
2.3. udpconn_to_d1.add_message_listener('PING', listen_msg_src)
Putting all together, I now have the following configuration working. Thank you!!!

I’m glad it is working! :-)
The “address already in use” message means that you are trying to bind two sockets on the same port on the same host, namely two UDP input connections.

Thank you! It was quite tricky to find out that the "udpout" was the right option for the connect function. I had to dig deep into the dronekit code. Do you know if there is a way to make it more obvious for people to use in the future?

You may contribute to the documentation! :-) It is in the "docs" directory.

I will be glad to. Any suggestion for where and how to proceed?

http://python.dronekit.io/contributing/contributions_documentation.html

Hey @weiminshen99 @weiminshen99 I have read all of the conversations and am hoping you can help.
This is the setup I am trying to achieve:

notice that the way to the liner servo is unidirectional but it is using the vehicle parameters that are constantly being updated and sent to the GCS.
So, I somehow need to divide the information, inside the RPi, coming from the pixhawk into two separate paths - one is to the GCS and the other to "loopback" into the RPi so that the parameters are the updated ones.
So now the question, would you recommend following your instructions and will it solve my issue?
Thanks

#677 last comment full information

@AsternA Congratulations to you for finding the solution you wanted!

@pietrodn Hi pietro,
I was reading your discussion and it is very similar to what I need to do ! I want to use the Dronekit as a proxy between the QGC and the Autopilot. I need to receive the waypoints from the QGC by the Dronekit, then modify the waypoints and the forward the new waypoints to the autopilot. The construction is like yours:
UAV (Autopilot) <==== (serial) ====> DroneKit <==== (MAVLink UDP stream) ====> QGroundControl
First I started to establish the connection between the QGC and the Dronekit, without any Autopilot. In fact from the QGC point of view, the Dronekit is the autopilot. I followed all the same as you explained but still the QGC does not recognize the Dronekit.
This is what I configured from QGC side:

I think that the problem is that you're trying to initialize a MAVConnection without a Vehicle.
The MAVConnection object does not send any message by itself, not even heartbeats. So, QGC won't connect.

I updated my question.
Ok, so what do you think I need to do in order to first establish the connection between QGC and Dronekit ? (QGC see the Dronekit as Autopilot)
Or is it needed that I do that? or directly establish the two connections? If I do so, Is it possible to modify the waypoints received from QGC?

I think that as a first step you should connect DroneKit to the autopilot and then setup the relay to QGC.
Honestly I don't know how to edit the messages in-flight, I'm only using this method to perform manual setup on my DroneKit-controlled drone.

@pietrodn  when I connect the Dronekit and the copter (I use dronekit-sitl copter), the connection will be established and I can upload the waypoints, but I was afraid that maybe the QGC is directly sending the waypoints to the Autopilot and there is no relay between ! because I thought that I have to use a command from the Dronekit to upload the waypoints to the autopilot, but now when I upload the waypoints from QGC, the autopilot also receives the waypoints and mission can be started ! in fact I have no control to forward or not to forward the received waypoints from the QGC to the autopilot. What do you think? is there any way to manage this issue? any idea?

Yes, that's precisely the point: in my setup QGC sends the messages directly to the autopilot, in the sense that the system ID in the MAVLink messages is the autopilot's one.
Maybe you can play with the forward_message decorator (see here) to manipulate the messages coming and arriving from QGC. But again, I've never attempted it, so I'm unable to give you detailed instructions. :-)

Thank you very much for your answers :-)
by the way, do you have any other idea, how to create a proxy, which receives the data from QGC and then after modification, forwards them to the Autopilot? what about Pymavlink? have you ever had any experiences?

Hi @pietrodn ,
As, I could not find a way to manipulate the messages coming from the QGC by dronekit, I am now trying to create the same thing with Pymavlink library. It is possible to receive and manipulate the messages with pymavlink library. The only problem is that now I can connect to the vehicle and also can connect to the QGC from my proxy, but the QGC does not recognize the vehicle to be able to send the messages. I receive heartbeat from both the vehicle and the QGC.
I think I need the same thing that you used for dronekit
vehicle._handler.pipe(udp_conn) udp_conn.master.mav.srcComponent = 1  # needed to make QGroundControl work!
but working in pymavlink. Do you have any idea how can I solve it?

Hi @pietrodn
I created the proxy as following:
I have created the interfaces as you described to me in Python. Here is the code:
      `gcs_conn = mavutil.mavlink_connection('tcpin:localhost:15795')
       gcs_conn.wait_heartbeat()
       print("Heartbeat from system (system %u component %u)" % (gcs_conn.target_system, gcs_conn.target_system))
       vehicle = mavutil.mavlink_connection('tcp:localhost:5760')
       vehicle.wait_heartbeat() # recieving heartbeat from the vehicle
       print("Heartbeat from system (system %u component %u)" % (vehicle.target_system, vehicle.target_system))
       while True:
                 gcs_msg = gcs_conn.recv_match()
                 if gcs_msg == None:
                        pass
                 else:
                        vehicle.mav.send(gcs_msg)
                        print(gcs_msg)

                 vcl_msg = vehicle.recv_match()
                 if vcl_msg == None:
                        pass
                 else:
                        gcs_conn.mav.send(vcl_msg)
                        print(vcl_msg)

`
First I just want to receive and forward the messages ! But it still does not work and when I run the code I get this:

Can you help me here?

I think you found a bug in pymavlink! Please do the print(vcl_msg) before the send so we can understand which kind of strange message we are dealing with...

@pietrodn Thank you for your response.
I put the the print(vcl_msg) before the send and I received a lot of None among the messages that you see above!
you sure that I am using the right command to send the messages ?
How can I find that the messages I am sending, will be received in the destination (vehicle or QGC)?
What do you think if I send the received messages one by one? I mean e.g. I receive from the vehicle are as following:

Then I send them like:
vehicle.mav.gps_raw_int_send(time_usec = gcs_conn.messages['HOME'].time_usec, fix_type = gcs_conn.messages['HOME'].fix_type, lat = gcs_conn.messages['HOME'].lat, lon = gcs_conn.messages['HOME'].lon, alt = gcs_conn.messages['HOME'].lat, eph = gcs_conn.messages['HOME'].eph, epv = gcs_conn.messages['HOME'].epv, vel = gcs_conn.messages['HOME'].vel, cog = gcs_conn.messages['HOME'].cog, satellites_visible = gcs_conn.messages['HOME'].satellites_visible)
to send the HOME messages receiving from the vehicle to the QGC.
what do you think?

I put the the print(vcl_msg) before the send and I received a lot of None among the messages that you see above!

Are you sure? How can they be None, if you explicitly check for it before?

How can I find that the messages I am sending, will be received in the destination (vehicle or QGC)?

You need to check on the receiving side :-)

What do you think if I send the received messages one by one?

Not a good idea, it's better to use a generic send method.

Yes it is strange but there are a lot of None among the messages that I you see in the first screenshot. Thats the reason I put a if statement to pass if the message is None. vcl_msg is the message coming from the vehicle and is strange that the vehicle is sending None!

It’s fine that recv_match returns None, since it’s a non-blocking function: if there are no bytes on the receive buffer, the method doesn’t wait and returns None.
So you have to check but it isn’t a problem.

Yes, but the question is how I can check e.g. in the vehicle side?
OK, I forget about it ;-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@pietrodn so what was strange when I said it is returning a lot of None? I am confused :-)
By the way,
Any idea, how can I make the QGC to recognize the vehicle? I see that the connections are established and data are transferring ! (before the error occurs) ! But why the QGC does not recognize the vehicle?

@pietrodn so what was strange when I said it is returning a lot of None? I am confused :-)

Sorry, I didn't make myself clear. Print the message inside the if block, so that you can see which message makes the application crash.

@pietrodn  Sorry but I do not get where you mean! previously (first screen shot) it was inside the if statement that the error is clear in the screen shot. Then I put it outside and the None messages also were included. Now I don't know where else exactly you mean! Can you show me in the code?

Ok. You did:
vcl_msg = vehicle.recv_match()
if vcl_msg == None:
    pass
else:
    gcs_conn.mav.send(vcl_msg)
    print(vcl_msg)

Your program crashed on send(), but since the print() is after the send(), I don't know which message caused the program to crash.
My suggestion is to do:
vcl_msg = vehicle.recv_match()
if vcl_msg == None:
    pass
else:
    print(vcl_msg)
    gcs_conn.mav.send(vcl_msg)

So that the last printed line shows the problematic message.

@pietrodn  I got  it.
Here it is:

There is a 'BAD_DATA' before the program crashes.  I filter the bad data ?

@pietrodn I change the if condition to the following:
`
    if vcl_msg == None or isinstance(vcl_msg, pymavlink.dialects.v10.ardupilotmega.MAVLink_bad_data):

              pass

    else:

              print(vcl_msg)

              gcs_conn.mav.send(vcl_msg)`

and I got the following without any crash:

But the problem is that the QGC does not recognize the vehicle and so nothing happens! just the heartbeats !

It suspect that QGC only supports PX4/ArduPilot for some things and won't recognise systems that advertise as something else. It may also require that your system implement some minimal set of autpilot protocols - e.g. parameter protocol.

Thank you @hamishwillee  for your comment. In my application, I am trying just to forward whatever I receive from the QGC to the vehicle and vise versa. So, When the QGC is receiving all the messages that it receives in the direct connection, why it should not recognize the vehicle?!
What do you mean that my system require to implement some minimal set of parameters? can you explain more? what do you suggest to do then?

@pietrodn , @hamishwillee  I created a direct connection between the vehicle and QGC and investigated which messages are being transferred. Here it is:

But when I put the proxy to receive and send the messages, these are the transferred messages:

Therefore, QGC is not asking for some messages! and that's the reason that it does not recognize the vehicle !
What do you think? How can I deal with this?

I see that you are communicating with QGC via TCP. Try UDP instead, and check that the port is open (Wireshark, netcat...)

Yes, @pietrodn advice is good - I don't think PX4 supports TCP connections. Certainly SITL does not.

@pietrodn @hamishwillee  I replaced the communication between the proxy and QGC with UDP connection. I received the same messages as following:

But, as I know, the UDP connection is not bidirectional ! so, I may need to create another connection for returning the messages from the proxy to the QGC ! what do you think?

UDP packets have a source (port, ip) tuple and a destination (port, ip) tuple. So it is possible to "answer" to an unicast UDP datagram (think about DNS, for example).
In this case the communication is bidirectional, as you can see. QGC is sending data on UDP port 15667.

@pietrodn I understood !
the problem here must be the lack of some messages in gcs_conn.messages ! any other advises? or idea?

@pietrodn What about if I modify the pipe function (I mean here: vehicle._handler.pipe(connection)), leading not to forward messages directly ! I mean, instead of forwarding the messages, first modify them and then forwarding ! Is it possible?

And yes, I tried both on a real UAV and on a PX4 SITL. On the SITL, however, I had to disable the automatic listening on UDP port 14540 on QGC, otherwise QGC will try to connect directly to the SITL and not to the forwarded connection.

Hi Pietro, how exactly did you manage this?

Sorry but I don't work with drones anymore and forgot these details 😞
I think you can achieve it by changing the connection settings in the QGC UI.

@giamo152 That's odd, since QGC listens on 14550. If you're working on PX4 I strongly recommend moving to MAVSDK as it is properly supported: https://mavsdk.mavlink.io/main/en/index.html

Thank you for your input @hamishwillee. I am essentially trying to spy on the communication between QGC and my PX4 (SITL).  From my little understanding, the examples of this discussion should help me do that. Am I correct? Is there even a simpler way to directly print this information exchange, either from QGC or PX4 without having to use dronekit?
Many thanks

@giamo152 In that case you should have created a separate issue rather than adding to this one. The answer to your question is "maybe".
But a better one is to use Wireshark: https://mavlink.io/en/guide/wireshark.html


Automated cherry pick of #9500

Cherry pick of #9500 on release-6.3.
/cc  @M-ZubairAhmed
NONE

Will try to auto merge this PR once all tests and checks are passing. This might take up to an hour.

Trying to auto merge this PR.

Pull Request successfully merged
SHA: 23278fa2e1765095559fd91856fdfe3402251680


openweathermap set to metric only

The queryUri in the getWeatherData method in /apis/openweathermap.js explicitly sets the units field as metric, and the constructor itself doesn't even seem to offer units as a parameter.
		const queryUri = url + "?units=metric&lang=" + this.language + "&lat=" + this.locationGeo[0] + "&lon=" + this.locationGeo[1] + "&appid=" + this.apiKey;

A couple of points here:

I haven't tried telling this plugin to use a different unit than metric
I do know that HomeKit internally only uses metric values and it leaves it up to the clients to convert to units that are configured via platform settings or app settings.
This plugin seems to assume that all values provided by data providers (eg OpenWeatherMap) are metric
If the user has configured via this plugin's settings to use different units, then it converts all values to those units just before providing it the Homebridge. Conversion convenience functions are in util/characteristics.js

So, IMO, the above mentioned code is correct.

Closing this as resolved.


remove sudo and added root check

Removed sudo because it made no sense running the script not as root
when nearly all of the commands where run as root.

Thanks for the contribution! I will make a matching change for the 16.04 scripts.


elastalert greater than operator not working

I am trying to write rule which checks for duration field and if duration value is greater than 5 seconds i want to generate alert.
Below is what i am using
name: alert on duration value higher than 5 sec ( 5000 ms )
type: any
index:  log-st-*
filter:
- query:
    query_string:
            query: "log_json.logType: AUDIT AND log_json.performance.elapsedDuration: >5000"

When i run this query on Kibana under discover tab - i am able to get logs as expected but with elastalert its not getting any hit as below.
INFO:elastalert:Ran alert on duration value higher than 5 sec ( 5000 ms )  from 2019-06-13 15:06 CDT to 2019-06-13 15:21 CDT: 0 query hits (0 already seen), 0 matches, 0 alerts sent

Please show the full JSON of a document you expect to match AND an elastalert log line showing it ran over the same time period.

I'm experiencing the same issue. Elastalert appears to format queries (of alert type "any") into a "query_string". Querying for the same events in Kibana using the same query produces different results. This seems to be because under the hood Kibana is using a more structured bool range query instead.
Below is a comparison of the same query on in Kibana written in the search bar as "signal.rule.risk_score>90 AND event.dataset:prod_ssh.anomaly" and another from Elastalert rule type 'any' written in the query field of the rule as the same.
Kibana's query:
"query": {     "bool": {       "must": [],       "filter": [         {           "bool": {             "should": [               {                 "range": {                   "signal.rule.risk_score": {                     "gt": 90                   }                 }               }             ],             "minimum_should_match": 1           }         },         {           "match_phrase": {             "event.dataset": "prod_ssh.anomaly"           }         },         {           "range": {             "@timestamp": {               "gte": "2020-08-27T00:00:00.000Z",               "lte": "2020-08-28T17:44:20.959Z",               "format": "strict_date_optional_time"             }           }         }       ],       "should": [],       "must_not": []     }   }
Elastalert rule type "any" query:
"query": {     "bool": {       "filter": {         "bool": {           "must": [             {               "range": {                 "@ingest_timestamp": {                   "format": "date_optional_time",                   "gt": "2020-08-27T00:00:00Z",                   "lte": "2020-08-28T17:44:20Z"                 }               }             },             {               "query_string": {                 "query": "signal.rule.risk_score>90 AND event.dataset:prod_ssh.anomaly "               }             }           ]         }       }     }   }

@bharatm89 I got around this by adding a "range" filter query below my initial "query" filter. Please see the documentation on adding additional filters. https://elastalert.readthedocs.io/en/latest/recipes/writing_filters.html#range


Removed binary formatter dependency for Sha256 hashing

I have this as an alternative to #3282
Unlike #3282, this PR does introduce a breaking change, in that the same input will yield a different output.
This is because (as described by @secretlyagoblin the BinaryFormatter gives us more than just the string value bytes, but also several bytes of type information) With this implementation, I've aligned the hashing behaviour with our Python SDK, which simply gets the UTF-8 encoded bytes.
I think we should consider accepting this breaking change, the implementation here is much simpler than having to patch in prefix as specified here https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nrbf/eb503ca5-e1f6-4271-a7ee-c4ca38d07996, is already exactly what we're doing in Python SDK, and means there is less code for us to maintain.

I have benchmarked it against our current implementation, and it is a tad faster with both "small" and "long" data sets.

Method
input
Mean
Error
StdDev
Gen0
Gen1
Allocated

BinaryFormatter
long(...)8o7y [471]
1,463.3 ns
18.65 ns
16.54 ns
0.2975
0.0019
4992 B

Utf8
long(...)8o7y [471]
956.4 ns
10.23 ns
9.57 ns
0.1259
-
2112 B

BinaryFormatter
small(...)0sdfa [50]
1,199.7 ns
20.45 ns
18.13 ns
0.2403
-
4032 B

Utf8
small(...)0sdfa [50]
703.1 ns
8.39 ns
7.01 ns
0.1011
-
1696 B

The remaining thing for us to decide, are we happy to make this breaking change (maybe in a 2.19 release)
The biggest effect of this is diffing in the viewer will not be useful between prior and post change versions.
Or, We can make this change in a later release where we can communicate a breaking change clearer (e.g. in the DUI3 connectors release). We can always publish a nuget in the interim to unblock the Net8 users who can't

@secretlyagoblin I'd be curious about what you think about this option, your PR has the advantage that its non-breaking.
But, If we decide a breaking change is acceptable, I think keeping things simple (and aligned with specklepy) would be a nice long term solution.

For what it's worth, the "breaking" change part I discussed with @JR-Morgan today and we agreed to "take it on" affects only potential "fast" diffing based on hash + applicationId checks, like we do in our viewer. In other words, "the same input will yield a different output" will only apply on this swap - future commits versions will not suffer from this, and hashing will be consistent on a forward looking basis (even more so, considering specklepy).
(e.g., wall A has been sent previously, if it's going to be sent again it will get a new hash, hence confounding potential workflows.)
I am highly inclined to make this breaking change, as otherwise we increase surface area.

@JR-Morgan, @didimitrie, it's your call, but if you haven't already, I'd suggest writing a policy on breaking changes to that you can refer to in these situations.
To be clear, I'm happy with either approach as I can't think of anything that this would break that couldn't be easily communicated (and our Rhino users will be moving to R8 with 2.19 anyway so there's some other stuff going on) and I'm in no way precious about the code that I've written.
Also if you're clear that you're trying it in the new pre-releases, you'd hopefully catch any edge-case power-users.
I will note that:

my PR increases the complexity of the codebase, but would be invisible to users of speckle,
the solution here simplifies the codebase, but does affect the end users of speckle,

So, it really comes down to your philosophy! Good luck :D


Edit color function

Hi! I really like this neat view of timetable. I just feel like it would be nice when user creates a schedule he can edit the color of the schedule as well, same way as setting name, place, start time etc.
Thank you for your nice project and your effort.

Hi, thank you for your issue.
I'll try to apply this requirement to the next version :)

Hello! Great Timetable! Any Update on this function?


Invalid argument: During Variant Host->Device Copy: non-DMA-copy attempted of tensor type: string

Opening a new bug per @nikitamaia's suggestion. See discussion in #28007, in which she confirmed the bug. Bug only presents when using GPU, not CPU.
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 20.04.2 LTS
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): 2.4.1
Python version: 3.8.5
Bazel version (if compiling from source): n/a
GCC/Compiler version (if compiling from source): n/a
CUDA/cuDNN version: 2.4.1/8
GPU model and memory: GeForce GTX 1050 Ti computeCapability: 6.1, 3.95GiB

Describe the current behavior
Error during function call for compiled function:
Invalid argument: During Variant Host->Device Copy: non-DMA-copy attempted of tensor type: string
Describe the expected behavior
Compiled function call should succeed like uncompiled function call.
Standalone code to reproduce the issue
import tensorflow as tf

def _get_char_flags(char_tensor):
    char = char_tensor.numpy().decode()
    return char.isalpha(), char.isspace()

@tf.function  # <--------------- Runs fine with this line commented out.
def tf_split_text(text):
    tf.assert_rank(text, 0)
    tf.debugging.assert_type(text, tf.string)

    chars = tf.strings.unicode_split(text, input_encoding='UTF-8')
    is_alpha, is_space = tf.map_fn(lambda char: tf.py_function(_get_char_flags, char, Tout=[tf.bool, tf.bool]),
                                   (chars,), dtype=tf.bool, parallel_iterations=True,
                                   fn_output_signature=[tf.bool, tf.bool])

    is_alpha = tf.concat([is_alpha, [False]], axis=0)
    is_space = tf.concat([is_space, [True]], axis=0)

    is_special = ~(is_alpha | is_space)
    is_non_alpha = ~is_alpha
    is_non_space = ~is_space

    was_special = tf.concat([[False], is_special[:-1]], axis=0)
    was_non_alpha = tf.concat([[True], is_non_alpha[:-1]], axis=0)
    was_non_space = tf.concat([[False], is_non_space[:-1]], axis=0)

    any_to_special = is_special
    non_alpha_to_non_space = was_non_alpha & is_non_space
    token_start_flags = any_to_special | non_alpha_to_non_space
    token_start_indices = tf.where(token_start_flags)[:, 0]

    special_to_any = was_special
    non_space_to_non_alpha = was_non_space & is_non_alpha
    token_end_flags = special_to_any | non_space_to_non_alpha
    token_end_indices = tf.where(token_end_flags)[:, 0]

    tf.debugging.assert_equal(tf.size(token_start_indices), tf.size(token_end_indices))

    preceding_space = tf.concat([[False], is_space[:-1]], axis=0)

    tokens = tf.strings.substr(text, token_start_indices, token_end_indices - token_start_indices, unit='UTF8_CHAR')
    has_preceding_space = tf.gather(preceding_space, token_start_indices)

    tf.assert_rank(has_preceding_space, 1)
    tf.assert_rank(tokens, 1)
    tf.assert_equal(tf.reduce_sum(tf.map_fn(tf.strings.length, tokens, fn_output_signature=tf.int32)) +
                    tf.reduce_sum(tf.cast(has_preceding_space, tf.int32)),
                    tf.strings.length(text))
    return has_preceding_space, tokens

text = tf.constant('hi there', tf.string)
preceding_spaces, words = tf_split_text(text)
print(words)

Other info / logs
Traceback:
Traceback (most recent call last):
  File "/home/hosford42/PycharmProjects/ImageParser/error.py", line 56, in <module>
    preceding_spaces, words = tf_split_text(text)
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/eager/def_function.py", line 828, in __call__
    result = self._call(*args, **kwds)
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/eager/def_function.py", line 894, in _call
    return self._concrete_stateful_fn._call_flat(
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/eager/function.py", line 1918, in _call_flat
    return self._build_call_outputs(self._inference_function.call(
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/eager/function.py", line 555, in call
    outputs = execute.execute(
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/eager/execute.py", line 59, in quick_execute
    tensors = pywrap_tfe.TFE_Py_Execute(ctx._handle, device_name, op_name,
tensorflow.python.framework.errors_impl.InvalidArgumentError: 2 root error(s) found.
  (0) Invalid argument:  2 root error(s) found.
  (0) Invalid argument: During Variant Host->Device Copy: non-DMA-copy attempted of tensor type: string
  (1) Invalid argument: During Variant Host->Device Copy: non-DMA-copy attempted of tensor type: string
0 successful operations.
0 derived errors ignored.
	 [[{{node map_1/TensorArrayUnstack/TensorListFromTensor/_96}}]]
	 [[map_1/while/loop_body_control/_61/_107]]
  (1) Invalid argument:  2 root error(s) found.
  (0) Invalid argument: During Variant Host->Device Copy: non-DMA-copy attempted of tensor type: string
  (1) Invalid argument: During Variant Host->Device Copy: non-DMA-copy attempted of tensor type: string
0 successful operations.
0 derived errors ignored.
	 [[{{node map_1/TensorArrayUnstack/TensorListFromTensor/_96}}]]
0 successful operations.
0 derived errors ignored. [Op:__inference_tf_split_text_265]

Function call stack:
tf_split_text -> tf_split_text

Was able to reproduce the issue with TF v2.3 and TF v2.4. Whereas with TF-nightly, Colab doesn't detect GPU.
Please check the linked gist for reference. Thanks!

This prints tf.Tensor([b'hi' b'there'], shape=(2,), dtype=string) on tf-nightly, so I'm assuming this is already fixed.
@hosford42 I'm closing the issue for now, but please reopen if you find that it is not fixed.

@sanjoy, was that when using the GPU? It doesn't occur with CPU. See @amahendrakar's earlier comment:

Whereas with TF-nightly, Colab doesn't detect GPU.

@sanjoy, was that when using the GPU? It doesn't occur with CPU. See @amahendrakar's earlier comment:

This was on my local machine and TF was able to use the GPU.  Can you confirm that you're able to reproduce the problem with tf-nightly?

I can't install tf-nightly right now. I may be able to get back to you on this in a few days, though. Thanks, all, for looking at this.

hi @geetachavan1,
I saw you mark this issue Done in TF2.5.0.
But I can reproduce it in TF2.5.0 Colab.  This issue will be reproduced in TF2.5.0-GPU, But not in TF2.5.0-CPU.
Please Help.

I just tried this in colab with TF2.7 and I do not get the error. I believe this is fixed.


Support for Auto Scale notifications

Is this recent? Looks like it. Love this project and I think I can contribute what I put together for my team's own needs. Primitive-as-would-imagine but willing to make this my baby as much as a can.
@arabold thanks for taking the time on this project. Gonna get some dinner and coffee and put together something for you to review. Thanks again!

Hi @nickallevato , I'm happy for any help. If you have any ideas, feature requests, or even better a pull request, let me know. The open tasks here in this list are basically serving as a to do list for the project.

Thanks for implementing the Auto Scaling parser @homeyjd, this issue can be closed then I presume?

Seems so :)


Display a different warning for the alpha website

@yann300 since you have merged this, a change should be made which pushes master to remix-ide-alpha instead of yann300.

Well I guess should wait first until the build is pushed to yann300 to start displaying the popup :)


HTTPS Certificate question

Hello, I have issues with the Load balancing part where I get an index error fetching certificates since there are none in my account. I can't seem to find any oci_load_balancer_certificate instance on the config that lets me wonder if we don't have to import it manually, is that correct ?
│ Error: Invalid index │  │   on modules/nextcloud/load_balancer.tf line 72, in resource "oci_load_balancer_listener" "https_443_ingress": │   72:     certificate_name        = data.oci_load_balancer_certificates.certs.certificates[length(data.oci_load_balancer_certificates.certs.certificates) - 1]["certificate_name"] │     ├──────────────── │     │ data.oci_load_balancer_certificates.certs.certificates is empty list of object │  │ The given key does not identify an element in this collection value: a negative number is not a valid index for a sequence.
Also, quick update about my last issue : I did create a new OCI account and I can create NAT Gateways now

thanks for fixing it using dynamic blocks!


Use theme color

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#299  👈
#298
#297
#295
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @ksharma-xyz and the rest of your teammates on  Graphite


Add Fall for Greenville Routes

More discussion here https://github.com/codeforgreenville/trolley-tracker/issues/84 and some files https://drive.google.com/drive/folders/0B1Wxj_5D6dLNfnFEeXo3a3pFVl9VVmxmWWpaNElCaXJrUXhxNi0ycVdOb3Y2SzRrWExFRTA

Add routes and updated schedule

JANUARY 2016 BSWA Schedule.pdf
For your eyes only: Attached is the schedule for the Well in January.


Add new icon, and update readme to link to Nuget

Love the new icon! Can you have the url for the icon point to the one that will be merged into this repo?

Happy to see a Xamarin MVP interested in this library :)
Would you mind telling me a little about how you became an MVP?

I've updated the URL to this repo!

Merged. Thanks! :+1:

Join me for a chat on Slack to talk about other stuff: https://xamarinchat.herokuapp.com/ ;)


Colorize code error

When you use """ to escape a double quote inside a string the code that follow are colorized as part of string even when the string had ended, like showed below:

I will look into this.

If you have solution for this, feel free to create Pull Request.


No glyphs on opening solution

Is this a bug?
Repro steps:

Open TddStudio for a solution.
No glyphs appear.

Changed some file. The glyphs dont change color.

works fine.


Chainer should depend on protobuf >= 2.6.0

apt python-protobuf is 2.5.0 on ubuntu trusty, and I found someone who encountered this problem.
% pip show protobuf
Name: protobuf
Version: 2.5.0
Summary: Protocol Buffers
Home-page: http://code.google.com/p/protobuf/
Author<EMAIL_ADDRESS>Author-email<EMAIL_ADDRESS>License: New BSD License
Location: /usr/lib/python2.7/dist-packages
Requires:

% python -c 'import chainer.links.caffe.protobuf2.caffe_pb2'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "chainer/links/caffe/__init__.py", line 1, in <module>
    from chainer.links.caffe import caffe_function
  File "chainer/links/caffe/caffe_function.py", line 37, in <module>
    from chainer.links.caffe.protobuf2 import caffe_pb2 as caffe_pb
  File "chainer/links/caffe/protobuf2/caffe_pb2.py", line 10, in <module>
    from google.protobuf import symbol_database as _symbol_database
ImportError: cannot import name symbol_database

% sudo pip install 'protobuf==2.6.0'
The directory '/home/wkentaro/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
The directory '/home/wkentaro/.cache/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Collecting protobuf==2.6.0
/usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:318: SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/security.html#snimissingwarning.
  SNIMissingWarning
/usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:122: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
  Downloading protobuf-2.6.0.tar.gz (187kB)
    100% |████████████████████████████████| 194kB 3.4MB/s
Requirement already satisfied: setuptools in /usr/local/lib/python2.7/dist-packages (from protobuf==2.6.0)
Requirement already satisfied: appdirs>=1.4.0 in /usr/local/lib/python2.7/dist-packages (from setuptools->protobuf==2.6.0)
Requirement already satisfied: packaging>=16.8 in /usr/local/lib/python2.7/dist-packages (from setuptools->protobuf==2.6.0)
Requirement already satisfied: six>=1.6.0 in /usr/local/lib/python2.7/dist-packages (from setuptools->protobuf==2.6.0)
Requirement already satisfied: pyparsing in /usr/local/lib/python2.7/dist-packages (from packaging>=16.8->setuptools->protobuf==2.6.0)
Installing collected packages: protobuf
  Found existing installation: protobuf 2.5.0
    Uninstalling protobuf-2.5.0:
      Successfully uninstalled protobuf-2.5.0
  Running setup.py install for protobuf ... done
Successfully installed protobuf-2.6.0

% pip show protobuf
Name: protobuf
Version: 2.6.0
Summary: Protocol Buffers
Home-page: http://code.google.com/p/protobuf/
Author<EMAIL_ADDRESS>Author-email<EMAIL_ADDRESS>License: New BSD License
Location: /usr/local/lib/python2.7/dist-packages
Requires: setuptools
wkentaro at hoop in /tmp/chainer tm 16:24 on use_protobuf_ge_2.6.0
% python -c 'import chainer.links.caffe.protobuf2.caffe_pb2'

Thank you. I confirmed that chainer does not work with protobuf 2.5.


fix capitalised letter

@beyond2void have you checked in the paper that they are correct now?

@beyond2void have you checked in the paper that they are correct now?

Yes, already checked.


Command displayed as block which makes it overflowed.

Display error here: http://z42.readthedocs.org/zh/latest/mush.html#docker

It can be fix by changing tt element from block to inline-block -- change these lines to:
  tt
    @extend code
    color: $black
    display: inline-block
    big, em
      font-size: 100% !important
      line-height: normal

Warning: Not tested.

@snide
My code really fixed this issue, but while building multi files but sass are changed:
    modified:   sass/_theme_rst.sass
    modified:   sphinx_rtd_theme/static/css/theme.css
    modified:   sphinx_rtd_theme/static/css/theme.css.map

Should I add they into commit or not?

Fixed in cb3c08a


bug: HOSTEDCP-569 HC controller blocked reconcile verifying releaseImage

This bug happens when you try to provision a HC and you have not created the PullSecret. The reconcile process will try to pull the ReleaseImage and verify it, but it cannot because cannot recover the Pull Secret.
With the current verification process the controller returns 'nil' and after 7 tries, the reconcile process gets blocked.
The fix validates this situation of the missing pull secret before this second check, but in this case the controller returns an error, which made possible the controller to wait indefinitely until the PullSecret gets created by the user.
Signed-off-by: Juan Manuel Parrilla Madrid<EMAIL_ADDRESS>What this PR does / why we need it:
Fixes: HOSTEDCP-569
Checklist

[X] Subject and description added to both, commit and PR.
[X] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

Ha, I just ran into this as well. Nice find. Will review when CI is fixed.

and after 7 tries, the reconcile process gets blocked.

Where is this 7 coming from?
Is the issue that the controller doesn't notice when the secret is created afterwards? If so we should make sure it triggers reconciliation, we are already watching secrets. We should possibly contemplate this use case in the reconciliation filtering enqueueParentHostedCluster https://github.com/openshift/hypershift/blob/main/hypershift-operator/controllers/hostedcluster/hostedcluster_controller.go#L191-L193
Erroring here would requeue in loop and increase the rate limiter.

and after 7 tries, the reconcile process gets blocked.

Where is this 7 coming from?
Is the issue that the controller doesn't notice when the secret is created afterwards? If so we should make sure it triggers reconciliation, we are already watching secrets. We should possibly contemplate this use case in the reconciliation filtering enqueueParentHostedCluster https://github.com/openshift/hypershift/blob/main/hypershift-operator/controllers/hostedcluster/hostedcluster_controller.go#L191-L193 Erroring here would requeue in loop and increase the rate limiter.

Good question, probably is nothing in purpose but when it returns nil instead of an handled error, it ends in a stuck situation.
I think there are better ways to handle the issue as I'm PRing, so I will take a look to the watchers instead of delegate in the RateLimiter as I'm doing now.

Thanks!
/approve
/lgtm


[BUG] The Commented guns in howitzer.lua errors when they shoot

sv: Wire error (Entity [365][acf_gun] by Player [3][LaikaWuff]):
addons/acf-3/lua/entities/acf_gun/init.lua:419: bad argument #2 to '__mul' (number expected, got nil)
stack traceback:
    [C]: in function '__mul'
    addons/acf-3/lua/entities/acf_gun/init.lua:419: in function 'Shoot'
    addons/acf-3/lua/entities/acf_gun/init.lua:295: in function <addons/acf-3/lua/entities/acf_gun/init.lua:286>
    [C]: in function 'xpcall'
    addons/wire/lua/wire/server/wirelib.lua:58: in function 'TriggerInput'
    addons/wire/lua/wire/server/wirelib.lua:530: in function 'Wire_TriggerOutput'
    addons/wire/lua/entities/gmod_wire_input.lua:76: in function 'func'
    lua/includes/modules/numpad.lua:82: in function 'FireImpulse'
    lua/includes/modules/numpad.lua:110: in function 'Activate'
    gamemodes/sandbox/gamemode/player.lua:205: in function <gamemodes/sandbox/gamemode/player.lua:203>

Anything other information you believe might help with this one? I was able to fire both the 240mm and the 290mm with no issues.

Will see if I can repro with whatever wiring that guy did.

There's probably some set of steps that cause the bulletdata to reset or something. I'm not getting any more info so will have to just watch for this bug.

Closing because its not specific to the commented guns.


IPython mode: load cell magics from configuration

Searched for: cell magics, Jupyter, IPython, configuration, pyproject.toml
ruff version: 0.7.1

In handling IPython magics, the list of magics that contain Python code to be checked/formatted is currently hard-coded.
Since loads of extensions (especially profiling, etc.) and even users can define these magics interactively, it seems like the list of cell magics that should be treated as containing Python code should be loaded from configuration, so users can lint their notebooks without a patch to ruff itself.
nbqa has this feature and can be used to run ruff on the contents of arbitrary cell magics, with the same default of assuming unrecognized cell magics don't contain Python code. A similar feature in ruff itself would be great!
Example notebook with the cells:
from IPython import get_ipython

def decorate_cell(line, cell):
    print("before")
    get_ipython().run_cell(cell)
    print("after")

get_ipython().register_magic_function(decorate_cell, "cell")

%%decorate_cell
x = 5

print(x) # <- F821 false positive

This seems like a reasonable request to me.
Unlike nbqa, Ruff is able to differentiate between line magics and cell magics. Ruff is able to parse out the line magics and continue parsing any other lines surrounding these line magics. The hard coded values are specific to cell magics and Ruff ignores them because they're applied on the entire cell. I'm sure you're aware of this but just re-iterating for context.
I'd prefer to have an alternate option name like allowed_cell_magics / cell_magics along with the extend_* version to make it clear that this is related to the "cell magics". This option should be at the top level [tool.ruff] because both the linter and the formatter will consider them as is done so today. The non-extend option would have the default value that is hard coded today.

I'm also not sure if ruff handles it, but cell magics can be arbitrarily nested because the code-running cell magics (many of them anyway) call run_cell, which in turn may call cell magics, etc.. This is a valid cell containing Python code that should be recognized as a candidate for Python formatting assuming prun, time, and timeit are understood to be cell magic functions that accept code:
%%prun
%%time
%%timeit
for i in range(5):
    _env = %env

whereas this one should not format the contents, since sql is not a Python-code cell magic:
%%prun
%%sql
SELECT * FROM TABLE

I think we should handle it correctly because we check if any of the lines contains a cell magic which might not have valid Python code:
https://github.com/astral-sh/ruff/blob/bd0d782b76d75c02668741c64303f6164910f8f2/crates/ruff_notebook/src/cell.rs#L206-L207


does it change the voice on a song? Does it automatically do stems to change the voice? How can you use it command line?

?

Yes
No
https://github.com/IAHispano/Applio/blob/main/core.py CLI


[DOCS] Suggested Reading bug fix

Notes for Reviewers
This PR fixes #9996

Signed commits

[x] Yes, I signed my commits.

🚀 Preview for commit bd69f5dfaa5d49c13edc26d9452dece8e55f5530 at: https://65aa61cdde06af14124866fe--meshery-docs-preview.netlify.app

@sandramsc, that could be another issue because I am not writing descriptions, I am fetching those descriptions from the front matter of Markdown pages.

🚀 Preview for commit 85835ce43684608060588b326e2724df0d60f72f at: https://65ab7628f5229e6236ff5b05--meshery-docs-preview.netlify.app

did you mean to write "...managed as a state machine..."?
the word environment in lowercase

Yes, ideally, both of these are updated in accordance with your suggested change, @sandramsc

did you mean to write "...managed as a state machine..."?
the word environment in lowercase

Oh, the reason that Environments and Credentials are uppercased is that we're treating them as keywords - Meshery core constructs.
We need to either uppercase all the time or lowercase all the time.

@sandramsc's feedback incorporated.

🚀 Preview for commit 05b96f60a3ed795ace1717087cd86e40e69b16dd at: https://65ab84107077ff6b0f4d98e7--meshery-docs-preview.netlify.app


Script error when pressing tab to complete

Describe the bug
When I use tab for auto completion an error occurs.
To Reproduce
Open a shell, press tab.
Expected behavior
The error not to occur.
Shell output
~/.config/fish/functions/_fifc_action.fish (line 29): array indices start at 1, not 0.
        if test -n "$$comp[$i][1]"
                            ^
in function '_fifc_action' with arguments 'source'
	called on line 1 of file ~/.config/fish/functions/_fifc.fish
in command substitution
	called on line 26 of file ~/.config/fish/functions/_fifc.fish
in function '_fifc'
~/.config/fish/functions/_fifc_action.fish (line 34): array indices start at 1, not 0.
        if test -n "$$comp[$i][2]"
                            ^
in function '_fifc_action' with arguments 'source'
	called on line 1 of file ~/.config/fish/functions/_fifc.fish
in command substitution
	called on line 26 of file ~/.config/fish/functions/_fifc.fish
in function '_fifc'
~/.config/fish/functions/_fifc_action.fish (line 46): array indices start at 1, not 0.
        set _fifc_extract_regex "$$comp[$i][7]"
                                         ^
in function '_fifc_action' with arguments 'source'
	called on line 1 of file ~/.config/fish/functions/_fifc.fish
in command substitution
	called on line 26 of file ~/.config/fish/functions/_fifc.fish
in function '_fifc'
~/.config/fish/functions/_fifc_action.fish (line 55): array indices start at 1, not 0.
        else if test "$action" = source; and test -n "$$comp[$i][5]"
                                                              ^
in function '_fifc_action' with arguments 'source'
	called on line 1 of file ~/.config/fish/functions/_fifc.fish
in command substitution

System (please complete the following information):
Using fish, version 3.7.1 on MacOS 15.0.1.
Additional context
I installed fifc using fisher. Error started to occur today. I'm the module daily using fisher update so it was working fine earlier this week.

When I install the version before the latest PR the error does not occur.
I.e. fisher install gazorby/fifc@1bc301453f674ed21fac4979c65a9a4cb7f2af61

Does it occur once or every time you try to complete?

Yes

exactly same thing happen on my end, same fish version with osx sonoma.

Does it occur once or every time you try to complete?

For me, it happens every time I try to complete.

fish, version 3.7.1
fisher, version 4.4.5
macOS 14.7 (23H124)
Alacritty 0.14.0 (22a4475)


Refactor and Remove hardcode URL dependency from the RESTTransport

The RESTTransport sets the message body for POST command using hardcode URL ending (i.e /HL7, /demographics, /elr, else).  This will lead us to keep changing the code when STLT's URL changes.  We want to move the dependency out to the setting to prevent changing the code when  STLT's URL changes.
Refactor out to individual Receiver as a plugin.

Depends on #12802

This ticket includes the design of the new RESTTransport as well.

@victor-chaparro.  I think this ticket is done since all URLs have moved out from the transport code and replaced with standard REST header Content-Type info such as text/plain, text/application, application/json, and multipart/form-data.  Therefore, we can close this ticket.


The new movingreason table should be referenced in playerround

After adding the movingreason table to the database, a reference [picklist] from the playerround table should be added to the editing of the player round (see https://github.com/averbraeck/housinggame-common/issues/9). The relation is optional.

Selection of movingreason in editing works as intended:


Date and time format configuration

Here is a cleaner pull request to configure date and time formats.
All configuration elements have been put in the main json file, the example.json has been updated accordingly.

This PR would be very helpful to us to have merged.  Is there anything I can do to assist in getting this merged?

It does not merge anymore so an update would be needed, I'd love to hear from the etsy folks about it though


Update documentation to direct people to the WP plugins db

Hello @kylehg, @majelbstoat,
Please review the following commits I made in branch 'jamie-doc-update'.
e6b96fc76829d440babd6a047fab1876659d1f67 (2015-10-21 11:41:46 -0700)
Update documentation to direct people to the WP plugins db
R=@kylehg
R=@majelbstoat
MANUAL TESTING=not manually tested

YOLOMerge of documentation.


Option or methods to skip serialization

We're trying to use this over at NPR as a drop-in solution to access and set localstorage variables used for analytics from the sub-domains we use for special projects. I love the overall design of the library and the high quality of the code, especially the use of ES6 promises.
However, it doesn't work as a drop-in solution because of the choice to serialize the data in and out of localstorage. Because my team and our projects don't have control over how those variables are set on our parent website and nobody thought to adopt cross-storage when they originally decided to use LocalStorage to stash this information, we can't use the library without modification.
For now, we're going to maintain a fork which skips the json serialization and directly sets/gets the values out of LocalStorage on the hub. But I'm curious if you'd be open to a initialization option that skips the serialization or alternate get/set methods (getDirect?) that accomplish the same. Since we're forking anyway, we could easily make such a thing and submit a pull request.
I suspect this would help spur adoption, because we can't be the only ones who need to retrofit a cross domain storage solution into an existing ecosystem of sites where the choice of storage format is out of their control.

Sorry for the late reply! I think a getRaw function could be useful, as you mentioned :)

Oh, no worries whatsoever! We've been buried by election coverage as it is and are only now emerging to be able to contribute back to open source projects we've been using.
Me or someone on my team will tackle this in the next month or so! We'd be very appreciative if this landed in the official version so that we don't have to maintain our own.
Tangentially, this thing has been a godsend and the architecture gives me some ideas for the next generation of our responsive iframe library.

I've gone over https://github.com/zendesk/cross-storage/pull/26 and the proposed solution is definitely in line with the discussion here, much appreciated!
But I've been thinking about this more, and cross-storage is probably doing too much. I think it would make sense to simply drop TTLs and stop serializing altogether. It would be much more flexible, though it would be a major breaking change with no clear upgrade path. For users looking to upgrade, you could perhaps ship some code in the hub that looked through all stored items and deserialized them if they followed the format {value, expire}

Awesome, we appreciate it. IMHO, cross-storage is a little too opinionated about the storage format, which probably acts as a barrier to adoption. Raw values are easy enough to serialize however the developer using cross-storage sees fit.
The upgrade path is difficult, which is why we proposed an alternate mode. But that doesn't help migrate anyone to use the raw values.

MHO, cross-storage is a little too opinionated about the storage format, which probably acts as a barrier to adoption.

Agreed! Scope changed. I had actually intended to build it out as a more complex store, but that didn't happen. Some functionality (TTLs) are remnants of that early design. Operating just on raw values should be much simpler and v1.0.0 provides exactly that :)
I think the project has been successfully cut down to its most essential parts.

Here's a possible migration solution for those looking to use 1.0.0 and not losing existing data. (Haven't tested)
<script>
/**
 * Migration function to update keys set by cross-storage ~8 and below to be
 * to be compatible with cross-storage 1.0. Assumes no JSON objects were
 * previously stored with a key named "value"
 */
function migrate() {
  var i, key, item, value;
  for (i = 0; i < localStorage.length; i++) {
    try {
      key = localStorage.key(i);
      item = JSON.parse(localStorage.getItem(key));

      if ('value' in item) {
        localStorage.setItem(key, item.value);
      }
    } catch (e) {
      // no-op
    }
  }

  migrate();
</script>


support passion feed searching in lastEvent resolver

In order to avoid duplicate elements on 【Newest List】/【Latest Salse】, we create a new resolver 'lastEvent'. Still need to make it support passion feed searching.
ref: https://github.com/kodadot/nft-gallery/pull/3062

[x] remove duplicate item from [Newest List]/[Latest sales]

[x]  inaccurate time to nft listing

[x] nft may be displayed on [Newest List] even if  its listing price equal to 0.

[ ] support passion feed

Originally posted by @Jarsen136 in https://github.com/kodadot/nft-gallery/issues/3062#issuecomment-1161050376

@Jarsen136 when you open up PR for this one, make sure to attach https://github.com/kodadot/rubick/pull/102 as completed (and not payed out) and tag me :)

Hey, Could you pls deploy this resolver https://github.com/kodadot/rubick/pull/102  so that I could move on to finish the frontend part? @vikiival

cc @Jarsen136


San Andreas (classic) crashing after a few minutes of booting up.

Please describe your issue as accurately as possible.
If you use Windows, please check the following page: https://github.com/doitsujin/dxvk/wiki/Windows
Software information
Name of the game, settings used etc.
System information

GPU: AMD Radeon R3
Driver: 2.0.179
Wine version: 1.2.170
DXVK version: 1.9.4

Apitrace file(s)

Put a link here

For instructions on how to use apitrace, see: https://github.com/doitsujin/dxvk/wiki/Using-Apitrace
Log files
Please attach Proton or Wine logs as a text file:

When using Proton, set the Steam launch options for your game to PROTON_LOG=1 %command% and attach the corresponding steam-xxxxx.log file in your home directory.
When using regular Wine, use wine game.exe > game.log 2>&1 and attach the resulting game.log file.
gta_sa_d3d9.log

Ho there.
We don't support old versions of dxvk. The best you can do is try 1.10.3 which is the latest release that will work with your driver.

Hi there. We don't support old versions of dxvk. The best you can do is try 1.10.3 which is the latest release that will work with your driver.

I've tried various versions including 1.10.3 and they all don't work. When I use some them the game doesn't launch at all.
gta_sa_d3d9.log

I've also noticed some lines that usually don't appear when using DXVK on other gmes. I'm not sure if this is useful or not but I thought I should mention it.

These likely arent DXVK crashes, but GPU hangs... of a year 2021.Q1 era drivers.
Just played a bit of TopSpin and AMDVLK 2021.Q1.6 driver hanged after couple minutes too... so you cant help it :dagger:

Do those work on Windows? From what I can find RADV doesn't work on Windows.

Also not working in windows with DXVK 2.4
err:   D3D9SwapChainEx: Failed to recreate swap chain: VK_ERROR_INITIALIZATION_FAILED
gta_sa_d3d9.log

Also not working on Windows with DXVK 2.4 err: D3D9SwapChainEx: Failed to recreate swap chain: VK_ERROR_INITIALIZATION_FAILED gta_sa_d3d9.log

I saw from one post claiming that the issue can be solved with changing a single line. I'm not sure what line that is since I don't know the first thing about coding, sadly.

@Sbo-RSA I don't think there is much for us to do here since your setup doesn't support Vulkan 1.3. dxvk have already received a whole bunch of 32bit memory and vram (useful on say a Laptop that might system memory for vram) improvements. I assume it is a out of memory issue.
@RouatbiH Please open a new issue as that doesn't seem related.

@Blisto91 I just realised that I've made a mistake. I'm actually using Windows 10, not Vulkan. I've been trying anything supported by Vulkan 1.2 and none of them seem to work. it always ends with the game locking up for a few minutes and sometimes indefinitely til I restart it. If it's a memory issue, is it possible to adjust that through dxvk.config? Because I've tryied halving the amount but I still experienced crashes. I onl have 8 GB and usually only 5 GB is usable. Oh and I should mention that I've modified the exe file to use 4 GB RAM. Could that also be the cause?


Check handling of ICMP errors in UDP mode

I noticed a possible issue if the library is configured to create an UDP channel to a host/port so that the host is reachable but the port is not bound by any process.
In this case it seems that the library closes and reopens the channel continuously, without any delay between two consecutive attempts regardless of the configured ChannelRetry.
I took a tcpdump capture on the machine running the library, the output is the following and repeats continuously:
08:26:03.927398 IP <IP_ADDRESS>.20001 > <IP_ADDRESS>.20001: UDP, length 17
08:26:03.929240 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP <IP_ADDRESS> udp port 20001 unreachable, length 36
08:26:03.936501 IP <IP_ADDRESS>.20001 > <IP_ADDRESS>.20001: UDP, length 17
08:26:03.938731 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP <IP_ADDRESS> udp port 20001 unreachable, length 36
08:26:03.946056 IP <IP_ADDRESS>.20001 > <IP_ADDRESS>.20001: UDP, length 17
08:26:03.956866 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP <IP_ADDRESS> udp port 20001 unreachable, length 36
08:26:03.964693 IP <IP_ADDRESS>.20001 > <IP_ADDRESS>.20001: UDP, length 17
08:26:03.968120 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP <IP_ADDRESS> udp port 20001 unreachable, length 36
08:26:03.975901 IP <IP_ADDRESS>.20001 > <IP_ADDRESS>.20001: UDP, length 17
08:26:03.977529 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP <IP_ADDRESS> udp port 20001 unreachable, length 36
08:26:03.984591 IP <IP_ADDRESS>.20001 > <IP_ADDRESS>.20001: UDP, length 17
08:26:03.986223 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP <IP_ADDRESS> udp port 20001 unreachable, length 36
08:26:03.993334 IP <IP_ADDRESS>.20001 > <IP_ADDRESS>.20001: UDP, length 17
08:26:03.994930 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP <IP_ADDRESS> udp port 20001 unreachable, length 36
08:26:04.002017 IP <IP_ADDRESS>.20001 > <IP_ADDRESS>.20001: UDP, length 17

The machine running the library is <IP_ADDRESS>, it seems that the issue is caused by the ICMP error sent back by the peer.
This causes an error on the channel side, as can be seen in the following log generated by the application using the library:
2020-10-21T08:18:54,102 [Thread-98] INFO   channel state changed to: OPEN
2020-10-21T08:18:54,109 [Thread-98] WARN   outstation stack: WARN Connection refused
2020-10-21T08:18:54,111 [Thread-98] INFO   channel state changed to: CLOSED
2020-10-21T08:18:54,113 [Thread-98] INFO   channel state changed to: OPENING
2020-10-21T08:18:54,116 [Thread-98] INFO   outstation stack: INFO Binding UDP socket to: <IP_ADDRESS>, port 20001, resolving address: <IP_ADDRESS>, port 20001
2020-10-21T08:18:54,119 [Thread-98] INFO   outstation stack: INFO UDP socket binded to: <IP_ADDRESS>, port 20001, sending to <IP_ADDRESS>, port 20001
2020-10-21T08:18:54,121 [Thread-98] INFO   channel state changed to: OPEN
2020-10-21T08:18:54,128 [Thread-98] WARN   outstation stack: WARN Connection refused
2020-10-21T08:18:54,130 [Thread-98] INFO   channel state changed to: CLOSED
2020-10-21T08:18:54,133 [Thread-98] INFO   channel state changed to: OPENING
2020-10-21T08:18:54,135 [Thread-98] INFO   outstation stack: INFO Binding UDP socket to: <IP_ADDRESS>, port 20001, resolving address: <IP_ADDRESS>, port 20001
2020-10-21T08:18:54,138 [Thread-98] INFO   outstation stack: INFO UDP socket binded to: <IP_ADDRESS>, port 20001, sending to <IP_ADDRESS>, port 20001
2020-10-21T08:18:54,140 [Thread-98] INFO   channel state changed to: OPEN
2020-10-21T08:18:54,147 [Thread-98] WARN   outstation stack: WARN Connection refused
2020-10-21T08:18:54,149 [Thread-98] INFO   channel state changed to: CLOSED
2020-10-21T08:18:54,151 [Thread-98] INFO   channel state changed to: OPENING
2020-10-21T08:18:54,154 [Thread-98] INFO   outstation stack: INFO Binding UDP socket to: <IP_ADDRESS>, port 20001, resolving address: <IP_ADDRESS>, port 20001
2020-10-21T08:18:54,157 [Thread-98] INFO   outstation stack: INFO UDP socket binded to: <IP_ADDRESS>, port 20001, sending to <IP_ADDRESS>, port 20001
2020-10-21T08:18:54,159 [Thread-98] INFO   channel state changed to: OPEN
2020-10-21T08:18:54,166 [Thread-98] WARN   outstation stack: WARN Connection refused
2020-10-21T08:18:54,168 [Thread-98] INFO   channel state changed to: CLOSED
2020-10-21T08:18:54,170 [Thread-98] INFO   channel state changed to: OPENING
2020-10-21T08:18:54,172 [Thread-98] INFO   outstation stack: INFO Binding UDP socket to: <IP_ADDRESS>, port 20001, resolving address: <IP_ADDRESS>, port 20001
2020-10-21T08:18:54,176 [Thread-98] INFO   outstation stack: INFO UDP socket binded to: <IP_ADDRESS>, port 20001, sending to <IP_ADDRESS>, port 20001
2020-10-21T08:18:54,178 [Thread-98] INFO   channel state changed to: OPEN
2020-10-21T08:18:54,185 [Thread-98] WARN   outstation stack: WARN Connection refused
2020-10-21T08:18:54,188 [Thread-98] INFO   channel state changed to: CLOSED
2020-10-21T08:18:54,190 [Thread-98] INFO   channel state changed to: OPENING
2020-10-21T08:18:54,192 [Thread-98] INFO   outstation stack: INFO Binding UDP socket to: <IP_ADDRESS>, port 20001, resolving address: <IP_ADDRESS>, port 20001
2020-10-21T08:18:54,196 [Thread-98] INFO   outstation stack: INFO UDP socket binded to: <IP_ADDRESS>, port 20001, sending to <IP_ADDRESS>, port 20001

This can cause log flooding and generates a lot of network traffic, which can be a serious issue on a metered connection.
The library is running on a Linux machine. I tried to use OSX, Linux and Windows machines as peer, the issue seems to occur in the first two cases but not in the latter.
Windows do not seem to send back ICMP errors.
I can think about the following strategies for fixing this:

Using the UDP socket in unconnected mode, in this case at least on Linux the ICMP errors do not seem to be reported to the application by the OS, (even if the documentation is not so clear on this topic).
I've created a commit that explores this approach at [1]. It seems to solve the issue at the cost of increased complexity and maybe worse performance.
Change the code to ignore this specific error basing on error code. This can be tricky because if I understood correctly std::error_code is platform dependent.
Configure the firewall on the master/outstation to drop incoming/outgoing ICMP error packets. This requires additional configuration on the machines and can lead to the loss of potentially interesting messages. This workaround should prevent the issue without the need for code changes.

Do you know any other possible ways to prevent this issue?
I observed this on 3.0.4 and release branch
[1] https://github.com/eurotech/opendnp3/commit/151a0a8f713994b787587ad5d776b3ee2951695c

I tried something similar at first, it solved the log flooding and the excessive traffic problem, but I found I a remaining issue:
If you try to connect an opendnp3 master to an opendnp3 outstation over UDP the sockets on the two ends will stay bound for a very short time, making the connection difficult to establish, the following happened in my tests:

Host A binds the socket and sends the first datagram
The socket is likely not bound on host B (see 3), so it sends back an ICMP error message.
Host A closes the socket due to ICMP and waits for the reconnect delay to expire, during this interval the socket is not bound, so if B sends a datagram, it will get an ICMP error back.

This approach should work if one of the two ends keeps the socket bound all time.

Hi, do you have any update on this? Thanks

We haven't had time to research it. It'll likely happen just before we need
to implement UDP support for another project.
On Mon, Nov 23, 2020, 7:41 AM nicolatimeus<EMAIL_ADDRESS>wrote:

Hi, do you have any update on this? Thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dnp3/opendnp3/issues/405#issuecomment-732240552, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACKVFKC5NKINBTAUBESWE3SRJ7C5ANCNFSM4S3MWIJQ
.


Allow editing motif areas in scrolled editor

REDMINE-17343

Coverage remained the same at 99.208% when pulling be065e4131d89750976c896107263c4d7ae55a74 on tf:motif-area-selection into 435a533c81efbf24ef62c81e1eb211cf2a860469 on codevise:master.


[WIP] Sudo improvements

WIP because I will test this either this week or next. I am posting it now, for feedback and review.
This cleans up some leftover issues with #760:

PR 760 handled the calls to docker-compose but not the calls to docker

We now have these two functions:
cmd() {
    $__maybe_sudo $__compose_exe "$@"
}

dodocker() {
    $__maybe_sudo docker "$@"
}

Thoughts:

We should probably name these functions consistently.
One option is docompose() and dodocker() but you may have another preference.

The functions were supposed to encapsulate the use of $__maybe_sudo
But in fact there are some places in the script where we still need to use $__maybe_sudo $__compose_exe and $__maybe_sudo docker which looks a bit ugly.
I could make those a bit cleaner, if I put the sudo back inside $__compose_exe and inside $__docker_exe variables.
I think I will try that arrangement later. We can always rollback if it doesn't feel better.
Update: I did that. It does look a bit cleaner now. But there arestill places where we need to write $__maybe_sudo docker-compose (before we have determined $__compose_exe).

This would need to target main now.

Understood.
Some things came up. But I will try to get back to this when I can.

Thanks for your help! I may take this up once the merge activity dies down a little


don't show colormap for rgb images

Description

Solves issue: https://github.com/napari/napari/issues/1542
Type of change

[x] Bug-fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

References

How has this been tested?

[ ] example: the test suite for my feature covers cases x, y, and z
[ ] example: all tests pass with my change

Final checklist:

[ ] My PR is the minimum possible work for the desired functionality
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works

@sofroniewn Please take a look

Hi @ekdnam I just gave this a try and i could reproduce the same problem you were mentioning about the colorbar appearing in the top left, which is likely due to the parent not being set properly. See

Let's try a different approach. Instead of not showing the widgets, let's just hide them. I think that will be something like
        if layer.rgb:
            self.grid_layout.itemAtPosition(3, 0).widget().hide()
            self.colorbarLabel.hide()
            self.colormapComboBox.hide()

Where we need to hide the label, the colorbar, and the combobox.
For ease of reading do you want to try putting this at the end of the init method (after everything gets added). You can also remove the extra commented lines you added above.
I think this should work. Let me know if you run into more problems!!

@sofroniewn I have made the changes, please take a look.
the line self.grid_layout.itemAtPosition(3, 0).widget().hide() led to an error, so I removed it, and the code works just fine.

In the interest of maintaining UX uniformity, why not keep the colormap dropdown but add "RGB" to it? Then someone can easily switch between viewing an image with shape (..., [3,4])-sized image as RGB or separate slices. When viewing an image where the dimensions don't permit a conversion to RGB, the "RGB" option is grayed out but still visible in the dropdown.

@d-v-b I tried something different, now for RGB images the widgets would be turned off, by,
if layer.rgb is True:
            self.colorbarLabel.setDisabled(True)
            self.colormapComboBox.setDisabled(True)

The functionality of the colorbar label and the combo box gets disabled (they cannot be used now), but they don't become grey per se.
Screenshot attached below:

@sofroniewn @jni @tlambert03 @kne42 is disabling the widgets also an option that can be implemented here?

In the interest of maintaining UX uniformity, why not keep the colormap dropdown but add "RGB" to it? Then someone can easily switch between viewing an image with shape (..., [3,4])-sized image as RGB or separate slices. When viewing an image where the dimensions don't permit a conversion to RGB, the "RGB" option is grayed out but still visible in the dropdown.

@d-v-b We were planning to expose those sorts of conversions in the layer list, rather than the colormap dropdown as they will change the layer representation, but it is an interesting idea, and maybe one we can follow up on. It is unclear to me how to undo that operation cleanly from that dropdown menu.
An alternative might just be to show RGB as a string in the combo box and disable it entirely as was done by @ekdnam here

The functionality of the colorbar label and the combo box gets disabled (they cannot be used now), but they don't become grey per se.

We could also add hide the colorbar icon.
The following seems like a reasonable improvement on where we are now and will be easy to implement

hide the colorbar
set the combobox to read RGB
disable the combobox so it can't be changed

I think we can think about more complex functionality in the future

@sofroniewn should I move ahead with your suggestions?
Namely,

hide the colorbar
set the combobox to read RGB
disable the combobox so it can't be changed

@d-v-b what do you think?

I agree with @sofroniewn

@sofroniewn should I move ahead with your suggestions?

Go for it @ekdnam

The ui now looks like this

Quite a few tests are failing. What should be done to pass 'em?

Quite a few tests are failing. What should be done to pass 'em?

two issues:

you need to give you QLabel a parent, so that it is properly cleaned up when the widget is destroyed:
self.colormapLabel = QLabel('colormap:', parent=self)
surface add_layer tests are failing because QtSurfaceControls inherits QtBaseImageControls ... but surface layers have no attribute rgb, so this code fails for surface layers:
https://github.com/napari/napari/blob/0c9022ff73a449f9fe366e8cef879cd9909e2431/napari/_qt/layer_controls/qt_image_controls_base.py#L54-L58

you could check for if hasattr(layer, 'rgb') ... but I wonder whether this isn't indicative of a deeper design issue.  @sofroniewn ?

you could check for if hasattr(layer, 'rgb') ... but I wonder whether this isn't indicative of a deeper design issue. @sofroniewn ?

Agreed indicative of a large issue that we might want to resolve when do things like the ColorManger clean up see #1356, so I think it's probably ok to use that quick fix for now.
Thinking about this more @ekdnam I wonder if instead of adding RGB to the combobox and disabling it, maybe we should just hide the combobox and replace it with a QLabel with RGB instead, then it will be clear that would can't click on the combobox at all.
I worry now that people might try and click the combobox and be confused about why it is disabled

Also in conversations @jni made the suggestion to make the label (RBG) instead as it isn't a colormap in quite the same way that the others are

Okay, I will add a QLabel for RGB images

@ekdnam Hi there, I created another PR to update your proposed change, you may need to pull master to your branch to see the clean change list, hopefully this unblocks your PR: https://github.com/ekdnam/napari/pull/1

@ziyangczi  Okay, will rebase my branch with master, and also look into your changes. Thanks!

What should be done to solve these errors? cc @sofroniewn @ziyangczi

@ziyangczi thanks! all checks have been passed.
@sofroniewn can this PR be merged now?


high severity vulnerabilities after install @capacitor/assets 3.0.5

I have installed "@capacitor/assets": "^3.0.5" from my ionic project, but after the installation I got the following warnings
npm warn deprecated<EMAIL_ADDRESS>Rimraf versions prior to v4 are no longer supported
npm warn deprecated<EMAIL_ADDRESS>Glob versions prior to v9 are no longer supported
npm warn deprecated<EMAIL_ADDRESS>You or someone you depend on is using Q, the JavaScript Promise library that gave JavaScript developers strong feelings about promises. They can almost certainly migrate to the native JavaScript promise now. Thank you literally everyone for joining me in this bet against the odds. Be excellent to each other.
npm warn deprecated
npm warn deprecated (For a CapTP with native promises, see @endo/eventual-send and @endo/captp)
npm warn deprecated<EMAIL_ADDRESS>this version is no longer supported, please update to at least 0.8.*
npm warn deprecated<EMAIL_ADDRESS>this version is no longer supported, please update to at least 0.8.*

and the high severity vulnerabilities message
3 high severity vulnerabilities

To address all issues, run:
  npm audit fix

Run `npm audit` for details.

Environment
Ionic:

   Ionic CLI                     : 7.2.0 (/opt/homebrew/lib/node_modules/@ionic/cli)
   Ionic Framework               : @ionic/angular 8.4.0
   @angular-devkit/build-angular : 17.3.11
   @angular-devkit/schematics    : 17.3.11
   @angular/cli                  : 17.3.11
   @ionic/angular-toolkit        : 12.1.1

Capacitor:

   Capacitor CLI      : 6.1.2
   @capacitor/android : not installed
   @capacitor/core    : 6.1.2
   @capacitor/ios     : not installed

Utility:

   cordova-res : not installed globally
   native-run  : 2.0.1

System:

   NodeJS : v20.16.0 (/usr/local/bin/node)
   npm    : 10.8.1
   OS     : macOS Unknown

Steps to reproduce the issue.

Start a new ionic aplication ionic start myApp blank --capacitor --typeangular-standalone
Move to the project directory cd myApp
Install it npm i @capacitor/assets
See the error.

Same here. Looks like these are coming from deps of deps.
% npm ls q
<EMAIL_ADDRESS>/Users/home/Projects/myapp
└─┬<EMAIL_ADDRESS>-> ./apps/app
  └─┬<EMAIL_ADDRESS>    └─┬<EMAIL_ADDRESS>      └─┬<EMAIL_ADDRESS>        ├─┬<EMAIL_ADDRESS>        │ └──<EMAIL_ADDRESS>        ├─┬<EMAIL_ADDRESS>        │ └──<EMAIL_ADDRESS>deduped
        ├─┬<EMAIL_ADDRESS>        │ └──<EMAIL_ADDRESS>deduped
        ├─┬<EMAIL_ADDRESS>        │ └──<EMAIL_ADDRESS>deduped
        ├─┬<EMAIL_ADDRESS>        │ └──<EMAIL_ADDRESS>deduped
        ├─┬<EMAIL_ADDRESS>        │ └──<EMAIL_ADDRESS>deduped
        ├─┬<EMAIL_ADDRESS>        │ └──<EMAIL_ADDRESS>deduped
        ├─┬<EMAIL_ADDRESS>        │ └──<EMAIL_ADDRESS>deduped
        ├─┬<EMAIL_ADDRESS>        │ └──<EMAIL_ADDRESS>deduped
        └─┬<EMAIL_ADDRESS>          └──<EMAIL_ADDRESS>deduped

O mesmo aconteceu comigo, sera concertado em breve?


fix-video-cut-in-fullscreen-mode

In full screen mode:

Show the timeline and bottom control bar only when the cursor hovers on them.
If the cursor is not hovering on the timeline or bottom control bar, they will then fade out in 6 seconds.
So that the video will not be cut and will show completely on the screen in full-screen mode.

We are using the solution in PR #98.


Integration no longer starting up

I installed this integration about 5 months ago, and it has been working fine.
Yesterday, it began failing to start.
I see messages in my logs like:
Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:297
Integration: Sensor ([documentation](https://www.home-assistant.io/integrations/sensor), [issues](https://github.com/home-assistant/home-assistant/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+sensor%22))
First occurred: 11:03:10 AM (1 occurrences)
Last logged: 11:03:10 AM
Setup of platform ge_home is taking longer than 60 seconds. Startup will proceed without waiting any longer.

and
Logger: homeassistant.config_entries
Source: custom_components/ge_home/update_coordinator.py:164
Integration: GE Home ([documentation](https://github.com/simbaja/ha_gehome))
First occurred: 11:02:49 AM (1 occurrences)
Last logged: 11:02:49 AM
Error setting up entry Ovens for ge_home

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/gehomesdk/clients/async_login_flows.py", line 76, in async_get_authorization_code
    code = await async_handle_ok_response(session, await resp.text())
  File "/usr/local/lib/python3.9/site-packages/gehomesdk/clients/async_login_flows.py", line 111, in async_handle_ok_response
    raise GeAuthFailedError(f"Authentication failed, reason: {reason}")
gehomesdk.exception.ge_auth_failed_error.GeAuthFailedError: Authentication failed, reason: Invalid credentials

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/ge_home/update_coordinator.py", line 162, in async_setup
    await self.async_start_client()
  File "/config/custom_components/ge_home/update_coordinator.py", line 183, in async_start_client
    await self.async_begin_session()
  File "/config/custom_components/ge_home/update_coordinator.py", line 193, in async_begin_session
    await self.client.async_get_credentials(session)
  File "/usr/local/lib/python3.9/site-packages/gehomesdk/clients/base_client.py", line 188, in async_get_credentials
    await self.async_do_full_login_flow()
  File "/usr/local/lib/python3.9/site-packages/gehomesdk/clients/base_client.py", line 192, in async_do_full_login_flow
    self.credentials = await self._async_do_full_login_flow()
  File "/usr/local/lib/python3.9/site-packages/gehomesdk/clients/websocket_client.py", line 63, in _async_do_full_login_flow
    await self._async_get_oauth2_token()
  File "/usr/local/lib/python3.9/site-packages/gehomesdk/clients/base_client.py", line 215, in _async_get_oauth2_token
    oauth_token = await async_get_oauth2_token(
  File "/usr/local/lib/python3.9/site-packages/gehomesdk/clients/async_login_flows.py", line 147, in async_get_oauth2_token
    code = await async_get_authorization_code(session, account_username, account_password, account_region)
  File "/usr/local/lib/python3.9/site-packages/gehomesdk/clients/async_login_flows.py", line 83, in async_get_authorization_code
    raise GeAuthFailedError(f'Could not obtain authorization code') from exc
gehomesdk.exception.ge_auth_failed_error.GeAuthFailedError: Could not obtain authorization code

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 339, in async_setup
    result = await component.async_setup_entry(hass, self)
  File "/config/custom_components/ge_home/__init__.py", line 45, in async_setup_entry
    if not await coordinator.async_setup():
  File "/config/custom_components/ge_home/update_coordinator.py", line 164, in async_setup
    raise HaAuthError("Authentication failure")
custom_components.ge_home.exceptions.HaAuthError: Authentication failure

AFAIK, my auth credentials to the GE portal/app have not changed (the iOS app I use continues to see my 2 ovens, and works fine)
Other stuff I did yesterday:

Updated to core-2022.6.6
Installed a bunch of bleeding edge addons and integrations for the "Matter" workshop, to see the details of what I installed: https://docs.google.com/document/d/1MldgA337wHTEx-vPkoxlCqKHrhVm5QIcHV32iLsv_2k/edit

I don't know for certain that there is an issue with the GE integration, but everything else I have installed/configured continues to work fine...

A few things you can try: 1) update to the latest version 2) uninstall/reinstall the component, 3) download docker desktop and run HASS in that environment, and test to see if it works there.

It tells you right in the log that you have invalid credentials. Did you possibly change your password? Try removing it and read ding the integration with updated credentials.

I ran into a similar (if not the same) issue.  The password that I had previously set for my account no longer worked, even though I was still logged into the mobile app (albeit from years ago).  It seems GE has changed things a bit since I originally created the account.  Of course, their password reset system wasn't working, either.  It would send me a link to a slightly different page to request a new password reset link, and then just kept me in that loop, never sending me a link that would actually let me change it.
What seemed really odd was that this was all through a Salesforce app--I suppose they moved their authentication and account management over there.  Eventually, I found a "passwordless login" page, which will email you a one-time code to log in with instead of your (now invalidated) password.  After logging in with that code, it required I set a new password, and of course, the complexity requirements had changed such that my old password hadn't met them.  I assume this is why it would no longer let me in.  Hope this helps!

Thanks for the responses above.
When I first created my account with the SmartHQ app, I used my iPad.
After the auth advice above, I attempted to connect with my iPhone, and it complained about my credentials.
I did the "reset my password" dance, and set my NEW password to what I strongly believe was my old/previous/existing password (Because I keep it in a password manager, and used copy/paste)
Then I was able to log in via the iPhone app, and my iPad app continues to work.
I restarted Home Assistant to no avail.
Later, I deleted the integration from the HA, restarted, and added it back
In the configuration that popped up, I added my user/password (which is almost certainly the same as before)
The integration succeeded this time....
Some comments/questions:

It would be nice if I could re-enter my user/password to this integration without deleting/reinstalling.....
Is it technically possible to reverse engineer the API to the appliances, so this (or a similar) integration didn't have to work through the cloud?  Not saying that would be easy, or asking/expecting anyone to jump in and start working on that!  For example, the author of the Lennox S30 integration jumped through all kinds of MITM proxy hoops to figure out a way to reverse engineer that API, and after a ton of work, he has it working very well.  Just wondering if there is any reason a similar effort wouldn't be possible?

No reason that the API couldn't be reverse engineered.  In fact, there are a few people out there that are connecting devices to the diagnostics port which enables serial communication/control.  It probably wouldn't be too much of a stretch to get something local working using that technique.  It would probably be more involved to intercept the device <-> server communications, but probably possible.  I know I'd like to have local control, but I haven't had the time to investigate the feasibility.


LruRedux::TTL::ThreadSafeCache.delete does not return the deleted item as docs say

The LruRedux::TTL::ThreadSafeCache.delete method does not return the deleted item as docs say.  It looks like the code returns an expiration time float value and not the deleted item.
Easy enough to work around, but we need to either update the README docs or change the library's behavior.
Example reproduction:
my_cache = LruRedux::TTL::ThreadSafeCache.new(8, 300)
my_cache["a"] = "This is string A"
my_cache["b"] = "This is string B"

result_obj = my_cache.delete "a"
puts "result_obj: #{result_obj} #{result_obj.class}"

This produces output like:
result_obj:<PHONE_NUMBER>.1882849 Float

This repository may be dead.
However, I forked it and fixed the bug.
You can install by gem install sin_lru_redux.
https://rubygems.org/gems/sin_lru_redux


Status Update 2014-04-13

What was accomplished

Design Doc for additional log/assert removals
use new error reporting endpoint for module build errors
Updated Google AMP Cache to upgrade amp-viewer-integration load priority
Remove ie-media-fix polyfill from ESM build

Lessons Learned

Take care of your mental health

What's Next

postHTML transforms in integration tests (carry over)
Start work on AMP optimizer and validator for module build changes. (carry over)
Wrap up testing and merge FixedLayer PR
Move amp-ad and amp-analytics components lazy loading to cache transform

Accomplished

Refactored and add support for FunctionExpressions to babel-plugin-transform-function-declarations.
Flatten TemplateLiterals in Module build, reducing and extension size by ~1.5%.
Remove 'use strict' declarations from Module build.
Remove additional IE specific codepaths from Module build, reducing size by ~1%.
Convert const to let for greater variable folding in Module build, reducing size by ~1.5%.
Repair broken Module output after Babel refactor.
Introduce Module build test into Travis for every PR to prevent build regressions.
Add new --debug option to yarn gulp dist for debugging build system lifecycles.

What's Next

Repair AMP transform so we can remove custom Closure compilation, and nailgun allowing us to use more cores during build time and reduce time taken.
Have a baby!


Move to go1.12 without enabling modules

Cherry picks (well, it is a separate commit, so technically not cherry-picked, but same idea) just the "switch go version" part of #63 . It doesn't change how we get build-tools/ or switch to go modules or any of that. All of those will be in a separate PR once this one is in.

LGTM


Allow empty Expiry Date

I have a need to import a blank expiry date, however, Craft will automatically add the current timestamp if a null value is passed to the expiryDate field.
To overcome this I made a modification to version 1.4.12, which I thought worth sharing as it non destructive.
I have change line 86-93 in services > FeedMe_EntryService.php from:
// Set expiry date
$expiryDate = FeedMe_Element::ExpiryDate;
if (isset($fields[$expiryDate])) {
    $d = date_parse($fields[$expiryDate]);
    $date_string = date('Y-m-d H:i:s', mktime($d['hour'], $d['minute'], $d['second'], $d['month'], $d['day'], $d['year']));

    $element->$expiryDate = DateTime::createFromString($date_string, craft()->timezone);
}

to:
// Set expiry date
$expiryDate = FeedMe_Element::ExpiryDate;
if (isset($fields[$expiryDate])) {
    $d = date_parse($fields[$expiryDate]);
    $date_string = date('Y-m-d H:i:s', mktime($d['hour'], $d['minute'], $d['second'], $d['month'], $d['day'], $d['year']));
    if ($d[year]) {
      $element->$expiryDate = DateTime::createFromString($date_string, craft()->timezone);
    } else {
      $element->$expiryDate = '';
    }
}

The simple conditional checks if a the date has a value for the Year. If not then it passes an empty string.
If this can not been introduced into the plugin then I hope it helps someone else who needs to achieve the same thing.

Thanks for supplying this fix. This will be much more improved in v2, where you'll be able to provide a default value for dates (and every other field).

Any idea how to modify this to work for a custom date time field? I have a field that I'm mapping to that I'd like to set to blank but it defaults to the current date and time.

You could achieve this by using the provided fieldtype hooks to add a case for your datetime field - https://github.com/engram-design/FeedMe/wiki/Hooks#prepforfeedmefieldtype.
This will be addressed in Feed Me 2 however.

I don't want to modify the FeedMe plugin, but a very easy solution would be to change the prepDate function (in ) from this:
return DateTimeHelper::formatTimeForDb(DateTimeHelper::fromString($data, craft()->timezone));

to this:
return $data ? DateTimeHelper::formatTimeForDb(DateTimeHelper::fromString($data, craft()->timezone)) : '';

But, like I said, I don't want to modify FeedMe, and I can't quite see how to do it using the prepforfeedmefieldtype hook. How would I check for an empty date in the incoming JSON and set the date to empty in the entry?

In other words, is there a way to access the original data that was brought in from the JSON file? In the prepforfeedmefieldtype hook, the fields have already been prepped so I can't know which ones were blank.

Well, here's what I did. Not ideal, but it's working for me... haha.
  public function prepForFeedMeFieldType($field, &$data, $handle)
  {
    if ($field->type == 'Date') {
      // if the date is less than 10 seconds ago then
      // we assume it was set from a blank field to the current time
      if (strtotime($data[$handle]) - time() < 10) {
        $data[$handle] = '';
      }
    }
  }

Using prepForFeedMeFieldType is what this sort of thing is for - but totally agree that altering this in core field handling is the way to go. I'll look at adding this in the short term.

I know this won't be an issue in 2.0 with defaults, but in the mean time here's a question...
Do you think it should be expected behavior for an empty string to become the current time? I suppose if we are talking about the post date that might make sense but if post date were mapped then there should be a date being passed in, right? In other words, do you think people are relying on being able to send an empty string in the JSON and get the current date time?
At any rate, I would like to know if there's a way to get the original string that came from the JSON within prepForFeedMeFieldType.

Its a good point, and probably something a simple checkbox can fix (use today's date by default vs leave empty).
And sadly not - the prepForFeedMeFieldType is called after core fieldtype behaviour, so its already changing the $data variable. Arguably, I'm likely to change this atomic variable. Let me test out your original code, as I believe providing no data should leave the field blank.

Should be fixed in Feed Me 2.


how to disable todo-comment in some filetype ?

i want to disable todo-comment in some filetype, is there a command provided by todo-comment to disable todo-comment ?

I have the same question, As you can see is reading all inside node_modules folder

You should look at #71 maybe it would help.


Docs

Pull Request Test Coverage Report for Build 214

9 of 10 (90.0%)  changed or added relevant lines in 2 files are covered.
7 unchanged lines in 4 files lost coverage.
Overall coverage increased (+0.2%) to 94.302%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

autokeras/search.py
1
2
50.0%

Files with Coverage Reduction
New Missed Lines
%

autokeras/layer_transformer.py
1
99.13%

autokeras/search.py
1
90.06%

autokeras/classifier.py
2
93.06%

autokeras/net_transformer.py
3
85.94%

Totals

Change from base Build 207:
0.2%

Covered Lines:
1324

Relevant Lines:
1404

💛  - Coveralls