Adding localization support to improve accessibility

While accessibility labels and ARIA support seem to exist, many statically generated sites like app landing pages or documentation sites would be vastly more accessible if they were available in multiple languages. From what I understand, it would be already possible to create a view with buttons that link to separate subfolders of articles (such as en, de-DE etc.). But there are a few others things that need to be considered for a website with multi-language support:

A way to adjust the language value of the Site based on the current language settings (this line)
A way to provide different values for String parameters such as for a sites description or a buttons label
A built-in way to know/determine the supported languages of a site during build
A built-in language switcher component that automatically lists the supported languages & sets it on click
Some kind of string table where users can provide different values for different languages

I know that this sounds like adding a dynamic layer to this "static" site generator. Localization in my opinion is for sure a "dynamic" aspect worth providing, but if implemented in a thoughtful manner, we can retain the static aspect by simply creating a duplicate of each page with only the localized texts changed. The language could be provided at root path level via the Language enums raw value, leading to URLs like https://ignitesamples.hackingwithswift.com/de/grid-examples/. We could generate variants of all pages for each supported language and place them in the respective folder (e.g. de) so everything still is static.
But we would need some JavaScript to set the language value based on the path during page load, so things like the metadata have the correct language set. For things like the usage of localizedContains, while building the different language subfolders, we would need to set a custom locale with the current language being generated for accurate results.
As for the string table, I would suggest we use a subset of String Catalogs as we don't need all features, such as "Vary by device". We could even start without pluralization support to keep things simple. I'm happy to donate my Codable struct to parse them, which I have already implemented for one of my apps. Updating that is simple enough in case Apple makes changes. It's versioned as well, so we should be able to notice easily. This year, they didn't change anything to the structure, so it should be pretty stable. But I'm happy to adjust the code whenever needed.
Using String Catalogs rather than a custom format has great advantages:

Users can use well-known APIs like String(localized:) to specify texts that should be localized
We can adjust existing components to accept LocalizedStringKey rather than String where needed
Xcode will automatically extract the localizable texts to the String Catalog on build/run
Xcode provides an easy-to-use editor for String Catalogs built into Xcode with localization progress & more

As not everyone will need or want to localize their sites, we should keep this as opt-in and default to exactly the same behavior without any subpaths like /en. Also, a default language should be set and used as a fallback for when a domain is called without any language subpath. I'm not sure if a safe redirect is even possible on static site calls, so the default locale files should just live in the root directory.
Please let me know what you think about adding localization support and also about my suggestion. I'm happy to do provide an initial version of localization support once you've approved that what I outlined makes sense to you.

Someone else asked me about this by email, and I think it's a great idea – I'd love for Ignite sites to be localized, where possible!

But we would need some JavaScript to set the language value based on the path during page load, so things like the metadata have the correct language set.

I don't fully see why JavaScript is needed. This should all be done at build time, no?

Using String Catalogs rather than a custom format has great advantages:

String catalogs would be a great choice, as long as they are fully supported outside of macOS; people have already started building Ignite sites on Linux.

As not everyone will need or want to localize their sites, we should keep this as opt-in and default to exactly the same behavior without any subpaths like /en. Also, a default language should be set and used as a fallback for when a domain is called without any language subpath. I'm not sure if a safe redirect is even possible on static site calls, so the default locale files should just live in the root directory.

Everything should be flattened at build time, so the whole thing remains static. That would mean using the base language by default (perhaps by changing languages to an array, then using whichever one is listed first?), then push the rest to /es/original/path, /fr/original/path, etc. This should mean no redirect is needed, and there would be no opting in or out. That might be overly simplistic, though, so I'd be keen to hear more on why you want to introduce javaScript here.
In my head, the greatest challenge would be around making sure all a site's content is localized to the supported languages, or if we even want to push for that. For example, if I say my site is English first then French second, what happens if one of my Markdown posts is missing in French? Perhaps this is just a configuration option, but it could get rather messy with things like tag pages.

String catalogs would be a great choice, as long as they are fully supported outside of macOS; people have already started building Ignite sites on Linux.

When you say "started building on Linux" you mean they do the entire editing part there? So no Xcode available? If that's what you mean, then I understand that it might not be optimal to use String Catalogs as a format due to lack of an editor. But I'm also not sure if any other localization file format has an editor there, and String Catalogs are quite readable JSON at the core, so it might still be a viable option. If hosting on Linux is your only concern, that shouldn't be a problem as we would parse the localized texts out from the String Catalog during build all with Swift code, so I don't see any problem there.

Everything should be flattened at build time, so the whole thing remains static. That would mean using the base language by default (perhaps by changing languages to an array, then using whichever one is listed first?), then push the rest to /es/original/path, /fr/original/path, etc. This should mean no redirect is needed, and there would be no opting in or out. That might be overly simplistic, though, so I'd be keen to hear more on why you want to introduce javaScript here.

I agree in general with flattening everything at build time. But the reason I would still add some Javascript is for automatic browser language preference detection. So when a user who prefers French visits the site it automatically shows the French site, not the English one. This could not be achieved without some JavaScript AFAIK, but it would be just a couple lines of code, and we could make it opt-in and not render it at all if only one language is supported. It should also only be there for the default path without a locale inside, so when users call /fr/original/path then it stays in French, no JavaScript included.
This could be important for many use cases where people share links to their app landing page, for example. While they could share different language links with different audiences, at least for the home page of a domain you don't usually do that, you just call the domain and expect it to be in the language you need, like how it works on App Store Connect.
Of course, we could start without this feature. But as an opt-in one I don't see a problem and I would be up to implement it, as I need it for my app landing pages that I'm planning to build with Ignite.

In my head, the greatest challenge would be around making sure all a site's content is localized to the supported languages, or if we even want to push for that. For example, if I say my site is English first then French second, what happens if one of my Markdown posts is missing in French? Perhaps this is just a configuration option, but it could get rather messy with things like tag pages.

Note sure what you mean with tag pages, but if we use String Catalogs and localization markers like String(localized:) and LocalizedStringKey, the String Catalog would exactly show which languages have missing text translations. If someone was looking for a 100% localized site, this would be very helpful and reduce the chance for overlooked translations. For users who rather need a single page localized and nothing else, I would argue they could just create a file at /fr/original/path and manually link to it without using the official localization feature. I don't see an easy way to support part-localization without creating all kinds of problems.

They build on Linux.
No automatic language selection; that would be unwelcome.
Tag pages are used in Ignite to show all content that matches a certain tag. String catalogs would not apply here.

Without automatic language selection, I can't use Ignite for any of my planned use cases as my apps are multi-language and my app landing pages should be as well. If that's a direction you don't want to go (which I totally respect, of course), I might have to create a fork and maintain that with the dynamic features I need, if that's okay with you.
For the tag pages, aren't they generated like any other page? Why couldn't they be localized as well with links to all localized pages that have a certain tag? Even the tags themselves could be localized, internally they would keep the default locale name but when shown to viewers they could be localized like any other content. I don't see how String Catalogs are a problem there.

It's an open-source project; you can fork it whenever you want.
Automatic language selection will not happen. If you want to direct folks to a particular part of your site, that should be done in your app, in your App Store Connect settings, or similar – you know what language they actually want there, because it's the setting on their phone or overridden on a per-app basis in Settings, and correctly takes into account the user's actual preference rather than trying to auto-detect. If you want users of your app who have expressly said "Ignore my phone's setting, use English for this app" to visit your site and suddenly be given French because that's what Safari is set to, that's down to you.
This is, as far as I know, fairly standard behavior for the web: if I enable French as the primary language on my iPhone then visit apple.com, I get the US English site. If I use US English on my iPad and visit apple.com/jp, I get the Japanese site. The same is true for microsoft.com, intel.com, amd.com, and many more. This appears to be common, so it's hardly unprecedented for Ignite to follow suit.
Ultimately, if all you want to do is inject some custom JavaScript, that's something you can do within the current Ignite system: add your own language detection code, then redirect as needed.
For the tag pages: As I said, my concern is when there's a mismatch between pages that are localized and those that aren't; we'd need to be careful to show only the pages that match the tag in that language, and also need to be careful for places where tags exist in one language but not another. Showing some kind of language selection box would need to take into account that any given page might not actually have a translation available, or might spelled "Artikel" rather than "Articles". We'd likely need to give users some control here (allow mismatched translations? Force matching translations? Some way to link English tag to German equivalent here?), but it's definitely a non-trivial problem that deserves careful thought.

Alright, I do get your point with websites not always doing the redirection. But Apple, for example, does detect that I'm coming from Germany if I visit apple.com and prominently gives me a button at the top of the page that brings me to apple.de. And many other sites (like App Store Connect) automatically localize. So at least I think there should be an option.
The use case for me would not be restricted to digital products (where I can link to different languages), but to physical printings with a link to the apps website, such as on these cards.
But you said I could "add (my) own language detection code, then redirect as needed". That certainly sounds great. But it's one of the things I didn't understand was possible by the current docs. How is it done? Do I add an Include to every single page for that that I want to localize?
For the tag pages: You are right, giving users some control is not a trivial problem. But for a first version, would you be fine if we only properly supported the "everything is localized" approach? Like I said, the progress percentage indicator in String Catalogs helps detect which languages are missing. For simple websites like app landing pages which only have few languages anyway, this could be a totally viable solution. Or do you want a full-fledged solution from the get to?

I also just typed microsoft.com which redirected me to https://www.microsoft.com/de-de/ and amd.com redirected me to https://www.amd.com/de.html – only intel.com resulted in an English page. As you can see, it's also very common to redirect, so at least I think there should be an option.

Yes, but are they doing that through IP address or JavaScript locale? Lots of sites use GeoIP or similar, which is why if I visit Microsoft from the UK I get the UK site, but if I enable a VPN in Germany I get the German site – despite using the same computer. The same is true for amd.com, and many others: the source IP address is being read, not the computer's settings.

Do I add an Include to every single page that I want to localize?

If you want to include custom JavaScript on every page, the best thing to do is put it directly into a custom theme. This would probably be best expressed as a Script element.

But for a first version, would you be fine if we only properly supported the "everything is localized" approach?

For now, I think switching languages to an array then assuming everything is localized is a good step forward – I don't think it would break anything, because we have no localization at all right now and I suspect almost everyone left the setting as the default.
So, if someone changes languages to be [.en, .de] for example, we would look for the first of those in the existing directory structures, and the second by prefixing "de" to all the URLs. So, for English it would be Content/article/swift-against-humanity.md, but for German it would be Content/de/article/swift-against-humanity.md
How does that sound?

Like I said, the progress percentage indicator in String Catalogs helps detect which languages are missing.

Again, we need to be very careful here to ensure we don't affect building on Linux and other platforms, so whatever we use to handle localization should be able to work on every platform. Apple renewed their cross-platform push in this year's WWDC SOTU, and when dealing with websites Linux is significantly more commonplace; if we don't strive for cross-platform compatibility I think it will come back to bite us.

So, if someone changes languages to be [.en, .de] for example, we would look for the first of those in the existing directory structures, and the second by prefixing "de" to all the URLs. So, for English it would be Content/article/swift-against-humanity.md, but for German it would be Content/de/article/swift-against-humanity.md
How does that sound?

Sounds good to me. 👍 I'll give it a spin later this summer when I work on my app websites.

Again, we need to be very careful here to ensure we don't affect building on Linux and other platforms, so whatever we use to handle localization should be able to work on every platform. Apple renewed their cross-platform push in this year's WWDC SOTU, and when dealing with websites Linux is significantly more commonplace; if we don't strive for cross-platform compatibility I think it will come back to bite us.

If there only was a SwiftUI-like UI framework for Linux, I would actually build a String Catalog Editor for Linux platforms. I mean, I already have it all in my app and it's also a 100% free feature, so there's no reason I couldn't create an open-source editor for Linux. If you're thinking about this long term, then I believe a native Linux app written in Swift is the best option. I'm happy to provide a first version once we have a Swift-based UI framework for Linux (much like Ignite is a Swift-based UI framework for the web).
Having that said, "dealing with websites Linux is significantly more commonplace" reminds me of where those sites usually are hosted or built on, so I'd like to reiterate that String Catalogs are fully compatible with Linux, it's all just JSON after all, and it's quite human-readable JSON, too. And JSON is editable on Linux without problems. So if I provided a Swift plugin that detected things like String(localized:) or LocalizedStringKey and auto-extracted them into a String Catalog file, it would even work if people want to develop on Linux. I'd be willing to do this work long-term if there is enough interest. I've done something similar with BartyCrouch after all.

It seems there are several core tasks here:

Support decoding of strings catalog JSON.
Update all instances of text (including images?) to support internationalization, similar to SwiftUI.
Switch language over to languages, defaulting to [.en]
Add a Text(verbatim:) initializer that skips internationalization.

Once that's done, we could move on to step 5: update content processing to support localized versions. I've separated that off because it's possible to create Ignite sites entirely without Markdown – just a bunch of static pages, which would require only the first four steps above.

@twostraws Did you outline those steps for clarity or because you prefer a separate PR for each? I prefer feature-complete PRs that I keep small by limiting the scope. But all 4 steps mentioned would be one PR, I think.
I'll think about the best way to change language to languages so nothing breaks for existing users. And as a side note, while Text(verbatim:) is available to specify in SwiftUI that a Text view should not be localized, most other views don't have a verbatim initializer overload. One could of course use the label overloads and provide Text inside, but I found that simply passing an explicit String("My unlocalized text") is much simpler to write and easy enough to understand. Because of the type specification the unlocalized String APIs are used then and the text doesn't get localized. One could even introduce a typealias named something like Unlocalized for String to make it even more explicit, but just wanted to let you know that this is a trick I'm using all the time and teaching others, so the Ignite views should support that as well.
Currently I'm still focusing on some Post-WWDC work, so I won't be able to immediately start on the localization work here. But I'll probably start sometime in July. I'll let you know of any progress. I'd probably create a WIP PR early, so you can correct me if I go the wrong direction.

One huge PR would be unwelcome. I'll start on this myself.


Module type projects can't be built when there are plugins

flutter create normal_project
[add some plugin to pubspec]
flutter run --local-engine

works
flutter create -t module module_project
[add some plugin to pubspec]
flutter run --local-engine

however causes
* What went wrong:
Could not determine the dependencies of task ':app:lintVitalRelease'.
> Could not resolve all artifacts for configuration ':app:profileCompileClasspath'.
   > Could not resolve project :url_launcher.
     Required by:
         project :app > project :flutter
      > No matching variant of project :url_launcher was found. The consumer was configured to find an API of a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'profile' but:
          - Variant 'debugApiElements' capability io.flutter.plugins.urllauncher:url_launcher:1.0-SNAPSHOT declares an API of a component:
              - Incompatible because this component declares a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'debug' and the consumer needed a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'profile'
          - Variant 'debugRuntimeElements' capability io.flutter.plugins.urllauncher:url_launcher:1.0-SNAPSHOT declares a runtime of a component:
              - Incompatible because this component declares a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'debug' and the consumer needed a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'profile'
          - Variant 'releaseApiElements' capability io.flutter.plugins.urllauncher:url_launcher:1.0-SNAPSHOT declares an API of a component:
              - Incompatible because this component declares a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'release' and the consumer needed a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'profile'
          - Variant 'releaseRuntimeElements' capability io.flutter.plugins.urllauncher:url_launcher:1.0-SNAPSHOT declares a runtime of a component:
              - Incompatible because this component declares a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'release' and the consumer needed a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'profile'
   > Could not resolve project :sensors.
     Required by:
         project :app > project :flutter
      > No matching variant of project :sensors was found. The consumer was configured to find an API of a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'profile' but:
          - Variant 'debugApiElements' capability io.flutter.plugins.sensors:sensors:1.0-SNAPSHOT declares an API of a component:
              - Incompatible because this component declares a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'debug' and the consumer needed a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'profile'
          - Variant 'debugRuntimeElements' capability io.flutter.plugins.sensors:sensors:1.0-SNAPSHOT declares a runtime of a component:
              - Incompatible because this component declares a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'debug' and the consumer needed a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'profile'
          - Variant 'releaseApiElements' capability io.flutter.plugins.sensors:sensors:1.0-SNAPSHOT declares an API of a component:
              - Incompatible because this component declares a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'release' and the consumer needed a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'profile'
          - Variant 'releaseRuntimeElements' capability io.flutter.plugins.sensors:sensors:1.0-SNAPSHOT declares a runtime of a component:
              - Incompatible because this component declares a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'release' and the consumer needed a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'profile'

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

@xster I wasn't able to reproduce this issue locally.
log.txt
I don't know where the difference is, but I followed this:
flutter create -t module module_project
cd module_project
// add url_launcher to pubspec.yaml
flutter run  --local-engine-src-path <engine>/src --local-engine=android_debug_unopt_x64

@xster I wasn't able to reproduce this issue locally.
log.txt
I don't know where the difference is, but I followed this:
flutter create -t module module_project
cd module_project
// add url_launcher to pubspec.yaml
flutter run  --local-engine-src-path <engine>/src --local-engine=android_debug_unopt_x64


date issue

Hi. Project looks amazing so far. And I've got one of the examples running quite easily.
However I'm having troubles using a real api feed. Dates just won't work.
See, I'm receiving this timestamp from the API:<PHONE_NUMBER>000
And I'm transforming that to this: 2018-01-22T20:50:00.000Z (string)
As far as I can say, that's the format expected by d3, but the graphics renders just empty and console says:

Unexpected value NaN parsing x attribute.
Unexpected value NaN parsing width attribute.

If I use ISO format but with an object instead of a string, the graphic renders something but it's really a mess.
So, any clue about how to convert timestamp to a correct format with d3? I'm trying this:
import { timeParse, timeFormat } from "d3-time-format";

const parseDate = timeParse("%s");
const formatDate = timeFormat("%s");

 console.log( parseDate(formatDate(t)) )

And this:
 console.log( new Date(t).toISOString() )

This is how I see the candles.

Same result if I just use the timestamp.

@libasoles- I have same problem few days back. You can add below code to make it working.
new Date(timestamp), timestamp should be  in milliseconds.
Can you share your code, how you are integrating with API, I have some problem during API integration with websockets

Cool @abhiindia , that made the trick. Actually, I realized that with '1d' time period my code worked quite well. Not with shorter periods, like '1h'. But your code seems to works even with '5m' periods so it's great. It was easy!
Look, I'm using redux-saga. Not sure if that will be useful for you, guess not. Also, queries are performed by a third party lib. And I'm not planning to implement websockets by now. But maybe you could start a ticket.


Cannot change artifacts of configuration ':@mauron85_react-native-background-geolocation:default' after it has been included in dependency resolution.

Error after add react-native-onesignal and run ./gradlew clean or react-native run-android please help for fix this error thanks
`FAILURE: Build failed with an exception.

What went wrong:
A problem occurred configuring project ':@mauron85_react-native-background-geolocation'.

Cannot change artifacts of configuration ':@mauron85_react-native-background-geolocation:default' after it has been included in dependency resolution.`

"@mauron85/react-native-background-geolocation": "0.6.3",
"react": "16.9.0",
"react-native": "0.61.4",
"react-native-onesignal": "3.5.0",

Same here, seems like when we use onesignal, this happens.

Same here, please someone help to fix this.

I don't know if there will be any issues but 0.5.6 version works with react-native 0.61.4, and i am using it without problem.
Keep in mind that 0.5.6 is an old version made for react-native >= 0.57

I don't know if there will be any issues but 0.5.6 version works with react-native 0.61.4, and i am using it without problem.
Keep in mind that 0.5.6 is an old version made for react-native >= 0.57

not work after add react-native-onesignal

Strange. 0.6.3 wasnt working for me either but after downgrading to 0.5.6, it works fine.
I can't help you how i made it work (because i don't know), i'm new at android.
"react-native": "0.61.4",
"@mauron85/react-native-background-geolocation": "0.5.6",
"react-native-onesignal": "^3.5.0",

Strange. 0.6.3 wasnt working for me either but after downgrading to 0.5.6, it works fine.
I can't help you how i made it work (because i don't know), i'm new at android.
"react-native": "0.61.4",
"@mauron85/react-native-background-geolocation": "0.5.6",
"react-native-onesignal": "^3.5.0",

thanks this is work for me

This isn't a permanent solution

This isn't a permanent solution

temporary solution, until waiting @mauron85  update

Strange. 0.6.3 wasnt working for me either but after downgrading to 0.5.6, it works fine.
I can't help you how i made it work (because i don't know), i'm new at android.
"react-native": "0.61.4",
"@mauron85/react-native-background-geolocation": "0.5.6",
"react-native-onesignal": "^3.5.0",

this solution not work on IOS

Yep, just tested. Doesn't work on ios. Crash log: CRASH: Invalid parameter not satisfying: !stayUp

Strange. 0.6.3 wasnt working for me either but after downgrading to 0.5.6, it works fine.
I can't help you how i made it work (because i don't know), i'm new at android.
"react-native": "0.61.4",
"@mauron85/react-native-background-geolocation": "0.5.6",
"react-native-onesignal": "^3.5.0",

this solution not work on IOS

Solve the problem change your package.json version (ios 0.6.3 mauron), for android go to (android 0.5.6 mauron). Every time you change package.json don't forget to clean your node modules "rm -rf node_modules && yarn install". cheers

@mauron85 can you please take a look at this issue?
There must be some conflicting issues with onesignal

Fixed & Tested!!
remove following line from your app/build.gradle
-> apply plugin: 'com.onesignal.androidsdk.onesignal-gradle-plugin'
This is required only if you run into any issues with duplicate classes.
i found it in onesignal build.gradle file

After two hours, this works.
I was using react-native-firebase for storage, react-native-onesignal for push notifications and this library for geolocation features.
At first, I commented this line from my app/build.gradle
// apply plugin: 'com.onesignal.androidsdk.onesignal-gradle-plugin'
Add following lines at the bottom
apply plugin: 'com.google.gms.google-services'
com.google.gms.googleservices.GoogleServicesPlugin.config.disableVersionCheck = true

Dependencies section from that same file are:
dependencies {
    implementation fileTree(dir: "libs", include: ["*.jar"])
    implementation "com.facebook.react:react-native:+"  // From node_modules
    implementation "com.android.support:multidex:1.0.0"

    implementation project(':react-native-firebase')
    implementation project(':react-native-navigation')
    implementation project(':@mauron85_react-native-background-geolocation')
    implementation project(':react-native-onesignal')
    implementation project(':react-native-splash-screen')

    implementation "com.google.android.gms:play-services-base:16.1.0"
    implementation "com.google.android.gms:play-services-location:15.0.1"

    implementation "com.google.firebase:firebase-core:16.0.9"
    implementation "com.google.firebase:firebase-messaging:18.0.0"
    implementation "com.google.firebase:firebase-analytics:17.0.0"
    implementation "com.google.firebase:firebase-storage:17.0.0"

    if (enableHermes) {
        def hermesPath = "../../node_modules/hermes-engine/android/";
        debugImplementation files(hermesPath + "hermes-debug.aar")
        releaseImplementation files(hermesPath + "hermes-release.aar")
    } else {
        implementation jscFlavor
    }
}

My build.gradle file (at the root, not from app/ folder):
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
    ext {
        buildToolsVersion = "28.0.3"
        minSdkVersion = 18
        compileSdkVersion = 28
        targetSdkVersion = 28

        supportLibVersion = "28.0.0"
        googlePlayServicesVersion = "11+"
    }
    repositories {
        google()
        jcenter()
    }
    dependencies {
        classpath("com.android.tools.build:gradle:3.4.2")
        classpath 'com.google.gms:google-services:4.1.0'

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        google()
        mavenLocal()
        mavenCentral()
        jcenter()
        maven {
            // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
            url("$rootDir/../node_modules/react-native/android")
        }
        maven {
            // Android JSC is installed from npm
            url("$rootDir/../node_modules/jsc-android/dist")
        }
        maven { url 'https://jitpack.io' }
    }
}

subprojects { subproject ->
    afterEvaluate {
        if ((subproject.plugins.hasPlugin('android') || subproject.plugins.hasPlugin('android-library'))) {
            android {
                compileSdkVersion rootProject.ext.compileSdkVersion
                buildToolsVersion rootProject.ext.buildToolsVersion

                variantFilter { variant ->
                    def names = variant.flavors*.name
                    if (
                            names.contains("reactNative51") ||
                            names.contains("reactNative55") ||
                            names.contains("reactNative56") ||
                            names.contains("reactNative57") ||
                            names.contains("reactNative57_5")
                    ) {
                        setIgnore(true)
                    }
                }
            }
        }
    }
}

Finally, my versions from the package json:
"@mauron85/react-native-background-geolocation": "^0.6.3",
"react-native-onesignal": "^3.6.1",
"react-native-firebase": "^5.6.0"

Hope to help someone. Cheers!

After two hours, this works.
I was using react-native-firebase for storage, react-native-onesignal for push notifications and this library for geolocation features.
At first, I commented this line from my app/build.gradle
// apply plugin: 'com.onesignal.androidsdk.onesignal-gradle-plugin'
Add following lines at the bottom
apply plugin: 'com.google.gms.google-services'
com.google.gms.googleservices.GoogleServicesPlugin.config.disableVersionCheck = true

Dependencies section from that same file are:
dependencies {
    implementation fileTree(dir: "libs", include: ["*.jar"])
    implementation "com.facebook.react:react-native:+"  // From node_modules
    implementation "com.android.support:multidex:1.0.0"

    implementation project(':react-native-firebase')
    implementation project(':react-native-navigation')
    implementation project(':@mauron85_react-native-background-geolocation')
    implementation project(':react-native-onesignal')
    implementation project(':react-native-splash-screen')

    implementation "com.google.android.gms:play-services-base:16.1.0"
    implementation "com.google.android.gms:play-services-location:15.0.1"

    implementation "com.google.firebase:firebase-core:16.0.9"
    implementation "com.google.firebase:firebase-messaging:18.0.0"
    implementation "com.google.firebase:firebase-analytics:17.0.0"
    implementation "com.google.firebase:firebase-storage:17.0.0"

    if (enableHermes) {
        def hermesPath = "../../node_modules/hermes-engine/android/";
        debugImplementation files(hermesPath + "hermes-debug.aar")
        releaseImplementation files(hermesPath + "hermes-release.aar")
    } else {
        implementation jscFlavor
    }
}

My build.gradle file (at the root, not from app/ folder):
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
    ext {
        buildToolsVersion = "28.0.3"
        minSdkVersion = 18
        compileSdkVersion = 28
        targetSdkVersion = 28

        supportLibVersion = "28.0.0"
        googlePlayServicesVersion = "11+"
    }
    repositories {
        google()
        jcenter()
    }
    dependencies {
        classpath("com.android.tools.build:gradle:3.4.2")
        classpath 'com.google.gms:google-services:4.1.0'

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        google()
        mavenLocal()
        mavenCentral()
        jcenter()
        maven {
            // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
            url("$rootDir/../node_modules/react-native/android")
        }
        maven {
            // Android JSC is installed from npm
            url("$rootDir/../node_modules/jsc-android/dist")
        }
        maven { url 'https://jitpack.io' }
    }
}

subprojects { subproject ->
    afterEvaluate {
        if ((subproject.plugins.hasPlugin('android') || subproject.plugins.hasPlugin('android-library'))) {
            android {
                compileSdkVersion rootProject.ext.compileSdkVersion
                buildToolsVersion rootProject.ext.buildToolsVersion

                variantFilter { variant ->
                    def names = variant.flavors*.name
                    if (
                            names.contains("reactNative51") ||
                            names.contains("reactNative55") ||
                            names.contains("reactNative56") ||
                            names.contains("reactNative57") ||
                            names.contains("reactNative57_5")
                    ) {
                        setIgnore(true)
                    }
                }
            }
        }
    }
}

Finally, my versions from the package json:
"@mauron85/react-native-background-geolocation": "^0.6.3",
"react-native-onesignal": "^3.6.1",
"react-native-firebase": "^5.6.0"

Hope to help someone. Cheers!

Thanks, this works perfectly

// apply plugin: 'com.onesignal.androidsdk.onesignal-gradle-plugin'

Only comments this line solve my problem, closing this issue

// apply plugin: 'com.onesignal.androidsdk.onesignal-gradle-plugin'

Only comments this line solve my problem, please, close this issue

stilll not working

If your project run for company, I suggest you to buy this lib https://github.com/transistorsoft/react-native-background-geolocation. Because this library won't help you. Sorry for that

After two hours, this works.
I was using react-native-firebase for storage, react-native-onesignal for push notifications and this library for geolocation features.
At first, I commented this line from my app/build.gradle
// apply plugin: 'com.onesignal.androidsdk.onesignal-gradle-plugin'
Add following lines at the bottom
apply plugin: 'com.google.gms.google-services'
com.google.gms.googleservices.GoogleServicesPlugin.config.disableVersionCheck = true

Dependencies section from that same file are:
dependencies {
    implementation fileTree(dir: "libs", include: ["*.jar"])
    implementation "com.facebook.react:react-native:+"  // From node_modules
    implementation "com.android.support:multidex:1.0.0"

    implementation project(':react-native-firebase')
    implementation project(':react-native-navigation')
    implementation project(':@mauron85_react-native-background-geolocation')
    implementation project(':react-native-onesignal')
    implementation project(':react-native-splash-screen')

    implementation "com.google.android.gms:play-services-base:16.1.0"
    implementation "com.google.android.gms:play-services-location:15.0.1"

    implementation "com.google.firebase:firebase-core:16.0.9"
    implementation "com.google.firebase:firebase-messaging:18.0.0"
    implementation "com.google.firebase:firebase-analytics:17.0.0"
    implementation "com.google.firebase:firebase-storage:17.0.0"

    if (enableHermes) {
        def hermesPath = "../../node_modules/hermes-engine/android/";
        debugImplementation files(hermesPath + "hermes-debug.aar")
        releaseImplementation files(hermesPath + "hermes-release.aar")
    } else {
        implementation jscFlavor
    }
}

My build.gradle file (at the root, not from app/ folder):
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
    ext {
        buildToolsVersion = "28.0.3"
        minSdkVersion = 18
        compileSdkVersion = 28
        targetSdkVersion = 28

        supportLibVersion = "28.0.0"
        googlePlayServicesVersion = "11+"
    }
    repositories {
        google()
        jcenter()
    }
    dependencies {
        classpath("com.android.tools.build:gradle:3.4.2")
        classpath 'com.google.gms:google-services:4.1.0'

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        google()
        mavenLocal()
        mavenCentral()
        jcenter()
        maven {
            // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
            url("$rootDir/../node_modules/react-native/android")
        }
        maven {
            // Android JSC is installed from npm
            url("$rootDir/../node_modules/jsc-android/dist")
        }
        maven { url 'https://jitpack.io' }
    }
}

subprojects { subproject ->
    afterEvaluate {
        if ((subproject.plugins.hasPlugin('android') || subproject.plugins.hasPlugin('android-library'))) {
            android {
                compileSdkVersion rootProject.ext.compileSdkVersion
                buildToolsVersion rootProject.ext.buildToolsVersion

                variantFilter { variant ->
                    def names = variant.flavors*.name
                    if (
                            names.contains("reactNative51") ||
                            names.contains("reactNative55") ||
                            names.contains("reactNative56") ||
                            names.contains("reactNative57") ||
                            names.contains("reactNative57_5")
                    ) {
                        setIgnore(true)
                    }
                }
            }
        }
    }
}

Finally, my versions from the package json:
"@mauron85/react-native-background-geolocation": "^0.6.3",
"react-native-onesignal": "^3.6.1",
"react-native-firebase": "^5.6.0"

Hope to help someone. Cheers!

P E R F E C T !
Thanks !!!!


Adds Axios v1 support

In Axios v1 release, header types changed to defined types
Previous were Record
Type changes from Record https://github.com/axios/axios/pull/4334/files
Addition of defined types including RawAxiosHeaders https://github.com/axios/axios/pull/4787/files
Axios v1 Release notes https://github.com/axios/axios/pull/4787/files
This pr adds additional cli flag v to specify version to support and conditionally updates service files to new header types

for future reference, there was also a [CONTRIBUTORS.md] that you may add your email too


Add git-guilt post-commit hook

git-guilt reports the change in blame since the last commit.
Blocked by #92.
This branch is based on jawshooah:feature/post-commit, so the diff includes changes from #92.

@sds Resolved merge conflicts, this should be good for review now.

Merged in 7a7f670 with adjustments in 72a0107. Thanks!


rustpython: 2022-10-11 -> 0.2.0

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[x] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Build fails on aarch64-linux: https://github.com/NixOS/nixpkgs/pull/219938/checks?check_run_id=11814383365


evaluation code

Hi, did you use the code contained in this repo ?
If not, would you mind providing one? especially for (Super)GLUE and MSGS (MCC)

Yes, we used the evaluation pipeline provided by the organisers of the BabyLM challenge (like most submissions probably did).
The code can be a bit fragile, but if you follow the installation instructions, it should in principle work. Also note that depending on the specific versions of dependencies (in particular transformers), you may obtain slightly different numerical results.

Thanks for your response! by the way, did you use the finetune code in that repo on GLUE and MSGS dataset when writing the paper?

Yes, this is what we used.

Thanks, that helps a lot! I will implement this code!

Hi, can I know why you use F1 score for MRPC and QQP and use MCC for others in (Super)GLUE dataset?

Hi. I just double-checked, and for this dataset the only reason is that this is what was specified by the challenge organisers in order to have consistent scores between the various submissions. I am not sure why they made this choice, but if I remember correctly, the evaluation code should compute all the metrics under the hood.
Note that unless specified otherwise, what is reported in fig. 3 is the accuracy, with the only exceptions being QQP and MRPC for which the $F_1$ score is reported, and CoLA for which the MCC is reported.


Topic-Draft prefill initiator with currentUser

Closed because I selected wrong branch (Master instead of dev).


Event Grid not sending Events for the blobs created by spark

step1 :
Written data to data lake gen2 with pyspark
parquet format :
<EMAIL_ADDRESS>csv format:
<EMAIL_ADDRESS>Step2:
I see that blobs were created successfully

But event are not being sent to the event hub topic when these blobs are created.
The event is getting triggered when we manually uploaded a file or renamed existing file in the storage.

Event which got triggered for this

Summary: Events are not getting generated when an external application like spark writes into Blob. They are only triggering when file is uploaded/renamed/ deleted manually.

This problem happened because the storage account was a Data Lake Gen1. I mistakenly created Gen 1 instead of Gen2.
Upgrading the account to Gen2 resolved the issue.


doc: The Go Memory Model : a channel example has a bug

Hi. Following the go_mem documentation I found  a bug in a channel example.
var limit = make(chan int, 3)

func main() {
	for _, w := range work {
		go func() {
			limit <- 1
			w() // not guaranteed to run their own function.
			<-limit
		}()
	}
	select{}
}

I know this is just a realistic pseudo-code, but it would be better to fix this for the beginners like me :-)
So I suggest:
var limit = make(chan int, 3)

func main() {
	for _, w := range work {
		go func(worker func()) {
			limit <- 1
			worker()
			<-limit
		}(w)
	}
	select{}
}

It has been a long time since the issue opened, I will go ahead
and send a CL. https://golang.org/cl/7602.


[Feature request]: Include some kind of summary view for time tracking

Hello,
and thanks for nice time tracking feature.
However, it would be nice if I could see some kind of summary of total time spent on issues currently shown or something like that.
Br, Miika

Hello,
I hope I am allowed to add my 2 cents here
It would be nice to have a setting so that I can limit the maximum unit the summary gets merged to..
currently you see summarized time tracking on a milestone in the biggest unit (if you have 3 hours tracked you see 3 hours, if you have 25 hours tracked you see 1day 1 hour ect)
For billing reasons and better comparison between projects it would be nice for me to limit this to hours so its on the same page everywhere
have a nice day ;)


Library dependencies not respecting platforms

Configuration
Operating system: Ubuntu Linux 64
PlatformIO Version: PlatformIO, version 3.1.0
Description of problem
I have a library that has dependencies on other libraries and some are specific per platform.
Previously I was managing the dependencies through a dependencies.h file in my library. The problem is that the user has to be editing the library files for each sketch, that's not cool.
I'm upgrading to platformio, and I am struggling to solve this problem, it seems to be a bug.
LIB: https://github.com/OpenDevice/opendevice-lib-arduino/tree/0.1.4
  "dependencies": [
    {"name": "PubSubClient", "version": ">=2.6"},
    {"name": "EnableInterrupt", "version":  ">=0.9.5", "platforms" : "atmelavr"},
    {"name": "MFRC522", "version":  ">=1.1.8"},
    {"name": "Bridge", "version":  ">=1.6.1", "platforms" : "atmelavr"},
    {"name": "Ethernet", "version":  ">=1.1.2", "platforms" : "atmelavr"},
    {"name": "EEPROM", "version":  ">=2.0"},
    {"name": "SPI", "version":  ">=1.0"},
    {"name": "WiFi", "version":  ">=1.2.7", "platforms" : "atmelavr"},
    {"name": "ESP8266WiFi", "version":  ">=1.2.7", "platforms" : "espressif8266"}
  ],

Steps to Reproduce
Starting an example, I have two platforms set in my Skech: atmelavr / uno, espressif8266.
When I compile for UNO, throws an error that can not find the lib ESP8266WiFi that this being should only be "active" when compiling for the esp8266
Actual Results (ERROR)

pio run -e uno -vv

[Wed Oct 26 02:23:12 2016] Processing uno (platform: atmelavr, lib_deps: PubSubClient, lib_compat_mode: 2, board: uno, framework: arduino)
----------------------------------------------------------------------------------------------------------
Library Storage: /media/ricardo/Dados/TEMP/platformio-test/unotest/.piolibdeps
LibraryManager: Installing id=89
PubSubClient @ 2.6 is already installed
Collected 30 compatible libraries
Looking for dependencies...
Error: Could not find `ESP8266WiFi` dependency for `OpenDevice` library
======================================= [ERROR] Took 0.77 seconds =======================================

=============================================== [SUMMARY] ===============================================
Environment esp12e      [SKIP]
Environment uno [ERROR]
======================================= [ERROR] Took 0.77 seconds =======================================

Expected Results
Compile "OpenDevice" using libraries with match the platform of active enviroment
If problems with PlatformIO Build System:
The content of platformio.ini:
[platformio]
env_default = uno

[common]
lib_deps = PubSubClient

[env:uno]
platform = atmelavr
board = uno
framework = arduino
lib_compat_mode = 2
lib_deps = ${common.lib_deps}
; enable auto-uploading
;targets = upload

[env:esp12e]
platform = espressif8266
board = esp12e
framework = arduino
lib_compat_mode = 2
lib_deps = ${common.lib_deps}

Source file to reproduce issue:
// I only use a blink and include:
#include <OpenDevice.h>

Additional info
On lib,  i'm using: "build" : { "libLDFMode" : 0 }
On sketch: lib_compat_mode = 2

Thanks a lot for the great report! This is a bug and I've just fixed it. Please re-test with the http://docs.platformio.org/en/stable/installation.html#development-version

I found a problem with "EnableInterrupt" library

http://platformio.org/lib/show/311/EnableInterrupt/manifest

This library doesn't has platforms field and PIO Build System can not check for platform compatibility. There are 2 options:

Male PR to https://github.com/GreyGnome/EnableInterrupt and specify platforms field.
Replace {"name": "EnableInterrupt", "version":  ">=0.9.5", "platforms" : "atmelavr"}, with {"name": "EnableInterrupt", "version":  ">=0.9.5"},

WoW... Thanks for the quick fix...
It's working now finally .... was for more than four hours trying to solve ...
One question: Why dependencies are not automatically downloaded?
And a small problem: I think the verification platform is very narrow and some libraries are using the old name: "espressif

.piolibdeps/MFRC522_ID63/library.json

{
  "name": "MFRC522",
  "frameworks": "arduino",
  "platforms": ["atmelavr", "ststm32", "teensy", "espressif"]
}

Running

pio run -e esp12e -v

I got:

Processing esp12e (platform: espressif8266, lib_deps: PubSubClient, lib_compat_mode: 2, board: esp12e, framework: arduino)
Library Storage: /media/ricardo/Dados/TEMP/platformio-test/unotest/.piolibdeps
LibraryManager: Installing id=89
PubSubClient @ 2.6 is already installed
Platform incompatible library /media/ricardo/Dados/TEMP/platformio-test/unotest/.piolibdeps/MFRC522_ID63
Platform incompatible library /media/ricardo/Dados/Programacao/platformio/packages/framework-arduinoespressif8266/libraries/SoftwareSerial
Collected 24 compatible libraries
More details about "Library Compatibility Mode": http://docs.platformio.org/en/stable/librarymanager/ldf.html#ldf-compat-mode
Looking for dependencies...
Error: Could not find MFRC522 dependency for OpenDevice library

I did a pull request for these libraries, but I think it will happen to other ...

Why dependencies are not automatically downloaded?

It should work. If library is already installed, then PIO will not re-check "dependencies". Try to isntall
pio lib -g install https://github.com/OpenDevice/opendevice-lib-arduino/archive/0.1.4.zip

I think the verification platform is very narrow and some libraries are using the old name: "espressif

I'll think on it. Maybe, will add some hook for that.

It should work. If library is already installed, then PIO will not re-check "dependencies". Try to isntall
I think it's because I'm using the lib directly without installing

Thanks


Support custom color and size

Color and size across the board or does this apply to specific components?
Also, size in regards to what exactly? Icon size, font size? These have different implications and meanings depending on what methods are being used to set them.

This issue concerns color and size in different places. Currently, some places allow passing a custom color instead of primary and such. It's not supported everywhere so needs to be updated across the entire project to make sure it works the same in all places where you can pass a color or size.


chore: merge main to develop

Just a merge from main to develop. Please ignore the size.
Additional Commits:

added one liner to fix failing tests
disabled docker-hub-release.yaml

There is still one test failing. Could you take a look again @DominikPinsel ?

There is still one test failing. Could you take a look again @DominikPinsel ?

Will do :) The never ran successfully, but I will repair it anyway.

@carslen Disabled the workflow, it never ran. It can be merged now :)

Ping @carslen


node_security_group_id vs vpc_security_group_ids for EKS Managed Node Groups?

Description
We are upgrading our cluster from 17.24.0 to 18.31.2 and there are a couple of changes to say the least. I'm pretty much following the upgrade guide where renames are concerned, but I have noticed that it says in the upgrade guide that what was once worker_additional_security_group_ids is now vpc_security_group_ids. But what is node_security_group_id for if vpc_security_group_ids also exists?
Secondly, we had the following for version 17.24.0:
  cluster_create_security_group = false
  cluster_security_group_id     = aws_security_group.eks_cluster.id
  worker_create_security_group  = false
  worker_security_group_id      = aws_security_group.eks_cluster.id

With aws_security_group.eks_cluster.id referencing a SG that had the following rules:
# EKS ENI & Managed NodeGroup security group
resource "aws_security_group" "eks_tooling" {
  name        = "eks-eni-and-managed-nodegroup-${var.eks_cluster_name}"
  description = "Applied to EKS ENIs and Managed NodeGroups"
  vpc_id      = var.vpc_id

  tags = {
    Name        = "eks-eni-and-managed-nodegroup-${var.eks_cluster_name}"
    Environment = var.environment_name
    Capability  = "Security Group"
    Cluster     = var.eks_cluster_name
  }
}

# Allow all ingress TCP traffic to self. Worker<->Master nodes allow all traffic
resource "aws_security_group_rule" "eks_ingress_tcp_traffic_tooling" {
  description       = "All TCP traffic. Worker and Master communication"
  security_group_id = aws_security_group.eks_cluster.id
  type              = "ingress"
  from_port         = 0
  to_port           = 65535
  protocol          = "tcp"
  self              = true
}

# Allow all ingress UDP traffic to self. Worker<->Master nodes allow all traffic
resource "aws_security_group_rule" "eks_ingress_udp_traffic_tooling" {
  description       = "All UDP traffic. Worker and Master communication"
  security_group_id = aws_security_group.eks_cluster.id
  type              = "ingress"
  from_port         = 0
  to_port           = 65535
  protocol          = "udp"
  self              = true
}

Is it true that these SecurityGroups and rules are already added by the provider now? I ask because the SG and SG rules above were written over 2 years ago, so it's entirely possible the provider does this kind of stuff now.

I'd like to know more about this too. Going through this same upgrade atm.
So far not much luck getting the security groups lined up, but learning quickly.
I'll try to ping back if I find anything out myself.

node_security_group_id is the primary security group id, and vpc_security_group_ids is any additional security groups.
I believe the distinction is primarily required because of the underlying logic in it.
If the module is told not to create the security group, then it checks that the secuirty group id has been provided.
In a normal programming language one might just check that there was at least one security group in the list of security groups, but it's probably easier to have two separate fields in terraform.
Maybe there are other reasons to separate the two as well.

I am curious if you got to try going straight to v19. I'm upgrading ours atm and have done like 5 v17->v19 transitions successfully so far. It has not been easy though.
I'd even be up for a slack or zoom sometime now that I feel pretty confident about it.
Cheers!

in general, there are two distinct security groups because there are two logical constructs at play - the control plane, and the data plane. Therefore there are access requirements for the control plane, and access requirements for the data plane. For the majority of the workloads, users will only be modifying access in the node security group. You can see more details and reasoning behind the design here https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/docs/network_connectivity.md

So I've come back to this and given it another try but this time the upgrade straight from 17.x to 19.x. It seems that the Security Groups that are attached to the worker nodes is the one that was mentioned above: aws_security_group.eks_cluster.id. Whereas on the cluster before the upgrade, the security group that seems to be attached to the worker nodes is the default security group with description: "EKS created security group applied to ENI that is attached to EKS Control Plane master nodes, as well as any managed workloads.".
I'm not entirely sure where I need to change in order to get it to work.
Pre upgrade:
  cluster_create_security_group = false
  cluster_security_group_id     = aws_security_group.eks_tooling.id
  worker_create_security_group  = false
  worker_security_group_id      = aws_security_group.eks_tooling.id

After upgrade:
  create_cluster_security_group = false
  cluster_security_group_id     = aws_security_group.eks_tooling.id
  create_node_security_group  = false
  node_security_group_id      = aws_security_group.eks_tooling.id

Now as expected, the Security Group that is being attached to the nodes is indeed  aws_security_group.eks_tooling.id. Which somewhat seems expected, the only thing that I don't understand is how in 17.x when we provided worker_security_group_id      = aws_security_group.eks_tooling.id, it still attached the EKS created Security Group to the EC2 instances (worker nodes).

Update:
I managed to solve the above by just adding the following:
  eks_managed_node_group_defaults = {
    attach_cluster_primary_security_group = true
    ...
    ...
  }.

I need to sort out the Security Group Rules in future anyways but this has allowed me to progress with a potential upgrade.
I can close now as I know the answer to the question I asked when I raised this ticket!
Thanks for your help both @reedjosh  @bryantbiggs


Proper graceful shutdown

use count down latch to block awaiter thread

@jvmlet anything I can do to help clarify the behavior of shutdownGrace? I've tested it on a sample service and setting shutdownGrace to 0 behaves properly and does not give any pre-existing calls any time to complete (no graceful shutdown) while setting it to something like 30 seconds does allow any ongoing calls to complete before the server shuts down.

According to this logic in destroy method
 if (shutdownGrace < 1) {
                    s.awaitTermination();
                } else {
                    s.awaitTermination(shutdownGrace, TimeUnit.SECONDS);
                }
}

setting shutdownGrace to 0 should wait infinitely.
So I'm confused when you say that   setting shutdownGrace to 0 behaves properly and does not give any pre-existing calls any time to complete

There are two distinct paths that we need to cover.
1. Start the server keep it running to serve requests
When the program starts, we need to start the server and keep it running to serve requests. The current code keeps the server running by creating an awaiter thread that calls awaitTermination to prevent the thread from completing and thus ending the Java program (this PR changes it so that we use a lock instead of awaitTermination to prevent the thread from completing).
This is working fine.
2. Shutting down the server due to JVM shutdown
When the JVM is instructed to shutdown (such as by a SIGINT signal to the java process), it gives the application code a chance to clean up. Once the application's clean up logic has completed, the JVM will shut down.
This shutdown path as a completely separate path from the first path. And this is the path we are trying to fix.
The destroy method is our bean's chance to clean up before the JVM shuts down. The moment the destroy method returns / completes, the JVM will shut down regardless of the status of the awaiter thread that we created when starting the server.
This means that we should only allow destroy to return whenever we are ready for the JVM to shut down. In order to prevent destroy from returning, my original PR adds another call to awaitTermination inside the destroy method, which will wait until all preexisting calls to finish before returning.
shutdownGrace does not control how long to keep the server running after startup.
shutdownGrace is only applicable to the shutdown path (the second path). It controls how long to wait for preexisting calls to finish during shutdown.

Setting shutdownGrace to 0 means that we do not wait in the destroy method for preexisting calls to finish

This is not true. Have a look at my PR to your repo :
if (shutdownGrace < 1) {
                    s.awaitTermination();
                } else {
                    s.awaitTermination(shutdownGrace, TimeUnit.SECONDS);
                }
}

With 0 or negative value we wait indefinitely.

With 0 or negative value we wait indefinitely.

Ah my fault. I misunderstood that part of the PR.
I have a couple of concerns with that change:

Having 0 represent infinite is a bit odd. I think a negative number makes more sense here.
If we default shutdownGrace to 0, and also have 0 mean infinity, then we don't preserve the existing behavior. The existing behavior (prior to my PR) is to not wait in destroy. This change makes it so that the default behavior is to wait indefinitely*.

What do you think about keeping 0 to mean don't wait instead of wait indefinitely?

Yes, you are right. Let's have 0 as don't wait as it was before. But please have a waiter thread to block on count down latch instead of awaitTermination().

But please have a waiter thread to block on count down latch instead of awaitTermination()

I can make this change. Out of curiosity, what is the problem that the CountDownLatch is solving? If it is important, perhaps we should also update the grpc-java repo's examples

Closing in favor of: https://github.com/LogNet/grpc-spring-boot-starter/pull/139/commits/4c0dacb28c4ec49e929215afe5a9ca0a310af642

Out of curiosity, what is the problem that the CountDownLatch is solving

I just don't feel comfortable calling awaitTermination() twice.

FWIW the grpc-java maintainers didn't have any concerns with calling awaitTermination twice: https://github.com/grpc/grpc-java/pull/6512

FWIW the grpc-java maintainers didn't have any concerns with calling awaitTermination twice: grpc/grpc-java#6512

I wonder what happens if awaiterThread completes before destroy methods completes as a result of calling  s.shutdown()  in destroy method.
I'm also thinking to make awaitThread as private field and add awaitThread.join(); in destroy method , what do you think ?

I'm also thinking to make awaitThread as private field and add awaitThread.join(); in destroy method , what do you think ?

What problem are we solving with that?


fix(mdc chips) Fix matChipRemove Expression has changed error

This line works fine with mat-icon, but was causing errors in a
unit test environment when matChipRemove was on a button element.
Defer the tab index update to avoid the errors.

jelbourn@ or crisbeto@, would one of you mind taking a look?


Test cases getting failed on using useAlert()

TypeError: Cannot read property 'current' of undefined
> 14 |     let alert = useAlert();

I am not using useRef in my component and test cases started failing only after adding this react alert.

I have the exact same Error using Typescript, testing with Jest in a create-react-app bootstrap

I have this issue too. did anyone solve it? usealert seems to be the only thing breaking my unit tests :/

Actually, found the solution. It's here: https://github.com/schiehll/react-alert/issues/148
(wrap in AlertProvider)


Current price / close price

Is there a quick way just to grab the current price when the market is open and the "close" price when the market is close? Scanning through the API, i only see bid,ask, previousClose, and history(), but nothing just combines that data to single field.

yep, not clear to me neither how do we get intraday data vs historic data.
Apparently the functions would seem to be the same but the behaviour would change ?
There is no example that I could find on the author's page neither

Hi, I think I have found the correct solution to this.
The historical close price updates during trading to display the current value.
q = yf.Ticker("MSFT")
data_frame = q.history("1d")
price = data_frame["Close"].values[0]


make pipeline run with local (not-singularity) R environment

will make it easier to add and change packages used in the pipeline

Due to hardcoded urls in bio-conda bioconductor packages, it appears this may be impossible to accomplish...


Selected menu item background is no longer controlled by the theme

VSCode version: 1.54.0-insider
OS: macOS Catalina 10.15.7

Steps to Reproduce:

Pick a theme (I use Community Material Theme Darker High Contrast, but I don't think it matters)
Open the command menu
The background of the selected menu item now always uses a navy blue colour. Previously, it was light grey (may or may not be overridden by the theme I used)
If this is expected, just wondering what theme colour property I should use to override it back again

Does this issue occur when all extensions are disabled?: Yes

If this is expected, just wondering what theme colour property I should use to override it back again

Yes. It's part of #115873. Ping @joaomoreno for correct color token.

The right change would be to swap customizing the list.focusBackground color and simply customize the quickInput.list.focusBackground one. This will be clearly laid out in our Release Notes. If you do that change today I suggest to target your extension to Code >= 1.54.


Fix concurrency issues

Intermittent timeouts on certain channel reads can occur, and not catch
when a context has been closed causing hangs and other potential issues.
This adds additional checks for when a context has been closed in a
first pass at fixing the fundamental issue.
Additionally, gets rid of the raw{Marshal,Unmarshal} calls, and
updates LICENSE.

@kenshaw
I have encountered problems in this place.
https://github.com/kenshaw/chromedp/blob/a76972444aa378c1ad34715e64b308ee19faadad/chromedp.go#L274

@molon apologies. I had missed these other instances on fixing the context read. I'll be pushing an update shortly covering these instances.


[TASK] Remove empty trailing lines from PHP files and templates

This patch removes empty trailing lines from PHP files and configuration
templates to comply with PSR-12 which defines the following on file endings:
All PHP files MUST end with a non-blank line, terminated with a single LF.
See https://www.php-fig.org/psr/psr-12/#22-files

Seems I messed up my master. But no issue for this PR. Will clean it afterwards...

It's rebased now


XDG overrides can be used to inject a library to suid process

From reading of source code, env override is disabled for suid binaries on this line but this doesn't affect using XDG paths in any way -- it only depends on override == NULL later. One can override XDG_CONFIG_DIRS with malicious configuration and run a setuid process, which then will inject malicious library into itself.
I haven't actually checked that it would work and was just reading the source code, so I'm sorry if I'm mistaken!

Thanks for the code review! On reviewing it myself, I confirmed XDG_CONFIG_DIRS and XDG_DATA_DIRS are accessed with secure_getenv, which I understand to return NULL when the process is SUID or SGID. Therefore, I do not believe this report is valid as written.
However, this report did prompt me to review the loader's use of environment variables in general, and loader_add_layer_env looks pretty suspicious; it does not use secure_getenv and looks like it's invoked unconditionally during vkCreateInstance.

@Ralith Oh, I have not noticed secure_getenv -- I feel embarrassed and should have been more attentive, sorry for the noise.
About loader_add_layer_env -- from a very cursory glance it only adds layers from already filtered sources (i.e. from "approved" layer locations) so it should be fine. I'm not sure however -- that is literally after two minutes of reading.

Forgive my ignorance, but is there a reason we should not always use secure_getenv?  I could change the one, or I could change the loader_getenv to always use secure_getenv on Linux and just replace the manual usages of secure_getenv back to loader_getenv.

I didn't hear back, so I've switched all loader getenv calls with secure_getenv if that's available.  This change is in commit f7a2742355bb67cd3f2d7a7e3dce36f7249f8bd5.  Please let me know if I missed anything.  Otherwise, I'll close this issue in a few days.

The downside with secure_getenv is, of course, that it doesn't work when the process is SUID, so if there are any uses of environment variables which do not represent a security vulnerability, said uses become unreasonable. I'm not 100% sure what the semantics of all environment variables read by the loader are, but e.g. @abbradar suggested that VK_INSTANCE_LAYERS may be one such.
f7a2742355bb67cd3f2d7a7e3dce36f7249f8bd5 falls back to exploitable behavior if secure_getenv is unavailable. Are you sure that's appropriate? To quote the manpage, secure_getenv returns NULL when:

the process's effective user ID did not match its real user ID or the process's effective group ID did  not  match its real group ID (typically this is the result of executing a set-user-ID or set-group-ID program);
the effective capability bit was set on the executable file; or
the process has a nonempty permitted capability set.

It seems desirable to manually perform a similar set of tests when accessing sensitive environment variables such as layer search paths if secure_getenv cannot be a hard dep.

getauxval(AT_SECURE) from sys/auxv.h appears to be a good, forwards-compatible solution for testing whether the environment can be trusted on linux, but is not available on BSDs. issetugid might be appropriate on BSDs, but I haven't checked carefully.

Some libc's don't support secure_getenv at all, like musl.  For our official loader builds, we use a C library that does include this.  Only people building their own loader will run into issues with falling back to a non-secure getenv.  I'll add a pragma which triggers a warning in these cases as well, that should fail on our internal builds if it ever happens.
As far as environment variables go, we have several that could cause different drivers/layers to load that could also be a security concern.  I'll investigate and use the secure get on only those.
Thanks again, I'll update with the hopefully final commit.

To be clear, I believe the behavior of secure_getenv can be reliably emulated on other libcs by guarding getenv calls with something like
if(getauxval(AT_SECURE)) return NULL;, mitigating the need for unsafe behavior on non-glibc. This is very linux-specific but I don't think it's glibc-specific--musl certainly defines it, at least, and I suspect any working libc needs the facilities to set up prior to main properly.

I've committed all my changes with a984b99946b3c8a7d047861698972da26a032c61 and 60dc418bdc8ca3000f254c2a8940cf73d9b42bce. It doesn't fix the case which doesn't find secure_getenv or __secure_getenv.  I'm hesitant to make the getauxval change without being able to test it on more platforms.
I would file a separate issue from this since the original issue should be fixed by the above commits, and the remaining issue is limited to user developer loader's on systems with no direct support of the secure versions.


fix: Issue#812 fixed. Navbar made uniform in the rate us page.

Title and Issue number

Title : Navbar in the rate us page fixed.
Issue No. : #812
Code Stack : HTML, CSS and JS
Close #812

Description

I have fixed the navbar in the rate us page such that it looks consistent with the index page as well.
Video/Screenshots (mandatory)

In the index page :

In the rate us page :

Type of PR

[x] Bug fix

Checklist:

[x] I have performed a self-review of my code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[x] I have gone through the  contributing.md file before contributing

Additional context:

##Are you contributing under any Open-source programme?

[ ] I am contributing under GSSOC'24
[ ] I am contributing under VSOC'24

@apu52 please check the PR and tell me any changes needed.


[Minor] Removed unused variables and parameters

I've updated the PR according to @slde-gorillaman's comments and rebased against master to resolve conflicts.


disable ath79 for now till kernel hangs on boot are fixed

i downgraded back to v2022.1.1 in site version v2022.1.12 and upgraded to the fixed v2022.1.3 in v2022.1.13


Fails to install on Linux due to /home/dynatrace not existing

On Linux (specifically CentOS 7.x), the agent fails to install.
Affected Puppet, Ruby, OS and module versions/distributions

Puppet: 5.5.6
Ruby: puppet ruby
Distribution: CentOS 7
Module version: 0.0.3

How to reproduce (e.g Puppet code you use)
puppet module install dynatrace-dynatraceoneagent
cat << EOF > /tmp/oneagent.pp
class { 'dynatraceoneagent':
  download_link => 'https://dynatrace(censored)'
}
EOF
puppet apply /tmp/oneagent.pp

What are you seeing
Error: Cannot create /home/dynatrace/oneagent; parent directory /home/dynatrace does not exist
Error: /Stage[main]/Dynatraceoneagent/File[/home/dynatrace/oneagent]/ensure: change from 'absent' to 'directory' failed: Cannot create /home/dynatrace/oneagent; parent directory /home/dynatrace does not exist

What behaviour did you expect instead
Successful installation
Output log
Warning: This method is deprecated, please use the stdlib validate_legacy function,
                    with Pattern[]. There is further documentation for validate_legacy function in the README. at ["/etc/puppetlabs/code/environments/production/modules/dynatraceoneagent/manifests/resources/cleanup_log.pp", 20]:
   (location: /etc/puppetlabs/code/environments/production/modules/stdlib/lib/puppet/functions/deprecation.rb:28:in `deprecation')
Notice: Compiled catalog for dyntest01.vagrant.local in environment production in 0.11 seconds
Error: Cannot create /home/dynatrace/oneagent; parent directory /home/dynatrace does not exist
Error: /Stage[main]/Dynatraceoneagent/File[/home/dynatrace/oneagent]/ensure: change from 'absent' to 'directory' failed: Cannot create /home/dynatrace/oneagent; parent directory /home/dynatrace does not exist
Notice: /Stage[main]/Dynatraceoneagent/File[install.sh]: Dependency File[/home/dynatrace/oneagent] has failures: true
Warning: /Stage[main]/Dynatraceoneagent/File[install.sh]: Skipping because of failed dependencies
Notice: /Stage[main]/Dynatraceoneagent/File[dynatrace_installer_download]: Dependency File[/home/dynatrace/oneagent] has failures: true
Warning: /Stage[main]/Dynatraceoneagent/File[dynatrace_installer_download]: Skipping because of failed dependencies
Notice: /Stage[main]/Dynatraceoneagent/Dynatraceoneagent::Resources::Install_oneagent[install_oneagent]/Exec[install_oneagent]: Dependency File[/home/dynatrace/oneagent] has failures: true
Warning: /Stage[main]/Dynatraceoneagent/Dynatraceoneagent::Resources::Install_oneagent[install_oneagent]/Exec[install_oneagent]: Skipping because of failed dependencies
Notice: Applied catalog in 0.07 seconds

Any additional information you'd like to impart
Perhaps the user should be created?
Perhaps the user's home directory should be created using the managehome attribute?
https://puppet.com/docs/puppet/5.3/types/user.html#user-attribute-managehome

sure would love to see this merged in.  pretty easy fix.

fixed on latest version


"Invalid regular expression" error with test names ending in ?

Steps to reproduce:

Create a test named "foobar?".
Refresh the mocha sidebar.

Result:

Invalid regular expression: /foobar?+/: Nothing to repeat

Nothing loads.
Diagnosis:
https://github.com/maty21/mocha-sidebar/blob/88f04f5d054b32704a23c94d0fb1d67cfcd3acf6/provider-extensions/NavigateEditorItem.js#L7
I think the problem is that test names should be treated as plain text, not regexes.

Proposed PR: #42

tks for your contribution


Artifact Attestations

Summary
The SLSA framework defines a gradually increasing set of security measures designed to ensure the integrity of software artifacts throughout the supply chain. Once an organization reaches SLSA Build Level 2, they’ve implemented a substantial set of best practices to help secure their software supply chain.
Summary
Sigstore and SLSA (Supply chain levels for Software Artifacts) are two initiatives designed to ehance the security of the software supply chain.
The Sigstore project provides infrastructure for keyless signing, verifying, and protecting software.  By using cryptographic signatures, Sigstore enables developers and users to verify the integrity an dorigin of software artifacts, thus preventing insertion of malicious code during the sofware development and distribution process. In addition to the tooling the project sponsors graciously host a public good instance with transparency log to enable the broader community to adopt signing as part of their workflow.
Supply-chain Levels for Software Artifacts (SLSA) is a security framework that helps ensure the security and integrity of your software supply chain. In particular it defines a build provenance attestation to describe how an artifact of set of artifacts was produced. The build provenance contains information such as the repository, commit, and workflow where the artifact was produced which you may not want published to a public log.
Intended Outcome
Artifact Attestations enables you to realize all of the benefits of Sigstore and SLSA while keeping your information private.
How will it work?
Customers will be able to:

Use first party GitHub Actions to generate and sign build provenance attestations for any artifact.
Store those attestations securely in the GitHub attestation store.
Download and verify attestations using the GitHub Cli.

🚢 This has shipped: https://github.blog/changelog/2024-05-02-artifact-attestations-public-beta


Key Vault Permissions

Just a note in our implementation the only Key Vault permission required for the SQL Monitoring profile is Key Vault Reader. Can you review these permissions if they are required ?
Microsoft.Authorization/roleAssignments/write
Microsoft.Authorization/roleAssignments/delete

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 0c8f1262-a509-dbd4-3690-d36fec7cbcd6
Version Independent ID: 81eb8133-7111-236d-a9a5-124f7961f656
Content: Enable SQL insights - Azure Monitor
Content Source: articles/azure-monitor/insights/sql-insights-enable.md
Service: azure-monitor
Sub-service: insights
GitHub Login: @bwren
Microsoft Alias: bwren

@dpatel124 Thank you for reaching out to us, our team will review and get back to you at the earliest.

Hi @dpatel124, Yes, all 3 perms are required.
'write' and 'delete' are pre-requisite perms needed to create or delete permission models on Key Vault. Both perms roll up to the Owner & Administrator roles by default. i assume you are an Admin/Owner on the subscription which explains why the only other perm you had to set was 'key Vault Reader' which explicitly grants the ability to list Key Value Objects in KV.
Hope this helps but dont hesitate to ping back if you have any followup questions.
cheers,
Femi


Documentation link broken

Seeing as this has been reported and fixed before i'm a bit hesitant to report it, but better safe than sorry!

The docs are hosted via IPFS on one of the dev's machines. Unfortunately, they aren't pinned in many places, so they tend to disappear when that machine goes offline for any reason. If you'd like to help, you can pin the docs to your own IPFS nodes!

The docs are not down and are hosted on my server, however they do sometimes need quite some time until they are loaded – especially when ipfs.io is overloaded again.

Just FYI: in the py-ipfs-httpclient branch the link is broken due to the renaming:
https://ipfs.io/ipns/QmZ86ow1byeyhNRJEatWxGPJKcnQKG7s51MtbHdxxUddTH/Software/Python/ipfshttpclient/
ipfs resolve -r /ipns/QmZ86ow1byeyhNRJEatWxGPJKcnQKG7s51MtbHdxxUddTH/Software/Python/ipfshttpclient/: no link named "ipfshttpclient" under QmPkXGx17pqqktjdRQnVrPz3sr21U5NjhTV1CTMvzaX1dw

When ipfshttclient becomes the main branch, please remember to pin the renamed docs directory.

@radfish: Yes, I haven't pushed any documentation with the new code yet, but will do once we release the first version.

The new ipfs-http-client library now has a different documentation link on its own IPNS ID (not on my machine's node one as previously). Previously it had been different because back when we published the first documentation snapshots, none-node-ID IPNS names weren't even a thing yet.


Installation is super slow

So I've installed hundreds of these distros and on modern hardware the installation should take no more than a few minutes.
I've a Corsair GTX USB-SSD 3.1 which has a read speed of 500MB/s and write speed of about 400MB/s.
Trying to install on an NVME SSD with a read speed of 5000MB/s and write speed of about the same.
Everything from setting boot flags to creating new partitions takes like 3 minutes each... so even just the first few percent of the installation takes like 20 minutes plus.
Installing the regular version of Manjaro takes about 2½ minutes total. So there's definitely something going on with the way you have modified the installer to accommodate Sway. I would give you more information but there's no verbose read-out of the installer actions, just a singular progress bar.

just to be sure: nvidia?


package.json: Update @patternfly/react-core package dependency

Check for any outstanding update of point version of any outstanding NPM package dependency

[x] npm-update

npm-update in progress on 3-ci-srv-01.
Log: https://logs.cockpit-project.org/logs/npm-update-922-20200402-085858/

npm-update @patternfly/react-core done: https://github.com/cockpituous/welder-web/commits/npm-update-@patternfly/react-core-20200402-085959

Please manually check features related to these files:
components/ListView/BlueprintContents.js:import { DataList, Alert } from "@patternfly/react-core";
components/ListView/BlueprintsDataList.js:import { DataList, DataListItem, DataListItemRow, DataListCell, DataListItemCells } from "@patternfly/react-core";
components/ListView/ComponentDetailsView.js:import { Tooltip, TooltipPosition } from "@patternfly/react-core";
components/ListView/ComponentInputs.js:} from "@patternfly/react-core";
components/ListView/ComponentSummaryList.js:} from "@patternfly/react-core";
components/ListView/ComponentTypeIcons.js:import { Tooltip, TooltipPosition } from "@patternfly/react-core";
components/ListView/ComponentsDataListItem.js:} from "@patternfly/react-core";
components/ListView/DependencyListView.js:import { DataList } from "@patternfly/react-core";
components/ListView/ImagesDataList.js:import { DataList } from "@patternfly/react-core";
components/ListView/ListItemImages.js:} from "@patternfly/react-core";
components/ListView/ListItemUploads.js:} from "@patternfly/react-core";
components/Logs/Logs.js:} from "@patternfly/react-core";
main.js:import<EMAIL_ADDRESS>package.json:    "@patternfly/react-core": "3.153.3",

Codecov Report

Merging #922 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #922      +/-   ##
==========================================
- Coverage   76.52%   76.49%   -0.03%
==========================================
  Files          69       69
  Lines        3386     3386
  Branches      710      710
==========================================
- Hits         2591     2590       -1
- Misses        795      796       +1

Impacted Files
Coverage Δ

core/selectors.js
91.74% <0.00%> (-0.92%)
:arrow_down:

Continue to review full report at Codecov.

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

Close this PR due to duplicated with #924


drop two-phase compilation targeting mic

Dropping two-phase compilation targeting MIC architecture affects the build system as well as the source code:

Begin/end macros decorating symbols originating from external headers, and API decorators, e.g., LIBXSMM_API
Build system (Makefile, Makefile.inc, and SpecFEM sample)

Makefile internal variable: NO_OFFLOAD_FLAG.


Create a Flask Server 🌐

Task :

Create a Flask server in a folder named backend
Initiate Home Route with the React App

@pooranjoyb can you please elaborate more on this?

@pooranjoyb can you please elaborate more on this?

You'll have to initiate the Backend for the application.

Create a folder in the Root directory named backend
Create a server.py file inside it
Import and install required dependencies for creating the Flask Server
Create / route for the application.
Make sure that React App Runs in the Flask Server upon starting it.

Don't forget to add requirements.txt file in the backend directory.

Got it. @pooranjoyb can you assign it to me?

Would also like to work on the backend sir

Hello devs. I will also like to work on the backend if it possible.


Pop Up KB Article and Audit Trail

any update on when these features will be available on the UUI? many thanks

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 9ab324e0-f5c6-64cb-d93b-85d238bf25d3
Version Independent ID: 94fbb660-5300-51a1-9c98-4b6500800e29
Content: About Unified Interface Dynamics 365 Customer Engagement
Content Source: ce/admin/about-unified-interface.md
Service: crm-online
GitHub Login: @jimholtz
Microsoft Alias: jimholtz

Hi,
Unified Interface features mentioned in the topic are available on version 9.x for both Dynamics 365 for Customer Engagement Online and On-prem.
Thanks,
Mints

hi Mints, please can you let me know where I can access Audit Trail on the new UUI, it's not under 'Related' section, if it's available then where is it?

@mspilde can you help?

hi there, when is KB pop up and audit feature going to be available on UI?

I've seen a screenshot of the Audit History in the UUI today on Linked-In.
Can Microsoft confrim a rollout of this feature?


I want to contribute!

Hi! My name is Karan. I am a beginner developer. I came here from issuehub.io. I don't have experience contributing to open source projects but would love starting to do so 😁

Hi @shettykaran21 !!
First of all, sorry for the late response. We are so glad to have you on board!
I'll work on an issue for you asap and link it here, ok?
Do you have any restrictions about working with React or with pure HTML/CSS ?

@tiagostutz I am not fully comfortable with React but I will try my best!
Yeah sure, please link an issue 👍

Not a problem at all @shettykaran21 !
I can assign to someone else and will open another issue for you and link it here, ok?

Hey @shettykaran21 how about this issue? https://github.com/bancodobrasil/stop-analyzing-embed/issues/51
Take a look and if you want to tackle that, please comment on the issue.

Hi @shettykaran21 ! What about the issue https://github.com/bancodobrasil/stop-analyzing-embed/issues/55?
Want to tackle that? If so, just comment on that and we will assign that to you.!

Hi! My name is Adebola. I am a beginner developer. I came here from goodfirstissue.dev. I don't have experience contributing to open source projects but would love to do so 😁. I have experience with HTML, CSS, and javaScript.
Hope to hear from you soon

Hello Sir,I want to contribute.I am new to open source.Please me out.I am comfortable with react,HTML,CSS,...

Hi! My name is Adebola. I am a beginner developer. I came here from goodfirstissue.dev. I don't have experience contributing to open source projects but would love to do so 😁. I have experience with HTML, CSS, and javaScript.
Hope to hear from you soon

Hi there @OluyemisiA  👋🏻 !! Welcome to stop-analyzing.
First of all, sorry for the late response. I was closing some old pending tasks here and got stuck on that.
Thanks for reaching by and offering help to the project. I'm sure we will craft some issues for you to take, learn and make the project even better.! What about the issue https://github.com/bancodobrasil/stop-analyzing-embed/issues/51? Want to take that? If so, just comment on the issue and I'll assign it to you.!

Hello Sir,I want to contribute.I am new to open source.Please me out.I am comfortable with react,HTML,CSS,...

Hi there @sj00coder  👋🏻 !! Welcome to stop-analyzing. Nice to have you on board.!
Thanks for reaching by and offering help. We will craft some issues for you to take, learn and  grow the project.!
As you are comfortable with React/HTML/CSS/JSS, what about the issue #76 ? Want to take that? If so, just comment on the issue and I'll assign it to you, ok?


Fix BlockMask: Adjust Regex generation to allow a strict prefix

Description
Currently, the logic for generating the regex for a BlockMask requires the first Block to use a range from 1 to X.
If not, the generated regex is invalid.
Resolves #8308
How Has This Been Tested?
Tested using the original unit test and updated it to include an additional check.
The unit test viewer was also used to test the UI component.
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[x] The PR is submitted to the correct branch (dev).
[x] My code follows the code style of this project.
[x] I've added relevant tests.

Thanks


DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-archive-test-target_0a1dcad3-c9be-4def-a05e-e816680d3e8b/pull/1 is merged into live branch.
Auto archive content to https://github.com/opstest2/docs-archive-test-target_0a1dcad3-c9be-4def-a05e-e816680d3e8b.git

Docs Build status updates of commit 72243c6:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error-UserAccountBuildPermissionInsufficientError] Owner v-alji no longer has Read permission of the repository https://github.com/opstest2/docs-archive-test-source. It might be due to recent GitHub changes on SSO. Please ask the owner v-alji to logon to Docs Portal https://ops.microsoft.com once again. If it is not the case, please ask anyone of Admin permission of the repo to assign a new owner via Docs Portal https://ops.microsoft.com

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Feat/53 handle different languages

used decimal points or commas in pd.read_csv() depending on the chosen language so that floats are read as floats instead of strings
introduced a database and language specific dictionary for column names so that prettify_table works for en and de

Will add tests for language support once https://github.com/CorrelAid/pystatis/pull/99 is merged.

Will not support language='en' for Regionalstatistik database, since the API responses are of low data quality and handling them is too complicated and error prone.


Add playwright tests for missing scanrios in Form Fields

Add playwright tests for the missing scenarios in the Form Fields.
Please refer US-611865 for more details.

What's happening with this PR?


Client Crash when running /warn command

TypeError: "Return value of WarnPlayer\Main::onCommand() must be of the type boolean, none returned" (EXCEPTION) in "plugins/Warn-master/src/WarnPlayer/Main" at line 139
2019-04-15 [16:23:29] [Server thread/DEBUG]: #0 src/pocketmine/command/PluginCommand(58): WarnPlayer\Main->onCommand(pocketmine\Player object, pocketmine\command\PluginCommand object, string warn, array Array())
2019-04-15 [16:23:29] [Server thread/DEBUG]: #1 src/pocketmine/command/SimpleCommandMap(270): pocketmine\command\PluginCommand->execute(pocketmine\Player object, string warn, array Array())

You need to use the patch version of the plugin. Or even still - Use the latestpoggit build. Issue closed.

Latest poggit build has same client crash issue when running the command, just tried it.

Please post the error log for the latest poggit build.

Did you try this link: https://poggit.pmmp.io/ci/iZeaoGamer/WarnPlayer/WarnPlayer

Okay, please try the latest poggit build, as this bug should now be fixed with v3.0.0.


Where is the "INSTALLED_APPS"

INSTALLED_APPS = (
...
'django.contrib.sites',  # This is required by Django Classified
'bootstrapform',  # This is required by Django Classified
'sorl.thumbnail',  # This is required by Django Classified

'django_classified',

)
Where exactly needs to input those entries above?

in quickstart.py


Local history supported

Add local history supported.
Thx.

@jzendo can you be more specific?

A number of days has past without answer on the questions asked. I am thereby going to close this issue to clean up our backlog of issues. Once you can answer on the questions, the issue can be reopened again. Thanks for understanding this process!


add target cpu info to configuration

site_config remains local, no longer exposed
added field 'target_cpu' to cfg and config file environments

as discussed in https://github.com/keplerproject/luarocks/issues/390#issuecomment-114852615

oops... fixed!

I had a go at testing this but I think something is wrong. luarocks.cfg seems to be overriding my config file with wrong values.
This is what the installer found:
==========================
== System check results ==
==========================

Will configure LuaRocks with the following paths:
LuaRocks        : c:\luarocks\2.2
Config file     : c:\luarocks\config.lua
Rocktree        : c:\luarocks\systree

Lua interpreter : c:\lua\X64\5.1.5\bin\\lua.exe
    binaries    : c:\lua\X64\5.1.5\bin\
    libraries   : c:\lua\X64\5.1.5\lib\
    includes    : c:\lua\X64\5.1.5\include\
    architecture: x86_64
    binary link : lua51.lib with runtime MSVCR120.dll

This is part of my config file:
variables = {
    MSVCRT = 'MSVCR120',
    LUALIB = 'lua51.lib'
}

And it seems that https://github.com/keplerproject/luarocks/blob/master/src/luarocks/cfg.lua#L342 is overriding it with the wrong value.

Ok... nevermind, I saw that "remains; configuring targets from config.lua". Until that is in place, not even the builtin build backend works on Windows. (MSVCRT variable is nil)

No... you're right. But the problem was introduced in #385. The config file was directly loaded into cfg, which exposed cfg to the config file. After changing that, the content of the config file was no longer merged into cfg, because that should now be an extra step.
Fixed it, PR is upcoming

see PR #397
please give this another try, it should also allow updating targets if you add target_cpu = x86_64 in config.lua for example.

Thanks. Will check that first thing tomorrow morning.

@Tieske Just checked and it is working fine. Also overriding target_cpu on the config file. The PR is good to merge.
Thanks!