Remove an unneeded ResMut

I believe this ResMut is unnecessary since they deref to a mutable reference and you can just pass that into the function. Taking the mutable reference directly also allows this function to be called from thread local systems where Resources.get_mut returns a RefMut rather than a ResMut. There may be a way to convert between those types, but just removing the wrapper entirely seems cleaner.

Just added one more on top of it that is effectively the same.

Nice. I should have looked more carefully for others.


Replace dashes with underscores when searching for matching hosts

Sometimes hostnames are presented with dashes, sometimes with underscores.  On the tasks page they are presented with underscores. Because of this, when linked from a page where they're presented with dashes, no match would be found. This fixes that.

cc @wolfd @kwm4385 @tpetr

LGTM


Each child in a list should have a unique "key" prop.

Complete log
Check the render method of `PagerViewAdapter`. See https://reactjs.org/link/warning-keys for more information.
    at Box (http://localhost:8081/index.bundle?platform=android&dev=true&minify=false&app=com.starter&modulesOnly=false&runModule=true:168328:24)
    in PagerViewAdapter (at TabView.tsx:79)
    in RCTView (at View.js:34)
    in View (at TabView.tsx:78)
    in TabView (at ShipmentDetailsComponent.js:344)
    in ShipmentDetailsComponent (at SceneView.tsx:132)
    in StaticContainer
    in EnsureSingleNavigator (at SceneView.tsx:124)
    in SceneView (at useDescriptors.tsx:217)
    in RNSScreen (at createAnimatedComponent.js:217)
    in AnimatedComponent (at createAnimatedComponent.js:278)
    in AnimatedComponentWrapper (at src/index.native.tsx:147)
    in Screen (at ResourceSavingScene.tsx:30)
    in ResourceSavingScene (at DrawerView.tsx:203)
    in RNSScreenContainer (at src/index.native.tsx:186)
    in ScreenContainer (at DrawerView.tsx:182)
    in RCTView (at View.js:34)
    in View (at Drawer.tsx:625)
    in RCTView (at View.js:34)
    in View (at createAnimatedComponent.tsx:682)
    in AnimatedComponent(View) (at createAnimatedComponent.tsx:693)
    in Unknown (at Drawer.tsx:618)
    in RCTView (at View.js:34)
    in View (at createAnimatedComponent.tsx:682)
    in AnimatedComponent(View) (at createAnimatedComponent.tsx:693)
    in Unknown (at Drawer.tsx:608)
    in PanGestureHandler (at GestureHandlerNative.tsx:13)
    in PanGestureHandler (at Drawer.tsx:599)
    in DrawerView (at DrawerView.tsx:235)
    in SafeAreaProviderCompat (at DrawerView.tsx:233)
    in GestureHandlerRootView (at GestureHandlerRootView.android.tsx:26)
    in GestureHandlerRootView (at DrawerView.tsx:232)
    in DrawerView (at createDrawerNavigator.tsx:47)
    in DrawerNavigator (at DrawerNavigator.js:44)
    in DrawerNavigator (at App.js:25)
    in $29383e587d62412a$export$9f8ac96af4b1b2ae (at NativeBaseProvider.tsx:97)
    in ToastProvider (at NativeBaseProvider.tsx:95)
    in PortalProvider (at NativeBaseProvider.tsx:94)
    in HybridProvider (at NativeBaseProvider.tsx:90)
    in ResponsiveQueryProvider (at NativeBaseProvider.tsx:89)
    in RNCSafeAreaProvider (at SafeAreaContext.tsx:76)
    in SafeAreaProvider (at NativeBaseProvider.tsx:84)
    in NativeBaseConfigProviderProvider (at NativeBaseProvider.tsx:77)
    in NativeBaseProvider (at App.js:22)
    in EnsureSingleNavigator (at BaseNavigationContainer.tsx:430)
    in BaseNavigationContainer (at NavigationContainer.tsx:132)
    in ThemeProvider (at NavigationContainer.tsx:131)
    in NavigationContainerInner (at App.js:21)
    in App (at ReactNativeStarter-main/index.js:19)
    in PersistGate (at ReactNativeStarter-main/index.js:18)
    in Provider (at ReactNativeStarter-main/index.js:17)
    in ReduxProvider (at renderApplication.js:47)
    in RCTView (at View.js:34)
    in View (at AppContainer.js:107)
    in RCTView (at View.js:34)
    in View (at AppContainer.js:134)
    in AppContainer (at renderApplication.js:40)

Everything work fine... but theres a huge log that repeats itself and seems to be a problem with some render inside the library.
I'm using this code
Material UI Tab View

Assign a key prop to each child component.

I'm having the same issue, any news on this?

check renderTabBar method


FancyZones with multiple extended monitors does not work.

Environment
Windows build number: Version 1903 (OS Build 18362.295) in a Hyper-V VM
PowerToys version: v0.11.0
PowerToy module for which you are reporting the bug (if applicable): FancyZones

Steps to reproduce
-Enable FancyZones

Override Windows Snap hotkeys (win+arrow) to move between zones

Expected behavior
Works on all my monitors (currently 2 attached as extended).
Actual behavior
I can move windows around on my main monitor. The second one is ignored.
Screenshots

Duplicate 195

As @lennybacon noted, this is a duplicate of https://github.com/microsoft/PowerToys/issues/195


[Discussion] API for TestingHelpers

This issue collects the requirements for an API for TestingHelpers, see here.

Events #168

Create File
Delete File
...

Handling access (read, write, create) to

Drives

Disallowed drives #189

Files #183 (MockFileStream.StreamType)
Directories

Feel free to add further requirements, proposal, ...
It is beneficial to add example and if possible the interfaces.

cc @Zvirja @AlexanderPruss

I don't see my submitted Issues as evidence that the TestingHelpers need an API.  It seems clear that the mocked filesystem should function the same way that a non-mocked filesystem does, or what's the point? My issues are just straight-up bugs with relatively simple fixes.

It is a bit misleading that the API of the testing helpers is also used to implement the mock filesystem.
This leaves us with a few problems.
i.e.: We cannot change the TestingHelpers if it changes the behaviour of the mock filesystem.
We are limited in refactoring efforts because we don't want to break existing tests using the Testinghelpers API.
And maybe a few more problems.
The API of used to set up a mock filesystems in our unit tests is almost a side product of the mock filesystem implementation.
Yet necessary.
A separate API could solve some of those issues.
But I agree, at this point the correctness of the mock filesystem behavior is most important.

The correctness of the mock filesystem has top priority for me, too.
Here are some reasons for this discussion for an "API".
Recent PRs introduced lots of new functionality, some with changes on the "API".
For me it is already challenging to verify the functionality of the mock file system regarding to the real file system.
Some changes in the past fixed a small portion, on the other hand it introduced new, incorrect behavior.
The purpose of this issue is to collect the needed functionality and to prevent uncontrolled growth.
It can be that the "API" is not needed, maybe a change in the development process can solve this challenge. I am open to suggestion and/or solutions.
Especially I do not want to waste the effort of somebody in implementing functionality which is not accepted.

While I have changed the interface of the MockFileSystem in one of my PRs, I only expanded it, which is hopefully less bad.


Rewrite fetch source files (#249)

Addresses #249, #248, #239 and #254.
Mainly, provides a Python version of tools/fetch_source_files.sh, for better portability and maintainability.

@FabienLelaquais We need an update on the Installation page.
Besides, what do you think about explicitly explain the arguments of tools/fetch_source_files.py on this page?
Like provide a list of --no_pull, --check, ... with short description on the installation page so that the user know the options, and they can run --help for more information.

We need an update on the Installation page

Yes yes that's true. The different options are already documented in the sh and the py versions of the fetch script.
It would make a lot of sense to indicate them in the Installation md file as well, indeed.
At this stage, I have not changed the build process, which still relies on the Bash version of the script.
The plan is to move tot he Python version, drop the sh version, and then update the Installation file, where your comment makes a lot of sense.
thx


Pulumi program testing library

Adds an experimental new library for constructing tests which interact with the Pulumi CLI. Once stabalised and proven, this could be a candidate to be re-homed into pulumi/pulumi.
Pulumi Testing Library
Pulumi Test is a thin(ish) wrapper over the Automation API, making it easier to use within test scenarios.
The Automation API is just a thin wrapper around the calling the Pulumi CLI (pulumi ...). Some additional commands which are not yet supported by the Automation API are also added for convenience.
Getting Started
The starting point to testing a program is to create a new PulumiTest pointing at some existing test.
func TestPulumiProgram(t *testing.T) {
  test := NewPulumiTest(t, filepath.Join("path", "to", "program"))
  //...
}

By default run your program is copied to a temporary directory before running to avoid cluttering your working directory with temporary or ephemeral files. To disable this behaviour, use NewPulumiTestInPlace. You can also do a copy of a test manually by calling CopyToTempDir():
source := NewPulumiTestInPlace(t, ...)
copy := source.CopyToTempDir()

The source variable is still pointing to the original path, but the copy is pointing to a new PulumiTest in temporary directory which will automatically get removed at the end of the test.
Before we can preview or deploy a program we need to install dependencies and create a stack:
//...
test.Install() // Runs `pulumi install` to restore all dependencies
test.NewStack("my-stack") // Creates a new stack and returns it.

These two steps can also be done together by calling InstallStack():
test.InstallStack("my-stack")

The created stack is returned but is also set as the current stack on the PulumiTest object. All methods such as source.Preview() or source.Up() will use this current stack.

[!NOTE]
The new stack will be automatically destroyed and removed at the end of the test.

Default Settings
PULUMI_BACKEND_URL is set to a temporary directory. This improves test performance and doesn't rely on the user already being authenticated to a specific backend account. This also isolates stacks so the same stack name can be re-used for several tests at once without risking conflicts and avoiding stack name randomisation which breaks importing & exporting between test runs. This can be overridden by the option opttest.UseAmbientBackend() or by setting PULUMI_BACKEND_URL yourself in the stack initialization options.
PULUMI_CONFIG_PASSPHRASE is set by default to "correct horse battery staple" (an arbitrary phrase) so that encrypted values are not tied to an external secret store that the user might not have access to. This can be overridden by setting PULUMI_CONFIG_PASSPHRASE in the stack initialization options.
Configuring Providers
Pulumi discovers plugins the same as when running Pulumi commands directly.
In a test scenario, we often want to ensure a specific implementation of a provider is used during testing. The most reliable way is to configure use plugin attachment PULUMI_DEBUG_PROVIDERS=NAME:PORT. This prevents the Pulumi engine from searching for and starting the provider with the given name. Instead, it will connect to the already-running provider on the specified port. If the provider is not reachable on the given port, Pulumi will throw an error.
These can be specified via the Attach* options when constructing the test:
// Start a provider yourself
NewPulumiTest(t, "path", opttest.AttachProvider("gcp", func(ctx context.Context) (int, error) {
  return port, nil // TODO: Actually start a provider.
})
// Start a server for testing from a pulumirpc.ResourceProviderServer implementation
NewPulumiTest(t, "path", opttest.AttachProviderServer("gcp", func() (pulumirpc.ResourceProviderServer, error) {
  return makeProvider()
})
// Specify a local path where the binary lives to be started and attached.
NewPulumiTest(t, "path", opttest.AttachProviderBinary("gcp", filepath.Join("..", "bin"))
// Use Pulumi to download a specific published version, then start and attach it.
NewPulumiTest(t, "path", opttest.AttachDownloadedPlugin("gcp", "6.61.0")

For providers which don't support attaching, we can configure the path to the binary of a specific provider in the plugins.providers property in the project settings (Pulumi.yaml) by using the LocalProviderPath() option:
NewPulumiTest(t, "path", opttest.LocalProviderPath("gcp", filepath.Join("..", "bin"))

Pulumi Operations
Preview, Up, Refresh and Destroy can be run directly from the test context:
test.Preview()
test.Up()
test.Refresh()
test.Destroy()

[!NOTE]
Stacks created with InstallStack or NewStack will be automatically destroyed and removed at the end of the test.

Using Local SDKs
When running tests via SDKs that haven't yet been published, we need to configure the program under test to use our local build of the SDK instead of installing a version from their package registry.
Node.js (Yarn Link)
For Node.js, we support using a locally linked version of the NPM package. Before running your test, you must run yarn link in the directory of the built Node.js SDK (normally in sdk/nodejs/bin).
Once the local link is configured, you can configure your test to use the linked package by using the YarnLink test option:
NewPulumiTest(t, "test_dir", opttest.YarnLink("@pulumi/azure-native"))

Go - Module Replacement
In Go, we support adding a replacement to the go.mod of the program under test. This is implemented by calling go mod edit -replace with the user-specified replacement.
The replacement can be specified using the GoModReplacement test option:
NewPulumiTest(t, "test_dir",
  opttest.GoModReplacement("github.com/pulumi/pulumi-my-provider/sdk/v3", "..", "sdk"))

Additional Operations
Update Source
Update source files for a subsequent step in the test:
test.UpdateSource("folder_with_updates")

Set Config
Set a variable in the stack's config:
test.SetConfig("gcp:project", "pulumi-development")

Asserts
The assertup and assertpreview modules contain a selection of functions for asserting on the results of the automation API:
assertup.HasNoDeletes(t, upResult)
assertup.HasNoChanges(t, upResult)
assertpreview.HasNoChanges(t, previewResult)
assertpreview.HasNoDeletes(t, previewResult)

Example
Here's a complete example as a test might look for the gcp provider with a local pre-built binary.
func TestExample(t *testing.T) {
  // Copy test_dir to temp directory, install deps and create "my-stack"
  test := NewPulumiTest(t, "test_dir", opttest.AttachProviderBinary("gcp", "../bin"))
  test.InstallStack("my-stack")

  // Configure the test environment & project
  test.SetConfig("gcp:project", "pulumi-development")

  // Preview, Deploy, Refresh,
  preview := test.Preview()
  t.Log(preview.StdOut)

  deploy := test.Up()
  t.Log(deploy.StdOut)
  assertpreview.HasNoChanges(t, test.Preview())

  // Export import
  test.ImportStack(test.ExportStack())
  assertpreview.HasNoChanges(t, test.Preview())

  test.UpdateSource(filepath.Join("testdata", "step2"))
  update := test.Up()
  t.Log(update.StdOut)
}

Comparative ProgramTest example:
func TestExample(t *testing.T) {
  test := integration.ProgramTestOptions{
    Dir: testDir(t, "test_dir"),
    Dependencies: []string{filepath.Join("..", "sdk", "python", "bin")},
    ExpectRefreshChanges: true,
    Config: map[string]string{
      "gcp:project": "pulumi-development",
    },
    LocalProviders: []integration.LocalDependency{
      {
        Package: "gcp",
        Path:    "../bin",
      },
    },
    EditDirs: []integration.EditDir{
      {
        Dir:      testDir(t, "test_dir", "step2"),
        Additive: true,
      },
    },
  }

  integration.ProgramTest(t, &test)
}

🚢
I think this is very nice. This is a well factored foundation that has all the features that ProgramTester.ManualLifecycle and then some improvements that we were needing badly in providertest.. It's not yet "proven" by  a lot of use but it has no legacy cruft and looks very easy to maintain. Extra props for including tests from the get-go.
The state traditions are modeled imperatively and this being Go that seems like the way..
I'm thinking that I'm not seeing anything missing here to implement upgrade test cleanly. One thing perhaps, this:
opttest.AttachProviderBinary("gcp", "../bin")

This is currently a 'global' option. But it shouldn't be. I want to be able to imperatively change up dependencies in the lifecycle. This is the essence of upgrade testing. Could we make it imperatively modified same way you have this:
test.UpdateSource(filepath.Join("testdata", "step2"))

We could then do this:
func TestPreviewOnlyUpgrade(t *testing.T) {
  test := NewPulumiTest(t, "test_dir")
  test.InstallStack("my-stack") // install baseline versions

  // Configure the test environment & project
  test.SetConfig("gcp:project", "pulumi-development")

  test.ImportStack("..saved..snapshot..") // grab from baseline versions

  test.SetDependencies(opttest.AttachProviderBinary("gcp", "../bin")) // now we're testing the local build
  test.UpdateSource(filepath.Join("testdata", "step2")) // optionally simulate the user updating the source on upgrade
  deploy := test.Preview()
  assertpreview.HasNoChanges(t, test.Preview())
}

And for "real" upgrade test we could do this:
func TestRealUpgrade(t *testing.T) {
  test := NewPulumiTest(t, "test_dir")
  test.InstallStack("my-stack") // install baseline versions

  // Configure the test environment & project
  test.SetConfig("gcp:project", "pulumi-development")

  test.Up()

  test.SetDependencies(opttest.AttachProviderBinary("gcp", "../bin")) // now we're testing the local build
  test.UpdateSource(filepath.Join("testdata", "step2")) // optionally simulate the user updating the source on upgrade
  deploy := test.Up()
  assertpreview.HasNoChanges(t, deploy)
}

Default Settings
PULUMI_BACKEND_URL is set to a temporary directory. This improves test performance and doesn't rely on the user already being authenticated to a specific backend account. This also isolates stacks so the same stack name can be re-used for several tests at once without risking conflicts and avoiding stack name randomisation which breaks importing & exporting between test runs. This can be overridden by the option opttest.UseAmbientBackend() or by setting PULUMI_BACKEND_URL yourself in the stack initialization options.
PULUMI_CONFIG_PASSPHRASE is set by default to "correct horse battery staple" (an arbitrary phrase) so that encrypted values are not tied to an external secret store that the user might not have access to. This can be overridden by setting PULUMI_CONFIG_PASSPHRASE in the stack initialization options.

These are exceptionally reasonable defaults. A lot of integration tests currently hit the Pulumi Cloud service, but this generates an enormous amount of clutter in the system not to mention another source of flakiness.

Going to merge as-is so we can start integrating this and can continue to iterate on additional features in follow-up PRs.


Add some logging for new or updated bookplates

https://github.com/sul-dlss/libsys-airflow/blob/d29dd5e2a3b0ff43174e9a540ff8e05b80b4e78e/libsys_airflow/plugins/digital_bookplates/purl_fetcher.py#L36-L57
When running this locally we won't get an email report with the new or updated bookplates. It would be nice to see in the log for each mapped task some info about the bookplate (new, update, no change).
For the extract_bookplate_metadata task, one of the mapped tasks we see:

Should failure or fund_name show empty {} rather than, I'm guessing "None" in this context?
I think the add_update_model task is where we see in the XCOM the "newness" of a bookplate. This is from a first run of the DAG:

And this is a subsequent run (so I guess return_value = {} means no change):

Either way, it would be nice to have some logger.info.

This came about because I was thinking I'd see the next DAG, digital_bookplate_instances, run but I didn't. I eventually saw in the log for trigger_instances_dag task the "No new funds to trigger digital_bookplate_instances DAG". 👍


Add favicon to jupyterhub theme.

Reference Issues or PRs
N/A
What does this implement/fix?
Put a x in the boxes that apply

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds a feature)
[ ] Breaking change (fix or feature that would cause existing features not to work as expected)
[ ] Documentation Update
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build related changes
[ ] Other (please describe):

Testing

[ ] Did you test the pull request locally?
[ ] Did you add new tests?

Any other comments?

Favicon added to nebari-design repo
Adding favicon to jupyterhub theme to further support theming Nebari

@dcmcand , The failed job is an existing issue correct? If so, when can we expect to merge this? Thanks!

yes, the CI failure is outside the scope of this PR. This is ready for review/merging after review.


PFFile raises exception when getting data from caches

I'm getting this crash from time to time on app startup when trying to fetch user's profile image:
2015-11-08 13:23:15.088 MyApp[7219:471946] [Error]: Caught "NSInvalidArgumentException" with reason "*** -[_NSPlaceholderData initWithContentsOfFile:options:error:]: nil file argument":
(
0   CoreFoundation                      0x0000000110a07f45 __exceptionPreprocess + 165
1   libobjc.A.dylib                     0x000000011047edeb objc_exception_throw + 48
2   CoreFoundation                      0x0000000110a07e7d +[NSException raise:format:] + 205
3   Foundation                          0x000000011002cd48 -[NSData(NSData) initWithContentsOfFile:options:error:] + 95
4   Foundation                          0x00000001100c5fcc +[NSData(NSData) dataWithContentsOfFile:options:error:] + 61
5   MyApp                               0x000000010e828426 -[PFFile _cachedData] + 94
6   MyApp                               0x000000010e886cac __62-[BFTask continueWithExecutor:successBlock:cancellationToken:]_block_invoke + 83
7   MyApp                               0x000000010e88658c __55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 + 82
8   MyApp                               0x000000010e8874ab __29+[BFExecutor defaultExecutor]_block_invoke_2 + 358
9   MyApp                               0x000000010e887a15 -[BFExecutor execute:] + 65
10  MyApp                               0x000000010e886510 __55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke + 138
11  MyApp                               0x000000010e886110 -[BFTask runContinuations] + 396
12  MyApp                               0x000000010e8859c6 -[BFTask trySetResult:] + 151
13  MyApp                               0x000000010e883c4c -[BFTaskCompletionSource trySetResult:] + 79
14  MyApp                               0x000000010e7e48b3 __28-[PFAsyncTaskQueue enqueue:]_block_invoke_2 + 198
15  MyApp                               0x000000010e88658c __55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 + 82
16  libdispatch.dylib                   0x00000001145fce5d _dispatch_call_block_and_release + 12
17  libdispatch.dylib                   0x000000011461d49b _dispatch_client_callout + 8
18  libdispatch.dylib                   0x0000000114605bef _dispatch_root_queue_drain + 1829
19  libdispatch.dylib                   0x00000001146054c5 _dispatch_worker_thread3 + 111
20  libsystem_pthread.dylib             0x000000011494ea9d _pthread_wqthread + 729
21  libsystem_pthread.dylib             0x000000011494c3dd start_wqthread + 13
).
This seems to start happening after I recently updated the Parse SDK. Does this mean that file's cache is not somehow compatible with old cache or this is just a bug? Reinstalling the app has fixed it for now.

Super strange and shouldn't happen.
I'll try to look into it, but overall - it should be definitely there or simply redownloaded.
Any chance you can post the stack trace for all threads of the app the moment it crashes?
Or better - whilst debugger is attached - post a file path of the file its trying to get the file from.
Also, are you trying to get the file path for the file that was saved to Parse? (Meaning that the url of e the file should be non-nil).

@nlutsenko Any update on this. I similarly cannot receive errors when I try to load PFFiles.

@dtaitz Any chance you can post the stack trace for all threads of the app the moment it crashes?
Or better - whilst debugger is attached - post a file path of the file its trying to get the file from.
Also, are you trying to get the file path for the file that was saved to Parse? (Meaning that the url of the file should be non-nil).

@nlutsenko  The app doesn't crash. I just get a lot of errors and the the images do not load from the file. The images are definitely saved to Parse.
There is definitely a change I am trying to load nil PFFile's, but that had not been a problem in the past. I am using the PFImageView ParseUI element.
Here is the backtrace:
(lldb) bt all
thread #1: tid = 0x35c026, 0x000000019acd0b3c libsystem_kernel.dylibsyscall_thread_switch + 8, queue = 'com.apple.main-thread'     frame #0: 0x000000019acd0b3c libsystem_kernel.dylibsyscall_thread_switch + 8
frame #1: 0x000000019adad534 libsystem_platform.dylib_os_lock_handoff_lock_slow + 120     frame #2: 0x000000019ad15524 libsystem_malloc.dylibszone_malloc_should_clear + 116
frame #3: 0x000000019ad15468 libsystem_malloc.dylibmalloc_zone_malloc + 116     frame #4: 0x00000001856aa718 CoreFoundation_CFRuntimeCreateInstance + 316
frame #5: 0x00000001862b9328 CoreTextCTFontDescriptorCreateCopyWithFeature + 48     frame #6: 0x000000018b6fc1c0 UIKit-[UIStatusBarForegroundStyleAttributes proportionalFontForFont:] + 212
frame #7: 0x000000018b6fc0c4 UIKit-[UIStatusBarForegroundStyleAttributes makeTextFontForStyle:] + 184     frame #8: 0x000000018adae544 UIKit-[UIStatusBarForegroundStyleAttributes textFontForStyle:] + 124
frame #9: 0x000000018b6fbb84 UIKit-[UIStatusBarForegroundStyleAttributes imageWithText:ofItemType:forWidth:lineBreakMode:letterSpacing:textAlignment:style:withLegibilityStyle:legibilityStrength:] + 312     frame #10: 0x000000018adae3c4 UIKit-[UIStatusBarItemView imageWithText:] + 264
frame #11: 0x000000018adae168 UIKit-[UIStatusBarItemView updateContentsAndWidth] + 40     frame #12: 0x000000018ad54684 UIKit-[UIStatusBarItemView setStatusBarData:actions:] + 104
frame #13: 0x000000018ad545b8 UIKit-[UIStatusBarLayoutManager _updateItemView:withData:actions:animated:] + 156     frame #14: 0x000000018ad5441c UIKit-[UIStatusBarLayoutManager updateItemsWithData:actions:animated:] + 232
frame #15: 0x000000018ad53db4 UIKit-[UIStatusBarForegroundView _setStatusBarData:actions:animated:] + 1024     frame #16: 0x000000018ad53778 UIKit-[UIStatusBarForegroundView setStatusBarData:actions:animated:] + 688
frame #17: 0x000000018ad52854 UIKit-[UIStatusBar statusBarServer:didReceiveStatusBarData:withActions:] + 188     frame #18: 0x000000018ad52750 UIKit_UIStatusBarReceivedStatusBarDataAndActions + 76
frame #19: 0x000000018ad526bc UIKit_XReceivedStatusBarDataAndActions + 96     frame #20: 0x000000018c8e3398 AppSupportmigHelperRecievePortCallout + 212
frame #21: 0x0000000185784c7c CoreFoundation__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 56     frame #22: 0x00000001857843b4 CoreFoundation__CFRunLoopDoSource1 + 436
frame #23: 0x000000018578210c CoreFoundation__CFRunLoopRun + 1800     frame #24: 0x00000001856b0ca0 CoreFoundationCFRunLoopRunSpecific + 384
frame #25: 0x00000001908ec088 GraphicsServicesGSEventRunModal + 180     frame #26: 0x000000018adc8ffc UIKitUIApplicationMain + 204
frame #27: 0x00000001001c2b8c Planvanmain(argc=1, argv=0x000000016fdc7b00) + 124 at main.m:17     frame #28: 0x000000019abce8b8 libdyld.dylibstart + 4
thread #3: tid = 0x35c05b, 0x000000019acec4fc libsystem_kernel.dylibkevent_qos + 8, queue = 'com.apple.libdispatch-manager'     frame #0: 0x000000019acec4fc libsystem_kernel.dylibkevent_qos + 8
frame #1: 0x0000000100cd6328 libdispatch.dylib_dispatch_mgr_invoke + 232     frame #2: 0x0000000100cc3ee4 libdispatch.dylib_dispatch_mgr_thread + 52
thread #5: tid = 0x35c05e, 0x000000019aceb440 libsystem_kernel.dylib__semwait_signal + 8     frame #0: 0x000000019aceb440 libsystem_kernel.dylib__semwait_signal + 8
frame #1: 0x000000019ac09e2c libsystem_c.dylibnanosleep + 212     frame #2: 0x00000001999e6314 libc++.1.dylibstd::__1::this_thread::sleep_for(std::__1::chrono::duration<long long, std::__1::ratio<1l,<PHONE_NUMBER>l> > const&) + 84
frame #3: 0x000000018737dcf4 JavaScriptCorebmalloc::Heap::scavenge(std::__1::unique_lock<bmalloc::StaticMutex>&, std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000l> >) + 404     frame #4: 0x000000018737d8cc JavaScriptCorebmalloc::Heap::concurrentScavenge() + 84
frame #5: 0x000000018737fe0c JavaScriptCorebmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>::entryPoint() + 100     frame #6: 0x000000018737fd9c JavaScriptCorebmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::)()>::pthreadEntryPoint(void) + 12
frame #7: 0x000000019adb3b28 libsystem_pthread.dylib_pthread_body + 156     frame #8: 0x000000019adb3a8c libsystem_pthread.dylib_pthread_start + 156
thread #6: tid = 0x35c05f, 0x000000019acd0a40 libsystem_kernel.dylibmach_msg_trap + 8, name = 'WebThread'     frame #0: 0x000000019acd0a40 libsystem_kernel.dylibmach_msg_trap + 8
frame #1: 0x000000019acd08bc libsystem_kernel.dylibmach_msg + 72     frame #2: 0x0000000185784108 CoreFoundation__CFRunLoopServiceMachPort + 196
frame #3: 0x0000000185781e0c CoreFoundation__CFRunLoopRun + 1032     frame #4: 0x00000001856b0ca0 CoreFoundationCFRunLoopRunSpecific + 384
frame #5: 0x00000001972be54c WebCoreRunWebThread(void*) + 456     frame #6: 0x000000019adb3b28 libsystem_pthread.dylib_pthread_body + 156
frame #7: 0x000000019adb3a8c libsystem_pthread.dylib`_pthread_start + 156
thread #7: tid = 0x35c061, 0x000000019aceba38 libsystem_kernel.dylib__unlink + 8, queue = 'PFSQLiteDatabase.synchronizationQueue'     frame #0: 0x000000019aceba38 libsystem_kernel.dylib__unlink + 8
frame #1: 0x000000019acd3cd4 libsystem_kernel.dylibunlink + 16     frame #2: 0x000000019a8cc028 libsqlite3.dylib___lldb_unnamed_function227$$libsqlite3.dylib + 48
frame #3: 0x000000019a8b361c libsqlite3.dylib___lldb_unnamed_function146$$libsqlite3.dylib + 1868     frame #4: 0x000000019a8b2bac libsqlite3.dylib___lldb_unnamed_function144$$libsqlite3.dylib + 172
frame #5: 0x000000019a885b80 libsqlite3.dylib___lldb_unnamed_function54$$libsqlite3.dylib + 1860     frame #6: 0x000000019a8ad368 libsqlite3.dylib___lldb_unnamed_function114$$libsqlite3.dylib + 52044
frame #7: 0x000000019a89f87c libsqlite3.dylibsqlite3_step + 504     frame #8: 0x0000000100439350 Planvan__30-[PFSQLiteDatabaseResult step]_block_invoke_2(.block_descriptor=) + 88 at PFSQLiteDatabaseResult.m:42
frame #9: 0x00000001004392c8 Planvan__30-[PFSQLiteDatabaseResult step]_block_invoke(.block_descriptor=0x000000016e31a560) + 120 at PFSQLiteDatabaseResult.m:42     frame #10: 0x000000010043e2cc PlanvanPFThreadsafetySafeDispatchSync(queue=0x000000013d5b1f30, block=(Planvan__30-[PFSQLiteDatabaseResult step]_block_invoke at PFSQLiteDatabaseResult.m:42)) + 152 at PFThreadsafety.m:29     frame #11: 0x00000001004391e4 Planvan-[PFSQLiteDatabaseResult step](self=0x000000013d688f10, _cmd="step") + 164 at PFSQLiteDatabaseResult.m:42
frame #12: 0x000000010043755c Planvan__57-[PFSQLiteDatabase executeSQLAsync:withArgumentsInArray:]_block_invoke_2(.block_descriptor=<unavailable>, task=0x000000013d685960) + 96 at PFSQLiteDatabase.m:240     frame #13: 0x00000001002217a4 Planvan__62-[BFTask continueWithExecutor:successBlock:cancellationToken:]_block_invoke(.block_descriptor=, task=0x000000013d685960) + 172 at BFTask.m:412
frame #14: 0x0000000100220a74 Planvan__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2(.block_descriptor=<unavailable>) + 124 at BFTask.m:338     frame #15: 0x000000010021d06c Planvan__31+[BFExecutor immediateExecutor]_block_invoke_2(.block_descriptor=0x00000001007221b0, block=(Planvan__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 at BFTask.m:330)) + 64 at BFExecutor.m:60     frame #16: 0x000000010021d894 Planvan-[BFExecutor execute:](self=0x000000013d55a670, _cmd="execute:", block=(Planvan__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 at BFTask.m:330)) + 108 at BFExecutor.m:111     frame #17: 0x000000010022099c Planvan__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke(.block_descriptor=0x000000013e8257c0) + 228 at BFTask.m:330
frame #18: 0x00000001002207f8 Planvan-[BFTask continueWithExecutor:block:cancellationToken:](self=0x000000013d685960, _cmd="continueWithExecutor:block:cancellationToken:", executor=0x000000013d55a670, block=(Planvan__62-[BFTask continueWithExecutor:successBlock:cancellationToken:]_block_invoke at BFTask.m:408), cancellationToken=0x0000000000000000) + 608 at BFTask.m:381
frame #19: 0x0000000100221698 Planvan-[BFTask continueWithExecutor:successBlock:cancellationToken:](self=0x000000013d685960, _cmd="continueWithExecutor:successBlock:cancellationToken:", executor=0x000000013d55a670, block=(Planvan__57-[PFSQLiteDatabase executeSQLAsync:withArgumentsInArray:]_block_invoke_2 at PFSQLiteDatabase.m:238), cancellationToken=0x0000000000000000) + 332 at BFTask.m:408
frame #20: 0x000000010022150c Planvan-[BFTask continueWithExecutor:withSuccessBlock:](self=0x000000013d685960, _cmd="continueWithExecutor:withSuccessBlock:", executor=0x000000013d55a670, block=(Planvan__57-[PFSQLiteDatabase executeSQLAsync:withArgumentsInArray:]_block_invoke_2 at PFSQLiteDatabase.m:238)) + 116 at BFTask.m:398
frame #21: 0x00000001004374b4 Planvan__57-[PFSQLiteDatabase executeSQLAsync:withArgumentsInArray:]_block_invoke(.block_descriptor=<unavailable>) + 224 at PFSQLiteDatabase.m:236     frame #22: 0x000000010021f498 Planvan__37+[BFTask taskFromExecutor:withBlock:]_block_invoke(.block_descriptor=, task=0x000000013e855b40) + 80 at BFTask.m:176
frame #23: 0x0000000100220a74 Planvan__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2(.block_descriptor=<unavailable>) + 124 at BFTask.m:338     frame #24: 0x0000000100cc1c68 libdispatch.dylib_dispatch_client_callout + 16
frame #25: 0x0000000100ccd4ec libdispatch.dylib_dispatch_barrier_sync_f_slow + 908     frame #26: 0x000000010043e2dc PlanvanPFThreadsafetySafeDispatchSync(queue=0x000000013d5b1f30, block=(Planvan__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 at BFTask.m:330)) + 168 at PFThreadsafety.m:31     frame #27: 0x0000000100435a84 Planvan__33-[PFSQLiteDatabase initWithPath:]_block_invoke_2(.block_descriptor=) + 60 at PFSQLiteDatabase.m:77
frame #28: 0x0000000100cc1ca8 libdispatch.dylib_dispatch_call_block_and_release + 24     frame #29: 0x0000000100cc1c68 libdispatch.dylib_dispatch_client_callout + 16
frame #30: 0x0000000100cd0ec8 libdispatch.dylib_dispatch_root_queue_drain + 2344     frame #31: 0x0000000100cd0590 libdispatch.dylib_dispatch_worker_thread3 + 132
frame #32: 0x000000019adb1470 libsystem_pthread.dylib`_pthread_wqthread + 1092
thread #8: tid = 0x35c06f, 0x000000019acd0a40 libsystem_kernel.dylibmach_msg_trap + 8, name = 'com.apple.CoreMotion.MotionThread'     frame #0: 0x000000019acd0a40 libsystem_kernel.dylibmach_msg_trap + 8
frame #1: 0x000000019acd08bc libsystem_kernel.dylibmach_msg + 72     frame #2: 0x0000000185784108 CoreFoundation__CFRunLoopServiceMachPort + 196
frame #3: 0x0000000185781e0c CoreFoundation__CFRunLoopRun + 1032     frame #4: 0x00000001856b0ca0 CoreFoundationCFRunLoopRunSpecific + 384
frame #5: 0x00000001856fe44c CoreFoundationCFRunLoopRun + 112     frame #6: 0x00000001861362e4 CoreMotion___lldb_unnamed_function2150$$CoreMotion + 828
frame #7: 0x000000019adb3b28 libsystem_pthread.dylib_pthread_body + 156     frame #8: 0x000000019adb3a8c libsystem_pthread.dylib_pthread_start + 156

thread #11: tid = 0x35c076, 0x00000001004471cc Planvan`-[PFURLSessionFileDownloadTaskDelegate _taskDidFinish](self=0x000000013d549010, _cmd="_taskDidFinish") + 1556 at PFURLSessionFileDownloadTaskDelegate.m:97, queue = 'NSOperationQueue 0x13d52fa50 :: NSOperation 0x13d62ac40 (QOS: LEGACY)', stop reason = breakpoint 30.1

frame #0: 0x00000001004471cc Planvan-[PFURLSessionFileDownloadTaskDelegate _taskDidFinish](self=0x000000013d549010, _cmd="_taskDidFinish") + 1556 at PFURLSessionFileDownloadTaskDelegate.m:97 frame #1: 0x000000010044618c Planvan-[PFURLSessionDataTaskDelegate URLSession:task:didCompleteWithError:](self=0x000000013d549010, _cmd="URLSession:task:didCompleteWithError:", session=0x000000013d56dda0, task=0x000000013d788c50, error=0x0000000000000000) + 432 at PFURLSessionDataTaskDelegate.m:158
frame #2: 0x0000000100441a88 Planvan-[PFURLSession URLSession:task:didCompleteWithError:](self=0x000000013d703020, _cmd="URLSession:task:didCompleteWithError:", session=0x000000013d56dda0, task=0x000000013d788c50, error=0x0000000000000000) + 184 at PFURLSession.m:237 frame #3: 0x0000000184ff30f0 CFNetwork__51-[NSURLSession delegate_task:didCompleteWithError:]_block_invoke170 + 72
frame #4: 0x00000001866f4374 Foundation__NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16 frame #5: 0x00000001866471a0 Foundation-[NSBlockOperation main] + 96
frame #6: 0x00000001866373e8 Foundation-[__NSOperationInternal _start:] + 604 frame #7: 0x00000001866f6768 Foundation__NSOQSchedule_f + 224
frame #8: 0x0000000100cc1c68 libdispatch.dylib_dispatch_client_callout + 16 frame #9: 0x0000000100cce780 libdispatch.dylib_dispatch_queue_drain + 1036
frame #10: 0x0000000100cc5958 libdispatch.dylib_dispatch_queue_invoke + 464 frame #11: 0x0000000100cd0898 libdispatch.dylib_dispatch_root_queue_drain + 760
frame #12: 0x0000000100cd0590 libdispatch.dylib_dispatch_worker_thread3 + 132 frame #13: 0x000000019adb1470 libsystem_pthread.dylib_pthread_wqthread + 1092

thread #13: tid = 0x35c07e, 0x000000019acebb6c libsystem_kernel.dylib__workq_kernreturn + 8   frame #0: 0x000000019acebb6c libsystem_kernel.dylib__workq_kernreturn + 8
frame #1: 0x000000019adb1530 libsystem_pthread.dylib`_pthread_wqthread + 1284
thread #14: tid = 0x35c07f, 0x000000019acebb6c libsystem_kernel.dylib__workq_kernreturn + 8   frame #0: 0x000000019acebb6c libsystem_kernel.dylib__workq_kernreturn + 8
frame #1: 0x000000019adb1530 libsystem_pthread.dylib`_pthread_wqthread + 1284
thread #16: tid = 0x35c081, 0x000000019acebb6c libsystem_kernel.dylib__workq_kernreturn + 8   frame #0: 0x000000019acebb6c libsystem_kernel.dylib__workq_kernreturn + 8
frame #1: 0x000000019adb1530 libsystem_pthread.dylib`_pthread_wqthread + 1284
thread #18: tid = 0x35c084, 0x000000019acd0a40 libsystem_kernel.dylibmach_msg_trap + 8, name = 'com.apple.NSURLConnectionLoader'   frame #0: 0x000000019acd0a40 libsystem_kernel.dylibmach_msg_trap + 8
frame #1: 0x000000019acd08bc libsystem_kernel.dylibmach_msg + 72   frame #2: 0x0000000185784108 CoreFoundation__CFRunLoopServiceMachPort + 196
frame #3: 0x0000000185781e0c CoreFoundation__CFRunLoopRun + 1032   frame #4: 0x00000001856b0ca0 CoreFoundationCFRunLoopRunSpecific + 384
frame #5: 0x0000000184f49b84 CFNetwork+[NSURLConnection(Loader) _resourceLoadLoop:] + 412   frame #6: 0x000000018670fc80 FoundationNSThread__start + 1000
frame #7: 0x000000019adb3b28 libsystem_pthread.dylib_pthread_body + 156   frame #8: 0x000000019adb3a8c libsystem_pthread.dylib_pthread_start + 156
thread #19: tid = 0x35c085, 0x000000019aceb368 libsystem_kernel.dylib__select + 8, name = 'com.apple.CFSocket.private'   frame #0: 0x000000019aceb368 libsystem_kernel.dylib__select + 8
frame #1: 0x000000018578a670 CoreFoundation__CFSocketManager + 648   frame #2: 0x000000019adb3b28 libsystem_pthread.dylib_pthread_body + 156
frame #3: 0x000000019adb3a8c libsystem_pthread.dylib`_pthread_start + 156
thread #20: tid = 0x35c4f0, 0x000000019adb101c libsystem_pthread.dylibstart_wqthread   frame #0: 0x000000019adb101c libsystem_pthread.dylibstart_wqthread
thread #21: tid = 0x35c4f1, 0x000000019adb101c libsystem_pthread.dylibstart_wqthread   frame #0: 0x000000019adb101c libsystem_pthread.dylibstart_wqthread

Sorry for late response - I cannot reproduce this anymore after I have uninstalled the app and installed it back. Most probably it was caused by parse sdk update when the app installed was once run with an older sdk. There is also another guy having the same problem here https://groups.google.com/d/msg/parse-developers/c2HL3kmqWWU/XehgdSlqCQAJ
last comment in that thread is mine so just ignore it - i copied it here.

FYI - in my case the app was also not crashing, just not loading the files from cache and showing in the console the exception I originally posted. Seems like the exception was caught somewhere.

My issue seems to be different that the one on the Parse Developers Google Group thread. I am not getting an NSException, but instead I receive the following error each and every time I try to load a PFFile image:
[Error]: Response status code was unacceptable: 400 (Code: 1, Version: 1.9.1)

Ok then I guess you should open a new issue. BTW, I got the error again, I will try to dump some data here...

@nlutsenko should I move this off to a new thread? I started one a day ago. Issue #536

@nlutsenko you were right, the url is null....
What I'm doing is fetching the user in background to update all the fields. Then, when finished, doing a check like this:
PFFile *userImageFile = user[@"picture"];
if ((userImageFile == nil) || [userImageFile isKindOfClass:[NSNull class]]) {
    // no image is stored in DB
    return;
}
NSLog(@"user image url %@", userImageFile.url);

In this particular case the PFFile is ok but the url is null - the above code outputs "user image url (null)". Although there IS a valid image stored on Parse side in that column. If this is normal then let me know how to get my image and feel free to close this issue.
Thanks!

@frangulyan Can you point me to the URL that you see on the server?
Also - your app name would help tremendously, since I can't really reproduce an issue without looking at the way the image is stored here.

the url is [here] (http://files.parsetfss.com/7c0e4c0f-b1b8-41c4-a38e-fc23addfe59f/tfss-579f6556-5564-4a05-9d8c-27782508c1db-profile.png) and the app name is weeto

@frangulyan, could you tell me the user objectId where you have this file attached?
The thing is - we don't ever expect for a URL to be nil for any file that is being fetched from parse.com
If you use the REST API via say, curl, - does it return a file field with null url as well?

Sure, the user id is IhfZepZ8SW, column "picture". I'm not familiar with REST API so I'm not sure that I will be able to make that request without some help :)

@frangulyan The URL that you posted above is different from the one that is stored on Parse (that's still OK).
I tried via REST API myself - it works great, nvm.
Can you attach a repro project here, or send it to nlutsenko (at) fb.com, I can't seem to reproduce an issue at all.

The thing is that after reinstalling the app the issue is usually gone. I just dumped the file attributes and got name='file' url='null' and 'isDirty'=1. One short clarification on the logic to understand if I'm doing it right. I'm doing fetchInBackgroundWithBlock on user and when it's done I'm taking its file column. Should I also fetch this file column to fill the info in that PFFile or fetching the user will bring everything needed to immediately call getDataInBackgroundWithBlock?

Fetching the user should download all the fields for that user automatically, including all the required information for the file field.
As I said before, since I can't reproduce the issue locally - can you attach or send a repro project?
That would be a tremendous help in identifying why this issue happens for you as well as will speed up fixing it.

I just reinstalled the app (it's in simulator but I noticed similar stuff on the device) and the issue is gone. The file properties are name='tfss-b73775f4-660d-490a-942f-3491998082a5-profile.png' url='https://files.parsetfss.com/7c0e4c0f-b1b8-41c4-a38e-fc23addfe59f/tfss-b73775f4-660d-490a-942f-3491998082a5-profile.png' isDirty='0'.
I guess sending a repro project will not help you since you will not be able to reproduce just like I cannot after the reinstall. But maybe creating a small project and being able to reproduce will work, if I would also send you some files and caches from apps directories.
Anyway, I will get to it tomorrow, it's 3:30 AM in Germany and I need to wake up soon for work...
Дуже дякую ;)

Sounds good :wink:
Any kind of repro would work great!

Hey Nikita,
I'm terribly sorry, after digging and debugging for 3 hours it comes out to be my bug.
What happens is that I fetch PFUser data which brings PFFile in one of the columns (user picture). Then I download it, use it in UI and everything is fine. But at some point I (wrongly) assign a new PFFile with same image data to that column (kind of user wants to upload a new picture):
NSData *imageData = UIImagePNGRepresentation(userImage);
PFFile *imageFile = [PFFile<EMAIL_ADDRESS>data:imageData];
user[@"picture"] = imageFile;

After those lines the url becomes null - which I assume to be OK since the file is not yet uploaded to Parse. Then I guess sometimes I was doing some actions which were saving the whole user data (like changing email). Restarting the app was either crashing (if I didn't save before and the file was loaded from local data store with null url) during a fetch try or working normally (if I saved it before).
Does this all make sense to you or it is still not the behaviour that you would expect and I missed something?

Hey @frangulyan, that sounds about right. I am glad you were able to find the reason behind this.
Not sure how you end up with an unsaved image on currentUser, since it shouldn't allow you to persist it locally. One thing that comes to my mind - is that your user gets persisted somehow on a failed save to disk, but the file is not yet uploaded, so it persists the file with a nil URL.
I would suggest adding a check for url on your user object there, and if it doesn't have a URL - you can revert the changes for the file key by using PFUser.currentUser().revertObjectForKey("picture"), or simply try recreating the picture (if you have data for it somewhere else), or even remove the dangling file for that key.
I still am curious on how you end up with an unsaved file on a currentUser() object, since we don't epxect this behavior for any given PFFile and it shouldn't happen.

Ok I found a way to reproduce it and isolated in a small piece of code for you. I will send the test project to the email you mentioned above.

Ok I've sent it. Since it is the whole project including the frameworks it is a bit heavy - 17MB. Hopefully it will reach you without problems, let me know if you got it and are able to reproduce the issue.

@frangulyan got the project, am able to reproduce an issue, turns out to be an absolutely valid way of doing this and it's indeed a bug in our code.
Looking into ways to fix it...
Likely will simply attach a pull request to this issue and auto-close by merging that fix.

Multiple actionables:

I am going to send a fix for this issue soon. It won't crash anymore, but report an error instead.
I've created a feature issue #560 that tracks offline PFFile persistence

Current workaround for your case:
Persist the file you are going to save to a different place in addition to PFFile if you care about cross-app run persistence, since this is not yet supported on PFFiles. You will also be able to look at the error on trying to get/save the unsaved PFFile without a URL and local file, and reset that field to a new file that you've persisted elsewhere.

I will do that, I'm glad I could help! Also your support was amazing, thanks :)


Add substring method for String

This adds an implementation for String's substring() method along with some tests for it and a test for the existing length getter.
Fixes: #26

LGTM


Question/Proposed enhancement

Is there a reason you're not using the CMakeDependentOption CMake module for handling option dependencies?
i.e., ENABLE_GMOCK depends on ENABLE_GTEST,  ENABLE_FRUIT depends on ENABLE_FORTRAN etc.
It would be easy to work up a PR to include this capability. CMake support goes as far back as at least 3.0 if not earlier.

Thanks for the suggestion.  I wasn't aware of this macro.
This seems like it could clean up some of our internal logic.

Let me know if a contribution here is welcome or if you'd prefer to look at this on your own.

If you're interested, we'd definitely welcome the contribution.


v1.1.8.jar can't work on eclipse.

Caused by: java.lang.reflect.InvocationTargetException
Caused by: java.lang.NoClassDefFoundError: Failed resolution of: Lcom/daimajia/swipe/R$styleable;
Caused by: java.lang.ClassNotFoundException: Didn't find class "com.daimajia.swipe.R$styleable"

me  too

@asdfers @tanranran I noticed this problem, tried to fix this, try the following jar file.
classes.jar | uploaded via ZenHub

ok,solved!


[edn/rtl] field enable has just two valid values

For any field enable, only 0xa and 0x5 take action.
Signed-off-by: Mark Branstad<EMAIL_ADDRESS>

sorry if i missed part of the discussion @mwbranstad , but can you elaborate a bit on the reason we're adding an extra set of flops on the output to do the enable/disable?
could we do something that's just blah.q == On and consider all others off? I'm not seeing the benefit of the extra storage at the moment.

@tjaychen thanks for picking up on this. I wanted to discuss this at the last entropy meeting, but attendance was very light, so just made a decision and went with it. However, we could certainly export the controls from the reg_top block and feed this field enable block, so only one set of flops per bit would be implemented. Was looking for security guidance here. Also, regarding valid states, I believe myself, steve, and ziv all concluded that forcing the off state could be harmful as well. With this circuit, only two states out of 16 are valid. Again, that was another topic at the last entropy meeting.

@tjaychen @cdgori @moidx this PR is ready for a new review.


ENH: Allow configuring RunEngine context managers

Description

An alternative to #1007, this allows the user to add or remove context managers for the run loops as they see fit.
Motivation and Context

Unlike #1007, this pulls us away from the path of having many different RunEngine classes in some awful inheritance hierarchy, and gives us clear ways to run without the sigint handler or with extra locks as we need them.
How Has This Been Tested?

This still passes the bluesky tests. An additional test should be added to make sure we can use other context managers.
This can probably be cleaned up more, but I wanted to start discussion.

Codecov Report

Merging #1008 into master will increase coverage by 0.04%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master   #1008      +/-   ##
=========================================
+ Coverage   90.25%   90.3%   +0.04%
=========================================
  Files          50      50
  Lines        8044    8021      -23
=========================================
- Hits         7260    7243      -17
+ Misses        784     778       -6

Impacted Files
Coverage Δ

bluesky/run_engine.py
96.25% <100%> (+0.49%)
:arrow_up:

Continue to review full report at Codecov.

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

I prefer this PR to #1007. More flexible and avoids complicated inheritance.

I agree with Teddy’s comment. Nice approach here. — Ghost of @danielballan, writing from a waiting room on a New Dad errand


Correct README URL typo

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Good catch! Thanks @joeltoby


Enable output in html while blocking it from user side and keeping unsafe_allow_html:false

It's obvious that unsafe_allow_html should always be set to false to disable script injections on user side, however LLM and system responses need often to be displayed in html format. Is there a way to authorize only system and LLM responses to be displayed in html?
thanks a lot for considering this.

Could you update the function to accept setting unsafe html to true only for LLM response like this for example?
cl.Message(content=llm_response, unsafe_allow_html=True).send()

I would suggest maintaining the existing functionality and if needed add this ability for your use case. Some of us use Chainlit in an internal corporate environment with very limited and monitored access aimed at business users, so script injection is not much of a concern and can be blocked in other ways. Generally I believe we should limit breaking existing functionality, as this has been a source of much pain for this community.

I don't really agree that this breaks the existing functionality if it is designed as part of the product

Security including preventing script injection is a real concern whether you use the tool internally or externally.  This can be contained by preventing html through unsafe_allow_html=false. If you set this to true then there are no 100% secure ways to prevent injections despite any sanitization methods you would use. Does anyone really think that because a tool is exposed internally only that it makes it secure by nature?

I was requesting from the chainlit core team to include the possibility to inject html in the LLM response like this example.
cl.Message(content=llm_response, unsafe_allow_html=True).send() when the unsafe_allow_html=False globally for users.
If there are better ways to allow such exception then why not.

I don't see why we cannot conciliate between user friendly rendering (in html) and keeping the solution secure from any script injection.


Many set-cookie headers are sent for a single response

I am implementing my custom local provider.
Here are the response headers for the login endpoint:
HTTP/1.1 201 Created
set-cookie: nuxt-session=<redacted>; Path=/; HttpOnly; Secure; SameSite=Lax
set-cookie: nuxt-session=; Path=/; HttpOnly; Secure; SameSite=Lax
set-cookie: nuxt-session=<redacted>; Path=/; HttpOnly; Secure; SameSite=Lax
set-cookie: nuxt-session=<redacted>; Path=/; HttpOnly; Secure; SameSite=Lax
content-type: application/json
[...]

I feel like I shouldn't get that much new session ids. For one request, 3 sessions are created and 1 is destroyed?
This is my implementation, which could be one of the causes of this havoc:
/server/api/auth/login.post.ts
export default defineEventHandler(async (event) => {
  // log(getResponseHeaders()) n°1

  await requireGuestSession(event);
  // log(getResponseHeaders()) n°2

  const body = await readBody<MyUserInterface>(event, { strict: true });
  const user = await accountController.verify(body);

  await replaceUserSession(event, { user });
  // log(getResponseHeaders()) n°3

  setResponseStatus(event, 201);
  return user;
});

logs:
[Object: null prototype] {} // n°1
[Object: null prototype] { // n°2
  'set-cookie':
   [ 'session_id=<redacted>; Path=/; HttpOnly; Secure; SameSite=Lax' ] }
[Object: null prototype] { // n°3
  'set-cookie':
   [ 'session_id=<redacted>; Path=/; HttpOnly; Secure; SameSite=Lax',
     'session_id=; Path=/; HttpOnly; Secure; SameSite=Lax',
     'session_id=<redacted>; Path=/; HttpOnly; Secure; SameSite=Lax',
     'session_id=<redacted>; Path=/; HttpOnly; Secure; SameSite=Lax' ] }

After calling requireGuestSession, which internal just uses getUserSession, a new session id is set. Why is that so?
Then, after replacing the user session, 3 different cookies are set, 1 empty, and 2 new session ids. Is it really necessary?
Please feel free to let me know anything I've missed, I feel it is the case (:

But what is the main HTTP response that you receive in the browser?


Rigging coin flips in duels

is there an option to make th call coin toss always right in your advantage? like when time wizard activate it's effect he call it right? or any other card xD it will be fun.

Duplicate of #283


question: headers alongside react-navigation

I'm using expo, react-navigation for navigation and headers and native-base for the UI controls in the content area. Is there anyone who has experience using native-base navigation controls (like Header and Drawer) while using react-navigation?
Is it straight forward to do or generally not a good idea?

Please follow issue template
Also that this seems some sort of discussion. NativeBase Forum, SO, NativeBase Slack is an appropriate platform for this

@jannikbuschke did you find a fix?

@gsouf works okish together. I have run into issues (layout moved down and out of screen display about 8px or so), but was somehow able to fix everything. Its a bit annoying, as somehow all of the following parts could theoretically interfere:

expo (has androidstatusBar settings in appmanifest)
react-navigation (I use it for drawer UI component and different router logic, i.e. drawer, stack without header, switch)
native-base (to actually render headers)
react-native SafeAreas (for nodges)

somehow it works all together, but there was a bit trial and error necessary. Also overall the setup feels kind of weak.

@jannikbuschke I got it fixed too, just disabled header in react-navigation (their doc is not very good, it was challenging by itself to find the right option). Just have to use null for defaultNavigationOptions.header.
const AppNavigator = createStackNavigator(
  routes,
  {
    defaultNavigationOptions: {
      header: null
    }
  }
);

Then for react-native-web I had to get the wrapper html element to use the following css:
height: 100vh;
display: flex;

UPDATE for React Navigation 5.x
If you want to use Nativebase's header with react navigation 5, you can do it like this:
    import { NavigationContainer } from '@react-navigation/native';
    import { createStackNavigator } from '@react-navigation/stack';

    import {
      Header,
      Left,
      Body,
      Title,
      Button,
      Icon,
      View,
      Text
    } from 'native-base';

    const Stack = createStackNavigator();

    const Home = () => {
        return (
            <View>
                <Text>Hello World</Text>
            </View>
        )
    }

    const CustomHeader = ({scene, previous, navigation}) => {
      const {options} = scene.descriptor;
      const title =
        options.headerTitle !== undefined
          ? options.headerTitle
          : options.title !== undefined
          ? options.title
          : scene.route.name;

      return (
        <Header>
          <Left>
            {previous ? (
              <Button transparent onPress={navigation.goBack}>
                <Icon name="arrow-back" />
              </Button>
            ) : (
              undefined
            )}
          </Left>
          <Body>
            <Title>{title}</Title>
          </Body>
        </Header>
      );
    };

    const App = () => {
        return (
            <NavigationContainer>
                <Stack.Navigator initialRouteName="Home">
                    <Stack.Screen
                    name="Home"
                    component={Home}
                    options={{
                    header: (props) => <CustomHeader {...props} />,
                  }}
                    />
                </Stack.Navigator>
            </NavigationContainer>
        )
    }

More of the options here https://reactnavigation.org/docs/en/stack-navigator.html


Provide as yeoman generator

Hi, thanks your great work.
frasco is awesome tool for me.
I have an idea to enhance frasco.
I'd like to make yeoman template of frasco.
When I have created website with frasco, I needed to change README , package.json , git/config and so on.
How about it? If you agree my idea, I'll do it.

Thanks @Kuchitama !
This is a great idea. I'm also thinking to have a frasco command to generate Frasco projects. https://github.com/ixkaito/frasco/tree/v0.6
I don't know whether Yeoman is the best solution, but it's OK to start with Yeoman at first. I'm glad to receive pull requests from you.

What about making it a gem ?

@ginfuru Thanks for your idea. Gem can also be a solution. Maybe we can make Frasco available for both npm and gem.


update intl

@johnpryan Please, can you accept this pull request?

I'm not part of the apptreesoftware org, let me see if I can get this transferred.

@matthewtsmith can you approve pull request and publish package?


AMBARI-23740 JS error after installing Ranger from Install Wizard - Smart Configs are broken - page refresh fixed the issue

How was this patch tested?
21532 passing (29s)
48 pending

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/2079/
Test PASSed.


Analyzer should recognize features not accepted by a package's minimum required SDK version.

Example: In Dart 2.1, the dart:core library re-exports Future and Stream from dart:async.
If you write a package and use Future or Stream without an import, the 2.1.0 analyzer will say that is perfectly OK. However, if your pubspec SDK version requirment allows a 2.0.0 SDK, then the code might not work there.
Similarly, Dart 2.1 introduced the ability to use integer literals in a double context, as a shorthand for the double litteral. Again, code using this with an SDK requirement below 2.1.0 is not correct.
Each Dart SDK released can introduce new non-breaking language features or library extensions. The analyzer should keep track of those changes and compare them to the minimum required SDK allowed by a package.
For language features, the versioning information will likely need to be hard-coded into the analyzer.
For library changes, we could introduce an annotation like @Since("2.1") on new parts of the API, which would apply to entire libraries, exports, single declarations, or even individual parameters.
(We can't mark API removals that way, but removals are breaking changes, so we will likely only do them on major version increments anyway. We can add version numbers to deprecations before we remove the feature, so something can be @Deprecated(since: "2.2"), but I'm not sure that's actually helpful. Or we can document removed fatures @Deprecated.andRemoved(namedArgument: #foo).)
It might be easier to just maintain a structured API changelog on the side.

I actually argued for several years that analyzer would need to be aware of the differences between different versions of the SDK for exactly this reason. The answer I was given is that users are expected to use the version of the tools that were shipped with the version of the SDK that they're using. While I don't object to being proved right :-), I will point out that providing this level of support would probably be a non-trivial amount of work, so we'll need to schedule that work.
I'll also point out that unless the front end team is willing to take on this additional support (@kmillikin), adding this requirement for the analyzer would place additional difficulties in the path of eventually getting the analyzer ported over to use the front end. I'm not sure we want to make that goal harder to achieve.

cc @a-siva @zanderso @vsmenon I think this is essentially the same issue we discussed a week or so ago.  I think @zanderso was going to delve into it a bit more.  It's not just an issue for the SDK: flutter has the same issue (if they add to their API, then code written against that new API is not compatible with older flutter SDKs).

FYI @tvolkert

Pub is another potential place to implement a check since the problem surfaces when the package is published. https://github.com/dart-lang/pub/issues/1981

I think the analyzer is a good place to do the checking. it can alert the user while they are writing, and it's (probably) a simple quick-fix to update the SDK requirement in the pubspec.yaml file.
Pub can do the same thing too, but that would just amount to analyzing the package source again.
My main question is probably which metadata is needed to actually do this.
I'm fine with adding @Since("2.1") annotations on the APIs, that would solve the problem for Future and for any other API changes.
It will not handle language changes. That will require the front-end to let the analyzer know which language features are used (no desugaring integer literals in double contexts into double constants before passing it to the analyzer). That's probably necessary anyway, otherwise the analyzer can't give good enough warnings.
I'm willing to start with @Since annotations. WDYT?

... a simple quick-fix to update the SDK requirement ...

Yes, that would be easy to implement.

It will not handle language changes.

As I understand it, the plan, going forward, is for every new feature to initially be implemented behind an "experiment" flag. My initial assumption was that when the experiment was enabled by default that we would remove all of the references to that flag in the analyzer code base.
But one possibility for supporting multiple versions would be for analyzer to always keep that functionality behind the flag and to keep track of which experiments are enabled by default in each version. When a package is to be analyzed, analyzer could look to see which SDK is being used and enable the appropriate set of flags.
(It makes me kind of sad to think about the kind of code we'll need to have in the analyzer to deal with all of the different versions of the SDK. It won't be easy to maintain.)
There's another aspect of this: we need to be able to analyze a package against the same version of the SDK's APIs as the version of language features. If we're getting the APIs from the SDK and the set of language features from the version constraint in the pubspec, then we can easily have inconsistencies.
I think the better approach is for the information about which features are supported to be included directly in the SDK. When analyzer finds the SDK to be used (how it finds it can be a separate discussion if the current approach is not adequate), it can get everything it needs to know about both language features and the API (and the two pieces of information will always be consistent).
Analyzer can check to see whether the SDK matches the minimum bounds defined in the pubspec and let the user know if the two don't match.
I'll note that getting all of the information from the SDK also allows us to analyzer code that does not have a pubspec.

We plan to have some sort of language-version opt-in/out, likely on a per library basis.
A library will uses the newest language version unless otherwise restricted. It can be restricted by having an explicit lower language version written in the library file, or by being in a package with a lower SDK version dependency.
It does mean that when a language feature is enabled by default, it can still be disabled by the library opting to be compiled using a lower language version. You can just be certain that if a feature is disabled, so are all features added in the same or later language versions, so the implementation of a feature can always depend on all features that are not newer than itself.
When we do get the language-version opt-in/out feature, we will say that experimental features only work in libraries that are compiled using the most recent language version. You can't go back and use 2.1 language semantics with a single 2.4 feature. You have to be on language version 2.3 to use experimental features planned for 2.4.
The default language version used by the libraries of a package is derived from its SDK version constraint. That would mean that experimental features are always disabled if you are not depending on the actual SDK that you are using. Individual libraries may opt for a lower language version, then they will not see experiments either.
So:

Packages specify their SDK dependency in the pubspec.
Language changes are handled as progressive versions. We enable compiling at older versions to allow gradual migration. Language experiments only work on top of the most recent language version, until they become the new language version. A package should not/cannot opt any library in to a version newer than its pubspec SDK version, which is also the default language version for its libraries. The analyzer (and all language tools) must be able to run without newer features. This should be easy if the features are developed below a flag to begin with.
Library changes are non-breaking. We can mark changes with @Since markers. The analyzer can warn if a library uses SDK features newer than its pubspec SDK version.

The analyzer should not need to know about more than one set of SDK libraries. It does need to know about language features and which version they are enabled from. For incremental changes, it's fine to parse the feature and then report an error. For breaking language changes, the same syntax may be valid in both versions and mean something different.

Related https://github.com/dart-lang/sdk/issues/35158

Note that #35158 illustrates a specific instance of this bug that is proving particularly troublesome, even for google-owned packages: package owners are beginning to rely on the fact that as of SDK version 2.1.0-dev.5.0, dart:core exports Future, but they aren't updating their pubspecs to reflect that.  As a result, users who are still on SDK version 2.0.0 are getting errors.  We may want to write a special case lint to address this particular issue with Future ASAP, even if it takes us longer to address the general case.
Escalating to P1.

Can we get this assigned to the 2.1 SDK milestone? As soon as this is in a public release it will become a much bigger issue, and we won't be able to easily fix it for those users for a long time (until 2.2...)

a specific instance of this bug that is proving particularly troublesome, even for google-owned packages

That is the same flag I raised when the feature was first introduced:
https://github.com/dart-lang/sdk/issues/26162#issuecomment-419549832

I can take a quick look at this today since its close to my ❤

Just to add to your troubles: The goal is to give people a warning if they use a feature which is only available through a declaration with a @Since annotation with a version later than their min-SDK requirement.
The Future export from dart:core was a good example of that.
If you import dart:async as well, you have two imports which expose the same declaration (dart:async::Future), and only one has a @Since annotation (on the export itself), so there is no need to warn, even with a 2.0.0 min-SDK.
Similarly, the BytesBuilder was previosuly exposed only by dart:io, but later also by dart:typed_data. (And I now notice that export lacks the @Since, the other one has a @Deprecated though).

Ok, unassigning myself then 🤣 . It doesn't sound like something which I can reasonably fix in a short timeframe.

Should we consider removing all @Since annotations, and converting them to simple doc comments? At least until we have actual support?
Currently we are promising something that does not exist.

If we remove the annotations then there won't be any motivation to add the support.
As for the implementation, we have other (non-annotation-based) checks for the use of language features that are not supported by the min SDK version, and the same pattern could be followed.

But there doesn't seem to be any plan to implement this, the request is over 3 years old and there is no active work scheduled.
If we aren't going to implement it, we should stop pretending we do, imo. Or, we should get it prioritized to a level that it will get on OKRs.

I think there's an interesting assumption here that I'd like to make explicit in order to confirm: annotations that are not statically checked have no value.
If so, I'd like to challenge that assumption. I think that annotations are at least as good a way to express intent / contracts as documentation comments. I actually think they're often better because, for me at least, it's harder to miss the presence of an annotation than it is to miss a sentence somewhere in a doc comment.

Or, we should get it prioritized to a level that it will get on OKRs.

Personally, I think that this is too small an item to make it appropriate for OKRs. But ignoring that, it sounds like you think that it hasn't been prioritized correctly relative to the items that have made it onto the OKRs. Am I misunderstanding what you're saying?

I think that annotations are at least as good a way to express intent / contracts as documentation comments.

When I see an annotation, I assume it is there for some tool to read. I am not aware of any annotations that are not consumed by a lint or something else.
So when we started adding these annotations, I have assumed for a long time now that the analyzer was checking them, and I have been relying on that to know when I need to increase my min SDK constraint. We are often fairly good about running tests on stable SDKs in our own packages, and so we probably haven't actually made a mistake here, but I do feel like the annotation is making a promise that it isn't keeping.
So  it isn't that I don't think the annotation does a good job of communicating things at a textual level, but more that there is some additional implicit support that I assume when I see an annotation, which I wouldn't assume from just a doc comment. So from my perspective it is better not to have the annotation, than to not have any tool reading it. But that is just my personal opinion, because I was myself tricked by it into thinking something was supported which was not.

Personally, I think that this is too small an item to make it appropriate for OKRs. But ignoring that, it sounds like you think that it hasn't been prioritized correctly relative to the items that have made it onto the OKRs. Am I misunderstanding what you're saying?

Whether it is on OKRs or not, I do think this should be highly prioritized. It is a very useful feature that prevents people from falling into a very easy trap (using an api that doesn't exist on an SDK they claim to support).
Yes, people should be running their tests on both their minimum and maximum SDK constraints. But they don't do that often in practice, and even on the Dart team there is not agreement that it is worth doing it, and it is likely not consistently done across all our packages.

When I see an annotation, I assume it is there for some tool to read.

Thanks! I understand your perspective better now.

It is a very useful feature that prevents people from falling into a very easy trap ...

I agree that this would be a useful feature, so I'm going to increase the priority of the issue. Hopefully it can get addressed fairly soon.

If we can get support for @Since on entire methods and arguments I think that would be worth doing, even if we don't get support for @Since on exports. I suspect that if we can implement support for deprecating exports (https://github.com/dart-lang/sdk/issues/48807) then the implementation could look similar for @Since

@bwilkerson @srawlins - can we either:

keep this as a P1, assign it to someone, and aim for an upcoming release
downgrade to P2

?

Thanks for the ping, @vsmenon. I've added this to our agenda for tomorrow's meeting, and have downgraded it to P2 for now. We'll have a firmer plan tomorrow.

OK we decided to leave this as a P2. It certainly was more like a P1 with the Dart 2.1 issues of exporting Future from core, but that is certainly affecting users less now. There was a consensus that this is an important feature, and it is added to our next planning doc.
It also sounds like the common case (e.g. referencing a class which is new in some version and doesn't exist in a previous release) should be easier to implement. The case of "this element is newly being exported" is trickier, and can be implemented separately, and needs some groundwork.

FYI, we encountered another instance recently where this feature would have been useful.  In 63b49dfc8ef255f39856e5a73ed8fbe465f2678a, a new method was added to the SDK and used in the analyzer in the same commit; this doesn't work because the analyzer is published on pub (and hence has to work with older SDK versions).  Fortunately I noticed the problem because I checked out the latest analyzer codebase with an SDK that was a few days old.  However, as soon as I build the latest SDK there won't be any safeguard to stop me from accidentally starting to use that method again.


[CallWithChat] Copy Invite Link margin added and sidepane cancel button border radius styled

What
[CallWithChat] Copy Invite Link margin added and sidepane cancel button border radius styled

Why
Copy Invite link was too close to the edge of the browser.
https://skype.visualstudio.com/SPOOL/_workitems/edit/2777071
Cancel button hover highlight border radius did not match other button styles.
https://skype.visualstudio.com/SPOOL/_workitems/edit/2777072

How Tested
Tested locally on CallWithChat Sample
Process & policy checklist

[x] I have updated the project documentation to reflect my changes if necessary.
[x] I have read the CONTRIBUTING documentation.

Looks like an icon in messed up after code changes

Looks like an icon in messed up after code changes

That's odd as my diff shows the icon and my locally ran sample shows the icon as well.
Do you still have the icon missing @anjulgarg ?

Looks like an icon in messed up after code changes

That's odd as my diff shows the icon and my locally ran sample shows the icon as well. Do you still have the icon missing @anjulgarg ?

I believe this is a timeout issue with the update snapshots CI, I am seeing it in my PR's as well but depending on the run it will be correct. its happening to me in this PR: https://github.com/Azure/communication-ui-library/pull/1579

Looks like an icon in messed up after code changes

That's odd as my diff shows the icon and my locally ran sample shows the icon as well. Do you still have the icon missing @anjulgarg ?

I believe this is a timeout issue with the update snapshots CI, I am seeing it in my PR's as well but depending on the run it will be correct. its happening to me in this PR: #1579

Yes, I have seen this in my PR too. Filed this bug https://skype.visualstudio.com/SPOOL/_workitems/edit/2782334. This issue is not related to the changes in this PR


CoreSightTarget selected_core changes

Very minor changes.

The selected core is inited to None, then is set to the core number of the first created core.
selected_core property returns None if no cores have been created.
reset() performs a hardware reset if selected_core returns None.

/morph test


Remove duplicate GitHub Action (vs. Jenkins)

We still run (and need to run) Jenkins CI checks on this repo, so having
GitHub Actions adds no value; it's also confusing when the GA checks pass
but the Jenkins ones don't (or vice versa). This removes them pending a
plan to fully switch over.*
*This is currently in progress for Smart Answers.
:warning: This application is Continuously Deployed: :warning:

Merged changes are automatically deployed to staging and production.

Make sure you follow the guidance for deployments before you merge.

Check your branch is being deployed in the Release app, after merging.

We've found this pretty useful for content people working on yaml updates to campaign pages. Would you mind keeping it around for now?

Ah sure, OK. As long as it's useful for someone...


[CC scenario] gc-ttl timeout works not expected

What did you do?

Pause changefeed: tiup ctl:v5.3.0 cdc changefeed pause -c mysql-task-1 --pd=http://<IP_ADDRESS>:2379
{
"id": "mysql-task-1",
"summary": {
"state": "stopped",
"tso":<PHONE_NUMBER>69691685,
"checkpoint": "2021-12-19 08:52:23.317",
"error": {
"addr": "<IP_ADDRESS>:8401",
"code": "CDC:ErrPeerMessageClientClosed",
"message": "[CDC:ErrPeerMessageClientClosed]peer-to-peer message client has been closed"
After more than 24hours, resume this changefeed

What did you expect to see?

The changefeed status becomes error since gc ttl timeout reached.

What did you see instead?

After resume the changefeed, there's not gc-ttl timeout ERROR as expected, actually the checkpoint moves on...

changefeed config:
[2021/12/17 09:08:20.638 +08:00] [INFO] [server.go:75] ["creating CDC server"] [pd-addrs="[http://<IP_ADDRESS>:2379,http://<IP_ADDRESS>:2379,http://<IP_ADDRESS>:2479]"] [config="{"addr":"<IP_ADDRESS>:8401","advertise-addr":"<IP_ADDRESS>:8401","log-file":"/data2/upstream-cc/cdc-8401/log/cdc.log","log-level":"info","log":{"file":{"max-size":300,"max-days":0,"max-backups":0}},"data-dir":"/data2/upstream-cc/cdc-8401/data","gc-ttl":86400,"tz":"System","capture-session-ttl":10,"owner-flush-interval":200000000,"processor-flush-interval":100000000,"sorter":{"num-concurrent-worker":4,"chunk-size-limit":134217728,"max-memory-percentage":30,"max-memory-consumption":17179869184,"num-workerpool-goroutine":16,"sort-dir":"/tmp/sorter"},"security":{"ca-path":"","cert-path":"","key-path":"","cert-allowed-cn":null},"per-table-memory-quota":10485760,"kv-client":{"worker-concurrent":8,"worker-pool-size":0,"region-scan-limit":40},"debug":{"enable-table-actor":true,"enable-db-sorter":true,"db":{"count":8,"concurrency":128,"max-open-files":10000,"block-size":65536,"block-cache-size":4294967296,"writer-buffer-size":8388608,"compression":"snappy","target-file-size-base":8388608,"write-l0-slowdown-trigger":2147483647,"write-l0-pause-trigger":2147483647,"compaction-l0-trigger":160,"compaction-deletion-threshold":160000,"iterator-max-alive-duration":10000,"cleanup-speed-limit":10000},"messages":{"client-max-batch-interval":100000000,"client-max-batch-size":8192,"client-max-batch-count":128,"client-retry-rate-limit":1,"server-max-pending-message-count":102400,"server-ack-interval":100000000,"server-worker-pool-size":4}}}"]

Versions of the cluster
Upstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):
(paste TiDB cluster version here)

TiCDC version (execute cdc version):
(paste TiCDC version here)

Close it, because tikv gc ttl already set to 100days, it's expected


APNG are convented to static PNG

The conversion removes all but 1st frame

I've released new version 1.5.0 of image_size which includes detection of apng, which should make image_optim ignore apng images. I will also update dependency so image_optim requires new image_size.
Adding support for optimising apng images is a separate issue, as most or all used png tools don't support properly optimising them.

Please reopen if needed.


Automatic PR from RestAPI-PR1635

Generated from RestAPI PR: https://github.com/Azure/azure-rest-api-specs/pull/1635

Codecov Report

Merging #1435 into master will decrease coverage by <.01%.
The diff coverage is 43.2%.

@@            Coverage Diff            @@
##           master   #1435      +/-   ##
=========================================
- Coverage   52.61%   52.6%   -0.01%
=========================================
  Files        3344    3347       +3
  Lines       85048   85128      +80
=========================================
+ Hits        44746   44780      +34
- Misses      40302   40348      +46

Impacted Files
Coverage Δ

...e-mgmt-sql/azure/mgmt/sql/sql_management_client.py
100% <100%> (ø)
:arrow_up:

...ure-mgmt-sql/azure/mgmt/sql/operations/__init__.py
100% <100%> (ø)
:arrow_up:

azure-mgmt-sql/azure/mgmt/sql/models/__init__.py
100% <100%> (ø)
:arrow_up:

azure-mgmt-sql/azure/mgmt/sql/version.py
100% <100%> (ø)
:arrow_up:

...ure/mgmt/sql/models/sql_management_client_enums.py
100% <100%> (ø)
:arrow_up:

...l/azure/mgmt/sql/operations/database_operations.py
28.26% <28.26%> (ø)

...mt-sql/azure/mgmt/sql/models/database_operation.py
29.41% <29.41%> (ø)

.../azure/mgmt/sql/models/database_operation_paged.py
80% <80%> (ø)

... and 1 more

Continue to review full report at Codecov.

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

Version 0.8.1
New features:

Added support for listing and canceling management operations on a database.


Escape characters stripped in CDN version

After I noticed several broken web pages in my projects, I began to investigate and found the cause to be several modules which were imported from cdnjs.com. Upon closer inspection, I determined that the minified source code did not match the original source code, because critical escape characters have been removed in the minified source code.
Of the affected modules I discovered, I found these responsible for breaking my web pages:
https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/languages/xml.min.js
https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/highlight.min.js
After checking the same modules on jsdelivr.net, I have found the same issue.
Specifically, there are <\/script> strings in the source code which have their backslashes removed from the documents, causing the browser to end <script> elements earlier than it should.
I have verified that the original source code does indeed contain the backslashes, and I cross-checked the release version with this repository based on commit, therefore the only possible cause left is the process in which these files are minified.

Can you confirm this is still an issue with latest version on CDN?

I think the issue is now resolved. I have inspected the version 9.15.10 source code on the CDN and it appears to be corrected now. I also crosschecked the source code on the CDN with the source code of the 9.15.10 release commit tree for good measure. :)

Thanks!


Links

This fixes an issue where internal page links inserted with Draftail always pointed to #.
I also added some unittests.

Is there anything I have to do to get this PR merged?

... and merged!
@thijskramer we would be really interested in your feedback using this module, from the developer's perspective. It sort of works but is still really fresh, and we have a big backlog of improvements that is proving hard to prioritise.


Implement signing and voting interfaces

Merging this should close #418 . Note that we're not authenticating data messages as both enum variants are handled in other ways. Notably, we expect transaction authentication to be done by the application layer. And newest QC is unused.


feat: expander init

Issue #, if available:
Description of changes:
Adds a new expander renderer under view renderer
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Codecov Report

Merging #599 (698aa23) into tagged-release/forms-and-views (ebd3c46) will decrease coverage by 0.19%.
The diff coverage is 81.57%.

@@                        Coverage Diff                         @@
##           tagged-release/forms-and-views     #599      +/-   ##
==================================================================
- Coverage                           90.74%   90.55%   -0.20%
==================================================================
  Files                                  87       88       +1
  Lines                                3285     3356      +71
  Branches                              891      916      +25
==================================================================
+ Hits                                 2981     3039      +58
- Misses                                285      298      +13
  Partials                               19       19

Impacted Files
Coverage Δ

...erate-view-definition/generate-table-definition.ts
95.00% <50.00%> (-5.00%)
:arrow_down:

.../lib/amplify-ui-renderers/amplify-view-renderer.ts
77.77% <71.42%> (-4.05%)
:arrow_down:

...es/codegen-ui-react/lib/react-expander-renderer.ts
82.14% <82.14%> (ø)

.../codegen-ui-react/lib/views/react-view-renderer.ts
80.46% <90.00%> (+0.79%)
:arrow_up:

packages/codegen-ui-react/lib/index.ts
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Add frontend

Hello, thanks for your hard work!
Wanted to ask if you could add frontend from this https://github.com/harubaru/waifu-diffusion repository (it's in scripts folder - called txt2img_gradio.py)

Thanks for the suggestion, but I'm not sure that's worth doing now. At some point soon the whole ecosystem will be replaced by interactive image editors that make calls into a stable-diffusion backend. By the time I have understood gradio and have done the implementation, there are going to be so many better solutions!
If there's a developer out there who is versed in gradio and wants to do the implementation, I'd very much welcome a contribution.

Personally I don't see a benefit of GUI over terminal atm. When inpainting feature will be implemented by somebody it would be very nice to have a GUI to paint over image to specify areas that user wants to be redrawn by AI while keeping all other parts of the original image intact.

Okay, thanks, in that case I guess it's better to wait for interactive image editors


FYI: Official GitHub feature now being rolled out

See https://github.com/isaacs/github/issues/283 https://help.github.com/en/articles/listing-the-issues-and-pull-requests-youre-subscribed-to

Yeah - I think it probably makes sense to retire this extension now.


Assets rerouted Instatlation Issue

Hello,
i have some trouble installing cockpit. Probablly something i missed, but i would be really thankfull if someone can point me in the right direction. Don't even know how to diagnose it further.
The installation locally worked fine, but now i tried to upload it to my webserver (strato). The install went without error but the login page is brocken. It seems to me some problem with mod rewrite because all the assets (like jquery) get reroutet with a 302 to /api/auth/login.
I have installed it under a subdomain, if that makes a difference.
Thank you for your time and help.

You don't need to change the .htaccess.
Create a file defines.php in your cockpit root directory with
define('COCKPIT_BASE_URL', '/' . basename(__DIR__));
define('COCKPIT_BASE_ROUTE', '/' . basename(__DIR__));
define('COCKPIT_DOCS_ROOT', dirname(__DIR__));

And I wrote an install script for strato, because it was very annoying to have such a limited console:
https://github.com/raffaelj/cockpit-scripts/blob/master/install-cockpit-on-strato/install.sh

Thank you @raffaelj,
that sounds good. Will try it tomorrow.

Finally got time to do it and it worked. Just added the defines.php and put in my pathnames.
Thanks again @raffaelj

Sorry, but maybe i closed this to early. Should i open a new one?
Last time i only checked that the frontend of Cockpit worked on my server. But now i filled in my data and tried to fetch it. but now i get a 404 on the api request.
i can access the frontend at: beta.MYDOMAIN/cms
so shouldn't i get the api with: beta.MYDOMAIN/cms/api/collections/get/test
that is what worked locally.
I'm really sorry for asking all this questions.

Sorry, I used cockpit as a library to have a backend for a simple php frontend. I didn't notice, that the api doesn't work. It worked on my localhost and apparently I never checked, if the api works on the server.
I tested it again. The backend and frontend work. When trying to call the api through https://example.com/admin/api/..., I got redirected to the login page. If calling https://www.example.com/admin/api/..., I get a {"error": "404", "message":"File not found"}.
There was some weird config, I had to add to load cockpit as library (found it here):
$options['route'] = preg_replace('#'.preg_quote(BASE_URL, '#').'#', '', parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH), 1);

$app = new Lime\App($options);

Maybe this is helpful.
Otherwise - If you don't have to use strato shared hosting (because a client already has a cheap account and wants to stay...), you could consider to choose a better webhoster.

No reason to be sorry, I'm thankfull you spend the time on my problem. And yes i'm bound to strato.
But im not sure i understand your solution. I'm on the 0.8.0 stable relase. I don't seem to have a line:
$app = new Lime\App($options);
so i tried putting it in the bootstrap.php because the LimeExtra\App there seems to just inherit from Lime\App. but i don't really understand the project yet and have no idea where i could kind of check if anything changes.
// load config
$config = array_replace_recursive([
  'debug'        => preg_match('/(localhost|::1|\.dev)$/', @$_SERVER['SERVER_NAME']),
  'app.name'     => 'Cockpit',
  'base_url'     => COCKPIT_BASE_URL,
  'base_route'   => COCKPIT_BASE_ROUTE,
  'docs_root'    => COCKPIT_DOCS_ROOT,
  'session.name' => md5(__DIR__),
  'sec-key'      => 'c3b40c4c-db44-s5h7-a814-b4931a15e5e1',
  'i18n'         => 'en',
  'database'     => ['server' => 'mongolite://'.(COCKPIT_STORAGE_FOLDER.'/data'), 'options' => ['db' => 'cockpitdb'] ],
  'memory'       => ['server' => 'redislite://'.(COCKPIT_STORAGE_FOLDER.'/data/cockpit.memory.sqlite'), 'options' => [] ],

  'paths'         => [
    '#root'     => COCKPIT_DIR,
    '#storage'  => COCKPIT_STORAGE_FOLDER,
    '#pstorage' => COCKPIT_PUBLIC_STORAGE_FOLDER,
    '#data'     => COCKPIT_STORAGE_FOLDER.'/data',
    '#cache'    => COCKPIT_STORAGE_FOLDER.'/cache',
    '#tmp'      => COCKPIT_STORAGE_FOLDER.'/tmp',
    '#thumbs'   => COCKPIT_PUBLIC_STORAGE_FOLDER.'/thumbs',
    '#uploads'  => COCKPIT_PUBLIC_STORAGE_FOLDER.'/uploads',
    '#modules'  => COCKPIT_DIR.'/modules',
    '#addons'   => COCKPIT_DIR.'/addons',
    '#config'   => COCKPIT_CONFIG_DIR,
    'assets'    => COCKPIT_DIR.'/assets',
    'site'      => COCKPIT_SITE_DIR
  ],
  'filestorage' => [],
], is_array($customconfig) ? $customconfig : [], [
  // FIXME: hack to get strato to work?
  'route' => preg_replace('#'.preg_quote(BASE_URL, '#').'#', '', parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH), 1),
]);

$app = new LimeExtra\App($config);

Your fixme hack might work... Try to replace BASE_URL with COCKPIT_BASE_URL.
For debugging create a file path/to/cockpit/config/bootstrap.php and add
<?php
// view the debug info on top of the layout
$app->on('app.layout.contentbefore', function(){

    $vars = [
        'app_important_routes' => [
            'route' => $this['route'],
            'base_url' => $this['base_url'],
            'base_route' => $this['base_route'],
            'base_host' => $this['base_host'],
            'base_port' => $this['base_port'],
            'docs_root' => $this['docs_root'],
            'site_url' => $this['site_url'],
        ],
        'DOCUMENT_ROOT' => $_SERVER['DOCUMENT_ROOT'],
        'cockpit_DIR' => dirname(dirname(__DIR__)), // may differ from DOCUMENT_ROOT (symlinks)
        'user_constants' => get_defined_constants(true)['user'],
        'app_paths' => $this['paths'],
        // 'SERVER' => $_SERVER,
        // 'app_config' => $this->config, // config.yaml + app defaults
        // 'app' => $this, // the whole app, needs a few seconds to load/print
    ];

    echo '<pre>' . print_r($vars, true) . '</pre>';

});

My setup was:
- /dir/cockpit   // backend
- /dir/index.php //frontend
- /dir/...

content of frontend index.php:
//include cockpit
include_once("cockpit/bootstrap.php");

// start Lime
$app = new Lime\App($options);

// some logic to bind paths and render output as html

Wait, the route is already set this way:
https://github.com/agentejo/cockpit/blob/next/index.php#L18
Let me know, if you find a solution. I really thought, I was able to run cockpit on strato and I'm sure, I'll run into this issue again in the future.

I found the issue, and maybe the solution. The constant COCKPIT_API_REQUEST is set to 0, so the api controller doesn't start and the backend returns a 404.
Add this debug code here: https://github.com/agentejo/cockpit/blob/next/bootstrap.php#L67
$vars = [
    'DOCUMENT_ROOT' => $_SERVER['DOCUMENT_ROOT'],
    'cockpit_DIR' => __DIR__, // may differ from DOCUMENT_ROOT (symlinks)
    'user_constants' => get_defined_constants(true)['user'],
    'SERVER' => $_SERVER,
];
print_r($vars);
die;

to return your SERVER vars and constants to the api output.
In the defines.php define COCKPIT_API_REQUEST with a mixup from
define('COCKPIT_API_REQUEST'    , COCKPIT_ADMIN && strpos($_SERVER['REQUEST_URI'], $COCKPIT_BASE_URL.'/api/')!==false ? 1:0);

and
if (COCKPIT_ADMIN && !defined('COCKPIT_ADMIN_ROUTE')) {
    $route = preg_replace('#'.preg_quote(COCKPIT_BASE_URL, '#').'#', '', parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH), 1);
    define('COCKPIT_ADMIN_ROUTE', $route == '' ? '/' : $route);
}

If it works - Let's start a new thread in the Cockpit Community Forum with best practices for defines.php and supported webhosters.

I fixed it. Try it with this branch. If it works for you, I'll send a pull request.
https://github.com/raffaelj/cockpit/tree/cp-next_fix-api-call-redirect-to-login
I moved the COCKPIT_BASE_URL definition above the COCKPIT_API_REQUEST definition and removed one $ sign in bootstrap.php.

I tried your branch and it just works. I tested the Interface, got my data via the api and even tested the email submit via forms. Everything I need.
That is just awesome, thank you so much. I would have been lost without you.


Tail call elemination with curly braces does not work

This code fails with StackOverflow:
let rec f (x: Int): Int = {
  f 2
};

f 2

May I ask what is your expected result? The function f is sort of ill-formed, even in Haskell, it will go to infinite loop. f2j is call-by-value, so StackOverflow comes no surprise for me.

@bixuanzju I think if TCE works, it should be an infinite loop instead of stack overflow.

@zonyitoo @orionll  Sure it is! Just invoke f2j with TCE support, like f2j -m stack <file>. In my machine, it does seem to run like forever

Oh, well, that's true.

The expected result is an infinite loop. The actual behavior is StackOverflowError (even with -m stack). If you remove curly braces then it will run into an infinite loop as expected.

@orionll That's true! Quite odd ... Maybe @zhiyuanshi could look into it

@bixuanzju isn't the issue that curly braces create SeqExprs which falls under this case: https://github.com/hkuplg/fcore/blob/develop/lib/StackTransCFJava.hs#L174 ?


Tweak script to update release info page

Update the script for fetching Kubernetes Release Cycle and updating it.

Change the warning to a pageinfo shortcode

We reserve warning shortcodes for dangerous, never-do-this kind of advice

Update the fetched page to match
Change the first heading to a level 2 (the page title becomes a level 1 heading)

/sig release

/area web-development
too

/lgtm

/approve