Don't debug assert on broken link in moduleNameResolver

Fixes #47372
Fixes #50973
Fixes #55084
Fixes #55085
Fixes #55590
This debug assert was added back in #20374. Unfortunately, I believe that it's causing more problems than it solves thanks to races.
Here's a potential flow:

You open your editor, loading a pnpm installed project, which contains symlinks.
You do some package operation, which starts mucking around in node_modules.
The file watcher picks up on some of the changes, and kicks off some new program construction. pnpm is still working in the meantime, removing files and links.
The new program construction observes a symlink and sees that it's valid so it's added to the program, but slightly later, pnpm removes what the link is pointing to.
This broken symlink is observed later in a place that assumes that it won't be broken, debug asserting. Boom.

Could this be avoided if pnpm guaranteed to never cause a broken link by ensuring it removes things in the right order? Probably, but it clearly doesn't and that sounds challenging to get right and we really shouldn't crash like this.
In sys, realpath is implemented like:
function realpath(path: string): string {
    try {
        return fsRealpath(path);
    }
    catch {
        return path;
    }
}

To me, this implies that there's not much point in verifying that symlinks aren't broken, because we entirely ignore them everywhere else; if the link is broken we're going to get an error later. Or, more likely, the pnpm install will finish and the file watcher will say so.
Unfortunately I have not yet been able to produce a test case which causes this assert to fire; our compiler/fourslash tests don't really let you create broken symlinks. I think I can do it via verifyTsc so I'll try and do that.

verifyTsc also doesn't reproduce the problem; the VFS even enforces that no symlinks are broken! Even removing those checks doesn't reproduce the problem. I can't seem to get it to race :(

Honestly I'm not sure; from my skimming it seemed like all that happens is that we attempt to call findSourceFile on the broken symlink which will eventually just return undefined (createGetSourceFile catches all errors and instead calls onError and returns the empty string).

You’re right, the try/catch in createGetSourceFile will handle it. I think this should be fine, then.


Allow additional service-ui annotations

Signed-off-by: igoritos22<EMAIL_ADDRESS>
What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

If this PR will release a new chart version please make sure to also uncomment the following line:

/kind chart-release

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area falco-chart

/area falco-exporter-chart

/area falcosidekick-chart

What this PR does / why we need it:
Allow add annotations to falcosidekick-ui service
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Checklist

[ ] Chart Version bumped
[ ] Variables are documented in the README.md
[ ] CHANGELOG.md updated

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: igoritos22
To complete the pull request process, please assign kris-nova after the PR has been reviewed.
You can assign the PR to them by writing /assign @kris-nova in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Welcome @igoritos22! It looks like this is your first PR to falcosecurity/charts 🎉

/assign @kris-nova

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: igoritos22
To complete the pull request process, please ask for approval from issif after the PR has been reviewed.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@Issif, update done!

LGTM label has been added.  Git tree hash: 8527d29160d12ca476cd26810b06247b82e0cb18

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: igoritos22, Issif
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Issif]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

New changes are detected. LGTM label has been removed.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: igoritos22
To complete the pull request process, please ask for approval from issif after the PR has been reviewed.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: igoritos22
To complete the pull request process, please ask for approval from issif after the PR has been reviewed.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@Issif, I can't understand why ci/circleci lint charts is failing. Can youu help me ?

Here the result of lint from Circle-CI:
falcosidekick/values.yaml
  396:70    error    trailing spaces  (trailing-spaces)
  438:3     error    no new line character at the end of file  (new-line-at-end-of-file)
  438:1     error    trailing spaces  (trailing-spaces)

LGTM label has been added.  Git tree hash: f94801e09321689289c3ea88465194578f2ce080

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: igoritos22, Issif
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Issif]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


add -snp flag to gcs binary

This PR adds a way to tell GCS that it is expected to be running
inside an SEV-SNP enabled linux.
In addition to the flag we also try making "get-snp-report" ioctl
and refuse to run when -snp is requested, but not supported or
when -snp is not requested, but supported.
Signed-off-by: Maksim An<EMAIL_ADDRESS>

Is the work to actually set this on the gcs cmdline coming? What would we key off of there, if the host has support?

I'd like to understand better why this change is needed. I see in the end we set snpSupported based on this flag, but this isn't currently used anywhere. What will this flag be used for?


autofit

Hi,
a autofit method would be fine. So after adding markers and so one i like to call a autofit method set set the view to all markers with the minimum zoom level.

@SmuSmu Leaflet does not keep track of markers in any special way: markers are layers, and generally you don't want to fit all visible layers into view.
I would suggest keeping track of the markers in your application. If you keep all of them are in a FeatureGroup, you can easily get the bounds with getBounds.
If you really want an autoFit method, you can hack it together with the eachLayer method. Here's a quick hack:
        function autoFit(map) {
            function getBounds(layerContainer) {
                var bounds;
                layerContainer.eachLayer(function(l) {
                    var layerBounds;
                    if (l.eachLayer) {
                        var layerBounds = getBounds(l);
                        bounds = bounds ? bounds.extend(layerBounds) : layerBounds;
                    } else if (l.getLatLng) {
                        var latLng = l.getLatLng();
                        bounds = bounds ? bounds.extend(latLng) : L.latLngBounds([latLng]);
                    }
                });

                return bounds;
            }

            var bounds = getBounds(map);

            if (bounds) {
                map.fitBounds(bounds);
            }
        }

This will, however, fit any layer with a getLatLng method, not only markers.


Set cookie to locale that it redirected to, and always redirect (unless manually switched to different locale)

What problem does this feature solve?
I implemented my own version of detectBrowserLanguage when I was still using an older version of nuxt-i18n and I was happy to see this feature was added in a later version! I just tried it out, and I think the current implementation can be improved, because now it will only redirect the first time, not when a user returns to the main url.
What does the proposed changes look like?
The cookie should be set to the initially detected language, en then always check what the (last selected) language is set to in the cookie. Then we can always redirect to the language stored in the cookie. If the user manually switched language through the switchLocalePath function, the cookie can be updated with the manually selected language, and also remember this manual overwrite on the next visit.

This feature request is available on Nuxt.js community (#c81)

Doesn't seem to work though

Not working for me either. If I go to main_url/locale, it will use that locale and store it in the cookie. The next time I visit main_url (so without the locale suffix), it will load the default locale instead of using the one that's stored in the cookie

Thanks. I ended up doing something similar, making a plugin:
`
import VueCookie from 'vue-cookie'
export default function ({ app }) {
app.i18n.onLanguageSwitched = (oldLocale, newLocale) => {
if (process.browser) {
if (VueCookie.get('i18n_redirected') !== newLocale) {
VueCookie.set('i18n_redirected', newLocale)
}
}
}
}`

This is now implemented. Redirection always happens with alwaysRedirect enabled and saved locale can be updated with setLocaleCookie() method.
Can be closed.

@rchl Hi, when alwaysRedirect is enable, can I switch the locale manually and immediately just like switchLocalepath() method? I used setLocaleCookie() but it only works on the next navigation.

@MasterHiei You can set cookie and then call this.$router.replace(this.switchLocalePath(locale));

@rchl That's it! I'm foolish! Thank you for your help!

Maybe a feature request to allow switchLocalePath to change cookie automatically
Boolean to add ? this.switchLocalePath(locale, true /* set cookieKey */)

@stact despite the naming, switchLocalePath just returns URL of current page for given locale. So it wouldn't really fit to make it set the cookie. Remember it can be used multiple time in a template and then it would change state every time it's called.

For some clarity on what @rchl has stated

@MasterHiei You can set cookie and then call this.$router.replace(this.switchLocalePath(locale));

You can so this like so
 changeLocale(locale) {
      this.$i18n.setLocaleCookie(locale)
      this.$router.push(this.switchLocalePath(locale))
    }

And as confusing as all of this is, its actually documented on here
https://nuxt-community.github.io/nuxt-i18n/lang-switcher.html

If detectBrowserLanguage.useCookie and detectBrowserLanguage.alwaysRedirect options are enabled, you might want to persist change to locale by calling this.$i18n.setLocaleCookie(locale) (or app.i18n.setLocaleCookie(locale)) method. Otherwise locale will switch back to saved one during navigation.

My suggestion would be to add a switchLocale method which does this work and rename switchLocalePath to something more suited like getLocalePath

My suggestion would be to add a switchLocale method which does this work and rename switchLocalePath to something more suited like getLocalePath

I agree and given that v6 is in the works, it can be done there.

Hi everyone! Sorry if this is not the thread but I think my issue is related, also I'm a beginner at programming so for sure I must be doing something bad but can't find the reason.
I'm using the following dependencies:
"nuxt": "^2.8.1",
"nuxt-i18n": "^6.0.0"

I have the following nuxt.config.js file:
[
      'nuxt-i18n', {
        locales: [
          {
            code: 'en',
            iso: 'en-US',
            name: 'English',
            file: 'en.js'
          },
          {
            code: 'es',
            iso: 'es-AR',
            name: 'Spanish',
            file: 'es.js'
          }
        ],
        detectBrowserLanguage: {
          useCookie: true,
          cookieKey: 'i18n_redirected',
          alwaysRedirect: true,
          fallbackLocale: 'en'
        },
        lazy: true,
        langDir: 'locales/',
        vuex: {
          moduleName: 'i18n',
          syncLocale: true,
          syncMessages: true,
          syncRouteParams: true
        }
      }
    ],

Vue component:
<nuxt-link :to="switchLocalePath('en')">English</nuxt-link>
<nuxt-link :to="switchLocalePath('es')">Spanish</nuxt-link>

I'm having the following issues:

When I access the website for the first time it reads the default browser language (lets say it's English at the beginning) saving the value in a cookie for later use, after that I click Spanish and it changes correctly adding the /es to the URL, the issues are that the cookie is not being updated to es and the content is not changing, only the URL changes.

I'm using this approach because I want that if the user is for example under Spanish language and deletes the /es manually from the URL and press enter to redirect to Spanish as expected and not to English as it's by default.

Another issue I saw but don't know if it's related to Vuex, Vue tools and/or nuxt-i18n is the following:

Thank you.

@cloudstrife-bce did you read the thread?
You need to manually set the cookie
 changeLocale(locale) {
      this.$i18n.setLocaleCookie(locale)
      this.$router.push(this.switchLocalePath(locale))
    }

Hi @blowsie, thank you for the help!I been reading around and searching for other repositories to see how to achieve it but unfortunately I still couldn't fix it, can you help me taking a look at my CodeSandbox please?
Basically I'm trying to achieve the following:

At the beginning get the language of the browser and show that one, if none use English by default (Working)
Always show /en or /es in the URL (Working)
Save locale and messages to Vuex (Working)
If the user deletes manually the /en or /es from the URL get the cookie value and set it to that one, not to redirect showing in English if it was in Spanish when I delete it

Another thing which is not working is the data changing in the CodeSandbox example, it only changes the URL but not the data from Testing:.
Sorry to bother and thank you again for your help.

The initial issue is fixed. There is setLocale API that changes the language, updates the cookie and redirect to new route.


add new flags & deprecate old ones

Syncs changes according to https://github.com/ava-labs/avalanchego/releases/tag/v1.10.2
Closes: https://github.com/ava-labs/avalanchego/pull/1370

Not sure why the build is failing, don't have access to view the cloudflare logs. Can you re-run all jobs? Changes LGTM @ceyonur


NetworkSecurityGroupSecurityRule missing in .NET API

NetworkSecurityGroupSecurityRule does not appear to exist in the .NET API (C# or F#).  This causes pulumi up to fail with the following message:
Diagnostics:
  pulumi:pulumi:Stack (c19-pulumi-dev):
    error: Running program '/home/zakaluka/projects/c19-pulumi/bin/Debug/netcoreapp3.1/c19-pulumi.dll' failed with an unhandled exception:
    System.InvalidOperationException: Pulumi.Azure.Network.Outputs.NetworkSecurityGroupSecurityRules is not a supported argument type.
    	monitor.registerResourceOutputs(...).c19_nsg_waf.SecurityRules.id[0]
       at Pulumi.Serialization.Serializer.SerializeAsync(String ctx, Object prop)
       at Pulumi.Serialization.Serializer.SerializeListAsync(String ctx, IList list)
       at Pulumi.Serialization.Serializer.SerializeAsync(String ctx, Object prop)
       at Pulumi.Serialization.Serializer.SerializeAsync(String ctx, Object prop)
       at Pulumi.Deployment.SerializeFilteredPropertiesAsync(String label, IDictionary`2 args, Predicate`1 acceptKey)
       at Pulumi.Deployment.SerializeAllPropertiesAsync(String label, IDictionary`2 args)
       at Pulumi.Deployment.RegisterResourceOutputsAsync(Resource resource, Output`1 outputs)
       at Pulumi.Deployment.Runner.WhileRunningAsync()

EDIT: To be clear, I created the resources using NetworkSecurityRule outside of the NetworkSecurityGroup.  This error is thrown on running pulumi up, when it is trying to update internal state (I assume).

Hi @zakaluka do you have a code snippet that I could use to reproduce? Thanks!

Here is some code in F#:
First, I created an NSG with 1 Rule:
  /// Build NSG for WAF
  let c19_nsg_waf =
    let name = "c19-nsg-waf"
    NetworkSecurityGroup
      (t name,
       NetworkSecurityGroupArgs
         (Name = i2 name, ResourceGroupName = io C19Automation.Name,
          Tags = tags ManagementSecurity))

  /// Add NSG Rule to allow Inbound traffic on ports 80 and 443.
  let c19_nsgrule_in_valid_internet =
    let name = "c19-nsgrule-in-valid-internet"
    NetworkSecurityRule
      (t name,
       NetworkSecurityRuleArgs
         (Name = i2 name,
          Description = input "Allow inbound traffic from the Internet",
          Access = input "Allow", Direction = input "Inbound",
          SourceAddressPrefix = input "*", SourcePortRanges = validPorts,
          DestinationAddressPrefix = io c19_ip.IpAddress,
          DestinationPortRanges = validPorts,
          NetworkSecurityGroupName = io c19_nsg_waf.Name, Priority = input 100,
          Protocol = input "Tcp", ResourceGroupName = io C19Automation.Name))

Then, I added 1 more entry, which caused the failure during refresh:
  let c19_nsgrule_out_all =
    let name = "c19-nsgrule-in-invalid"
    NetworkSecurityRule
      (t name,
       NetworkSecurityRuleArgs
         (Name = i2 name,
          Description = input "Deny outbound traffic to the Internet",
          Access = input "Deny", Direction = input "Outbound",
          SourceAddressPrefix = input "VirtualNetwork",
          SourcePortRange = input "*",
          DestinationAddressPrefix = input "Internet",
          DestinationPortRange = input "*",
          NetworkSecurityGroupName = io c19_nsg_waf.Name, Priority = input 101,
          Protocol = input "*", ResourceGroupName = io C19Automation.Name))

Here is an easier snippet, maybe.  It uses inline Security Rules instead of separate ones that reference the NSG.  Just adding  one rule causes failure here.  All items are created successfully, but the state update on Pulumi is what seems to be failing (I tore down the entire environment and re-built it using the script, and everything succeeded on Azure but failure happened during state update).
  let c19_nsg_waf =
    let name = "c19-nsg-waf"
    let nsrInbound = "c19-nsgrule-in-valid-internet"
    let nsrOutbound = "c19-nsgrule-in-invalid"
    NetworkSecurityGroup
      (t name,
       NetworkSecurityGroupArgs
         (Name = i2 name, ResourceGroupName = io C19Automation.Name,
          Tags = tags ManagementSecurity,
          SecurityRules =
            ([ NetworkSecurityGroupSecurityRulesArgs
                 (Name = i2 nsrInbound,
                  Description = input "Allow inbound traffic from the Internet",
                  Access = input "Allow", Direction = input "Inbound",
                  SourceAddressPrefix = input "*", SourcePortRanges = validPorts,
                  DestinationAddressPrefix = io c19_ip.IpAddress,
                  DestinationPortRanges = validPorts, Priority = input 100,
                  Protocol = input "Tcp") ]
             |> List.map input
             |> inputList)))

Output:
Enter your passphrase to unlock config/secrets
    (set PULUMI_CONFIG_PASSPHRASE to remember):
Previewing update (dev):
     Type                                   Name                             Plan       Info
     pulumi:pulumi:Stack                    c19-pulumi-dev                          1 error
     ├─ azure:core:ResourceGroup            C19Automation-track-2
 ~   ├─ azure:network:NetworkSecurityGroup  c19-nsg-waf-track-2              update     [diff: ~securityRules]
     ├─ azure:network:Subnet                c19-subnet-waf-frontend-track-2             [diff: -delegations,serviceEndpoints]
     ├─ azure:network:PublicIp              c19-ip-track-2
     └─ azure:network:VirtualNetwork        c19-vnet-track-2                            [diff: -dnsServers,subnets]

Diagnostics:
  pulumi:pulumi:Stack (c19-pulumi-dev):
    error: Running program '/home/zakaluka/projects/c19-pulumi/bin/Debug/netcoreapp3.1/c19-pulumi.dll' failed with an unhandled exception:
    System.InvalidOperationException: Pulumi.Azure.Network.Outputs.NetworkSecurityGroupSecurityRules is not a supported argument type.
    	monitor.registerResourceOutputs(...).c19_nsg_waf.SecurityRules.id[0]
       at Pulumi.Serialization.Serializer.SerializeAsync(String ctx, Object prop)
       at Pulumi.Serialization.Serializer.SerializeListAsync(String ctx, IList list)
       at Pulumi.Serialization.Serializer.SerializeAsync(String ctx, Object prop)
       at Pulumi.Serialization.Serializer.SerializeAsync(String ctx, Object prop)
       at Pulumi.Deployment.SerializeFilteredPropertiesAsync(String label, IDictionary`2 args, Predicate`1 acceptKey)
       at Pulumi.Deployment.SerializeAllPropertiesAsync(String label, IDictionary`2 args)
       at Pulumi.Deployment.RegisterResourceOutputsAsync(Resource resource, Output`1 outputs)
       at Pulumi.Deployment.Runner.WhileRunningAsync()

Hi @zakaluka
I tried to repro this issue but it all works fine so far. I'm clearly not doing something the same way you do.
Here is the gist with my full code: https://gist.github.com/mikhailshilkov/fb45df272c235a2643398df5bd102998
I tried creating and NSG with 1 rule, then adding another one, then removing, as internal property or as separate resources, all worked fine.
Could you give my repro a try and log the example commands you execute in the console to get an error?
I'm on Pulumi v. 1.14.1, just in case. Thank you!

Nevermind, I've finally dig into the error message. I suppose you export the rules as stack outputs, something like thig:
dict [("test", c19_nsg_waf.SecurityRules :> obj)]

This is not currently supported, see https://github.com/pulumi/pulumi/issues/3641

@mikhailshilkov Thank you for digging into this.  Is there documentation somewhere that states what objects/items can or cannot be exported?

@mikhailshilkov Thank you for digging into this. Is there documentation somewhere that states what objects/items can or cannot be exported?

Not really, you were supposed to hit this error but something didn't quite work:

Allowed types are:  String, Boolean, Int32, Double, Nullable<...>, ImmutableArray<...> and ImmutableDictionary<string, ...>

https://github.com/pulumi/pulumi/blob/6e15c83e1a2bce2e99841eebd0786106a9d51377/sdk/dotnet/Pulumi/Serialization/Converter.cs#L381

Thank you.  Closing this for now, as I have the answer.  If there's any work you'd like to track against this issue, please feel free to reopen it.


Update eatlocal.eatlocal.read_bite() to use glob() and rglob()

Instead of iterating over path.iterdir() use Path.glob() and Path.rglob().
Currently this code exists for parsing the bite.html file and rendering the instructions. Parsing the file path for the code is complicated by the fact that in each bite directory there are exactly two (at least in all bites explored so far) .py files. One file for the bite, the other for the tests.

Used a list comp to filter out the test file. Fixed this issue with 9a79ba5


Can sponge operate World asynchronously?

Bukkit does not recommend or prohibit the asynchronous operation of BukkitAPI after 1.8.
Is sponge able to perform asynchronous operations on the main thread?

No


Add support for INSERT queries

Add support for INSERT queries

INSERT INTO *** VALUES
INSERT INTO *** FROM *** WHERE ***

Added support and docs for insert queries


Firefox support

Hi, wondering if you could create a Firefox extension which does the same thing? Thanks for this great extension!

Hi @Orcamm thank you for your feedback. I'll look into it this weekend 👍

Done. Instructions here: https://github.com/franckdpt/keep-my-monitors-awake/blob/master/README.md


Classes for dark mode support on iOS are not applied when using page-router-outlet

Environment
Provide version numbers for the following components (information can be retrieved by running tns info in your project folder or by inspecting the package.json of the project):

CLI: 6.2.1
Cross-platform modules:
iOS Runtime: 6.2.0
Plugin(s):
NativeScript-Angular: 8.20.3
Angular: 8.2.13

Describe the bug
Since NativeScript 6.2, iOS dark mode has been implemented
When using a page-router-outlet, the ns-dark and ns-light classes are not applied, thus not applying the correct component css rules.
To Reproduce

Launch attached project.
The first label color should be red in dark mode, green in light mode. It's currently blue.
Edit src/app/app.component.tns.html
*comment the page-router-outlet and uncomment the stack layout
the correct behaviour will be shown

Sample project
nsbug.zip

@gdurys there is a specific rule that has to be followed when applying your custom light/dark styles. See the documentation here for details - basically, you have to do the following
authentication.component.tns.css
:host-context(.ns-dark) .ns-dark .connection {
    color: red;
}

:host-context(.ns-dark) .ns-light .connection {
    color: green;
}


headings (and possibly other formatting?) don't work within snap

This doesn't get formatted as a heading:
@snap[north]

# One

@snapend

See demo here: https://gitpitch.com/joachim-n/git-pitch-demo/master

The Snap Layouts Content Types section in the documentation explains why the markdown in your sample slide is not formatted. And what you will need to do to get the desired result.
I recommend reading through the complete Layout Features chapter in the docs as it provides lots of useful information and examples to teach you how to get the most out of snap-layouts.

Ah, I hadn't read that far in the docs, sorry!
That does seem really weird though to have these snap sections so limited. Having to use HTML tags within them seems to me to go against the whole purpose of using Markdown in the first place.

Ah, I hadn't read that far in the docs, sorry!

No worries.

That does seem really weird though to have these snap sections so limited. Having to use HTML tags > within them seems to me to go against the whole purpose of using Markdown in the first place.

Thanks for this feedback. I'm just going to jot down a few thoughts and clarifications in response, for you and for any future readers of this thread.
This one limitation - is (1) real and (2) agreed, not ideal.
But in truth the practical limitations are minimal - only basic markdown text formatting is not supported within the snap tags. And the workaround is to use the corresponding HTML snippets - which are themselves pretty simple and perfectly valid within GitHub Flavored Markdown.
Support for GitPitch markdown shortcuts within the snap tags should go a long way to mitigating concerns about overall usefulness. The detailed examples in the docs try to demonstrate that as best they can. But play around with it and you will see this for yourself.
Bottom line, if you embrace the constraints - that's a real thing apparently :) - you can achieve a whole lot with snap layouts. But they are entirely optional, so I understand they might not be for everyone.
Finally, I will update this thread if I do find a way to seamlessly support auto-formatting for markdown text within snap tags. So stay tuned.

Thanks for the detailed reply!
I'll explain my use case to give you a bit more of an idea of why this seems like a limitation to me.
I wanted to the same H1 heading appear in the same place over several slides. Because the content below the slides is not the same size, the heading moves up and down which ruins the effect of having a constant heading while the contents below change.
Therefore, snap layout seemed a good solution for this, until I found that the Markdown for headings doesn't work there.

Again, thanks for this feedback.

I wanted to the same H1 heading appear in the same place over several slides. Because the content below the slides is not the same size, the heading moves up and down which ruins the effect of having a constant heading while the contents below change.

At this point I'm not sure if you concerns are theoretical or if you have actually tried to use snap-layouts and you experiencing the problem you describe here - headings moving up and down? If you have actually experienced this problem can you please share a link to your sample presentation? I would really like to take a closer look at what you are doing.
I ask these questions because what you describe should be impossible. Should be. The only way I can imagine snapped-content moving on a slide (even temporarily) is if you have not taken the required step to deactivate transitions on the slide, per the snap-layouts documentation.
Snap-layouts are designed for exactly the purpose you first imagined - they give you (the presentation author) the ability to position content completely independent of whatever standard content might be rendered on the slide.
For example, let's assume you want to add a markdown # (H1)  to the north-east corner of each slide in your presentations. You can not use plain markdown, so you would use the equivalent HTML snippet, as follows:
@snap[north-east]

The Heading

@snapend

That's it. You would then add this to every slide you want that heading to appear on. And it should not matter what content is being rendered on the individual slides, the heading should always appear in the exact same position on every slide.
And even more powerful way to take full control over the look of your custom heading would be to use a custom css shortcut as follows:
@snap[north-east]
@css[slide-heading](The Heading)
@snapend

To use this you would need to define a custom slide-heading css class to style the font, spacing, colors, etc. of your heading.
As further reference, take a look at the GitPitch Hello World slideshow presentation demonstrates this exact behavior.
Slide #4, slide #6, slide #8, slide #11 etc all use the same north-east snap-layout positioning for their heading and that positions stays perfectly constant in all cases, regardless of the specific content on individual slides. Which is exact what everyone should see if they are using snap-layouts.
Snap-layouts are a brand new feature and I'm wide open to feedback like yours on problems, bugs etc. So thanks again. I will be very interested to learn more about the problem cases you have described.

At this point I'm not sure if you concerns are theoretical or if you have actually tried to use snap-layouts and you experiencing the problem you describe here - headings moving up and down?

You've misunderstood me. I originally was not using snap layouts. I had this sort of thing:
# Common heading

- A list
- list 2

---

# Common heading

- Longer list that takes up more space
- more
- more
- more
- more

I wanted the effect that one list would be replaced with another, while 'Common heading' would stay fixed. However, the layout system places the 'Common heading' heading in a different place on the two slides, because the 2nd slide has a longer list.
Therefore, I looked to snap layouts as a solution: I wanted to place 'Common heading' in a snap north, so it's guaranteed to stay in the same place over multiple slides.

And it should not matter what content is being rendered on the individual slides, the heading should always appear in the exact same position on every slide.

Yup, that's working fine. It's just that having to use HTML there instead of Markdown syntax is a bit of a pain.

I wanted the effect that one list would be replaced with another, while 'Common heading' would stay fixed. However, the layout system places the 'Common heading' heading in a different place on the two slides, because the 2nd slide has a longer list.

Just fyi, even without the use of snap-layouts, if you wanted all of your headings to appear in a fixed position on every slide you could have set the automatic layout policy for you presentation to use any of the  top layout options  - top, top-left, top-right - and it would not matter how long your list of items was the heading would always have been anchored in the same place.
Anyway, now you are spoiled for options. Enjoy.

UPDATE Nov 2018: GitPitch now supports plain markdown content inside of snap-tags.
This update addresses the original issue raised on this thread. You can now use regular markdown syntax to create h1, h2, h3, etc headings or apply bold or italics etc  within your snap tags. Details in the docs.

@gitpitch I'm guess fenced fragments (not @code) don't work?

Fenced code blocks are not supported with snap regions. As you noted, the @code markdown shortcut has been provided to solve that problem among other things. If for any reason you didn't want to use that shortcut you could try directly using
...
 tags.


Handle ´{[key in Extract<NodeJS.Signals, "SIGINT" | "SIGTERM">]: number}´

Describe the issue
Something like this cannot be done:
/** @type {{[key in Extract<NodeJS.Signals, "SIGINT" | "SIGTERM">]: number}} */
const signals = Object.freeze({
  SIGINT: 2,
  SIGTERM: 15,
});

To Reproduce
See above.
Which mode was used:

[ ] jsdoc
[ ] closure
[x] typescript

Expected behavior
This would not fail even though i would expect it to.
/** @type {{[key in Extract<NodeJS.Signals, "SIGINT" | "SIGTERM">]: number}} */
const signals = Object.freeze({
  SIGINT: 2,
  SIGTERM: 15,
  FOO: 23,
});

In which modes would you expect the parser to accept the failing expression:

[ ] jsdoc
[ ] closure
[x] typescript

Additional context
Add any other context about the problem here.

As you can see in the live-demo (https://jsdoc-type-pratt-parser.github.io/jsdoc-type-pratt-parser/), this expression actually can get parsed with the newest version of the parser.
It produces the following output:
{
  "type": "JsdocTypeObject",
  "meta": {
    "separator": "comma"
  },
  "elements": [
    {
      "type": "JsdocTypeObjectField",
      "key": {
        "type": "JsdocTypeMappedType",
        "key": "key",
        "right": {
          "type": "JsdocTypeGeneric",
          "left": {
            "type": "JsdocTypeName",
            "value": "Extract"
          },
          "elements": [
            {
              "type": "JsdocTypeNamePath",
              "left": {
                "type": "JsdocTypeName",
                "value": "NodeJS"
              },
              "right": {
                "type": "JsdocTypeProperty",
                "value": "Signals",
                "meta": {}
              },
              "pathType": "property"
            },
            {
              "type": "JsdocTypeUnion",
              "elements": [
                {
                  "type": "JsdocTypeStringValue",
                  "value": "SIGINT",
                  "meta": {
                    "quote": "double"
                  }
                },
                {
                  "type": "JsdocTypeStringValue",
                  "value": "SIGTERM",
                  "meta": {
                    "quote": "double"
                  }
                }
              ]
            }
          ],
          "meta": {
            "brackets": "angle",
            "dot": false
          }
        }
      },
      "right": {
        "type": "JsdocTypeName",
        "value": "number"
      },
      "optional": false,
      "readonly": false,
      "meta": {}
    }
  ]
}

@simonseyock if I try this, it gives no failure:
const signals = Object.freeze(
  /**
   * @type {{[key in Extract<NodeJS.Signals, "SIGINT" | "SIGTERM">]: number}}
   */ ({
    SIGINT: 2,
    SIGTERM: 15,
    A: 5,
  })
);

However, I do get auto-completion for SIGINT and SIGTERM when filling them in in the object.
I also get a failure if I e.g. use a string for the value of the properties.
But it does not warn about A being there.

@simonseyock thanks. There seems to be a very verbose way to achieve what I want, but thanks, it did not struck me.


Fix/436 Env var files 'devent' typo

Related issues 🔗
Closes #436
Description ℹ
Some env var files had a typo of .env.devent. Renamed to .env.devnet.

also fixed it here: https://github.com/vegaprotocol/frontend-monorepo/pull/433 :)


Speed local parsing

How to speed up the local analysis.
Pyspider gets a local address on Nginx, but it works very slowly, so parsing site. How can I fix this?
Thanks

Did you change the rate of speed on dashboard?

Oops, did not see!
everything works!


MariaDB no resource limits or requests

https://github.com/kubernetes/charts/blob/master/stable/mariadb/templates/deployment.yaml
No resource usage settings :(

Thanks @chrislovecnm. Would you be interested in submitted a PR with the required changes?

FYI -- This issue looks very similar to #60 which references the same chart

@prydonius I will defer to your experience on some sane resource default for MariaDB

@lachie83 256m .25 cpu on both ... good starting point.  But who knows ...


Build error

Hi! I got this error while building  3-AccelerationStructur:
1>------ Build started: Project: 3-AccelerationStructure, Configuration: Debug x64 ------
1>Vk-Helper.lib(VkCore.obj) : error LNK2005: vkCreateAccelerationStructureNV already defined in AccelerationStructure.obj
1>Vk-Helper.lib(VkCore.obj) : error LNK2005: vkGetAccelerationStructureMemoryRequirementsNV already defined in AccelerationStructure.obj
1>Vk-Helper.lib(VkCore.obj) : error LNK2005: vkBindAccelerationStructureMemoryNV already defined in AccelerationStructure.obj
1>Vk-Helper.lib(VkCore.obj) : error LNK2005: vkCreateRayTracingPipelinesNV already defined in AccelerationStructure.obj
1>Vk-Helper.lib(VkCore.obj) : error LNK2005: vkGetRayTracingShaderGroupHandlesNV already defined in AccelerationStructure.obj
1>Vk-Helper.lib(VkCore.obj) : error LNK2005: vkGetAccelerationStructureHandleNV already defined in AccelerationStructure.obj
Any idea why and how to fix it?
PS. vk_layer_lunarg_standard_validation is replaced with vk_layer_khronos_validation for RTX 30XX series. Simple to fix, just wanted to let you know.
PS2. Great job with your tutorials on yt! Waiting for the next one!

Thanks for the bug heads up and the info on the 3000 series (Really need to get one, but stock is low everywhere). Should be fixed now and I should have another video ready this weekend. Was unwell, but should be back to once a week soon 😄


Missing Login method in the Local Callback

I'm having an issue trying to use login. I would just add this in and do a PR, but I am really bad at doing the testing stuff. I think this is what it should look like... perhaps I'm wrong?
callback: function (req, res, next) {
    var provider = req.param('provider', 'local');
    var action = req.param('action');

    // Passport.js wasn't really built for local user registration, but it's nice
    // having it tied into everything else.
    if (provider === 'local' && action !== undefined) {
      if (action === 'register' && !req.user) {
        this.protocols.local.register(req, res, next);
      }
      else if (action === 'login' && !req.user) {
        this.protocols.local.login(req, res, next);
      }
      else if (action === 'connect' && req.user) {
        this.protocols.local.connect(req, res, next);
      }
      else if (action === 'disconnect' && req.user) {
        this.protocols.local.disconnect(req, res, next);
      }
      else {
        next(new Error('Invalid action'));
      }
    } else {
      if (action === 'disconnect' && req.user) {
        this.disconnect(req, res, next) ;
      } else {
        // The provider will redirect the user to this URL after approval. Finish
        // the authentication process by attempting to obtain an access token. If
        // access was granted, the user will be logged in. Otherwise, authentication
        // has failed.
        this.authenticate(provider, next)(req, res, req.next);
      }
    }
  }

I'm having an issue trying to use login.

Can you describe in more detail what you tried to do, and what didn't seem to work?

Thanks @tjwebb for the quick reply.  When I use the route 'auth/local/:callback'  by calling 'auth/local/login' it should hit the service/protocols/local.js login export, however when the request get's routed through services/passport.js the login action is missing, causing it to return "Invalid Action."  I could be wrong, but in the current code base, there is no way to preform a passport local login which should look like this:
     else if (action === 'login' && !req.user) {
        this.protocols.local.login(req, res, next);
      }

I can verify that this works:
// api/services/passport.js

var _ = require('lodash');
var _super = require('sails-permissions/api/services/passport');

function passport () { }

passport.prototype = Object.create(_super);
_.extend(passport.prototype, {

  // Extend with custom logic here by adding additional fields and methods,
  // and/or overriding methods in the superclass.

  /**
   * For example:
   *
   * foo: function (bar) {
   *   bar.x = 1;
   *   bar.y = 2;
   *   return _super.foo.call(this, bar);
   * }
   */

  callback: function (req, res, next) {
    var provider = req.param('provider', 'local');
    var action = req.param('action');

    // Passport.js wasn't really built for local user registration, but it's nice
    // having it tied into everything else.
    if (provider === 'local' && action !== undefined) {
      if (action === 'register' && !req.user) {
        this.protocols.local.register(req, res, next);
      }
      else if (action === 'login' && !req.user) {
        this.protocols.local.login(req, res, next);
      }
      else if (action === 'connect' && req.user) {
        this.protocols.local.connect(req, res, next);
      }
      else if (action === 'disconnect' && req.user) {
        this.protocols.local.disconnect(req, res, next);
      }
      else {
        next(new Error('Invalid action'));
      }
    } else {
      if (action === 'disconnect' && req.user) {
        this.disconnect(req, res, next) ;
      } else {
        // The provider will redirect the user to this URL after approval. Finish
        // the authentication process by attempting to obtain an access token. If
        // access was granted, the user will be logged in. Otherwise, authentication
        // has failed.
        this.authenticate(provider, next)(req, res, req.next);
      }
    }
  }

});

module.exports = new passport();

It just overrides the default callback method.  I hope that helps in your investigation.

Hey Scott...The unit tests in this file show you how to authenticate: https://github.com/tjwebb/sails-auth/blob/master/test/unit/controllers/AuthController.test.js

Oh snap @bgulotta thanks man, I'll give it a go.

@bgulotta is correct, you can just point a login form to /auth/local and login works. My initial assumption was wrong about the missing login function.

Hi guys !
I wonder when action becomes "login" as it sends me undefined all the time ?
  var action = req.param('action');

  if (action === 'register') {
    res.redirect('/register');
  }
  else if (action === 'login') {
    res.redirect('/login');
  }
  else if (action === 'disconnect') {
    res.redirect('back');
  }
  else {
    // make sure the server always returns a response to the client
    // i.e passport-local bad username/email or password
    res.forbidden();
  }


03/04/2021 Meeting

Hi @bpbond
I would like to discuss R coding optimization during tomorrow's meeting. Particularly the following items:

Script efficiency and clarity: processing raw data files, eliminating code duplication, and manipulating large data sets
Reshaping data frames for efficient plotting
Converting .json files into .txt files
Creating soil depth profile graphs using geom_line

We can use the TEROS data files as an example if that works for you. I have uploaded all of the raw TEROS data files (archived monthly) to TEMPEST/Data/Soil VWC, T, and EC (TEROS12)/teros12_data/Raw Data/. The files are separated based on the data logger ID. I also included the current data since the last archived file was prior to the network maintenance we just completed (note this is not available for PNNL11 since there are still some issues with this logger). Finally, there is also a file - "TEMPEST_TEROS_Network_Location&ID.csv" - that provides the data table channel for each sensor.
Please feel free to revise/add items to this agenda :-)

OK, a code-not-science meeting, sounds good :)


Enable private IP by default

This PR updates the metadata-service module to make make assign_public_ip consume value from variables and default to private IP.

Thanks for the PR! Can you make formatting tweaks and doc line suggested by the linter there https://github.com/outerbounds/terraform-aws-metaflow/runs/7752331542?check_suite_focus=true, otherwise LGTM!


Upgrade Node.js for security fixes #security-nodejs-20160209

Please upgrade Node.js to v0.12.10, v4.3.0, v5.6.0, or newer, to address the security issues listed here:
https://groups.google.com/forum/#!topic/nodejs-sec/G8IA0G4uA88.
Due date for this request is 2016-02-26.
This update addresses the following issues:

CVE-2016-2086 Request Smuggling Vulnerability
CVE-2016-2216 Response Splitting Vulnerability
OpenSSL upgrades and improvements

Please acknowledge that you've received this request and that it makes sense.
If it's not applicable to your repo, let me know so I can fix my list.
Thank you!

node version 4.3.1


Request Money - Unexpected error occurs in IOU when requesting money twice through chat.

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Click on the plus sign.
Select "New Chat" and search for email.
Click on plus sign > Request Money > add desired numbers and click Next.
Observe that nothing is previewed, then repeat step 3 and go to IOU.
Observe unexpected errors in IOU.

Expected Result:
No unexpected error should occur when requesting money through chat.
Actual Result:
An unexpected error occurs in IOU when requesting money twice through chat.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

Version Number: 1.3.30-5
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/93399543/753f58c1-24ff-41d3-ac7c-52912ac596af
https://github.com/Expensify/App/assets/93399543/578408fc-c3d5-44c8-a95b-5cc4d4cb9d8c
Expensify/Expensify Issue URL:
Issue reported by: @tewodrosGirmaA
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1687416755208539
View all open jobs on GitHub

Backend is responding with this

Dupe https://github.com/Expensify/App/issues/21208

Hello,  @sophiepintoraetz, I believe the root cause may not be the same. When I press the plus sign and request money, it works fine. However, in my case, the issue occurs when I request money inside a new chat and try to do it twice. I don't think this is the same root cause. I am willing to help if needed, but if you cannot reproduce the issue, please let me know. If you are not convinced, it's okay to leave it as closed.

@sophiepintoraetz  Additional videos
screen-capture (66).webm

even nothing comes on the preview  after splitting the bill inside the new chat


Create links between Angular and React Platform versions on target, disease, and drug profile pages

For our 20.06 release, we will also release the alpha branch of the React rewrite project. To ensure that users can toggle between the classic Angular and modern React views, we need to update the layout of the target, disease, and drug profile pages in the Angular application. As such, can we please update the target HTML template, disease HTML template , and drug summary HTML template files with the following notification?
Important Notice:
We are currently redesigning and rebuilding the Open Targets Platform with new features.
For a preview of the new Platform interface, please see the new profile page for <entity_name>
Can we please update <entity_name> with either the HGNC symbol, disease name, or drug name value?
To style the component, can we please set the following:
background-colour: #FFFFCC
padding: 20px
I also set a margin-top:20px to separate the navigation bar and notification.
For the link, details will be confirmed once the alpha branch has been deployed.
See below for samples for each page:
Target profile page

Disease profile page

Drug profile page

Ticket closed as PR merged and pushed to production


DS-1028 Implementation of CAS (Single Sign-On) authentication for DSpace

The first patch was formerly implemented by Kaboré Wendin-Malegdé Patrick at JIRA (https://jira.duraspace.org/browse/DS-1028).
This first version was done for DSpace 1.7.2, afterwards user kgunn at JIRA did some arrangements to make it work with DSpace 1.8.2 and CAS 3.1.x
and now I've been able to make a 'remix' of both solutions to make it work with DSpace 3.1 and CAS 3.5.x.
Hopefully, this patch will be officially implemented in subsequent DSpace versions as an additional authentication method.

For  org.jasig.cas.client.validation used in CASAuthentication.java I needed to add
        <dependency>
            <groupId>org.jasig.cas</groupId>
            <artifactId>cas-client-core</artifactId>
            <version>3.1</version>
         </dependency>

to dspace-api/pom.xml
I made the CAS logout conditional on the availability of the #cas.logout.url config setting

Closing as outdated/obsolete (significant merge conflicts, would need recreating). Please resubmit if you are interested in helping move this forward. Thanks!


A few formatting fixes

The more important thing here is the first commit, which fixes the documentation formatting. Before:

After:

Oh my, it looks sweet now, thanks!
@homu r+

:pushpin: Commit 32540b6 has been approved by kvark

:hourglass: Testing commit 32540b6 with merge 4db07e9...

:sunny: Test successful - status


Add support for readonly and featured field functions

As discussed in #103 this PR adds support to use a callback function to modify the behavior of the "featured" and "readonly" field.

Thank you!


🐛 Use shutil.move instead of Path.rename

https://github.com/laminlabs/pfizer-lamin-usage/issues/45

Thanks, Sergei!
Just: we should always add comments when do this. I've added comments in other places because when I read this code I'm otherwise like: "why don't we use rename?"


npm audit fix

fixes #25

storybook is broken...

Thank you for your PR.
We will also check the cause (npm run storybook).


Should we clarify the backwards compatibility objective?

This question is motivated by discussions at a recent WMO workshop discussing a pathway to increased future use of CF by the WMO. The issue of backward compatibility is important to the WMO: they accept that CF will evolve in ways which are dictated by the established rules and mechanisms, but want some assurances that anything the implement based on CF will not be undermined by future changes to CF. In principle this is can be guaranteed through our commitment to backwards compatibility, but there is a loophole in the form of a slight divergence between practise and the ideal we express.
The slight loophole is reflected in the 8 attributes which had no meaning in CF-1.0 but have been assigned meaning in CF-1.7: actual_range, cf_role, computed_standard_name, external_variables, feature_types, flag_masks, instance_dimension, sample_dimension. The rate of addition of new attributes is agreeably slow, and the chances of a conflict with pre-existing usage are low. Nevertheless, it is clear that we do not have any mechanism or intention of checking that the attribute in question has not been used differently in pre-existing CF compliant netcdf files. That is, we believe that any usage of the 35 attributes defined in CF-1.0 which complies with CF-1.0 is compliant with CF-1.7, but usage of, for instance, flag_masks which complied (by default) with CF-1.0 may be non-compliant with CF-1.7.
In other words, the check on backwards compatibility mentioned in the white paper on maintaining and advancing the standard only applies to previously defined attributes.
First question: is the white paper the right place to look for a statement of our commitment to backwards compatibility? It is mentioned in section 2.3 of that document.
I don't think we should change our practise (I don't see any feasible alternative here), but, in order to avoid potential disappointment when dealing with organisations such as the WMO which are liable to take rigid interpretations of commitments we make, I feel there is a need of a caveat needed in the way we claim backwards compatibility.

It seems to me that this is precisely the point of naming the version of CF used in the Conventions attribute. If you named CF 1.0 in a file, then nothing past CF 1.0 holds for that file. What is the scenario under which an actual problem arises?

Here is an example:
Someone writes a CF 1.7 compatible file and includes an attribute (not currently described by the CF convention) named frequency, which identifies the sampling frequency for data included in the file according to a controlled vocabulary (e.g., "hourly", "daily", "monthly").  The dataset is written without defining the Conventions attribute.
Now suppose at some point in the future the CF community (which may be unaware of the file described above) decides it would like to enhance the CF conventions by including an attribute named frequency with a controlled vocabulary that includes "hour", "day", "month", "year".  The CF checker would have to be able to check whether the assigned value for frequency was consistent with the controlled vocabulary.  Suppose this were release CF 1.22
If this updated CF checker were run on the file described in the first paragraph above, which was produced before the enhancement to CF, the checker would find the file to be non-compliant, when it should find it compliant under CF 1.7, but non-compliant under CF1.22.
We could perform a proper check on the sample file if the Conventions attribute were required.  Then the checker could perform different checks depending on the which release was specified there.  (Note that currently the Conventions attribute is only "recommended", not "required").
Requiring the Conventions attribute doesn't prevent all confusion, however.  Users would have to be aware that something like frequency has a standardized interpretation, as far as CF is concerned, only if the Conventions attribute specifies a version of 1.22 or later.  A frequency attribute written before 1.22 might be interpreted in an entirely different way (unconstrained by CF).

I'm in agreement with @JimBiardCics regarding the purpose of the "version". At the CF meetings at summer ESIP, there was a suggestion to switch to using semantic versioning, but that has not been adopted.
The following are just my how I was thinking regarding this:
When thinking about this issue... I eventually decided that CF is not backwards or forwards compatible with itself, but might be backwards compatible with COARDS, though I don't know enough about COARDS to really conclude this.
For the purposes of the WMO, I don't think "backwards compatible" is a promise that can be made to them. The CF conventions are a community and essentially "living standard" which is always (slowly) changing in response to user request and needs. I think if the WMO wants to adopt a "strict" version of this, they would need to publish that themselves or at least specify an exact CF version.
To make this promise I would imagine the following would need to happen:

Frozen data model (#159), I've heard many people say at meetings that CF is not explicitly tied to netCDF as a data format, however, almost all of the CF documentation talks about netcdf as the data format it uses.
Since features outside of "netcdf classic" have already been added (e.g. strings, groups), then #191 would need to be resolved. Since most of the features are available in netCDF4 anyway, I imagine it is a "how" and "when" these are added to CF, not an "if".
Either a commitment to never add new standardized attributes to CF, or disallow the use of non standardized attributes in files claiming to be CF.

Since the "standard_name" list isn't tied to a specific version of CF, they do have some tacit agreement to never remove or change the definition of an existing name in a non backwards compatible way.

Thanks for those comments. The case outlined by Karl illustrates the point I was concerned with.
In response to Andrew (@DocOtak), I'd just like to clarify that I'm trying to clarify the existing policy on backwards compatibility in order to avoid confusion in our conversation with WMO, I don't see any need to change it for them change it for them.
Jonathan (@JonathanGregory ) often refers to backward compatibility, but it appears there are different views on the subject. My understanding was that:

(a) Future modifications of CF are intended to preserve backward compatibility so that files which comply with the current version will continue to comply with future versions;

(b) The intention is that software which is designed to work with the current version of CF should automatically function with earlier versions.

It is clear that Andrew and Jim disagree with (a), but I'm pretty sure it was a view expressed by members of the CF Governance Panel to the WMO representatives at the meeting last week. Did I misunderstand this (@JonathanGregory )?

Dear @martinjuckes and all
I agree that CF is already backwards-incompatible in the way illustrated by Karl's example. That is similar to what we discussed as "extensions" with the WMO; an extension e.g. a new attribute may conform to the present CF but become incompatible with a future version of CF.
I believe that, so far, CF versions are backwards-compatible in the narrower sense that any metadata which is defined according to explicitly stated conventions in any previous version also conforms with the present version. (This is what @martinjuckes says in his third paragraph.) I accept that what @JimBiardCics says ("If you named CF 1.0 in a file, then nothing past CF 1.0 holds for that file") is logical and workable, but I think that nonetheless we should continue to maintain backwards-compatibility (in the sense of this paragraph) whenever we can. This is because it's likely that there are many present and future users of CF who will read or write files using software which is not sensitive to the Conventions attribute. Of course, one can tell them they have no-one to blame but themselves if they use careless software, but it's more helpful to them, and to the value of CF, if we avoid causing hazards and problems when we can.
I don't advocate this kind of backwards-compatibility as a principle of CF design as strongly as some of our other ones (like not doing things without use cases) but I think it's worth adhering to if it doesn't impede progress. I agree it would be helpful to define what we mean by backwards-compatibility when stating this intention.
Cheers
Jonathan

I think @JonathanGregory has put it well. In slightly different words, I see backwards compatibility as:
A later version of CF will not make invalid a compliant usage of an earlier version of CF terms and forms.
Any stronger guarantee would put CF in such a straightjacket that we would be unable to develop it further.

For what it's worth I agree with @JimBiardCics 's sentiment - data encoded in CF-1.2 should be readable for a client aware of CF-1.5, but a CF-1.5 compliant file may not be readable for a client that only is capable of reading CF-1.2. And in any case any client should warn about the Conventions attribute if it finds one that it doesn't know how to interpret.
More backwards incompatibility isn't really necessary in my view; one can use the Conventions attribute to verify that one can read the data and that is in my view sufficient.

Whatever the meaning of "backward compatibility", I think we need to decide

how the CF checker should treat attributes that are added to a later version of the conventions, and
whether we want to make the Conventions attribute mandatory.

I recommend that

The Conventions attribute should become mandatory and include the CF version (in the form "CF-y.x", where y and x are integers).
The CF checker could assume any file without a Conventions attribute might only be compliant with versions of the conventions promulgated prior to the one when Conventions became mandatory.
As new attributes become added to CF (which might have names conflicting with attribute names in existing CF-conforming files, but now defined differently by CF), these new attributes would be checked by the CF checker only if the Conventions attribute indicates the file conforms to a CF version where these attributes are described.  If the Conventions attribute is undefined or indicates a CF version earlier than when the attribute was added to the conventions, the CF checker would not check the attribute for conformance and not raise an error.  (In this case conformance would be assured only with CF versions appearing before the introduction of the new attribute.)

Hello Karl, Daniel,
I agree with recommendations 1. and 2. above, but, in 3. I think what we need is already covered by the CF checker.
Currently (v3.1.1 on my laptop), the checker uses the latest conventions version by default. A warning is issued if the Conventions attribute is either absent of different from the current. You can use the command line to specify that checks are against either the version specified in the file or a specific version entered on the command line (presumably this would be useful if your software is expecting a specific version). That is, the user has some flexibility to determine what version of the Convention is checked against. [@RosalynHatcher : is this an accurate description of how the checker deals with the Conventions attribute?].
There would be a need to update some of the warning message. E.g. if there is no Conventions attribute in the file, this warning is given:

WARN: (2.6.1): No 'Conventions' attribute present

Under the proposed changes, an absent Conventions attribute would be either an error under the latest convention or a unspecified version in a file which complies with an earlier version. For checks carried out under the new rules, something along the lines of the following might work:

ERROR: (2.x.y): 'Conventions' attribute absent. This attribute is required in versions 1.8 and later. The file may comply with earlier versions of the CF Convention. Use the '-v' flag if you want to check compliance with a different version.

...data encoded in CF-1.2 should be readable for a client aware of CF-1.5, but a CF-1.5 compliant file may not be readable for a client that only is capable of reading CF-1.2.

I think a CF-1.5 compliant file should certainly be readable by a client written for CF-1.2; some new aspects of the standard will simply not be understood implicitly, but they won't break anything.

Are there any objections to proposing that the Conventions attribute become required?  I think the CF checker would be affected but probably not other software.

@taylor13 I think that sounds entirely reasonable.

I think this is a very good idea. It looks as though only changes in sections 1.3 (2nd paragraph) and 2.6.1 (1st paragraph) would be needed.
In the 1st paragraph of 2.6.1 there is also an obsolete reference to an FTP server where there used to be a collection of conventions documents: UNIDATA now just maintains a website pointing to online resources for each convention. This could be cleaned up at the same time.
Karl (@taylor13): do you think it would be appropriate to include (in section 2.6.1) some clarification of the relationship between conventions versions? E.g., along the line of Jim's phrase above: A later version of CF will not make invalid a compliant usage of an earlier version of CF terms and forms.

Hi all,
I've taken the liberty of putting together a pull request that implements these changes. My survey of the text leads me to believe that this does not introduce any inconsistencies. You can see the text in PR #208. How do you find it?
Daniel

thanks, @erget .  Is the following statement really what we want to say?
However, later versions of the CF Conventions will not make invalid a compliant usage of
earlier versions of the CF terms and forms.

Files written prior to version 1.8, for example would be non-compliant with 1.8 if they didn't include the Conventions attribute, although they would remain compliant with earlier versions of the conventions.  Is that consistent with the above statement?

My interpretation is that a file without the Conventions attribute set to 1.8 would only be compliant with earlier versions anyway, as this would make the Conventions attribute mandatory from 1.8. However, they would still be compliant with the version that was used to write them.
The intent of the text is to state that a client "aware" e.g. of CF-1.20 should be able to read a file written using CF-1.8, because the meaning of attributes used in CF-1.8, e.g. standard_name, would not be replaced by a new attribute with a different meaning. If we did decide to abandon standard_name (which I am definitely not advocating! This is simply a thought experiment) we could only do so by discontinuing its use and instead using an attribute with a different name.

Hi Daniel,
Thanks for taking the initiative.
(1) The requirement should be that the Conventions attribute contains the string CF-1.8 -- it can also contain references to additional conventions.
(2) As we are specifying CF-1.8, I think we should provide either a persistent link to that version (e.g. a DOI if that is agreed in #127 ) or just a link to the cfconventions.org. Linking to the "latest" page will be misleading when 1.8 is no-longer the latest.
(3) Putting the discussion about relationships between different CF versions after the paragraph about including references to other conventions looks confusing to me. I would add the sentence from Jim there, adjusted to fit the paragraph. E.g.

This version of the CF Convention (and any subsequent versions) can be found on cfconventions.org. Subsequent versions of the CF Conventions will not make invalid a compliant usage of this and earlier versions of the CF terms and forms.

(4) I don't see the need to refer to putting multiple CF version numbers in the Conventions attribute .. if we refer to this practice, I think we should ban it. Is there a use-case?
(5) I would also leave out the text saying software developed for this version won't necessarily understand new features -- surely that is self-evident?

@martinjuckes point by point:
(1) - right you are, I've changd it.
(2) - agreed. I'm a bit confused about the webpage because I thought it was possible to also find older versions of the CF Conventions there, but I only find the latest one and the current working draft. We should at least link back to the GitHub repository if we want to keep it this way. This is a different issue and probably belongs to the larger discussion @ethanrd was interested in starting concerning reworking the webpage. For now I've linked straight back to http://cfconventions.org/
(3) - I get what you're saying here, I've adopted roughly that wording and moved it directly behind the sentence linking back to the webpage.
(4) - I definitely don't see one, I'd been extrapolating a desire to have some clarity here from the discussion in this thread. I'm happy to remove it and have done so.
(5) - see (4).

@erget : thanks. On point (2), there is a full list of past versions here: http://cfconventions.org/documents.html -- so you could use that instead.

Yes, but I don't see a link to it from the other pages so it's kind of an orphan (unless I'm just not finding it - I'm at a workshop right now so I've had limited time to dig for the URL). Therefore I'd prefer to leave the URL pointing to the main page, especially in light of the fact that the website may be restructured anyway.
Note to self that if this text is accepted, am update to the Conformance document will be required.

OK. The link from the main page is in the "Documents" tab at the top ... it could be clearer. There may be a case for rationalising the relationship between latest.html and documents.html, and how they are linked to -- but that would be for a new issue after this is completed.

Agreed. Now I see why I wasn't able to find the link - when viewing the website on a small device, such as my phone in this case, the tab bar at the top Isn't shown! It's obvious from a desktop but not from tiny screens. I agree though that this is a separate issue from this one.

Dear Daniel, Martin et al.
Thanks for this proposal. I support the proposed text changes. I have a small suggestion, that in both places it could say "Files that follow this version of the CF Conventions" i.e. inserting this version. Other versions would not have to say "CF-1.8". It may be self-evident but it's useful to be explicit, especially to avoid implying that all existing files written for previous versions without the Conventions attribute have become invalid.
I think the definition stated of backwards-incompatibility is what we can practically adhere to. Nan suggested it could work the other way e.g. "a CF-1.5 compliant file should certainly be readable by a client written for CF-1.2". I agree that this holds for attributes that didn't exist in CF-1.2, which should be ignored silently, since that is not an error. However there are many kinds of change we could need to make that would break this kind of compatibility. For example (1) we generalised the grid_mapping attribute from its original form to its present form, which would probably not be compatible with the expectations of earlier software, (2) if 2D lat and lon auxiliary coordinate variable become optional provided that a grid_mapping is provided, that would present problems for earlier software. I think it would be too restrictive to adhere to this kind of backwards-compatibility, which is not proposed in the current text.
Best wishes, Jonathan

@JonathanGregory agreed, I've updated the text.

Strongly support the changes as most recently discussed, including Jonathan's point. Requiring the version is a huge improvement.
Regarding the full list of past versions at http://cfconventions.org/documents.html, even if there is no link to it that's a web site deficiency. I think it's important to link directly to the actual list of versions, that is a central resource for CF that should never go away.
Sorry if you may have made this comment moot already

I've not had time to take this issue in, but I notice that it does not have a moderator assigned. Can someone who's taken part summarize the discussion and suggest whether it is concluded or not? I'll gladly assign a moderator who wants to be identified as such!

I've added a summary. It's also worth noting that an update to the CF Checker is underway that would ameliorate some of the issues noted above. I noticed that some changes to the Conformance document had already been made but I've updated these to what I consider a clearer formulation.
With no further objections I propose to merge the corresponding pull request in 2 weeks, on 2020-01-13. Please shout if you don't agree with this plan.
On a separate note I agree with @DocOtak's comment, points (1) and (2), and hope that we resolve those soon.

PS: I've also updated the original post to include the full quote of @martinjuckes's proposal plus my summary. His text is unchanged and quoted; everything else is from me.

Fantastic. A model to follow I think.
In case others have not seen it, any edited comment has a drop down to access the history of that comment as well. The summary comment of this issue says it was lasted edited by @erget and has the option to see those changes.

I'm confused about one line, sorry if this is a basic misunderstanding:

Subsequent versions of the CF Conventions will not make invalid a compliant usage of this or earlier versions of the CF terms and forms.

I understand we want/expect any CF tool to be able to read CF files from previous CF versions, so it makes sense that we don't want to invalidate those earlier files.
But if I use an attribute name in my CF 1.8 compliant file, and then later (say CF 1.9) the CF standard (unknowingly of course) uses that same attribute for a specific purpose (incompatible with the purpose I used it for in my 1.8-compliant file), how will that not make my compliant usage invalid? How is this accidental re-purposing avoidable?
I just can't figure out how any tools would implement that, without having a whole bunch of historical libraries for reading files from older versions of CF.

@graybeal this gets to the heart of the discussion thus far in this thread. You're right, if somebody uses an attribute we don't know about, there's no way to guarantee that we won't reserve that attribute for something else in the future.
My understanding of that sentence is that we won't invalidate previous practices from the CF Conventions - anything that users do outside of the CF Conventions, like using their own attributes, is fine, but of course as you say we can't know if we break that. What we are saying is that we don't want to break uses of attributes that are governed by CF by changing their use in future versions.

@graybeal I read and understand the sentence in question this way:
A file that is compliant with a particular version of CF and contains a declaration of the CF version used is not made invalid by any later change to CF that would make the same file non-compliant if it was declared to use that later version. The fact that a change made in CF 1.9 invalidates a standard or non-standard practice in a file built using CF 1.8 doesn't make the CF 1.8 - compliant file invalid, as long as I have a Conventions attribute in the file that declares CF-1.8.

Dear all,
Thanks for the productive conversation around this topic - consensus seems to have been reached and therefore as noted previously I am merging this request.


HMS Maps are not rendering in huawei cloud device and hms core installed google play service devices

I'm trying to use Huawei maps in react native application for android support, After making necessary changes based on hms map kit demo, I'm unable to load the maps in Huawei cloud simulator and hms core with google play service devices as well. I'm able to see only a white screen on the map. Please let me know any changes to be done to resolve the issue.

Platform: React-Native 0.63.4 , React 16.13.1
Kit: [Map ]
Kit Version [5.0.1-300]
OS Version [Android 10, Android 11]
Android Studio version  [ Android Studio  4.0.1]

Hi,
Can you see the map in other devices? (other than cloud devices and the ones with google play services)
Also can you also run the native demo in these devices with same configurations (especially agconnect and keystore configurations) so that we can understand the source of the problem?

Thanks.  let me check in device

Did you find a solution for this?


BAC-296 updated sdk with the new groups parameter for evaluate

i have updated the clarify go sdk to support the new evaluate parameter groups. i have also updated some names to match the changes introduced in BAC-282. lastly i have updated the automation and examples packages to use the new builder style EvaluateRequest type

thank you sindre, i'll be back with something corrected

Split in two documents, but try to follow this commit-style:

https://searis.slite.com/app/docs/xvLCQUTVkH
https://searis.slite.com/app/docs/qZbg75gJge

E.g.
BAC-296: update Client.Evaluate call to version 1.2alpha1 (breaking)
<Blank line>
<Longer description, including list all breaking changes>


Replaced hardcoded '/opt' in project_path in spark job with PROJECT_HOME env

Replaced hardcoded '/opt' in project_path in spark job with PROJECT_HOME environment variable which is already set in cluster init script.
Resolves #128

Keep in mind:

[ ] Documentation updates
[x] Changelog updates

@lmaczulajtys Could you please merge the current develop into your branch? It should fix the failed tests issue

@szczeles Done.

Linting and tests suceeded, merging into develop. Thanks, @lmaczulajtys !


Centralizes localized category string for the execution plan category

This PR centralizes a category string for execution plan actions.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.0007%) to 42.166%

Totals

Change from base Build<PHONE_NUMBER>:
0.0007%

Covered Lines:
28199

Relevant Lines:
62422

💛  - Coveralls