Crash report FPRNetworkTrace.m - Line 253

Description
I see SIGABRT (ABORT) crash in my Crashlytics after update to v11.1.0.
FPRNetworkTrace.m - Line 253 - [FPRNetworkTrace didCompleteRequestWithResponse:error:] + 253
Which belong to firebase Performance SDK.
I saw that users had this crash before, but the issue was closed
https://github.com/firebase/firebase-ios-sdk/issues/10807
Reproducing the issue
I have never received these crashes while working on project running on my device so I was not able to reproduce them but I see them in Crashlytics in firebase dashboard.
Firebase SDK Version
11.1.0
Xcode Version
15.4
Installation Method
Swift Package Manager
Firebase Product(s)
Performance
Targeted Platforms
iOS
Relevant Log Output
# Crashlytics - Stack trace
# Application: com.myapp.ebc
# Platform: apple
# Version: 100.19.1 (24.254.7319279)
# Issue: 41b61afa8c63168ac078827dc5574441
# Session: 9a0a46ecc49f4e59be2714cae961cddc_DNE_1_v2
# Date: Tue Sep 10 2024 20:27:35 GMT+0200 (Central European Summer Time)

Crashed: com.apple.NSURLSession-delegate
0  libsystem_kernel.dylib         0xc2ec __pthread_kill + 8
1  libsystem_pthread.dylib        0x7c0c pthread_kill + 268
2  libsystem_c.dylib              0x75ba0 abort + 180
3  libsystem_malloc.dylib         0x9588 malloc_vreport + 896
4  libsystem_malloc.dylib         0x6430 malloc_zone_error + 104
5  libsystem_malloc.dylib         0x1fd4 _szone_free + 480
6  CoreFoundation                 0x84ec __CFStringDeallocate + 196
7  CoreFoundation                 0x7888 _CFRelease + 292
8  CFNetwork                      0xcaa94 CFHostCreateWithName + 117928
9  MyApp                          0x58c2f4 -[FPRNetworkTrace didCompleteRequestWithResponse:error:] + 253 (FPRNetworkTrace.m:253)
10 MyApp                          0x5929ec __InstrumentDataTaskWithRequestCompletionHandler_block_invoke_2 + 306 (FPRNSURLSessionInstrument.m:306)
11 CFNetwork                      0x6ac70 CFHTTPCookieCreateWithResponseHeaderFields + 62444
12 CFNetwork                      0x6aa44 CFHTTPCookieCreateWithResponseHeaderFields + 61888
13 libdispatch.dylib              0x213c _dispatch_call_block_and_release + 32
14 libdispatch.dylib              0x3dd4 _dispatch_client_callout + 20
15 libdispatch.dylib              0xb400 _dispatch_lane_serial_drain + 748
16 libdispatch.dylib              0xbf64 _dispatch_lane_invoke + 432
17 libdispatch.dylib              0x16cb4 _dispatch_root_queue_drain_deferred_wlh + 288
18 libdispatch.dylib              0x16528 _dispatch_workloop_worker_thread + 404
19 libsystem_pthread.dylib        0x4934 _pthread_wqthread + 288
20 libsystem_pthread.dylib        0x10cc start_wqthread + 8

If using Swift Package Manager, the project's Package.resolved
{
"package": "Firebase",
"repositoryURL": "https://github.com/firebase/firebase-ios-sdk.git",
"state": {
"branch": null,
"revision": "9118aca998dbe2ceac45d64b21a91c6376928df7",
"version": "11.1.0"
}
},
If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

Replace this line with the contents of your Podfile.lock!

Thanks for reporting, @Odobush1. Could you provide the full stack trace of your issue to see what's causing it?

Thanks for reporting, @Odobush1. Could you provide the full stack trace of your issue to see what's causing it?

Done.

Same crash, reverting my app to 11.0.0 for now:
#0	0x000000020df3f4e4 in _platform_strstr ()
#1	0x0000000104f41e90 in ___lldb_unnamed_symbol96 ()
#2	0x0000000104f2f8d8 in __lldb_unnamed_symbol54 ()
#3	0x0000000186c3e0f4 in invoking ()
#4	0x0000000186c3d144 in -[NSInvocation invoke] ()
#5	0x000000011535f25c in -[ADJRequestHandler signWithSigV2PluginWithParams:activityKind:clientSdk:] at /Users/sc0rch/Documents/Develop/EWA/EWA-ios/Pods/Adjust/Adjust/ADJRequestHandler.m:744
#6	0x000000011535aec4 in -[ADJRequestHandler sendPackageByPOST:sendingParameters:] at /Users/sc0rch/Documents/Develop/EWA/EWA-ios/Pods/Adjust/Adjust/ADJRequestHandler.m:94
#7	0x0000000115356924 in -[ADJPackageHandler sendFirstI:] at /Users/sc0rch/Documents/Develop/EWA/EWA-ios/Pods/Adjust/Adjust/ADJPackageHandler.m:293
#8	0x0000000115356a9c in -[ADJPackageHandler sendNextI:] at /Users/sc0rch/Documents/Develop/EWA/EWA-ios/Pods/Adjust/Adjust/ADJPackageHandler.m:308
#9	0x000000011535544c in __37-[ADJPackageHandler sendNextPackage:]_block_invoke at /Users/sc0rch/Documents/Develop/EWA/EWA-ios/Pods/Adjust/Adjust/ADJPackageHandler.m:115
#10	0x00000001153782d4 in __42+[ADJUtil launchInQueue:selfInject:block:]_block_invoke at /Users/sc0rch/Documents/Develop/EWA/EWA-ios/Pods/Adjust/Adjust/ADJUtil.m:803
#11	0x0000000105bd4a30 in _dispatch_call_block_and_release ()
#12	0x0000000105bd671c in _dispatch_client_callout ()
#13	0x0000000105bde5e8 in _dispatch_lane_serial_drain ()
#14	0x0000000105bdf360 in _dispatch_lane_invoke ()
#15	0x0000000105bec5f0 in _dispatch_root_queue_drain_deferred_wlh ()
#16	0x0000000105bebc00 in _dispatch_workloop_worker_thread ()
#17	0x000000020dfefc7c in _pthread_wqthread ()
Enqueued from com.apple.NSURLSession-delegate (Thread 22) Queue : com.apple.NSURLSession-delegate (serial)
#0	0x0000000105bdb390 in dispatch_async ()
#1	0x00000001153781f8 in +[ADJUtil launchInQueue:selfInject:block:] at /Users/sc0rch/Documents/Develop/EWA/EWA-ios/Pods/Adjust/Adjust/ADJUtil.m:798
#2	0x00000001153553ac in -[ADJPackageHandler sendNextPackage:] at /Users/sc0rch/Documents/Develop/EWA/EWA-ios/Pods/Adjust/Adjust/ADJPackageHandler.m:112
#3	0x00000001153552d0 in -[ADJPackageHandler responseCallback:] at /Users/sc0rch/Documents/Develop/EWA/EWA-ios/Pods/Adjust/Adjust/ADJPackageHandler.m:103
#4	0x000000011535bcc4 in __73-[ADJRequestHandler sendNSURLSessionRequest:responseData:methodTypeInfo:]_block_invoke at /Users/sc0rch/Documents/Develop/EWA/EWA-ios/Pods/Adjust/Adjust/ADJRequestHandler.m:233
#5	0x0000000115febca8 in __InstrumentDataTaskWithRequestCompletionHandler_block_invoke_2 at /Users/sc0rch/Documents/Develop/EWA/EWA-ios/Pods/FirebasePerformance/FirebasePerformance/Sources/Instrumentation/Network/FPRNSURLSessionInstrument.m:306
#6	0x0000000115febca8 in __InstrumentDataTaskWithRequestCompletionHandler_block_invoke_2 at /Users/sc0rch/Documents/Develop/EWA/EWA-ios/Pods/FirebasePerformance/FirebasePerformance/Sources/Instrumentation/Network/FPRNSURLSessionInstrument.m:306
#7	0x0000000188156a18 in __40-[__NSURLSessionLocal taskForClassInfo:]_block_invoke ()
#8	0x00000001881567d4 in __49-[__NSCFLocalSessionTask _task_onqueue_didFinish]_block_invoke_2 ()
#9	0x0000000105bd4a30 in _dispatch_call_block_and_release ()
#10	0x0000000105bd671c in _dispatch_client_callout ()
#11	0x0000000105bde5e8 in _dispatch_lane_serial_drain ()
#12	0x0000000105bdf394 in _dispatch_lane_invoke ()
#13	0x0000000105bec5f0 in _dispatch_root_queue_drain_deferred_wlh ()
#14	0x0000000105bebc00 in _dispatch_workloop_worker_thread ()
#15	0x000000020dfefc7c in _pthread_wqthread ()
#16	0x000000020dfec488 in start_wqthread ()
Enqueued from com.apple.NSURLSession-work (Thread 2) Queue : com.apple.NSURLSession-work (serial)
#0	0x0000000105bdb390 in dispatch_async ()
#1	0x0000000188132d04 in __49-[__NSCFLocalSessionTask _task_onqueue_didFinish]_block_invoke ()
#2	0x0000000188132194 in -[__NSCFURLSessionDelegateWrapper task:didFinishCollectingMetrics:completionHandler:] ()
#3	0x0000000188132180 in -[__NSCFURLSessionDelegateWrapper task:didFinishCollectingMetrics:completionHandler:] ()
#4	0x0000000188131f90 in -[NSURLSessionTaskMetrics collectWithCompletionHandler:queue:] ()
#5	0x000000018813199c in -[__NSCFLocalSessionTask _task_onqueue_didFinish] ()
#6	0x00000001881b472c in -[__NSCFLocalSessionTask connection:didFinishLoadingWithError:] ()
#7	0x00000001881b4638 in __51-[__NSCFURLLocalSessionConnection _task_sendFinish]_block_invoke ()
#8	0x00000001881b395c in -[__NSCFURLLocalSessionConnection withDelegateAndPendingCompletion:] ()
#9	0x00000001881b38b8 in -[__NSCFURLLocalSessionConnection _tick] ()
#10	0x0000000105be7844 in _dispatch_block_async_invoke2 ()
#11	0x0000000105bd671c in _dispatch_client_callout ()
#12	0x0000000105bde5e8 in _dispatch_lane_serial_drain ()
#13	0x0000000105bdf394 in _dispatch_lane_invoke ()
#14	0x0000000105bec5f0 in _dispatch_root_queue_drain_deferred_wlh ()
#15	0x0000000105bebc00 in _dispatch_workloop_worker_thread ()
#16	0x000000020dfefc7c in _pthread_wqthread ()
#17	0x000000020dfec488 in start_wqthread ()
Enqueued from com.apple.NSURLSession-work (Thread 2) Queue : com.apple.NSURLSession-work (serial)
#0	0x0000000105bdb390 in dispatch_async ()
#1	0x00000001881bd454 in -[__NSCFURLSessionConnection withWorkQueueAsync:] ()
#2	0x00000001881bd280 in -[__NSCFURLLocalSessionConnection afterDelegateWithTick:] ()
#3	0x00000001881b6108 in __50-[__NSCFURLLocalSessionConnection _tick_finishing]_block_invoke_2 ()
#4	0x00000001881b5b4c in -[__NSCFLocalSessionTask connection:willCacheResponse:responseCallback:] ()
#5	0x00000001881b5a7c in __50-[__NSCFURLLocalSessionConnection _tick_finishing]_block_invoke ()
#6	0x00000001881b395c in -[__NSCFURLLocalSessionConnection withDelegateAndPendingCompletion:] ()
#7	0x00000001881b38b8 in -[__NSCFURLLocalSessionConnection _tick] ()
#8	0x00000001881b37c4 in -[__NSCFURLLocalSessionConnection _tick] ()
#9	0x00000001881b395c in -[__NSCFURLLocalSessionConnection withDelegateAndPendingCompletion:] ()
#10	0x00000001881b48e4 in -[__NSCFURLLocalSessionConnection _didFinishWithError:] ()
#11	0x00000001881b320c in invocation function for block in SessionConnectionLoadable::withLoaderClientAsync(void (LoaderClientInterface*) block_pointer) ()
#12	0x0000000105be7844 in _dispatch_block_async_invoke2 ()
#13	0x0000000105bd671c in _dispatch_client_callout ()
#14	0x0000000105bde5e8 in _dispatch_lane_serial_drain ()
#15	0x0000000105bdf394 in _dispatch_lane_invoke ()
#16	0x0000000105bec5f0 in _dispatch_root_queue_drain_deferred_wlh ()
#17	0x0000000105bebc00 in _dispatch_workloop_worker_thread ()
#18	0x000000020dfefc7c in _pthread_wqthread ()
#19	0x000000020dfec488 in start_wqthread ()
Enqueued from com.apple.NSURLSession-work (Thread 2) Queue : com.apple.NSURLSession-work (serial)
#0	0x0000000105bdb390 in dispatch_async ()
#1	0x00000001881bd454 in -[__NSCFURLSessionConnection withWorkQueueAsync:] ()
#2	0x00000001881bd3d4 in SessionConnectionLoadable::withLoaderClientAsync ()
#3	0x00000001881bdcf4 in URLConnectionLoader::protocolDidFinishLoading ()
#4	0x00000001881ba950 in invocation function for block in URLConnectionInstanceData::withWorkQueueAsync(void () block_pointer) const ()
#5	0x0000000105bd4a30 in _dispatch_call_block_and_release ()
#6	0x0000000105bd671c in _dispatch_client_callout ()
#7	0x0000000105bde5e8 in _dispatch_lane_serial_drain ()
#8	0x0000000105bdf394 in _dispatch_lane_invoke ()
#9	0x0000000105bec5f0 in _dispatch_root_queue_drain_deferred_wlh ()
#10	0x0000000105bebc00 in _dispatch_workloop_worker_thread ()
#11	0x000000020dfefc7c in _pthread_wqthread ()
#12	0x000000020dfec488 in start_wqthread ()
Enqueued from com.apple.CFNetwork.Connection (Thread 5) Queue : com.apple.CFNetwork.Connection (serial)
#0	0x0000000105bdb390 in dispatch_async ()
#1	0x00000001881bd578 in URLConnectionInstanceData::withWorkQueueAsync ()
#2	0x0000000188135f50 in non-virtual thunk to URLConnectionLoader_Classic::protocolDidFinishLoading() ()
#3	0x0000000188135d44 in URLProtocol::sendDidFinishLoading ()
#4	0x00000001881054fc in HTTPProtocol::handleStreamEvent ()
#5	0x0000000188105180 in HTTPTransaction::_onqueue_invokeHandler ()
#6	0x0000000188104d94 in HTTPConnection::_onqueue_responseDataArrived ()
#7	0x0000000188144320 in HTTPEngine::_readBodyFinish ()
#8	0x0000000188102ff8 in HTTPEngine::_deliverBodyBytes ()
#9	0x0000000188106f70 in HTTPEngine::_getBodyIntelligently ()
#10	0x0000000188106c94 in HTTPEngine::_readBodyStartNextRead ()
#11	0x0000000188102ec4 in invocation function for block in HTTPEngine::_getBodyIntelligently(void (NSObject<OS_dispatch_data>*, CFStreamError, bool) block_pointer) ()
#12	0x0000000105bd4a30 in _dispatch_call_block_and_release ()
#13	0x0000000105bd671c in _dispatch_client_callout ()
#14	0x0000000105bde5e8 in _dispatch_lane_serial_drain ()
#15	0x0000000105bdf394 in _dispatch_lane_invoke ()
#16	0x0000000105be0b20 in _dispatch_workloop_invoke ()
#17	0x0000000105bec5f0 in _dispatch_root_queue_drain_deferred_wlh ()
#18	0x0000000105bebc00 in _dispatch_workloop_worker_thread ()
#19	0x000000020dfefc7c in _pthread_wqthread ()
#20	0x000000020dfec488 in start_wqthread ()

Hi there, are you still experiencing this issue on the latest SDK version?


GrafanaDatasource periodic resync does not work when WATCH_NAMESPACES=""

Hi, thanks for the great project!
We've encountered an issue where our GrafanaDatasource resources often are often missed by the controller. We apply the operator Deployment and the GrafanaDatasource resources together, and I imagine there is a race when the operator starts causing the datasource to be missed. The operator will create the grafana-datasources configmap, but will not populate that configmap with any datasource data.
This is usually fixed by the periodic reconcilers built in to operators, however this reconciler doesn't seem to work when WATCH_NAMESPACES="" is set on the operator.  When this is set, we see the operator logging:
{"level":"info","ts":1587040706.1083543,"logger":"controller_grafanadatasource","msg":"running periodic datasource resync"}
{"level":"info","ts":1587040706.1084628,"logger":"controller_grafanadatasource","msg":"no datasources configmap found"}

despite the datasource configmap existing:
» kubectl get cm grafana-datasources -o yaml -n foo
apiVersion: v1
kind: ConfigMap
metadata:
  annotations:
    last-config: ""
  creationTimestamp: "2020-04-16T13:04:00Z"
  name: grafana-datasources
  namespace: foo
  ownerReferences:
  - apiVersion: integreatly.org/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: Grafana
    name: grafana
    uid: d628a368-976c-4af9-acd6-502079a698d4
  resourceVersion: "108672"
  selfLink: /api/v1/namespaces/foo/configmaps/grafana-datasources
  uid: 2a3417c1-de9f-43c5-b235-abb99f5bf80d

My guess is that this is caused by WATCH_NAMESPACES="" setting the namespace to "", which is used when checking if the grafana-datasources ConfigMap exists: https://github.com/integr8ly/grafana-operator/blob/674aca8f3fe8333eae37a982abc551355c87d163/pkg/controller/common/dataSourcesState.go#L53
This only breaks the periodic resync, as single-resource reconciliation will have the namespace explicitly set by the caller.

closing as this appears to not be supported: https://github.com/integr8ly/grafana-operator/blob/master/documentation/multi_namespace_support.md#support-for-multiple-namespaces


[PORT] Add community docs

Port this change from botbuilder-dotnet/master branch:
https://github.com/microsoft/botbuilder-dotnet/pull/4067

Fixes #4065
Adds;

Code of conduct doc (link to MS Community code of conduct)
Contribution guidelines
PR template

Already addressed. Closing.


[5.1] Add multiple key support to the forget() method for Collections

As discussed with @taylorotwell in Larachat/#internals, currently in Collections you can only forget() a single key: $collection->forget('key'); this PR adds the ability to also specify an array of keys to forget, $collection->forget(['foo', 'baz']); without breaking if just a single string/key is provided.
Multiple Forget:
$collection = new Collection(['name' => 'taylor', 'foo' => 'bar', 'baz' => 'qux']);
$collection->forget(['foo', 'baz']);

Results In:
>>> $collection->all();
=> [
       "name" => "taylor"
   ]

Single Forget (default 5.1):
$collection = new Collection(['name' => 'taylor', 'foo' => 'bar', 'baz' => 'qux']);
$collection->forget('foo');

Results In:
>>> $collection->all();
=> [
       "name" => "taylor",
       "baz"  => "qux"
   ]

Does the doc block need to be adjusted?

@taylorotwell Oops, missed that one. I have updated the docblock accordingly.

@GrahamCampbell :+1: I have updated it to your recommendation.


Inspect pages

This PR adds the following inspect pages:

Volume Inspect
Network Inspect
Account Inspect
Image Inspect

I've also re-worked the navigation to the left as it was too cramped at the top, still some more styling changes that need to be done later.

/cc @ehazlett @cloutiertyler

Looking good!
I don't see the welcome screen -- should I?  Also I'm getting an error on the services view:

I will merge since this branch is a WIP.  Just wanted to give feedback.  Thanks!


proposal: add condition and tags fields to requirements entries

Problems

Currently there is no simple way to selectively enable/disable sub-charts. This limitation makes composing with charts (e.g. choosing from more than one type of db) difficult and spawns workarounds such as template wrapping.
Currently there is no simple way to selectively install groups of sub-charts. This limitation makes composing with charts (e.g. installing a minimal 'compute-kit' subset of charts ) more difficult.

Note: Both are addressed here because they operate similarly and likely need changes in the same place in the code. Also, Tags would likely depend on the chart's 'enabled' status.
"Condition" field
The conditional field attempts to solve problem 1.
Add an optional field "condition" to chart.yaml and requirements.yaml entries. The value of this field would be a YAML path in dot notation (e.g. mariadb.enabled). The YAML path is then looked up in the parent charts values and if found with a value of false (actual false, not just falsy) the relevant chart is not loaded. If the path does not exist or is not explicitly false, the chart is loaded as normal.
# parent/requirements.yaml
    dependencies:
       - name: subchart1
	  repository: http://localhost:10191
	  version: 0.1.0
	  condition: subchart1.enabled

# parent/values.yaml
    subchart1:
       enabled: false

In the above example, the chart 'subchart1' would NOT be loaded since its condition value exists in the parent's values and returns false.
"Tags" field
This attempts to solve problem 2.
Add an optional field "tags" to chart.yaml and requirements.yaml entries. The value of this field would be a YAML list of one or more "tags".
# parent/requirements.yaml
    dependencies:
      - name: subchart1
        repository: http://localhost:10191
        version: 0.1.0
        condition: subchart1.enabled
        tags:
          - front-end
          - subchart1
      - name: subchart2
        repository: http://localhost:10191
        version: 0.1.0
        condition: subchart1.enabled
        tags:
          - back-end
          - subchart2

In values.yaml, "tags" field is introduced as a new top level key. The value of this key contains key/value pairs or a YAML list which specifies which groups of charts should be enabled/disabled based on their tag. Two possible approaches to formatting tags in the values.yaml are listed below.
# parent/values.yaml

# switch-like
tags:
  front-end: true
  back-end: false

# list-like
tags:
  - front-end

In the above "switch-like" example, all charts containing the tag "front-end" would be installed and those containing the "back-end" would not. In case of conflict, the "condition" value wins over "tags" which allows a group to be enabled (e.g. all "front-end" charts) and allows one or more unnecessary sub-charts in that group to be disabled or vice-versa.
Some problems like how to resolve conflicting tags still need discussion.
Additionally the tags could be specified as a special set parameter using the CLI
# using the command line
helm install --set tags.front-end=true,tags.back-end=false

Complex use cases with condition logic
To achieve very complex use cases where sub-charts are re-used with different values within the same release, we should discuss the pros/cons of allowing the condition field to contain logic.
Logic in condition field options

follow a convention
a. given a list of yaml paths, use the first one that resolves
b. use a format like k8s labels, something like  - {key: environment, operator: NotIn, values: [dev]}
c. ?

allow TPL access, can access templates and template functions

run arbitrary golang >:)

Example complex use case
Two umbrella charts (who are themselves a member of a global umbrella) each have many sub-charts, some of which need to be enabled/disabled based on logical AND/OR of other keys. Furthermore, charts at any level can have more than one instantiation with different values.
charts
rootChart
-subchart1
--subchartA
---subchartZ (conditionally enable/disable from values)
---subchartY(enable if peer subchartZ is enabled and mykey is disabled )
--subchartB
-subchart2
--subchartA (disabled)
--subchartB (enabled with different values that other B chart)
---subchartZ (conditionally enable/disable from values)
---subchartY(enable if peer subchartZ is enabled and mykey is disabled )

@jascott1 Sorry this took a bit for me to get to. Just for clarification, are you wanting to choose one over the other or is this a proposal to implement both of them?

This is a proposal to implement both together. Im working on some complex use cases right now. Please share your thoughts. Thanks Thomas!

@jascott1 there is a discussion on this in #1568, although I'm not sure if you intended to create this issue to surface the proposal in https://github.com/kubernetes/helm/issues/1568#issuecomment-264145982?

Yes I created this to surface @syhol's idea and then tags were an idea added by @technosophos

I am in favor of this proposal. I think it very cleverly solves some real-world problems that have surfaced several times.
I have a few specific comments on specific issues you raised.
List vs Switch
Regarding _list vs. switch, I'm slightly in favor of switches because it does make it easy to manage. With lists, there's always a question of whether the intent is to replace the list or modify the list. With switches, you can deal with just one item at a time.
That is, say we have a chart with five tags, all of which are on by default. Turning off one tag feels easier with switch syntax: --set tags.foo=false. The list syntax would be --set tags={bar,baz,blarg,zap} (or, turning on all the tags that aren't foo).
Analogously, when merging two YAML files (values.yaml and -f myvals.yaml), it's much easier to merge switches:
Values.yaml:
tags:
  foo: false
  bar: false
  baz: true
  zap: true

myvals.yaml:
tags:
  baz: false
  bar: true

Seems like the expected output is pretty simple to compute:
tags:
  foo: false
  bar: true
  baz: false
  zap: true

But, truth be told, we could make either work.
Conditions
I wouldn't mind punting on conditions initially, but if we added them, I think I would suggest ruling out sending values YAML files through the template engine. It gets pretty confusing for users to understand multiple template runs, and which runs have which values available to them.
I like keeping in mind some available options for this.
Nested charts
One thing we will need to decide is how to handle scoping for nested charts. Do we treat the tags object like global and pass it down unmodified to children? Or do we try to scope tags the same way we scope regular values?
With conditions, I'm a little concerned about how we would resolve these relatively. Say we have this graph:
mychart/
  - charts/
    - worker1/
      - charts/
        - mysql/
    - worker2/
      - charts/
        - mysql/

In the chart above, we have two instances of MySQL being created -- one for worker1, and one for worker2. How do we disable worker1's MySQL without disabling worker2's? How does that look at the top level (e.g. in mychart/values.yaml) versus in the subchart (mychart/charts/worker1/values.yaml)?
Looking forward to adding this feature. I think it's going to be really helpful.

Two thoughts. Kolla-kubernetets is using a nested value sturcture now to make it easy to set a value more generically and hit a bunch of subcharts, and then set values more specifically to affect fewer.
This ends up with a search path like:
if defined at Values.foo, use that.
if defined at globals.kolla.mysubchart.foo, use that.
if defined at globals.kolla.allcharts.foo use that.
So it would be nice if the conditional value to lookup, was at least a list, with this same behavior.
I can see some strong benifit to being able to call out to macro's to use for the conditionals. Users could then use the same logic inside the templates as in the conditionals. It may or may not require some real heavy lifting in the engine though. not sure how it is architected currently.
As for whether subcharts get the parents values or not, raw, I think currently I'd like to see it not. but I could see some cases where it should... so kind of a hard thing to decide... Perhaps it should be a field in Charts.yaml and support both ways? Then it can be set as needed per chart.

@technosophos By using globals we have been able to create nested values structure that results in the following except I have added the enabled and rabbitmq properties (but they are doable).
COMPUTED VALUES:
global:
  kolla:
    all:
      kubernetes_entrypoint: true
      rabbitmq:
          all:
              port: 5672
              mgmt_port: 15672
          ...
    neutron:
      enabled: true
      # this is optional
      rabbitmq:
          all:
              port: 5672
              mgmt_port: 15672
          ...

To @kfox1111 's point, we could check global.neutron.rabbitmq and then fallback to global.kolla.all.rabbitmq by using a list of those YAML paths as the condition. We are already doing this using gotpl. To implement that now we would need to consider the future use and if we are ok with assuming a condition field containing a list will be treated this way (first one that exists wins). It might be a good start and allow us to add functionality later.

So in the condition field, , would be treated as an OR?
This is the situation I was thinking about when I suggested that we might want some operators, since I could also imagine someone wanting to specify an AND or NOT condition there. And maybe it would be as simple as considering ',' to be OR, '^' to be NOT ('!' is a control character in YAML), and '&' to be AND.
One thing to keep in mind as we design this: At the time that we have to evaluate the conditions on the requirements.yaml file, we will have only the following pieces of information available to us:

The merged contents of -f and --set
The files in the top-level chart, including values.yaml

Globals, for example, can't be fully populated until after we've figured out which charts to include. So only the globals in the top-level chart would be available in this context. (That's not a show stopper at all -- just wanted to point out that some users could get confused by this).

@technosophos Good point about globals. Also I like the simple logic operator idea. Here are some examples
condition: ke1,key2^key3

key1 exists OR key2 exists AND NOT key3

condition: key1&key2,key3^key4

key1 AND key2 exist OR key3 AND NOT key4

condition: ^key1,key2

NOT key1 exist OR key2 exist

condition: key1,key2,&key3

the ,& above should throw error imo

In my original work, loading a chart is only skipped when the path exists and value is actual false. This means unless explicitly disabled, charts always load. Now though if we have above logic, a condition such as "^key1" (NOT key1) would mean what if key1=true in values?

@jascott1 With that third example, it would probably be clearer to require parens. So ^(key1,key2). As you have it written, it seems like NOT key1 exists or key2 exists

@technosophos: What I was suggesting is something different then an or for ','
Say you have these values:
globals:
kolla:
all:
enabled=true
mythingIcareabout:
enabled=false
ordering the list like:
globals.kolla.mythingicarabout.enabled,globals.kolla.all.enabled
I want the value of mythingicareabout to be the value, as it exists. if its true or false, thats the value if it exists.
If the entry is not defined at all, then it consideres the value of globals.kolla.all.enabled next.
Neither and, or or, has that behaviour. Does that make sense?

@thomastaylor312 I did mean "NOT key1 exists or key2 exists" as an example to think thru. kfox1111 and others have also suggested parens, what do you think this style?
(global.a,global.b)&(global.c)
global.a OR global.b result AND global.c

@kfox1111 not sure im getting you on last comment. what you said is the same as how we've been defining OR.
globals.kolla.mythingicarabout.enabled,globals.kolla.all.enabled
use first if it exists else use second if it exists

so, or would be first defined value, not the logic, true if a or b is true? What if someone wanted a logical 'or' operator?
I'm a little worried this will turn into its own language all on its own. would it be better to just use a gotl macro? Then we can reuse the whole gotl engine for logic.

@kfox1111 Right, OR on key existence not key value was the original idea. Maybe shows some of the confusion we might get when users try to grok it. Im also worried about the increase in complexity. By  "What if someone wanted a logical 'or' operator?" i take you mean operate on the value. If we start down that road then we would have to discuss "truthiness/falseness". ( in a "post truth" era :)
YAML has a false so the original idea was that charts are enabled unless a specific path exists and is explicitly false. Then charts that have conditions could be used independently ignoring the condition altogether if no keys existed with false. Now we are talking about a more conventional (and intuitive) 'end result of combining a bool-ish expressions' so using a condition at all becomes more invasive.

@technosophos Although the tpl approach has those downsides you mentioned is it possibly the lesser of two evils for conditions here? We don't have to invent/write/preach another system and tpl is documented and full featured (we are already using it for conditions).
Tags: I think we want nested tags for the complex use case and it seems like we could re-use the nested globals approach, is that the case?

re: Tags
Anyone have any problems with the following statement:
"A chart will be loaded if at least one of its tags evaluates to true, unless overridden by a condition which evaluates to false"
#requirements.yaml
dependencies:
      - name: subchart1
        condition: subchart1.enabled
        tags:
          - front-end
          - subchart1
      - name: subchart2
        condition: subchart2.enabled
        tags:
          - back-end
          - subchart2

# values.yaml
tags:
  front-end: true
  back-end: false
  subchart2: true

In above example subchart2 chart is effectively enabled since the "subchart2" tag is true despite its other tag "back-end" being false. If the condition "subchart2.enabled" evals to false then the chart would NOT be loaded no matter what its tags are set to.

The above PR #1917 introduces basic functionality for tags and conditions, each of which is in its own function. If we are happy with the approach it should be easy to add more advanced processing. Currently for conditions it only does 'first valid path wins' from comma delimited list of YAML paths. For tags, only the top parent's values is considered and only the root key "tags:". Tags under "globals:" are not implemented.

Also, only requirements.yaml is searched for tags and conditions, Chart.yaml is not currently used (a change from original implementation). If requirements.yaml is supposed to represent developer intent (version choice etc) then it seems appropriate to only use that file and leave chart alone.


Add possibility to use a downloaded nextcloud archive and copy on rem…

…ote host. This is useful for setting up config or when installing on multiple machines, because it avoids multiple downloads.

On my compiter, ansible-lint does not throw any error. Also, I have tested all variants and it worked. Changes to code are very view only, thus should not show any issue.

On my computer, ansible-lint does not throw any error. Also, I have tested all variants and it worked. Changes to code are very view only, thus should not show any issue.

Hello there
there is an issue with the github action docker setup. not sure if it comes from github  or our GA config

Thanks for clarifying @aalaesar. Good to know that this is not an issue on my end.


Call decorator strategies on cursor position change

Do you want to request a feature or report a bug?
Feature
What is the current behavior?
Decorator strategies are only called on ContentState change, not EditorState change.
What is the expected behavior?
I'd like the decorator strategies to be called also when the cursor moves position, since I'm trying to make a 'bracket highlighter' decorator, which is dependent not only on the text content but also on the cursor's position.
Which versions of Draft.js, and which browser / OS are affected by this issue? Did this work in previous versions of Draft.js?
0.10.3, Chrome 72.0.3626.119, Win10. It's probably never worked, not sure.

Accepting the issue. Has the same annoying trouble while trying to highlight words over collapsed selection state in a decorator


Tomcat memory leak

[x] Implement code
[x] Update documentation in code as comment
[x] Update CHANGELOG.md

Jenkins run the tests

Jenkins run the tests please

Jenkins run the tests

Closing. Seems to be messed up with prior commits, not trigerring CI.
Opened #804 instead.


Separate usages of "math/rand" and "crypto/rand" in single Go file using package alias

This commit refactors a single Go file to differentiate between the usage of "math/rand" and "crypto/rand". A package alias, "crand", is introduced exclusively for importing "crypto/rand". This separation is employed due to the superior implementation of the "read" function in "crypto/rand".

Bit confused about the intent here, all the rand.Read() calls are in tests, and usually seeded with a timestamp. I think the timestamp seeding is useful to potentially replicate test runs if needed, thouugh I don't think we've used that so far.
FWIW, the only use of crypto/rand I see in the repo is here: https://github.com/lightninglabs/taproot-assets/blob/4f22232d8a972e6b866b4fe5822d8598fb297c4e/tapdb/macaroons.go#L145
Which could be replaced with rand.Read(rootKey).

CI run approved.

Won't use crypto/rand in test helpers now since we've added deterministic test vector generation, so closing this.


Tensor bool

Pull Request type

Please check the type of change your PR introduces:

[ ] Bugfix
[v ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

I worked on the bool tensor type implementation
Issue Number: 406
What is the new behavior?

Added the Bool Tensor Type
Added at operator test for Bool Tensor
Added stride operator test for Bool Tensor

Does this introduce a breaking change?

[v ] Yes
[ ] No

Other information
To proceed to implement the not operator, I need review on this pr. Apologies, I think I commited also for not which is not suppose to be on this pr.

@all-contributors add @Ephraim-nonso for code


Views

In this milestone

implemented the design as given in the wireframes,
populated the database with data that is being displayed in the view, and
checked and verified that pages were rendering accordingly.

@rloterh Thank you for the review, I tried to check on the error so I can fix it but I did not get any error of such can you please put me through how you encountered the error

@rloterh Thank you for the review, I tried to check on the error so I can fix it but I did not get any error of such can you please put me through how you encountered the error

Hi @Tobby8629
This error occurred during a process of running migration.
I've checked thoroughly and same error still surface.
The only configuration changes I made during setup was to change the ruby version used from 3.2.1 to 3.2.2, perhaps might be cause of the error on my side.
I'm however glad that your project has been successfully approved! 👏 👏
Cheers! 😃

Thank you very much for looking into it, I will take note next time


fix: Always wrap string passed to slot in a helper component

I've originally encountered this issue while porting bootstrap-vue to Vue3
All known (at least to me and in mentioned stack overflow :stuck_out_tongue: question) methods of checking if something is HTML reports false for <col><col><col> because <col> is considered valid tag only inside table -> colgroup
In order to fix that I simply removed check if it is HTML and always wrap slot provided as string into <SlotWrapper>
This has a downside - if code under test relies on knowing that slot will always have raw strings - it will be confused by wrapper. User could workaround it with passing slot as function:
slots: {
  'some-slot': () => h('Something which should be just plain old string')
}

I consider this way more rare case, and what is more important - people who manipulate slot contents in that way are usually far more expert to understand the root cause of the issue and to discover (or find this PR) workaround.
For original issue - it took me a while to realize why slot work for certain HTML string and does not work for another when the only difference is tag

isHTML was introduced here: https://github.com/vuejs/vue-test-utils-next/pull/599 I am surprised this did not break one of those tests.
This would technically be a breaking change (at least for existing V2 users). Any chance you could write something I can include in the release notes explain the breaking change and how to work around it? Just a paragraph with a snippet or two would be great.

This would technically be a breaking change (at least for existing V2 users). Any chance you could write something I can include in the release notes explain the breaking change and how to work around it? Just a paragraph with a snippet or two would be great.

Well, I'm not sure this is a breaking change. For me it feels more like a fix for perfectly valid use case:
 it('allows passing a scoped slot via string with no HTML inside without template tag', () => {
      const wrapper = mount(ComponentWithSlots, {
        slots: {
          scoped: 'Just a plain {{ params.aBoolean }} {{ params.aString }}'
        }
      })

      expect(wrapper.find('.scoped').text()).toEqual('Just a plain true string')
    })

I've added this test in a recent commit.
WDYT of something like:
Note: if you're passing raw strings to a slot of the component - these are now always wrapped into helper component (previously wrapping occurred only if string contained HTML. If your component relies on raw string being passed to slot without any specific wrappers, pass render function to slot content wrapping your string in h():
 it('allows passing a scoped slot via string with no HTML inside without template tag', () => {
      const wrapper = mount(ComponentWithSlots, {
        slots: {
          // this one will be wrapped with helper component
          scoped: 'Just a plain string',
          // this one will be passed to slot as plain string
          otherScoped: () => h('Just a plain string'),
        }
      })

      expect(wrapper.find('.scoped').text()).toEqual('Just a plain true string')
    })

Feel free to edit this for making most easy-to-understand description

@lmiller1990 Ignore my explanation, if https://github.com/vuejs/vue-test-utils-next/pull/844 this will effectively hide any "slot wrapper" stuff from end users, making this explanation wrong and unneeded

Do we still need this or will #844 take it's place?


doc/UI: update instructions for enabling the UI

The UI is now part of the stable snap, but it must be explicitly enabled.

Documentation preview available at: https://linuxcontainers.org/lxd/docs/pr.11751/


Method for Move Range Visualization

Moves as viewed in the menu only have short descriptors and some require some experimentation to fully understand their ranges.  Add an option to preview the range of a move somewhere.

Visualization of move targetting can be added using tile-highlighting like the Turn button.

https://github.com/RogueCollab/RogueEssence/commits/master


InvalidDifficultyThreshold?

Error
only called after inserting a block

Metadata

key
value

version
1.0.0-alpha.16+968.gd1430fd

Zcash network
Mainnet

state version
25

branch
komodo

git commit
d1430fd

commit timestamp
2022-10-06T14:19:35Z

target triple
x86_64-unknown-linux-gnu

build profile
debug

location
zebra-state/src/service/non_finalized_state.rs:312:14

SpanTrace

SpanTrace:
   0: zebra_state::service::state
             at zebra-state/src/service.rs:609
   1: zebrad::components::sync::obtain_tips
             at zebrad/src/components/sync.rs:508
   2: zebrad::components::sync::try_to_sync
             at zebrad/src/components/sync.rs:433
   3: zebrad::components::sync::sync
             at zebrad/src/components/sync.rs:400
   4: zebrad::application::
           with zebrad="d1430fd" net="Main"
             at zebrad/src/application.rs:397

Block before:
2022-10-06T23:40:16.895241Z  WARN {zebrad="d1430fd" net="Main"}:sync:try_to_sync: zebrad::components::sync: error downloading and verifying block e=Invalid { error: Block(Commit(CloneError { source: CommitBlockError(InvalidDifficultyThreshold { difficulty_threshold: CompactDifficulty(0x1d01fe5b, Some(ExpandedDifficulty("00000001fe5b0000000000000000000000000000000000000000000000000000"))), expected_difficulty: CompactDifficulty(0x1d017a62, Some(ExpandedDifficulty("000000017a620000000000000000000000000000000000000000000000000000"))) }) })), height: Height(3025602), hash: block::Hash("0000000078426135b855b0fdb62fb8bfb7d2faf801340b79cf0cf1c35b935f3c") }

Block: #3025602
0000000078426135b855b0fdb62fb8bfb7d2faf801340b79cf0cf1c35b935f3c
0000000078426135b855b0fdb62fb8bfb7d2faf801340b79cf0cf1c35b935f3c
00000001fe5b0000000000000000000000000000000000000000000000000000 - difficulty_threshold
000000017a620000000000000000000000000000000000000000000000000000 - expected_difficulty

The reason for this error is that PRE_BLOSSOM_POW_TARGET_SPACING param currently set for zcash as 150 should be changed to 60 sec for komodo

Also, I reverted difficulty stub commit, will test sync from scratch now.


POST is not working for relations authorized account

Hi, yesterday I started geting error on POST message on following request.
I was authorized my account's token with this kind of url (as you can see there is relationships at the end):
https://api.instagram.com/oauth/authorize/?client_id=44e6baf1dc5d45a082cae725ffa2f36d&redirect_uri=http%3A%2F%2Freveal-it.appspot.com%2Foauthtest&response_type=code&scope=comments+likes+relationships
I'm using this nearby month, it was okay early and I didnt changed a bit.
Here is an error stacktrace:

org.jinstagram.exceptions.InstagramBadRequestException: APIError: This client ID is not permitted to POST relationships actions.
at org.jinstagram.entity.common.InstagramErrorResponse.throwException(InstagramErrorResponse.java:44)
at org.jinstagram.Instagram.handleInstagramError(Instagram.java:977)
at org.jinstagram.Instagram.createInstagramObject(Instagram.java:941)
at org.jinstagram.Instagram.setUserRelationship(Instagram.java:484)
at com.nebula.insta.classes.InstagramInstance.followTo(InstagramInstance.java:507)
at com.nebula.insta.app.App.start(App.java:203)
at com.nebula.insta.app.App.main(App.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)

I've tested it with 1.1.3, 1.1.4 and 1.1.5-SNAPSHOT versions - both my accounts have same error.

It looks more of a client specific error. Can you create a new client and try it out ?

I've tried it with a new account, I got this error :

But I have already created a token with relationships scope like that :
InstagramService service = new InstagramAuthService()
.apiKey(clientId)
.apiSecret(clientSecret)
.callback(callbackUrl)
.scope("comments likes relationships")
.build();

@Ariloum @sachin-handiekar
As far as I am aware, POSTing comments / likes and relationships requires special permissions on the client given by Instagram as stated in their docs here and this is the form to request POST permissions.
Regards

Closing the ticket... Re-open if needed


[Enhancement][Cherry-Pick][Branch-3.1] Improve credential mask util

cp #29615
What type of PR is this:

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.1
[ ] 3.0
[ ] 2.5
[ ] 2.4

[FE Incremental Coverage Report]
:heart_eyes: pass : 44 / 48 (91.67%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/server/GlobalStateMgr.java
0
1
00.00%
[2866]

:large_blue_circle:
com/starrocks/credential/CredentialUtil.java
42
45
93.33%
[28, 96, 105]

:large_blue_circle:
com/starrocks/credential/azure/AzureCloudConfigurationFactory.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/qe/ShowExecutor.java
1
1
100.00%
[]

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)


Missing required sign_message method

Purpose
Add sign_message when connect
Changes
sign_message to methods
Checklist

[ x] My code follows the style of this project.
[ x] The code compiles without warnings.
[ x] I have performed a self-review of the changes.
[ x] I have documented my code, in particular the intent of the
hard-to-understand areas.
[ x] (If necessary) I have updated the CHANGELOG.

By submitting the contribution I accept the terms and conditions of the
Contributor License Agreement v1.0

link: https://developers.concordium.com/CLAs/Contributor-License-Agreement-v1.0.pdf

[ x] I accept the above linked CLA.

Hi @lunguyenhat thank you for the contibution! Could you also add a line to the changelog (i.e. a ### Changed item under ## [Unreleased])? Thanks.

Hi @lunguyenhat thank you for the contibution! Could you also add a line to the changelog (i.e. a ### Changed item under ## [Unreleased])? Thanks.

I did

@lunguyenhat this has just been released as v0.2.1 of both @concordium/wallet-connectors and @concordium/react-components. Sorry for the delay.


Update/remove broken links

Description
Resolves nightly link check failures. Both affected services are deprecated, so since I couldn't find a suitable replacement for the link in azure-ai-anomalydetector, I removed the link and "Next steps" section of the samples README.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

/check-enforcer override


breadcrumbs test fails as the site root is not returned

calling http://localhost:8000/@breadcrumbs
response is:
{
"@id": "http://localhost:8000/@breadcrumbs",
"items": []
}
calling http://localhost:8000/news/@breadcrumbs
response is:
{
"@id": "http://localhost:8000/news/@breadcrumbs",
"items": [
{
"@id": "http://localhost:8000/news",
"title": "News"
}
]
}
the first element representing the site is missing.

Fixed in master, thanks for the issue!


Added __system_property_get calls to replace getprop calls.

Fixed sysinfo_ffi for android.
Replace all calls to getprop command with __system_property_get calls from ffi.
Added bindgen for sys/system_properties.h
Added build_android() function.

Performance increase around ~70ms

Old
~Performance increase around 50ms~ ~screenshot~

The call to pm list packages is what takes a lot of time (~50ms).

The CPU info of android could be better.

I do think CPU information on android isn't as descriptive as I'd like it to be, but there's a slight annoyance, if we append the contents of hardware to the existing string, we're going to potentially have a string that is just too long, for no reason.
We might have to do some replacing.
Also I'm thinking of making relative shell path the default, what do you think?

Great work!
70ms improvement is truly a wonderful improvement, I can't wait to see how low we can get it.
I do think CPU information on android isn't as descriptive as I'd like it to be, but there's a slight annoyance, if we append the contents of hardware to the existing string, we're going to potentially have a string that is just too long, for no reason.
We might have to do some replacing.
Also I'm thinking of making relative shell path the default setting, what do you think?

Thanks,
Yeah I was thinking of replacing
ARMv8 Processor rev 4 (v8l) (8)  with something like Qualcomm Technologies, Inc SDM636 (ARMv8) (8).
Yeah the shell path on termux is unnecessarily long. I haven't tried the relative setting yet so I can't say but something like
fish (3.2.1) could also work.

Yeah I was thinking of replacing ARMv8 Processor rev 4 (v8l) (8) with something like Qualcomm Technologies, Inc SDM636 (ARMv8) (8).

Brilliant, I'd love to see this too.

Yeah the shell path on termux is unnecessarily long. I haven't tried the relative setting yet so I can't say but something like fish (3.2.1) could also work.

All is good until you mentioned 3.2.1, which is sort of something we have struggled to obtain since day 1, we can't access say, $ZSH_VERSION or $BASH_VERSION, trying to get these values results in empty strings.
The reason behind this is stated somewhere in the Rust docs, but it's something along the lines of, "the program isn't actually running in a shell" or something.

Also most stuff has SELinux permissions so It can't really be manually read.

Sh*t

Would you like to continue improving this or shall I merge?

I was thinking more like fish -v
Performance impact should be minimal
❯ hyperfine 'fish -v'
Benchmark #1: fish -v
  Time (mean ± σ):       3.2 ms ±   0.2 ms    [User: 2.5 ms, System: 1.4 ms]
  Range (min … max):     2.7 ms …   4.2 ms    485 runs

  Warning: Command took less than 5 ms to complete. Results might be inaccurate.

Would you like to continue improving this or shall I merge?

I'll have to make the /proc/cpuinfo change. Then I'll ping you to merge.

fish => fish -v

3ms is kinda significant unfortunately, and the problem with this approach is we have to parse the -v output, which is different across shells, bash for example likes to print way too many things when invoked with -v.

Added fallback to cpu model
I also bumped the version to 0.2.9

Added fallback to cpu model
I also bumped the version to 0.2.9

We might need another fallback, that is "Processor" with a capital P, as I don't have "cpu model" in there.

Haha I'll add a fallback to that too.

There's no reason to test if var.is_none() because they're initially none, we need to use else if rather than if, too.

Oh yeah I just copy pasted that since cpu model might appear multiple times so I'd like to avoid initializing them multiple times .
I'll remove the is_none for hardware and Processor since they appear once and add else if

Also while testing I just realized that the android ascii art legs are asymmetric and its really bugging me lol.

Feel free to fix it :)

@grtcdr You can merge it if you feel it's ready.

I don't see a reason to use header files, __system_get_prop is already in libc.

If I try to use __system_property_get from libc it doesn't compile.
libmacchina on  main [!] is 📦 v0.2.9 via 🦀 v1.53.0-nightly took 36s
❯ cross build --target=aarch64-linux-android --release
   Compiling libmacchina v0.2.9 (/project)
error[E0432]: unresolved import `libc::__system_property_get`
 --> src/android/system_properties.rs:5:5
  |
5 | use libc::__system_property_get;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `__system_property_get` in the root

error: aborting due to previous error


Added  better error for PubSubRouter when accessManager is denying th…

Added  better error for PubSubRouter when AccessManager is denying the access

Coverage decreased (-0.1%) to 75.033% when pulling 4476d48d078d6048cf7b6399a0511a70e421980a on feature/guble-#27-use-accessmanager-inside-router-for-RW-operations into 8ec3c6a3b05b59034b7428935d6c349d0f456357 on master.


LayerGroup visibility change

When the visibility of a layer group changes, it switches off its sub layers, but no events are emitted on the sub layers. This seems wrong to me?
Or maybe this was by design somehow?

The sublayers state doesn't change, does it?

very true @marcjansen
okay, probably makes sense to handle this at the application level then ;-)

@marcjansen how did you handle this in the GeoExt 3 layer tree?
For instance you cannot have 1 sublayer visible and another one invisible, without having the layer group itself checked. This seems different from how other systems work? I thought in Ext the parent is only visible if all children are visible?

We're not really dealing with this properly right now. PR welcome :-)


Usage in typescript

How to use this package in typescript? I cannot found any types package related to this

Use @hugocxl/react-to-image instead.
Hope that helps


Layout Routes break route sorting

Describe the bug
When using layout routes the / path is not matched correctly. The first route with a path will be used, even if its path does not match and a matching route exists.
It appears that usage of layout routes between routes and root breaks the route sorting advertised in the docs
Your Example Website or App
https://stackblitz.com/github/xyng/ts-router-sorting-bug
Steps to Reproduce the Bug or Issue

Open StackBlitz Site
Compare Current Path with Current Matches. You will notice that /login is matched and rendered while the path is actually /
Swap lines 48 and 49. If layoutB is added before layoutA, the correct route / is matched.

Expected behavior
I expected that the layout-routes would be flattened and component-routes would be sorted as stated in the docs here (Web-Archive Link for future reference) and match the correct paths.
Screenshots or Videos
No response
Platform

OS: macOS
Browser: Chrome
Version: 112.0.5615.121 (arm64)
Router Version: 0.0.1-beta.83

Additional context
If you can give me a hint where that problem could be caused I'm happy to try help fixing it.

This is because your layoutA doesn't have component or you doesn't set default component on options. And it has been explain on the docs.
Documentation: https://tanstack.com/router/v1/docs/guide/routes#outlets
https://github.com/TanStack/router/blob/8d7f9e314a061cf9650fd64528fd679100669ebc/packages/router/src/react.tsx#L600

@Anjianto thanks for trying to help - but that is not the problem here.
The component for the layout routes was left out just to simplify of the reproduction.
Outlet is the default fallback (is seen in your linked code snippet).
and even if you would add a component: () =>
<Outlet />
 to the layout Routes the Problem persists.
This problem is about the routes not being flattened and sorted as described in the documentation (linked in issue).

This should be fixed as of beta-90


Kitties are breedable without owners' consent

The breed_kitty function does not ensure that the owners of the kitties are interested in breeding.
An attacker could breed two strangers' kitties and keep the offspring.

To me, this authorization check adds complexity where it is otherwise not very educational.

Good point. This is for teaching, not for production.

This was added as a stretch goal in https://substrate.dev/substrate-collectables-workshop/#/3/playing-our-game


[Feature] package resolution (1.x to 2.x dependencies)

This topic will help developers that have invested in .NET Core 1.x update their projects and dependencies to the .NET Core / .NET Standard 2.x dependencies.

@mairaw I'm closing this based on this doc Re-open if you don't think that covers what's needed.

That topic doesn't cover this subject but I'm not sure if we still need this. So I think it's fine to close it.


[TASK] Editable Output Text Fields

Description:
User can edit text fields that are pre-populated
Existing:
What is intended can be seen here from 3:06 to 3:35
https://dmp.deloitte.com/detail/video/6357136557112

@johbaxter I think this can be achieved through text field component where we have a default value which can be editable.


[WIP] feat(storage): compaction deterministic test tool

I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?
Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] All checks passed in ./risedev check (or alias, ./risedev c)

Documentation
If your pull request contains user-facing changes, please specify the types of the changes, and create a release note. Otherwise, please feel free to remove this section.
Types of user-facing changes
Please keep the types that apply to your changes, and remove those that do not apply.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note
Please create a release note for your changes. In the release note, focus on the impact on users, and mention the environment or conditions where the impact may occur.
Refer to a related PR or issue link (optional)

I quickly skim through the codes and I think the overall layout of the test suite looks good. Thanks for the PR.
Before diving too deep in the review, I noticed some potential issues in terms of implementation:

The logic to trigger a deterministic compaction is too intrusive, which increases the complexity and can easily affect the normal code path.
We only trigger one round of compaction after replaying one version delta. Since the size of one compaction task is bounded and L0 compaction is prioritized, we may end up only testing compaction in L0 on a small subset of the replayed data.
We only read from latest for correctness check and miss to check snapshot read. From the past experiences, bugs in compaction are more likely to affect snapshot read so it is better to also perform snapshot read to improve the test coverage.

To address 1) and 2), here are my thoguhts:

Avoid adding complexity in compaction scheduler (i.e. no side channel and finish channel) but add another types of manul compaction which just calls try_send_compaction_request to enqueue a compaction request.
Use a poll based mechanism to check the status of the compaction task triggered by manual compaction. We can use the RPC to list version delta or list compaction assignment to achieve this. Note that the list version delta or list compaction assignment RPC can also be useful for debugging in other cases and can be added into risectl tool.
Since we will auto trigger another round of compaction on completion of a compaction task (in report_compact_task_impl), it will introduce some nondeterminacy in the test. I think we can have a flag somewhere (e.g. in the compaction task) to mark whether we need to auto trigger compaction on completion. With this flag, compaction can only be manually triggered and the test suite can control when to trigger a compaction, how many rounds of compaction should be triggered after replaying a delta, and determine the concurrency.

We can also have an offline discussion.

Because we need to check that the data is correct after compactions.  So the basic requirement for the test tool is to aware that compaction tasks triggered by a specific request are finished.
Ideally, it would be better that we have a synchronous API for compaction triggering, when returns ok, it means all compaction tasks are done. I have some discussions with @zwang28 and he suggested that I can poll the current hummock version until its id becomes large to know that compactions have finished.
Unfortunately, this poll-based method is not reliable. Because try_send_compaction_request is actually a hint, the scheduler may not schedule tasks for a request (NoTask). If we poll after try_send_compaction_request, the program may become stuck. So I add the compaction_sched_status_rx to aware whether compaction tasks have been scheduled successfully.

Avoid adding complexity in compaction scheduler (i.e. no side channel and finish channel) but add another types of manul compaction which just calls try_send_compaction_request to enqueue a compaction request.

There are multiple places can trigger compactions (#5321) , If we don't mock up the original channel of compaction scheduler, how can we know that we are "polling" the compaction request issued by the test tool?

Unfortunately, this poll-based method is not reliable. Because try_send_compaction_request is actually a hint, the scheduler may not schedule tasks for a request (NoTask). If we poll after try_send_compaction_request, the program may become stuck. So I add the compaction_sched_status_rx to aware whether compaction tasks have been scheduled successfully.

After try_send_compaction_request is triggered, we can wait for some time (e.g. 5s) and poll both compaction task assignment and version delta. If none of them has changed, we are almost 100% sure there is no task triggered because the test tool manual trigger is the only trigger for compaction and there is no contention. Even if the judgement is wrong (i.e. the task is assigned after finish waiting for 5s), it doesn't affect the effectiveness of the test because we are just missing one check and will not affect the test tool result. Therefore, I think this approach is accetable.

There are multiple places can trigger compactions (https://github.com/risingwavelabs/risingwave/issues/5321) , If we don't mock up the original channel of compaction scheduler, how can we know that we are "polling" the compaction request issued by the test tool?

In order to make compaction controllable and deterministic, we need to make the test tool the only trigger for compaction no matter which implementation we choose. In terms of how to make the test tool the only trigger, we can:

Disable the timer trigger, which is easy since we can set the interval to a infinite number.
Disable the report compact task trigger, which is doable as I mentioned in my previous comment (i.e. via a flag).
commit epoch trigger is already disabled since it never happens.

Unfortunately, this poll-based method is not reliable. Because try_send_compaction_request is actually a hint, the scheduler may not schedule tasks for a request (NoTask). If we poll after try_send_compaction_request, the program may become stuck. So I add the compaction_sched_status_rx to aware whether compaction tasks have been scheduled successfully.

After try_send_compaction_request is triggered, we can wait for some time (e.g. 5s) and poll both compaction task assignment and version delta. If none of them has changed, we are almost 100% sure there is no task triggered because the test tool manual trigger is the only trigger for compaction and there is no contention. Even if the judgement is wrong (i.e. the task is assigned after finish waiting for 5s), it doesn't affect the effectiveness of the test because we are just missing one check and will not affect the test tool result. Therefore, I think this approach is accetable.

There are multiple places can trigger compactions (#5321) , If we don't mock up the original channel of compaction scheduler, how can we know that we are "polling" the compaction request issued by the test tool?

In order to make compaction controllable and deterministic, we need to make the test tool the only trigger for compaction no matter which implementation we choose. In terms of how to make the test tool the only trigger, we can:

Disable the timer trigger, which is easy since we can set the interval to a infinite number.
Disable the report compact task trigger, which is doable as I mentioned in my previous comment (i.e. via a flag).
commit epoch trigger is already disabled since it never happens during version delta replay.

After try_send_compaction_request is triggered, we can wait for some time (e.g. 5s) and poll both compaction task assignment and version delta. If none of them has changed, we are almost 100% sure there is no task triggered because the test tool manual trigger is the only trigger for compaction and there is no contention. Even if the judgement is wrong (i.e. the task is assigned after finish waiting for 5s), it doesn't affect the effectiveness of the test because we are just missing one check and will not affect the test tool result. Therefore, I think this approach is accetable.

IIUC, your point is that we can trade accuracy for less intrusive. Although the accuracy of the awareness of compaction will not affect the effectiveness of test tool, the overhead of the poll-based method should be concerned. If every compaction triggering needs to be waiting for 5s or even 1s, the overall runtime may not be acceptable.

Rounds of real compaction are triggered when running the test so the running time bottleneck should be the compaction duration, which usually takes tens of seconds (see the graph below of compaction duration when running nexmark Q7 in a 1CN-1compactor cluster). If we are concerned about the polling adding too much delay, we can poll more frequently (e.g. poll every 50ms and stop polling after 1s). IMO, We can expect in most cases the compaction task can be generated and assigned very quickly with less than 100ms since there is no contention.

In order to make compaction controllable and deterministic, we need to make the test tool the only trigger for compaction no matter which implementation we choose. In terms of how to make the test tool the only trigger, we can:

Disable the timer trigger, which is easy since we can set the interval to a infinite number.
Disable the report compact task trigger, which is doable as I mentioned in my previous comment (i.e. via a flag).
commit epoch trigger is already disabled since it never happens.

I think adding a flag everywhere we call try_send_compaction_request or relying on the assumption of some trigger being implicitly (as opposed to explicitly reflected in code) disabled is not very maintainable, because when try_send_compaction_request is called might change in the future, and we need to watch out for them.
So I'm thinking maybe we can add a parameter like ScheduleCause in try_send_compaction_request and set the filter on  CompactionRequestChannel to explicitly control which triggers we want to enable.

There are some conflicts introduced by my PR #5500, let me fix them.

Will the test tool still work if we restart the whole cluster (without cleaning etcd and S3) after data loading is done?

Yes. And we need to restart the cluster with full-compaction-test config and stop Meta committing new epochs.


Encodings are hard!

So we can't document (╯°□°)╯︵ ┻━┻ …

My reaction: (╯°□°)╯︵ ┻━┻
:P
We need to be able to document unicode emoji, because there are a lot of them

Yeah, I can't figure out how to get man(1) to display them properly, though. I'm sure there's a way. Maybe I'll email the authors of groff(1) and see what they say.


tensorflow.python.framework.errors_impl.AbortedError: Graph handle is not found

Actual behavior
Start universe-starter-agent with:
$ python train.py --num-workers 4--env-id flashgames.DuskDrive-v0 --log-dir /mnt/kube-efs/universe-perfmon/usa-flashgames.DuskDrive-v0-20170110-054801
  -m child

After about 40 minutes, one worker crashed with the error below.
This wasn't a case of restarting the worker, it had been running successfully and was on episode 21. It was running inside a fresh container (from universe-perfmon) so it can't be a case of connecting to the wrong parameter server.
Exception in thread Thread-10:
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/client/session.py", line 1021, in _do_call
    return fn(*args)
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/client/session.py", line 1003, in _run_fn
    status, run_metadata)
  File "/usr/lib/python3.5/contextlib.py", line 66, in __exit__
    next(self.gen)
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/framework/errors_impl.py", line 469, in raise_exception_on_not_ok_status
    pywrap_tensorflow.TF_GetCode(status))
tensorflow.python.framework.errors_impl.AbortedError: Graph handle is not found:<PHONE_NUMBER>00000d

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner
    self.run()
  File "/experiment/universe-starter-agent/a3c.py", line 92, in run
    self._run()
  File "/experiment/universe-starter-agent/a3c.py", line 101, in _run
    self.queue.put(next(rollout_provider), timeout=600.0)
  File "/experiment/universe-starter-agent/a3c.py", line 139, in env_runner
    summary_writer.add_summary(summary, policy.global_step.eval())
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/ops/variables.py", line 515, in eval
    return self._variable.eval(session=session)
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/framework/ops.py", line 575, in eval
    return _eval_using_default_session(self, feed_dict, self.graph, session)
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/framework/ops.py", line 3633, in _eval_using_default_session
    return session.run(tensors, feed_dict)
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/client/session.py", line 766, in run
    run_metadata_ptr)
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/client/session.py", line 964, in _run
    feed_dict_string, options, run_metadata)
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/client/session.py", line 1014, in _do_run
    target_list, options, run_metadata)
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/client/session.py", line 1034, in _do_call
    raise type(e)(node_def, op, message)
tensorflow.python.framework.errors_impl.AbortedError: Graph handle is not found:<PHONE_NUMBER>00000d

[2017-01-10 06:27:56,508] Received signal 15: exiting
I tensorflow/core/distributed_runtime/master_session.cc:891] DeregisterGraph error: Aborted: Graph handle is not found:<PHONE_NUMBER>00002c. Possibly, this worker just restarted.
[2017-01-10 06:27:56,601] Killing and removing container: id=e8bf782d91fa3d6e3bb685e37ed4f9622f054bfb281f1e1e61021f1ed6798a06

Versions
Linux 0c0c02f2bfdb 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6 15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Python 3.5.2
Name: universe
Version: 0.21.1
Summary: Universe: a software platform for measuring and training an AI's general intelligence across the world's supply of games, websites and other applications.
Home-page: https://github.com/openai/universe
Author: OpenAI
Author-email<EMAIL_ADDRESS>License: UNKNOWN
Location: /experiment/universe
Requires: autobahn, docker-py, docker-pycreds, fastzbarlight, go-vncdriver, gym, Pillow, PyYAML, six, twisted, ujson
---
Name: gym
Version: 0.7.0
Summary: The OpenAI Gym: A toolkit for developing and comparing your reinforcement learning agents.
Home-page: https://github.com/openai/gym
Author: OpenAI
Author-email<EMAIL_ADDRESS>License: UNKNOWN
Location: /experiment/gym
Requires: numpy, requests, six, pyglet
---
Name: tensorflow
Version: 0.12.1
Summary: TensorFlow helps the tensors flow
Home-page: http://tensorflow.org/
Author: Google Inc.
Author-email<EMAIL_ADDRESS>License: Apache 2.0
Location: /usr/local/lib/python3.5/dist-packages
Requires: protobuf, six, wheel, numpy
---
Name: numpy
Version: 1.11.0
Summary: NumPy: array processing for numbers, strings, records, and objects.
Home-page: http://www.numpy.org
Author: NumPy Developers
Author-email<EMAIL_ADDRESS>License: BSD
Location: /usr/lib/python3/dist-packages
Requires:
---
Name: go-vncdriver
Version: 0.4.19
Summary: UNKNOWN
Home-page: UNKNOWN
Author: UNKNOWN
Author-email: UNKNOWN
License: UNKNOWN
Location: /usr/local/lib/python3.5/dist-packages
Requires: numpy
---
Name: Pillow
Version: 4.0.0
Summary: Python Imaging Library (Fork)
Home-page: http://python-pillow.org
Author: Alex Clark (Fork Author)
Author-email<EMAIL_ADDRESS>License: Standard PIL License
Location: /usr/local/lib/python3.5/dist-packages
Requires: olefile

Aha, I see what went wrong. Not a tensorflow bug. I tried to kill the entire training session (4 workers plus a parameter server) but missed this one worker, which ran for about 10 more minutes before dying with this error.
The only indication of a problem in this one worker's logs is a start master session about 30 seconds after the parameter server died. Then 10 minutes later, it crashed.
I tensorflow/core/distributed_runtime/master_session.cc:993] Start master session 28ab4c2385610d79 with config:
device_filters: "/job:ps"
device_filters: "/job:worker/task:2/cpu:0"

So not really a problem. But maybe universe-starter-agent should periodically report the status of the cluster.


feat: add release conf test script

To test validity of release.conf, the script use rsync to fetch file list and test, and finally output a list generated.

用于检测 contributor 提交的 releases.conf 是否能够匹配镜像站的文件


[Feature Request] Create OnceLock and OnceCell using this library's Once

Since unlike Mutex, you can't specify which underlying Once to use with std::sync::OnceLock and std::cell::OnceCell, I would either have to roll my own, which seems wasteful and will not update when the std versions get changed, or manage the value and the Once separately like in the Once example, which is error-prone and puts the burden of upholding invariants on the developer

I would be happy to accept a PR for it, but it is not something I have time to work on myself.

I could try making a PR for it, but it will probably be almost entirely just a copy paste of the std implementation and just changing the import from std::sync::Once to parking_lot::Once, would that be any good?

That's fine.


Rename genericParameters to genericParameterClause for consistency.

Resolve #1678
Rename genericParameters of EnumDeclSyntax to genericParameterClause for consistency.
Since the existing genericParameters was declared public, we left it with the deprecated attributes. (If we don't need to keep it, I'll remove it.)

While working on this, I found a few more types that use genericParameters.
I renamed them all at once, if any further modifications are needed, please let me know.

@TTOzzi, you modified a lot of files that are generated using CodeGeneration. These changes will be reverted if you run CodeGeneration again (see https://github.com/apple/swift-syntax/blob/main/CodeGeneration/README.md).
What you need to do instead, is to modify the declaration of these types in the CodeGeneration package (in the CodeGeneration folder) and then run CodeGeneration as linked in the README I linked above.
As for the deprecated compatibility functions, can you add them to SyntaxCompatibility.swift?

Ah, I see! I didn't know there was such a convenient script!
I will make the changes again. Thank you for letting me know 🙇♂

Also, in case you haven’t done so already: Can you please make sure that swift-syntax builds without warnings locally?

The build is being successful without any warnings on my local. Is there anything else I should check?

@swift-ci Please test

@swift-ci Please test Windows

@swift-ci Please test Windows


Create MRCS

@Turtle1504 lib/domains/ca/bc/MRCS: this request has an incorrect file path format, please ensure that you are familiar with     this repository rules located at the bottom of this page and change     your request accordingly. If you don't know how to change request, close it and open a new one.     If you are not able to make the pull request according the instructions, please send us an email to<EMAIL_ADDRESS>Please mention this request URL in the message.

@Turtle1504 lib/domains/ca/bc/MRCS: this request has an incorrect file path format, please ensure that you are familiar with     this repository rules located at the bottom of this page and change     your request accordingly. If you don't know how to change request, close it and open a new one.     If you are not able to make the pull request according the instructions, please send us an email to<EMAIL_ADDRESS>Please mention this request URL in the message.

@Turtle1504 You might miss my previous comment. Please react.

@Turtle1504 lib/domains/ca/bc/MRCS: Your request has an incorrect file path format, please ensure the request follows     the repository rules set out at the bottom of this page and change     it accordingly or start a new one.     If you are unable to make a pull request with the instructions provided, please send an email to<EMAIL_ADDRESS>mentioning the URL of this request in the message.

@Turtle1504 Please react. Also, please provide us with:

the school official website URL, if different from the domain you are submitting
an URL of a page on the official website where an IT-related long-term (>1 year) course is offered by the school
an URL of a page or another proof (.pdf or a screenshot are OK) showing that the school recognizes the domain which you are submitting as an official email domain for the students.

@Turtle1504 lib/domains/ca/bc/MRCS: Your request has an incorrect file path format, please ensure the request follows     the repository rules set out at the bottom of this page and change     it accordingly or start a new one.     If you are unable to make a pull request with the instructions provided, please send an email to<EMAIL_ADDRESS>mentioning the URL of this request in the message.

@Turtle1504 lib/domains/ca/bc/MRCS: Your request has an incorrect file path format, please ensure the request follows     the repository rules set out at the bottom of this page and change     it accordingly or start a new one.     If you are unable to make a pull request with the instructions provided, please send an email to<EMAIL_ADDRESS>mentioning the URL of this request in the message.

@Turtle1504 lib/domains/ca/bc/MRCS: Your request has an incorrect file path format, please ensure the request follows     the repository rules set out at the bottom of this page and change     it accordingly or start a new one.     If you are unable to make a pull request with the instructions provided, please send an email to<EMAIL_ADDRESS>mentioning the URL of this request in the message.

@Turtle1504 I am sorry, this request remains unanswered for a while. I have to close it without merging. Please reopen and comment if you have an update regarding the aforementioned issue. Thank you for the understanding!


Shippable pipeline broken

The tag name change to "master-<8 char commit SHA>" introduced in Commit 55ae946 works fine and the image with the proper tag is pushed to the repository but the shippable pipeline doesn't pick it up properly. The deploy step (to test) fails when executing /home/shippable/micro/nod/stepExec/managed/deploy/run.sh and looking at the failed ECS tasks the error message is like this: "Status reason	CannotPullContainerError: Error: image front-end:master.2 not found". With the new tagging "master.2" does not exist anymore and instead it should use "master-<8 char commit SHA>".

I made it work by switching back from "TRAVIS_TAG" to "IMAGE_TAG" at the bottom of push.sh. That's obviously not what is intended but fixes the pipeline for now.
There are two more minor issues with the documentation for the ecs-weave-shippable deployment (here):

the step to commit the changes for the microservice-demo is missing (after changing the shippable.resource.yml file)

scope is not running automatically. I had to ssh in and start it to make it available on port 4040.


Session pages fixes

Fixed #8730
Fixed #8729
Fixed #8717
Fixed #8684
Fixed #1300
Fixed #8704
Fixed #8669
Fixed #8666
Fixed #8665
Added new spinner.
Fixed flexbox in header.
Changed form links color property (added the new one).
Made changes to show different style in normal user login and the organizations one.
Fixed css in login-related views, mainly error messages.
Changed text "Welcome to the CARTO Builder" in onboarding message.

CR @xavijam

Passing tests after latest merge. As it is not urgent, leaving it to @MariaCheca to merge on Monday (maybe after a CR if required).

It would be great if you can check it with me @piensaenpixel please ❤

@xavijam @piensaenpixel you can review!

Let's wait for organization background change please.

So looking fwd to this!

✨


Buggy Optimization of Simple Kernel using Shared Memory for Inter-Warp Communication

The following code produces wrong results when compiled with optimization flags other than -O0. Tested on ROCm 3.9 and 4.0, on gfx906 (AMD Mi50) and gfx908 (AMD Mi100) cards.
Compiled with disabled optimizations, that is hipcc -O0 code.cpp, the compiled code produces the expected output, while higher optimization levels (-O1 or higher) fail. Thus, we assume there is an error in one of the compiler’s optimization passes.
The bug was detected while debugging a GPU reduction code, where the same pattern was is for inter-warp/wavefront reductions.
On NVIDIA GPUs (directly compiled with nvcc -x cu code.cpp), the expected result is produced.
#include <iostream>
#include <numeric>
#include <vector>

#ifdef __CUDACC__
#define GPU(x) cuda##x
#else
#include <hip/hip_runtime.h>
using hipDeviceProp = hipDeviceProp_t;
#define GPU(x) hip##x
#endif

template <int BlockSize, int WarpSize>
__global__ void kernel(int const *__restrict__ in, int *__restrict__ out) {
  // one shared value per warp
  __shared__ int shared[BlockSize / WarpSize];

  // thread zero of each warp puts a value into shared mem
  if (threadIdx.x % WarpSize == 0)
    shared[threadIdx.x / WarpSize] = in[threadIdx.x];

  __syncthreads();

  // move result to global memory
  if (threadIdx.x < BlockSize / WarpSize)
    out[threadIdx.x] = shared[threadIdx.x];
}

int main(int argc, char *argv[]) {
  using namespace std;

#define CHECK(x)                                                               \
  if ((x) != GPU(Success)) {                                                   \
    cerr << "Error in " << #x << " on line " << __LINE__ << endl;              \
    return 1;                                                                  \
  }

  int device;
  CHECK(GPU(GetDevice)(&device));
  GPU(DeviceProp) props;
  CHECK(GPU(GetDeviceProperties)(&props, device));

  constexpr int block_size = 512;
  const int warp_size = props.warpSize;

  vector<int> a(block_size), b(block_size / warp_size);
  iota(begin(a), end(a), 0.0f);

  int *ad, *bd;
  CHECK(GPU(Malloc)(&ad, a.size() * sizeof(int)));
  CHECK(GPU(Malloc)(&bd, b.size() * sizeof(int)));

  CHECK(GPU(Memcpy)(ad, a.data(), a.size() * sizeof(int),
                    GPU(MemcpyHostToDevice)));

  switch (warp_size) {
  case 32:
    kernel<block_size, 32><<<1, block_size>>>(ad, bd);
    break;
  case 64:
    kernel<block_size, 64><<<1, block_size>>>(ad, bd);
    break;
  default:
    cerr << "ERROR: unsupported warp size" << endl;
    return 1;
  }
  CHECK(GPU(GetLastError)());
  CHECK(GPU(DeviceSynchronize)());

  CHECK(GPU(Memcpy)(b.data(), bd, b.size() * sizeof(int),
                    GPU(MemcpyDeviceToHost)));

  CHECK(GPU(Free)(ad));
  CHECK(GPU(Free)(bd));

  cout << "Result:  ";
  for (auto x : b)
    cout << " " << x;
  cout << endl;

  cout << "Expected:";
  bool correct = true;
  for (int i = 0; i < b.size(); ++i) {
    int x = i * warp_size;
    cout << " " << x;
    if (b[i] != x)
      correct = false;
  }
  cout << endl;

  if (!correct) {
    cerr << "Wrong result!" << endl;
    return 1;
  }

  return 0;
}

Just a thought:

Does it work with block_size <= 256?
Does it work if you add __launch_bounds__(512) before the kernel?

Just a thought:

Does it work with block_size <= 256?
Does it work if you add __launch_bounds__(512) before the kernel?

Sorry for the late update, both seems to be true. Block sizes <= 256 work and adding launch bounds make it also work with a block size of 512.
Even more important for us, the issue seems to be fixed in ROCm 4.1.1 (I have no access to 4.1.0, but at least in 4.0.0 it was still present).

Even more important for us, the issue seems to be fixed in ROCm 4.1.1 (I have no access to 4.1.0, but at least in 4.0.0 it was still present).

This is because of this change:
https://github.com/RadeonOpenCompute/ROCm#performance-impact-for-kernel-launch-bound-attribute

I have the same issue on rocm 5.0.2 :(
why using optimization resulted in an incorrect result? I can see that some of my kernels' calculations were set to zero(e.g. 12134231 => 0) when I used optimization flags(-O1, -O2, -O3), which is incorrect.


Enforce PKCS 11 80 char column limit

Enforce PKCS 11 80 char column limit
Description
As per the FreeRTOS coding standard, enforce an 80 character column limit.
Checklist:

[ x] I have tested my changes. No regression in existing tests.
[ x] My code is Linted.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/bot run checks

/bot run checks

/bot run checks

/bot run checks

/bot run checks

/bot run checks

/bot run checks

/bot run checks

/bot run checks

/bot run checks


CLN: deduplicate some code with macros in geometry-creating ufuncs

https://github.com/pygeos/pygeos/pull/156 added quite some code to get the GIL release working with geometry creating ufuncs. I think we can improve maintainability a bit by factoring out some of the parts into additional macros.

Other possible snippets that are repeated in all of the geometry-creating ufuncs are:
  // allocate a temporary array to store output GEOSGeometry objects
  geom_arr = malloc(sizeof(void*) * dimensions[0]);
  if (geom_arr == NULL) {
    PyErr_SetString(PyExc_MemoryError, "Could not allocate memory");
    return;
  }

and
  // fill the numpy array with PyObjects while holding the GIL
  if (errstate == PGERR_SUCCESS) {
    geom_arr_to_npy(geom_arr, args[1], steps[1], dimensions[0]);
  }
  free(geom_arr);

Do people think those are also worth replacing with a macro? (those are shorter, so less sure here if it will necessarily improve readability with a macro)

Per the snippets above, it seems like a good idea to keep malloc and free visible within the top-level function, rather than potentially hiding them in a macro.
However, this could potentially get put into a maco like CHECK_ALLOC(geom_arr) to centralize the error message without obscuring malloc / free:
  if (geom_arr == NULL) {
    PyErr_SetString(PyExc_MemoryError, "Could not allocate memory");
    return;
  }

@brendan-ward thanks for the suggestion, added such macro!


Added api docs generator

for Windows only now. If need I can make run them on Mono too.

@avbel merge conflicccccct

~

Fixed


Unable to read file at

Not sure why it's not working

Seems like you forgot to check out (download) your repository inside of your workflow. This means that inside of the workflow, none of the files in your repository will be available, so the Unable to read file at "" message in this case means that the file simply doesn't exist. I'll look into making the error message clearer if something like this happens.
To check out your repository inside of your workflow and have your files available to use, you should put in a step with the official checkout action before running the publish. Hope that helps!

@filiptibell would this be correct?
name: Roblox Unit Test

on: [push]

jobs:
  Run-Tests:
    runs-on: windows-latest
    timeout-minutes: 10

    steps:
      - uses: actions/checkout@v1

      - name: Install Tools
        uses: Roblox/setup-foreman@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

      - name: Install Roblox Studio
        uses<EMAIL_ADDRESS>        with:
          cookie: ${{ secrets.ROBLOXSECURITY }}
          token: ${{ secrets.GITHUB_TOKEN }}

      - name: Add RBXID to the Windows registry
        run: REG ADD HKCU\Software\RobloxStudioBrowser\roblox.com /t REG_SZ /v .RBXID /d "${{ secrets.RBXID }}"

      # Flip flag that causes issue
      - name: Create fflag overrides
        run: |
          $flags = @{DFIntStudioUseNewLoginDataEndpointHundredthPercent=0; FFlagStudioUseNewLoginDataEndpoint=$false}
          New-Item -Path 'C:/Program Files (x86)/Roblox/Versions/version-*/' -Name "ClientSettings" -ItemType "directory"
          New-Item -Path 'C:/Program Files (x86)/Roblox/Versions/version-*/ClientSettings' -Name "ClientAppSettings.json"
          $flags | ConvertTo-Json -depth 32| set-content -Path 'C:/Program Files (x86)/Roblox/Versions/version-*/ClientSettings/ClientAppSettings.json'

      - name: Run tests
        run: |
          run-in-roblox --place "./Time Attack!.rbxlx" --script ./src/TestService/TestServer/init.lua
          run-in-roblox --place "./Time Attack!.rbxlx" --script ./src/TestService/TestClient/init.lua

      - name: Publish to Roblox
        uses<EMAIL_ADDRESS>        with:
          universe-id: "3166878368"
          place-id: "8255321900"
          api-key: ${{ secrets.CLOUD_API_KEY }}
          path: "Time Attack!.rbxl"

      - name: Publish to Roblox
        uses: Ulferno/upload-to-roblox@latest
        with:
          api-key: ${{ secrets.ROBLOX_API_KEY }}
          universeId:<PHONE_NUMBER>
          placeId:<PHONE_NUMBER>
          file: "./Time Attack!.rbxl"


Models for ledger state objects

We should have models for ledger data, including the ledger header and all types of ledger objects that can be in the ledger's state data.
This would aid reading/exploring and processing ledger data as well as transaction metadata.

More important than other enhancements, but not truly a bug fix

More important than adding response objects

May make sense to prioritize if/when devs request it


Add preconditioning in GD

Currently we have the following for the GD algorithm:
$$ x_{k+1} = x_{k} - \gamma_{k} \nabla f (x_{k}) $$
However, we need to have a preconditioning before the f.gradient step as discussed in #1345. This is both useful in the deterministic and stochastic step.
$$ x_{k+1} = x_{k} - \gamma_{k} D(x_{k})\nabla f (x_{k}) $$
Notice that we already have this functionality in the SIRT algorithm but it is hardcoded. In fact in SIRT, we have two fixed preconds, which are
$$ \frac{1}{A^{T}\mathbb{1}} $$
and
$$ \frac{1}{A \mathbb{1}} $$
Of course SIRT is designed for a specific optimisation problem where we know that the objective function is
$$ ||Ax - d||^{2} $$
and our users will only need to pass the operator A and the data d.  However, if GD , ISTA and FISTA allow preconditioning we can have an algorithm similar to SIRT

without non-negativity constraint = GD
with non-negativity constraint = ISTA/FISTA

And also, we can have their stochastic versions, i.e., OS-SIRT etc. Actually, since SIRT does not accept an objective function, we cannot setup OS-SIRT with the SIRT class via SubsetSumFunction.
As described in #1345, we can have the following that can be used in both deterministic and stochastic cases:
a) preconditioner is fixed $\frac{1}{A^{T}\mathbb{1}}$
b) depends on the iterates  $\frac{x_{k}+\delta}{A^{T}\mathbb{1}}$
c) depends on the subsets_num, i.e., activate/deactivate it after some epochs or iterations.
d) None
To cover all of the above cases, I suggest to have sth like
 GD-update
    def update(self):
        '''Single iteration'''

        self.objective_function.gradient(self.x, out=self.x_update)
        if self.precond is True:
           self.x_update *= self.precond( x iterate, num_subset, iteration)
        if self.update_step_size:
            # the next update and solution are calculated within the armijo_rule
            self.step_size = self.armijo_rule()
        else:
            self.x.sapyb(1.0, self.x_update, -self.step_size, out=self.x)

And the user can predefine a callable function for the precond step:
def fixed_precond(x, num_subset, iteration):
         return 1./A.adjoint(ag.allocate(1.0)) # sometimes we need to check if there are no 0's in the denominator

def fixed_precond(x, num_subset, iteration):
         return (x + delta)/(A.adjoint(ag.allocate(1.0))

or in the stochastic case
def fixed_precond(x, num_subset, iteration):
         if epochs<5:
               return (x + delta)/(A.adjoint(ag.allocate(1.0))
        else:
              self.precond = False # deactivate precond after 5 epochs

What do you think @paskino @gfardell @jakobsj

After the discussion we had, I want to write down my proposal based on the following assumptions:

The preconditioner does not belong to the Function nor to the Algorithm classes
The preconditioner is used by the algorithm and needs to access properties that might not be known to the algorithm
The algorithm applying preconditioning can pass information that is available to it, and may be dependent on the current iteration, such as iteration number and current solution. These seem to be the only required parameters the algorithm can contribute for the calculation of the preconditioner.

Given this, I propose to create a new class Preconditioner with a method called, for the sake of the argument, apply with the following signature

class Preconditioner(object):

    def apply(self, x, iteration_num):
        pass

As described above by @epapoutsellis, in the GD-update section, GD is calling the function (in that case) precond. I propose that GD gets passed an instance of the Preconditioner appropriately defined, and use it in the update method, as sketched below:

def update(self):
        '''Single iteration'''

        self.objective_function.gradient(self.x, out=self.x_update)
        if self.precond is True:
           self.x_update *= self.preconditioner.apply(self.x, iteration)
        if self.update_step_size:
            # the next update and solution are calculated within the armijo_rule
            self.step_size = self.armijo_rule()
        else:
            self.x.sapyb(1.0, self.x_update, -self.step_size, out=self.x)

I also suggest to create preconditioners by means of a factory, which could be the same Preconditioner class. Something as follows could be used:

class Preconditioner(object):

    @staticmethod
    def create_fixed(A):
        precond = Preconditioner()
        precond.A = A
        precond.ag = A.range_geometry()
        precond.apply = self.apply_fixed
        return precond

    def apply_fixed(self, x, iteration_num):
        return 1./self.A.adjoint(self.ag.allocate(1.0))

    @staticmethod
    def create_variable(A, delta):
        precond = Preconditioner()
        precond.A = A
        precond.ag = A.range_geometry()
        precond.delta = delta
        precond.apply = self.apply_variable
        return precond

    def apply_variable(self, x, iteration_num):
        return (x + self.delta)/(self.A.adjoint(self.ag.allocate(1.0))

    @staticmethod
    def create_fixed_stochastic(A, num_subsets, max_epoch):
        precond = Preconditioner()
        precond.A = A
        precond.ag = A.range_geometry()
        precond.num_subsets = num_subsets
        precond.max_epoch = max_epoch
        precond.apply = self.apply_fixed_stochastic
        return precond

    def apply_fixed_stochastic(self, x, iteration_num):
        if iteration_num * self.num_subsets<self.max_epoch:
               return (x + self.delta)/(self.A.adjoint(self.ag.allocate(1.0))
        else:
              return 1.

    def apply(self, x, iteration_num):
        pass

This will cover all the above mentioned cases. The user would use it as below, provided we define set_preconditioner in GD:

f = LeastSquares(A,b,0.5)
algo = GD(initial=A.domain_geometry().allocate(0.), objective_function=f, step_size=f.L/3, max_iteration=100)

precond = Preconditioner.get_fixed(A)
# or
precond = Preconditioner.get_variable(A, delta)
# or in case f is a stochastic function
f = SGDFunction(...)
precond = Preconditioner.get_fixed_stochastic(A, f.num_functions)

algo.set_preconditioner(precond)

algo.run(100)

Additionally a user might create an appropriate Preconditioner to pass to the algorithm provided that this object, which may or may not be an instance of Preconditioner, has an apply  method with the above mentioned signature. In Java, you would say that the object passed follows a certain Interface, i.e. it provides certain methods with a defined signature.

@paskino , @KrisThielemans any decision on the above design about GD and preconditioning?


ts: Migrate pm_conversations module to typescript.

Migrates pm_conversations.js module to typescript.

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

@zulipbot add "mentor review" "buddy review"

This is ready for another look. @PIG208

Thanks! This looks good to me. I have nothing else to add.

Merged, thanks @Lalit3716!


Initial Implementation of Sentry.

Removed fabric from Android.
Removed fabtic from ios

@borisyankov reverted back all the auto formated changes 👍 (in package.json, android manifest and iOS info.plist)

I know it is super-annoying, so thanks for the effort 👍