"Unable to get mapping for AWSInstanceType2Capabilites" error while creating cluster with p2.xlarge instance

My attempts at creating a cluster with p2.xlarge instance gives this error "Template error: Unable to get mapping for AWSInstanceType2Capabilites::p2.xlarge::EBSOpt". I tried some other instance types and they work just fine.
A quick look at the "cfncluster.cfn.json" file shows that the mappings for "AWSInstanceType2Capabilites" is given as "p2.large" in line 1579. Shouldn't this be "p2.xlarge"? I would appreciate suggestions to fix this since I need the p2.xlarge instance to work for my needs.
I am using cfncluster 1.3.1.

So I changed p2.large to p2.xlarge in cfncluster.cfn.json, and used this edited file by specifying template_url = url_of_my_edited_cfncluster.cfn.json in the config file. This seems to have fixed the problem as I can now create clusters with p2.xlarge instances.
The default json might still need to be updated for it to work out of the box.

I am having the same problem. On top of that, I cannot seem to link to a json I have in an s3 bucket, even though it is in the same region (us-west-2) as everything else, can can be accessed easily with a web browser. How did you set up your s3 link?

I had to make my json in the S3 bucket downloadable by everyone for it to work. It may not be the best solution, but it worked for me. This can be done in the 'permissions' section of S3 console via a web browser. Hope it helps.

Thanks for the bug report.  This will be fixed in CfnCluster 1.3.2.  You can track the patch set at pull request https://github.com/awslabs/cfncluster/pull/188.


(export) vars is corrupt!

export (TYPE) var NAME_VAR does not work correctly. At the time of construction of the object, all fields that were installed with the help of the inspector, in the editor window during the boot sequence of the scene (at a time when executed, the function _ ready ()), are absolutely empty, even if the original scene takes the field set in the inspector, in advance, before the creation of any instance of such a scene.
And if, in the script, previously obvious way to set default values, they will be in place initially, but when the editor creates a new instance of the scene and in the Inspector, change the field (export), for some other value, and save the scene, then when run scene, the new value will never appear, instead will always be something that was previously specified in the script in obvious way ...

Let me add to this that exported arrays are not correctly shown in the inspector.

that is intended, try assigning a default value for it to infer type and it will work better, try:
export var myvar = 2

and it automatically exports an integer

that is intended, try assigning a default value for it to infer type and it will work better, try:
export var myvar = 2
and it automatically exports an integer
@ reduz
as I said higher ...
And if, in the script, previously obvious way to set default values, they will be in place initially, but when the editor creates a new instance of the scene and in the Inspector, change the field (export), for some other value, and save the scene, then when run scene, the new value will never appear, instead will always be something that was previously specified in the script in obvious way ...

I am really not seeing that behaviour, can you make a scene where editor
overriden values are not kept so i can test?
On Tue, May 19, 2015 at 4:51 PM, OlexiyKravchuk<EMAIL_ADDRESS>wrote:

that is intended, try assigning a default value for it to infer type and
it will work better, try:
export var myvar = 2
and it automatically exports an integer
@ reduz
as I said higher ...
And if, in the script, previously obvious way to set default values, they
will be in place initially, but when the editor creates a new instance of
the scene and in the Inspector, change the field (export), for some other
value, and save the scene, then when run scene, the new value will never
appear, instead will always be something that was previously specified in
the script in obvious way ...
—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1896#issuecomment-103649763.

https://www.dropbox.com/s/4ry7fytwe3awda0/ZERO_Temperatures_TEST.7z?dl=0
while I was doing this example, I seem to have understood what the problem was, it is because, constructor is late in _init (), you have already is mentioned about it in a different issue.

when you edit a node, you might have realized that the script property is
at the bottom. When nodes or resources are loaded, properties are set from
the bottom to the top. This means that the script is set first (thus
_init() is run) and, after all the node has been configured, the property
with the exported variable is set. As you aquire the value in the
constructor, this value has not been set yet.
On Thu, May 21, 2015 at 6:03 PM, OlexiyKravchuk<EMAIL_ADDRESS>wrote:

https://www.dropbox.com/s/4ry7fytwe3awda0/ZERO_Temperatures_TEST.7z?dl=0
while I was doing this example, I seem to have understood what the problem
was, it is because, constructor is late in _init (), you have already is
mentioned about it in a different issue.
—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1896#issuecomment-104419277.

Thank you for the details, so I close this issue.


Wiki/tutorial is missing halfway

Hello
I see in the readme part how to read the values but how I can save for example a new file with new details? How I can modify one value or multiple values?
Sorry, I am very beginner and no idea how to use. For beginners would be nice to see at least the basic usage in every perspective which would be read (which already has), write and modify values.
Maybe I don't find this tutorial and already is there somewhere. If not then it would be nice to give overview how to use properly this.
Thank you in advance.

Hi there, there is almost no documentation (except this README section)
I'm preparing a big update, I will also add more documentation, seems like it's much needed


The system cannot find the path specified and exited abnormally in flutter

I want to run my first application with flutter but there is an error like this
command
flutter run
exception
ProcessException: ProcessException: Process "C:\Users\IT20\AndroidStudioProjects\flutter_app_first\android\gradlew.bat" exited abnormally:

------------------------------------------------------------
Gradle 5.1
------------------------------------------------------------

Build time:   2019-01-02 18:57:47 UTC
Revision:     d09c2e354576ac41078c322815cc6db2b66d976e

Kotlin DSL:   1.1.0
Kotlin:       1.3.11
Groovy:       2.5.4
Ant:          Apache Ant(TM) version 1.9.13 compiled on July 10 2018
JVM:          1.8.0_152-release (JetBrains s.r.o 25.152-b01)
OS:           Windows 10 10.0 amd64

The system cannot find the path specified.

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.

Exact same issue on my end.
`C:\Users\USERNAME\flutter_app\android>gradlew.bat -v

Gradle 4.10.2
Build time:   2018-09-19 18:10:15 UTC
Revision:     b4d8d5d170bb4ba516e88d7fe5647e2323d791dd
Kotlin DSL:   1.0-rc-6
Kotlin:       1.2.61
Groovy:       2.4.15
Ant:          Apache Ant(TM) version 1.9.11 compiled on March 23 2018
JVM:          1.8.0_131 (Oracle Corporation 25.131-b11)
OS:           Windows 10 10.0 amd64`

Resolved.

Resolved by looking at what path cannont be found using Process Monitor.

I am having the same problem on windows.. I already added the path into the environment but it keeps telling me that
D:\flutter>flutter doctor
The system cannot find the path specified.
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, v1.7.8+hotfix.4, on Microsoft Windows [Version 10.0.17134.915], locale en-US)
[√] Android toolchain - develop for Android devices (Android SDK version 29.0.1)
[√] Android Studio (version 3.4)
[√] VS Code (version 1.36.1)
[!] Connected device
! No devices available
! Doctor found issues in 1 category.

in my case, I had a & sign in the name of the folder that I had put in the flutter project. removing it solved the problem for me.

The same issue over here any solutions ?


Improve Core Web Vitals (performances)

https://blogjolt.com/how-to-embed-youtube-videos-without-sacrificing-site-speed/ is a thorough analysis about how using a Youtube iframe embed affects the Core Web Vitals "Performances" stat negatively.
Currently, react-player supports the "lazy loading" mode. I've tried using it and didn't notice any score improvements whatsoever.
A few stats for Core Web Vitals "Performances":

Without Youtube embed: 40-75
With Youtube embed: 22-25
With Youtube embed using react-player "lazy load" feature: 22-25

Could it be possible to add a mode using the 4th method explained in the above link? Basically don't load the youtube video at all, but display a thumbnail instead, and load the video on click on the player.
Here is a potential implementation: https://www.corewebvitals.io/pagespeed/perfect-youtube-core-web-vitals
Does such idea make sense? CWV has become more and more important and having a way to load videos without negatively affecting websites has become necessary.

Could it be possible to add a mode using the 4th method explained in the above link? Basically don't load the youtube video at all, but display a thumbnail instead, and load the video on click on the player.

This sounds exactly like what the light prop does. https://github.com/cookpete/react-player#light-player

Thanks! I had missed that option. Maybe mentioning it around the "lazy load" feature would make sense? I believe it could be highlighted a bit more, as it's a good practice to use it by default, not only for its performance implication but also to reduce network usage on mobile.


moved dtype validation for min and max to dataframe.py

[x] passes git diff upstream/master -u -- "*.py" | flake8 --diff
[x] passes black --check modin/

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Modin/309/
Test FAILed.

Merged build finished. Test FAILed.

merged, thanks for the fix!


Declaration of 'RCTImageLoaderCancellationBlock' must be imported from module 'React.RCTGIFImageDecoder' before it is required

Bug
This build issue happens on iOS. react-native-maps is installed using CocoaPods. It only happens after adding :modular_headers => true to the React pod in the Podfile (see below). I need to add :modular_headers => true in order to import from Swift pods when building them as static libraries. The requirement is coming from lottie-react-native, also see: https://github.com/react-native-community/lottie-react-native/issues/511#issuecomment-511147668

Podfile
# Uncomment this line to define a global platform for your project
platform :ios, '10.0'

install! 'cocoapods', :deterministic_uuids => false

target 'HelloAgainTeam' do
  pod 'CodePush', :path => '../node_modules/react-native-code-push'

  rn_path = '../node_modules/react-native'
  rn_maps_path = '../node_modules/react-native-maps'

  pod 'yoga', path: "#{rn_path}/ReactCommon/yoga/yoga.podspec"
  pod 'React', path: rn_path, subspecs: [
    'Core',
    'CxxBridge',
    'DevSupport',
    'RCTActionSheet',
    'RCTAnimation',
    'RCTGeolocation',
    'RCTImage',
    'RCTLinkingIOS',
    'RCTNetwork',
    'RCTSettings',
    'RCTText',
    'RCTVibration',
    'RCTWebSocket',
  ], :modular_headers => true

  # React Native third party dependencies podspecs
  pod 'DoubleConversion', :podspec => "#{rn_path}/third-party-podspecs/DoubleConversion.podspec"
  pod 'glog', :podspec => "#{rn_path}/third-party-podspecs/glog.podspec"
  # If you are using React Native <0.54, you will get the following error:
  # "The name of the given podspec `GLog` doesn't match the expected one `glog`"
  # Use the following line instead:
  # pod 'GLog', :podspec => "#{rn_path}/third-party-podspecs/GLog.podspec"
  pod 'Folly', :podspec => "#{rn_path}/third-party-podspecs/Folly.podspec"

  # react-native-maps dependencies
  pod 'react-native-maps', path: rn_maps_path
  pod 'react-native-google-maps', path: rn_maps_path  # Remove this line if you don't want to support GoogleMaps on iOS
  pod 'GoogleMaps'  # Remove this line if you don't want to support GoogleMaps on iOS
  pod 'Google-Maps-iOS-Utils' # Remove this line if you don't want to support GoogleMaps on iOS

  pod 'lottie-react-native', :path => '../node_modules/lottie-react-native'
  pod 'lottie-ios', :path => '../node_modules/lottie-ios'
  pod 'SentryReactNative', :path => '../node_modules/react-native-sentry'

end

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['EXPANDED_CODE_SIGN_IDENTITY'] = ""
      config.build_settings['CODE_SIGNING_REQUIRED'] = "NO"
      config.build_settings['CODE_SIGNING_ALLOWED'] = "NO"
    end

    ## <Extension postinstall targets>

    if target.name == 'react-native-google-maps'
      target.build_configurations.each do |config|
        config.build_settings['CLANG_ENABLE_MODULES'] = 'No'
      end
    end
    if target.name == "React"
      target.remove_from_project
    end

  end
end

Environment info
React native info output:
  React Native Environment Info:
    System:
      OS: macOS 10.14.6
      CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
      Memory: 1.08 GB / 16.00 GB
      Shell: 5.3 - /bin/zsh
    Binaries:
      Node: 10.15.3 - /usr/local/opt/node@10/bin/node
      Yarn: 1.17.3 - /usr/local/bin/yarn
      npm: 6.4.1 - /usr/local/opt/node@10/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    SDKs:
      iOS SDK:
        Platforms: iOS 12.4, macOS 10.14, tvOS 12.4, watchOS 5.3
      Android SDK:
        API Levels: 25, 26, 27, 28
        Build Tools: 27.0.3, 28.0.3
    IDEs:
      Android Studio: 1.1.0 AI-135.1740770
      Xcode: 10.3/10G8 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.8.3 => 16.8.3
      react-native: 0.59.10 => 0.59.10
    npmGlobalPackages:
      react-native-camera: 0.12.0
      react-native-cli: 2.0.1
      react-native-device-info: 0.10.2
      react-native-fcm: 11.2.0
      react-native-vector-icons: 4.5.0

Library version: 0.26.1

Thanks. That worked for me as well.


Fix inconsistent button styles

The button styles within the field editor need to match the rest of the UI. They're still using the styles from the old editor.

Buttons also need specific foreground colors; when the system is in dark mode but the user has chosen light mode certain buttons can be illegible.

Variant button also impacted by the system dark theme

The latest UI changes for monochromatic should fix the issues with the buttons.


schema changes to v0.10

Can you make sure to rebase before merging when the schema changes for version 0.10 are complete?

Yes, the schemas' metadata section needs some improvements. I recall we briefly discussed parts of the metadata section, so once I'll review the minutes, I will update the branch and try to resolve conflicts. the changes to the CV were metric additions and term definition refinements, so I'd rather not loose them

Ok. For the CV: I will have a look at the changes in this PR and add them to a new slightly cleaned version (0.0.11?), which will cover the discussed topics.

TY!
On 25/04/18 08:30, Julian Uszkoreit wrote:

Ok. For the CV: I will have a look at the changes in this PR and add them to a new slightly cleaned version (0.0.11?), which will cover the discussed topics.

--
Mathias Walzer
European Bioinformatics Institute (EMBL-EBI)
Wellcome Trust Genome Campus, Hinxton, Cambridge, UK
Office: +44 (0)1223 494 2610
E-mail<EMAIL_ADDRESS>

deprecated w/ move to json


add a test for new binary artifact download concurrent download limit

motivation: recent change to SwiftPM introduce a limit on # of concurrent binary artofacts downloads, but was missing a test
changes: add a test for the new functionality

@swift-ci please smoke test
cc @plu

@swift-ci please smoke test

Thank you for adding tests, and sorry I didn't do it in the first place.


Use hooks on front page

This pull request refactors the examples on the home page to be function components using hooks, instead of class components.
Hooks are inherently easier to understand than the concept of classes and lifecycles at first glance - so I think it makes sense to show people the easiest-to-grasp version first.
I'm sure this could've been discussed in an issue first, sorry for just barging in with a PR like this. It didn't take a lot of time though!
I think we might want to re-consider the second example, however, since it introduces the concept of useEffect - a slightly harder to grok piece of functionality. Perhaps a simple counter example would suffice?

Oops, this didn't work at all. Gimme a second

Thanks, but we intentionally want to wait around a little longer. At least until most docs are converted to Hooks. Otherwise the transition is way too jarring. (And we don't want to rush converting docs either until there is more wide adoption.)

Any plans to redo this?


Split Snapshot into Link & Snapshot + migrate

Proof of concept.
Summary
Poking around some ideas to improve the data model in ArchiveBox. This introduces splits the Snapshot into a Snapshot & Link model, with a Link representing a single URL added to ArchiveBox, and a Snapshot representing one download that Link at a given time.
There's definitely more work to be done with this (including testing against more than just one URL + tags), but this seems like one of several necessary steps to move data that's currently on the fs into the db (similar to #513).
How does this approach look? Thoughts?
Related issues
Conversation in #496.
Changes these areas

[ ] Bugfixes
[X] Feature behavior
[ ] Command line interface
[ ] Configuration options
[ ] Internal architecture
[ ] Snapshot data layout on disk

Link is actually the last remaining part of the old ArchiveBox core design that we've been moving away from for several months. It's frozen code that only exists as an adapter layer right now, and it's due to be removed completely in the next version in favor of just using Snapshots without a unique URL requirement.
The final portion of that refactor will be timed to land with (or soon after) the move of ArchiveResult into the sqlite db, and that will be the last major legacy portion of the codebase to move to the new Snapshot system.
This was a reasonable PR for the idea you had, but unfortunately it conflicts with our plans for incrementally changing the core design over the next few months, so I'm going to close it for now. Happy to provide more context and discuss further if we chat this upcoming week (just pick any time on https://calendly.com/nicksweeting/choose-a-time).

@pirate Yeah, I went away for the weekend so I haven't had a chance to pick a time. I had a day Friday to do some open source work so thought it would be worth sharing what I was considering in that thread. Will get something on the calendar to figure out where you're going with things and how I can help.


Move to conda-build 3

Build is currently failing in the Linux containers due to a linking problem in the system libraries ... the CI output shows problems with redefining XRender symbols, but I believe the proximate cause is this message in config.log:
configure:22839: checking for XRenderCreateLinearGradient
configure:22839: gcc -o conftest [....] conftest.c -lrt  -lm   -lSM -lICE  -lX11 -lXext   -lXrender >&5
/usr/lib/../lib64/libSM.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/../lib64/libSM.so: undefined reference to<EMAIL_ADDRESS>collect2: error: ld returned 1 exit status

Not sure why this has started happening. Could perhaps be avoided by using conda-forge's X libraries, but that has been controversial.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Actually, the host environment does include libuuid, so the build stage is probably trying to link libSM with that rather than the system libuuid. It looks like fontconfig is the package with the internal libuuid dependency.
Using conda-forge's X libraries for the Linux build would be one way to avoid this, I think.

I'm all for it to merge it! :)

Me too. Any comments on the issues alluded to above, @conda-forge/staged-recipes folks?

(FYI, I just force-pushed with a package name fix (xorg-xcb-proto is deprecated for xcb-proto) and some tidying of the history. Should definitely still pass CI ...)

LGTM

Thanks @pkgw and @sodre for the review.


add packer configuration without atlas?

It took me some time to understand that I need to throw away all the stuff related to atlas from nixos-x86_64.json and have just
  "post-processors": [
    {
      "type": "vagrant",
      "keep_input_artifact": false
    }
  ]

I think this has been fixed?

thanks


image-copy resets image hyper-v generation to V1

Extension name (the extension in question)
image-copy
Description of issue (in as much detail as possible)
Why copying an image created for Hyper-V generation 2 VMs the resulting copy made with the image-copy extension has its generation reset back to Hyper-V generation 1.
Workaround
Avoid using --cleanup. Export the image ARM template, change the hyper-V generation, delete the copied image, and deploy the ARM template with the correct generation.

This issue seems to be duplicated with https://github.com/Azure/azure-cli-extensions/issues/2476, so close this one and let's focus on another issue for discussion

I agree-- looks like a perfect duplicate. Sorry I missed that in my pre-submission search for existing issues.


Document serializing/loading indices

Is this the correct way to save/load indices? The documentation doesn't say much about this.
var idx = lunr(...)
var data = JSON.stringify(idx)

var idx = lunr.Index.load(JSON.parse(data))

Yep, thats the right way of loading/serialising. The documentation could be a little clearer on this, I really need to spend some time on writing guides for common things like this.


Bad "nice url" generated

https://www.vsixgallery.com/extension/45521019-e4c7-480c-8ea8-fc4a2c6f50aa
(Yes, I am sorry for the bad naming of the extension (using a "/" in the name)

Renamed my extension.


correct defaultBrokerClass name in  eventing crd description

Proposed Changes

the MTChannelBasedBroker is the new default broker

Release Note
None

@googlebot I signed it!

/ok-to-test
@xq2005 Welcome to join knative!


Fix: handle whitespace paths for Windows launchers

Follow-up to: https://github.com/NationalSecurityAgency/ghidra/commit/38edc05f812c752713ca0fcecf1239d99d3efc3c
Fixes: https://github.com/NationalSecurityAgency/ghidra/issues/3201
It seems like these instances for the "!" check were not quoted but need to be if the path contains whitespaces.
Not sure if there are other such cases, but this at least resolves the issue with the launcher for me with a path containing my name.
Prior:
C:\Users\Dominic Della Valle\path\Ghidra>ghidraRun.bat
Della was unexpected at this time.

Post:
Launches as expected (so long as some version of java is in PATH).
Even though this is a small change that looks obvious, it's Batch, so someone should scrutinize it as if it's intended to be malicious. Since that seems to be the default nature of the command interpreter.

Thanks, this was a bonehead move on my part.


Modularize library

First of all, apologies for the enormous PR - I initially tried to do incremental changes but it became clear that a rewrite from the ground up was required, so here we are.
This rewrite had several motivations that explain many of the design decisions:

The ability to support multiple splitting algorithms in the future, such as ICU.
The ability to support non-terminal contexts that have different width calculations than unicode-width.
Currently, the library assumes that terminals will display characters using their Unicode width, however this is an incorrect assumption: iTerm2 for example displays 👨👨👧👦 (a family emoji) in two columns instead of eight as unicode-width would report. This point ties into the last one: allowing swapping out unicode-width for other functions.
The possibility of supporting no_std in the future; none of the main algorithms currently allocate or use any std features.
Favouring modularity over configuration - having the core API be entirely modular allows it to be implemented in a far simpler way and allows it to be more extensible. However it can be fairly verbose, I can add a configuration layer on top of it if you wish.

To understand the precise changes that were made, it's probably best to just to open it in Rustdoc.
This is far from complete. I still have to re-add hyphenation support, tests, benchmarks, examples, shorthand functions et cetera, but the base functionality is there. By the way, I'm not expecting this API to be added as-is; this PR just represents one extreme of how modular this library could be. We could compromise between this and the current one.

Hi @Koxiaet,
Wow, this is indeed a big change. There are definitely some nice ideas here — now the good question is how we can extract them and merge them.

I think would need to discuss the problems with the current design first — when we agree on what those are, then we can look for solutions to them.
You mention above that this PR brings

The ability to support multiple splitting algorithms in the future, such as ICU.

Can this not be done today by preparing Fragments in a suitable fashion using ICU?
Right now, textwrap::wrap takes a &str and gives you a Vec. It finds and splits the Words internally, but I was thinking that we should change wrap to something like
pub fn wrap<'a, S, Opt>(text: &str, options: Opt) -> Vec<Cow<'_, str>>
where
    S: WordSplitter,
    Opt: Into<Options<'a, S>>,
{
    text.split('\n').flat_map(|line| {
        let words = core::find_word_and_measure_unicode_width(line, &options);
        core::wrap_fragments(words, &options);
    })
}

That is, make wrap really trivial. If someone has a different way of finding and measuring words, then it simply replace find_words_and_measure_unicode_width with another function. This function can be as complex as it wants, as long as it returns a Vec<Fragment> or Iterator<Item = Fragment> at the end of the day. We can then feed that into a generic wrapping function and we should be good?

Currently, the library assumes that terminals will display characters using their Unicode width, however this is an incorrect assumption: iTerm2 for example displays family_man_man_girl_boy (a family emoji) in two columns instead of eight as unicode-width would report. This point ties into the last one: allowing swapping out unicode-width for other functions.

Right, we cannot actually know how the characters are displayed at the end of the day. Applications which know more than what unicode-width does, will have to prepare their Fragments themselves.
My goal was to make it easy for 99% of the applications to call
for line in textwrap::wrap(&some_text, some_width) {
    // do something with the line of text
}

while also making it possible for more advanced programs to do something like this:
let fragments = custom_way_of_finding_words(&some_text);
let wrapped_fragments = core::wrap_optimal_fit(&words, line_lengths);
for line in wrapped_fragments {
    // Use the fragments in line to refer back to font and styling information
    // so you can render them in your UI or put them into a PDF, or...
}

Perhaps an advanced program only needs to check if $TERM_PROGRAM is equal to iTerm.app after which it can run through the words returned by core::find_words and adjust the widths suitably. We could also do this automatically in find_words, which would be pretty awesome actually!

The decoupling of Span from Fragment seems nice:
/// A span of text with content, glue and a penalty.
///
/// This type is intentionally agnostic over the algorithm used to calculate the width of each
/// string, and so does not implement [`Fragment`](super::Fragment).
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub struct Span<'a> {

The Word struct I made has one and only one way to measure the text width (via unicode-width) and that might have been a mistake...
In any case, I look forward to seeing some benchmark results when you get that hooked up. I don't know precisely how fast textwrap needs to be, but my feeling is that people consider wrapping text to be "simple" or nearly "trivial", so I hope to keep things fairly lean here. The functions in textwrap::core are pretty lean to me right now and I hope to keep that.

Just to clear up some confusion - I'm not suggesting that all users should be forced to use the modular and verbose API. I was planning on adding simple functions like the ones we have now on top of it that use sensible defaults. So I absolutely share the goal "to make it easy for 99% of the applications".

Perhaps an advanced program only needs to check if $TERM_PROGRAM is equal to iTerm.app after which it can run through the words returned by core::find_words and adjust the widths suitably. We could also do this automatically in find_words, which would be pretty awesome actually!

This is a good idea, the trouble is I don't know how to "adjust the widths suitably". Once an application doesn't use Unicode width, it's hard to say anything about string widths without hard-coding special cases ourselves, which isn't really a good solution.

people consider wrapping text to be "simple" or nearly "trivial", so I hope to keep things fairly lean here.

One improvement we could make is to only build in support for text splitting with ICU. In theory this would reduce performance for simple cases, but it's not by much and really users should always be using internationalized algorithms anyway. What do you think?

Just to clear up some confusion - I'm not suggesting that all users should be forced to use the modular and verbose API. I was planning on adding simple functions like the ones we have now on top of it that use sensible defaults. So I absolutely share the goal "to make it easy for 99% of the applications".

Definitely! I saw that you talked about putting a layer on top of the new building blocks you've created. This is great and necessary.
I've been trying to figure out what the problem is with the current building blocks? Why can users of textwrap not use the Fragments instead? I saw that @robinkrahl was able to wrap lines of text for a PDF library (see https://github.com/mgeisler/textwrap/issues/126#issuecomment-736671357), so that shows some promise to the current abstraction.

This is a good idea, the trouble is I don't know how to "adjust the widths suitably". Once an application doesn't use Unicode width, it's hard to say anything about string widths without hard-coding special cases ourselves, which isn't really a good solution.

Yeah, I also don't know how to know that the family emoji should be counted as taking up 2 columns or something else... However, I think that is okay: textwrap doesn't need to solve this problem in the first attempt. But we should enable other programs to solve it, if they want.
So I'm imagining that a more comprehensive program would have code like
let mut words = custom_way_of_finding_words(&some_text);
for word in words {
  if has_zwj_emoji(word) {
    adjust_width(&mut word);
  }
}
let wrapped_fragments = core::wrap_optimal_fit(&words, line_lengths);

(plus/minus mutability)
Does that goal make sense?
If so, I think a first next step would be to make it very simple for external programs to do what wrap does today. This means extracting the functionality of wrap into helper functions which we can put into core.

One improvement we could make is to only build in support for text splitting with ICU. In theory this would reduce performance for simple cases, but it's not by much and really users should always be using internationalized algorithms anyway. What do you think?

I'm skeptical of the ICU dependency — simply because it's a dependency on a C library, which means that there are a number of new requirements, such a Clang being installed. However, it could still be a non-default dependency for people who need it and who has the C library installed on their system.
I see the splitting as the first step of a kind of "pipeline", as described here: textwrap::core. So I'm totally onboard with making it configurable. Does the Fragment approach not satisfy this?

Why can users of textwrap not use the Fragments instead?

Does the Fragment approach not satisfy this?

This API is also based on Fragments, the only difference is that it separates text splitting and text width finding via plain::Span and plain::Fragment. This means that users who want to change the width-finding function will not have to reimplement the text splitting functionality, they only have to replace the width finding layer.

But we should enable other programs to solve it, if they want.

This was the motivation behind the Width trait - users can implement the Width trait for their own type, and plug it in to the existing logic and everything should work. So your example would look roughly like:
struct UserWidth {
    inner: width::Unicode,
}
impl Width for UserWidth {
    fn width_char(&self, c: char) -> usize {
        self.inner.width_char(c)
    }
    fn width_str(&self, s: &str) -> usize {
        // Magic ZWJ stuff
    }
}

and then
core::wrap_optimal_fit(
    custom_way_of_finding_words(&some_text)
        .map(|s| s.width(UserWidth::new())),
    line_lengths,
)

However, it could still be a non-default dependency for people who need it

That's a good idea, I think a feature flag is the way to go, since there's never any case where you wouldn't want ICU to be used if you have it. Otherwise we should probably use unicode-linebreak, which is slightly better than splitting on spaces.

Does the Fragment approach not satisfy this?

This API is also based on Fragments, the only difference is that it separates text splitting and text width finding via plain::Span and plain::Fragment. This means that users who want to change the width-finding function will not have to reimplement the text splitting functionality, they only have to replace the width finding layer.

Okay, but we need to break the change down into smaller steps. Otherwise I cannot review it and we won't make forward progress :-) In other words, it's great that you've create a goal, but please try to start with the existing code.
My plan is still to basically rip out all the logic of wrap so that it only calls some helper functions. This way it becomes a trivial wrapper around the helper functions. In Rust pseudo code I imagine it would look like this:
fn wrap(text: &str, options: Opt) -> Vec<&str> {
    text.split('\n').flat_map(|line| wrap_single_line(line, options))
}

fn wrap_single_line(line: &str, options: Opt) -> Vec<&str> {
    let words = core::find_words(line);
    let split_words = core::split_words(words);
    let broken_wrods = core::break_words(split_words);
    let break_points = core::wrap_fragments(broken_words);
    core::wrap_line_by_break_points(line, break_points)
}

// in core
fn wrap_text_by_break_points(line: &str, wrapped_words: &[[Fragment]]) -> Vec<&str> {
    // The second half of wrap today:
    let mut idx = 0;
    for words in wrapped_words {
        // ...
    }
}

The problem with such an approach is probably that I'll run into all sorts of problems with borrowing: I'll need to pass the Options around and I also need to make sure that I have the original &str at hand at the right place so I can get a substring out of it.
Have you tried writing the full wrap function with your approach — and verified that it can borrow correctly from the input string? Last I tested it, there was a clear performance win from using the Cow<str> type as the result for each line (a win when there is no indentation so that we can borrow from the input). if you haven't already, then please see if this also works smoothly with your approach.

This was the motivation behind the Width trait - users can implement the Width trait for their own type, and plug it in to the existing logic and everything should work. So your example would look roughly like:

I'm not opposed to this at all — as I wrote somewhere above, the existing Word struct is actually measuring things twice and thus doing some extra work.
So we should perhaps let core::find_words return something else than Word, or let the measurement be delayed like you suggest. Both would be fine, I think, but please start attack the problem from that starting point.
Looking at names, I think we cannot have both Fragment and Span: it's not intuitively clear and obvious what the difference is between two such abstract entities. Does a Span have a width or is it Fragment? We could perhaps rename the Word struct to TextFragment so we have

Fragment: a trait for something which can be wrapped
TextFragment: a concrete type of Fragment, what I called Word before.

We could do the same with Span and TextSpan — I like the shorter name :-) I don't think anybody will start depending on the inner workings of the library anytime soon, so I'm fine with making a breaking release sometime in the new year.

Otherwise I cannot review it and we won't make forward progress :-) In other words, it's great that you've create a goal, but please try to start with the existing code.

Yes, I was planning on doing so - this was mostly an experiment so I could better understand the problem space and spark discussion. Should have made that more clear in the original PR, sorry.

Have you tried writing the full wrap function with your approach — and verified that it can borrow correctly from the input string?

I have not - the next thing I'll do is to add the iterator-based wrapping functions to the library I think, and I'll see how it goes.

let the measurement be delayed like you suggest

The big advantage of delaying measurement is allowing for chaining of multiple splitting functions (e.g. word splitting -> hyphenation splitting) without recalculating widths.

We could do the same with Span and TextSpan — I like the shorter name :-)

As in, have a Span trait? Or rename Span to TextSpan? I'm fine with all of text::Fragment, TextFragment, Span and TextSpan for the struct names, whichever you think is clearer :).
Something I wanted to discuss is the use of configuation (Options); if wrap is trivialised to the pseudocode you wrote, then is there much benefit for users to use options as opposed to simply writing out the steps manually?

Otherwise I cannot review it and we won't make forward progress :-) In other words, it's great that you've create a goal, but please try to start with the existing code.

Yes, I was planning on doing so - this was mostly an experiment so I could better understand the problem space and spark discussion. Should have made that more clear in the original PR, sorry.

Awesome, thanks! It is definitely valuable to explore the design, so thanks for putting up the experiment.
I've been playing with the ideas in #221 for about two years now — it was just a background thing that I tinkered with when I found some free time. Originally, the code would step through the input string char by char and keep track of everything in a bunch of local variables. It was a mess...and various bugs kept cropping up over time :grimacing:
I had a hunch that it should be possible to simplify the code while also making it more flexible. So I'm quite happy with the new "pipeline" and with the reformulation in terms of Words or Fragments or whatever we should call them.
For the user of textwrap, nothing much changed with #221, but that's where great decoupling ideas like you have come into the picture :smile:

let the measurement be delayed like you suggest

The big advantage of delaying measurement is allowing for chaining of multiple splitting functions (e.g. word splitting -> hyphenation splitting) without recalculating widths.

Yeah, that is indeed cool! Definitely something we need.

We could do the same with Span and TextSpan — I like the shorter name :-)

As in, have a Span trait? Or rename Span to TextSpan? I'm fine with all of text::Fragment, TextFragment, Span and TextSpan for the struct names, whichever you think is clearer :).

Okay, cool! If at all possible, then I would prefer to have just one abstract term. That is, we can have a trait named Fragment, Segment, Span or something similar. I tried looking at the definitions of those words:

Fragment: a part broken off, detached, or incomplete.

Segment: a separate piece of something or one of the constituent parts into which a body, entity, or quantity is divided or marked off by or as if by natural boundaries.

Span: an extent, stretch, reach, or spread between two limits: such as a: a limited space (as of time), the spread or extent between abutments or supports (as of a bridge).

Based on these definitions, as in particular the synonym discussion for fragment, I think I like fragment more than span. I guess the word span came to mind because I've seen it used to describe regions of Rust code. It's also HTML where the <span> element is used to mark regions of text.
This would imply renaming Word to TextFragment, or perhaps have a text module with a Fragment struct which implements core::Fragment. I find that a bit confusing, though, since the two names are the same.

Something I wanted to discuss is the use of configuation (Options); if wrap is trivialised to the pseudocode you wrote, then is there much benefit for users to use options as opposed to simply writing out the steps manually?

No, in some sense there isn't — the steps would be simple and users could have written them themselves. However, from looking at the reverse dependencies, I conclude that 99% of all users simply want to call textwrap::fill(some_string, some_width) or textwrap::wrap(some_string, some_width). It seems very rare that people actually customize the wrapping behavior. So from that perspective, the top-level function provides value by giving people a good default. It's less maintenance for people to call the functions over having to understand anything about fragments and whatnot.

I think I like fragment more than span.

Me too; I think Span has also has connotations of text (<span>, Rust's spans) whereas Fragment is more generic.

I find that a bit confusing, though, since the two names are the same.

Ok, in that case we'll use TextFragment; but we also do need a name for a bit of text without a width, and I think Span is a good name for it, since it has the aforementioned text connotations and doesn't include the word Fragment (which implies it would implement Fragment).

So from that perspective, the top-level function provides value by giving people a good default.

Agreed, we should absolute keep the top-level functions; I was wondering whether it is better to just take a usize instead of impl Into<Options>. Since 99% of users are just using a usize and those that aren't can use the modular API, Options might not be necessary at all.

Ok, in that case we'll use TextFragment; but we also do need a name for a bit of text without a width, and I think Span is a good name for it, since it has the aforementioned text connotations and doesn't include the word Fragment (which implies it would implement Fragment).

Ahh.... that's why you need two types: one for (content, glue, penalty) and one for the same but with a cached width? And you need two types because you want to cache the width? Otherwise you could just compute the width on the fly — wrap_first_fit and wrap_optimal_fit both compute the width of each Fragment once. However, the break_words function also computes the width to see if it should forcibly break the word.
I don't think struct Span fits in well with struct TextFragment. Perhaps we could use struct UnmeasuredText as a name for a type which simply holds content, glue, and whitespace? We could even go with struct Text.
The Breaking Paragraphs into Lines paper talks about "items" as the generic term for something that is put into a line. These items can then either be a box, glue, or whitespace. However, I think Fragment is a better term than Item — the latter is too generic.

So from that perspective, the top-level function provides value by giving people a good default.

Agreed, we should absolute keep the top-level functions; I was wondering whether it is better to just take a usize instead of impl Into<Options>. Since 99% of users are just using a usize and those that aren't can use the modular API, Options might not be necessary at all.

I think Options is useful because it gives people a central overview of the configuration options available to them when using fill or wrap. Otherwise this knowledge would be spread across the individual building-block functions that wrap calls. As an example, toggling break_words would require a user to look at the implementation of wrap, notice that it calls a core::break_words function and then decide to not call this function.
So for me, Options gives people some ready-made recipies. For example, it allows for indentation of the first or subsequent lines. One could easily use the functions in core to indent every odd line differently. But this is not supported via Options and I think that is fine. Similarly, the wrapping functions can in principle use different line widths for every line — so you can shape text into triangles, circles and whatnot. I've been playing with that and it's a lot of fun :-) But it's also not exposed and I'll probably simply end up adding a demo to the examples/ folder.

one for (content, glue, penalty) and one for the same but with a cached width?

Yes. If the wrapping functions take in iterators and the splitting function outputs are passed directly into the line wrapping inputs, the widths will be lazily computed on the fly anyway, but conceptually caching them will allow users that have static (unchanging) text to only compute the width of each fragment once.

However, the break_words function also computes the width to see if it should forcibly break the word.

I actually want to move the force-breaking into the line wrapping functions themselves eventually, so it would only have to be calculated once. Another advantage of having the force breaking in the wrapping functions is that we don't have to pass around the line widths everywhere - they only have to be managed by one part, the line wrappers.

Perhaps we could use struct UnmeasuredText as a name for a type which simply holds content, glue, and whitespace? We could even go with struct Text.

I don't really like UnmeasuredText or Text; UnmeasuredText is very long and it's not quite clear what "measure" means, and they both use the word Text which implies it's a complete string of text rather than a small range of it.

However, I think Fragment is a better term than Item — the latter is too generic.

Agreed, and our fragments are not the same as their item; our fragments are a combination of a box, glue and penalty item. As a side note this means that we don't support multiple glue items in a row, which the paper does support, but I don't think it's that important since we also do box-breaking based on words rather than characters.

I think Options is useful because it gives people a central overview of the configuration options available to them when using fill or wrap.

I think that this purpose is better served by documentation and examples; but if you think Options is worth keeping that's probably a better idea.
I'm currently reading the line breaking paper, so once I'm done with that I'll start working on actual code again.

one for (content, glue, penalty) and one for the same but with a cached width?

Yes. If the wrapping functions take in iterators and the splitting function outputs are passed directly into the line wrapping inputs, the widths will be lazily computed on the fly anyway, but conceptually caching them will allow users that have static (unchanging) text to only compute the width of each fragment once.

That's a very good point!

Perhaps we could use struct UnmeasuredText as a name for a type which simply holds content, glue, and whitespace? We could even go with struct Text.

I don't really like UnmeasuredText or Text; UnmeasuredText is very long and it's not quite clear what "measure" means, and they both use the word Text which implies it's a complete string of text rather than a small range of it.

Hmm... yeah, I guess you're right :smile: Let's revisit this later, perhaps Span is good enough after all.

Agreed, and our fragments are not the same as their item; our fragments are a combination of a box, glue and penalty item. As a side note this means that we don't support multiple glue items in a row, which the paper does support, but I don't think it's that important since we also do box-breaking based on words rather than characters.

Yeah! I'm quite happy to have a simpler model t han the full model in the paper. I've seen people do all sorts of tricks in (La)TeX using the full expressive power of glue and penalties — I would prefer not to see such tricks again if I can avoid it.
So the paper can serve as inspiration, but it's a non-goal to implement the exact same algorithm.

I'm currently reading the line breaking paper, so once I'm done with that I'll start working on actual code again.

Sounds good :+1:

I've been thinking a lot about whether to favour consistency or efficiency/flexibility. This comes up for example in the return types of wrap_first_fit and wrap_optimal_fit:

If they both return Vecs, wrap_first_fit will always cause an allocation even when one isn't necessary. This also eliminates the possibility of using it in no-std.
If they both return iterators, and a user calling wrap_optimal_fit wants a Vec they'll have to .collect() the result of wrap_optimal_fit even though it is already a vector, causing an unnecessary allocation. This approach does avoid .reverse()ing the vec if we do .into_iter().rev() so maybe it's a good idea anyway? Still, collecting a reversed vector iterator is slower than reversing an existing vector.
If wrap_first_fit returns an iterator but wrap_optimal_fit returns a Vec that's inconsistent and could be confusing.

Similar problems occur in other places too (e.g. wrap_first_fit can take the more flexible iterator of line lengths whereas wrap_optimal_fit must take the less flexible random-access line lengths with Fn(usize) -> usize).
Do you have any thoughts on how to solve this? Do you mind having a slightly inconsistent API if it allows for optimal efficiency?


[SPIKE+] Write a unittest for a simple selection

Creating this one as a Spike + because there is not a single unit test for selection, and selection is very involved.
By trying to write out one unit test for a simple selection, we aim to get a sense of

what fixture do we need to properly start writing unit tests for selection
how much effort it takes to refactor selection out of task into it's own module. So task can start with a selected set of nodes to run.

A list of node types is defined on the task and will filter down the node.

I noticed a set of tests while reorganizing all unit tests.
I think it might be worth spending the 3 points we estimated for this ticket making those better/more consistent.
What do you think @QMalcolm ?


Padding batches with high ranks (>=6) doesn't work

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 20.04
TensorFlow installed from (source or binary): Nvidia docker (nvcr.io/nvidia/tensorflow:21.08-tf2-py3)
TensorFlow version (use command below): 2.5 (default installation) / 2.7 (updated with pip), doesn't work for both
Python version: 3.8.10
CUDA/cuDNN version: 11.4

Describe the problem
Padding batches with high ranks (>=6) doesn't work and raise an tensorflow.python.framework.errors_impl.UnimplementedError: CopyElementToLargerSlice Unhandled rank: 6 error.
Source code / logs
# Rank 5 is working
import tensorflow as tf
a = {"x": tf.ones([1, 1, 1, 1, 1])}
b = {"x": tf.ones([1, 1, 1, 1, 2])}
labels = [a, b]
ds = tf.data.Dataset.from_generator(lambda: iter(labels), output_types={"x": tf.float32})
ds = ds.padded_batch(2, padded_shapes={"x": [None, None, None, None, None]})
list(ds.take(1))
# [{'x': <tf.Tensor: shape=(2, 1, 1, 1, 1, 2), dtype=float32,
#    numpy=array([[[[[[1., 0.]]]]], [[[[[1., 1.]]]]]], dtype=float32)>}]

# Rank 6 doesn't
import tensorflow as tf
a = {"x": tf.ones([1, 1, 1, 1, 1, 1])}
b = {"x": tf.ones([1, 1, 1, 1, 1, 2])}
labels = [a, b]
ds = tf.data.Dataset.from_generator(lambda: iter(labels), output_types={"x": tf.float32})
ds = ds.padded_batch(2, padded_shapes={"x": [None, None, None, None, None, None]})
list(ds.take(1))
# Throws below error

Full error message:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/data/ops/iterator_ops.py", line 800, in __next__
    return self._next_internal()
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/data/ops/iterator_ops.py", line 783, in _next_internal
    ret = gen_dataset_ops.iterator_get_next(
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/ops/gen_dataset_ops.py", line 2845, in iterator_get_next
    _ops.raise_from_not_ok_status(e, name)
  File "/usr/local/lib/python3.8/dist-packages/tensorflow/python/framework/ops.py", line 7107, in raise_from_not_ok_status
    raise core._status_to_exception(e) from None  # pylint: disable=protected-access
tensorflow.python.framework.errors_impl.UnimplementedError: CopyElementToLargerSlice Unhandled rank: 6 [Op:IteratorGetNext]

@Saduf2019 ,
I was able to reproduce the issue in tf v2.7,v2.5 and nightly.Please find the gist here.

This is because only till Rank 5, case is handled, anything above that rank will throw the unimplemented error.
Is there any specific need for Rank above 5 in general use case scenarios.

My usecase was 3d-action-recognition, with a shape of [persons, timesteps, x, y, z, joints]
The workaround was reshaping the tensor before padding (in this case [x,y,z]->[xyz]) and reshaping it back after batching.

I'm currently ok with the workaround.
Is there so much logic behind the padding step? I didn't thought it was restricted to a maximal rank before.

It's base implementation is in C++ and you can see the logic here https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/util/batch_util.cc#L386-L395 which is having the defined cases for rank.


Screen moving in GUis

I use the latest version of the mod for 1.12.2 : MineMenu-1.12.2-1.6.11-universal.jar
My head is moving when i'm moving my mouse in the GUIs.

Duplicate of #76

Duplicate of #76


Add resources page

Add the resources page and redesign it.

What is this supposed to be? Can I help with this one?

What is this supposed to be? Can I help with this one?

@jaredscarr Honestly, I'm not totally sure. It was on the original design of the club website.

This is fine web-development-wise but I'm not sure what content was planned to go here. We can flesh it out, or just remove it.

I like the idea, but it might mean maintaining a bunch of links that could change. The get involved section is covered by Discord. Coursework is covered by the individual teachers and curriculum should probably be outside the scope of the club. Honestly, I think it would be fine to remove this and let these types of questions be directed to Discord where discussion can occur. What do you think?


use Nullable, NonNull and GuardedBy annotations from AndroidX

Summary
This PR replaces JSR-305 Nullable, NonNull and GuardedBy annotations with same annotations from AndroidX, and remove JSR-305 from deps when possible. AndroidX annotation is used in every aspect of AndroidX, thus most packages require it to build.
Changelog
[Android] [Changed] - use Nullable and NonNull annotations from AndroidX
Test Plan

I had to revert the changes to Yoga because it can run outside of Android.

@cpojer excluded yoga from the change

I think I'll need @mdvacca's help to land this :)

Hey @dulmandakh, could you rebase and resolve conflicts on this PR this week so we can merge it? :)

@dulmandakh
Nullable and NonNull annotations were migrated to Android X as part of:
https://github.com/facebook/react-native/commit/aa5edca0e229940c79f2efcb917f5c8b05022e4d
Feel free to close this PR and I will migrate GuardedBy annotations as part of another PR.
CC @cpojer, @makovkastar


Has anyone tried to deploy socket cluster on Azure Container apps?

Container apps hides complexities in managing Kubernetes and take care of auto scaling among other things. I was wondering whether it'll be possible to use Azure container apps instead of kubernetes.
Anyone here who have tried this?

Although I'm not familiar with Azure Container apps. If it's a platform for Kubernetes, which from a short search seems like it is. SocketCluster, by default, is shipped with a configuration for K8S. So you should be able to. If you have a successful deployment, feel free to share how you did it! Perhaps we can add it to the documentation.


[SPARK-42279][PS][TESTS] Simplify pyspark.pandas.tests.test_resample

What changes were proposed in this pull request?
Simplify test_resample
Why are the changes needed?
test_resample may take more than 20min, this PR remove redundant combinations.
In my local env,  249 sec -> 30 sec.
Does this PR introduce any user-facing change?
No, test only
How was this patch tested?
updated tests

master:  https://github.com/apache/spark/actions/runs/4063229672/jobs/6995258363
Starting test(python3.9): pyspark.pandas.tests.test_resample (temp output: /__w/spark/spark/python/target/100da025-d91f-49a5-a584-c5b6b73b5fe8/python3.9__pyspark.pandas.tests.test_resample__eaa8shha.log)
Finished test(python3.9): pyspark.pandas.tests.test_resample (715s)

in this PR
Starting test(python3.9): pyspark.pandas.tests.test_resample (temp output: /__w/spark/spark/python/target/ee3dab52-733a-4fd0-8df8-94753436bc56/python3.9__pyspark.pandas.tests.test_resample__5jmdqzv1.log)
Finished test(python3.9): pyspark.pandas.tests.test_resample (58s)

cc @HyukjinKwon

Merged to master and branch-3.4.


Index title can be configured by docbase-config.js with title property.

If someone want to change index title, does not need to modify index.html anymore. This can be done by docbase-config.js. HTML is also supported.
Example of usage:
var docbaseConfig = {
  "name": "defaultConfig",
  "method": "file",
  "title": "Doc<b>base</b>"
  // ...
}

There was something wrong with the build https://travis-ci.org/appbaseio/Docbase/jobs/123638746
It is something with dependencies. Can you check that?

@mateusfreira, I'll check and solve

Thanks for the contribution @StanleySathler!


Errors in documentation

Here I want to collect all errors in DT documentation to qucikly access for them. If you has one - comment it here - I'll add to the list

[x] [api.column().index()] (https://datatables.net/reference/api/column().index()) The return type is wrong. Should be 'Integer' instead of 'DataTables.Api'
[x] [api.columns()] (https://datatables.net/reference/api/columns()) The type of 'column-selector' argument should be 'column-selector' instead of 'column-cell'

Hi,
Thanks for flagging this up. Both have been addressed in this commit and will be pushed out to the site with the next update.


To do list

I did the following on this Repo:

Created Repo To-Do-List.
Cloned the Repo.
Created a feature branch.
Modify the README.md file.
Initialized my repo.
Install webpack.
Add .gitignore file.
Add src/ folder with .html, .css, and .js files.
Add dist/ folder.
Configure the webpack.
Fix Linter errors.

@tufoinnkuo10

Checked and Confirmed I did changes as per the previous reviewer.
Approved.


prisma db push generating identifier names longer than 64 characters

Bug description
I have relations between complex objects that generates long identifier names.
While executing prisma db push Prisma appends '_ibfk_1' even if it will have more than 64 characters after appending. My use case is to be used by Jest for pushing the schema into test database.
It rejects promise:
Promise {
        <rejected> Error: Command failed: /Users/../../../node_modules/.bin/prisma db push --preview-feature
        Error: Database error: Error querying the database: Server error: `ERROR 42000 (1059): Identifier name 'foundation_variable_set_foundation_configuration_values_aud_ibfk_1' is too long'
           0: sql_migration_connector::sql_database_step_applier::apply_step
                   with index=0
                     at migration-engine/connectors/sql-migration-connector/src/sql_database_step_applier.rs:14
           1: migration_core::api::SchemaPush
                     at migration-engine/core/src/api.rs:166

How to reproduce

Have a Prisma schema in which there are table names with length larger than 57 characters (64 - 7) as '_ibfk_1' has 7 characters.
run prisma db push --preview-feature
Expect an error to be thrown

Expected behavior

Generate an alternative name which is shorter than 64 characters, or
Let the user choose custom name for the identifier
In my case I can't really change the MySQL schema and I need to work with what I have.
I know these names are unnecessary and repetitive but that's what Prisma generates.
Prisma information

The schema is pretty big so I include the part of it:
model foundation_variable_set_foundation_configuration_values_aud {
  REV                Int
  CompanyVariable_id Int
  valueList_id       Int
  REVTYPE            Int?
  DeviceVariable_id  Int
  GroupVariable_id   Int
  revinfo            revinfo @relation(fields: [REV], references: [REV])

  @@id([REV, GroupVariable_id, valueList_id])
}

Environment & setup

OS: MacOS
Database: MySQL
Node.js version: 12.16.1
Prisma version: 12.15.0

I can confirm this. I think either we should ask the user to put the name of the fk in the schema or we should trim the name of the generated fk name.
Below schema reproduced the crash for me. Max limit of mysql foreign key name length is 64 as mentioned by you. So had to add one more character to the shared schema for reproduction.

model foundation_variable_set_foundation_configuration_values_aud_ {
  REV                Int
  CompanyVariable_id Int
  valueList_id       Int
  REVTYPE            Int?
  DeviceVariable_id  Int
  GroupVariable_id   Int
  test               User @relation(fields: [userId], references: [id])

  userId String
  @@id([REV, GroupVariable_id, valueList_id])
}

model User {
  id   String @id @default(uuid())
  name String

 field foundation_variable_set_foundation_configuration_values_aud_?
}

This is still reproducible in 2.22

I catch this problem when trying to create relation, that joins model name with field name, as result composing string with more than 64 characters.
What do you think about implementing workaround via reserve last symbol to number, and iterate all long names with unique numbers?

This is currently being worked on, expect a preview feature to make it into a release soon.

A fix for this issue is now available via the namedConstraints preview flag since 2.29. It implements both solutions mentioned above, a default name generation that respects db name length limits and the option for user-specified names.
See https://www.prisma.io/docs/guides/upgrade-guides/upgrading-to-use-preview-features/enabling-named-constraints


cf create-buildpack fails with 500 error - cloud_controller_ng.log shows Permission denied @ rb_sysopen using CF 253 and local NFS blobstore

Issue
Using CF 253, cf create-buildpack is returning a 500 error.  The cloud_controller_ng.log shows error:  Permission denied @ rb_sysopen
Context
cloud_controller_ng.log shows:
{"timestamp":1507811621.162408,"message":"cp_to_blobstore-retry","log_level":"debug","source":"cc.blobstore","data":{"request_guid":"b2bce9be-4594-4bfd-4977-f2d2b4ea642d::d83a2926-2784-49a0-b16d-4e0be19d539c","error":"Input/output error @ fptr_finalize - /var/vcap/nfs/shared/cc-buildpacks/8d/3c/8d3ccb97-5fb2-4885-acb6-0c31a968c0ce_21be9f1ab8ce3cc605c07bc6196aa970a3cf83255b3f4ce98fe5d4673e4a9edf","remaining_retries":2,"args":{"source_path":"/var/vcap/data/cloud_controller_ng/tmp/uploads/0000000001","destination_key":"8d3ccb97-5fb2-4885-acb6-0c31a968c0ce_21be9f1ab8ce3cc605c07bc6196aa970a3cf83255b3f4ce98fe5d4673e4a9edf"}},"thread_id":47206024060760,"fiber_id":47206033866320,"process_id":27277,"file":"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/blobstore/retryable_client.rb","lineno":131,"method":"rescue in with_retries"}
{"timestamp":1507811621.6277585,"message":"blobstore.cp-start","log_level":"info","source":"cc.blobstore","data":{"request_guid":"b2bce9be-4594-4bfd-4977-f2d2b4ea642d::d83a2926-2784-49a0-b16d-4e0be19d539c","destination_key":"8d3ccb97-5fb2-4885-acb6-0c31a968c0ce_21be9f1ab8ce3cc605c07bc6196aa970a3cf83255b3f4ce98fe5d4673e4a9edf","source_path":"/var/vcap/data/cloud_controller_ng/tmp/uploads/0000000001","bucket":"cc-buildpacks"},"thread_id":47206024060760,"fiber_id":47206033866320,"process_id":27277,"file":"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/blobstore/fog/fog_client.rb","lineno":53,"method":"cp_to_blobstore"}
{"timestamp":1507811621.6300044,"message":"cp_to_blobstore-retry","log_level":"debug","source":"cc.blobstore","data":{"request_guid":"b2bce9be-4594-4bfd-4977-f2d2b4ea642d::d83a2926-2784-49a0-b16d-4e0be19d539c","error":"Permission denied @ rb_sysopen - /var/vcap/nfs/shared/cc-buildpacks/8d/3c/8d3ccb97-5fb2-4885-acb6-0c31a968c0ce_21be9f1ab8ce3cc605c07bc6196aa970a3cf83255b3f4ce98fe5d4673e4a9edf","remaining_retries":1,"args":{"source_path":"/var/vcap/data/cloud_controller_ng/tmp/uploads/0000000001","destination_key":"8d3ccb97-5fb2-4885-acb6-0c31a968c0ce_21be9f1ab8ce3cc605c07bc6196aa970a3cf83255b3f4ce98fe5d4673e4a9edf"}},"thread_id":47206024060760,"fiber_id":47206033866320,"process_id":27277,"file":"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/blobstore/retryable_client.rb","lineno":131,"method":"rescue in with_retries"}
{"timestamp":1507811621.630315,"message":"blobstore.cp-start","log_level":"info","source":"cc.blobstore","data":{"request_guid":"b2bce9be-4594-4bfd-4977-f2d2b4ea642d::d83a2926-2784-49a0-b16d-4e0be19d539c","destination_key":"8d3ccb97-5fb2-4885-acb6-0c31a968c0ce_21be9f1ab8ce3cc605c07bc6196aa970a3cf83255b3f4ce98fe5d4673e4a9edf","source_path":"/var/vcap/data/cloud_controller_ng/tmp/uploads/0000000001","bucket":"cc-buildpacks"},"thread_id":47206024060760,"fiber_id":47206033866320,"process_id":27277,"file":"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/blobstore/fog/fog_client.rb","lineno":53,"method":"cp_to_blobstore"}
{"timestamp":1507811621.6316981,"message":"cp_to_blobstore-retry","log_level":"debug","source":"cc.blobstore","data":{"request_guid":"b2bce9be-4594-4bfd-4977-f2d2b4ea642d::d83a2926-2784-49a0-b16d-4e0be19d539c","error":"Permission denied @ rb_sysopen - /var/vcap/nfs/shared/cc-buildpacks/8d/3c/8d3ccb97-5fb2-4885-acb6-0c31a968c0ce_21be9f1ab8ce3cc605c07bc6196aa970a3cf83255b3f4ce98fe5d4673e4a9edf","remaining_retries":0,"args":{"source_path":"/var/vcap/data/cloud_controller_ng/tmp/uploads/0000000001","destination_key":"8d3ccb97-5fb2-4885-acb6-0c31a968c0ce_21be9f1ab8ce3cc605c07bc6196aa970a3cf83255b3f4ce98fe5d4673e4a9edf"}},"thread_id":47206024060760,"fiber_id":47206033866320,"process_id":27277,"file":"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/blobstore/retryable_client.rb","lineno":131,"method":"rescue in with_retries"}
{"timestamp":1507811621.6325166,"message":"Request failed: 500: {\"error_code\"=>\"UnknownError\", \"description\"=>\"An unknown error occurred.\", \"code\"=>10001, \"test_mode_info\"=>{\"description\"=>\"Permission denied @ rb_sysopen - /var/vcap/nfs/shared/cc-buildpacks/8d/3c/8d3ccb97-5fb2-4885-acb6-0c31a968c0ce_21be9f1ab8ce3cc605c07bc6196aa970a3cf83255b3f4ce98fe5d4673e4a9edf\", \"error_code\"=>\"CF-EACCES\", \"backtrace\"=>[\"/var/vcap/packages/ruby-2.3/lib/ruby/2.3.0/fileutils.rb:1393:in `initialize'\", \"/var/vcap/packages/ruby-2.3/lib/ruby/2.3.0/fileutils.rb:1393:in `open'\", \"/var/vcap/packages/ruby-2.3/lib/ruby/2.3.0/fileutils.rb:1393:in `block in copy_file'\", \"/var/vcap/packages/ruby-2.3/lib/ruby/2.3.0/fileutils.rb:1392:in `open'\", \"/var/vcap/packages/ruby-2.3/lib/ruby/2.3.0/fileutils.rb:1392:in `copy_file'\", \"/var/vcap/packages/ruby-2.3/lib/ruby/2.3.0/fileutils.rb:486:in `copy_file'\", \"/var/vcap/packages/ruby-2.3/lib/ruby/2.3.0/fileutils.rb:403:in `block in cp'\", \"/var/vcap/packages/ruby-2.3/lib/ruby/2.3.0/fileutils.rb:1571:in `block in fu_each_src_dest'\", \"/var/vcap/packages/ruby-2.3/lib/ruby/2.3.0/fileutils.rb:1587:in `fu_each_src_dest0'\", \"/var/vcap/packages/ruby-2.3/lib/ruby/2.3.0/fileutils.rb:1569:in `fu_each_src_dest'\", \"/var/vcap/packages/ruby-2.3/lib/ruby/2.3.0/fileutils.rb:402:in `cp'\", \"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.3.0/gems/fog-local-0.3.1/lib/fog/storage/local/models/file.rb:98:in `save'\", \"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.3.0/gems/fog-core-1.43.0/lib/fog/core/collection.rb:51:in `create'\", \"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/blobstore/fog/fog_client.rb:70:in `block in cp_to_blobstore'\", \"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/blobstore/fog/fog_client.rb:57:in `open'\", \"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/blobstore/fog/fog_client.rb:57:in `cp_to_blobstore'\", \"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/blobstore/retryable_client.rb:46:in `block in cp_to_blobstore'\", \"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/blobstore/retryable_client.rb:126:in `with_retries'\", \"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/blobstore/retryable_client.rb:40:in `cp_to_blobstore'\", \"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/blobstore/fog/error_handling_client.rb:49:in `block in cp_to_blobstore'\", \"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/blobstore/fog/error_handling_client.rb:55:in `error_handling'\", \"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/blobstore/fog/error_handling_client.rb:49:in `cp_to_blobstore'\", \"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/upload_buildpack.rb:22:in `upload_buildpack'\", \"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/app/controllers/runtime/buildpack_bits_controller.rb:33:in `upload'\", \"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/app/controllers/base/base_controller.rb:80:in `dispatch'\", \"/var/vcap/data/packages/cloud_controller_ng/50f1e9080429f03d8fbdaede647d08e8a1bac2f5/cloud_controller_ng/lib/cloud_controller/rest_controller/routes.rb:16:in `block in define_route'\", \"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1610:in `call'\", \"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1610:in `block in compile!'\", \"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:975:in `block (3 levels) in route!'\", \"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:994:in `route_eval'\", \"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:975:in `block (2 levels) in route!'\", \"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1015:in `block in process_route'\", \"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1013:in `catch'\", \"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1013:in `process_route'\", \"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:973:in `block in route!'\", \"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:972:in `each'\", \"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:972:in `route!'\", ........

I can see that the buildpack gets uploaded to /var/vcap/data/cloud_controller_ng/tmp/uploads and then gets moved to the local nfs /var/vcap/nfs/shared/cc-buildpacks/8d/3c
# ls -al /var/vcap/nfs/shared/cc-buildpacks/8d/3c/
total 481864
drwxr-xr-x 2 vcap vcap      4096 Oct 12 12:33 .
drwxr-xr-x 3 vcap vcap      4096 Oct 12 12:33 ..
-r-------- 1 vcap vcap 493419433 Oct 12 12:33 8d3ccb97-5fb2-4885-acb6-0c31a968c0ce_21be9f1ab8ce3cc605c07bc6196aa970a3cf83255b3f4ce98fe5d4673e4a9edf

However there is some error during this process that causes an error.
Steps to Reproduce

Install CF 253, use local NFS blobstore
cf create-buildpack
Error displayed

FAILED
Server error, status code: 500, error code: 10001, message: An unknown error occurred.

Expected result
The buildpack should successfully be loaded and saved.
Current result
buildpack cannot be created via cf command line
Possible Fix
Similar item reported in #897, but that was on a newer CF version

Keeping issue updated with slack #capi discussion

Unfortunately I couldn't reproduce this with cf create-buildpack nor with cf update-buildpack. Could you provide a step-by-step repro?  I also  tried this both with and without our fix for issue 897 --@ericp

Does any of this depend on the umask value for root or vcap?  What should the umask value be on the vm cloud_controller_ng and debian_nfs_server runs on?

We tried updating a file with the changes for https://github.com/cloudfoundry/cloud_controller_ng/commit/ef4ec09a20f4984ca4fed51c3927474dd1d6a01e but it did not help

One thing we tried was changing so that the debian_nfs_server was not used by buildpacks.  We used a local directory.  Basically cc:, used /var/vcap/data.
    buildpacks:
      blobstore_type: fog
      buildpack_directory_key: cc-buildpacks
      cdn: null
      fog_connection:
        #local_root: /var/vcap/nfs/shared
        local_root: /var/vcap/data
        provider: Local

This worked for creating buildpacks.   Any ideas on what we should do to debug what seems to be a debian_nfs_server issue?

@chrisahl @gcoon151 we've got a story coming up to get a CI env setup with NFS: https://www.pivotaltracker.com/story/show/150375975. Once that's done we can dig a little deeper into this issue.
I should also note that while CC does support NFS as a blobstore via the nfs_mounter, I believe we consider the debian_nfs_server to be somewhat deprecated. We don't run tests against it and can't vouch for whether it still works. I'm not sure whether there is another bosh release of NFS server that is better supported.

@ljfranklin Based on recent testing, we have narrowed the error down to how the vm running cloud_controller_ng mounts NFS.  The mount is coming from:
/var/vcap/data/jobs/nfs_mounter/6f7ef273c98b6d88b25c9c886422675591f049a5/bin/handle_nfs_blobstore.sh:  mount --verbose -o timeo=10,intr,lookupcache=positive,soft -t nfs 0.debian-nfs-server.default.bluemix.microbosh:/var/vcap/store $NFS_SHARE
We are experimenting with trying:

increasing the timeo value
changing from soft to hard
Both have given better results.  We would be interested in what your team's preference would be for a code change.    By this afternoon we hope to have more definite results after additional testing.

We have finished our testing of a patch for cf create-buildpacks.   We want the file handle_nfs_blobstore.sh (e.g. /var/vcap/data/jobs/nfs_mounter/6f7ef273c98b6d88b25c9c886422675591f049a5/bin/handle_nfs_blobstore.sh) to be changed so that the NFS mount uses timeo=100 instead of timeo=10.
This change produced 100% success for us.

@chrisahl interesting, looks like timeo param for NFS mount is in deciseconds instead of seconds: https://linux.die.net/man/5/nfs. The default value in the docs is 600 (60 seconds) before retrying a request. I can definitely imagine a value of 10 being too low even in a fairly healthy network.
As to changing from hard to soft, we had explicitly changed that mode as part of this story: https://www.pivotaltracker.com/story/show/121711865. As we checksum all the blobs before putting them in the blobstore, the possible data integrity issues mentioned in the docs around soft mode should be mitigated. When hard mode was enabled users could get their deployments wedged in strange states if the NFS server was ever unavailable.

fixed here: 254fbca


Use a hashset for scopes

The OAuth struct uses a vector for scopes but it would be better to use a hash set since it is made to ensure that the values are unique.

For tests, It would need to be possible to preserve order. One possible way is to first sort the scopes so that a test Url is predictable.

We can preserve ordering with BTreeSet as well.


Fresh Install of CMS 3.7.4 does not install logos/fonts

Description
I have found that a fresh install of django CMS does not load the icons/font resources.
## Steps to reproduce
Running Python 3.8.2 and Django 3.0.10 in a venv and having installed django-cms via pip using the command
pip install django-cms
then
pip install djangocms-installer
then
djangocms evenmore
When logging in to the site immediately after the installation concludes, the following is produced at the runserver output:
(pppvenv) paula@saturn:/var/ppp/evenmore$ ./manage.py runserver 0:12321
Watching for file changes with StatReloader
Performing system checks...
System check identified no issues (0 silenced).

Actual behaviour
icons and fonts are not present
Additional information
The static directories are both completely empty. Everything else is fully working properly.

apologies, no longer able to reproduce.


[Impeller] Potential rendering bug in widgets.shadow.shape_decoration

Bug with how we are producing the texture?

I don't see this in https://flutter-gold.skia.org/search?corpus=flutter&include_ignored=false&left_filter=name%3Dwidgets.shadow.ShapeDecoration.0&max_rgba=0&min_rgba=0&negative=true&not_at_head=false&positive=true&reference_image_required=false&right_filter=&sort=descending&untriaged=true


[TRI-1655] Ability to cancel all runs for a Job (from SDK)

Something like: client.cancelRunsForJob('<you_job_id>')
It would behave like cancelRunsForEvent in what would happen to the runs.
TRI-1655

@matt-aitken will u pls explain me this issue a little bit more ... so that i can try to solve it


Consider changing gRPC default settings for OTLP-Arrow

Is your feature request related to a problem? Please describe.
We are aware that several flags are strongly recommended for OTLP-Arrow users.
wait_for_ready prevents downgrade when the endpoint may be intermittently up
keepalive: max_connection_age: and
keepalive: max_connection_age_grace are recommended for load balancing concerns.
Describe the solution you'd like
Consider overriding these defaults when OTLP-Arrow is used, somehow?
Describe alternatives you've considered
It will be difficult to change these settings, so we can just documented our recommendations.

More obviously, the defaults for Arrow: Enabled are false in both components, but as standalone components it makes sense to enable them by default.


Fiddle with compute stuff

split the pods out so that etcd and the log server are logically separate entities.
add some handy turnup/down scripts
increase etcd timeouts

LGTM


use redis-py-cluster unable to connect to redis cluster in python 2.7

I follow the official documents: https://redis-py-cluster.readthedocs.io/en/master/ The example given is writing code to connect to my Redis cluster, but an error was reported: RedisCluster. exceptions. RedisClusterException: ERROR sending 'config get cluster require full coverage' command to Redis server: {'host ': u'196.2.xx. xx', 'server_ Type ':' slave ',' port ': 8xxxL,' name ':' 196.2.xxx. xx: 8xxx ', the strangest thing is that this IP address is not present in my code
# -*- coding: utf-8 -*-
from rediscluster import RedisCluster
startup_nodes = [
	{"host": "host1", "port": "port1"},
	{"host": "host2", "port": "port2"},
	...
]
# 构建StrictRedisCluster对象
src = RedisCluster(startup_nodes=startup_nodes, decode_responses=True)
# 获取键为name
name = src.get('20231024')
src.close()
print(name)

@RuoCJ Interesting case. But in general, the code here do not do any magic or adding of hosts or ports by itself if you do not specify it. If you have a startup_node that can be reached by any name or ip, it will find the cluster and ask the cluster for the config, and as you mention in the error, it has found a host and port that the cluster is on and at some point, one of the nodes have answered back with the cluster configuration and that is where it has picked up the ip+port.
My wild guess tho is that you somehow in your configuration on your machine where you run this code, can do a DNS lookup to one of the host string names you have specified in the startup_nodes variable so if you would do ping host1 for instance, it would get an IP, and it would attempt to reach the cluster on that ip to find the cluster configuration from it.
If that is not the truth, then you have to dig deeper and really root out where this comes from.
Lastly, this repo is since a long time ago now part of redis-py. No fixes of patches will be added to this repo and you are encouraged to migrate over to redis-py moving forward for all your redis-cluster needs

@RuoCJ Interesting case. But in general, the code here do not do any magic or adding of hosts or ports by itself if you do not specify it. If you have a startup_node that can be reached by any name or ip, it will find the cluster and ask the cluster for the config, and as you mention in the error, it has found a host and port that the cluster is on and at some point, one of the nodes have answered back with the cluster configuration and that is where it has picked up the ip+port.
My wild guess tho is that you somehow in your configuration on your machine where you run this code, can do a DNS lookup to one of the host string names you have specified in the startup_nodes variable so if you would do ping host1 for instance, it would get an IP, and it would attempt to reach the cluster on that ip to find the cluster configuration from it.
If that is not the truth, then you have to dig deeper and really root out where this comes from.
Lastly, this repo is since a long time ago now part of redis-py. No fixes of patches will be added to this repo and you are encouraged to migrate over to redis-py moving forward for all your redis-cluster needs

Due to the Python version, I am unable to use the higher version of redis-py, so I am unable to use redis-py to connect to the Redis cluster. The solution to this problem is to add parameters: skip_session_full_coverage_check=True


Added DietPi os ASCII art

Description
Added DietPi os ASCII art

Features
Issues
TODO

It has been not accepted in the past https://github.com/dylanaraps/neofetch/pull/1706#discussion_r651435345

It has been not accepted in the past #1706 (comment)

Since DietPi can now be correctly identified with the existing distro detection methods, I think we can merge it now.

I think #1706 looks better than this one so I'm going to merge #1706


[Question] Can't get list of exports from DLLs on disk

I'm using the MEF plug-in architecture. I have my ComposablePart.dll file in the executable's folder. The code is as per below:
using System.ComponentModel.Composition;

namespace ComposablePart
{
    [Export]
    public class ComposablePart : IMyInterface
    {
        public string SayHello()
        {
            return "Hello, this is the message!";
        }
    }
}

I'm using the example MefHosting class and code at https://github.com/microsoft/vs-mef/blob/master/doc/hosting.md and I can see my ComposablePart.dll in the config.Parts property on this line:
var config = CompositionConfiguration.Create(catalog);
but then it gets lost.
I tried to:
var program = exportProvider.GetExports<IMyInterface>().ToList();
but there are zero elements.
Can you suggest some code to get all the exports from the Dlls (one export per DLL) to populate the list of List<IMyInterface> ?

Your problem in this case is that you're [Export] exports the type that is decorated, but you're querying for one of its interfaces. If you [Export] then you need to GetExports<ComposablePart>().
If you want to GetExports<IMyInterface> then you need to [Export(typeof(IMyInterface))].

Is there a way of doing the export without specifying the [Export] attribute?
I thought there was a way for the host program to skim through the Dlls and particular interfaces (or class names) and import them into a list just by the name (with no attribute required). Otherwise, the 'plugin' DLL  seems to need either System.ComponentModel.Composition or vs-mef  as a dependency. This means the creator of a plugin that will implement the common interface has to download/install an extra package. I would rather have them simply implement a POCO object.
Is this possible?
Thanks again.

Is there a way of doing the export without specifying the [Export] attribute?

Yes. You can build your own PartDiscovery-derived class that looks for interface types that you find interesting instead of attributes. You can look at our two derived types for inspiration on how to do this. Our derived classes can look rather complicated because the attributes have so many subtle behaviors, but ultimately you're just responsible for creating a ComposablePartDefinition any time you identify a type that exports or imports something and should be included in the catalog.


KTime: Sync with realtime clock

Summary

Moved KTime / GetKTime from util to times package
Periodic sync with realtime clock (instead of boottime monotonic)

Gave it a spin with the latest changes.
When after putting my machine to sleep for ~10min... the timestamps after wake-up are off by these 10mins. I guess until the sync kicks in... Maybe we can make the sync every 1min or is this eating too much CPU in comparison to the total CPU usage of the agent (which is very low)?

I guess until the sync kicks in... Maybe we can make the sync every 1min or is this eating too much CPU in comparison to the total CPU usage of the agent (which is very low)?

It's a tradeoff, but not really for CPU usage: higher sync frequency increases the time window where timestamps can be off relative to realtime clock but lower sync frequency also increases possible number of discontinuities (e.g. timestamps jumping around). We should probably make sync frequency configurable and allow for it to be zero (in which case we're reverting to Option 1).

I guess until the sync kicks in... Maybe we can make the sync every 1min or is this eating too much CPU in comparison to the total CPU usage of the agent (which is very low)?

It's a tradeoff, but not really for CPU usage: higher sync frequency increases the time window where timestamps can be off relative to realtime clock but lower sync frequency also increases possible number of discontinuities (e.g. timestamps jumping around). We should probably make sync frequency configurable and allow for it to be zero (in which case we're reverting to Option 1).

Having a configurable value sounds good to me.
Is it a common issue that timestamps are jumping back and forth as you say? I can't remember ever having an issue with that. Jumps should be relatively rare under normal conditions.
Meanwhile, the sync kicked in. I have ~10mins of wrong time stamps and a gap in my time series at a wrong and unexpected time range.
So I wonder if we can't detect jumps in time faster and only resync when required. Wasn't that what the current code is doing?

So I wonder if we can't detect jumps in time faster and only resync when required. Wasn't that what the current code is doing?

The current code is more complicated and the consensus in previous discussions was to drastically simplify. We can certainly add threshold logic (Option 3) if the current consensus is that it's worth it.
My preference is to make sync-frequency configurable and lower the frequency e.g. (2-3 minutes).
IIRC a few other Go agents that deal with monotonic timestamps that I've looked at only sync once and keep the delta fixed for the life of the agent.

My preference is to make sync-frequency configurable and maybe reduce the default value (e.g. 2-3 minutes).

Sounds pragmatic, 2-3 minutes is acceptable at least to me.
Maybe add a short section to the README to explain the timestamp issue after sleep/power-saving!?


write-fonts: Fix clippy::single_match lint

Now that Rust 1.82 is out, this is probably needed for CI to pass.


Add guidelines from lwj

This pdf is not that huge...so feels unnecessary to use git lfs

Less responsibility for further bug :).


Multiple Errors in Single Line

Compiler API is not that perfect to for handling multiple missing symbols in single line. It only reports the first missing symbol as the expected symbol. We need to parse it manually or do it some way ? Any Ideas ?

Afif kya reaction dera yaar nikalo iskoo baher yha se !!


repeated search results as a result of forked process and RxJS combination

Combining RxJS and forked process in IPC main process results in multiple and repeated search results.

fixed via workaround: currently removing exisiting results and this is done in the renderer process (Angular). Find implementation in (grabInput) 5db670413d0d888f6b6d7f701b43a72b6da09ba8


cookiecutter cloning/loading error messages not cleared soon enough

They should be cleared as soon as the next cloning/loading starts, rather then when it finishes.  Otherwise you are still seeing that error during the next slow clone operation, and it only goes away when that finishes.
Repro:
clone chrisdev/wagtail-cookiecutter-foundation
error appears
clone pydanny/cookiecutter-django
error disappears only once clone is finished

This was fixed some time ago.


Update dependency typescript to v3.6.4

This PR contains the following updates:

Package
Type
Update
Change

typescript (source)
devDependencies
minor
3.5.3 -> 3.6.4

Release Notes

Microsoft/TypeScript
v3.6.4
Compare Source
For release notes, check out the release announcement.
For the complete list of fixed issues, check out the

fixed issues query for Typescript v3.6.4.
fixed issues query for Typescript v3.6.3.
fixed issues query for Typescript v3.6.2.
fixed issues query for Typescript v3.6.1.
fixed issues query for Typescript v3.6.0.

Downloads are available on:

npm
Visual Studio (Select new version in project options)
NuGet package

v3.6.3
Compare Source
For release notes, check out the release announcement.
For the complete list of fixed issues, check out the

fixed issues query for Typescript v3.6.3.
fixed issues query for Typescript v3.6.2.
fixed issues query for Typescript v3.6.1.
fixed issues query for Typescript v3.6.0.

Downloads are available on:

npm
Visual Studio (Select new version in project options)
NuGet package

v3.6.2
Compare Source
For release notes, check out the release announcement.

For the complete list of fixed issues, check out the

fixed issues query for Typescript v3.6.2.
fixed issues query for Typescript v3.6.1.
fixed issues query for Typescript v3.6.0.

Downloads are available on:

npm
Visual Studio (Select new version in project options)
NuGet package

Renovate configuration
:date: Schedule: At any time (no schedule defined).
:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.
:recycle: Rebasing: Whenever PR becomes conflicted, or if you modify the PR title to begin with "rebase!".
:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

PR has been edited
:construction_worker: This PR has received other commits, so Renovate will stop updating it to avoid conflicts or other problems. If you wish to abandon your changes and have Renovate start over you may click the "rebase" checkbox in the PR body/description.


Add cli support for global and organization secrets

cli support for secrets added in #1027

please update branch ;)

@lafriks yould you invite me to your fork or the fork-org ?
so I can apply stuff too

@6543 done

@lafriks yould you invite me to your fork or the fork-org ?
so I can apply stuff too

added


Update interfaces.cpp

whats the point of this?

first one crashing for me

ill try this rn, it should be fine like this

i dont remember any game updates, but yeah seems like this is outdated

New one is crashing, but old is working fine to me

New one is crashing, but old is working fine to me

It's crashing only with new beta, if u are using stable build use old indexes

New one is crashing, but old is working fine to me

It's crashing only with new beta, if u are using stable build use old indexes

Ohok


Fix unstable qunit tests.

https://travis-ci.org/testcafe-build-bot/testcafe/jobs/123972863#L1183
https://travis-ci.org/testcafe-build-bot/testcafe/jobs/123978257#L1183
https://travis-ci.org/testcafe-build-bot/testcafe/jobs/123984540#L1181
https://travis-ci.org/testcafe-build-bot/testcafe/jobs/123990910#L1183
They are mostly ios and android tests, but it can be os x test.

one more:
https://travis-ci.org/testcafe-build-bot/testcafe/jobs/124983050#L1186

At the current moment most falling tests are (descending on occurence):
Content-editable (/fixtures/runner/content-editable/api-actions-content-editable-test/index-test.js)
Test: difficult inverse select
message: Timeout is exceeded
expected: true
actual: false
Test: $startElement and $endElement
message: Timeout is exceeded
expected: true
actual: false
Test: without args
message: Timeout is exceeded
expected: true
actual: false
Select (/fixtures/runner/api/select-test/index-test.js)
Test: positive offset as a parameters
message: Timeout is exceeded
expected: true
actual: false
Test: startLine, startPos less than endLine, endPos as a parameters
message: Timeout is exceeded
expected: true
actual: false
Test: zero offset as a parameters
message: Timeout is exceeded
expected: true
actual: false
Cross-domain - in-iframe (/fixtures/runner/cross-domain/in-iframe-test.js)
Test: shared data
message: failed, expected argument to be truthy, was: false
expected: true
actual: false
Press (/fixtures/runner/api/press-test.js)
Test: B238757 - It is impossible to record and run 'press' action with '+' key
message: TypeError: n is null
The list can be extended.

I've seen this test failing frequently before:
https://travis-ci.org/testcafe-build-bot/testcafe/jobs/124989990#L1188
Press (/fixtures/runner/api/press-test.js)
Test: B253200 - TestCafe doesn't emulate browsers behavior for press "enter" key on the focused HyperLink editor (link with javascript)
message: Timeout is exceeded
expected: true
actual: false

Thanks @AndreyBelym, i updated comment above.

Found next behavior in IOS:
If safari just opened the page and we have called window.scrollTo () method, the page will scroll to specified coords, then to the top position, then to last scroll position (if we were on this page before) and after this all it will scroll again to our specified position. If we have immediatly called window.scrollTo() method  several times after page has been opened and without (or with small) delay between calls, this odd chain will be executed after our last method call.

Adding to the previous comment: it's reproduced only on saucelabs virtual machines with ios device emulators. It's not reproduced on macbook and browserstack

Found next behavior on Android simulator platform:
Overriding native dialog method, like in example below, will provoke native environment to call overriden method. It brings to raising unexpected dialog error, and the tests, where we check that an error wasn't raised, fail.
window.alert = function() {

};

We have fixed frequently blinking tests so I close this. We will open a new issue (or reopen this one) if when we discover other unstable tests


⚠ SCOD has degraded performance

In b332b44, SCOD ($URL_SCOD) experienced degraded performance:

HTTP code: 200
Response time: 5639 ms

Resolved: SCOD performance has improved in cf49c4b after 567 days, 9 hours, 47 minutes.


Security update for June '24 LTSR release

updates net, protobuf and apimachinery pkgs
Addresses the following issues

https://github.ibm.com/IBMPrivateCloud/roadmap/issues/63048
https://github.ibm.com/IBMPrivateCloud/roadmap/issues/63164

/retest

/retest

/retest


v0.2.0

Notes/Changes

Results now reproducible in multiple builds/executions
Modifiers now affect the output properly
Progress Bar has been stripped down to improve performance
Expose public api through lib.rs

MASSIVE SPEED INCREASE (1.6GB file now finishes in 20/21 seconds)

Nice