Request for improved build queue

The CQUI version was removed when the Vanilla game added it's own version but it doesn't work right. It won't let you queue a Harbor AND a Lighthouse and every time you capture a city you have to keep coming back and adding damaged buildings to the queue rather than all at once. Really annoying to me as I take a LOT of cities.

I concur. The original CQUI queue was awesome.

Is the any chance this feature request can get some love? I realize this is probably not an easy upgrade but it's probably about the most annoying thing left to fix in the base UI.

This is such an important QoL feature, that I'm surprised no one has bothered to do it yet. I'm going to do a bit of a brain dump and will come back to this once I have a better understanding of modding in Civ VI (I've never made a video game mod before).
Firstly, I see there is an integrations folder. The PQ folder seems to be empty, so does that mean that it is been removed from the project? Last time I checked the mod description on Steam, it said that it still had it.
Looking at https://github.com/kblease/ProductionQueue and comparing ProductionPanel.lua, there is a 5000 line difference (along with other files). That is pretty crazy, but my HOPE is that that is mostly from writing the queue from scratch, so tweaking the in-game production queue will be much easier (hopefully as simple as overriding existing functions).

Design

So from a functionality perspective, what we need are

Events for requesting add, remove, change order in the production queue
The ability to change the selectability of an item (in the production panel)
The ability to add an item (to the production panel)
The ability to find all visible items in the production panel
The ability to find all selectable items in the production panel
The ability to find all queued items for a city
The ability to change the order of queued items
The ability to find buildings/units based on their requirements (and if anything extra has to be done to support unique buildings/units, wonders, and city projects)

Event Logic

on adding a building/district to the production queue:

adjust the production panel accordingly

get list of all dependencies

if in production panel, evaluate if it now passes the requirements to be buildable and if it does, make selectable (non-obvious requirements would be like district placement for wonders)
if not in production panel and all other requirements are met (i.e. tech), add to the panel

does anything other than a district add new items to the panel? If not, then 'all other requirements' would not include building requirements. As in having the banking tech and adding commercial hub to the queue will add market, banking to the panel, but only market is selectable (also the commercial hub project will get added).
if other stuff than districts can add new items, then logic probably needs to be conditionally separated for districts and other stuff.

when removing an item from the queue

check the queue for any dependent items and remove them
adjust the production panel accordingly

this is going to do the opposite of what is described for adding to the panel, but it's going to have to do some sort of recursion or loop to properly handle multiple levels

a complicated example:

production queue of holy site, shrine, temple, mahabodhi temple and we remove the holy site

we probably want to start from the end. For our removed item, recursively find all dependent items that are in the queue and need adjustments. In this case, we would have an ordering of { mahabodhi temple, temple, shrine, holy site }. Now iterate through this.

remove mahabodhi from the queue (remove label if that enhancement is done)
remove temple from the queue. Apostle can no longer be bought, something like mahabodhi temple is no longer selectable, the religious building is no longer selectable
remove shrine from the queue. Missionary can no longer be bought, temple is no longer selectable (and any wonders that require a shrine aren't selectable either).
remove holy site from the queue. Missionary, Apostle, all holy site buildings, holy site project are removed from the panel (and adjust wonder selectability like before).

when moving an item around in the queue

check the queue for any required items and whether those items need to be moved too

move all requirements with your selected item

moving forward example:

scout, scout, holy site, warrior, shrine -> holy site, shrine, scout, scout, warrior when moving shrine to the 1st item

moving backward example:

scout, holy site, shrine, warrior, scout -> scout, warrior, holy site, shrine, scout when swapping holy site with warrior

More stuff to think about

with the described logic, will this automatically support restoring of damaged districts/buildings?
IIRC, you get locked into the production cost of a district once you place it on the map. When you queue a district, you have to select a tile, but the vanilla queue won't place it on the map unless you put it as the 1st item. It also doesn't adjust anything (doesn't account for district limit or if that tile is occupied by another queued district). Ideally, you should be able to put it on the map just from adding it to the end of the queue, but as long as you are still locked into the production cost, I guess it would be ok (I'm guessing we aren't though).
on a related note, there's no incentive to actually placing wonder buildings on the map until they've been put as the 1st item in the queue. Placing a label on the selected tile and removing the label once the building has been placed would be a neat QoL feature though. Additionally, a corner case that should be tested is moving a wonder to the 1st item in queue while it has dependencies that are also in queue (proposed design would be to move dependencies in front of it, but need to make sure we don't physically place the wonder on the map).

This is such an important QoL feature, that I'm surprised no one has bothered to do it yet. I'm going to do a bit of a brain dump and will come back to this once I have a better understanding of modding in Civ VI (I've never made a video game mod before).
Firstly, I see there is an integrations folder. The PQ folder seems to be empty, so does that mean that it is been removed from the project? Last time I checked the mod description on Steam, it said that it still had it.
Looking at https://github.com/kblease/ProductionQueue and comparing ProductionPanel.lua, there is a 5000 line difference (along with other files). That is pretty crazy, but my HOPE is that that is mostly from writing the queue from scratch, so tweaking the in-game production queue will be much easier (hopefully as simple as overriding existing functions).

Design

So from a functionality perspective, what we need are

Events for requesting add, remove, change order in the production queue
The ability to change the selectability of an item (in the production panel)
The ability to add an item (to the production panel)
The ability to find all visible items in the production panel
The ability to find all selectable items in the production panel
The ability to find all queued items for a city
The ability to change the order of queued items
The ability to find buildings/units based on their requirements (and if anything extra has to be done to support unique buildings/units, wonders, and city projects)

Event Logic

on adding a building/district to the production queue:

adjust the production panel accordingly

get list of all dependencies

if in production panel, evaluate if it now passes the requirements to be buildable and if it does, make selectable (non-obvious requirements would be like district placement for wonders)
if not in production panel and all other requirements are met (i.e. tech), add to the panel

does anything other than a district add new items to the panel? If not, then 'all other requirements' would not include building requirements. As in having the banking tech and adding commercial hub to the queue will add market, banking to the panel, but only market is selectable (also the commercial hub project will get added).
if other stuff than districts can add new items, then logic probably needs to be conditionally separated for districts and other stuff.

when removing an item from the queue

check the queue for any dependent items and remove them
adjust the production panel accordingly

this is going to do the opposite of what is described for adding to the panel, but it's going to have to do some sort of recursion or loop to properly handle multiple levels

a complicated example:

production queue of holy site, shrine, temple, mahabodhi temple and we remove the holy site

we probably want to start from the end. For our removed item, recursively find all dependent items that are in the queue and need adjustments. In this case, we would have an ordering of { mahabodhi temple, temple, shrine, holy site }. Now iterate through this.

remove mahabodhi from the queue (remove label if that enhancement is done)
remove temple from the queue. Apostle can no longer be bought, something like mahabodhi temple is no longer selectable, the religious building is no longer selectable
remove shrine from the queue. Missionary can no longer be bought, temple is no longer selectable (and any wonders that require a shrine aren't selectable either).
remove holy site from the queue. Missionary, Apostle, all holy site buildings, holy site project are removed from the panel (and adjust wonder selectability like before).

when moving an item around in the queue

check the queue for any required items and whether those items need to be moved too

move all requirements with your selected item

moving forward example:

scout, scout, holy site, warrior, shrine -> holy site, shrine, scout, scout, warrior when moving shrine to the 1st item

moving backward example:

scout, holy site, shrine, warrior, scout -> scout, warrior, holy site, shrine, scout when swapping holy site with warrior

More stuff to think about

with the described logic, will this automatically support restoring of damaged districts/buildings?
IIRC, you get locked into the production cost of a district once you place it on the map. When you queue a district, you have to select a tile, but the vanilla queue won't place it on the map unless you put it as the 1st item. It also doesn't adjust anything (doesn't account for district limit or if that tile is occupied by another queued district). Ideally, you should be able to put it on the map just from adding it to the end of the queue, but as long as you are still locked into the production cost, I guess it would be ok (I'm guessing we aren't though).
on a related note, there's no incentive to actually placing wonder buildings on the map until they've been put as the 1st item in the queue. Placing a label on the selected tile and removing the label once the building has been placed would be a neat QoL feature though. Additionally, a corner case that should be tested is moving a wonder to the 1st item in queue while it has dependencies that are also in queue (proposed design would be to move dependencies in front of it, but need to make sure we don't physically place the wonder on the map).

Updating the production panel
After digging through ProductionPanel.lua, it looks like there is a refresh function that is responsible for recreating all the state information. This involves creating the list (table) of what will show in the production panel and whether or not it will show as buildable. There is a function for the build queue 'canProduce' that is used both for controlling if the item is added to the list and whether it is added as buildable. Unfortunately, this function doesn't seem to be exposed. We can check all occurrences of that function and add in an 'or' conditional for whether or not the build requirements get met if you take into account the production queue. We should also take a look at the results table that is returned by 'canProduce' in case it gives stuff like missing building ids that would be easy to find in the production queue.
The complications for this are

We don't know exactly what 'canProduce' does. It is used both with 2 and 3 parameters, so it's behavior is situational.
There is also tons of duplicated code for this logic across districts, buildings, units, and projects.

So as long as adding/removing buildings to/from the queue triggers a refresh, we will properly update the production panel.
Managing the build queue
ProductionHelper.lua has RemoveQueueItem, SwapQueueItem, and MoveQueueItem that are hooked into stuff like mouse events. Those functions currently just take in indexes. We will situationally need to perform multiple operations on a single call, so we could pass in the build queue as the last parameter or handle that logic in a separate function that we define in ProductionPanel.
Remaining questions
Still not sure how we determine requirements from a building. Like how do we get the relationship of Shrine <-> Temple. I'm guessing that is defined in the simpler modding areas. Just not sure how to access from lua.

Updating the production panel
After digging through ProductionPanel.lua, it looks like there is a refresh function that is responsible for recreating all the state information. This involves creating the list (table) of what will show in the production panel and whether or not it will show as buildable. There is a function for the build queue 'canProduce' that is used both for controlling if the item is added to the list and whether it is added as buildable. Unfortunately, this function doesn't seem to be exposed. We can check all occurrences of that function and add in an 'or' conditional for whether or not the build requirements get met if you take into account the production queue. We should also take a look at the results table that is returned by 'canProduce' in case it gives stuff like missing building ids that would be easy to find in the production queue.
The complications for this are

We don't know exactly what 'canProduce' does. It is used both with 2 and 3 parameters, so it's behavior is situational.
There is also tons of duplicated code for this logic across districts, buildings, units, and projects.

So as long as adding/removing buildings to/from the queue triggers a refresh, we will properly update the production panel.
Managing the build queue
ProductionHelper.lua has RemoveQueueItem, SwapQueueItem, and MoveQueueItem that are hooked into stuff like mouse events. Those functions currently just take in indexes. We will situationally need to perform multiple operations on a single call, so we could pass in the build queue as the last parameter or handle that logic in a separate function that we define in ProductionPanel.
Remaining questions
Still not sure how we determine requirements from a building. Like how do we get the relationship of Shrine <-> Temple. I'm guessing that is defined in the simpler modding areas. Just not sure how to access from lua.

Extracting the failure reason
If something can't be built, the results object from 'canProduce' is a list of failure reasons. These failure reasons are the strings that show as a tooltip when hovering over a building.  We will likely have to deduce failure types through something like a "contains" call (for displaying the tooltip, there is a locale lookup that happens afterward. Idk if that means this string will always be English or not. If it isn't, then cross language support will be a bit difficult...).
Buildings seem to have a prereq building list, but I don't think it has any value since we need to be comparing against what is in the build queue and a building with multiple prereqs will still need to isolate which prereq building is the one mentioned in the fail text.
Accessing items from the queue
ProductionHelper and ProductionManager each have a function for refreshing the queue. This iterates through the queue and builds a table of queue instances. Both call ProductionHelper's CreateQueueInstance function, which shows how to extract the item information (like building name). The active item in production is skipped in this queue instance stuff, but there is already a getter in the BuildQueue object to get that.
We will need to know the contents of the BuildQueue during the 'getData' function, but also on BuildQueue order manipulation events. I'm not sure how realistic it is to manage this separately from the underlying BuildQueue. As a first pass at least, we should just recreate the queue in every relevant function call (getData, RemoveQueueItem, SwapQueueItem, MoveQueueItem). The queue operation functions can add an extra parameter to know if it's part of a batch operation or not.

i.e. scout, holy site, shrine moving shrine first would be a batch operation to get holy site, shrine, scout. You can build BuildQueue and figure out the operation list in the initial swap call and the rest of the calls won't need to do it. MoveQueueItem is never used in the code, should check what it does (if it moves to a spot and pushes everything after back 1, then that would be very useful).

Extracting the failure reason
If something can't be built, the results object from 'canProduce' is a list of failure reasons. These failure reasons are the strings that show as a tooltip when hovering over a building.  We will likely have to deduce failure types through something like a "contains" call (for displaying the tooltip, there is a locale lookup that happens afterward. Idk if that means this string will always be English or not. If it isn't, then cross language support will be a bit difficult...).
Buildings seem to have a prereq building list, but I don't think it has any value since we need to be comparing against what is in the build queue and a building with multiple prereqs will still need to isolate which prereq building is the one mentioned in the fail text.
Accessing items from the queue
ProductionHelper and ProductionManager each have a function for refreshing the queue. This iterates through the queue and builds a table of queue instances. Both call ProductionHelper's CreateQueueInstance function, which shows how to extract the item information (like building name). The active item in production is skipped in this queue instance stuff, but there is already a getter in the BuildQueue object to get that.
We will need to know the contents of the BuildQueue during the 'getData' function, but also on BuildQueue order manipulation events. I'm not sure how realistic it is to manage this separately from the underlying BuildQueue. As a first pass at least, we should just recreate the queue in every relevant function call (getData, RemoveQueueItem, SwapQueueItem, MoveQueueItem). The queue operation functions can add an extra parameter to know if it's part of a batch operation or not.

i.e. scout, holy site, shrine moving shrine first would be a batch operation to get holy site, shrine, scout. You can build BuildQueue and figure out the operation list in the initial swap call and the rest of the calls won't need to do it. MoveQueueItem is never used in the code, should check what it does (if it moves to a spot and pushes everything after back 1, then that would be very useful).

The fail reason isn't adequate for determining if we should show/enable a building because it will only show the district failure reason if it is missing both the district and building. The building holds references to it's requirements, so I've taken the approach of evaluating those and looking at the queue in addition to the districts/buildings owned by the city. I think the failure reasons are still a valuable way of weeding stuff out though, so we won't override anything unless the building has a failure reason.
To test: unique buildings, religious buildings, mutually exclusive buildings
When adding a district to the build queue, there is already a panel refresh (assuming the same for building).
I've got the 1st building to show up in the list and show as enabled when adding a district to the build queue. Unfortunately, clicking the building seems to do nothing. Having the district as the active production target also causes it to leave the list (by design), but this now results in the newly shown buildings displaying under another district (so we should get rid of the behavior that removes it).
On the bright side, newly added buildings don't show as purchase-able.
To test: when queueing more districts than the city can build, make sure that any buildings with that district as a requirement are also removed from the queue (I think they will if the queue actions are implemented properly).
I'm thinking of making a repo for this. Like the old production queue, this should be a feature that exists standalone and can be integrated into CQUI. Will link the repo when I set it up (never made a repo before, so fingers crossed I use the right settings...).

So the reason the newly enabled buildings don't do anything when clicked is that the operation request doesn't seem to go through. There doesn't seem to be any feedback for that and this isn't exposed in lua, so there is nothing we can do about it.
 CityManager.RequestOperation(city, CityOperationTypes.BUILD, tParameters);
I tried calling on BuildQueue:CreateBuilding, but that doesn't seem to work either.
We do have control over the display portion of the build queue though. The only way I see this working is if we track everything ourselves and make the display based off our queue instead of the underlying one. This will be a nightmare, but is theoretically doable. Will have to check if these queue's are used at all. ProductionPanel has RefreshQueue, ProductionHelper has RefreshProductionQueue. Both have similar behavior, so I think both need to produce the modified queue...

So the reason the newly enabled buildings don't do anything when clicked is that the operation request doesn't seem to go through. There doesn't seem to be any feedback for that and this isn't exposed in lua, so there is nothing we can do about it.
 CityManager.RequestOperation(city, CityOperationTypes.BUILD, tParameters);
I tried calling on BuildQueue:CreateBuilding, but that doesn't seem to work either.
We do have control over the display portion of the build queue though. The only way I see this working is if we track everything ourselves and make the display based off our queue instead of the underlying one. This will be a nightmare, but is theoretically doable. Will have to check if these queue's are used at all. ProductionPanel has RefreshQueue, ProductionHelper has RefreshProductionQueue. Both have similar behavior, so I think both need to produce the modified queue...

Looks like adding stuff to the display of the build queue does work. Doing stuff on the RefreshQueue functions doesn't seem to be enough to keep the multi-queue synched with it though.

Looks like adding stuff to the display of the build queue does work. Doing stuff on the RefreshQueue functions doesn't seem to be enough to keep the multi-queue synched with it though.


Get rid of Type.GetTypeCode

It looks like Type.GetTypeCode is currently missing in .NET Core, and so it makes our code less portable.
See discussion at #513.

Here you have an object and for object the implementation is [trivial] (https://github.com/AutoFixture/AutoFixture/pull/513/files#diff-03b8bf48a2b8c724baa0216d538313e9R22). The problem is that when you have only the Type you have to manufacture an instance.

One step at a time :smiley:

As @lbargaoanu points out, since we already have a value, and we're only testing for the types distinguishable with TypeCode, wouldn't it be less indirect to pull it out of the value using the IConvertible interface?

Very nice. I think @lbargaoanu's approach is more efficient and also makes the code easier to read.

I've just updated the Pull Request. Notice how the diff-output looks cleaner now :smiley:

Thank you for your contribution :+1:
I didn't release a new version of AutoFixture, since this doesn't change any behaviour.

Thank you for the great feedback @lbargaoanu and @ploeh.


Keptn CLI not backward compatible. Missing Keptn cluster version checks result in unclear error messages

Its possible to use a new Keptn CLI as the connected Keptn cluster, e.g: using CLI version 0.7.2 against a 0.7.1 Keptn Cluster.
This for instance leads to an unclear error message when executing keptn send event start-evaluation as the 0.7.2 CLI assumes the new /evaluation API endpoint which doesnt exist on a 0.7.1 installation. The error message simply returns that the /evaluation endpoint returned an error which is not very telling for the end user for troubleshooting.
I suggest that the CLI should do some version checks and either
1: warn the user that the CLI is newer or older then the keptn cluster and that an update on either side is suggested
2: is backward compatible, e.g: use the OLD API endpoints if the Keptn version is older

@johannes-b we seem to have missed this breaking change of the CLI in the release notes (we listed the new API endpoint though).
@grabnerandi I agree that this is a change that is unexpected for a patch release, like from 0.7.1 to 0.7.2.

1: warn the user that the CLI is newer or older then the keptn cluster and that an update on either side is suggested

We can extend issue https://github.com/keptn/keptn/issues/2571 such that we print a warning if CLI version is different from the API version. However, this means that in the case of a slow response from the Keptn API, the CLI will have to wait for the response, for every time you call the CLI.

2: is backward compatible, e.g: use the OLD API endpoints if the Keptn version is older

Being backward (and potentially forward compatible) for API and CLI requires quite some development effort. IMHO as long as our major version is 0, we do not need to be backwards compatible. We do however need to document such breaking changes.

@christian-kreuzberger-dtx I would go with the approach of checking the API version before executing a command with the risk of slowing down the command. Thanks for referencing it with #2571 that should be implemented with this issue.


[RFC] Pass RTL flag to rules function

This change is necessary for the sake of component styles being able to adapt to current presence of RTL mode.
As an example, suppose that we have a Chat Message component with the following layout

Relevant thing for us is the fact that 'timestamp' region has left padding, to ensure it won't overlap content of the 'author' area. However, in the RTL mode we would like this padding being applied on the right side of the component, not still on the left one:

But, unfortunately, at the moment we are unable to detect whether RTL is enabled from the 'rules' function. What would solve the problem is that if we would pass isRtl flag to rules functions, such that the following will be possible:
export default rules = () => {
  root: ({ isRtl }) => {
      padding: isRtl ? .. : ...
  }
}

Yep, this is required.  Please see comment and then merge.

comments are addressed


Firebase sdk dependencies

Is it necesery to add compile "com.google.firebase:firebase-core:9.2.1" or compile 'com.google.firebase:firebase-messaging:9.2.1' in build.gradle?
Same question for react-native-firebase-analytics.
Thanks.

I asked the question because got this:
google-services plugin could not detect any version for com.google.android.gms or com.google.firebase, default version: 9.0.0 will be used. please apply google-services plugin at the bottom of the build file.

does adding it removing the warning?
I have crash report compile with specific version in gradle myself

I did add those.

@mizinin are you good if I close the issue?

I added compile "com.google.firebase:firebase-core:9.2.1" to build.gradle. fcm and analytics works well and project compiles without any warning


Implement schema validation in JSON Schema -  (Request/response schema validator in Ballerina)

Description:
Currently ballerina does not have an approach to validate requests and responses using JSON schema.
Example: Schema validation use cases

The schema is created from the url and its stored contents are validated against itself.
An URL can point to a local file, where sub folder, current working directory.
Schema created with a Map and call to json parse etc.

Validating request/response based on a predefined json or xml API schema is helpful to     ensure whether the user have sent the request according to the schema and also to ensure whether the back-end have sent the correct response to the request.

@KasunAratthanage Shall we open a separate issue to track XSD based validation?

This can be achieved by providing data binding support for JMS

Closing this issue. Since we moved JMS module to https://github.com/wso2-ballerina/module-jms repository.
Please refer wso2-ballerina/module-jms#10 to get latest updates of this issue


Update classifier code for mypy

Description

Remove all star imports for classifier code from palace.manager.core.classifier import *

These were the last star imports we had 🎉

Add a __getattr__ method to classifier/__init__.py to let mypy know to expect dynamic imports
Move around some of the classifier code to break import cycle
Remove duplicated GradeLevelClassifier class

Motivation and Context

Trying to get to a place where we can toggle on check_untyped_defs mypy option.

How Has This Been Tested?

Running in CI

Checklist

[X] I have updated the documentation accordingly.
[X] All new and existing tests passed.

Codecov is complaining, but any code that isn't covered by this, wasn't covered before, so I think this is fine for review without adding more coverage.


std_within_in_meters not working

I have a query in my app that looks like this
def search_beacons(%{latitude: lat, longitude: lng, range: range}) do
    centerpoint = %Geo.Point{coordinates: {lng, lat}, srid: 4326}
    from(b in OverallBeacon)
    |> where([b], b.is_expired == false)
    |> where([b], st_dwithin_in_meters(b.location, ^centerpoint, ^range))
  end

when I run repo.all() over this, I get an empty list. however if I run the query directly

select * from overall_beacons b
where b.is_expired = false
and ST_DWithin(b.location, 'SRID=4326;POINT(-122.416 37.779)', 0.2)

I get several results.
I ran logged the output query before being run into ecto
{"SELECT o0.\"id\", o0.\"auto\", o0.\"batch_id\", o0.\"is_expired\", o0.\"personal\", o0.\"property\", o0.\"social\", o0.\"location\", o0.\"inserted_at\", o0.\"updated_at\" FROM \"overall_beacons\" AS o0 WHERE (o0.\"is_expired\" = FALSE) AND (ST_DWithin(o0.\"location\"::geography, $1::geography, $2))",
 [%Geo.Point{coordinates: {-122.416, 37.779}, properties: %{}, srid: 4326}, 500]}

here's an example record that comes up when I run the query directly using navicat
id	auto	property	personal	batch_id	location	is_expired	inserted_at	updated_at	social
946012e5-958f-417c-a347-f551e52d8286	55	22	0	87b4db24-5a6f-11e9-9d20-0a0d335f0b74<PHONE_NUMBER>E6100000F4FDD478E9925EC0F853E3A59BEC4240	f	2019-04-09 02:31:07	2019-04-09 02:31:07	0

I am using geo_postgis 3.1

dug a bit deeper and using _to_sql
#Ecto.Query<from o0 in Scout.Data.OverallBeacon, where: o0.is_expired == false,
 where: fragment("ST_DWithin(?::geography, ?::geography, ?)", o0.location, ^%Geo.Point{coordinates: {-122.416, 37.779}, properties: %{}, srid: 4326}, 5)>

with the params
[%Geo.Point{coordinates: {-122.416, 37.779}, properties: %{}, srid: 4326}]

which I expanded to
SELECT o0."id", o0."auto", o0."batch_id", o0."is_expired", o0."personal", o0."property", o0."social", o0."location", o0."inserted_at", o0."updated_at"
FROM "overall_beacons" AS o0
WHERE (o0."is_expired" = FALSE)
AND (ST_DWithin(o0."location"::geometry, 'SRID=4326;POINT(-122.416 37.779)'::geometry, 5))

this query works in navicat but I'm getting nothing from Repo.all()

also, whats the difference between st_dwithin_in_meters and st_dwithin?


bpf prog run can cause DPC timeouts

Describe the bug
Slow BPF program with very large repeat count.
bpftool prog run id 196610 data_in data_in.txt data_out data_out.txt repeat 100000
Due to running at dispatch, the DPC timeout will eventually fire.
OS information
No response
Steps taken to reproduce bug
bpftool prog run id 196610 data_in data_in.txt data_out data_out.txt repeat<PHONE_NUMBER>
Expected behavior
Machine doesn't bug check.
Actual outcome
DPC timeout.
Additional details
When running BPF programs at DISPATCH IRQL, the worker thread should periodically drop down too passive to allow other DPCs to run.

In my opinion, each iteration should separately raise to DISPATCH.  One should not run multiple iterations within the same DPC timeout


[Bug]: Uncommitted changes are seen on existing git apps

Is there an existing issue for this?

[X] I have searched the existing issues

Description
Uncommitted changes are seen on existing git apps

Steps To Reproduce

Visit ee-4987.dp.appsmith.com
Open any existing git connected app
Notice that there are uncommitted changes seen. However, the same app on release doesn't show any uncommitted changes

Example git app: https://ee-4987.dp.appsmith.com/app/promo-2feb-2/page1-65bc822036e8962e466b0bb6?branch=test_new
Git repo: https://github.com/laveena-en/promo-2Feb
I have branched off from main (where the uncommitted changes were seen) to branch test_new to check the diff
Diff: https://github.com/laveena-en/promo-2Feb/commit/d032fd0dccb56be74c66efd8e2b4872e171b4083
Public Sample App
https://ee-4987.dp.appsmith.com/app/promo-2feb-2/page1-65bc822036e8962e466b0bb6?branch=test_new
Environment
Production
Severity
High (Blocker to building or releasing)
Issue video log
No response
Version
Cloud

@laveena-en We are using this DP - https://ee-4517.dp.appsmith.com/applications. Can you check if this is still valid on this dp? This could probably from release changes also. I have merged the latest release. I don't have an existing git connected app on this dp, hence asking you to reverify the same.

@AnaghHegde Since ee-4517.dp.appsmith.com/applications is a fresh instance, we are using ee-4987.dp.appsmith.com to test for existing apps since it contains a dump of release. I re-checked, and I still see uncommitted changes(this issue is not seen on release). I've invited you to the app/workspace to help further debug
WS name: Promo-2Jan
App: https://ee-4987.dp.appsmith.com/app/promo-2feb-2/page1-65bc822036e8962e466b0bb6?branch=main

Fixed via the PR - https://github.com/appsmithorg/appsmith/pull/36354


Update variables.tf to fit the description

the version-variable should be set to optional according the docs and the terraform-resource configuration
Description
According to the official documentation (link), the version parameter should be optional.
The documentation of this module already has the right description of the field.
Type of Change

[ ] Non-module change (e.g. CI/CD, documentation, etc.)
[ ] Azure Verified Module updates:

[x] Bugfix containing backwards compatible bug fixes

[ ] Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
[ ] The bug was found by the module author, and no one has opened an issue to report it yet.

[ ] Feature update backwards compatible feature updates.
[ ] Breaking changes.
[ ] Update to documentation

Checklist

[x] I'm sure there are no other open Pull Requests for the same update/change
[x] My corresponding pipelines / checks run clean and green without any errors or warnings
[x] I did run all  pre-commit checks

@matthiasritter Thanks for opening this pr to us, I'm closing this one in favor of #86.


[BUG] Chapter 10: number of output arguments of model.evaluate(...) for multiple outputs

Describe the bug
cell 81 in "10_neural_nets_with_keras.ipynb" brings up an error
To Reproduce
weighted_sum_of_losses, main_loss, aux_loss, main_rmse, aux_rmse = eval_results

And if you got an exception, please copy the full stacktrace here:
ValueError                                Traceback (most recent call last)
Cell In[64], line 2
      1 eval_results = model.evaluate((X_test_wide, X_test_deep), (y_test, y_test))
----> 2 weighted_sum_of_losses, main_loss, aux_loss, main_rmse, aux_rmse = eval_results

ValueError: not enough values to unpack (expected 5, got 3)

Expected behavior
No errormessage
Versions (please complete the following information):

OS: Win 11 Education, Build 10.0.22631
Python: 3.12.2
TensorFlow: 2.16.1

Additional Info
4 cells below, the same error occurs. In addition
model.compile(loss="mse", loss_weights=[0.9, 0.1], optimizer=optimizer,               metrics=["RootMeanSquaredError"])
has to be replaced with
model.compile(loss="mse", loss_weights=[0.9, 0.1], optimizer=optimizer,               metrics=("RootMeanSquaredError", "RootMeanSquaredError"))
Otherwise, the following error message appears
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[74], line 7
      5 model.norm_layer_wide.adapt(X_train_wide)
      6 model.norm_layer_deep.adapt(X_train_deep)
----> 7 history = model.fit(
      8     (X_train_wide, X_train_deep), (y_train, y_train), epochs=10,
      9     validation_data=((X_valid_wide, X_valid_deep), (y_valid, y_valid)))
     10 eval_results = model.evaluate((X_test_wide, X_test_deep), (y_test, y_test))
     11 weighted_sum_of_losses, main_loss, aux_loss, main_rmse, aux_rmse = eval_results

File C:\Programs\WPy64-31220\python-3.12.2.amd64\Lib\site-packages\keras\src\utils\traceback_utils.py:122, in filter_traceback.<locals>.error_handler(*args, **kwargs)
    119     filtered_tb = _process_traceback_frames(e.__traceback__)
    120     # To get the full stack trace, call:
    121     # `keras.config.disable_traceback_filtering()`
--> 122     raise e.with_traceback(filtered_tb) from None
    123 finally:
    124     del filtered_tb

File C:\Programs\WPy64-31220\python-3.12.2.amd64\Lib\site-packages\keras\src\trainers\compile_utils.py:250, in CompileMetrics._build_metrics_set(self, metrics, num_outputs, output_names, y_true, y_pred, argument_name)
    248 if isinstance(metrics, (list, tuple)):
    249     if len(metrics) != len(y_pred):
--> 250         raise ValueError(
    251             "For a model with multiple outputs, "
    252             f"when providing the `{argument_name}` argument as a "
    253             "list, it should have as many entries as the model has "
    254             f"outputs. Received:\n{argument_name}={metrics}\nof "
    255             f"length {len(metrics)} whereas the model has "
    256             f"{len(y_pred)} outputs."
    257         )
    258     for idx, (mls, yt, yp) in enumerate(
    259         zip(metrics, y_true, y_pred)
    260     ):
    261         if not isinstance(mls, list):

ValueError: For a model with multiple outputs, when providing the `metrics` argument as a list, it should have as many entries as the model has outputs. Received:
metrics=['RootMeanSquaredError']
of length 1 whereas the model has 2 outputs.

I found a fix to the error. It is due to the Keras version. Google colab uses Keras version: 3.4.1. After some digging I had 3.6.0 locally. This was causing the bug.
To fix the bug run Keras version: 3.4.1
pip install keras==3.4.1


build(codemirror): use node16 module resolution -- blocked on data-object-grid

Semi-automatic PR to switch to node16 module resolution

Merged with PR #20045


error: umbrella header for module 'PINRemoteImage' does not include header 'PINRemoteImage.common-umbrella.h'

Hello.
I have trouble while build project
error: umbrella header for module 'PINRemoteImage' does not include header 'PINRemoteImage.common-umbrella.h'
PINRemoteImage installed from cocoapods (PINRemoteImage (3.0.1))

Can you upload a sample project?

Can you upload a sample project?

Sorry I could not do that... But I found resolution...

Modern build in Xcode
Remove additional dependency of PINRemoteImage from my Lib and stay PINRemoteImage which in Texture as dependency... (ASDK)

I suppose or we need move to SwiftPM, or wait while CocoaPods fix this problem (I mean build with two dependency)

Glad you got it fixed! I'm going to close this one out.


Set organization title by display_name param

Title is no longer a required param for create and is removed from the update schema. It is set to the display name for the content's language.
listed_at is now serialized
Review checklist

[ ] First, the most important one: is this PR small enough that you can actually review it? Feel free to just reject a branch if the changes are hard to review due to the length of the diff.
[ ] If there are any migrations, will they the previous version of the app work correctly after they've been run (e.g. the don't remove columns still known about by ActiveRecord).
[ ] If anything changed with regards to the public API, are those changes also documented in the apiary.apib file?
[ ] Are all the changes covered by tests? Think about any possible edge cases that might be left untested.

It is updated to be the same as the display name for the primary (or specified) language, so that there is consistency with how projects do the same thing.


Cannot clone local actions with self-signed cert

Description
My app.ini has the following:
[actions]
ENABLED = true
DEFAULT_ACTIONS_URL = self

And my runner's config.yaml has:
runner:
  insecure: true

I have an action hosted on the server, but when I try to run the action with uses: Actions/test-action@main it fails with:
Extracting content to '/var/run/act/'
  ☁  git clone 'https://gitea-domain/Actions/test-action' # ref=main
  cloning https://gitea-domain/Actions/test-action to /root/.cache/act/Actions-test-action@main
Unable to clone https://gitea-domain/Actions/test-action refs/heads/main: Get "https://gitea-domain/Actions/test-action/info/refs?service=git-upload-pack": tls: failed to verify certificate: x509: certificate signed by unknown authority
Get "https://gitea-domain/Actions/test-action/info/refs?service=git-upload-pack": tls: failed to verify certificate: x509: certificate signed by unknown authority

Gitea Version
1.21.3
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
Docker (both gitea and the runner)
Database
None

It's a bug on the act_runner side. The insecure option should work when cloning a repository from the Gitea instance

I've created a pull request to support cloning actions from the Gitea instance when the insecure option is true

Close as it's only act/act_runner related.


AuthZ plugins change headers

Output of docker version:
Client:
 Version:      1.13.0-dev
 API version:  1.25
 Go version:   go1.6.3
 Git commit:   43640a8
 Built:        Mon Aug 22 17:26:03 2016
 OS/Arch:      linux/amd64
 Experimental: true

Server:
 Version:      1.13.0-dev
 API version:  1.25
 Go version:   go1.6.3
 Git commit:   43640a8
 Built:        Mon Aug 22 17:26:03 2016
 OS/Arch:      linux/amd64
 Experimental: true

Output of docker info:
Containers: 28
 Running: 0
 Paused: 0
 Stopped: 28
Images: 88
Server Version: 1.13.0-dev
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: journald
Cgroup Driver: systemd
Plugins:
 Volume: local
 Network: bridge host null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.6.6-300.fc24.x86_64
Operating System: Fedora 24 (Workstation Edition)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 11.44 GiB
Name: localhost.localdomain
ID: 62I5:E7N5:VHP3:HEWA:7I2L:JLUR:JQV7:SDPV:GYHS:LFYI:QBIH:KRRV
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 15
 Goroutines: 25
 System Time: 2016-08-22T17:28:48.882005417+02:00
 EventsListeners: 0
Username: runcom
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 localhost
 <IP_ADDRESS>/16
 <IP_ADDRESS>/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):
physical/cloud
Steps to reproduce the issue:

start the docker daemon with an authorization plugin (e.g. https://github.com/projectatomic/docker-novolume-plugin even if every plugin which just reply with allow will raise the issue) and also have the daemon listen on localhost to be curl'ed
curl -vvv http://localhost:8081/images/json or curl -vvv http://localhost:8081/containers/json

Describe the results you received:
$ curl -vvv http://localhost:8081/images/json
*   Trying ::1...
* connect to ::1 port 8081 failed: Connection refused
*   Trying <IP_ADDRESS>...
* Connected to localhost (<IP_ADDRESS>) port 8081 (#0)
> GET /images/json HTTP/1.1
> Host: localhost:8081
> User-Agent: curl/7.47.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 22 Aug 2016 15:27:56 GMT
< Content-Type: text/plain; charset=utf-8
< Transfer-Encoding: chunked
<
[API output here truncated]

Describe the results you expected:
$ curl -vvv http://localhost:8081/images/json

*   Trying ::1...
* connect to ::1 port 8081 failed: Connection refused
*   Trying <IP_ADDRESS>...
* Connected to localhost (<IP_ADDRESS>) port 8081 (#0)
> GET /images/json HTTP/1.1
> Host: localhost:8081
> User-Agent: curl/7.47.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Server: Docker/1.13.0-dev (linux)
< Date: Mon, 22 Aug 2016 15:27:22 GMT
< Transfer-Encoding: chunked
<
[API output truncated]

Additional information you deem important (e.g. issue happens only occasionally):
You can see from the above that headers changed when using/not using an authz plugin. Specifically for instance the Content-Type header was application/json w/o the plugin enabled (which is correct) while it was text/plain; charset=utf-8 when using the plugin.
/cc @estesp @liron-l

This is happening from docker 1.10.3 when authz plugins were firstly introduced also

@runcom It seems that the issue is because WriteHeader is invoked before the headers have been copied:
https://github.com/docker/docker/blob/v1.12.1/pkg/authorization/response.go#L178-L189
Just created a pull request #25965 to try to fix it. Please let me know if there are any issues.


Cannot get the list of all datasets for a feed in one API call

Describe the bug
Using the v1/gtfs_feeds/{id}/datasets endpoint, we cannot obtain the list of all datasets for a given feed. It's either the latest, or not the latest (depending on the latest parameter). If latest is not specified, it seems to default to false.
Steps/Code to Reproduce
A call to v1/gtfs_feeds/mdb-279/datasets?latest=true returned mdb-279-202403190153
A call to v1/gtfs_feeds/mdb-279/datasets?latest=false returned mdb-279-202402071826.
A call to v1/gtfs_feeds/mdb-279/datasets returned mdb-279-202402071826, i.e. the same as when latest is false.
You can test this with any feed that has more than one dataset
Expected Results
v1/gtfs_feeds/mdb-279/datasets (i.e. latest not specified) should return all the datasets, latest or not.
Actual Results
See above
Screenshots
No response
Files used
No response
Additional notes
No response

I was unable to reproduce this bug with the current state of the API. Here are the details of my findings using the dev API:
According to the Open API specification, the latest parameter is defined as:

Boolean - If true, only return the latest dataset.

From my understanding, this means that if latest is false, all datasets should be returned.
Test Cases:

Running without the latest parameter specified:
According to the specification, this should default to false, i.e., display all datasets, which seems to be the case.

Query:
curl --location 'https://api-dev.mobilitydatabase.org/v1/gtfs_feeds/mdb-279/datasets' --header 'Accept: application/json' --header 'Authorization: Bearer [Token]'

Response:
Both mdb-279-202407021354 and mdb-279-202406182025 are returned.
See full response
 [
  {
    "id": "mdb-279-202406182025",
    "feed_id": "mdb-279",
    "hosted_url": "https://dev-files.mobilitydatabase.org/mdb-279/mdb-279-202406182025/mdb-279-202406182025.zip",
    "note": null,
    "downloaded_at": "2024-06-18T20:00:26.234781+00:00",
    "hash": "25f1f4d2d2a5b0af81f0d6fd805d2161d9480e0a38e816887d35fe1d1593183a",
    "bounding_box": {
      "minimum_latitude": 47.623688,
      "maximum_latitude": 48.370108,
      "minimum_longitude": -124.636859,
      "maximum_longitude": -122.511536
    },
    "validation_report": {
      "validated_at": "2024-06-27T13:13:08+00:00",
      "features": [
        "Transfers",
        "Fares V1",
        "Shapes",
        "Feed Information",
        "Route Colors",
        "Headsigns",
        "Wheelchair Accessibility",
        "Bikes Allowance",
        "Continuous Stops"
      ],
      "validator_version": "5.0.2-SNAPSHOT",
      "total_error": 0,
      "total_warning": 20,
      "total_info": 0,
      "unique_error_count": 0,
      "unique_warning_count": 1,
      "unique_info_count": 0,
      "url_json": "https://dev-files.mobilitydatabase.org/mdb-279/mdb-279-202406182025/report_5.0.2-SNAPSHOT.json",
      "url_html": "https://dev-files.mobilitydatabase.org/mdb-279/mdb-279-202406182025/report_5.0.2-SNAPSHOT.html"
    }
  },
  {
    "id": "mdb-279-202407021354",
    "feed_id": "mdb-279",
    "hosted_url": "https://dev-files.mobilitydatabase.org/mdb-279/mdb-279-202407021354/mdb-279-202407021354.zip",
    "note": null,
    "downloaded_at": "2024-07-02T13:40:55.660800+00:00",
    "hash": "954bbf7239c7968054e07bb3a77cc7ea32111ee044960a4a49f7813046cb1162",
    "bounding_box": {
      "minimum_latitude": 47.623688,
      "maximum_latitude": 48.370108,
      "minimum_longitude": -124.636859,
      "maximum_longitude": -122.511536
    },
    "validation_report": {
      "validated_at": "2024-07-02T13:41:55+00:00",
      "features": [
        "Transfers",
        "Fares V1",
        "Shapes",
        "Feed Information",
        "Route Colors",
        "Headsigns",
        "Wheelchair Accessibility",
        "Bikes Allowance",
        "Continuous Stops"
      ],
      "validator_version": "5.0.2-SNAPSHOT",
      "total_error": 0,
      "total_warning": 20,
      "total_info": 0,
      "unique_error_count": 0,
      "unique_warning_count": 1,
      "unique_info_count": 0,
      "url_json": "https://dev-files.mobilitydatabase.org/mdb-279/mdb-279-202407021354/report_5.0.2-SNAPSHOT.json",
      "url_html": "https://dev-files.mobilitydatabase.org/mdb-279/mdb-279-202407021354/report_5.0.2-SNAPSHOT.html"
    }
  }
]

Running with ?latest=false:
Returns the same result as without the latest parameter.

Query:
curl --location 'https://api-dev.mobilitydatabase.org/v1/gtfs_feeds/mdb-279/datasets?latest=false' --header 'Accept: application/json' --header 'Authorization: Bearer [Token]'

Response:
Both mdb-279-202407021354 and mdb-279-202406182025 are returned.
See full response
 [
  {
    "id": "mdb-279-202406182025",
    "feed_id": "mdb-279",
    "hosted_url": "https://dev-files.mobilitydatabase.org/mdb-279/mdb-279-202406182025/mdb-279-202406182025.zip",
    "note": null,
    "downloaded_at": "2024-06-18T20:00:26.234781+00:00",
    "hash": "25f1f4d2d2a5b0af81f0d6fd805d2161d9480e0a38e816887d35fe1d1593183a",
    "bounding_box": {
      "minimum_latitude": 47.623688,
      "maximum_latitude": 48.370108,
      "minimum_longitude": -124.636859,
      "maximum_longitude": -122.511536
    },
    "validation_report": {
      "validated_at": "2024-06-27T13:13:08+00:00",
      "features": [
        "Transfers",
        "Fares V1",
        "Shapes",
        "Feed Information",
        "Route Colors",
        "Headsigns",
        "Wheelchair Accessibility",
        "Bikes Allowance",
        "Continuous Stops"
      ],
      "validator_version": "5.0.2-SNAPSHOT",
      "total_error": 0,
      "total_warning": 20,
      "total_info": 0,
      "unique_error_count": 0,
      "unique_warning_count": 1,
      "unique_info_count": 0,
      "url_json": "https://dev-files.mobilitydatabase.org/mdb-279/mdb-279-202406182025/report_5.0.2-SNAPSHOT.json",
      "url_html": "https://dev-files.mobilitydatabase.org/mdb-279/mdb-279-202406182025/report_5.0.2-SNAPSHOT.html"
    }
  },
  {
    "id": "mdb-279-202407021354",
    "feed_id": "mdb-279",
    "hosted_url": "https://dev-files.mobilitydatabase.org/mdb-279/mdb-279-202407021354/mdb-279-202407021354.zip",
    "note": null,
    "downloaded_at": "2024-07-02T13:40:55.660800+00:00",
    "hash": "954bbf7239c7968054e07bb3a77cc7ea32111ee044960a4a49f7813046cb1162",
    "bounding_box": {
      "minimum_latitude": 47.623688,
      "maximum_latitude": 48.370108,
      "minimum_longitude": -124.636859,
      "maximum_longitude": -122.511536
    },
    "validation_report": {
      "validated_at": "2024-07-02T13:41:55+00:00",
      "features": [
        "Transfers",
        "Fares V1",
        "Shapes",
        "Feed Information",
        "Route Colors",
        "Headsigns",
        "Wheelchair Accessibility",
        "Bikes Allowance",
        "Continuous Stops"
      ],
      "validator_version": "5.0.2-SNAPSHOT",
      "total_error": 0,
      "total_warning": 20,
      "total_info": 0,
      "unique_error_count": 0,
      "unique_warning_count": 1,
      "unique_info_count": 0,
      "url_json": "https://dev-files.mobilitydatabase.org/mdb-279/mdb-279-202407021354/report_5.0.2-SNAPSHOT.json",
      "url_html": "https://dev-files.mobilitydatabase.org/mdb-279/mdb-279-202407021354/report_5.0.2-SNAPSHOT.html"
    }
  }
]

Running with ?latest=true:
Returns only the latest dataset.

Query:
curl --location 'https://api-dev.mobilitydatabase.org/v1/gtfs_feeds/mdb-279/datasets?latest=true' --header 'Accept: application/json' --header 'Authorization: Bearer [Token]'

Response:
Only mdb-279-202407021354 is returned, which is the latest dataset.
See full response
[
  {
    "id": "mdb-279-202407021354",
    "feed_id": "mdb-279",
    "hosted_url": "https://dev-files.mobilitydatabase.org/mdb-279/mdb-279-202407021354/mdb-279-202407021354.zip",
    "note": null,
    "downloaded_at": "2024-07-02T13:40:55.660800+00:00",
    "hash": "954bbf7239c7968054e07bb3a77cc7ea32111ee044960a4a49f7813046cb1162",
    "bounding_box": {
      "minimum_latitude": 47.623688,
      "maximum_latitude": 48.370108,
      "minimum_longitude": -124.636859,
      "maximum_longitude": -122.511536
    },
    "validation_report": {
      "validated_at": "2024-07-02T13:41:55+00:00",
      "features": [
        "Transfers",
        "Fares V1",
        "Shapes",
        "Feed Information",
        "Route Colors",
        "Headsigns",
        "Wheelchair Accessibility",
        "Bikes Allowance",
        "Continuous Stops"
      ],
      "validator_version": "5.0.2-SNAPSHOT",
      "total_error": 0,
      "total_warning": 20,
      "total_info": 0,
      "unique_error_count": 0,
      "unique_warning_count": 1,
      "unique_info_count": 0,
      "url_json": "https://dev-files.mobilitydatabase.org/mdb-279/mdb-279-202407021354/report_5.0.2-SNAPSHOT.json",
      "url_html": "https://dev-files.mobilitydatabase.org/mdb-279/mdb-279-202407021354/report_5.0.2-SNAPSHOT.html"
    }
  }
]

After testing by pointing the local API to the PROD database, I can confirm that the behavior remains the same. The latest dataset for feed mdb-279, which is mdb-279-202405270023, is returned regardless of whether ?latest=true, ?latest=false, or no latest filtering parameter is specified.

Closing as this bug is irreproducible.


Add missing babel-jest dependency to react-native package

Summary:
While adding D62583337, I noticed that react-native doesn't specify babel-jest as a dependency, despite referencing it in the included jest-preset.js — instead this would need to be installed by the template/project.
If we want to change this in future, we should consider a separate react-native/jest-preset package. However, I strongly believe this is the right location for this dependency: installing react-native = all parts of it work.
(Note that in the React Native monorepo, we are using dependencies for both dev and runtime deps in packages.)
Changelog: [Internal]
Differential Revision: D62583665

The way it typically is handled in a project is that the Babel configuration (and hence babel-jest @babel/core @babel/preset-env specified in https://jestjs.io/docs/getting-started#using-babel) is handled on the user side. It's some ancient times, but I recall this setup was necessary for Jest to resolve Babel tooling properly especially in monorepo setups. Not sure if anything changed here, but I'd like to make sure this change is not breaking for monorepo setups out there, i.e. if they use a different version of babel-jest in their project, as this may effectively lock-in particular Jest version to a particular React Native version.

@thymikee Oh, interesting! That's a bit awkward and undocumented 😐 I wonder to what extent we can rely on monorepo setups being "power users" and, if they need to override any built-in RN dep/devDep, they can do so with "resolutions"/constraints or equivalent.
From our point of view, shipping this with react-native is the correct setup. (Independently, I understand the frustration with the lack of devDependencies as a whole).


Spec reviewer signoff

Part of the stage 2 → 3 requirements is signoff from the official spec reviewers.

[x] @erights
[x] @michaelficarra (https://github.com/tc39/proposal-global/issues/13)
[x] @caridy (https://github.com/tc39/proposal-global/issues/14)

Approved.

LGTM (let's discuss #14 tomorrow)

LGTM.

Thanks, everyone!

This now needs rereview:

[ ] @erights
[ ] @michaelficarra
[ ] @caridy

Plus the additional members that indicated interest:

[ ] @allenwb
[ ] @domenic

LGTM.

👍 from @allenwb and @erights verbally

As Jordan noted, I approve.

LGTM, just one extra space after [[ in 3->2.b step: Let globalObj be ObjectCreate(intrinsics.[[ %ObjectPrototype%]]).

Actually that space isn't in the source, so it must be an ecmarkup bug. Thanks!


Missing bc files for tests

Hello,
Any chance you could commit the bc files used in the tests? E.g. https://github.com/cdisselkoen/llvm-ir-taint/blob/main/tests/call.rs#L11

I'm assuming they're here: https://github.com/PLSysSec/haybale-pitchfork/tree/69a048a66c59118bf88b21008fef2afc40e97263/tests/bcfiles


⚠ Fortnite has degraded performance

In d7a739f, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1695 ms

Resolved: Fortnite performance has improved in 10ceb85.


chore: rename raise a problem to raise a dispute

change copy Raise a problem in exchange widget
change copy Raise a problem in modals

@albertfolch-redeemeum this looks good


Configuration to be able to change use of ports 8500 and 8600

Is your feature request related to a problem? Please describe.
Trying to evaluate OrbStack; and unfortunately there is an embedded Consul running on default ports 8500 and 8600 which interferes with an installation on the system already.
Describe the solution you'd like
Ability to change the ports assigned for embedded Consul in OrbStack.

Is there a way to disable automatic port forwarding for a predefined range of ports?


picom: 9.1 -> 10

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/yshui/picom/releases.
meta.description for picom is: "A fork of XCompMgr, a sample compositing manager for X servers"
meta.homepage for picom is: "https://github.com/yshui/picom"
meta.changelog for picom is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 10 with grep in /nix/store/gxz138mx4ihns3vinfl7nhsvx7p5nag6-picom-10
found 10 in filename of file in /nix/store/gxz138mx4ihns3vinfl7nhsvx7p5nag6-picom-10

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
picom

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/gxz138mx4ihns3vinfl7nhsvx7p5nag6-picom-10 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A picom https://github.com/r-ryantm/nixpkgs/archive/2fcfc5f3c136467d4154399cd7af500e702b5d06.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/gxz138mx4ihns3vinfl7nhsvx7p5nag6-picom-10
ls -la /nix/store/gxz138mx4ihns3vinfl7nhsvx7p5nag6-picom-10/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

picom (compton)

Maintainer pings
cc @ertes @Twey @thiagokokada for testing.

Will need to remove services.picom.experimentalBackends option since the --experimental-backends argument will error out the service after this is merged. But I think the easiest way to do it is to merge this PR and open another one fixing the service.


Ignore ruff/tryceratops rule TRY003

Summary of changes
TRY003 Avoid specifying long messages outside the exception class

Applying this rule would mean creating lots of specialised exception classes. Not sure this would improve readability and maintainability in this context.
Addresses https://github.com/pypa/setuptools/pull/4450#issuecomment-2200583235.
Pull Request Checklist

[ ] Changes have tests
[ ] News fragment added in newsfragments/.
(See documentation for details)

First case of a PR failing because of this: https://github.com/pypa/setuptools/pull/4464
Probably related to https://github.com/businho/pytest-ruff/releases/tag/v0.4.0 being released ~1h ago.
CC @jaraco @abravalheri to try and expedite this quick fix

I did confirm that downgrading to pytest-ruff 0.3.2 suppresses the errors. I don't see anything in the pytest-ruff changelog that indicates that new rules are now enforced. Was it a mistake? Shouldn't we first see if pytest-ruff wants to yank the version? Is this issue going to affect other projects?

I see now there are probably several factors at play. Something about #4450 probably introduced broken config (or maybe there's broken config elsewhere) such that the failures weren't introduced, but now that pytest-ruff 0.4.0 fixes the handling of the brokenness in the config, the ruff checks are now running and failing. Maybe?
In any case, it looks like the issue is likely isolated to setuptools and its custom config so won't affect other projects right away.
Let's bring this fix in.
Since it seems we've already encountered scope creep on the TRY jobs, maybe it makes sense to opt-in to desired rules rather than opt out?

I noticed TRY003 appearing with ruff 0.5. I suspect the underlying version of ruff has been bumped to 0.5. I don't know how the version of ruff is chosen by pytest-ruff.

Independent of pytest-ruff, TRY003 is a code that is raised locall , as it should given current configs (that's how I noticed it, and should've been excluded in #4450).
Why it didn't raise on the CI previously is still an open question.

I noticed TRY003 appearing with ruff 0.5. I suspect the underlying version of ruff has been bumped to 0.5. I don't know how the version of ruff is chosen by pytest-ruff.

This here PR used pytest-ruff==0.3.2 and ruff==0.5.0 when last run: https://github.com/pypa/setuptools/actions/runs/9756635721/job/26927344059?pr=4454#step:5:26

My hope is that ruff will stabilise and such issues will get less and less frequent. The downside of opt-in is that the opt-in list might be much larger than the opt-out list, and would need to be updated from time to time to include new rules. Perhaps wait and see how often new rules break havoc?

Btw @jaraco TRY003 isn't new at all, it's been there since https://github.com/astral-sh/ruff/releases/tag/v0.0.236 , and I don't see any mention of it since 0.1 https://github.com/astral-sh/ruff/blob/main/CHANGELOG.md

Indeed. After downgrading to ruff 0.3, I still see TRY003 errors:
$ ruff --version
ruff 0.3.2
$
$ ruff check --extend-select TRY
[...]
Found 72 errors.
$

$ ruff --version
ruff 0.5.1
$
$ ruff check --extend-select TRY
[...]
Found 72 errors.
$

Why I didn't experience TRY003 errors in the CI jobs after #4450 remains a mystery...

Yes, I seem to recall I had run pytest-ruff, not ruff. That's why!


Polymorphism not supported?

Overview
Having two methods with the same name but a different signature results in duplicate names in the generated files
Expected
No errors
Actual
Errors because of duplicate names
Environment

Which library version are you using? 2.3.1
On which devices do you observe the issue? Nexus 4 / 5
Note any other information that might be useful. Android 7

Reproducible steps
Have two functions like this:

@NeedsPermission(Manifest.permission.ACCESS_FINE_LOCATION)
public void showMapFragment() {
Fragment fragment = StoresMapFragment.newInstance();
showFragment(fragment);
}
@NeedsPermission(Manifest.permission.ACCESS_FINE_LOCATION)
public void showMapFragment(String json) {
Fragment fragment = StoresMapFragment.newInstance();
Bundle args = new Bundle();
args.putString("a nice key", json);
fragment.setArguments(args);
showFragment(fragment);
}

And it will generate variables like this (erroring) in the MainActivityPermissionDispatcher:

private static final int REQUEST_SHOWMAPFRAGMENT = 1;
private static final String[] PERMISSION_SHOWMAPFRAGMENT = new String[] {"android.permission.ACCESS_FINE_LOCATION"};
private static final int REQUEST_SHOWMAPFRAGMENT = 2;
private static final String[] PERMISSION_SHOWMAPFRAGMENT = new String[] {"android.permission.ACCESS_FINE_LOCATION"};

Which are the same, and thus error.
A workaround (for now) would be to give the function a different name.

Interesting. Yes, this is not supported.
(By the way, it's method overloading, not polymorphism.)

Not sure how to fix this problem. Maybe change the name of format? PERMISSION_${METHOD_NAME}_${PARAMETER_TYPE}*
WDYT @hotchemi @aurae ?

Including the types of the objects should work. Also method overloading is a type of ad-hoc polymorphism, see https://en.wikipedia.org/wiki/Polymorphism_(computer_science) (although it is not well-defined anywhere and others argue otherwise)

Good to know that!

@lfdversluis Thx for your suggestion.
IMO....PERMISSION_${METHOD_NAME}_${PARAMETER_TYPE}* is fine for defining permission constants, but on the other hand we need to give different names for each methods as well.
Like:
static showMapFragmentStringWithCheck(Activity target) {
}

I'm just a bit anxious about this naming will make a debug or an understanding difficult, and this change would be a breaking change obviously so that we gotta be careful to decide.
What do you think folks?

Appending the parameter list to the generated static constants is OK with me, but I agree that the method signature naming could become a little tedious. If we used the simple class name of each parameter, the problem would simply be elevated one level above, e.g. with the following:
package com.example.pkg1;
public class Model {}

package com.example.pkg2;
public class Model {}

package com.example;

@RuntimePermissions
public class AnActivity extends... {
    @NeedsPermission(...)
    void showMapFragment(com.example.pkg1.Model model) {
    }

    @NeedsPermission(...)
    void showMapFragment(com.example.pkg2.Model model) {
    }
}

package com.example;

final class AnActivityPermissionsDispatcher {
    static void showMapFragmentModelWithCheck(Activity target) {
        // Which one?
    }
}

I know, this is a convoluted example, but something to consider nonetheless. I think I'd prefer an additional compile-time check which prevents method overloading, rather than trying to include the parameters inside generated method names - which would also make refactoring a little more annoying.

I agree with you guys. Changing method name could raise a lot of issues. And in most case, developer doesn't use method overloading. They don't get any benefit of that change.
For instance, In this case, code can be refactored like the following
@NeedsPermission(Manifest.permission.ACCESS_FINE_LOCATION)
private void showMapFragment(Bundle bundle) {
    Fragment fragment = StoresMapFragment.newInstance();
    if (bundle != null) fragment.setArguments(args);
    showFragment(fragment);
}

public void showMapFragment() {
    showMapFragment(null);
}

public void showMapFragment(String json) {
    Bundle args = new Bundle();
    args.putString("a nice key", json);
    showMapFragment(bundle);
}

@shiraji That looks like a reasonable approach. You do add additional functions, but it's not that bad. Looking at @aurae 's argument, I would say this might be the best approach (or if you really do not want additional functions, just name them differently).
Perhaps a few lines about this "issue" in the readme and it's all good and well?

In any case, we should implement that additional compile-time check, so that we help out the user as much as possible if they run into this - I'd rather have the compiler show a focussed error message detailing the issue with how PermissionsDispatcher is set up inside an Activity/Fragment, rather than the generated code itself not compiling and blowing up. It's in line with the existing checks we have in place, and provides a better experience overall.

Thank you guys! Let me close the issue and move on #283 .


Chore: add retry mechanism to fanout request

Summary
Set up retry parameters. By default, retry mechanism is disabled (change to enable by default?), if we enable it, the fanout request will retry once by default after 1 second of backoff time.

Ooh, also, we might want to ignore certain errors we know shouldn't be retryable. Maybe something like:
non_retryable_errors = [400, 401]
if status_code != 200:
   if status_code in non_retryable_codes and retry_attempts > 0:
     retry_attempts -= 1
  else:
    throw the error


fix(generic-sdk): fix Requester type when rawQuery is true

Description
There is a bug in the typescript-generic-sdk plugin when using rawResquest: true. The Requester type is wrong, it should be something like ExecutionResult from graphql.
Related #7688
Type of change

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

How Has This Been Tested?
This has been tested in my own repo and demonstrated in this codesandbox
generated graphql.ts before:
import { DocumentNode } from 'graphql'

// [...]

export type Requester<C = {}> = <R, V>(doc: DocumentNode, vars?: V, options?: C) => Promise<R>
export function getSdk<C>(requester: Requester<C>) {
  return {
    TodoList(
      variables?: TodoListQueryVariables,
      options?: C
    ): Promise<{
      data?: TodoListQuery
      errors?: Array<{ message: string; extensions?: unknown }>
      extensions?: unknown
    }> {
      return requester<TodoListQuery, TodoListQueryVariables>(TodoListDocument, variables, options)
    },
  }
}
export type Sdk = ReturnType<typeof getSdk>

generated graphql.ts after:
import { DocumentNode, ExecutionResult } from 'graphql'

// [...]

export type Requester<C = {}, E = unknown> = <R, V>(
  doc: DocumentNode,
  vars?: V,
  options?: C
) => Promise<ExecutionResult<R, E>>
export function getSdk<C, E>(requester: Requester<C, E>) {
  return {
    TodoList(
      variables?: TodoListQueryVariables,
      options?: C
    ): Promise<ExecutionResult<TodoListQuery, E>> {
      return requester<TodoListQuery, TodoListQueryVariables>(TodoListDocument, variables, options)
    },
  }
}
export type Sdk = ReturnType<typeof getSdk>

Can we get this merged? This seems like a fairly straight-forward fix.


Central System does not send SetChargingProfile OCPP16

I'm trying to set a charging profile on the Charge Point. Every other communication works fine (all notifications, setting configurations, remote start/stop transaction, etc.), but when I try to send a charging profile it just doesn't work.
This is the function that handles this operation:
async def set_charging_profile(self, connector_id, amps, **kwargs):
    print('set_charging_profile')
    print(self.id)
    return await self.call(call.SetChargingProfilePayload(
        connector_id=connector_id,
        cs_charging_profiles=datatypes.ChargingProfile(
            charging_profile_id=random.randint(100, 100000),
            stack_level=100,
            charging_profile_purpose=ChargingProfilePurposeType.tx_profile,
            charging_profile_kind=ChargingProfileKindType.absolute,
            charging_schedule=datatypes.ChargingSchedule(
                charging_rate_unit=ChargingRateUnitType.amps,
                charging_schedule_period=datatypes.ChargingSchedulePeriod(
                    start_period=0,
                    limit=amps,
                )
            ),
        )
    ))

And this is the output in the terminal (I have enabled DEBUG level logging):
set_charging_profile
c0b70af3-f037-409c-bff8-8bbc681af806
DEBUG:websockets.server:% sending keepalive ping
DEBUG:websockets.server:> PING c1 78 a3 9a [binary, 4 bytes]
DEBUG:websockets.server:< PING 28 7b ec 1c [binary, 4 bytes]
DEBUG:websockets.server:> PONG 28 7b ec 1c [binary, 4 bytes]
DEBUG:websockets.server:< PONG c1 78 a3 9a [binary, 4 bytes]

As you can see those two test prints work fine. Everything after that does nothing.
On the Central Point (for the testing purposes) I have this function:
@on(Action.SetChargingProfile)
async def on_set_charge_profile(self, connector_id, cs_charging_profiles, **kwargs):
    print("Set charge profile")
    return call_result.SetChargingProfilePayload(
        status=ChargingProfileStatus.accepted
    )

The terminal instance running the test CP doesn't print anything.

After looking at some other peoples code cs_charging_profiles must be a dict and you can't use datatypes.ChargingProfile.
For people who might come across this same problem the function up there needs to look something like this to work:
async def set_charging_profile(self, connector_id, amps, **kwargs):
    print('set_charging_profile')
    print(self.id)
    return await self.call(call.SetChargingProfilePayload(
        connector_id=connector_id,
        cs_charging_profiles={
            'chargingProfileId': random.randint(100, 100000),
            'stackLevel': 100,
            'chargingProfilePurpose': ChargingProfilePurposeType.tx_profile,
            'chargingProfileKind': ChargingProfileKindType.absolute,
            'chargingSchedule': {
                'chargingRateUnit': ChargingRateUnitType.amps,
                'chargingSchedulePeriod': [{
                    'startPeriod': 0,
                    'limit': amps,
                }]
            }
        }
    ))


[Backport 2.16] Backport clean-up in tests done in #3474

Description
Partial backport of #3474
To ease the partial backport, I have also backported de70b16 and 2dbba99 (adding mbedtls_test_ prefix to hexcmp and associated reformatting).
The backport was almost straightforward. The conflict resolutions were essentially about removing code that is in development but not in 2.16.
Status
READY

CI OK, just current Travis errors.


broken cursor on /cities/:id/hotspots endpoint

following the cursor on https://api.helium.io/v1/cities/bmV3IHlvcmtuZXcgeW9ya3VuaXRlZCBzdGF0ZXM/hotspots (New York) for example results in a "not found" error

I believe this is the issue in the source:
File: /blockchain-http/src/bh_route_cities.erl
Line 20: -define(S_CITY_HOTSPOT_LIST_BEFORE, "hotspor_city_list_before").
The fix is to correct the misspelling of hotspor to hotspot. ;-)
Cheers

I believe this is the issue in the source:
File: /blockchain-http/src/bh_route_cities.erl
Line 20: -define(S_CITY_HOTSPOT_LIST_BEFORE, "hotspor_city_list_before").
The fix is to correct the misspelling of hotspor to hotspot. ;-)

Good typo catch. I don't believe that's he issue since that is only the identifier used in the query cache. Did you confirm that it actually fixes the issue here?

I wish I had the setup to do so. I have not confirmed this would fix the issue. Apologies if this misled. Just wanted to report this observation and coincidence.

Not a coincidence but a sharp eye for spelling mistakes.. May be worth stating it as a separate bug next time or at least not make it sounds like "the fix"

Agree.
Thanks for investigating.


电脑蓝屏终止DWV代码  分析0x133_ISR_nt!KeAccumulateTicks

电脑经常蓝屏且开不了机，重启七八次才有可能正常开机一次，希望有专业人员帮忙解答，非常感谢
021724-12265-01.dmp

This repo is for reporting issues with WinDbg, not to investigate random crashes. Your dump file may have already been sent to Microsoft directly for further investigation.


Add disk cache

hash normalized system and input in key
store on disk
should be consulted when serving web requests

Closed by #56


Contest/ command does not get scraped

Bot is online, but there is not content getting recognised by Bot

Have you tried using some commands like $help?
What's the response from the bot?

Hey, I found the issue.
You maybe want to add this to your setup Guide:

You need to enable "MESSAGE CONTENT INTENT" on the Discord Bot SETUP Page.

Great work guys!
PS: Maybe you wanna add product Page Links for each Resell Site for each shoe on the embeded Webhook :)

Hey, I found the issue.
You maybe want to add this to your setup Guide:

You need to enable "MESSAGE CONTENT INTENT" on the Discord Bot SETUP Page.

Great work guys!
PS: Maybe you wanna add product Page Links for each Resell Site for each shoe on the embeded Webhook :)

I'll fix it right away, thanks for your contribution.
I really appreciate that.

Updated doc with Message Content Intent
Thanks @Takshoe


AgGrid doesn't work with persistence props

Description
Not sure if this has been discussed before, but the persistence props do not work with the AgGrid in Vizro, while they work fine in a pure dash app.
Expected behavior
I would expect the persistence props to work as expected, but currently they do not seem to have an effect e.g. when configuring the persistence props, the inserted values still get lost after refreshing the page.
On another note, I think they should also be turned on as default for the dash_ag_grid function (similar how we turn it on automatically for the other components).
Which package?
vizro
Package version
0.1.14
Python version
3.9
OS

How to Reproduce

Run the code below with the latest vizro version
Insert a value inside the floatingFilter
Refresh the page

"""Example to show dashboard configuration."""

import vizro.models as vm
import vizro.plotly.express as px
from vizro import Vizro
from vizro.tables import dash_ag_grid

df = px.data.gapminder()

page = vm.Page(
    title="Enhanced AG Grid",
    components=[
        vm.AgGrid(
            title="Dash AG Grid",
            figure=dash_ag_grid(
                data_frame=df,
                columnDefs=[
                    {"field": "country", "floatingFilter": True, "suppressMenu": True},
                    {"field": "continent", "floatingFilter": True, "suppressMenu": True},
                    {"field": "year"},
                    {"field": "lifeExp", "cellDataType": "numeric"},
                    {"field": "pop", "cellDataType": "numeric"},
                    {"field": "gdpPercap", "cellDataType": "euro"},
                ],
                persistence=True,
                persisted_props=["filterModel"]
            ),
        ),
    ],
    controls=[vm.Filter(column="continent")],
)
dashboard = vm.Dashboard(pages=[page])

if __name__ == "__main__":
    Vizro().build(dashboard).run()

Output
No response
Code of Conduct

[X] I agree to follow the Code of Conduct.

This is part of the backlog, but not prioritised for this sprint: https://github.com/McK-Internal/vizro-internal/issues/660

I would leave this issue open so it's visible to OS users, as I am sure some will face the same issues especially if they use options such as the floatingFilter etc.

Can we close this now? @petar-qb

Yes, we can close it since this bug is fixed with https://github.com/mckinsey/vizro/pull/644.


Dataloader

您好，就是有个代码书写方面的问题想请教你们一下，Dataloader里面现在是每次随机抽取一个batch数据进行训练，如果我想要指定每个batch里面图片的id来进行训练，这种代码怎么来写？ 谢谢~

You may need to implement a BatchSampler.

@RangiLyu Hi I find a small typo in your Readme.md, where the swin is published in ICCV-21 instead of CVPR-21. It's a minor issue so I just inform you here without creating an issue.

@RangiLyu Hi I find a small typo in your Readme.md, where the swin is published in ICCV-21 instead of CVPR-21. It's a minor issue so I just inform you here without creating an issue.

Thanks! Welcome to create a PR to fix it.


config-daemon: Restart all instances of device-plugin

When the operator changes the device-plugin Spec (e.g. .Spec.NodeSelector), it may happen that there are two device plugin pods for a given node, one that is terminating, the other that is initializing.
If the config-daemon executes restartDevicePluginPod() at the same time, it may kill the terminating pod, while the initializing one will run with the old dp configuration. This may cause one or more resources to not being advertised, until a manual device plugin restart occurs.
Make the config-daemon restart all the device-plugin instances it founds for its own node.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>9
Details

11 of 25 (44.0%)  changed or added relevant lines in 1 file are covered.
12 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.02%) to 45.132%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/daemon/daemon.go
11
25
44.0%

Files with Coverage Reduction
New Missed Lines
%

pkg/daemon/daemon.go
1
44.5%

controllers/generic_network_controller.go
5
74.38%

controllers/sriovnetworkpoolconfig_controller.go
6
63.7%

Totals

Change from base Build<PHONE_NUMBER>2:
-0.02%

Covered Lines:
6657

Relevant Lines:
14750

💛  - Coveralls

Failing test
Summarizing 1 Failure:
  [FAIL] [sriov] Metrics Exporter When Prometheus operator is available [It] Metrics should have the correct labels
  /root/opr-ocp2-1/data/sriov-network-operator/sriov-network-operator/test/conformance/tests/test_exporter_metrics.go:162

is addressed in

https://github.com/k8snetworkplumbingwg/sriov-network-operator/pull/785


Migrating to scalapb 0.6.6 and sbt-protoc 0.99.12

I went a little bit further then just that, and also refactored the plugin to use the new AutoPlugin architecture, and sbt-scripted for plugin testing.
Since there are some major changes, I'd love if others would like to test and review this extensively.
The README has been updated with build/test/usage details.  It's much easier now.
I've disabled all the publish settings, since I don't have ability to test; you'll have to handle that part.

Thanks for working on this. Few initial comments:

The code generator should remain a library rather than an sbt plugin. The reason is that keeping it as a library allows people who don't use SBT to use it. The SBT tests you added are very useful though - thanks for adding them!
No need to comment out the release code.

how about converting it to a library, a library-codegen, and a plugin?  When using from SBT, having it as a plugin is immensely useful, and avoids common issues with configuring it for use.  Having the codegen library would still allow easy use outside sbt.  scalapb is itself more complicated to use than it needs to be - I'd be happy to do the same thing there (make it so it is usable with just an addSbtPlugin line, in addition to as a library)

I needed to comment it out for my own testing, I can fix that.

Many users are customizing the way the generator works by passing various
options to scalapb.gen, or modifying the directory where files are
generated. The current plug-in implementation won't let them to do so.
Making the plug-in mirror all scalapb options would just be duplicating
functionality. Can you explain why the plug-in is immensely useful? It only
adds 3 lines of hardcoded settings.
On Fri, Oct 20, 2017 at 8:49 PM Loki Coyote<EMAIL_ADDRESS>wrote:

how about converting it to a library, a library-codegen, and a plugin?
When using from SBT, having it as a plugin is immensely useful, and
avoids common issues with configuring it for use. Having the codegen
library would still allow easy use outside sbt. scalapb is itself more
complicated to use than it needs to be - I'd be happy to do the same thing
there (make it so it is usable with just an addSbtPlugin line, in addition
to as a library)
2.
I needed to comment it out for my own testing, I can fix that.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/scalapb/sparksql-scalapb/pull/6#issuecomment-338361509,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASwrZFfy9sCMLl5wJkdVHRY6Qof9QVdks5suWnfgaJpZM4QAQfR
.

--
-Nadav

The plugin adds the requires library dependencies and other required plugins (sbt-scalac) at the correct versions required for compatibility.  I find this useful to get someone started; often times, the docs are quite out of data.
It also adds default settings.  These settings can be overridden in the project configuration, just as if it didn't set them at all.  For any expert user, who needs to make customizations, this still lets them.

Side note, I almost have a SparkSQL Datasource codegen complete for this as well.  Will allow spark.read.format("com.example.proto.demo.Person").load("filename") for standard delimited protobuf data files.

As a maintainer of this project, I'd strongly prefer consistency in how
generators are published and configured. Allowing Sbt plugins for each
generator to override users' PB.targets is a recipe for confusion if there
was more than one Sbt plug-in that did so. Happy to accept the rest of the
updates in this PR.
On Sat, Oct 21, 2017 at 12:23 AM Loki Coyote<EMAIL_ADDRESS>wrote:

The plugin adds the requires library dependencies and other required
plugins (sbt-scalac) at the correct versions required for compatibility. I
find this useful to get someone started; often times, the docs are quite
out of data.
It also adds default settings. These settings can be overridden in the
project configuration, just as if it didn't set them at all. For any expert
user, who needs to make customizations, this still lets them.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/scalapb/sparksql-scalapb/pull/6#issuecomment-338370937,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASwrVR4gTH6F72lVxuwCFW5lBNdef1wks5suZwDgaJpZM4QAQfR
.

--
-Nadav

Hmm.  Good point; how about each sbt-plugin adds to the list by default?  I think I could make so that if the user explicitly set the list of generators, that would take precedence; but if there were no explicit definitions, it would add them.

especially if you add multiple code generators, I'm trying to avoid having to customize your list.  This is essentially what plugins like release/publish ones do; default a list of steps, but let you override it.

I think it's not worth it. The logic would need to deal with deduping
generators, and we will need each Sbt plug-in to do it in a consistent way.
I dont think this is solving a real pain point for novice users, and it has
the potential to complicate configuration for them down the road. Let's
pass on the Sbt plug-in for now.
On Sat, Oct 21, 2017 at 12:48 AM Loki Coyote<EMAIL_ADDRESS>wrote:

Hmm. Good point; how about each sbt-plugin adds to the list by default?
I think I could make so that if the user explicitly set the list of
generators, that would take precedence; but if there were no explicit
definitions, it would add them.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/scalapb/sparksql-scalapb/pull/6#issuecomment-338373134,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASwre0V-SldH2zFnQeEt26gXZ7xgSXjks5suaHrgaJpZM4QAQfR
.

--
-Nadav

I have removed the sbt plugin features, and added the ability to read/write from delimited protobuf files (as generated by the java and python libraries) to/from spark sql dataframes.
I have left alone the Protobuf/Parquet code.
I have upgraded the sparksql version number to 2.2.  Unfortunately, there were breaking interface changes between spark sql 2.1 and 2.2 in the OutputWriter interface, so this breaks compatibility with pre-2.2 spark sql.

side note, if we DO want to support all 2.x spark versions, @cloud-fan has suggested a method that the spark-avvo project is using: https://github.com/apache/spark/pull/16479#issuecomment-339792885

Sorry that this has been standing open for so long. It looks however there is no demand for this functionality so I am considering to close this PR. In the latest version of sparksql-scalapb it is easy to convert a proto RDD to dataframe and use that representation to save to parquet - so I wonder if this is still needed.

Looks like this is no longer relevant. Please file a new issue if there's anything that is still missing.


Fix for bug #5007

moved definition of Size_MatDepth_t and Size_MatDepth from ts_perf.hpp to perf_channels.cpp. This way they are closer to where they are needed and live in a different namespace (possibly the reason why the fix works).

:+1:


Adopt a Code of Conduct

It's recommended to use a code of conduct, New World Code is an excellent choice for fostering inclusiveness!

Have had one for years:
https://github.com/tailwindcss/tailwindcss/blob/master/.github/CODE_OF_CONDUCT.md


Should PCC be a CSR in Zcheri-legacy?

https://github.com/riscv/riscv-cheri/pull/113 Removed the PCC CSR register. This was previously used to implement converting pointers to capabilities where it's bounds are derived from the pcc. If modesw is availble you can read the pcc using auipc. Would it be better to keep the PCC CSR register for this purpose?

Hmm, agreed, this sounds like a problem: the current spec prevents a legacy-mode process from getting anything PCC-relative without Zcheri_mode. This was mentioned in https://github.com/riscv/riscv-cheri/issues/90: we no longer need the PCC CSR to facilitate a mode switch, but I guess we didn't consider that a legacy process would want access to PCC-relative data.
I suppose we should consider whether there's actually a use-case for this? If the region used isn't also covered by DDC then the process has no hope of actually dereferencing the derived capability, but could still hand it out to other cap-mode processes to use. Sounds a bit odd, but I wouldn't want to say for sure that it's useless/useful.

There is currently a proposal to merge Zcheri_legacy and Zcheri_mode into a single extension, so the modesw would always be available and the problem described here would be resolved. Lets keep this ticket open until #161 is merged.

#161 is due to get merged soon, so this is resolved.


Remove staging repo from podfiles.

This PR should be merged into its base branch when the iOS release occurs.


Version 2.0.12

Landed in https://github.com/metarhia/impress/commit/822f1329ceabbf2f390ab99aeaec8a0dda9e2a2a


Typo in section 5.3.4: "administrative data section" > "administrative metadata section"

Addressed in #379