Queries with TRE features

Hi Team,
We are working on a solution which utilizes Azure TRE as backend.
Can you please guide us on below scenarios.

We want to bundle resources into Catalogues. (Example: App Service, App Insights, SQL Server etc. as Catalogue 1. There can be other set of resources in Catalogue 2).
We then want to assign these Catalogues to different Workspaces so that workspace users can only create resources from the Catalogue which is assigned to their workspace. They should not have access to resources/Catalogues which are not provisioned for their workspace.
Can we add multiple independent resources into a Template so that it becomes a Catalogue? Example: Can we create ARM template which has all required resources like App Service, SQL Server, Key Vault, etc in a single template. Once this template is provisioned for a workspace, can user create any resources from the template?
Is it mandatory to create Workspace Service to provision User resources? Can we have any default/placeholder Workspace service and configure all Azure resources as user resources in that Workspace service?

Thanks in advance!

At present there is only a single "catalogue" of workspaces, a single "catalogue" of workspace services, and each workspace service has its "catalogue" of user resources. The different ways I can see giving the functionality you desire are:

We introduce a concept of catalogues into the TRE. This has been discussed previously, but would require significant development effort.
Likely the easiest "PoC" solution would be to treat a workspace service as a catalogue which I think is what you are suggesting in your final bullet.

Can we add multiple independent resources into a Template so that it becomes a Catalogue? Example: Can we create ARM template which has all required resources like App Service, SQL Server, Key Vault, etc in a single template. Once this template is provisioned for a workspace, can user create any resources from the template?

If look at this example - https://microsoft.github.io/AzureTRE/v0.9.0/tre-templates/workspace-services/health_services/#azure-healthcare-workspace I think you can see something similar happening? The deployment check boxes become variables in terraform which define whether to deploy the item or not. I'd recommend terraform over ARM templates/bicep as deletion of resources is supported and can also use the Azure AD provider to assign Azure roles to users. For example to enable a user to access Azure ML.
Hope that helps.


Color issue with generating in 24dp and 48dp

Some icons with dimen 24dp and 48dp have an issue. The image is total filled with color in resolutions bigger than hdpi.
I didn't try with all icons. But the icon wich I need have the problem: ic_add with white color, but the same problem occurs with any color. See images attached.

It something wrong to me also.

Same here, trying to add av/ic_playlist_add (18dp), running Android Studio on Ubuntu. Can also confirm ic_add is not working for high resolutions at 18dp.

Same happens to me, running Android Studio on OS X.

same here

Same thing with ic_add.

@dsdebastiani @shimika @ferbeb @igorsousa-b  @ShkurtiA
hi，guys
i fixed it on my fork，and something differently also.hope it helps.

+1


Multitemplate Angular, only default template is displayed

Which platform(s) does your issue occur on?
Tryed on Android but probably affects both
Please, provide the following version numbers that your issue occurs with:

CLI: 3.4.1
Cross-platform modules: 3.4.0
Runtime(s): 3.4.1
Plugin(s): nativescript-pager 7.0.12,

Please, tell us how to recreate the issue in as much detail as possible.
Hello @triniwiz,
When I try to create a multitemplate pager in a angular app on android platform, templates are ignored and just the first one is picked up.
I debugged a little bit your plugin and I noted that pagerTemplateKey are correctly parsed and registerTemplate method is called. The problem is that registerTemplate fills _templateMap variable but internally pager uses itemTemplates property to look for registered templates which is filled by setItemTemplates. But the latest is never called when a new template is registered.
I added a call to setItemTemplates at the end of registerTemplate and things seem to work again, but I'm not sure it is the right solution, maybe you can tell me something better.
Here is what i changed:
https://github.com/farzeni/nativescript-pager/commit/fd3b5251ddbecdf4f70590c8d81102d35b31a8a0
Thank you for your work

Good catch 😄


Test Requires Import in order to Run

Test Requires Import in order to Run
Summary:
import is needed in order to have the fixture injected.  Added notes to the common file.
JIRA issues:  MARATHON-7892

I might be wrong, but it is possible that #5702 is doing the same thing?

Thanks @unterstein !!   That PR from @wavesoft doesn't work (at least with my testing).  this approach works.


MetaGeneratorMiddleware #371

Add a middleware in Orchard.Commons to insert automatically a  thanks to ResourceManager.

Can you check the lifetime of the middleware, i.e. how many times is it instantiated, once per request?

Yes, once per request, even for .css and .js files, which is bad.
How can I filter for only the needed requests ?

If the middleware is registered after the static file middlewares then it won't be called. Or right before the Route one.
I wonder what drives the lifetime of the middlewares. For instance in the tenant pipeline I know I cache them, but I don't know how it's handled for the other ones, I would have expected them to be singletons too.

As per my comment on the issue, use a filter so we are sure it's only done for a view. Still in the Commons module.


dotnet publish -c release, Memory too high

dotnet publish  Memory too high, up to 100%,How can I analyze what causes.

dotnet itself requires a high memory due to the graphics

This repo is no longer actively monitored. Closing up old issues that have not had activity in while. If this is still an issue, please open a new issue in an appropriate repo listed in microsoft/dotnet#1275

This repo is no longer actively monitored. Closing up old issues that have not had activity in while. If this is still an issue, please open a new issue in an appropriate repo listed in microsoft/dotnet#1275


Not supported by Apple Appstore anymore

Summary
I love this library, I've used in many apps that I've released, but for the first time I got a problem with Apple developers.
When I submit my new app I got this:

Please correct the following issues and upload a new binary to App Store Connect.
ITMS-90809: Deprecated API Usage - New apps that use UIWebView are no longer accepted. Instead, use WKWebView for improved security and reliability. Learn more (https://developer.apple.com/documentation/uikit/uiwebview).

I didn't know that I was using UIWebview, so I did:
grep -r "UIWebView" node_modules/
And got:

node_modules//react-native-device-info/ios/RNDeviceInfo/RNDeviceInfo.m:    UIWebView* webView = [[UIWebView alloc] initWithFrame:CGRectZero];

So it seems that is react-native-device-info who is using it. And for what I'm reading now it should be using WKWebView.
Is there any way to solve this? I tried by editing the RNDeviceInfo.m file but it didn't work.
Thank you
Current behavior

It's being rejected by Apple
Expected behavior
It should be accepted

https://github.com/search?q=repo%3Areact-native-device-info%2Freact-native-device-info UIWebView&type=code
what version are you using ?
It doesn't exist in the code

(used to tho)

Oh thank now I updated the library and it's working again. But I let you know that using "react-native-device-info": "^14.0.0"
I was getting the same error:

[TypeError: _nativeInterface.default.getUniqueId is not a function (it is undefined)]

But then I installed the version 9 and it's working perfectly :).
Thanks again

Little of that makes sense as something to do on purpose - using old APIs on new versions of the module, or just continuing to use old versions instead of updating, but sounds like there's no actual module problem here.


Different maxBoundsViscosity for x and y axes

Would a PR for two additional map options maxBoundsViscosityX and maxBoundsViscosityY that both default to maxBoundsViscosity, if not explicitly set, be accepted?
If x and y are frowned upon, we could also go with maxBoundsViscosityLng and maxBoundsViscosityLat.
In our case, we want to restrict panning to one axis only, but keep the bounciness when reaching the end. Currently this is not possible without also allowing a bit of viscous panning on the other axis.

I'm not convinced. If you need to restrict panning in one axis only, then set maxBounds to [[a, -Infinity], [b, Infinity]].
Is there a use case I'm missing?

I think I wasn't making myself clear enough. Sorry.
I'll try to explain it with this graphic.

The map element / viewport has the size of the fully opaque area. The map itself (or to be more precise, the maxBounds) has the size of the translucent area.
Assuming that the map has the minimal zoom and zooming is disabled, the user can pan on the green axis, but not on the red axis.
If we set maxBoundsViscosity to 1, the panning will abruptly stop, when the end of the map on the left or right side is reached.
If we set it to 0.5 for instance, we would get that nice viscous bounds effect that we want. However, that would also mean that the user can pan the map on the red axis as well, at least a bit.
By allowing separate maxBoundsViscosity values for either axis, we could enable the viscous bounds for one axis, but completely restrict panning on the other axis.

Hhhhhhmmmmm. 🤔
In your use case, what would happen when the map is zoomed, and then the user pans to a corner? Solid bounds on top/bottom, but viscous on left/right?

That's a good question. I would expect the panning on the red axis to stop immediately, but the movement on the green axis to continue for a bit. As if the map was hitting a solid brick wall on the red axis, but was suspended on rubber bands on the green axis
At least that would be the desired behavior. Without digging into the code, I don't know if that's easily achievable. But I'd guess yes.

As with most of these special cases, I'd say a plugin would be the preferred way to cater for special use cases like this. Having said that, I'm not familiar with the code in question, so I don't know if that's feasible.
If not possible to write as a plugin, perhaps we should look into if it would be possible to make the bounds bounce-code more extensible?

https://github.com/Leaflet/Leaflet/blob/d3c7ed13ad7272f41ab1170501357a329a8d2bc9/src/map/handler/Map.Drag.js#L109
https://github.com/Leaflet/Leaflet/blob/d3c7ed13ad7272f41ab1170501357a329a8d2bc9/src/map/handler/Map.Drag.js#L151-L153
https://github.com/Leaflet/Leaflet/blob/d3c7ed13ad7272f41ab1170501357a329a8d2bc9/src/map/handler/Map.Drag.js#L161-L164

Should be quite easy to adapt. I'd be okay with using a plugin for this. But I'm not sure how I would specify a custom DragHandler. :thinking:

The default Map.Drag handler registers itself here:
https://github.com/Leaflet/Leaflet/blob/d3c7ed13ad7272f41ab1170501357a329a8d2bc9/src/map/handler/Map.Drag.js#L231
https://github.com/Leaflet/Leaflet/blob/b997839fe73397330c292dcac1e5a65cb3ea8fdb/src/map/Map.js#L669-L681
I don't see a way to unregister and replace it.

Don't unregister it. Replace the behaviour of L.Map.Drag with L.Map.Drag.include({...});.

Ah I see, so Class.include can overwrite / monkey-patch the class? That's neat. Thanks. :smile:

Yeah, that's buried somewhere in the "extending Leaflet" tutorials 😄
I'll wait for your plugin then 😉


Performance issue with regex into filter function

Hi! i am struggling to find a fast way of searching my db searching with product's title.
Equals & startsWithIgnoreCase are not good solutions for my case.
I tried db.products.filter(row => regex.test(row["title"])).distinct().limit(10).toArray((products) => {, it was very fast for less than 500 items, but with 10000 it delays approx 20''.
Any other solution that dexie can provide to retrieve faster the items, using the title ignoring lowercase, but also searching into the 2nd and rest words of the title?

Actually i found a promising solution in #476. Not sure if this is the optimal way, but any other solution would be appreciated

Actually i can confirm that the solution in #476 works fast enough for a good solution in a db with over 10.000 items. Using multiIndex field like e.g. *barcodes. Closing this. 👍


Wrong suggestion case

a@hot produces a wrong suggestion: a@com
I realized this as I'm using mailcheck on keypress instead of on blur.

Please re-open if this is still an issue!


Use Travis container-based architecture

Coverage remained the same at 83.33% when pulling 7862f0f45aecd486e451c6c03495b58bd2b380bc on sudo-false into 4651361cd58932c395fee96d25cfd247fb261599 on master.


Feat: add store for bridge

Creates the getStoryblokBridge store to allow better DX to listen to live updates with Storyblok.
Stores with auto-subscriptions make it really easy to subscribe to content that changes often. Here's a demo of the starter app with stores!

Hey, Alex! 👋
I think we might be already there. The reason that we have a two-line solution right now is because the initial props, which are fed from the server. Initial data is useful to help prevent CLS, and for SEO. But, we can always set the initialStory to undefined, and wait until that store is populated (like the React SDK):
let story = getStoryblokBridge(myStoryId, undefined);

Note that this won't get you the content on the page initially — and it has to be that way, since server side props have to be serializable.
As for the name, we can certainly rename it to useStoryblok — I'll update the name of the fn to reflect that. @alexjoverm
And yes, this will work with SvelteKit! The current one already does — but the initial story needs to be provided from the server — otherwise, we don't get any of the benefits from SvelteKit (SEO, for example).
The same is true in React/Next.JS. In order to populate the page with HTML before the React DOM takes over, we'd have to supply an initial story just like the Next.JS example.
That is, the example in the example demo has two lines because of the initial data, just like the Next.JS example above — in this case, we're replacing the getStaticProps with the load function (though that's been moved in the latest versions of SvelteKit).
Let me know if this all makes sense... I'd be happy to show a demo!

Update: it's been renamed!

Amazing, thank you @phultquist !
We had some internal discussions on naming things, and finally could agree on the following suggestion: could you please rename "useStoryblok" to "subscribeStoryblokBridge"?
This way, we don't break in consistency with the other frameworks and hopefully it becomes more clear what the function will do. Thanks!

Just a heads up! I cancelled the workflow as it was running for well over 2hrs


MINOR: Add documentation for running integration tests

Which issue does this PR close?

N/A
Rationale for this change

I wanted to run the integration tests locally and it took a little figuring out so I am documenting it so that it is easier for others to use in the future.
What changes are included in this PR?

Documentation
Made Postgres env vars optional for more flexibility with different environments

Are there any user-facing changes?

No

Codecov Report

Merging #2839 (30be839) into master (93d985c) will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2839      +/-   ##
==========================================
- Coverage   85.20%   85.18%   -0.03%
==========================================
  Files         274      275       +1
  Lines       48543    48761     +218
==========================================
+ Hits        41363    41539     +176
- Misses       7180     7222      +42

Impacted Files
Coverage Δ

datafusion/data-access/src/object_store/mod.rs
0.00% <0.00%> (-100.00%)
:arrow_down:

datafusion/data-access/src/object_store/local.rs
78.06% <0.00%> (-10.97%)
:arrow_down:

datafusion/core/src/physical_plan/stream.rs
66.66% <0.00%> (-9.53%)
:arrow_down:

datafusion/core/src/datasource/file_format/avro.rs
61.53% <0.00%> (-8.03%)
:arrow_down:

datafusion/core/src/datasource/file_format/json.rs
93.75% <0.00%> (-5.13%)
:arrow_down:

.../core/src/physical_plan/file_format/file_stream.rs
89.89% <0.00%> (-3.35%)
:arrow_down:

datafusion/core/src/physical_plan/join_utils.rs
93.61% <0.00%> (-3.20%)
:arrow_down:

datafusion/common/src/error.rs
80.00% <0.00%> (-2.28%)
:arrow_down:

...afusion/core/src/physical_plan/file_format/json.rs
91.06% <0.00%> (-2.13%)
:arrow_down:

...tafusion/core/src/physical_plan/file_format/csv.rs
92.22% <0.00%> (-1.56%)
:arrow_down:

... and 50 more

Continue to review full report at Codecov.

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


introduce hypervisor.Process

Signed-off-by: Gao feng<EMAIL_ADDRESS>

there is ContainerDescription in the runv/api/, should this hypervisor.Process be moved to runv/api/ ? CC @gnawux for whom create runv/api/

I'd like to see it in runv/api/

@laijs @gnawux please review

should it be defined in the proto file?


[WIP] Keep PHY calibration data in RTC memory (IDFGH-3790)

In designing an ultra low power sensor node that periodically transmits data to a gateway via ESP-NOW, I found that the active time could be effectively halved by avoiding the need for NVS initialization and/or PHY calibration on wakeup by keeping PHY calibration data in RTC memory. In combination with existing config optimisations, the total time for an ESP-NOW transmission, from deep sleep to deep sleep, can be reduced to as little as 39ms (from 85ms without this change), allowing up to 50% longer battery life (@ 1 Tx/5mins).
ESP-NOW transmission:

Applications targeting very fast WiFi connection times could also see some benefit from this.
For demonstration, I've got one implementation here, where esp_wifi claims a chunk of RTC memory internally, however it is incomplete (eg. no way to access the data to save it manually or via esp_phy_store_cal_data_to_nvs) and I'm open to better ways.

Thanks for your contribution.

@boarchuz would this optimisation also work for wifi STA to AP ?

@AshUK I think so, but it's a lot more complexity for a proportionally much smaller benefit.
As I understand, a lot of the hard work in authenticating with a secured access point is saved to flash upon initial connection, making every subsequent connection much faster by loading it back up rather than doing all that processing from scratch every time. (ie. NVS actually saves a lot of time.)
So if it's an open network, then I don't see any issues; otherwise, it might be possible to initialize WiFi and start connecting, then initialize NVS while still scanning for the access point. Hacky and probably not worth the 30-40ms shaved off, though.

This can already be achieved with the current API by using esp_phy_rf_init before WiFi initialisation.
eg.
static esp_err_t init_phy(esp_phy_calibration_mode_t cal_mode)
{
    static RTC_DATA_ATTR esp_phy_calibration_data_t s_rtc_cal_data;
    const esp_phy_init_data_t* init_data = esp_phy_get_init_data();
    assert(init_data);
    return esp_phy_rf_init(init_data, cal_mode, &s_rtc_cal_data, PHY_WIFI_MODULE);
}

void app_main(void)
{
  if (esp_reset_reason() != ESP_RST_DEEPSLEEP) {
    // Full calibration on reset
    ESP_ERROR_CHECK( init_phy(PHY_RF_CAL_FULL) );
  }
  else
  {
    // No calibration on deep sleep wakeup, just set phy data
    ESP_ERROR_CHECK( init_phy(PHY_RF_CAL_NONE) );
  }
  // WiFi initialisation, ESP NOW initialisation, etc
}

esp_phy_rf_init no longer exists in recent ESP-IDF (v4.3), if somebody winds up here looking for a solution for fast ESP-NOW init after deep sleep I have a working example here:
Calibration on bootup:
https://github.com/FruitieX/esp32-volume-control-sender/blob/22aec694bc168d854eaab43edd34de7ebd4a88f4/main/ulp_adc_example_main.c#L288-L297
Load calibration data from RTC memory after deep sleep wakeup:
https://github.com/FruitieX/esp32-volume-control-sender/blob/22aec694bc168d854eaab43edd34de7ebd4a88f4/main/ulp_adc_example_main.c#L312-L330
You also need to disable CONFIG_ESP32_WIFI_NVS_ENABLED, CONFIG_ESP32_PHY_CALIBRATION_AND_DATA_STORAGE and CONFIG_ESP32_PHY_INIT_DATA_IN_PARTITION in sdkconfig.

Did you manage to fully cache the Wifi STA info into RTC?
I want to fully disable NVS to save energy (its initialization and access take a big chunk of time from the deep-sleep wakeups of my low-power application)
It seems like supplying the bssid and channel to wifi_init_config_t isn't enough. After reading https://github.com/espressif/esp-idf/issues/3784 from @boarchuz, it seems like the missing piece is somehow caching the PMK in RTC and restoring it on every wakeup.
I bet that that information is in the infamous apinfo NVS key, but there doesn't seem to be an API which would allow to store it in RTC memory.

@2opremio
Yes, I went the route of modifying all nvs_* pointers in g_wifi_osi_funcs to custom functions that store and retrieve from RTC memory instead.

Ah, nice! Would you be able to share the code?

Also, it would be awesome if it could be upstreamed!

Sure, you can find the component "bo_wsc" here: https://github.com/boarchuz/bo_wsc
You might run into some minor issues as I only had my own project in mind when writing/using it. In particular, I'm on ESP-IDF 5.1.0 and set CONFIG_BO_WSC_NVS_DISABLED.
You just need to do ESP_ERROR_CHECK(bo_wsc_set(&g_wifi_osi_funcs)); before any WiFi initialisation to replace the default functions, and then later (eg. when returning to sleep) use the bo_wsc_nvs_... functions to commit changes to flash if desired.

@boarchuz wow! such a nice generic solution.
In the meantime I have managed to solve my specific problem in a simpler way. As I expected, the issue was coming from the WPA PMK not being cached. This patch (against idf 5.3) solves it:
diff --git a/components/wpa_supplicant/src/rsn_supp/wpa.c b/components/wpa_supplicant/src/rsn_supp/wpa.c
index 4e4e189363..bb0fc4488c 100644
--- a/components/wpa_supplicant/src/rsn_supp/wpa.c
+++ b/components/wpa_supplicant/src/rsn_supp/wpa.c
@@ -2483,6 +2483,11 @@ wpa_set_passphrase(char * passphrase, u8 *ssid, size_t ssid_len)
         sm->key_mgmt == WPA_KEY_MGMT_DPP)
         return;

+    // PMK-cache in RTC memory (so that it survives deep-sleeps)
+    static RTC_DATA_ATTR u8 cached_ssid[SSID_MAX_LEN] = {0};
+    static RTC_DATA_ATTR size_t cached_ssid_len = 0;
+    static RTC_DATA_ATTR u8 cached_pmk[PMK_LEN] = {0};
+
     /* This is really SLOW, so just re cacl while reset param */
     if (esp_wifi_sta_get_reset_param_internal() != 0) {
         // check it's psk
@@ -2491,8 +2496,13 @@ wpa_set_passphrase(char * passphrase, u8 *ssid, size_t ssid_len)
                            esp_wifi_sta_get_ap_info_prof_pmk_internal(), PMK_LEN) != 0)
                 return;
         } else {
-            pbkdf2_sha1((char *)esp_wifi_sta_get_prof_password_internal(), sta_ssid->ssid, (size_t)sta_ssid->len,
-                        4096, esp_wifi_sta_get_ap_info_prof_pmk_internal(), PMK_LEN);
+            if (cached_ssid_len == ssid_len && memcmp(ssid, cached_ssid, ssid_len) == 0) {
+                // Use RTC-cached pmk
+                memcpy(esp_wifi_sta_get_ap_info_prof_pmk_internal(), cached_pmk, PMK_LEN);
+            } else {
+                pbkdf2_sha1((char *)esp_wifi_sta_get_prof_password_internal(), sta_ssid->ssid, (size_t)sta_ssid->len,
+                            4096, esp_wifi_sta_get_ap_info_prof_pmk_internal(), PMK_LEN);
+            }
         }
         esp_wifi_sta_update_ap_info_internal();
         esp_wifi_sta_set_reset_param_internal(0);
@@ -2503,6 +2513,10 @@ wpa_set_passphrase(char * passphrase, u8 *ssid, size_t ssid_len)
     } else {
         memcpy(sm->pmk, esp_wifi_sta_get_ap_info_prof_pmk_internal(), PMK_LEN);
         sm->pmk_len = PMK_LEN;
+        // Save pmk to cache
+        memcpy(cached_ssid, ssid, ssid_len);
+        cached_ssid_len = ssid_len;
+        memcpy(cached_pmk, sm->pmk, PMK_LEN);
     }
 #ifdef CONFIG_IEEE80211R
     /* Set XXKey to be PSK for FT key derivation */

It sucks that there isn't (or I havent'been able to find) a way to set/cache the PMK through wifi_config_t
I may upstream my change in a PR.
@boarchuz Nonetheless I may still use your solution. However, I am weary of it's RTC memory consumption since it stores all keys (I assume your approach is all-or-nothing, since the driver won't likely accept only certain keys being present)


Failed in firefox (invalid_request)

When I try connect to stackedit from gdrive in firefox I get:

I'm getting this error in all browsers as well when I try to share a file


Update google api dependencies to use canonical path

See https://golang.org/s/go14customimport for an explanation.
Fixes the below warning:
package github.com/google/google-api-go-client/googleapi: code in
directory
$GOROOT/src/github.com/google/google-api-go-client/googleapi
expects import "google.golang.org/api/googleapi"

Hello @pefoley2 where are getting this warning? I've been using go{1.3, 1.4, 1.5} and never had a problem building, unless this just happened in the last 8 hours. Also would you mind opening an issue first? This way we can a discussion about it, as keep records for the next release. Thanks.

Issue 398 created.

Thank you for this patch and for advocating that this gets fixed. LGTM! Merging it in.


chore(main): release 1.11.7

:robot: I have created a release beep boop
1.11.7 (2023-10-31)
Bug Fixes

🐛 macOS x64ArchFiles Errors (151cb29)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/viarotel-org/escrcpy/releases/tag/v1.11.7 :sunflower:


Patient Experience supports removed tests

Related Issue

In the previous deploy for these pxp changes (see #3822), we saw null pointer exceptions when getting results for Covid in a small subset of cases. It turns out that only happened for tests that had been removed, because the Result object didn't point at the new (removed) testEvent in those cases.

Changes Proposed

This change adds back the patient experience changes to support multiplex
It also adds logic for removed events to grab the Result off the priorCorrectedTestEvent if applicable.
Finally, it gracefully handles a 500 on the frontend by telling patients to contact their testing provider.

Additional Information
@zdeveloper I know this is not quite the PR I promised - the underlying fix will be addressed in #3831, to create a second Result for removed TestEvents. But this short-term fix to make sure we have the patient experience squared away before we release multiplex.
Error on a 500 response (triggered manually, I haven't gotten this to trigger with the current code)

Accessing a removed result:

Testing

PXP works as intended

Checklist for Primary Reviewer

[ ] Any large-scale changes have been deployed to test, dev, or pentest and smoke tested
[ ] Any content updates (user-facing error messages, etc) have been approved by content team
[ ] Any changes that might generate questions in the support inbox have been flagged to the support team
[ ] GraphQL schema changes are backward compatible with older version of the front-end
[ ] Changes comply with the SimpleReport Style Guide
[ ] Changes with security implications have been approved by a security engineer (changes to  authentication, encryption, handling of PII, etc.)
[ ] Any dependencies introduced have been vetted and discussed

Closing this PR as we've decided to go in another direction WRT removals.


Winners Section

This is really good just one comment. I feel the position markers (1st,2nd and 3rd) are little dim in contrast with dark background

One more, shouldn't this winner section be the top section? Or atleast main banner should give some focus to the Hack-R-Play results  .

One more, shouldn't this winner section be the top section? Or atleast main banner should give some focus to the Hack-R-Play results .

@koustov
how about we add a "Winners" button to the hero


Discovering Build Task from module, and import them

I really like Invoke-Build and the way you can split tasks in different files, use parameters and the property keyword to propagate them across dot sourced Build tasks files, providing defaults or overriding values.
I think some PS Modules should export tasks generic but relevant to their subject (say PSDepend could expose some tasks like those here), and then a user can import and compose them in a single .build.ps1 file, overriding variables as needed.
This would allow much more re-usability from Build scripts, instead of everyone 'making their own'.
Then it would be good to have Invoke-Build providing some helper functions for discovering those Build tasks/file from other installed modules or from the gallery.
To implement that function, I think Plaster has a very neat way of doing exactly that for PlasterTemplates.
In short, the module needs to 'expose' an extension in its metadata, then the Plaster module can find the extension and list its Templates.
What do you think?
/cc @RamblingCookieMonster

By the way, those who do not want to 'pollute' their module with build tasks can similarly create another module i.e. TheirModuleName.BuildTasks that depends on TheirModuleName and implements the extension as described above.
Might be even better... but raises the same question as Plaster and its templates potentially polluting the PSGallery (see Jaykul's comment)

Thank you for the interesting topic. It is the area for some development and potential improvements. I have been thinking of something similar a few times. I did not find an elegant and universal way of doing this. So far.
I am looking for ideas, suggestions, and especially use cases. I am not keen to rush, though, let's discuss and think.
"Modules" (or other "things") may expose "special" tools in many ways. They do not have to wrap them in tasks. Pre-wrapping may be handy in some cases, yes. But then a user must use Invoke-Build. On the other hand: (a) not task-wrapped tools could be used in more PowerShell scenarios; (b) it is not that difficult for an end user to compose a task that just calls an exposed tool with proper parameters. The latter, in fact, is the primary/typical scenario of Invoke-Build, i.e. tools and complex code are outside, tasks just glue things together and declare dependencies.

@gaelcolas
A side question. In your example I noticed constructs
$Parameter = $(try { property Name} catch { }), #propagate or use $null

Do you think it makes sense to allow the default null value if it is provided as null? The used construct is not neat, e.g. it may generate errors polluting the $Error.

I'm not sure if it's the right place, but if there are a set of more general-purpose tasks that might be worth distributing via the gallery, I'd be happy to include tasks with the BuildHelpers module - the module is already out on the gallery, so wouldn't pollute the gallery in that sense, and the idea for that module was re-usable tools for builds, so it fits the goal, if it makes sense and a sensible implementation could be designed.
As for per-module, very interesting idea - but yeah, not sure what the best vehicle would be if you went that route
Cheers!

re @nightroman: I think the best option could be to allow setting the default to $null such as $parameter = (property propName $null) so that backward compatibility works.
What I did was a quick hack for my PoC while learning the tool.
I haven't looked at the source code yet.
However, the best way to throw if no value is set would be by adding the [Parameter(Mandatory)] attribute to the parameter.
re @nightroman and @RamblingCookieMonster, I think there is value in offering generic and re-usable tasks, along with some modules (BuildHelpers being an obvious one), but many CI/CD related modules would also make sense. It would allow a bit more standardization and community-driven improvement, instead of everyone building things their own way, and would also encourage beginners to start composing simple build 'workflow' with CI/CD by re-using basic tasks, and then extending it with other integration (i.e. uploading test results to AppVeyor).
The build Tasks would only be an 'Extra', and by no mean would replace a module... I truly recognize the benefit of modules, and providing the build tasks would merely provide some bricks and example of composition, that the user is free to compose as they wish in their own build script.
As for the scenarios, I found that most build scripts revolve around similar principles, and many excel in different parts.
Re-using someone else's script is nearly impossible as there's always some specificity not relevant to your case, merging two monoliths while removing some bits is a nightmare as they don't respect the same naming conventions and variable names...
Starting with smaller bricks, doing atomic tasks, and splitting them in separate files (in essence, the PowerShell best practices for modules), would improve readability, re-usability and flexibility.
I found that it seems relevant to group them based on category, and usually the module they leverage. As an example, here are common tasks that would make sense:

PlatyPS: Create the documentation based on .md files
PSScriptAnalyzer: Static code Checking...
BuildHelpers: manage many common tasks
PSSlack: Built-in Notification on Build failure (no more dependent on the CI tool's integration)
AppVeyor/Bamboo/Jenkins: Upload test results
DscBuildHelpers: Similar to BuildHelpers but for DSC...

And so on...
I hope it's clear enough to show you the point, now I'm gonna try to write some of those tasks and compose them to see how it feels.
This is obviously only food for thoughts for the moment, but I'm keen on getting more brain on the matter. I know that some of the trouble we'll get will be with the standards used (build variable Names, environment setup...) but with the help of Plaster and the BuildHelpers, PSdepend, PSDeploy, and other we have an opportunity to build up instead of from scratch every time...

Yeah, probably would be tough to come up with something that everyone would be happy with and that would fit everyone's needs.
That said, I like the idea, and given that we control some of those repos, I'd be happy to help hash out a basic convention and implement it on a few - e.g. PSSlack might be fun.  At the very least, we could illustrate this in a consumable way (friendly blog post) that folks like myself (far from the actual-dev-world) might be more comfortable with.
Roman - we can take discussion elsewhere if you'd rather not have it in this repo : )

Any ideas, suggestions, or new input on this? If this stalls I would rather close (we can open a new issue any time). Invoke-Build supports and encourages imported tasks, this is not a question. As far as I understand, the question is about some conventions on how modules/tools expose their shared tasks, so that Invoke-Build may find them. I do not have ideas or use cases on my own.

Sorry, I was away the last couple of weeks.
I'll close this for now and will re-open when I have a 'demo' of what I have in mind, it's in progress but I'll be away again in 2 weeks so it might stall a bit until I'm back.

All of these are great points, I just wanted to add a few things.

Having to have to dot source the build tasks in the default project build script is cumbersome when sharing build scripts and tasks with others.
Suggest having a folder name and file naming convention that Invoke-Build includes in addition to the default build script when parsing tasks.

Variables are a limiting factor when sharing scripts.
Suggest having a way to declare/describe variables used within a task script. Having a require statement depending on something like BuildHelpers would be a good start. I may be wrong, but having a schema based variable declaration seems to be a better solution because it would allow scripts to know that that their build script that uses variables from "Schema A" to use tasks  from another script that use the same "Schema A"

@gaelcolas @RamblingCookieMonster
A simple and robust but not so obvious technique of exporting and importing module tasks is probably found. See EXAMPLE 2. Import from a module with tasks here:
https://github.com/nightroman/Invoke-Build/tree/master/Tasks/Import

Not a bad idea and it's lightweight. Will give it a go when I get a chance...
Thanks!

ah! I'm confronted again with that good ol' chicken and egg problem....
I like having a single point of entry: Assuming you have Invoke-Build.ps1 in your repo, you only have to call the .build.ps1 and then the Build script should find out what it needs by himself (I use a PSDepend task for this called ResolveDependencies).
The problem with resolving those dependencies within a task, is that all the tasks added to, say, the default task . needs to be pre-defined...
That means I can't have:
Param()
if ((Get-PSCallStack)[1].InvocationInfo.MyCommand.Name -ne 'Invoke-Build.ps1') {
    Invoke-Build
    return
}
task . Clean, ResolveDependencies, LoadDependenciesTasks, SomeTaskFromOneDependency, SomeTaskFromTheOtherDependency
task Clean {<# ... #>}
task ResolveDependencies {<# ... #>}
task LoadDependenciesTasks {<# ... #>}

Because SomeTaskFromOneDependency and SomeTaskFromTheOtherDependency must be defined before running ResolveDependencies...
Any idea how to work around this?
Worst case scenario, I think I can start by bootstrapping PSDepend in my ,build.ps1, resolving the dependencies, before importing the tasks and returning the control to Invoke-Build.

Actually, I'm relatively happy with my bootstrap process in .build.ps1
In short I do (or will do), my .build.ps1 looks like this:
Param()
Process {
    if ((Get-PSCallStack)[1].InvocationInfo.MyCommand.Name -ne 'Invoke-Build.ps1') {
        Write-Verbose "Returning control to Invoke-Build"
        Invoke-Build
        return
    }
    Resolve-Dependency
    Load-TaskFromLoadedModule

}
Begin {
    function Resolve-Dependency { <#...#> }
    function Load-TaskFromLoadedModule {
         (get-modules).exportedAliases.where{key -match '\.tasks$'}.foreach{. $_}
    }

}

(I know I should update the invoke-build return with @nightroman updated example)

I think this approach should work.
A side note (up to you): if you prefer to use blocks Begin and Process, use End instead of Process. Process is designed for processing piped data which we do not have.


[BUG] Quote is not sufficiently long/does not extend

Describe the bug
When taking the timed typing test, the sample text to copy can be completed before the timer runs out. When this happens, no extra text is allotted and the highlight disappears, leaving the visitor to wait until the timer runs out. The words per minute (WPM) displayed once the timer runs out is not representative of the end user's skill because the quote was not sufficient.
To Reproduce
Steps to reproduce the behavior:

Go to the "Practice" section
Click on the easy difficulty and the 5 minute option
Finish typing the sample text
See error

Expected behavior
The expected behavior would be the sample text extending as the user types or the original sample text being too long for any human to reasonably complete.
Screenshots

Desktop (please complete the following information):

OS: Windows 10
Browser: Firefox
Version: 109.0 (64-bit)

Expected Solution
This bug can be solved by generating more sample text or checking for a completed test to create additional text.

Hey @zemetskiym, Thanks for noticing this bug. This is the problem in every case of difficulty.
We need to solve this issue so that it would not affect the user experience.
If you see our code, currently we are generating text from a set of words (incl. nouns, pronouns, verbs, adjectives, prepositions, etc.) and for each difficulty level we are generating only a set of words which we repeated so that the length of the sentence increases but we need a different approach to generate words as per difficulty level, time given and the user's speed.
Are you able to think of any such approach, do let me know. I am also working on it to find a good solution.

Hey @arpitghura, I looked at the code for generating quote length
// making the quote from the words
const makequote = () => {
    // setting up difficulty level
    if (easyLvlBtn.checked) {
        selectedDifficultyLevel = "easy";
        quoteLength = 30
    } else if (interLvlBtn.checked) {
        selectedDifficultyLevel = "medium";
        quoteLength = 50
    } else if (hardLvlBtn.checked) {
        selectedDifficultyLevel = "hard";
        quoteLength = 60
    }
    return makeSentence(selectedDifficultyLevel,quoteLength);
};

Consider the condition when the user selects easy difficulty, then it is likely for the user to type faster thereby typing more words. But if the user goes with a higher difficulty, the words generated is harder and user types slower. So the logic must be inverted in the about snippet.
Also, we have the highest wpm of the user from his history of typing in the user's local storage. We can also use that to generate words per user. Ideally, Words = Highest WPM + 10 Words so the user has a buffer region to break his personal record.

If you agree that this is a feasible solution, assign me this and I will work on it.

Hey @arpitghura, I looked at the code for generating quote length
// making the quote from the words
const makequote = () => {
    // setting up difficulty level
    if (easyLvlBtn.checked) {
        selectedDifficultyLevel = "easy";
        quoteLength = 30
    } else if (interLvlBtn.checked) {
        selectedDifficultyLevel = "medium";
        quoteLength = 50
    } else if (hardLvlBtn.checked) {
        selectedDifficultyLevel = "hard";
        quoteLength = 60
    }
    return makeSentence(selectedDifficultyLevel,quoteLength);
};

Consider the condition when the user selects easy difficulty, then it is likely for the user to type faster since the generated quote is easy thereby typing more words. But if the user goes with a higher difficulty, the quote generated is harder and user types slower. So the logic must be inverted in the about snippet of code.
Also, we have the highest wpm of the user from his history of typing in the user's local storage. We can also use that to generate words per user. Ideally, Words = Highest WPM + 10 Words so the user has a buffer region to break his personal record.

If you agree that this is a feasible solution, assign me this and I will work on it.

That's a great idea. Go ahead and fix this bug. I am assigning this issue to you.

Pull request #113 solved this issue.


Minimal distance depth view

Hi, I'm using gemini e. I need to make a fully sealed housing for this camera, but as soon as I put plexiglass/polycorbanate/acrylic glass on the camera the camera stops working (no depth image). My assumption is that the problem is in the rangefinder, which shows the distance 0. How can I disable this setting? I am using python wrapper.

Some depth cameras rely on infrared structured light to assist in measuring depth, but some plastics or glass do not seem to allow infrared light to pass through well. (Maybe that's why they launched a new product with waterproofing)

Hi, I'm using gemini e. I need to make a fully sealed housing for this camera, but as soon as I put plexiglass/polycorbanate/acrylic glass on the camera the camera stops working (no depth image). My assumption is that the problem is in the rangefinder, which shows the distance 0. How can I disable this setting? I am using python wrapper.

This usage is not recommended. Our device already has a lens, and adding an additional layer of glass for encapsulation will affect the reflection and reception of the laser, thereby impacting the quality of the depth data. The reason you are getting a depth value of 0 could be that the laser protection mechanism has been triggered.
You can invoke this command to disable LDP, but we do not recommend doing so.
from pyorbbecsdk import *
pipeline = Pipeline()
device = pipeline.get_device()
#True：turn on LDP，False：turn off LDP
device.set_bool_property(OBPropertyID.OB_PROP_LDP_BOOL, False)


MongoDB create method should ignore client side provided _id

Regression. Both datasync and generic plugins add _id to create.
This is not only invalid but causes clientSide id to break server:
message: "Variable "$input" got invalid value "storeclient.6f0bee74-25b0-48b4-a471-96bb9e15843a" at "input._id"; Expected type "GraphbackObjectID". Value is not a valid mongodb object id of form: storeclient.6f0bee74-25b0-48b4-a471-96bb9e15843a

Model seems invalid as well:
type Todo {
  _id: GraphbackObjectID!
  title: String
  description: String
  completed: Boolean
  _lastUpdatedAt: GraphbackTimestamp
}

input CreateTodoInput {
  _id: GraphbackObjectID
  title: String
  description: String
  completed: Boolean
}

/cc @craicoverflow, @machi1990
Automatically generated comment to notify maintainers

CC @ssd71

I think it makes sense to ignore surrogate primary keys (id: ID! or _id: GraphbackObjectID in case of MongoDB) since these will be generated.
The challenge is being able to reliably tell the underlying database. Is it MongoDB or a relational database (PostgreSQL) in our case.

We can make a better judgement that no one uses ObjectID as primary key in PostgreSQL as it does not make sense. With this assumption we can safely ignore id: ID! or _id: GraphbackObjectID from the generated input.
Or in the longer term, introduce a means to query graphback core for the registered features (database) e.g when the knex package is loaded it automatically register a knex feature, likewise for the mongodb package a mongodb. Based on this information, plugins can reliably query them and make reasonable assumptions.

I think for me it will be only to not add _id: GraphbackObjectID as by definition we know about scalar type in the schema plugin.

Yes, but we'll want to do it only for MongoDB database.  I am wondering how do we get to do it properly without breaking things for one database (I am thinking of Postgres) as we probably would not want to ignore it.
Also (whatever solution we'll go with), I think it makes sense to do it also for id since it be automatically generated.

Let's leave this then. I think that making quick fixes here might lead to issues.
I see that _id is now ignored (wasn't before) for datasync so all good.

Sure, we can revisit it later.

I would really like to have the ability to skip _id.
Number of the hacks I need to do in the client for this is to big. I will check if I can hack this (detect scalar and not include it for create)

Let's chat about this tommorow.

I would really like to have the ability to skip _id.

This makes sense.

Number of the hacks I need to do in the client for this is to big. I will check if I can hack this (detect scalar and not include it for create)

This is the simplest enough "hack", but I also think the client should not send the "_id" or "id" key during create.

Let's chat about this tommorow.

Sure :-)

This is one month old - should it be left open?

It is huge problem. Just no time to fix it :)


DistanceBand include the point itself as neighbor

The behavior is not the same as the example. The DistanceBand include the point itself as neighbor.
points=[(10, 10), (20, 10), (40, 10), (15, 20), (30, 20), (30, 30)]

w=pysal.DistanceBand(points,threshold=11.2,binary=False)
C:\Miniconda3\lib\site-packages\pysal\weights\Distance.py:499: RuntimeWarning: divide by zero encountered in double_scalars
  weights[i].append(weight**self.alpha)

w.weights
Out[29]:
{0: [0.10000000000000001, inf, 0.089442719099991588],
 1: [0.10000000000000001, 0.089442719099991588, inf],
 2: [inf],
 3: [inf, 0.089442719099991588, 0.089442719099991588],
 4: [0.10000000000000001, inf],
 5: [0.10000000000000001, inf]}

w.neighbors
Out[30]: {0: [1, 0, 3], 1: [0, 3, 1], 2: [2], 3: [3, 0, 1], 4: [5, 4], 5: [4, 5]}

I'm using anaconda with python 3.5.1, scipy 0.17.0, numpy 1.10.4, pysal 1.11.0

This is related to a bug #726 that has been fixed in dev. It should be out in a rolling release in the next few weeks, but for now one could grab the dev branch as an interim solution.

Fixed in 1.11.1


Update reprounzip-qt doc: Linux sets up file association

See #253
Check that this works, update the docs.

Fixed by 14031489.


Reservation remove

Upgrade to moment.js 2.18
Add command 'cancel'

Cancels the next meeting of the commander
Takes the meeting room as its only argument
Usage: cancel <room>

Change usage of 'book'

Usage: book <room> [arguments...]
Arguments can be:

Duration:

Default: 15min
Format: __min
1 <= duration <= 60

Start time:

Default: now
Format: hour:minute, hour.minute or now

Start date:

Default: now
Format: ISO 8601, RFC 2822 Date time or JavaScript Date.parse compatible

'rooms' now returns next 5 reservations instead of 2
Rewrite 'help'
Remove some of the command aliases

Blocking issues:

[x] Date parsing does not work correctly
[x] Overlapping events when booking one are not detected correctly
[x] Meeting cancelling is untested
[x] Lacking comments and documentation

Date as 'room' argument is now also removed, even though it's not apparent from the commit messages.

Changes since the submission of this PR:
Features/changes:

Remove start time and date arguments for 'book'
Add help verbose
Make some printed times more human-readable

Fixes:

Fix reservation overlap checking in 'book'
'free' no longer erroneously says 'No free meeting rooms' when there's no reservations for said meeting room


fix: remove non-transient logs on missing artifact-repositories configmap

Fixes #9085.
Motivation
Remove high levels of error messages that aren't errors. Reduce additional observability costs associated with running Argo Workflows, although negligble.
Clarify the difference between side-effect and non-side-effect functions in utility module.
Modifications
Renames IsTransientErr to LogIsTransientErr, which is easily undoable if it's more noise than signal.
Introduces a LogOnlyTransientErr, which only logs errors if they're transient. Suitable for a use-case such as trying to fetch an object that doesn't exist when it's optional.
Verification
No verification performed due to the (deceptive) simplicity of the change.

The two new function names LogIsTransientError and LogOnlyIsTransient error imply things about their purpose which aren't really their primary use (logging, not a test).
They also don't immediately make sense - two functions called LogDogName and LogOnlyDogName I wouldn't know which to call to log the dogs name. The function names you've created make sense if you understand the history. The Is part of their name helps, but...
[...]
Naming things is hard.

Thanks for the review, @Joibel, much appreciated. I solidly agree, naming things is hard.

I'd suggest either calling them IsTransientErr and IsTransientErrVerbose, or my slight preference would be IsTransientErrQuiet and IsTransientErr.

Considering that the specific scenario wants to ignore non-transient errors only, do I understand you correctly that IsTransientErrQuiet seems appropriate although it won't be quiet, just less verbose?

EDIT: I've assumed that you indeed meant IsTransientErrQuiet was appropriate although it's not fully quiet, re: naming things, and simplified the PR to only switch the lookup of the configuration map artifact-repositories to IsTransientErrQuiet.

It's Quieter, but in the interests of sane shorter names it felt better to just call it Quiet.
Thanks, for doing this.

@Joibel I don't think the minimal E2E test that's failing here isrelevant to the code change. Is that something you could confirm, and if so, merge the PR?

@Joibel I don't think the minimal E2E test that's failing here isrelevant to the code change. Is that something you could confirm, and if so, merge the PR?

I'll re-run them and see if they pass, they look like a flakey test but I'd like to be sure.


clock project

Please send extracted stuff

ok
On Sun, Oct 3, 2021 at 1:17 AM Aflah @.***> wrote:

Please send extracted stuff
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ron2111/Hacktoberfest2021_awesome-projects/pull/247#issuecomment-932811364,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARKM3P2A2PP26R2YX5N6IXLUE5OWTANCNFSM5FF7R7DQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


Renable ivy-prescient file completion and add regexp to the default filter method

This PR does several things.

closes #33 . As describe in the issue, actions can now take an optional second argument that is a list of all marked candidates. To handle this, I decided to not call prescient-remember when multiple candidate have been marked. It could be very easy to mark 200 or so candidates and pollute your ratings.

closes #28 . The issue was that the actions from counsel-find-file are full file paths, but the candidates are only the base name. Therefore the database didn't match the candidate list. I remove the directory name before we remember the candidate to address this.

closes #27 and #24 . Use regexp in the default filter as discussed in that issue and removes the literal toggle.

Also I changed the action wrapper to only remember candidates when the collection is being sorted with ivy-prescient. This removes the need for ivy-prescient-exclude-commands.
Let me know what you think. Once everything is finalized, I will add a change log entry.
closes #15.

Thanks again :)


cddlib: 0.94h -> 0.94i, add cdd_both_reps binary

Motivation for this change

update cddlib to the latest version, 0.94i
add the cdd_both_reps binary. Sage needs the binary, most other big repositories package it and it is proposed upstream

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

@grahamcofborg build cddlib pynac gfan singular

cc maintainer @7c6f434c

Success on x86_64-linux (full log)
Attempted: cddlib, pynac, gfan, singular
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/896qx9kb8bwxyn3jsnlyv23ylgng16ic-pynac-0.7.19
shrinking /nix/store/896qx9kb8bwxyn3jsnlyv23ylgng16ic-pynac-0.7.19/lib/libpynac.so.17.1.1
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/896qx9kb8bwxyn3jsnlyv23ylgng16ic-pynac-0.7.19/lib
patching script interpreter paths in /nix/store/896qx9kb8bwxyn3jsnlyv23ylgng16ic-pynac-0.7.19
checking for references to /build in /nix/store/896qx9kb8bwxyn3jsnlyv23ylgng16ic-pynac-0.7.19...
/nix/store/fi6dqlsxv9bmhndnh539lfvh9xcwikci-cddlib-0.94i
/nix/store/896qx9kb8bwxyn3jsnlyv23ylgng16ic-pynac-0.7.19
/nix/store/r06dhla8kv6gayjf0m66npc0izip36mb-gfan-0.6.2
/nix/store/blyyv53dwqnn6j44rwg62x8d4025v4fs-singular-4.1.1p1

I am still too lazy to add @timokau as maintainer to all the stuff I packaged only because of Sage

Failure on aarch64-linux (full log)
Attempted: cddlib, pynac, gfan, singular
Partial log (click to expand)
shrinking /nix/store/qbxgncaikvvpiqhm9fhh0fg8672wr1gy-singular-4.1.1p1/lib/libomalloc-0.9.6.so
shrinking /nix/store/qbxgncaikvvpiqhm9fhh0fg8672wr1gy-singular-4.1.1p1/lib/libsingular_resources-4.1.1.so
gzipping man pages under /nix/store/qbxgncaikvvpiqhm9fhh0fg8672wr1gy-singular-4.1.1p1/share/man/
strip is /nix/store/gp7fylxwn18b7pl2c18ks89hsiaxyfvf-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/qbxgncaikvvpiqhm9fhh0fg8672wr1gy-singular-4.1.1p1/lib  /nix/store/qbxgncaikvvpiqhm9fhh0fg8672wr1gy-singular-4.1.1p1/libexec  /nix/store/qbxgncaikvvpiqhm9fhh0fg8672wr1gy-singular-4.1.1p1/bin
patching script interpreter paths in /nix/store/qbxgncaikvvpiqhm9fhh0fg8672wr1gy-singular-4.1.1p1
checking for references to /build in /nix/store/qbxgncaikvvpiqhm9fhh0fg8672wr1gy-singular-4.1.1p1...
building of '/nix/store/5g6jicws77097qhi5qqp8ngpq2f544jr-singular-4.1.1p1.drv' timed out after 3600 seconds
cannot build derivation '/nix/store/5li9rpkxnlz6h5ajwyl2893jlaih0rzx-pynac-0.7.19.drv': 1 dependencies couldn't be built
error: build of '/nix/store/5g6jicws77097qhi5qqp8ngpq2f544jr-singular-4.1.1p1.drv', '/nix/store/5li9rpkxnlz6h5ajwyl2893jlaih0rzx-pynac-0.7.19.drv' failed


Nina xpk gpu h100

Fixes / Features

Add cluster and workload creation for A3 cluster

Testing / Documentation
Ran xpk cluster create successfully in integ tests

[ y ] Tests pass
[ y ] Appropriate changes to documentation are included in the PR

Nina was able to check that Pathways functionality still work after these changes! Thank you for the change!


Create ping-ibc.json

Looking good now @liangping! Welcome to the IBC testnet!
$ rly q bal ping-ibc
70000pingcoin,1000transfer/wzirualrkqcvbpvi/samoleans


Windows Defender classifying installer as TROJAN

The file webOS.Dev.Manager_1.11.15_x64_en-US.msi is detected as a trojan by my windows defender
Category : Trojan:Script/Sabsik.FL.B!ml

See #10.


Added MIT option for owners

Added an option to select MIT for the formula owner. Updated Vagrantfile
to set up salt-extensions repo using gitfs when MIT is the owner.

This is better then #2 , so I'll close that in favor of this. :+1: I had one small nit comment.


Control refinement and common svt changes

Description

 Brief description of the requested change.
Checklist

[ ] I have read the instructions mentioned in Contribute to Code.
[ ] I have read and understood the criteria described under submitting changes.
[ ] The title of the PR clearly describes the intent of the PR.
[ ] This PR does not introduce any breaking changes to the code.

this code changes merged to sai's control changes branch


Calculation of numbers is concatenated as string in 2.0.0.beta-9

it('calculation with node operand returned as string', () => {
      var doc = initDoc(`
      <data>
        <number>4</number>
      </data>`);

      assertString('/data/number + 1', '5'); // returns '41'
    });

The requested XPath Result Type should have nothing to do with how the expression is evaluated.
I believe that the presence of an infix operator always means that both left and right operands are converted to numbers (and a + never concatenates in XPath).
To test in browser's native XPath Evaluator:
var doc = new DOMParser().parseFromString(`
     <data>
        <number>4</number>
      </data>
`, 'text/xml');
doc.evaluate('/data/number + 1', doc, null, 2);
// returns {resultType: 2, stringValue: "5", ...}

I created some tests

Hi @MartijnR  :wave:  If this is true:

I believe that the presence of an infix operator always means that both left and right operands are converted to numbers (and a + never concatenates in XPath).

then the fix would be at https://github.com/medic/openrosa-xpath-evaluator/blob/orxe2/src/utils/operation.js#L14 - change:
if(op.v === '+' && isNumber(lhs.v) && isNumber(rhs.v)) {

to
if(op.v === '+') {

Hi Alex! 👋 Thanks a lot!  I'll try out your fix and submit a PR.

@MartijnR I think this is now fixed in master: https://github.com/enketo/openrosa-xpath-evaluator/blob/master/test/integration/infix-operators.spec.js#L176

Yes. Thanks!


[examples] drop binutils from java examples

Summary
I think these were added when @mohsenari was developing these examples to
work inside a alpine Dockerfile. Usually, binutils is not needed and can be sourced
from the regular OS.
How was it tested?
DEVBOX_EXAMPLE_TESTS=1 go test -v -run TestExamples/development_java  ./testscripts/...

Current dependencies on/for this PR:

main

PR #930   👈

This comment was auto-generated by Graphite.

@Lagoja what criteria do we want for the examples-projects? Should they have packages like binutils that work in completely isolated environments, even if they may be excessive for most regular OS use-cases? I'd imagine the latter scenario is more common, and so submitted this PR.

At the time I was building the java planner I added binutils because it complained in the Docker build stage if I remember correctly. But if the example works without it, I think it should be removed.

eh, I tested gradle locally but not maven, and sure enough maven seems to require binutils


trivial, comments: for travis encrypt to use a specific repository

The repository when issuing travis encrypt is automatically set to origin
from git settings, however it can cause problems if origin is set to a
fork..

@bensigelman could you please review? It's related to https://github.com/opentracing-contrib/meta/pull/7 This should prevent any potential problems with travis encrypt.

LG, thanks!


Add 5.15.3 to the list

5.15.3 has been released as open-source for some time now  h̶t̶t̶p̶s̶:̶/̶/̶w̶w̶w̶.̶q̶t̶.̶i̶o̶/̶b̶l̶o̶g̶/̶c̶o̶m̶m̶e̶r̶c̶i̶a̶l̶-̶l̶t̶s̶-̶q̶t̶-̶5̶.̶1̶5̶.̶3̶-̶r̶e̶l̶e̶a̶s̶e̶d̶
is this the only thing needed?

Check your link again. Qt 5.15.3-6 have been released for some time, but you need a paid license to download them. We only support Qt binaries that are available at download.qt.io/online; the paid versions are not there.

it's publicly available here
https://download.qt.io/official_releases/qt/5.15/5.15.3/

That folder includes source code, not prebuilt binaries. Please read:

We only support Qt binaries that are available at download.qt.io/online

Adding support for the official_releases folder will take a lot more work than just modifying the combinations.json file.

@ddalcino indeed, what a pity!


Leak detection (--check-leaks) is running before the hooks, preventing cleanup

Prerequisites

[x] Checked that your issue hasn't already been filed by cross-referencing issues with the faq label
[x] Checked next-gen ES issues and syntax problems by using the same environment and/or transpiler configuration without Mocha to ensure it isn't just a feature that actually isn't supported in the environment in question or a bug in your code.
[x] 'Smoke tested' the code to be tested by running it outside the real test suite to get a better sense of whether the problem is in the code under test, your usage of Mocha, or Mocha itself
[x] Ensured that there is no discrepancy between the locally and globally installed versions of Mocha. You can find them with: node_modules/.bin/mocha --version(Local) and mocha --version(Global). We recommend that you not install Mocha globally.

Description
I'm unit testing a code which deals with global variables (intended).
Mocha leaks detection worked well and detected that I was leaking my unit test global variables.
I then proceeded to use hooks in attempt to clean the global scope. However it seems mocha's leak detection is running BEFORE the hooks, making it impossible to clean the global scope in hooks. I believe that's not what we want.
Steps to Reproduce
describe('test', function() {
	function _clean_global_scope() {
		delete globalThis._foo
	}
	before(_clean_global_scope)
	afterEach(_clean_global_scope)

	it('should set the global variable', () => {
		globalThis._foo = 33
		expect(globalThis._foo).to.equal(33)

		// _clean_global_scope() // if we uncomment this line, the test pass
	})
})

Expected behavior: [What you expect to happen]
No error.
Actual behavior: [What actually happens]
Error: global leak(s) detected: '_foo'
Reproduces how often: [What percentage of the time does it reproduce?]
100%
Versions

The output of mocha --version and node_modules/.bin/mocha --version: 10.1.0
The output of node --version: 18.12.1

Additional Information
If I manually call _clean_global_scope()  at the end of the unit test, the leak is not reported. However the point of the hooks is to avoid this duplication.
Also thanks for this trusty tool that I'm using for so many years!

@Offirmo could you please post a standalone reproduction? As in, something one of us can clone locally and run a couple quick commands to see the issue? It's hard to triage this with just a code block + plaintext description.

Hi @JoshuaKGoldberg thanks for responding.
I posted a standalone test above that trivially produce the issue. Is it inconvenient to copy/paste? Do I really need to setup a full repo? (I can)

I don't get any test failures when I try this locally on a basic Mocha project (the new one in https://github.com/mochajs/mocha-examples/pull/73). Neither when the line is commented nor when it's un-commented. So there's something missing. 😄

copy/paste

It's not just copy/paste being asked for, it's also sleuthing together the specifics of the surrounding context.

I'm guessing the expect comes from Chai, maybe it's another package library?
You're not on the latest Mocha (10.2.0), what other packages are out of date?
How are you running Mocha? Browser? CLI? Programmatically with the API?
What other packages are being used with Mocha? Or heck, what's the package manager?

Having a single unified reproduction that a maintainer can quickly get working on my computer bypasses all that questioning. It makes sure we can get exactly our issue, quickly, without guesswork.
https://antfu.me/posts/why-reproductions-are-required is a good blog post that goes into this more.

Hi @JoshuaKGoldberg thanks for the reminder.
Please find a minimal repro using the latest everything and no expect:
https://github.com/Offirmo/bug-report--mocha-202401
To re-iterate the issue, I suspect mocha's "leak checker" is running too soon, it should wait for the afterEach() to have executed.
Thanks for picking my 1 year old issue!

Ok swell thanks - confirmed that reproduction works for me! And it's very straightforward, thanks for that. 😄
I can definitely see why this behavior isn't optimal for cases like this. It feels to me like the right fix would be to have leak detection done at the very least after afterEach hooks... and potentially even after after hooks as well.
But I'm not extremely familiar with how folks in the wild generally use --check-leaks. Maybe there are some folks who are relying on this? For example, they might both be relying on --check-leaks and also running code that coincidentally wipes global variables. If that's a thing, then --check-leaks might need to be configurable as to when leak detection runs.
cc @mochajs/maintenance-crew for input. Marking this as status: in discussion for now. If nobody can back up my anxieties for a while then I'd expect we can treat this as a straightforward bug fix.

Hi @JoshuaKGoldberg ,
thanks for taking the time to look at this bug and thanks as well for your care in protecting backward compatibility 👍
My 2 cts on your questions:

indeed if we fix this it will be a breaking change and we should, at least temporarily, add an option to switch back to the old behaviour (and ask users who need this option for feedback)
I don't think it would affect many people:

global variables are rightly shunned in the dev world, they're very rarely used and linters should catch them. my use case was very special (a globalThis polyfill which is not even needed anymore since all browsers and node support it now)
the check-leaks option is not active by default, so not many people must be using it
I reported this bug 1y ago and it attracted no activity

Hence IMO it shouldn't affect many users and this should be a straightforward bug fix.
It's just my personal 2cts of course, I acknowledge the world is vast :)
Have a nice week-end.
P.S. different subject, but since we're at it, what's preventing us from enabling check-leaks by default? Also fail-zero? IMO all "good, safe" options should be enabled by default and disabled on-demand. What do you think?

P.S. different subject, but since we're at it, what's preventing us from enabling check-leaks by default? Also fail-zero? IMO all "good, safe" options should be enabled by default and disabled on-demand. What do you think?

Heh, I think just inertia. For a while Mocha wasn't actively maintained. And now per #5027 we're trying not to make too many splashy changes. I'd welcome an issue - maybe in some number of months we'd feel confident enough to look at changes like that. But I suspect it'd break enough people that it'll be a while, if ever.

Oh! Just found #2206 - which is a similar request. Since this issue has the great reproduction (❤) I'll close that one out as a duplicate of this one.

At first this seemed like a straightforward bug. But @voxpelli and I took a deeper look and found that leak detection has for many years run after every phase of tests: beforeEach, it, afterEach, etc.
describe("test", function () {
  beforeEach(() => {
    globalThis._foo = 33;
  });

  it("should set the global variable", () => {
    delete globalThis._foo;
  });
});

  1) test
       "before each" hook in "test":
     Error: global leak(s) detected: '_foo'

So if the behavior were to be resolved to work as the issue expected, it would be a big switch for the leaks. It'd have to be made more configurable, such as...

...switching the option to an enum like "after-hooks" (current) / "after-tests" (proposed)
...to an external framework, a la jest-leak-detector

It's not clear to us whether it'd be worth the work to keep this around in the enum form. It was switched from opt-out to opt-in in https://github.com/mochajs/mocha/issues/791 with a mention of edge cases and performance implicications.

It was made to run on tests instead of hooks in version 0.0.1-alpha1: https://github.com/mochajs/mocha/commit/c3aaca1766e17f3fdd011b4514c23e3dd498644f
Then was re-added for hooks as well in version 0.0.7: https://github.com/mochajs/mocha/commit/75ebe53718755f3ff3fd019dd0f0d91807d1c5b8
So essentially: This has always been detected the way it is tested right now and I think changing that now 10+ years later is to make it into something that it has never been.
The naming is also very unfortunate – it doesn't check for leaks, it checks for pollution of global namespaces, something that was a real struggle back in the jQuery days (probably why it was detected by default then) but which in today's world of modules is much less of an issue, especially considering that strict mode prohibits implicit assignment to global scope.
I think the use case for this option is nowadays probably better solved through linting like: https://eslint.org/docs/latest/rules/no-implicit-globals
Current implementation has special browser specific heuristics to be able to diff top level keys on globalThis, but eg. doesn't check for anything like JSON.foo = 123 or eg. memory leaks.
My vote would be: Deprecate in next major release, remove in release afterwards and suggest that people do such tests themselves by eg. doing:
describe("test", function () {
  let globalThisKeys;

  beforeEach(() => {
    globalThisKeys = Object.keys(globalThis);
  });

  afterEach(() => {
    if (Object.keys(globalThis).some(key => globalThisKeys.includes(key) === false)) {
      throw new Error('Leaked global');
    }
  });

  it("should set the global variable", () => {
    globalThis._foo = 123;
  });
});

Possibly adding in some of the same heuristics as the Mocha-internal filterLeaks() has if they are still needed for ones use cases (though it eg. has special cases for ie6,7,8 and old school opera): https://github.com/mochajs/mocha/blob/8317f902a11a5837d00581e7926b145d20f59b61/lib/runner.js#L1186-L1217

Too bad! Even imperfect, this feature was very useful!
However I agree that the current implementation is too awkward.
That could indeed be re-implemented properly as a plugin ✅

Following up: we'll figure out a long-term plan for --check-leaks on the core team and propose it publicly. We'll set a goal that folks can always have the behavior they rely on now. I.e. any deprecations will be accompanied by at least docs on how to achieve the old behavior.


Prompt for confirmation on destructive commands

To avoid accidental removal of services/apps/vault keys etc. a confirmation prompt in the CLI would be helpful.
PR: https://github.com/kontena/kontena/pull/712

Fixed in #712


Small documentation suggestion

curl -s does the same thing as 2>/dev/null
It can clean up your examples some.

Sweet! Thanks. I'll update the examples!


Error on Problem 45

Hello,
I found an error on Problem 45. It explicitly states that the last four digits have to be "2022", and yet the answer and reasoning are using "2002" instead. I hope this oversight can be corrected.

I believe the correct answer is 9362022.

Thanks for your comment, there is a typo in the question, so it should be whose last four digits are 2002. I would change it!


cmd/go: "install -v" does not reliably print changed package names

Please answer these questions before submitting your issue. Thanks!
What did you do?
I can't reproduce this 100% of the time, but generally, make a change to "github.com/kevinburke/travis/lib/travis.go" - add a package level variable, add a header to NewRequest, add a Do implementation that calls c.Client.Do.
Then recompile with cd $GOPATH/src/github.com/kevinburke/travis && go install -v ./...
What did you expect to see?
I expect to see github.com/kevinburke/travis/lib in the list of changed packages.
What did you see instead?
It does not appear in the output.
Does this issue reproduce with the latest release (go1.12)?
No
System details
go version devel +4fb900e9ca Mon Mar 4 01:22:28 2019 +0000 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/kevin/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/kevin"
GOPROXY=""
GORACE=""
GOROOT="/Users/kevin/go"
GOTMPDIR=""
GOTOOLDIR="/Users/kevin/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
GOROOT/bin/go version: go version devel +4fb900e9ca Mon Mar 4 01:22:28 2019 +0000 darwin/amd64
GOROOT/bin/go tool compile -V: compile version devel +4fb900e9ca Mon Mar 4 01:22:28 2019 +0000
uname -v: Darwin Kernel Version 17.7.0: Thu Dec 20 21:47:19 PST 2018; root:xnu-4570.71.22~1/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.13.6
BuildVersion:	17G5019
lldb --version: lldb-1<IP_ADDRESS>
  Swift-4.2

Apologies; the first draft of this bug report said "Yes" for "can reproduce with Go 1.12"; the answer is "No" so this is a regression.

Are you by any chance making changes that had been compiled before? If the only non-cached operation is linking a binary, and not compiling any package, I've seen go install use my CPU while not printing anything.

CC @jayconrod

What @mvdan said: if you're just making a change, it's possible that the result of the build is already cached. (The Go build cache is content-addressed, so the cache can hit even if the mtime of the inputs has changed.)

 I changed my vim-go settings for leader+d from "check if this compiles" to "check if this compiles AND build the package." The reason it was inconsistent was I wasn't rerunning the syntax checker between every build, so sometimes it would appear and sometimes it wouldn't.
Feel free to add a "ProblemBetweenKeyboardAndChair" label.


Event tracker

Added events publishing infra using mangos nanomsg implementation. introduced a Publisher server and subscriber as well.
Added a wrapper for publishing events via publisher singleton

@y0sher please re review


There is no way of adding relation type of a shape in GeoShapeQuery

Under current implementation, parameters can be added to at the query level, or to the body of the shape, but no way of adding a relation type as it is denoted in the elasticsearch documentation:
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-geo-shape-query.html

I've created a PR https://github.com/ongr-io/ElasticsearchDSL/pull/239


Program synthesis

Add a new programmatic task. This task asks the model to generate a python function that satisfies given input output.

@abhishekraok Thank you for submitting your task! We are in the process of pairing submissions with task reviewers and will be in touch soon.

FYI I have updated the code for #288 @cdfreeman-google @ajslone

Hello Abhishek, I am one of the reviewers assigned to your Python Program Synthesis task. I like this task overall and to me it looks submission worthy. I have the following review

Correctness

Good. Tests are passing. Examples are consistent with each other and the aim of the task.
In line 131 of task.py where you compare "y == expected" there is the possibility that the types are incomparable. In other words the model returned a syntactically correct definition of x but with the return type being completely different than what is expected.

Formatting

Some arrays end with a comma rather than an element (i.e. ", ]"), please make them all end the same way.

Specificity

Justification is good; keywords listed.

Thoroughness

The custom metric allows for degrees of model correctness ranging from compilation to correctness on a subset of inputs. I think this is sufficient. The only part of the metric I question is the assumption that the max length of all program definitions should be 25 characters, and all lengths greater are of equal desirability. One of the example function definitions is 43 characters (lambda x: 234817 if x % 2 == 0 else 918276) so a model returning a verbose function would be scored just as well as one that returns this function. I don't have suggestions for a fix but I think it could be done better.

Difficulty

As you mention in the readme, existing models can already do limited code synthesis given a description. Simply to prove that there is still plenty of room for improvement I'd recommend adding a few test cases of multi-line functions.

Not Solvable by memorizing the Internet

This is sufficiently simple to be solvable by memorizing the internet if you're unlucky. You already have plans to add programmatically generated test cases which would solve the issue. In addition to generating test inputs I recommend generating test functions for different classes of functions. E.g. binding different values to y in f(x): x > y.

Novelty

I searched for "program", "script", and "synthesis" in the BIG-bench tasks and could not find duplicate benchmarks. I think this is novel but I'm not familiar with the space of language model evaluation tasks.

Justification

Good justification provided in the Readme.

Size

See comment for #6

Compute Resources

Example generation and answer evaluation is computationally easy.

Thanks for the detailed review.
Regarding comparing different type, the model is supposed to generate program that returns the correct type, so if there is a type mismatch then it gets 0 score.
For the length penalty being equal to all programs that are greater than 25 chars, good point,  I updated the code so that all programs > 100 chars have same score and anything less is scored 25 - len/4.
I added one multi line program as suggested.
I have updated the code so that some random elements are added to the input list and it is shuffled randomly to prevent memorization.
Thanks

The changes look good to me.
The programmatic input generation functionality (the add_noise function) seems overloaded. The way I'd set it up is have different random input generator functions and create lists with them. As an example I would take these task examples:
...
    [[2, 3, 4], lambda x: x * x],
    [[0, 1, 2], lambda x: 4 * x * x + 3 * x - 62],
    [[0, 1, 2], lambda x: 5],
...

and rewrite them as
def small_ints():
  return [randint(-100,100) for _ in range(3)]
...
    [small_ints(), lambda x: x * x],
    [small_ints(), lambda x: 4 * x * x + 3 * x - 62],
    [small_ints(), lambda x: 5],
...

or some variation of this. I think this will be simpler to read and extend with additional sampling spaces.

The changes look good to me.
The programmatic input generation functionality (the add_noise function) seems overloaded. The way I'd set it up is have different random input generator functions and create lists with them. As an example I would take these task examples:
...
    [[2, 3, 4], lambda x: x * x],
    [[0, 1, 2], lambda x: 4 * x * x + 3 * x - 62],
    [[0, 1, 2], lambda x: 5],
...

and rewrite them as
def small_ints():
  return [randint(-100,100) for _ in range(3)]
...
    [small_ints(), lambda x: x * x],
    [small_ints(), lambda x: 4 * x * x + 3 * x - 62],
    [small_ints(), lambda x: 5],
...

or some variation of this. I think this will be simpler to read and extend with additional sampling spaces.

The manually created inputs are provided to make it easier for the model to guess which function to generate, that is why I wanted to mix manual input + random inputs. In some pathollogical cases the random generator may generate all same numbers and it would be impossible to determine the program. I have added documentation to make this more clear. You can also check the readme design considerations section for more details. I have tried to simplify the add_noise function by refactoring it into 4 smaller functions.

@abhishekraok We are now requesting that task authors please include an explicit section in the README.md file called "data source", listing exactly where you got your data from (or explicitly state that you made it up yourself). Many thanks!

The refactoring is harder to read than the original. Please revert.
Thank you again for your submission, that's all the feedback I have for now until the second reviewer responds.

Reverted the refactor and added data source to README.

@ErrWare are one of the assigned reviewers for this task.  Please provide feedback and be sure to notify me with a formal accept or does not meet criteria by Tuesday June 22 (if you have not already done so).

@joshrule are one of the assigned reviewers for this task.  Please provide feedback and be sure to notify me with a formal accept or does not meet criteria by Tuesday June 22 (if you have not already done so).

Thanks for submitting this task. I'm glad to see program induction tasks included in the benchmark. That said, I think there are some important issues to address before accepting this task.

correctness/formatting

The task passes the tests.
Just for concreteness, it would be helpful to include an example trial in the opening of README.md.
x   - 2 and x - x are the same function and use the same inputs. They aren't extensionally distinguishable, so consider removing one of them from the task. This may affect other functions, too. I didn't check all of them.
Perhaps I'm missing something, but isn't the max score 25 + 60 + 20 = 105, rather than 100?

specificity

You naturally divide the tasks into multiple subtasks in task.py. Consider explicitly factoring these into BIG-bench subtasks so that we get a more detailed description of each language model's abilities for various kinds of program induction.
The way the prompts are constructed gives a list of inputs and a list of outputs (e.g. What function goes from [IN_1, IN_2, IN_3] to [OUT_1, OUT_2, OUT_3]?. This seems like an unusual way to structure the task and requires that the model perform long-range dependency management. That's a separate issue from being able to write code. To make it more specifically about program induction, consider something like What function goes from IN_1 to OUT_1, IN_2 to OUT_2, and IN_3 to OUT_3?
An explicit DSL would help to make clear exactly what kind of problems this task tests. Right now, it requires a variety of primitive python syntax and built-in functions, but I don't see any systematic logic to the choices. Moreover, there are huge swathes of legitimate python that are outside the scope of this task (e.g. no classes, no imports). It's hard to see what specifically is being tested.

thoroughness

The task is not thorough. It tests only 40 simple functions. Again, sampling from a DSL would make it easy to programmatically generate a large number of tasks.

difficulty

The pilot results suggest that the task is difficult for a reasonable language model baseline.
Even for deep learning models purpose engineered to induce programs, program induction is a difficult task. Given that large language models use much larger networks on massive datasets, it will be interesting to see how they perform.

not solvable by memorizing the internet

The author appears to have made some effort to make the tasks difficult to solve by memorization (e.g. changing "fizzbuzz" to "bizfuzz"). These functions are simple enough, though, that some of them (e.g. the identity function, x + 1, x   - 2) almost certainly appear in several places on the Internet. While the entire task cannot be solved by memorization, some probably can, and it may be difficult to tell whether this has happened.

novelty

Using a neural network to produce code isn't particularly novel. Language models aren't my core area, so I'm not aware how novel it is to use a general-purpose language model for this task. Consider adding a statement to address this more directly. Saying that this task tests the ability to "solve more general programming tasks" as compared to "generating html from [a] description" is a bit too vague for me to understand the novelty claim. Specific citations would be useful.
There are now several related tasks that require comprehending, executing, and debugging code, but these are all distinct from writing code from scratch. Reasoning about formal languages is an important enough skill to warrant having multiple related tasks.

justification

Program induction provides an important test of language models' ability to act intelligently and probes the difference between their ability to manipulate natural and formal languages.
I find the justification for this particular task weak as a test of large language models' program induction abilities. The task seems poorly scoped in terms of its relatively small size and lack of an explicit DSL. Resolving these issues would go a long way to justifying it.

size

The task tests 40 functions which is close to the low end of the stated guidelines. The task would be stronger with a much larger set of functions.
The task is configured to require exactly one trial per function. It would be a much stronger test if the number of trials per function were configurable, such that each trial involved different input/output pairs.

compute resources

The task requires one query per function and only tests 40 functions.
The task is otherwise computationally simple.

Hi Josh, thanks for the detailed review. I have made few changes based on your review.
Correctness
Added a sample input/output to readme.
There are no x-2 and x-x functions that you speak of. Perhaps you mean different functions?
I have updated the max score to 100.75. Since no valid function can have length < 5, the max score possible is 100.75, which is the one in the test_high_score() test.
Specificity.
Changed the format of query based on feedback to reduce long term dependency. I'm not clear about the sub-task, In the evaluation results, I do see results separately for each sub-task.
Thoroughness
The reason for not using explicit DSL is we want the model to be able to program in general programming language, so that it can be used more generally. Now with a general programming language like python it is not possible to cover all parts. This task is not trying to test the complete python programming capability of a model, just to see if it can guess some popular basic functions.
Memorization
The reason for keeping some simple functions (e.g. x+1, x etc.) is to have a graded difficulty for model scoring. Most of the problems are created with unique constants and should not be found on the internet. The inputs will certainly be unique due to the random numbers addition.
Novelty
The task need not be novel. As the BIG-bench review document says "Tasks should fill a gap in coverage by BIG-bench, but do not need to be conceptually novel.". Since program synthesis is not present in BIG-bench currently, this should be fine.
Size
I have added more functions now so that the total number is 64.
The reason for having only 1 query per function is so that the input list can be manually created such that it is helpful in figuring out the function.
Please let me know if there are any more suggestions.
Thanks

@abhishekraok:
Thank you for responding to my review and updating the task accordingly.

sorry x - 2 and x - x were typos in my review. I meant x ** 2 and x * x. Sorry about that! In any case, it looks like they're both still part of the task and are extensionally identical. Maybe substitute x ** 2 for x ** 3?
It looks like the high score has only been updated in one place. Does it also need to be updated on line 206 of task.py?
My suggestion about sub-tasks was that you should be able to review scores for the groups of tasks you mark as numeric, string, collection, logical, and type. It doesn't look like you currently do this in task.py? Am I missing something there?
Sorry for any confusion about the DSL. My recommendation was not to create a DSL separate from python but instead simply to be explicit about exactly what parts of python this task tested, and then be thorough as feasible in testing those parts. Since you're not testing all of python, you can think of the subset you do test as a DSL. Being clear about what that subset is and sampling a large number of simple functions would, ultimately, be a stronger test of basic python program induction.
I do think the task would be significantly stronger without much additional effort if you modified to run several queries, perhaps keeping the diagnostic inputs but resampling the random inputs each time. If you run enough queries, the diagnostic inputs may not even be necessary. Looping such that you run a few dozen queries per function would effectively marginalize over the random inputs and give you a more reliable estimate of a model's behavior.

Thanks again for the comments.

I have changed the function to x**3.
Good catch. Fixed
Created subtasks based on categories. Refactored the code.
Thanks for the clarifications.
I'll see if I can run the add_noise multiple times (e.g. 4) to increase the number of samples, I do not want to increase this too much as the output would be same for all of these, even though input would be unique.

Modified to run several queries by randomly sampling the input.

The amount of tasks we received this round is tremendous.  With so many tasks to review we have decided to extend the review period to Tuesday, June 29.
Reviewers: if the submitter has made revisions please be sure to notify me with a formal ”accept” or ”does not meet criteria” by Tuesday, June 29  (if you haven't already done so).
this is an automated message

@ErrWare - do you want to weigh in again now that I've also reviewed the task and @abhishekraok has updated in response?

This looks submission ready to me. I'm awaiting the "1 workflow awaiting approval" box to change to all workflows succeeded.

@chiafullo accept

@chiafullo accept

Your task has been accepted in the initial review stage.  The next stage of this process is for us to assign your task a meta-reviewer for final review and merge.  An assigned meta-reviewer will follow-up by commenting on the PR should it need further revisions.

Hello, I’m the meta-reviewer for this task. Here’s my feedback with respect to our review criteria:
Overall
Overall I think this is a reasonable task, however I have a couple of concerns that I think should be addressed prior to merging.
A major concern I have here is that the task uses exec to run arbitrary code as generated by a model. As is clear from the preliminary results, most likely this is completely harmless and often invalid python code. As we test this on larger and larger models, though, it is increasingly likely that the code will be valid, and executing potentially dangerous code is also increasingly likely. For BIG-bench we take care to sandbox all programmatic tasks in our internal evaluations, but for others to use this code in the future, we must take steps to ensure that no malicious code is executed. There are many examples of large language models memorizing blocks of code verbatim,  and numerous examples of researchers being able to coax these models into generating text verbatim from the training set. Given that the training corpus for all large LMs contains enormous amounts of source code, the probability of generating malicious code should not be ignored.
As a concrete recommendation, I would suggest using RestrictedPython to do any code evaluation. (https://restrictedpython.readthedocs.io/en/latest/index.html). This package ensures a much more secure and limited execution environment for running untrusted code. Given the scope and complexity of the target functions in this task, I don't think that using this restricted setting will impact the model's ability to generate a valid output. Another candidate task (https://github.com/google/BIG-bench/pull/124) uses this package, and there are some examples there, though the simple examples from the main RestrictedPython docs may be simpler and all that is needed here. It seems like for this task changing from using exec to a RestrictedPython implementation should be fairly straightforward.
Correctness
The task is formatted correctly and passes the tests.
Specificity
The task is reasonably specific, though program synthesis is a large category. The author describes the category of programs probed here in the README, outlining the scope of this task, so I think it is reasonably well-focused.
Thoroughness
The task is reasonably thorough for the stated goals, covering a few data types and mostly internal python methods.
Difficulty
Program generation tasks are typically quite difficult for current LMs, consistent with the author's initial experiments.
Not Solvable by Memorizing the Internet
The author generated the examples, and that coupled with the prompt formatting mitigates this risk.
Novelty
This task is not terribly novel, and there is at least one other candidate task in BIG-bench. (https://github.com/google/BIG-bench/pull/124)
Justification
The justification for the task is reasonable.
Compute Resources
This task has no compute resource issues.
Data Sources and Licensing
The author generated all of the examples, so there are no issues here.

Thanks for the detailed review Ambrose. Great tip on RestrictedPython, I have added it to my code and also a test to ensure a dangerous code snippet is not executed.
Thanks for bringing into my attention #124, I wasn't aware of this. Quite interesting. It is similar in many ways but different in few aspects. The main one being their input is natural language description of the problem, whereas in this the input is a set of input/outputs. I have added this info to the Readme.
Thanks

Thanks for the detailed review Ambrose. Great tip on RestrictedPython, I have added it to my code and also a test to ensure a dangerous code snippet is not executed.
Thanks for bringing into my attention #124, I wasn't aware of this. Quite interesting. It is similar in many ways but different in few aspects. The main one being their input is natural language description of the problem, whereas in this the input is a set of input/outputs. I have added this info to the Readme.
Thanks

@abhishekraok Thanks for all of the updates and the quick turnaround on this! Your changes were very thorough and address all of my concerns. Will merge this now. Thanks again for all of the hard work and for creating this task.


Something is wrong

When I run java-timeseries with the following data, something is wrong.
double[] sales = new double[] {3.0, 3.0, 7.0, 2.0, 2.0, 1.0, 0.0, 3.0, 4.0, 3.0, 2.0, 3.0, 6.0, 1.0,
                                                0.0, 3.0, 4.0, 2.0, 2.0, 0.0, 1.0};
long season = 8l;

TimePeriod   day = TimePeriod.oneDay();
TimeSeries   series = TimeSeries.from(day, sales);
TimePeriod   timePeriod = new TimePeriod(TimeUnit.DAY, season);
ArimaOrder   order = ArimaOrder.order(3, 1, 2, 1, 1, 2);
Arima             model = Arima.model(series, order, timePeriod);

Forecast forecast = model.forecast(7);
TimeSeries forecastValue = forecast.pointEstimates();
double[] forecastValuesArray = forecastValue.asArray();

 for ( double  forecastValue : forecastValuesArray) {
                System.out.println(forecastValue);
            }

Then the printed results are all NaN.
Thanks！

@y913403515 yeah me too :(

Sorry for the late response @y913403515. I'm just getting back to this project after a long time away.
You need to have more observations than the length of your seasonal cycle. For example, it wouldn't make sense to fit a monthly seasonal model with only 4 observations, which is roughly equivalent to what you're trying to do here.
Ideally, the number of observations you have should be at least twice the length of your seasonal cycle. So, in case your cycle is 81 days long, you should have 162 observations, but even then your forecast is going to be very unreliable. Think of fitting a seasonal model with only two years worth of monthly data. It's not enough data to learn from.
I'm not going to close this issue because one, I would like to see if I can give a better explanation of why this doesn't work, and two, there needs to be an error message in this circumstance instead of pumping out NaN values.


allow the use of any valid property via attributes

doing a bit of clean up and adding the ability to pass any valid property to yum via attributes.

@tas50 for review


Artifact along autoshader border

When far away, there's pixelated noise along the border between autoshaded and manually painted areas.

Looks similar to #244 and may be related or have the same cause.

This can be fixed by either removing the overlay shader optimization
if (out_mat.blend > 0.f) {
to
if (true) {

Or by moving the secondary texture lookups into the main function scope, moving them before the if out_mat.blend>0.
vec4 albedo_ht2 = texture(...)
vec4 normal_rg2 = texture(...);
if (out_mat.blend > 0.f) {

The above workarounds also fixes #244, so this is a duplicate. And both will be fixed with the latter as the branch does seem to still provide some optimization on my 3070.