Prevent u-turns at tower nodes that are connecting different OSM ways

This route includes an illegal u-turn in the middle of the bridge
https://graphhopper.com/maps/?point=45.501467%2C-122.661254&point=45.501237%2C-122.66142
OSRM returns the expected route
https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=45.5015%2C-122.6613%3B45.5012%2C-122.6613

Thanks for reporting!
This seems to be a u-turn, because if I set u_turn_costs to infinity I get the same route as on OSRM:
https://graphhopper.com/maps/?point=45.501467%2C-122.661254&point=45.501237%2C-122.66142&ch.disable=true&u_turn_costs=-1
Apparently there is a tower node in the middle of the bridge, even though there is no junction. There is a region border though:

@karussell any idea why we get a tower node here?
Btw: Another I ran into another problem: When I click on the above link (in @camelCaseSucks comment) and then change the vehicle to foot and back to car again I get another route once again, because for some reason turn_costs=false is appended to the url...

@karussell any idea why we get a tower node here?

No, this looks strange. As this is the main issue for me here - should I rename the issue title?

because for some reason turn_costs=false is appended to the url...

outch, this is likely yet another bug in the UI :/

@karussell any idea why we get a tower node here?

https://www.openstreetmap.org/way/587574521

https://www.openstreetmap.org/way/587574521

What do you think is suspicious here?

It might be the line crossing the bridge

It might be the line crossing the bridge

Yes, it really looks like it is :) But this is just a region border, so it should not even be considered by our OSM parser? If it was a ferry I would totally understand what happens because this would create a 'ghost junction' : #1858

Isn't it because the way in OSM is cut at the region border, so we get a tower node by definition? If one wants to avoid that, you would have to merge the features in OSM.

When GH parses OSM it first checks which of the nodes are really junctions (it counts how many ways there are for every node). And only for real junctions (>2 ways) a tower node is introduced. Otherwise the ways are simply merged into one GH edge (at least this is what I thought so far). But sure you are right this merging would only work if the tags are the same. However, here it looks like they are:
https://www.openstreetmap.org/way/123374695
vs
https://www.openstreetmap.org/way/587574521
But anyway pretty sure there are similar cases where the tags are different and then we would have the same problem even if such merging would be done.

Ah, yeah. This is the reason ...

And only for real junctions (>2 ways) a tower node is introduced.

... as soon as 2 ways use the same node a tower node is introduced: https://github.com/graphhopper/graphhopper/blob/master/reader-osm/src/main/java/com/graphhopper/reader/osm/OSMReader.java#L550
and there is no merging code. And even if such merging code would exist the question is really how we would avoid that when the tags would be different.
Related #758

and there is no merging code

Ah ok so we never merge multiple ways, but we make sure that we do not split a single way (and use pillar nodes instead). I think this is where my confusion came from.
Ok so in summary the problem is that there can be u-turns at nodes that are not junctions, simply because they connect two OSM ways.

We might have to rethink about when we can allow U-turns (for edges and nodes) because this dependents on many things like the vehicle, the circumstances at the junction, the road type (or width), the traffic (or average speed) and other things.
We partially already do that when we say that a U-turn is only possible at junctions (due to the space) but we do not make it vehicle-dependent which should be easy as well. And the road-property-dependency is likely even more important (but probably a bit trickier to implement). E.g. in this issue here it is a primary road and we could say we do not allow U-turns even for junctions for primary roads?

Yes we definitely should make this more specific. This probably will decrease performance, but certainly leads to higher quality routing. For the present case we could use road_environment? But really we should probably start with a list of cases where u-turns should / should not be allowed (and at which cost).

... as soon as 2 ways use the same node a tower node is introduced: https://github.com/graphhopper/graphhopper/blob/master/reader-osm/src/main/java/com/graphhopper/reader/osm/OSMReader.java#L550
and there is no merging code. And even if such merging code would exist the question is really how we could avoid tower node creation when the tags would be different.

So any street which is split up in multiple connected OSM ways is going to produce tower nodes at its joints?

At the moment we create a tower node as soon as an OSM node is used from two or more OSM ways (or if it is terminal). This already depends on the vehicle, i.e. if just car is configured then only car-accessible OSM ways are considered.

Would it make sense to mark tower node candidates if they're used by exactly two ways and demote them in cases like this one?

It surely reduces the number of edges but I'm unsure if it is worth the effort. Additionally it won't help in many other scenarios to prevent U-turns.

I proposed such a merging algorithm several years ago (I'd say 4-5 years ago). I had a working prototype. I remember that the number of reduced edges was not that big (I think it was <5%). At this time this did not consider relations like turn restrictions etc. which would further reduce this. That said, I think this would be an interesting feature.

That said, I think this would be an interesting feature.

Why do you think the merging would be an interesting feature? Because it might improve performance? Or because it prevents unnecessary u-turns? Or instructions? Or do you mean a better u-turn handling would be interesting? To me it seems like the most important part is the u-turn handling and merging some edges with identical tags would only be a part of the solution (at best). But maybe it has other advantages.

It always bothered me in OSM if ways are split without a good reason, and I merged quite few over the years by hand :). So I do have a history with that issue. I agree better u-turn handling would be awesome, but we might be able to handle this differently as well.
I gave this a bit more thought. I fear automatic merging might create issues with things like SpatialRuleLookup. The edge we discussed above is cut at a region border. If we would be using a SpatialRuleLookup for these regions, we could tag one part of the way to region A the other part of the way to region B. If we merge these roads, this is not that easy anymore.

I gave this a bit more thought. I fear automatic merging might create issues with things like SpatialRuleLookup. The edge we discussed above is cut at a region border. If we would be using a SpatialRuleLookup for these regions, we could tag one part of the way to region A the other part of the way to region B. If we merge these roads, this is not that easy anymore.

Is this really an issue? Streets which are crossing country borders will very likely differ in tags and shouldn't be merged. If we end up introducing more finegrained rules e.g arbitrary user defined regions, the OSM material won't fit those borders either way.

Streets which are crossing country borders will very likely differ in tags and shouldn't be merged

For major roads crossing a country this is probably not an issue. But when you use other regions, like states or smaller regions like municipalities, this might be.
Also smaller roads crossing a country might be different, and are often not even cut at the border.
https://www.openstreetmap.org/way/106628707
https://www.openstreetmap.org/way/380937474

If we end up introducing more finegrained rules e.g arbitrary user defined regions, the OSM material won't fit those borders either way.

Yes they won't always, but when we merge them on top of this, ways get longer and harder to classify.
But yes, it might be an edge case.

Hello,
I found similar problem on road with several ways.
Bad: https://graphhopper.com/maps/?point=50.223965%2C18.990002&point=50.221075%2C18.989643&locale=pl&elevation=true&profile=car&ch.disable=true&use_miles=false&selected_detail=Elevation&layer=Omniscale
Good: https://graphhopper.com/maps/?point=50.223965%2C18.990002&point=50.221075%2C18.989643&locale=pl&elevation=true&profile=car&ch.disable=true&use_miles=false&selected_detail=Elevation&layer=Omniscale

There is more stuff like this:

In this case, routing should either calculate a loop or a route to the nearest turning circle, like that at the end of “Winding Wood Court”.
I can only urge you to fix this asap because for years now people, especially novice OSM contributors like all kinds of delivery and ride sharing drivers, have been fixing the map by adding non-sense no_u_turn restriction relations with identical ways in the from and to roles. And, it is very difficult to explain to people

that there is nothing wrong with the map but their routing algorithm is broken,
what exactly turn restriction relations are in OSM,
what turn restrictions are for in OSM, and
what they are not for.

Things go even so far as that companies like Lyft hire masses of more or less oblivious people to map no u-turn traffic signs with turn restriction relations, while not understand and not explaining to their payed mappers that turn restriction relations only map the flow of traffic instead of the legal situation on the road (like traffic_signs do).
Because all of the above, you can find more and more things like this in the OSM database:

I do not know how difficult it is to fix this but please please fix it because the OSM database gets littered with superfluous and broken turn restriction relations by oblivious and novice contributors (and even commercial “contributors”).

Thanks for your input, I will take a look at this. IMO one big problem with turn restriction mapping is also this (still uncommented) issue: https://github.com/openstreetmap/iD/issues/9346

In this case, routing should either calculate a loop or a route to the nearest turning circle, like that at the end of “Winding Wood Court”.

From the algorithmic point of view this problem is already solved. GraphHopper accounts for the time it takes to do u-turns at a junction or the end of a dead-end street. It will then decide whether it is better to do such a u-turn or some kind of loop etc. should be used. In the present example it suggests the u-turn. I tried this for different values of the u_turn_costs parameter and it seems that above a value of 80 it suggests another route:

Here is another (live) example:

What is not so clear, though, is at which junctions it is possible to do a u-turn and how long it would take to turn around at a specific junction. This is less of an algorithmic, but more of a data issue. So far GraphHopper uses the same u-turn costs for every junction and every end of a dead-end street. Which OSM tags do you think can be useful to improve on this? Turning around at the end of 'Winding Wood Court' seems reasonable, but unfortunately the (node) tag turning_circle is currently not considered by GraphHopper. Reducing the u-turn-costs at turning_circles would certainly be an improvement and likely fix your present example. However, this tag isn't used very often. Currently there are only around 7100 cases on taginfo.

while not understand and not explaining to their payed mappers that turn restriction relations only map the flow of traffic instead of the legal situation on the road (like traffic_signs do).

Which OSM wiki are you referring to here, and when do you think traffic_sign should be used over a restriction relation? Which values of the traffic_sign tag do you think are relevant for turn restriction aware routing?
Btw if you have more examples like these, please share them.

Thank you @easbar for you extensive answer. I like that. It shows that you are taking this issue seriously, and rightly so because imho this has gotten out of hand. I am not sure how many other routers are affected but Graphhopper seems to have many big scale customers which leads the aforementioned consequences of “novice mappers fixing the map”.

From the algorithmic point of view this problem is already solved. GraphHopper accounts for the time it takes to do u-turns at a junction or the end of a dead-end street. It will then decide whether it is better to do such a u-turn or some kind of loop etc. should be used.

:+1: for covering this algorithmically! However, imho no amount of “time saving” cost is going to outweigh the cost of an accident.

In the present example it suggests the u-turn. I tried this for different values of the u_turn_costs parameter and it seems that above a value of 80 it suggests another route

I do not know what the upper limit for u_turn_costs is but in my understanding it should be set to the upper limit by default. Why? Simply because of safety considerations, it is almost always a bad idea to suggest a U-turn to any driver at any arbitrary junction node. Sure, in the handful of cases left from ”almost always” users should be able to tweak a U-turn cost parameter, if they really have to and know what they are doing. But again, (I do not have any hard evidence numbers) in about 99.9 % of use cases users do not need to and should not tweak such a parameter. Reality proves that almost no user is aware that such a parameter exists or even what it does. Hence, people start “fixing the map”.
Imho, costing a U-turn even in jurisdictions that allow a U-turn at a junction by default is still a dangerous idea, and a prudent one at best. Why? Because as you have mentioned yourself, the data simply does not exist to make a safe assumption and consequently do proper safe costing.

What is not so clear, though, is at which junctions it is possible to do a u-turn and how long it would take to turn around at a specific junction. This is less of an algorithmic, but more of a data issue. So far GraphHopper uses the same u-turn costs for every junction and every end of a dead-end street. Which OSM tags do you think can be useful to improve on this?

I do not think you should try or even can solve this problem with any tag or mapping scheme. Think about it, mappers would have to pre-cost every node on its potential for a safe (and swift) U-turn for every type of vehicle. The shear amount of data and man hours you would require renders this approach unfeasible. So, imho this is a dead end.
But, if you really want to know, in order to serve those 0.1 % of user cases, they could use a tag like u_turn_cost=0…1. Still, I do not think this would be a reasonable nor fair thing to do.

Turning around at the end of 'Winding Wood Court' seems reasonable, but unfortunately the (node) tag turning_circle is currently not considered by GraphHopper. Reducing the u-turn-costs at turning_circles would certainly be an improvement and likely fix your present example.

So, my advice would be to set the u_turn_costs parameter to its upper limit by default first. Not because it is my opinion but because it is the safe thing to do and because this is what most users’ natural and intuitive assumption is.
And second, lets definitely make Graphhopper consider (or cost adequately) turning_circle and turning_loop, maybe also junction=roundabout ways and highway=mini_roundabout nodes.

Which OSM wiki are you referring to here…

I cannot direct you to a specific section in the OSM Wiki. It is just that when you take some time to think about these things you get to certain conclusions. A few OSM contributors have written very interesting and helpful blog posts especially about the application of turn restrictions. If I could only find these again… Neither they nor I claim to be completely correct regarding turn restrictions but we are getting close. It might be a good idea to extend the description of turn restrictions in the OSM Wiki with these considerations.
Anyhow, I still want to answer your questions as far as I can and time permits: By their very nature traffic signs represent the legal situation on the road .

when do you think traffic_sign should be used over a restriction relation?

It depends on what you are trying to map. Do you want to map, or in other words, model the flow of traffic? Then use a turn restriction relation. However, you have to consider that you are just modelling here, not mapping the legal situation. Why is this so? Because you can model the legal situation on the road with different equivalent turn restrictions. A or exactly one turn restriction can model the exact legal effect but it does not have to.
But, if you want to map the legal situation on the road then use the traffic_sign tag. Why? Because by their very nature traffic signs have legal effect. Simply put, one should be aware whether one maps legal data or an effect of legal data. Sometimes, one does both at the same time, sometimes not. Most often, like in the case of turn restrictions, one wants to map legal effects but often enough people map/model legal data.

Which values of the traffic_sign tag do you think are relevant for turn restriction aware routing?

Due to the traffic_sign’s value syntax it depends on the jurisdiction of the traffic sign. For example, in the US you could have values like (including but not limited to) US:R3-1, US:R3-2, or US:R3-4. Generally speaking, mapping traffic signs for routing will not be very helpful. Not only because of the syntax but mainly because when you are mapping for routing you are interested in representing or modeling the flow of traffic.
Having said that, people should still not map a legal no U-turn restriction designated by traffic sign with a no_u_turn relation with identical ways in the from and to roles because it does not help any safe and sane routing algorithm. Yes, it may help in those 0.1 % cases where users want U-turn costing below u_turn_costs’ upper limit but just the relation’s data cost is totally unfair to the other 99.9 % of users. Besides, as you have already mentioned, users who want U-turn costing not only should but have to use far more data to get to a sane and safe u_turn_costs value. So, littering a no_u_turn restriction relation into the OSM database at any arbitrary junction node just because some routing algorithm is not good enough, one does not have, or is unable to aquire enough other data for estimating one’s U-turn cost is just lazy (or lame excuse) for overburdening the OSM database (and the vast majority of other users). No offense please, I am not talking about just Graphhopper here. This applies to every routing algorithm using the OSM database. In other words, routing algorithms should not offload their shortcomings on the map (database) nor their users. Neither should users feel the need to “fix the map” because their routing algorithm does not behave intuetively.

Reducing the u-turn-costs at turning_circles would certainly be an improvement and likely fix your present example. However, this tag isn't used very often. Currently there are only around 7100 cases on taginfo.

:open_mouth: Last time I checked there are 2,212,841 turning_circle nodes and 154,949 turning_loop nodes.

Thanks for your input, I will take a look at this. IMO one big problem with turn restriction mapping is also this (still uncommented) issue: https://github.com/openstreetmap/iD/issues/9346

Oh sure, inadequate tools do not help much either. :wink: But, I do not blame iD  (or any other editing tool) nor think that’s the core problem here because sooner or later novice contributors get the hang of it and create complete routing effective turn restriction relations. The point here is that they have no idea how routing works nor that there is costing involved especially for U-turns.
Now, I understand the dilemma for delivery app developers; where they have to compute a global optimal multi-stop route first with U-turn cost set to 0, and then break up the multi-stop route into local sub-routes with some safe and reasonable U-turn cost value. But again, imho u_turn_costs should default to its upper limit or just below the cost of a turning_circle or turning_loop. I am sorry, should I have mixed up the order of comparison. I hope you get what I mean. :wink:

leads to the aforementioned consequences of “novice mappers fixing the map”.

Do you have some examples/links to OSM where we can see such fixes? I found one here: https://www.openstreetmap.org/relation/13045491, but it is already one year old.

for covering this algorithmically! However, imho no amount of “time saving” cost is going to outweigh the cost of an accident.

If we did not cover this algorithmically we wouldn't be able to calculate such routes at all. There can always be situations where u-turns are the only possible option, like a curbside constraint pointing towards the end of a dead-end street: One has to turn around to get out of such a street again, otherwise we would not find a path at all. This is the reason the u_turn_cost parameter cannot be infinite.
But I see your argument that at least for navigation applications it might very often be better to suggest some kind of 'loop' rather than doing a u-turn.

I do not know what the upper limit for u_turn_costs is but in my understanding it should be set to the upper limit by default. Why? Simply because of safety considerations, it is almost always a bad idea to suggest a U-turn to any driver at any arbitrary junction node.

There is no real upper limit and at least in theory it can be set to a very large, but finite, value. Actually I thought the (hosted) GraphHopper API already uses a very large value, but there seems to be another issue with this that makes the algorithm behave as if it was smaller. We are currently investigating this. And again, I think I mostly agree that suggesting some kind of loop is better than suggesting a u-turn.

Sure, in the handful of cases left from ”almost always” users should be able to tweak a U-turn cost parameter, if they really have to and know what they are doing. But again, (I do not have any hard evidence numbers) in about 99.9 % of use cases users do not need to and should not tweak such a parameter. Reality proves that almost no user is aware that such a parameter exists or even what it does. Hence, people start “fixing the map”.

This is mostly a server-side parameter that (client-side only) users can not change. The u-turn costs can be changed per request for our flexible algorithms, but in most cases they will be fixed for each profile.

I do not think you should try or even can solve this problem with any tag or mapping scheme. Think about it, mappers would have to pre-cost every node on its potential for a safe (and swift) U-turn for every type of vehicle. The shear amount of data and man hours you would require renders this approach unfeasible. So, imho this is a dead end.

I'm not sure about this. Of course mapping the costs explicitly for each node won't be possible, but for example the highway tag could be an indicator to figure out if doing a u-turn is feasible or not, but yes, it won't be a good fit in every case.
For a safe and/or comfortable driving experience I think applications need to find a good way to tell drivers they need to turn around at the next suitable spot, and not just show them the next turn of the calculated route. Say, for example the route contains a u-turn (or some loop that avoids it), then an informed driver can find the next spot where this is possible and turn around instead of blindly following the route.

So, my advice would be to set the u_turn_costs parameter to its upper limit by default first. Not because it is my opinion but because it is the safe thing to do and because this is what most users’ natural and intuitive assumption is.

Yes, like I said, I think I agree the value should be rather high, because a higher value leads to long loops in the worst case, while a too low value can lead to impossible u-turns and drivers will be left with a route they cannot follow.

And second, lets definitely make Graphhopper consider (or cost adequately) turning_circle and turning_loop, maybe also junction=roundabout ways and highway=mini_roundabout nodes.

I already started implementing this for nodes tagged as highway=turning_circle and highway=turning_loop here: #2761

I cannot direct you to a specific section in the OSM Wiki. It is just that when you take some time to think about these things you get to certain conclusions. A few OSM contributors have written very interesting and helpful blog posts especially about the application of turn restrictions. If I could only find these again… Neither they nor I claim to be completely correct regarding turn restrictions but we are getting close. It might be a good idea to extend the description of turn restrictions in the OSM Wiki with these considerations.

Ok, I think if you are concerned about what is currently being mapped in OSM I think you really need to engage with the mapping community and make sure their opinion is clearly stated in the Wiki. If there is no consensus written down as OSM Wiki how can mappers agree about what to do. Everybody might get to their own 'certain conclusions'. From my data consumer / routing point of view I'm happy to help figuring out what kind of tagging is useful for routing applications, but ultimately this needs to be written down in the wiki.

Generally speaking, mapping traffic signs for routing will not be very helpful. Not only because of the syntax but mainly because when you are mapping for routing you are interested in representing or modeling the flow of traffic.

Typically, OSM mapping shouldn't be done for routers specifically, but turn restrictions might be an exception, because routing is the only reason turn restrictions are mapped at all? So far GraphHopper does not make use of traffic_sign mapping, but only considers turn restrictions. With regards to u-turns it comes down to the question what is the default. We could either assume doing a u-turn is possible everywhere unless there is a no-u-turn instruction. This corresponds to a small (global) u-turn cost and tagging no-u-turn will be useful or even necessary. Or we could assume that doing a u-turn is basically never possible, which corresponds to a large (global) u-turn cost. In this case no-u-turn relations will hardly ever be needed or useful.
At first sight it seems logical to add no-u-turn tagging to OSM, because there are traffic signs that indicate this (just like for normal turn restrictions), but tagging this everywhere to satisfy the routers, even in places where there is no 'no u-turn' sign, would be the wrong thing to do.
Do you suggest that:

routers should try to avoid u-turns as much as possible by default everywhere, including at junctions where there is no traffic sign or turn relation (a large u_turn_cost parameter in our case)
restriction relations should mostly be used for left/right/normal turns, but not really for u-turns?
no-u-turn traffic signs can still be mapped using the traffic_sign tag in OSM for completeness, but they won't really be used by routing software

That would sound reasonable to me.

Having said that, people should still not map a legal no U-turn restriction designated by traffic sign with a no_u_turn relation with identical ways in the from and to roles because it does not help any safe and sane routing algorithm.

Yes, I agree. However, the situation is different for turn relations with via-ways that are used to represent no-u-turn signs between different lanes, but you already excluded these, because in this case the from and to roles will be different as well.

No offense please, I am not talking about just Graphhopper here. This applies to every routing algorithm using the OSM database. In other words, routing algorithms should not offload their shortcomings on the map (database) nor their users. Neither should users feel the need to “fix the map” because their routing algorithm does not behave intuitively.

Yes, but GraphHopper really cannot be blamed here, because currently it even ignores no_u_turn restrictions: https://github.com/graphhopper/graphhopper/issues/2570. So if somebody tries to fix an unwanted u-turn by adding such a no_u_turn restriction to OSM (an unmodified instance of) GraphHopper will still suggest the u-turn.

open_mouth Last time I checked there are 2,212,841 turning_circle nodes and 154,949 turning_loop nodes.

Yes, sorry, my bad. Maybe I was looking at ways using these tags, not nodes, or something.

Oh sure, inadequate tools do not help much either. wink But, I do not blame iD (or any other editing tool) nor think that’s the core problem here because sooner or later novice contributors get the hang of it and create complete routing effective turn restriction relations. The point here is that they have no idea how routing works nor that there is costing involved especially for U-turns.

The problem here is that unaware iD users destroy restriction relations, because once they modify ways the (almost invisible) turn relations become stale and there is not even a warning that indicates this. I think this is unfair for both users who spent the time to map these relations and those who destroy them unintentionally without being told about this when all they wanted to do was improving something. I'm quite surprised there is still no reaction from the iD developers on this topic, because showing a warning would really help here and wouldn't even be hard to implement. I even offered to do it myself. But this is not directly related to the topics we discussed here.

Now, I understand the dilemma for delivery app developers; where they have to compute a global optimal multi-stop route first with U-turn cost set to 0, and then break up the multi-stop route into local sub-routes with some safe and reasonable U-turn cost value. But again, imho u_turn_costs should default to its upper limit or just below the cost of a turning_circle or turning_loop. I am sorry, should I have mixed up the order of comparison. I hope you get what I mean. wink

I'm not entirely sure I understood what you mean, but wouldn't the global optimal multi-stop route also depend on the (u-)turns one needs to do for the local routes? At least in theory there should be no reason to not consider u-turn costs for the global optimization, but do include it for the local one?

leads to the aforementioned consequences of “novice mappers fixing the map”.

Do you have some examples/links to OSM where we can see such fixes? I found one here: https://www.openstreetmap.org/relation/13045491, but it is already one year old.

I have just recently removed some here: https://www.openstreetmap.org/changeset/132897711
Perhaps you can download just the changeset and recreate how it looked before. It was one giant mess of U-turns. Please, note all the superfluous U-turn relations I had to delete.
Another example:
https://www.openstreetmap.org/changeset/109903470

Just by looking at the relations that have been created in this changeset you will easily understand that something has gone off rails here. Sure, that particular OSM contributor was a novice when the changeset was created and also apparently did not understand how turn restriction relations work but we have to look deeper why the user did it in the first place. You can find the initial reason in the changeset’s comment. Although it speaks of “some map issues”, it actually means that the user has had some ill advised U-turn encounters in his/her routing app and assumed that because the routing algorithm is more or less perfect (or immutable for his/her purposes), there has to be something wrong with the map. Perhaps that user was even encouraged by the routing app’s developers to “fix the user’s problem” by “fixing the map”?
You can find many similar examples in the Seattle, WA area too.
I do not know for sure whether Amazon uses Graphhopper for its routing apps but I have a gut feeling they might do. Amazon is not an outlier here, many other delivery and ride sharing employees suffer from similar problems and try to mitigate this issue by “fixing the map”.

If we did not cover this algorithmically we wouldn't be able to calculate such routes at all. There can always be situations where u-turns are the only possible option, like a curbside constraint pointing towards the end of a dead-end street: One has to turn around to get out of such a street again, otherwise we would not find a path at all. This is the reason the u_turn_cost parameter cannot be infinite.

Please, excuse me for not being a routing expert but isn’t this a special case? I would assume that from a routing perspective there is no U-turn involved in this case. You start a fresh route search in the only feasible direction?

For a safe and/or comfortable driving experience I think applications need to find a good way to tell drivers they need to turn around at the next suitable spot, and not just show them the next turn of the calculated route. Say, for example the route contains a u-turn (or some loop that avoids it), then an informed driver can find the next spot where this is possible and turn around instead of blindly following the route.

:thinking: The thing is that experience and reality have proven that there is no safe or comfortable way of saying to drivers to make a U-turn.
Long time ago, when in-car-navigation was new, companies like TomTom and many car makers encountered basically the same problem. Initially, drivers were told to “make a U-turn when possible or safe”. And, guess what? Drivers did whatever they wanted, mostly dangerous stuff and accidents, because they felt the pressure to comply with navigation as soon as possible. For many drivers this kind of pressure increased the longer it took them to do the U-turn. You can imagine that operating any heavy machinery under pressure is not a good idea. It is just how human psyche works. So, the solution was to basically avoid these rather dangerous “make a U-turn when possible or safe” messages at any cost. U-turns are not dangerous per se but it is a very unnatural maneuver for most drivers, especially in areas they are not familiar with. Most of the time, drivers go from A to B and this is also what they expect from their navigation. They do not care if there is a loop involved in the route. They want to get safely and stress free to their destination.

Typically, OSM mapping shouldn't be done for routers specifically, but turn restrictions might be an exception, because routing is the only reason turn restrictions are mapped at all?

True.

Or we could assume that doing a u-turn is basically never possible, which corresponds to a large (global) u-turn cost. In this case no-u-turn relations will hardly ever be needed or useful.

I think that although this may not be the most efficient basic assumption, especially in those jurisdictions that legally allow a U-turn at arbitrary junctions by default, this is the smarter and safer assumption.

Do you suggest that:

routers should try to avoid u-turns as much as possible by default everywhere, including at junctions where there is no traffic sign or turn relation (a large u_turn_cost parameter in our case)

:+1: Yes.

restriction relations should mostly be used for left/right/normal turns, but not really for u-turns?

no_u_turn restrictions can and should be mapped. But, only where it makes sense from a flow of traffic or routing point of view. When you assume (or come to the conclusion) that only a safe router is a router with a very high U-turn cost by default then one class of no_u_turn restriction relations becomes obsolete, namely those that have identical ways in the from and to roles. Why? Because a safe and sane router always optimizes for a loop or a turning_circle (or the like) first and will basically almost never suggest a U-turn at an arbitrary junction node.

no-u-turn traffic signs can still be mapped using the traffic_sign tag in OSM for completeness, but they won't really be used by routing software

Right, because of the above assumption about a safe and sane router.

Just by looking at the relations that have been created in this changeset you will easily understand that something has gone off rails here.

Yes, I see, this is unfortunate.

Please, excuse me for not being a routing expert but isn’t this a special case? I would assume that from a routing perspective there is no U-turn involved in this case.

Yes, it is a special case, but one that needs to be covered. But if the u-turn costs are sufficiently high u-turns will only be suggested for this special case (when there really is no other option). Actually there always needs to be some kind of constraint (like a one-way road, turn restriction, etc.) for a u-turn to occur, otherwise there would always be a path that does not go to the place where the u-turn occurs at all.

You start a fresh route search in the only feasible direction?

You cannot tell what is the feasible direction without calculating the route. For example if you want to prevent u-turns at the stops of a multi-stop route you need to constrain the starting direction at each stop. And once you do that you might find you are in the situation where going into this direction it is not possible to turn around without a u-turn. Imagine this road network where you arrive at s from the West. Your only options are doing a u-turn at s, or continuing in Eastern direction and doing a u-turn somewhere. You can't tell if turning around without a u-turn is possible without exploring the road network (running the routing algorithm). But once you found the route and see it includes a u-turn you could tell the driver to turn around wherever possible, right when she gets back to the car and even before she starts driving to the next stop.
         -------
         |
----s-------------------
            |  |  |

The thing is that experience and reality...

Thanks for your input, this sounds reasonable.
Ok, I think there are basically two issues here:

GraphHopper (using default settings and the hosted API) suggests u-turns too often
Some mappers add too many non-sensical no_u_turn restriction relations to OSM

For 1) we need to think about our settings and there is an issue with the relationship of the priority and u_turn_costs in CustomWeighting (the meaning of the u_turn_costs parameter changes once the priority is below 1), something we are currently investigating.
For 2) I think it is most important to use the OSM wiki to communicate what should and should not be mapped. Not only for mappers adding these relations but also for those removing them again, so there is something they can argue with.
The issues could or could not be related. Like I said, GraphHopper currently still ignores the no_u_turn tag: #2570, so 'fixing' the map does not even change anything, at least when using vanilla GraphHopper.

Thank you the issue with understanding.
Just FYI, it is interesting to see how different routers come to different solutions in this case.

I like OSRM's solution. :wink:

GH should yield a similar result with the PR from @easbar: https://github.com/graphhopper/graphhopper/pull/2761

Yes, with #2761 I got the same route as OSRM (using the turning circle at the end of Winding Wood Court). And when I increased the u_turn_costs (without this PR) I got the Valhalla route plus another alternative:

At first sight it seems logical to add no-u-turn tagging to OSM, because there are traffic signs that indicate this (just like for normal turn restrictions), but tagging this everywhere to satisfy the routers, even in places where there is no 'no u-turn' sign, would be the wrong thing to do.

It is already done in some cities. Not 100% coverage of course, but close to >90%.

Simply because of safety considerations, it is almost always a bad idea to suggest a U-turn to any driver at any arbitrary junction node.

Maybe it is in your country, but in many others it's not. There is at least two cases where u-turns aren't something special:

dedicated u-turn lanes
regular city junctions with traffic lights.

The thing is, in many cases it's necessary to use curbside constraint, otherwise the router will suggest illegal turns in the middle of the road (yes, this means every other OSM router I know is broken by design). And with this constraint it's also necessary to correctly suggest u-turns, respecting mapped restrictions and in some cases implicit restrictions.

example
This is the case I'm talking about. Without curbside constraint every router will suggest the red path from A to B, not respecting which side of the road you are on. Here it means taking forbidden u-turn across the street, and then either another forbidden u-turn or stopping on the other side of the street and walking across.
With Graphhopper one can account for that, but then u-turns become a problem. Currently I can either forbid them altogether (the default), or allow them anywhere regardless of the restrictions (the blue line on the picture). Both are unusable.

Can you please provide some links to the cases or mention some of the cities you have in mind?

Ukraine, Belarus, major cities in Russia, other ex-USSR countries.

Example
https://www.openstreetmap.org/node/4810494980 Street with a double solid line mapped as a single line in OSM, and junctions (service ways) with restrictions for left turn and u-turn.
https://yandex.ru/maps/-/CDrkf28x street view

Suggesting a u-turn to a driver that might be dangerous or impossible seems a lot more problematic to me than avoiding it and suggesting an alternative (possibly longer) route instead. Don't you agree?

Maybe; maybe not. It depends on the user/driver and their specific use case. That's why it's configurable, right?

I'm not sure what you are trying to say.

Sorry, maybe that's because I have two different things in mind.
First, the general observation, not about any specific case. People do u-turns all the time, at least in the cities I lived in. So when the router ignores potential route with the u-turn the driver knows is legal and safe, and suggests 2x longer route instead, there's a strong chance this router will go out of the window. Same with suggesting u-turn where it's not legal or impossible.
I think this is not the case where one can strongly de-prioritize u-turns, trading potential longer routes for assumed safety. Both will be considered broken.
Second, the specific use case where this issue is more clear and even critical: calculating routes for taxi drivers.
There is a taxi company in my city that is using routing on the OSM data (possibly OSRM, but I don't know for sure). They need to calculate the exact route the driver will take (including specific side of the street) to measure the distance and display the price. Because of that long detours are not acceptable, as well as impossible/illegal u-turns.
Currently they have an issue with routing that I showed in the picture in the previous post. They don't know how to fix this in the router, so they are trying to 'fix' the map by splitting the streets in two ways (even where that is against common practice) and messing up everything around in the process. Our local OSM community had enough of this and we wanted to suggest them a better router.

Anyhow, what you can do already is to add an intermediate target on the same edge you start your route in the direction you want to go

That's a good workaround, thanks!


Botón Flotante

Minor Fixes
//Description
Se reemplazan los dos botones de confirmar el pago por uno solo "flotante" que acompaña al usuario a medida que se desplaza por la pantalla de revisa y confirma.
//Issue related
Closes #
Requirements

[ ] Coverage > 90%

Note:

[ ] Android Lint check

Note:

[x] Code Style checked

Note:

[ ] Tested with "Don't keep Activities" configuration.

Note:
If impacts documentation (new components, inputs or outputs?)

[ ] PR to develop-docs

Note:

Codecov Report

Merging #613 into develop will decrease coverage by <.01%.
The diff coverage is 0%.

@@             Coverage Diff             @@
##           develop     #613      +/-   ##
===========================================
- Coverage    27.28%   27.27%   -0.01%
===========================================
  Files          204      204
  Lines        15672    15687      +15
  Branches      1380     1380
===========================================
+ Hits          4276     4279       +3
- Misses       10946    10957      +11
- Partials       450      451       +1

Impacted Files
Coverage Δ

...ontrollers/reviewandconfirm/ReviewSummaryView.java
0% <ø> (ø)
:arrow_up:

...java/com/mercadopago/ReviewAndConfirmActivity.java
0% <0%> (ø)
:arrow_up:

.../mercadopago/presenters/GuessingCardPresenter.java
23.22% <0%> (+0.2%)
:arrow_up:

...ain/java/com/mercadopago/GuessingCardActivity.java
21.88% <0%> (+0.22%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5db1e32...eae5dce. Read the comment docs.


subprocess.Popen need shell=True on windows.

From a windows install of NEURON,
bash-5.1$ runmodels --norun --workdir foo 3670
succeeds in the sense of
$ cd foo/NTW_NEW
$ nrniv
NEURON -- VERSION 8.2a-109-gff2af9afd+ olupton/more-c++ (ff2af9afd+) 2022-06-09
Duke, Yale, and the BlueBrain Project -- Copyright 1984-2021
See http://neuron.yale.edu/neuron/credits

loading membrane mechanisms from E:\hines\models\nrn-modeldb-ci\foo\NTW_NEW\nrnmech.dll
Additional mechanisms from files
 HH2.mod IAHP.mod ICAN.mod IT2.mod capump.mod gabaa.mod gabab1.mod
oc>

and in foo.json, one can see that the compilation occurred.

Just launched the whole CI for hines/windows-modelrun here: https://github.com/neuronsimulator/nrn-modeldb-ci/actions/runs/2515415377
If all OK, will merge

The CI got stuck, we should investigate this locally.


Add "directional move"

In many cases I would find it useful to be able to move a window in a direction, instead of swapping. Would that be difficult to implement.
I had a short look at tree.cpp, but could not figure it out. Given any pointers I would love to help implement this.

I think I get what you mean. Basically you want to detach a window, and reinsert it in a direction?
If this is the case, it should be quite trivial to implement as it will be more or less the same as the existing command kwmc window -x.

Exactly. I did not notice the window -x command. I will try to expand on that and see if it is useful in real usage.

Implemented in latest commit.

Great. You could add an argument to ToggleWindowFloating that is passed to RemoveWindowFromBSPTree avoid moving on the detatch if the intent is to reattach immediately afterwards.
`void ToggleWindowFloating(int WindowID, bool MoveOnDetatch)
{
if(IsWindowOnActiveSpace(WindowID) &&
KWMScreen.Current->Space[KWMScreen.Current->ActiveSpace].Mode == SpaceModeBSP)
{
int WindowIndex;
if(IsWindowFloating(WindowID, &WindowIndex))
{
KWMTiling.FloatingWindowLst.erase(KWMTiling.FloatingWindowLst.begin() + WindowIndex);
AddWindowToBSPTree(KWMScreen.Current, WindowID);
        if(KWMMode.Focus != FocusModeDisabled && KWMMode.Focus != FocusModeAutofocus && KWMToggles.StandbyOnFloat)
            KWMMode.Focus = FocusModeAutoraise;
    }
    else
    {
        KWMTiling.FloatingWindowLst.push_back(WindowID);
        RemoveWindowFromBSPTree(KWMScreen.Current, WindowID, MoveOnDetatch, MoveOnDetatch);

        if(KWMMode.Focus != FocusModeDisabled && KWMMode.Focus != FocusModeAutofocus && KWMToggles.StandbyOnFloat)
            KWMMode.Focus = FocusModeStandby;
    }
}

}
`

Thanks for noticing, this change is now in effect.


Investigate replacing the Makefile with nox

Is your feature request related to a specific problem?
Make lacks some features in the programmatic department, and although one can resort to bash it then breaks across platforms. Our Makefile is getting a bit messy/complex and as seen on fidesops, additional python files had to be written due to limited Make functionality.
Describe the solution you'd like
Replace Make as a dev tool with nox. It is purely pythonic, which means we can use the full power of python to handle our dev tasks as well as natively supports things like matrix testing (testing across multiple python versions, for instance).
Describe alternatives you've considered, if any
Continuing to use the Makefile as-is or writing more custom python scripts to deal with additional complexity.
Additional context
This is very much a "does this make sense? Is it feasible?" type of change proposal. I'm not sure how this will look in practice but its worth trying.

This sounds like a good idea to explore to me. There is a good chance Python developers haven't used Make before so this could be more intuitive for contributors also.


[QUERY] Ability to use built-in Lists workflow steps

With the recent GA release of Slack Lists (yay!), I'd like to build some custom functions with Lists.
I do know that it will take a while for true Lists API methods to be released, but are there abilities for this Deno SDK to use the built-in Slack workflow steps (Add to List, Update a List, etc.) when building a coded workflow?  I did a quick search in the code and didn't immediately see anything.

Hi @mcsescott - Yes, confirming that we do plan to add support for built-in Slack workflow steps to be able to be used in coded workflows.

@srajiang is there any ETA on Slack Lists support in workflows?

Update here: I am working on getting these released! I am hitting some errors testing them in coded workflows, so I just want to make sure they work properly before releasing. Unless I hit an unexpected pitfall, these will be available in the upcoming deno-sdk release - soon!

Another update here: this has proved more challenging than expected. There are some workflow-builder assumptions built into these steps that will take more effort to tackle and make them generic enough for use in code. Plus, the steps don't seem very developer-centric as is: there is no 'create list' step, for example.
Will revisit in the future. Apologies for this. If you have strong feelings about the need for these steps in code, please let your voice be heard by emailing<EMAIL_ADDRESS>and submitting that as a feature request.

Thanks. I’ve found some workarounds for the things I am attempting to do.
Keep up the good fight!


[3.x] Improve error message when OS.execute() fails on Windows

This takes the error message from 4.x and backports it to 3.x.
PS: I noticed we don't have any such message when OS.execute() fails on Linux (and possibly macOS). This also applies to 4.x.
Testing project: test_os_execute_3.x.zip

See https://github.com/godotengine/godot/issues/42719#issuecomment-2292617583.

Preview
Before
ERROR: Condition "ret == 0" is true. Returned: ERR_CANT_FORK
   at: execute (platform/windows/os_windows.cpp:2981)
ERROR: Condition "ret == 0" is true. Returned: ERR_CANT_FORK
   at: execute (platform/windows/os_windows.cpp:2981)

After
ERROR: Could not create child process: non-existent-command
   at: (platform/windows/os_windows.cpp:2981)
ERROR: Could not create child process: non-existent-command with arguments
   at: (platform/windows/os_windows.cpp:2981)

Thanks!


Using Intellij Shortcuts.  Cmd + Y to delete line does not work

VSCode Version: Code 1.17.2 (b813d12980308015bcd2b3a2f6efa5c810c33ba5, 2017-10-16T13:47:41.889Z)
OS Version: Darwin x64 17.0.0
Extensions:

Extension
Author (truncated)
Version

latex-workshop
Jam
3.5.5

vscode-elixirc-mix-linter
PTD
0.0.3

latex-preview
ajs
0.5.1

intellij-idea-keybindings
k--
0.2.15

vscode-elixir
mjm
1.0.0

Steps to Reproduce:

Reproduces without extensions: Yes/No

Please file this issue against the intellij keybindings extension: https://github.com/k--kato/vscode-intellij-idea-keybindings/issues


support baker in oasis runtime and editor

create repo engine-baker and support baker in runtime.
support baker capability in oasis editor

migrate to editor: https://github.com/oasis-engine/editor/issues/112


One transcript with several gene names

Hello!
I am trying to analyse differential gene expression in 83 samples split up into three groups following the protocol described by Pertea et al., 2016 (doi:10.1038/nprot.2016.095).
Now I have two CSV files for each pairwise comparison, one with the transcripts results and other with gene results. I have assigned a column with the gene name to the gene results file following Freeze's instructions (https://www.biostars.org/p/218136/).
A lot of rows have a dot "." as gene name... I suppose that it means "unknown gene". Is it correct? But when I look for these transcripts in the transcripts results file I find that the same transcript has multiple gene names. What's happen?
A technical question: What does StringTie do when a transcript matches with multiple exomes/genes? How does StringTie count it?
Gene results:
    geneNames feature          id        fc         pval       qval       exp_sig
1385            .    gene MSTRG.18605 0.3612696 8.836918e-05 0.02780747 Downregulated
2009            .    gene  MSTRG.2251 0.3705158 1.723619e-04 0.03990178 Downregulated
3565            .    gene MSTRG.31880 0.2855206 2.766333e-05 0.02210375 Downregulated
3577            .    gene  MSTRG.3192 0.4190300 2.500196e-04 0.04590761 Downregulated
7730            .    gene MSTRG.52616 0.4974403 1.902062e-04 0.04187998 Downregulated
8791 LOC102724999    gene MSTRG.57635 0.4391518 7.886925e-05 0.02780747 Downregulated
8833         RRM2    gene  MSTRG.5791 0.1491026 9.653982e-06 0.01517076 Downregulated
8941            .    gene MSTRG.58419 0.4839879 2.913421e-04 0.04883999 Downregulated
9248            .    gene  MSTRG.7286 0.4853837 4.294071e-05 0.02455956 Downregulated

Extract info about MSTRG.18605 in transcript file
          geneNames     geneIDs    feature    id        fc        pval      qval
12632         . MSTRG.18605 transcript 92336 0.8248940 0.348378059 0.8105198
12634         . MSTRG.18605 transcript 92338 0.5838309 0.180876736 0.7302217
12635         . MSTRG.18605 transcript 92339 0.4058340 0.051912182 0.5780383
12636         . MSTRG.18605 transcript 92340 0.3070723 0.002123351 0.2270620
12637         . MSTRG.18605 transcript 92341 0.8145933 0.510077645 0.8781143
12638     HLA-C MSTRG.18605 transcript 92342 0.1351463 0.002860136 0.2504040
12639         . MSTRG.18605 transcript 92343 1.0737243 0.810680044 0.9544281
12640         . MSTRG.18605 transcript 92344 0.4356676 0.012957412 0.3988734
12641         . MSTRG.18605 transcript 92345 0.5661032 0.014102596 0.4047605
12642         . MSTRG.18605 transcript 92346 0.4012696 0.048469168 0.5719337
12643         . MSTRG.18605 transcript 92347 0.2884399 0.004146397 0.2847510
12644         . MSTRG.18605 transcript 92348 0.3167699 0.033571700 0.5162445
12645         . MSTRG.18605 transcript 92349 0.3484434 0.017986318 0.4343761
12650         . MSTRG.18605 transcript 92355 1.1018119 0.684596561 0.9242470
12656         . MSTRG.18605 transcript 92362 1.2783697 0.407525370 0.8302648
12657         . MSTRG.18605 transcript 92363 0.6356763 0.383143717 0.8199931
12658         . MSTRG.18605 transcript 92364 0.9109425 0.752058633 0.9371627
12659         . MSTRG.18605 transcript 92365 0.7067905 0.098177182 0.6499381
12661         . MSTRG.18605 transcript 92367 0.7979155 0.371616108 0.8166484
12663         . MSTRG.18605 transcript 92372 0.8521393 0.347975902 0.8105198
12664         . MSTRG.18605 transcript 92373 1.1114767 0.630943495 0.9137496
12665         . MSTRG.18605 transcript 92374 1.1819176 0.227935366 0.7639951
12667         . MSTRG.18605 transcript 92376 0.8134280 0.242299301 0.7643093
12668         . MSTRG.18605 transcript 92377 0.8685366 0.616908528 0.9100701
12669     HLA-B MSTRG.18605 transcript 92378 0.4077784 0.080955383 0.6381334
12670         . MSTRG.18605 transcript 92380 1.0450625 0.892268294 0.9766652
12671     HLA-B MSTRG.18605 transcript 92381 0.8218658 0.667177666 0.9193687
12672     HLA-B MSTRG.18605 transcript 92382 0.7802102 0.441900921 0.8454283
12673         . MSTRG.18605 transcript 92383 1.1639513 0.778891293 0.9450891
12675         . MSTRG.18605 transcript 92386 0.5742808 0.170972054 0.7188115
12676   MIR6891 MSTRG.18605 transcript 92387 0.7063845 0.054794258 0.5844075
12677   MIR6891 MSTRG.18605 transcript 92389 1.3352687 0.217143588 0.7592203

what if analysing differential gene expression following the protocol "An alternate, faster differential expression analysis workflow can be pursued if there is no interest in novel isoforms (i.e. assembled transcripts present in the samples but missing from the reference annotation), or if only a well known set of transcripts of interest are targeted by the analysis. This simplified protocol has only 3 steps (depicted below) as it bypasses the individual assembly of each RNA-Seq sample and the "transcript merge" step. "? avoid the case that One internally generated locus IDs like MSTRG.18605  with several gene names ?

I am not sure about that but, I think not... because if you see at the table, the locus MSTRG.18605 has two gene IDs i.e. HLA-B and HLA-C (referenced in the human genome) and the sequences of both HLA are overlapped...

As is known, StringTie is a fast and highly efficient assembler of RNA-Seq alignments into potential transcripts. It uses a novel network flow algorithm as well as an optional de novo assembly step to assemble and quantitate full-length transcripts representing multiple splice variants for each gene locus. The flowchart of the protocol described by Pertea et al., 2016 (doi:10.1038/nprot.2016.095) is as following :

whether this flowchart include the optional de novo assembly step ? and leading to the issue that one StringTie gene/loci (MSTRG.#) matching multiple reference gene names.
@gpertea

What about the novel transcripts in such cases? Suppose, if a novel transcript is assigned MSTRG.ID loci and that ID has multiple gene names associated with it.
In such a case, how to figure out which gene_name does that transcript belong to?

Maybe an option is to extract this transcript and make blast? StringTie should be very strict in those cases because it is not able to distinguish which gene this transcript belongs to... no?

I agree that the annotation of StringTie's merged output is somewhat lacking at this point.. I am considering improving that in a future version by adding one ore more GTF tags that would actually show which reference gene_id (or gene_name, if the user prefers that) any particular StringTie output transcript might belong to (just by overlap, not by fully matching a reference transcript).
Currently the user should use third party programs in order to actually annotate those cryptic MSTRG.ID loci and MSTRG.ID.ID transcripts in some cases. GffCompare can address some of it (with its "annotation mode") but I guess it still does not do it quite conveniently enough for easy inclusion in analysis pipelines.
I'll leave this topic open (and of course take suggestions) until I get around implement (or find) a solution to properly address these needs of gene annotation of StringTie's output..

Hi, I am using stringtie to assemble RNA-seq reads and I have the same issue where one MSTRG locus overlaps with multiple reference loci. Could you please let me know what approaches I can take to annotate  these MSTRG loci?
I've already tried gffcompare and it din't help

Hi Everybody.
I have been having the same problem for a while and therefore I tried solving it as described below. There are two overlapping problems at work here:

Some genes have been "merged" due to genomic overlap of transcripts from the different genes.

Gene names (or non-StingTie gene_ids) have not been assigned.

From my experience with StringTie data there are typically thens of thousands of missing gene_names and ~50% of the missing gene_names are due to these problems (the rest are novel genes).
To solve this problem I implemented a "rescue" algorithm which simply:

Assign gene_names to transcripts. For cases when this involves "merged" genes transcripts are assigned by overlap i genomic coordinates (ignoring introns) as long as the largest overlap is X times larger than the second largest overlap.
Split merged genes by their gene_names.

The solution is implemented in my R package IsoformSwitchAnalyzeR (available in >1.11.6). You simply use the importRdata() function to import the GTF file into R. During this import it will fix the isoform annotation and clean up the rest of the annotation. From the resulting switchAnalyzeRlist object you can analyse isoform switches with predicted functional consequences with IsoformSwitchAnalyzeR or use the extractGeneExpression() function to get a gene expression/count matrix for analysis with other tools.
Hope this helps.
Cheers
Kristoffer

The solution is implemented in my R package IsoformSwitchAnalyzeR (available in >1.11.6). You simply use the importRdata() function to import the GTF file into R. During this import it will rescue the isoform annotation (which can be rescued) and clean up the rest of the annotation. From the resulting switchAnalyzeRlist object you can analyse isoform switches with predicted functional consequences with IsoformSwitchAnalyzeR (as exemplified here) or use the extractGeneExpression() function to get a gene expression/count matrix for analysis with other tools. This count/expression matrix will be equivalent to what is obtained by using txmeta or tximeta except it will be corrected for the merged gene problem and fully annotated with gene_names.

Hi Kristoffer,
Where can I find the function extractGeneExpression()? I cannot find it in your manual or the vignette. Did you remove the function from the package?


Support for rego policy over PPL

Pomerium has rego support as a alternative to PPL. There is no explicit mention to if this is supported via the existing or new annotation for ingress-controller
https://www.pomerium.com/docs/capabilities/authorization#rego-support
https://www.pomerium.com/docs/reference/routes/policy
https://www.pomerium.com/docs/k8s/ingress#set-authorization-policy
Trying to define a rego policy using the existing annotation has a error with the latest main build of ingress-controller e.g.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rego-test
  annotations:
    ingress.pomerium.io/policy: |
      package pomerium.policy
      allow := true
    ingress.pomerium.io/pass_identity_headers: "true"
spec:
  ingressClassName: pomerium
  rules:
    - host: "verify.localhost"
      http:
        paths:
          - pathType: Prefix
            path: /
            backend:
              service:
                name: verify
                port:
                  number: 8000

Events:
  Type     Reason       Age                From              Message
  ----     ------       ----               ----              -------
  Warning  UpdateError  3s (x19 over 18m)  pomerium-ingress  parsing ingress: annotations: applying policy annotations: parsing policy: invalid rules in policy: unsupported type for rule: parser.String

Hi @Dev25, thanks for the question. Custom Rego policies are supported only for Pomerium Enterprise. We're working on updating the documentation to make this clearer.


Container registry lists the architecture unknown/unknown when manifest attestations are present

Related:
https://github.com/orgs/community/discussions/45969
https://github.com/docker/build-push-action/issues/755
https://codeberg.org/forgejo/forgejo/issues/780

I recently noticed that packages that have been pushed to the container registry using docker buildx build now have a new architecture listed, unknown/unknown. After some further investigation, I discovered that what is happening is that the Docker Buildx CLI is including image attestations for these images, which seems harmless, but causes GitHub Packages to list the unknown/unknown arch used for these attestations under the "OS / Arch" tab. This is similar to another topic recently posted, but this is more of a UI bug rather than an issue inspecting or pulling the manifests.
The current behavior means that if you push an image for linux/arm64 and linux/amd64, you'll get three architectures listed, linux/arm64, linux/amd64, and unknown/unknown. The unknown/unknown arch has a hash listed, but that is not shown in the version list anywhere unless you dig deep to find it. This appears to inconsistent with what the Docker Hub shows, which, in this case, would be only two architectures linux/arm64 and linux/amd64.

Same problem here - this confused me quite a bit.
Can someone please check why exactly this is happening and is this something that is wanted?

Can you try https://github.com/go-gitea/gitea/issues/32170#issuecomment-2491269071?
docker buildx create --use --name {image}
docker buildx build --platform linux/amd64,linux/arm64 -t {gitea.domain}/{owner}/{image}:latest . --push --provenance false

Hi @hiifong,
thanks. Adding --provenance false to the docker buildx-command did the trick.
I wonder what the downsides of this are?

Also deleting single "layers" was a pain in the as*..
Why is there no "delete" button for a whole package and for tags?
Like possible at DockerHub.


Unmagle code

Hi,
I was wondering can the code be mode more readable?
Especially for MMM-awesome-alexa.js and node_helper.js.
Right  now code for both these files is in a single line.
I want to reuse parts of the code to see if I can enable Google Assistant too.
Thanks,
~Saurabh

They are deliberately designed to be like that
They are intentionally not readable because it is compiled from TypeScript
look into the src folder, it is very readable


Added the mode "bilinear" in the upscaling2D layer.

Summary
Thanks @ahundt for your work. I was able to get Theano working and be compatible with what was doing tensorflow, but only for (2, 2) upscaling. Other factors like (4, 4) show different results for the theano's implementation and the tensorflow's implementation.
I also couldn't figure out how to use other factors like (3, 2) with theano. Which is why, with the Theano backend, for implementation and backend compatibility reasons, only (2, 2) is implemented.
Related Issues
See @ahundt 's PR: #9303
PR Overview

[x] This PR requires new unit tests [y/n] (make sure tests are included)
[x] This PR requires to update the documentation [y/n] (make sure the docs are up-to-date)
[x] This PR is backwards compatible [y/n]
[x] This PR changes the current API [y/n] (all API changes need to be approved by fchollet)

It seems that tests/test_multiprocessing.py::test_multiprocessing_predict_error is failing. I don't think it's related to this PR.

cool! thanks for pushing this through @gabrieldemarmiesse!

You're welcome!

@gabrieldemarmiesse
tf.image.resize_image has an align_corners parameter  docs, which is impossble to pass using keras upsampling layer.

Hi thank you for the hard work!  I have a question about the tensorflow implementation of resize_images.
The current implementation in keras uses tf.image.resize_images, which suffers from a list of problems depending on the version:

the bilinear interpolation have alignment problems: https://hackernoon.com/how-tensorflows-tf-image-resize-stole-60-days-of-my-life-aba5eb093f35
the tf.image.resize_images (for nearest neighbor) is not as efficient as tf.tile + tf.reshape, as is tested in https://github.com/tensorflow/tensorflow/issues/18711#issuecomment-386401703
For 'channel_first' option in K.resize_images, the tensor has to go through 2 extra layers of transpose, it is going to slow down the operation?
It seems to me that tf.images.resize_images are designed for image pre-processing, not for intermediate layers (in early days, this op only runs on CPU, not GPU) are too generic for the simple goal of scaling the tensor by integer times, and tf.tile+tf.reshape sounds more reasonable for nearest, and tf.tile+tf.reshape+tf.conv2d (with pre-defined kernel) seems more reasonable for bilinear option.

In order not to break the previous code, would that make sense to add an option like 'nearest_by_tile', which uses the K.repeat_elements as in the CNTK back-end?  Than you for your consideration and please correct me if I mis-understood things here


Create first visualization to be shown on Oiretutka.fi

We should create the first visualization that will be shown on oiretutka.fi main page AND is embeddable to participating media sites as well.
For this we need:

Decide the first data set for visualization
Design the first visualization
Develop the visualization

This is handled on other issues now


fix(react-email): ESM Issue with await import of the compiled email templates

What was the issue?
Errors like the following when running email export:
TypeError: component.default is not a function
    at /Users/app/mailbox/node_modules/.pnpm/react-email@2.0.0_eslint@8.56.0/node_modules/react-email/cli/index.js:778:75
    at step (/Users/app/mailbox/node_modules/.pnpm/react-email@2.0.0_eslint@8.56.0/node_modules/react-email/cli/index.js:186:23)
    at Object.next (/Users/app/mailbox/node_modules/.pnpm/react-email@2.0.0_eslint@8.56.0/node_modules/react-email/cli/index.js:127:20)
    at asyncGeneratorStep (/Users/app/mailbox/node_modules/.pnpm/react-email@2.0.0_eslint@8.56.0/node_modules/react-email/cli/index.js:12:28)
    at _next (/Users/app/mailbox/node_modules/.pnpm/react-email@2.0.0_eslint@8.56.0/node_modules/react-email/cli/index.js:30:17)

This was happening because of a await import of the esbuild CJS bundled version of the email templates which
had flaky exports because of CJS and ESM incompatibility. The best solution was to use a require in the place of a await import or a .default.default which would be flaky as well.
How can I test to make sure it's fixed?

Run npx tsx ../../packages/react-email/src/cli/index.ts export inside of ./apps/demo
Verify that it doesn't error with TypeError: component.default is not a function

Hi @gabrielmfern , thanks for your change.
what should I do now? I just want to use the CLI to build my email project 😂

@AnnatarHe Just wait out for a bit until @bukinoshita can review it, I can't approve it anymore since I made changes 😆

Nice. Thank you @gabrielmfern.
@bukinoshita Any update on this? Sorry for pushing you like this but it's blocking me at work. Otherwise, I'd have to either go the separate repo route or use an alternative.

@tim3w4rp You can always use a patch to not be blocked.

@gabrielmfern Waiting for this to be merged as well to incorporate into a project using Resend. Is there a recommended patching approach in the meantime? I tried the yarn add 'AnnatarHe/react-email#canary/packages/react-email' approach through GitPkg but it didn't work as expected.

@gabrielmfern Waiting for this to be merged as well to incorporate into a project using Resend. Is there a recommended patching approach in the meantime? I tried the yarn add 'AnnatarHe/react-email#canary/packages/react-email' approach through GitPkg but it didn't work as expected.

You can use patch-package utility to do this. I cloned this repo, installed dependencies, applied changes from this PR and then rebuilt the library to get proper bundles with changes from this PR.  Once you have the file (index.js) you can place it in you projects node_modules and then run patch-package like described in it's readme.


ShareVia('sms') file handling

Hi, I was sharing a text + base64 image via the share() method and everything worked great.
Now I wanted my image to be passed only when sharing through SMS, so I made a custom sharing modal, and calling shareVia functions depending on what the user clicks.
The thing is that now I can't pass an image to shareViaSMS or shareVia('sms').
The shareViaSMS() does not accept file parameters and when I do:
window.plugins.socialsharing.shareVia('sms', short_url, null, base64_data, null);
I get this error (ios8):
2014-10-31 09:06:58.886 myapp[1195:487092] LaunchServices: invalidationHandler called
2014-10-31 09:06:58.892 myapp[1195:487053] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Application tried to present a nil modal view controller on target <MainViewController: 0x1567d830>.'
*** First throw call stack:
(0x29e1de3f 0x3750ac8b 0x2d59d689 0x2d59f15b 0x2d39bd93 0xb8af5 0xb7e15 0xad745 0xacfcf 0x2ab2d59f 0x29de458f 0x29de399f 0x29de2005 0x29d30621 0x29d30433 0x310df0a9 0x2d31b359 0xb30eb 0x37a8aaaf)
libc++abi.dylib: terminating with uncaught exception of type NSException

Is it possible to share a base64 image through SMS without the share() function ?
Thanks

@EddyVerbruggen I'm looking to send a png via SMS/MMS in Android. I saw you had the image field commented out. Is it possible to do this in Android? I forked your repo and tried to get it to work, but kept getting "no activity found to handle intent".
Thanks,
Dustin


Fixed manageRoles bug in lib. Fixes #507

Forgot to change ChannelPermissons inside lib directory. Should actually be correct now.
Also fixed commenting in Role.js related to same bug.

This was already fixed in a previous PR like I mentioned in discord. see #525

For future reference:
2. If the issue hasn't been patched, edit the files in the src folder
3. Prior to making the PR, build the lib files by running grunt --dev

https://github.com/hydrabolt/discord.js/blob/master/CONTRIBUTING.md


revert: use conventional commit messages

Reverts c771a3ec97aae02d61946b988602888e4dcd0378 and c771a3ec97aae02d61946b988602888e4dcd0378 and applies the same changes with conventional commit messages.
Please don't squash them!

@raphaelschwinger LGTM. Lets wait for the first release to pass the CI, so we can successfully merge this PR.


Fix Byron address format

The CDDL definition for Byron era has two mistakes in it:

It marked addrdistr as option. However, you can see that in the written spec, the field is not optional

I'm a little confused by the Rust implementation which marks the field as required but at the same time allows it to be missing during deserialization (setting BootstrapEraDistr as the default value) so maybe there is some history I am missing here (if this is intended, then maybe the .default type should be used in the CDDL definition)
EDIT: it turns out Dd addresses always contain the map, but Ae2 addresses just contain an empty map instead (which thus need a default stake_distribution). However, it wouldn't be right to set it as the .default in the CDDL because it really is missing instead of being a default value

Both the written spec and the binary spec are missing the protocolMagic attribute in addresses. Potentially the cause of this is because the protocolMagic was only added partway through the Byron era (notably, added when the public testnet was released) and it was only used on testnets.

You could argue that maybe this field is included in the Unparsed :: Word8 ⇀ Bytes } mapping used for attributes in the written spec, but this unparsed mapping is also missing from the binary spec so it's better to have protocolMagic than nothing I guess

I believe the actual definitions for addrattr and protocolMagic actually should be
addrattr = {   0 : bytes .cbor addrdistr
           , ? 1 : bytes                   ; HDAddressPayload (but may contain anything)
           , ? 2 : bytes .cbor protocolMagic
           }

I haven't been able to validate this because currently our codegen tool doesn't support the .cbor CDDL keyword so I can't see if it generates the same (de)serialization code

I also think the definition of address is wrong.
Right now it's
address = [ #6.24(bytes .cbor ([addressid, addrattr, addrtype])), u64 ]

but shouldn't it be
address = [ #6.24(bytes .cbor ([addressid, addrattr, addrtype])), addrattr, addrtype ]

This is the CDDL definition that worked for me
blake2b-224 = bytes .size 28

addressId = blake2b-224 ; blake2b-224 of sha256 of cbor(addrtype, spendingData, addrAttributes)
stakeholderId = blake2b-224

protocolMagic = u32
HDAddressPayload = bytes

; Addresses

singleKeyDistr = (0, stakeholderid)
bootstrapEraDistr = (1, uint)

stakeDistribution =
  [  bootstrapEraDistr
  // singleKeyDistr
  ]

publicEd25519Bip32 = bytes .size 64
script = bytes .size 32
publicEd25519 = bytes .size 32

spendingDataPubKeyASD = (0, publicEd25519Bip32)
spendingDataScriptASD = (1, script)
spendingDataRedeemASD = (2, publicEd25519)

spendingData = [
     spendingDataPubKeyASD
  // spendingDataScriptASD
  // spendingDataRedeemASD
]

addrType = 0 ; Public Key
         / 1 ; Script
         / 2 ; Redeem

addrAttributes = {
             ? 0 : bytes .cbor stakeDistribution         ; no value -> BootstrapEraDistr
           , ? 1 : bytes .cbor HDAddressPayload      ; strictly speaking, this may contain anything
           , ? 2 : bytes .cbor protocolMagic
           }

addressContent = [addressid, addrAttributes, addrtype]

crc32 = u64
address = [ #6.24(bytes .cbor address), crc32 ]

I'm not familiar with the Byron serialization code at all, but I had a look to see if I could figure out how it worked.

The FromCBOR instance for the Address Attributes is here:
https://github.com/input-output-hk/cardano-ledger/blob/14e1bcc89e275600efb8b66c7cefeebfb1764204/eras/byron/ledger/impl/src/Cardano/Chain/Common/AddrAttributes.hs#L108-L110
You can see that the bulk of the work is done by fromCBORAttributes, which takes an initial value and an iterating function (so like a fold). The are only two known fields in the Address Attributes:
https://github.com/input-output-hk/cardano-ledger/blob/14e1bcc89e275600efb8b66c7cefeebfb1764204/eras/byron/ledger/impl/src/Cardano/Chain/Common/AddrAttributes.hs#L41-L44
The initial values sets the derivation path to Nothing and the network magic to NetworkMainOrStage. The iterating function (named go) only knows how to parse fields 1 and 2, corresponding respectively to derivation path and the network magic. Note the absence of something corresponding to key 0, addrdistr.
Any fields that the iterating function (called go in the the FromCBOR instance, and updater inside fromCBORAttributes) does not know how to handle are ignored by fromCBORAttributes, but persist inside attrRemain:
https://github.com/input-output-hk/cardano-ledger/blob/14e1bcc89e275600efb8b66c7cefeebfb1764204/eras/byron/ledger/impl/src/Cardano/Chain/Common/Attributes.hs#L214-L225
Perhaps the correct CDDL description is:
addrattr = { ? 1 : bytes
           , ? 2 : protocolMagic }

Note that the ToCBOR instance also does not serialize the 0 key:
https://github.com/input-output-hk/cardano-ledger/blob/14e1bcc89e275600efb8b66c7cefeebfb1764204/eras/byron/ledger/impl/src/Cardano/Chain/Common/AddrAttributes.hs#L83

Of course, we shouldn't guess, but actually test this. This was just my first pass to try to understand...

Related, but I also noticed that the definition of byron witnesses in post-Shelley (https://github.com/input-output-hk/cardano-ledger/blob/master/eras/babbage/test-suite/cddl-files/babbage.cddl#L356) should be bytes .cbor addrAttributes

I noticed that in the definition address = [ #6.24(bytes .cbor ([addressid, addrattr, addrtype])), u64 ], the u64 at the end is actually a crc32. What's strange is that the crc32 should be a u32 (as its name implies). Does the node actually allow up to u64 values here?

I noticed that in the definition address = [ #6.24(bytes .cbor ([addressid, addrattr, addrtype])), u64 ], the u64 at the end is actually a crc32. What's strange is that the crc32 should be a u32 (as its name implies). Does the node actually allow up to u64 values here?

Great observation, thank you. It looks like the node does not allow up to u64 as the wire spec says, but in fact u32 as one would expect:
https://github.com/input-output-hk/cardano-ledger/blob/7f7a8ae757a5f60ed759efed8b0bc721277b95f7/eras/byron/ledger/impl/src/Cardano/Chain/Common/CBOR.hs#L117-L132
Note that actualCrc is a Word32, that expectedCrc is the value read from the wire, and that both values have the same type since they are compared without conversion.
It would still be great to test this to be certain.


iPhone < 5s temperature overlap

If you have temperature in F and use iPhone 5 or 4s, in portrait mode temperature is partially cut.
you might set minimum font size to scale down temperature label a bit
minimumFontSize="18" do the job

Thanks for reporting this issue, will fix it.


Command 'erb.toggleTags' not found (rendering extension unusable)

It's all in the title. :) Basic install, latest VSCode, yours is the first package I installed. If more info is needed, please let me know, I'll happily provide it.

Thank for the advise. I think is fixed on version 0.2.1 released today.


Create about docs component, pipeline for markdown to jsx

Functional changes: PR creates a new component, About, to render frontend documentation, and incorporates it into routing. Component takes markdown, converts it to JSX using react-markdown. Rehype-slug, rehype-autolink-headings, rehype-add-classes extract headers from the markdown and make each one an entry in a table of contents (TOC).
Style changes: Implement styles in About.module.css to improve document readability. Set nav bar position to fixed at the top of the screen. Set TOC position to fixed at the top of its container.

The rehype-add-classes package used an outdated version of the hast-util-select package, which has been flagged for potential DDOS vulnerabilities. Trying to upgrade hast-util-select to a stable release that fixes the issue (>= 4.0.2) while still using rehype-add-classes is not possible, since rehype-add-classes calls to use v1.01 hast-util-select,and therefore is impossible to force an upgrade with npm.
This issue has been addressed in a couple of places. The first being in an issue on the rehype-add-classes repo. The other being in a PR on the Nasa General Coordinates Network (believe it or not). The TLDR is to replace rehype-add-classes with rehype-class-names, which provides the same functionality but updates core packages to fix the security vulnerability.
I swapped these two libraries out for each other and updated the remaining dependencies. Frontend now has zero known dependency vulnerabilities when running npm audit, and the new About functionality seems to be working as expected.


Missing import on Flask 0.11.1

Traceback found (redacted for relevancy to Flask):
  File "/usr/local/lib/python2.7/dist-packages/flask/__init__.py", line 21, in <module>
    from .app import Flask, Request, Response
  File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 27, in <module>
    from . import json, cli
  File "/usr/local/lib/python2.7/dist-packages/flask/cli.py", line 17, in <module>
    import click
ImportError: No module named click

Just recently upgraded from 0.10 to 0.11. Did not see a requirements.txt for 3rd party dependencies.

https://github.com/pallets/flask/blob/master/setup.py#L77

OK. Please be aware that going from 0.10.1 to 0.11.1 did not install click for me; I had to upgrade to 0.11 and THEN to 0.11.1 for it to work.

@wschmrdrNS How did you install Flask?

sudo pip install --upgrade -r requirements.txt
Inside of requirements.txt for my project, I have:
Flask==0.11.1

I can't reproduce your issue.  I created a Python 2.7 env, added Flask==0.10.1 in requirements.txt, pip install -r requriements.txt, modified to ==0.11.1, pip install -U -r requirements.txt.  Flask was upgraded and Click was installed.
Unrelated, but never sudo pip install.  Install in a virtualenv.

Please, remove 0.11 from https://pypi.python.org/pypi

Why?

Sorry @untitaker, it happened to me as I use --no-deps in production environment. Solved here.


chore: cleanup Prisma Client extensions Preview feature flag mentions

Closes #4880

Unfortunately this should now mention that they were in preview since and until in at least some places so users of older Prisma versions can still discover that information to be able to use it in their projects.

That will be mentioned. The PR is still a draft 😄

I've updated the pages with admonitions of when it got into Preview & General Availability (cc @janpio). Let me know if it's what you had in mind.

Yep, that looks like what is needed 👍


add rkerner introduction blog post

@gunnarmorling there it is. feedback highly appreciated.

Nice write-up, @rk3rn3r! If I should suggest one thing, perhaps also add a forward-looking angle? Perhaps some things you look forward to working on, or what excites you about working on OSS full-time? Right now it's very focused on the past, so some outlook would be nice. Other than that, could you change the file name to today's date? I'll merge it and tweet from the Debezium handle in the afternoon. Thanks!

Thx, will be live in a bit!


Formatter

We should be able to format Requests/Responses to string.
Basic interface
<?php

namespace Http\Message;

use Psr\Http\Message\RequestInterface;
use Psr\Http\Message\ResponseInterface;

/**
 * Formats a request or a response into string.
 *
 * @author Márk Sági-Kazár<EMAIL_ADDRESS> */
interface Formatter
{
    /**
     * Formats a request.
     *
     * @param RequestInterface $request
     *
     * @return string
     */
    public function formatRequest(RequestInterface $request);

    /**
     * Formats a response.
     *
     * @param ResponseInterface $response
     *
     * @return string
     */
    public function formatResponse(ResponseInterface $response);
}

Some questions

Should we separate Request/Response format method into separate interfaces? (Like in case of message factories)

Default implementations

Simple text formatter: https://github.com/php-http/plugins/blob/master/src/Normalizer/Normalizer.php
Curl command formatter: https://github.com/namshi/cuzzle

+1
not sure about separating. a guzzle formatter makes absolutely no sense for a response. but it could just reuse the simple text formatter for the response and do its cool stuff on requests. that way, things are much simpler than having two interfaces that 90% of the time are provided by the same formatter.


Fix typos

Very interesting project!
Fixed typo in the documents.

Thanks @ssssota for your patch!
@ereslibre this LGTM now. But you are the change request owner :-)

Thank you @ssssota!


Updated require hook usage to use babel-register

Just updated the Require Hook usage page.
Should now be babel-register instead of babel-core/register

Thanks


Any recommended rotating proxy provider?

I am  using rotatingproxies.com right now, the performance is terrible. Also, if I were given 10 port proxy service. how to utilize that? open 10 instance of Youtube viewer and set thread as 1? and is it possible to set watch time, such as just watch 40 seconds instead of stream the entire video.  so making the process more efficient.
thanks

I don't have any recommendations. You can play around with another proxy provider. no 10 thread proxy service means you can maximum use 3 thread in my script. because to load a website a lot of requests are going through. They count every request as a thread.
how come watching 40 secs of your video is more efficient? you want to watch every time only 40 sec and youtube will see a pattern... then comes the average watch time duration the most important success factor in YouTube. Watching lesser time of your video will decrease your average watch time duration.
However, you can edit youtube_viewer.py change the following line.

video_len = video_len*.4


Address long-standing issue with right shift -- fixes #102

After several days and many discarded designs, I think I have found a reasonable way to i) optimize the generation of integer arithmetic constants and computations (hi @franziskuskiefer, @karthikbhargavan, please take a look at HACL branch protz_shift to see the effects of the change), ii) fix the semantics of right-shift (hi @s-zanella, @polubelova), and iii) in the process of doing so, fix integer conversion warnings for right-shifts (there are still spurious warnings in a lot of places in HACL, but at least that one reported on Slack by @franziskuskiefer in FrodoKEM is now gone).
I know that others have encountered #102 in one form or another in the past, so my request to @tahina-pro: can you please take a careful look at this PR and tell me whether you believe this compilation scheme is correct or not? In addition, can you see if this helps get rid of your earlier workarounds?
Thanks!

Note that in Wasm every subexpression of type smaller than uint32 is masked
https://github.com/FStarLang/karamel/blob/da83fc312e2f3833f5746dfb702a456048a7a3da/lib/CFlatToWasm.ml#L621-L634
so nothing to fix there


Access Google Analytics API using the API key created within the Google Service Account, not by signing in with a gmail account

Good Afternoon!
Using the Google Analytics Connector how can I access Google Analytics API using the API key created within the Google Service Account, not by signing in with a Gmail account?
I'd guess that's not possible given the options in this documentation, and in which case I should possibly try to use the default Web Connector, but not certain how - could you give an example here?
Thanks in advance,
Jon.
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 5b1dbd00-8e52-f989-bc84-15f2f4e97b11
Version Independent ID: a96aae45-f677-d62c-17d1-f02bb9120cad
Content: Power Query Google Analytics connector - Power Query
Content Source: powerquery-docs/Connectors/GoogleAnalytics.md
Service: powerquery
GitHub Login: @bezhan-msft
Microsoft Alias: bezhan

#assign:bezhan-msft

Hi @Acteon-Jon
Thanks for your dedication to our documentation. Unfortunately, at this time we have been unable to review your issue in a timely manner and we sincerely apologize for the delayed response. We are closing this issue for now, but if you feel that it's still a concern, please respond and let us know. If you determine another possible update to our documentation, please don't hesitate to reach out again. You can also direct product support requests to the Power Query discussion group.  #please-close


Docker container names

Works on my machine ™

Hi @gg7, thanks for your contribution ! Here is a quick review.

Good points @yadutaf.

Feel free to squash / cherry pick my commits.

Merged, thx ! (I never squash other people commits btw)


contrib: Add simplified version of Kubernetes relnotes script

This allows to automatically extract the release notes from the list of
merged PRs based on PR labels and special release-note blocks in the
body of the PR.
The relnotes script is derived from Kubernetes and scans for PRs which have been merged in the specified git revision range and extracts all PRs which have one of the following labels set:

release-note/major
release-note/minor
release-note/bug

Extensive documentation on how to use this will be submitted in separate PR covering the contribution guidelines.
Example:
# v0.12

Major Changes:

Bugfixes Changes:
* Test for release note (#1681, @joestringer)
    * fooo

It might be worth mentioning in the PR or commit message that it seems you can set GITHUB_TOKEN in your environment rather than specifying the token on the commandline every time.

Addressed in README


Rename setting convertSameNameSubFileToGroupIndexPage to useFolderLinkFromSameNameSubFile for consistency

Rename this
convertSameNameSubFileToGroupIndexPage
to
useFolderLinkFromSameNameSubFile
to be consistent with
useFolderLinkFromIndexFile
PS: just killed another evening debugging why the folder links are clickable.
Cheers.

Hello, thank you for reporting the issue.
This option was suggested before the useFolderLinkFromIndexFile option was added. It aims to use a subfile as an index page and at the same time not show that file in the sidebar.
The difference is that the useFolderLinkFromIndexFile option does not separately handle not showing the file in the sidebar (which is handled by the includeFolderIndexFile option).
However, I now agree with you about changing the name according to your comment for uniformity of both options.
I have changed the name to useFolderLinkFromSameNameSubFile as you requested, which is reflected in the 1.28.0 version.
Thank you.


About breaking changes

Hello!  I use ComfyUI's API a lot and it requires that all REQUIRED fields are sent with the POST json. Please, when you add new fields like "top_p" and "top_k", make them OPTIONAL with the OLLAMA's recommended default value. Thanks!

Sorry. I wasn't aware of that I'll be more careful, thank you. Maybe I can drag those as optional. Would that be okay?

Sure! Don't forget to add the default values to those parameters in your "def describe_picture( )". Thank you very much!

Okay I now move most of the parameters to optional and I am passing unto describe. I also unify the nodes into one and this looks to be more solid solution going forward to not break workflows the IFChatPrompt Node now will contain an SD mode.


Lock logging gem to < 2.0.0

See issue here: https://github.com/papertrail/remote_syslog_logger/issues/12

The Gemfile is only used for running tests, so adding gem version constraints here won't help people who depend on this gem.


Use CAM service account instead of CAC token (single)

To support autoscaling of CAC's in the future, we will need to generate
new CAC tokens to be used during CAC installations. To generate new
CAC tokens, we have used a python script during startup on the CAC
which will CAM API calls using the user-provided CAM service account
credentials.
Both plaintext and encrypted secrets is supported for this single
connector deployment using CAM service account instead of CAC token.
Signed-off-by: Edwin Pau<EMAIL_ADDRESS>

I will be applying the comments from the other review to this commit as well, then merging them together since they are related.


Support RadioButtons

You must enable an option to switch between radio buttons and dropdown.

How about two different widgets and a faryshta\widgets\EnumBase widget to make it easier to make third party widgets

+1

:+1:


added templates for issue and PR

This PR will fix issue #59, here I have added a issue and Pull request template.

Tbh, I don't know the reason for that.
Initially I haven't added any extra folder and pushed changes in my local branch and doesn't find any positive impact.
Then I found a repo where this the file were added in temp folder and it that repo was working fine for me ,so I did the same here in hope to working this way : )

Tbh, I don't know the reason for that. Initially I haven't added any extra folder and pushed changes in my local branch and doesn't find any positive impact. Then I found a repo where this the file were added in temp folder and it that repo was working fine for me ,so I did the same here in hope to working this way : )

Okay, no problem. Can you try reverting the temp directory changes and try to push only the two required files. Let me know if you face any problems.

@Sparsh1212  Did you added point for PR too, I think you only added for issue points?

@Sparsh1212 Did you added point for PR too, I think you only added for issue points?

You have been allotted two points. 1 for the issue (Already allotted at the time of opening the issue) and 1 for the fix. Since this was a relatively very easy issue.