choice filter in repeat shows incorrect options for first repeat if multiple repeat instances are created

Describe the bug
Itemsets (choice filter options) in the first repeat in a series of multiple repeat instances are not created correctly.
To Reproduce

Stick
RCFT1.xml.txt
in test/temp, change extension to xml and open http://localhost:8005/?xform=RCFT1.xml
Create second repeat
Enter 3 in text input for second repeat
See how the choices in the first repeat changed.

Expected behavior
The itemset logic within a repeat should be isolated and not affect other repeat instances.
Screenshots

Browser and OS (please complete the following information):
Enketo Core 6.0.0. It looks like this bug was introduced a long time ago between versions 5.15.4 and 5.15.5.

I will work on a fix.

culprit: https://github.com/enketo/enketo-core/commit/33800fcfc58b545152e7d373817d10dec5b3bcb8

[x] add test for bug
[x] add tests for new dom-utils functions

I'm reviewing #819. I can reproduce the issue with the steps you provided, but at first I did not think I could, due to an unrelated (to this bug) behavior. So I wanted to ask about this for clarification:

Enter 3 in text input for second repeat

When I first did this, I did not see a radio button appear at all. Curious about the behavior (and issues with repeats generally), I clicked the repeat's + button to add another repeat. This is when I saw:

The radio was added in both existing repeats as described.
No new repeat was added.

Seeing this, my first thought was that adding the radios was performed on the NewRepeat (or AddRepeat) event, and that adding a repeat was suppressed by that somehow. But trying again, I now understand that:

The radio is not added until a native change event, which doesn't fire until the field loses focus.
Clicking (technically mousedown, and presumably also pointerdown) the + button (or anywhere) causes the field to lose focus, thereby triggering change, which is why the radios are added then.
The + button receives focus but, because the radios were added the + button is now further down the page and never receives a mouseup/click.

This is all generally surprising behavior to me, is it expected? Is there a reason we wouldn't want to use an input event (possibly debounced to prevent jank) to provide visual feedback while typing?

Thanks @eyelidlessness! The reason for choosing change is that updating a model value upon each keypress (e.g. in a long text field or when scrolling up and down through a number input field), would trigger the whole evaluation cascade of all the calculations, constraints, relevants etc that depend on that value which can be a performance issue. So if there are 20 dependent evaluations those would evaluated 10 times in quick succession if a text value is 10 characters.
One exception that comes to mind are the drawing/signature widgets. These are saved multiple times while drawing but are throttled. I don't quite remember the exact reason for this. Thankfully those questions are very unlikely to have dependent logic.

Thanks for the quick reply @MartijnR! That all makes sense conceptually. Is there an example form with particularly expensive calculations, or could you describe what cocktail of cascades I could use to produce one? It would be good to have for benchmarking/stress testing in general. But I'd also like to take a look at whether throttled input is feasible (or perhaps MutationObserver, which is particularly intended for performance-sensitive use cases). I think it could be a pretty big UX improvement.

We've got this: https://github.com/enketo/enketo-core-performance-monitor, but as you can see in the current graph it has challenges.... Unfortunately those forms are 1) not public, and I no longer even know who owns them, and 2) they don't measure performance during form traversal (only loading, validating, transforming).
The kind of form that would present a challenge is where an itemset querying a huge secondary instance is updated every time a value changes, and perhaps combined with a relevant condition that shows/hides a group, updates calculations, setvalues, constraints. One of the directly linked calculations could also have dependent calculations etc.
Yes, it's worth considering throttling an 'input' event perhaps, but I have a somewhat uneasy feeling about the consequences. It looks like XForms leave this up to us: https://www.w3.org/TR/xforms11/#evt-valueChanged. One issue could be timestamps with setvalue/xforms-value-changed if they are wrapped in once(), like once(now()), and in the future perhaps also the audit functionality. Actually, it would be good to check what ODK Collect does.

One of the big advantages of pages mode (the Collect default) is that page flip is a very natural place to commit values and trigger reevaluation.
This decision point is relevant to field-lists in Collect. We made the decision to evaluate with every new character of input which is generally what users expect. In my experience, it’s not terribly common for large evaluation chains to be based on free text input. They’re typically based on selects. People do use free text to narrow down choices in a select (same as the search/autocomplete appearance). That can be slow to do character by character but the upside is that often the list is sufficiently filtered before typing the whole query.
@MartijnR is absolutely right that recomputation at every character is not compatible with once(). I think we’ve always been able to find a better way to get the same result with a value-change action or something like that.


decimal.InvalidOperation with small numbers

Trying to use small numbers like 1.09701 doesnt work, I tried scaling and everything but I always get a decimal conversion error no matter what I try
Error message(s):
Traceback (most recent call last):
File "c:/Spagetti Code Collection/Ultimate-Market-Oracle/process_trading_zones.py", line 45, in detect_patterns
coordinates_list, new_dataframe = strategy.detect_pattern(ohlc_data=self.ohlc_data)
File "c:\Spagetti Code Collection\Ultimate-Market-Oracle\patterns\zigzag_2_0.py", line 56, in detect_pattern
zigzag_data = [{'date': x.date, 'zig_zag': x.zig_zag, 'point_type': x.point_type} for x in result]
File "c:\Spagetti Code Collection\Ultimate-Market-Oracle\patterns\zigzag_2_0.py", line 56, in
zigzag_data = [{'date': x.date, 'zig_zag': x.zig_zag, 'point_type': x.point_type} for x in result]
File "C:\Spagetti Code Collection\Ultimate-Market-Oracle\venv\lib\site-packages\stock_indicators\indicators\zig_zag.py", line 51, in zig_zag
return to_pydecimal(self._csdata.ZigZag)
File "C:\Spagetti Code Collection\Ultimate-Market-Oracle\venv\lib\site-packages\stock_indicators_cstypes\decimal.py", line 36, in to_pydecimal
return PyDecimal(str(cs_decimal))
decimal.InvalidOperation: [<class 'decimal.ConversionSyntax'>]

Possibly related to https://github.com/facioquo/stock-indicators-python/issues/382#issuecomment-2125019121

@youngpake
Sorry for inconvenient. It looks like locale setting does not match with your Python environment.
To investigate it, could you give me the results after running the below?
On Python:
from decimal import Decimal
value = Decimal(12.345)
print(value) # case 1
print('{:n}'.format(value)) # case 2
print(format(value, 'n')) # case 3

import locale
print(locale.getlocale(locale.LC_ALL))
print(locale.localeconv())

On your terminal:
locale

12.3450000000000006394884621840901672840118408203125
12.3450000000000006394884621840901672840118408203125
12.3450000000000006394884621840901672840118408203125
Traceback (most recent call last):
File "test.py", line 8, in
print(locale.getlocale(locale.LC_ALL))
File "C:\Users\wytse\AppData\Local\Programs\Python\Python38\lib\locale.py", line 590, in getlocale
raise TypeError('category LC_ALL is not supported')
TypeError: category LC_ALL is not supported

im using 3.8, could that be the problem?

@youngpake
I don't think the Python version is the problem.
oh.. you are using Windows system. I'm sorry but could you print the zigzag results using the code below?
I'm not using Windows system now, so It's hard to figure out.
for r in results:
      print(str(r.date) + ", " + str(r._csdata.ZigZag))

@youngpake
I've just made a quick patch, could you try with this one?

Patched version released on test PyPI. Please have a test and any feedback appreciated.
pip install -i https://test.pypi.org/simple/ stock-indicators==1.3.1.dev9

The patch finally has been released in v1.3.1.


Handle JavaParseException in SourceCode Extraction - #94

Handle java parse exception, by parsing the parent commit
Refactor ProcessMetricsCollector and RefactoringAnalyzer code parsing

You think getting the previous version is better than using a string based
algorithm to count lines? What if a change from one version to another is
significant? (Which is a possibility!)
I’d say in the catch, call CKs method that counts lines based on the string
!
On Sat, 7 Mar 2020 at 12:22, Jan Gerling<EMAIL_ADDRESS>wrote:

@jan-gerling https://github.com/jan-gerling requested your review on:
#99 https://github.com/refactoring-ai/predicting-refactoring-ml/pull/99
Handle JavaParseException in SourceCode Extraction - #94
https://github.com/refactoring-ai/predicting-refactoring-ml/issues/94.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/refactoring-ai/predicting-refactoring-ml/pull/99?email_source=notifications&email_token=AAAYTTDQKOUWLVWTFMOXIMTRGIU7RA5CNFSM4LDO3HZ2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOXE5PCNQ#event-3107647798,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYTTF3U4UOAZ3NCLVGESLRGIU7RANCNFSM4LDO3HZQ
.

--
Maurício Aniche
Delft University of Technology
http://www.mauricioaniche.com

You think getting the previous version is better than using a string based algorithm to count lines? What if a change from one version to another is significant? (Which is a possibility!) I’d say in the catch, call CKs method that counts lines based on the string !

I am not sure which CK method you are referring to and how that would be better in this case.


Build for production failing

Is there any guidance on why builds will fail to go into production?
We have tried many different ways of setting production. Currently its successfully building, running and zipping but nothing will set this to production.
/* eslint-disable no-undef */
const path = require('path');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const { VueLoaderPlugin } = require('vue-loader');
const isDevelopment = process.env.NODE_ENV === 'development';

const alias = {
  jQuery: path.resolve('./node_modules/jquery'),
  $: path.resolve('./node_modules/jquery'),
  vue: 'vue/dist/vue.js'
};

const part = {
  resolve: {
    alias,
    extensions: ['.js', '.css', '.json', '.vue']
  },
  module: {
    rules: [
      {
        test: /\.vue$/,
        loader: 'vue-loader'
      },
      {
        test: /.js$/,
        loader: 'babel-loader',
        exclude: /node_modules/
      },
      {
        test: /.(png|jpg|jpeg|gif|svg|woff|woff2|ttf|eot)$/,
        loader: 'url-loader',
        //include: path.join(__dirname, ''),
        options: {
          publicPath: './',
          limit: 10000
        }
      },
      {
        test: /\.pcss$/,
        exclude: [ /node_modules/, /assets\/static/ ],
        use: [
          {
            loader: MiniCssExtractPlugin.loader,
            options: {
              // you can specify a publicPath here
              // by default it uses publicPath in webpackOptions.output
              // publicPath: '../',
              hmr: isDevelopment,
              sourceMap: isDevelopment,
            },
          },
          'style-loader',
          'css-loader',
          'vue-style-loader',
        ]
      }
    ]
  },
  plugins: [
    new VueLoaderPlugin(),
    new MiniCssExtractPlugin(),
  ]
};

const purgecss = require('@fullhuman/postcss-purgecss')({
  // Specify the paths to all of the template files in your project
  content: [
    './src/**/*.html',
    './src/**/*.liquid',
    './src/**/*.vue',
    './src/**/*.jsx'
  ],

  // Include any special characters you're using in this regular expression
  defaultExtractor: content => content.match(/[A-Za-z0-9-_:/]+/g) || []
});

module.exports =  {
  'webpack.extend': config => {
    return part;
  },
  'webpack.postcss.plugins': (config, defaultValue) => [
    require('tailwindcss'),
    require('autoprefixer'),
    require('cssnano')({
      preset: 'default',
    }),
    ...defaultValue,
    ...process.env.NODE_ENV === 'production' ? [purgecss] : []
  ]
};

Turns out this file does nothing. Removing it completely leaves the builds still working.

Gave up on this project folder and started a new one instead, it just wouldn't work. A new one is working albeit, not 100% of the time.


Can't reproduce the result using pytorch 0.4.1 branch

Thanks for reporting. I did not get a chance to take a look. Can you comment on why the issue is closed?

Thanks for reporting. I did not get a chance to take a look. Can you comment on why the issue is closed?

The  reason why i can't reproduce the result is same as #4. i set  the cnn eval mode and fix this problem.

Thanks for clarifying.


Label is hidden when value is false

When items=[true, false] and false is selected - the label of the selected item is hidden

That's not a bug but a feature :)
Whenever the label is false, it is hidden in the tag box ui.
It is meant to be used when specifying shortLabel for the tag ui, so it could show in the list but not in the box.


Allow building when there is no commit info for rustc

I was trying to build artichoke on my machine. However even though my rustc version matches the one in toolchain file, I was still getting an error:
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', artichoke-backend/build.rs:463:26
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::panicking::panic
   9: core::option::Option<T>::unwrap
             at /build/rust/src/rustc-1.42.0-src/src/libcore/macros/mod.rs:10
  10: build_script_build::release::compiler_version
             at artichoke-backend/build.rs:463
  11: build_script_build::release::build
             at artichoke-backend/build.rs:359
  12: build_script_build::main
             at artichoke-backend/build.rs:561
  13: std::rt::lang_start::{{closure}}
             at /build/rust/src/rustc-1.42.0-src/src/libstd/rt.rs:67
  14: std::panicking::try::do_call
  15: __rust_maybe_catch_panic
  16: std::rt::lang_start_internal
  17: std::rt::lang_start
             at /build/rust/src/rustc-1.42.0-src/src/libstd/rt.rs:67
  18: main
  19: __libc_start_main
  20: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Upon closer inspection I think this is because I have rust installed via package manager, not by rustup, and because of that I don't have info about commit hash of my rustc. I don't see why this would be blocking (i.e. why would I need specific version + installed via rustup), so I propose a fix to skip checking for commit hash when this information is not available.
Some additional context
> rustc --version
rustc 1.42.0

> uname -a
Linux brzask 5.5.13-arch2-1 #1 SMP PREEMPT Mon, 30 Mar 2020 20:42:41 +0000 x86_64 GNU/Linux

It looks like clippy wants that match statement structured as an if let

Force-pushed change requested by clippy.

(a bit unrelated: shouldn't this clippy by added to rake lint:all or mentioned in CONTRIBUTING.md? it caught me by surprise here)

I had left clippy out of rake lint:all because of bugs in the clippy and cargo integration that cause clippy to not run sometimes. I think this is being worked on, but I lost track of when it will land.

@katafrakt filed https://github.com/artichoke/artichoke/issues/638 to followup on adding clippy to the rake linter. Thanks for surfacing that gap.

(a bit unrelated: shouldn't this clippy by added to rake lint:all or mentioned in CONTRIBUTING.md? it caught me by surprise here)

This was fixed in GH-645.


Mobile comments - add the submit button to input

Only required on mbile.
Like they do on 3box:

Closing this. Finally got mobile to load and the send button is there


Configure certificate TTL

Please provide a description for what this PR is for: https://github.com/istio/istio/issues/21944.
Expose configuring SECRET_TTL as an installation option to allow operators to configure workload cert lifetime.
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ X] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

@lei-tang: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

gencheck_istio
dabbf037e1195c58c2ad6e56ea7e09e65c51f35c
link
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@lei-tang: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

gencheck_istio
dabbf037e1195c58c2ad6e56ea7e09e65c51f35c
link
/test gencheck_istio

unit-tests_istio
dabbf037e1195c58c2ad6e56ea7e09e65c51f35c
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@lei-tang: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

unit-tests_istio
dabbf037e1195c58c2ad6e56ea7e09e65c51f35c
link
/test unit-tests_istio

gencheck_istio
dabbf037e1195c58c2ad6e56ea7e09e65c51f35c
link
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

I don't see proxyMetadata in https://istio.io/docs/reference/config/istio.mesh.v1alpha1/#ProxyConfig ?

@lei-tang: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@weibohe I don't see proxyMetadata in the reference. Maybe we need to update it. But it can be set:
istioctl manifest apply --set values.global.tag=$TAG --set meshConfig.defaultConfig.proxyMetadata.SECRET_TTL=10
This sets the TTL on the client side.

Based on the review comments, this PR is closed for now.


Single valued enum is parsed as a broken reference

Search terms
Enum, Single value enum, Broken reference
Expected Behavior
Say I got this ts file, with an enum with only 1 value in it
export enum CoolEnum {
 FOO = 'FOO_VALUE',
}

export interface Response {
  x:  CoolEnum
}

I would expected the output to be:
{
  "id": 5,
  "name": "x",
  "kind": 1024,
  "kindString": "Property",
  "type": {
    "type": "reference",
    "id": 1,
    "name": "CoolEnum" // The reference name is CoolEnum.
  }
  ...
}

Actual Behavior
The output of is actually this:
{
  "id": 4,
  "name": "x",
  "kind": 1024,
  "kindString": "Property",
  "type": {
    "type": "reference",
    "id": 2,
    "name": "FOO" // It doesn't point into CoolEnum, it points to the *name* of the single value in the enum, by *reference*.
  }
  ...
}

if you think about it, it's structure would look like this :
export enum CoolEnum {
   FOO = 'FOO_VALUE',
}

export interface Response {
   x: FOO // That's the single enum values name, it not CoolEnum
}

Steps to reproduce the bug
This ts snippet is all you need, just use JSON as output.
Environment

Typedoc version: 0.22.7
TypeScript version: 4.1.6
Node.js version: 14.15.4
OS: macOS 10.15.7

Huh, well that's unexpected. I could argue it's not technically wrong to point to the single value, but it's certainly not the desired behavior... and the name ought to indicate that at least. I'd definitely rather have this use CoolEnum as the type.

Having spent more time looking at this... TypeDoc appears to be doing the right thing, at least based on my assumption that type.symbol for a reference type... points at the referenced symbol. If I look at the symbol ID of the type reference, it does actually point to FOO, not to CoolEnum. I'm leaning towards this being a bug in TypeScript... maybe I don't understand how references are resolved, but symbols work for everything else... I've posted a query in the compiler API chat that some TS team members look at, so might know more in a couple days.

@Gerrit0  Thanks ! really appreciate it.

Consensus there seemed to be that this was a bug in the compiler, I've filed https://github.com/microsoft/TypeScript/issues/46755. Will leave this open until that issue is appropriately labeled.

Based on the feedback from the TS issue, I think I'll mark this as wontfix - if someone submits a PR to TypeScript to change this, it'll automatically be picked up here. Until then, this feels like a very minor edge case that it isn't worth adding hacks to TypeDoc to try to fix.


added hooks project

This project is built with  --
1.React for the frontend
2. Firebase for backend and database management
3.  Chakra UI for a delightful user interface
4.  and React Router for seamless navigation.
features
1.User Authentication
2.Child and Elderly Profiles
3.Matching Algorithm
4.Real-time Updates
5.Messaging System
6.Responsive Design
7.Navigation

issue number?

Close #138

Ma'am what happened?
Why the repository wasn't merged..


US-210079 change UID, add custom opensearch.yml and install openssl

Description
[Describe what this change achieves]
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Can you please add more details about what the purpose of this change is and how you tested it?


Disable SQL server functionality

Given the CVEs in #438, it is insecure right now to cut a release with SQL server functionality, where a user would be able to exploit them.
This PR disables the SQL server implementation. which should make things secure until the remaining CVEs are addressed.

Maybe it is worth noting this needs to be reverted in a new or existing issue after the CVEs are addressed?

Sure, I will bump #438 with an overview of the ongoing CVE work


Example Request: Render Rich Text

@jpedroschmitz perhaps this is something we can add next week? 😉


Changes necessary for usage on Trezor

This is the result from cherry-picking the following upstream PRs (in this order) in their current state, see the PRs for details:

https://github.com/bitcoin-core/secp256k1/pull/566
https://github.com/bitcoin-core/secp256k1/pull/595
https://github.com/bitcoin-core/secp256k1/pull/596
https://github.com/bitcoin-core/secp256k1/pull/533
https://github.com/bitcoin-core/secp256k1/pull/587

cc @practicalswift: The reason I asked you to update https://github.com/bitcoin-core/secp256k1/pull/587 is that I needed the change here. Sorry, I didn't mention this, I hope you don't mind. :)

Forced pushed because I forgot to cherry-pick the (cosmetic) 76c7964 from  bitcoin-core/secp256k1#596, and I also added a zkp-specific follow-up commit on this commit.

Also missing 8558e3d from https://github.com/bitcoin-core/secp256k1/pull/595

Would be good to add ARG_CHECK_NO_RETURN(ctx != secp256k1_context_no_precomp); to secp256k1_cotnext_destroy as well as secp256k1_prealloc_destroy when cherry-picking 2ca27e2 from https://github.com/bitcoin-core/secp256k1/pull/595
I also have a bunch of spacing changes in a6add6c, also from https://github.com/bitcoin-core/secp256k1/pull/595, that you don't have. I think in this case I screwed up the cherry-pick and created a bigger diff than I needed to.

Would be good to add ARG_CHECK_NO_RETURN(ctx != secp256k1_context_no_precomp); to secp256k1_cotnext_destroy as well as secp256k1_prealloc_destroy when cherry-picking 2ca27e2 from bitcoin-core/secp256k1#595

This check is actually present in the current PR in secp256k1_preallocated_destroy (and secp256k1_context_destroy is also covered because it calls secp256k1_preallocated_destroy internally).
I'm addressing the other issues.

I added 8558e3d and a fixup from bitcoin-core/secp256k1#596, both just on top. I didn't squash or reorder to make sure you don't have to recreate it again from scratch. Let me know when I should squash.

ACK. Go ahead and squash.

done

ACK


Add LeafNode class

Currently, leaf node objects are being passed around as a list of dictionaries, but there seems to be a very clear outline in code for what a schema would look like for a LeafNode class.

Yes, this is a great chance to add standard Python classes or even Pydantic models to stop passing around these dicts everywhere.


Add remove module on runtime cause invalid advertisement known by peer

On advertisement update now will broadcast its new advertisement to peers


Provisioning setup - Tenant URL missing

Hi,
seems like the above tutorial is outdated when it comes to provisioning (Step 22).
I am required to enter a Tenant ID for Admin connection test.
Where can I find the Tenant ID?
Thanks,
Idan

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

ID: 8fa5814d-91e2-2f75-77e7-62a8597f340c
Version Independent ID: 458e93d7-a180-4c2f-5077-9b9d124d726a
Content: Tutorial: Azure Active Directory single sign-on (SSO) integration with Amazon Web Services (AWS)
Content Source: articles/active-directory/saas-apps/amazon-web-service-tutorial.md
Service: active-directory
Sub-service: saas-app-tutorial
GitHub Login: @jeevansd
Microsoft Alias: jeedes

@Idanshenhav  Thank you for your feedback. We will check and update on the same.

@Idanshenhav
You can go to Portal.azure.com > Azure Active Directory > Properties. The directory ID it shows there is your tennant ID. Alternatively, you can use the Powershell cmdlet Get-AzureADTenantDetail to get the Tenant details.
Also, we will assign the thread to the author to update the documentation.
@jeevansd Could this be updated on the document along with the screenshot ?

Hi,
thanks for the prompt response.
Actually I need the Tenant URL:

Where can I extract this info from?

@Idanshenhav I think you are seeing wrong UI for AWS User Provisioning. So can you please make sure that you are adding AWS gallery application? Then it will work correctly.

#please-close


Flutter [Web] Regression since Flutter-2.6-candiate.6 in iOS Keyboard popping up unwanted

Hi,
Since the release of Flutter-2.6-candidate.6 something has gone wrong that causes the iPad Web keyboard to show up unwanted and it can't seem to be dismissed without going back into the TextField. It doesn't appear to affect Android and I'm happy for this one to be user error or to find a workaround! :-)
Working:
Stable 2.5.0
2.6.0-5.1.pre / flutter-2.6-candidate.5
Broken:
flutter-2.6-candidate.6
2.6.0-6.0.pre.98
It seems there are only 32 commits between the two points so hopefully easy enough to isolate: https://github.com/flutter/flutter/compare/2.6.0-5.1.pre...flutter-2.6-candidate.6
Steps to repeat:

Start to type in Textfield
2A. Click on the Yellow and the keyboard should disappear and clicking around should not make it reappear
OR
2B. Start to scroll on the Switches and the keyboard will disappear and should NOT reappear when you toggle the switches

minimal code sample
import 'package:flutter/material.dart';
void main() {
runApp(const MyApp());
}
class MyApp extends StatelessWidget {
const MyApp({Key? key}) : super(key: key);
// This widget is the root of your application.
@override
Widget build(BuildContext context) {
return MaterialApp(
theme: ThemeData(
primarySwatch: Colors.blue,
),
home: MyHomePage(title: 'IOS keyboard popup'),
);
}
}
class MyHomePage extends StatefulWidget {
const MyHomePage({Key? key, required this.title}) : super(key: key);
final String title;
@override
State createState() => _MyHomePageState();
}
class _MyHomePageState extends State {
int _counter = 0;
String text = '';
List data = [];
bool switchState = false;
var textControllerAccessGroupName = TextEditingController()..text = '';
@override
Widget build(BuildContext context) {
for (int a = 0; a < 30; a++) {
_counter++;
data.add('Test' + _counter.toString());
}
return Scaffold(
  appBar: AppBar(
    title: Text(widget.title),
  ),
  body: GestureDetector(
    behavior: HitTestBehavior.opaque,
    onTap: () {
      FocusScope.of(context).unfocus();
    },
    child: Center(
      child: Column(
        children: [
          Container(
            alignment: AlignmentDirectional.center,
            height: 100,
            child: TextField(
              onChanged: (value) {
                setState(() {
                  text = value;
                });
              },
              controller: textControllerAccessGroupName,
              decoration: const InputDecoration(hintText: 'Enter Text Here'),
            ),
          ),
          Expanded(
            child: SingleChildScrollView(
              keyboardDismissBehavior: ScrollViewKeyboardDismissBehavior.onDrag,
              child: Column(
                  children: data.map((_) {
                return SizedBox(
                  width: 200,
                  height: 200,
                  child: Switch(
                    value: switchState,
                    onChanged: (value) {
                      setState(() {
                        switchState = value;
                      });
                    },
                  ),
                );
              }).toList()),
            ),
          ),
        ],
      ),
    ),
  ),
);

}
}

flutter doctor
[√] Flutter (Channel master, 2.6.0-6.0.pre.98, on Microsoft Windows [Version 10.0.17763.2114], locale en-IE)
    • Flutter version 2.6.0-6.0.pre.98 at C:\Code\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision b129fffa23 (85 minutes ago), 2021-09-15 11:51:47 +0200
    • Engine revision abb1980f65
    • Dart version 2.15.0 (build 2.15.0-96.0.dev)
[√] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
• Android SDK at C:\Users\Omega\AppData\Local\Android\sdk
• Platform android-30, build-tools 30.0.3
• Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
• Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6842174)
• All Android licenses accepted.
[√] Chrome - develop for the web
• CHROME_EXECUTABLE = C:\Code\FlutterTesting\ChromeCORS.bat
[√] Android Studio (version 2020.3)
• Android Studio at C:\Program Files\Android\Android Studio
• Flutter plugin can be installed from:
https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6842174)
[√] VS Code (version 1.60.0)
• VS Code at C:\Users\Omega\AppData\Local\Programs\Microsoft VS Code
• Flutter extension version 3.26.0
[√] Connected device (2 available)
• Chrome (web) • chrome • web-javascript • Google Chrome 93.0.4577.82
• Edge (web)   • edge   • web-javascript • Microsoft Edge 93.0.961.47
• No issues found!

Hi @zambetpentru, can you check if #90039 is similar to your issue?

Hi @danagbemava-nc ,
I just checked now and it seems to be different as you were able to reproduce that issue on 2.5.0 and the specific issue I have is fine on 2.5.0 and before that on flutter-2.4-candidate.2 and is related to a specific change between two tags on 2.6. I propose we please keep this one open and looked at separately.

@zambetpentru, do you experience it only in Safari or you experience in with other browsers as well?

Hi, I experience it with Safari and the latest version of Chrome (which I understand on ios is just a skin over Safari?)

Issue is reproducible with sample provided by author.
It may share a root cause with #90039 as the behaviours look similar imo.
Stable behaviour:
on Ipad, tapping outside the texfield will dismiss it, same for iphone.
However on iPhone, if you use the "Done" action that appears above the keyboard, they keyboard keeps popping back up.
Master behaviour:
on Ipad, tapping outside the textfield does not dismiss the keyboard, same for iPhone.
It disappears and pops back up again. However, on iPhone, after the textfield has lost focus, you can use the "Done" button to dismiss the keyboard.

 flutter doctor -v
[✓] Flutter (Channel master, 2.6.0-6.0.pre.114, on macOS 11.5.1 20G80 darwin-arm, locale en-GB)
    • Flutter version 2.6.0-6.0.pre.114 at /Users/nexus/dev/sdks/flutters
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision cd1892f04f (7 hours ago), 2021-09-15 22:17:02 -0700
    • Engine revision 5a09f16031
    • Dart version 2.15.0 (build 2.15.0-110.0.dev)

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/nexus/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.5.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • CocoaPods version 1.11.0

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2020.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[✓] VS Code (version 1.60.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.26.0

[✓] Connected device (5 available)
    • Nexus’ IPhone (mobile)       • 00008020-001875E83A38002E            • ios            • iOS 14.7.1 18G82
    • iPhone 12 (mobile)           • F2592D43-5FE3-46BB-8A2B-A38BA468DCE9 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-5 (simulator)
    • iPad Pro (9.7-inch) (mobile) • 64BCA5CE-E9C3-47AB-97F3-E0610A3A7E14 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-5 (simulator)
    • macOS (desktop)              • macos                                • darwin-arm64   • macOS 11.5.1 20G80 darwin-arm
    • Chrome (web)                 • chrome                               • web-javascript • Google Chrome 93.0.4577.82

• No issues found!

[✓] Flutter (Channel stable, 2.5.0, on macOS 11.5.1 20G80 darwin-arm, locale en-GB)
    • Flutter version 2.5.0 at /Users/nexus/dev/sdks/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 4cc385b4b8 (8 days ago), 2021-09-07 23:01:49 -0700
    • Engine revision f0826da7ef
    • Dart version 2.14.0

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/nexus/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.5.1, Build version 12E507
    • CocoaPods version 1.11.0

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2020.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[✓] VS Code (version 1.60.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.26.0

[✓] Connected device (5 available)
    • Nexus’ IPhone (mobile)       • 00008020-001875E83A38002E            • ios            • iOS 14.7.1 18G82
    • iPhone 12 (mobile)           • F2592D43-5FE3-46BB-8A2B-A38BA468DCE9 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-5 (simulator)
    • iPad Pro (9.7-inch) (mobile) • 64BCA5CE-E9C3-47AB-97F3-E0610A3A7E14 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-5 (simulator)
    • macOS (desktop)              • macos                                • darwin-arm64   • macOS 11.5.1 20G80 darwin-arm
    • Chrome (web)                 • chrome                               • web-javascript • Google Chrome 93.0.4577.82

• No issues found!


point_stat_wrapper isn't returning expected model files for a given prepBUFR file

Perry Shafran is attempting to run the point_stat_wrapper on his data on WCOSS.  Some of the expected model files aren't getting produced.

sample data provided by Perry, downloaded from WCOSS host gyre onto RAL host Dakota:/d4/projects/METplus/nam_perry/obs/nam.20181114/nam.t06z.prepbufr.tm06.nr and /d4/projects/METplus/nam_perry/model/
and log file, metplus_final.conf and tarball of METplus source code, Metplus_perry.tar in /d4/projects/METplus/nam_perry/debug

Tested that refactor to pb2nc and point_stat allows this case to work correctly.
The following config items need to be set for it to work:
[config]
LOOP_BY_INIT = False
VALID_TIME_FMT = %Y%m%d%H
VALID_BEG =<PHONE_NUMBER>
VALID_END =<PHONE_NUMBER>
VALID_INCREMENT = 21600
LEAD_SEQ = 0, 6, 12, 18, 24, 30, 36, 42, 48, 54, 60, 66, 72, 78, 84
PB2NC_OFFSETS = 6, 5, 4, 3, 2, 1, 0
PB2NC_SKIP_IF_OUTPUT_EXISTS = True
[dir]
PB2NC_INPUT_DIR = /d3/projects/METplus/nam_perry/obs
PB2NC_OUTPUT_DIR = {OUTPUT_BASE}/nam/conus_sfc
FCST_POINT_STAT_INPUT_DIR = /d3/projects/METplus/nam_perry/model
OBS_POINT_STAT_INPUT_DIR = {PB2NC_OUTPUT_DIR}
POINT_STAT_OUTPUT_DIR = {OUTPUT_BASE}/nam/stat
[filename_templates]
PB2NC_INPUT_TEMPLATE = nam.{da_init?fmt=%Y%m%d}/nam.t{da_init?fmt=%2H}z.prepbufr.tm{offset?fmt=%2H}.nr
PB2NC_OUTPUT_TEMPLATE = nam.{valid?fmt=%Y%m%d}/nam.t{valid?fmt=%2H}z.prepbufr.nc
FCST_POINT_STAT_INPUT_TEMPLATE = nam.{init?fmt=%Y%m%d}/nam.t{init?fmt=%H}z.awphys{lead?fmt=%2H}.tm00.grib2
OBS_POINT_STAT_INPUT_TEMPLATE = {PB2NC_OUTPUT_TEMPLATE}


Spike: Research OpenShift 101 course technology

Describe the issue
There is a reusable web format "powerpoint-like" training deck in the bcdevops github org.  Not sure exactly where.
This is a fairly important piece of research because it will define our documentation template going forward.  No more pptx or pdf.
Additional context

Assume the OpenShift 101 is using markdown
it needs to be branded to our team
it needs to support embedding to images & videos (so we update once and everything refers to it)
We want to tackle some learning by upskilling Bahaa in web formats
they are using GitBook hosted within Caddy

Definition of done

Meet and collaborate with Asghar, Avneet, Prabhu, connect with Bahaa see his availability for collaborating or keep him informed if he's not available.
Connect with Patrick S or Shelly H on RocketChat on the private cloud team to find where the OpenShift 101 course lives
Evaluate it for reusability (is it actually easy to update, maintain? can it be displayed via devhub?)
If not, come up with web training alternatives, present to team

Initial VuePress POC at repo: unoah/cloud-pathfinder. Static content is in the gh-pages branch
Can be accessed at https://unoah.github.io/cloud-pathfinder/
Will be doing some cleanup work needed on where static resources are deployed before merging upstream

POC merged with repo: bcgov/cloud-pathfinder via PR-1309
GitHub hosted static content available at: https://bcgov.github.io/cloud-pathfinder/


Fails in case of AWS Lambda cold start

I have used this extension to deploy my Probot on Lambda, my use case is I want to trigger the build on Travis CI when I add a comment on Pull Request. My issue is when I add a comment on a PR for the first time or after a while like 1 hour, it doesn't trigger the build and when the lambda resources are available or after the first failed try it triggers the build successfully.
Its my first issue, so be cool if I haven't provided sufficient details

As nobody else reported the same issue, I assume it was unique to your use case. Have you been able to resolve it?

I too have experienced this problem - please could the issue be reopened?
I have my Probot chatbot app deployed on Lambda using a typical SAM project setup: GitHub -> API Gateway -> Lambda.
When the Probot app hasn't been used for a while, Lambda must cold start an instance of the app. The cold start often takes longer than GitHub's webhook dispatcher is willing to wait, so it times out and doesn't redeliver the event.

The queue solution feels like a generic pattern that could be used in a lot of cases. Would adapter-aws-lambda-serverless need to be modified to handle webhook events coming from SQS rather than API Gateway, or is it able to handle events no matter their source?

Another solution would be to use Lambda Provisioned Concurrency to keep at least 1 instance of the Probot app warm at all times. This is operationally simpler to deploy than the queue, but it (a) costs money on an ongoing basis and (b) won't deal with usage spikes when extra instances of the Probot app need to start - they'll be cold starting, and there will be timeouts.
So I don't like it as much as the queue option.


Could you consider renaming the extension? 🙏🏼

Bun has official support for VSCode. Almost every other language uses the language name as a single word. It would be nice if you considered renaming this extension to Bun X (whatever this extension does better or uniquely). By doing this, Bun can officially take this name and make it easier for everyone to install the right one. Please 🙏🏼🙏🏼🙏🏼🙏🏼🙏🏼🙏🏼🙏🏼🙏🏼🙏🏼🙏🏼🙏🏼

I will do if Bun team contacts me.

I will do if Bun team contacts me.

Hi, I'm on the Bun team and we would appreciate it if this one could be renamed so the one most people are looking for can be first!
Thanks!

@RiskyMH  How do you verify you are on the Bun team?

@RiskyMH  How do you verify you are on the Bun team?

A simple way is I'm in the oven-sh githib organisation which only the team is in.
Another way as how I can publish the vscode extension, I can include a message.

@RiskyMH  How do you verify you are on the Bun team?

A simple way is I'm in the oven-sh githib organisation which only the team is in.
Another way as how I can publish the vscode extension, I can include a message.

@RiskyMH Verify you are by the second way.

@Penggeor I put your message at bottom of the readme.
https://marketplace.visualstudio.com/items?itemName=oven.bun-vscode

@Jonatthu  Check! I need two things:

A formal mail to request a rename from Bun's official mail account.
Leave the explanation in your VSCode extension README.

@Penggeor, how about if the creator of Bun comments here about how nice it is for you to do this?
This doesn't require official emails or mods to the readme. Also, it benefits your extension to be more explicit on what truly specializes, all of this is optional and for the love of your community. You are not obligated to do this. You would just be showing support back to Bun by doing this 🥇
In reality, this is just for the community, if you notice many languages have this pattern:

You could contemplate deeply why the two aforementioned things are needed.


Bug report - a dataviewjs script that causes all other scripts crash

What happened?
I am writing a dataviewjs script to calculate the amount of study time I planned for each subject, so I write a script bellow. The script work successfully, however, all other dataview script in my vault stop working after this...
Error:
Evaluation Error: TypeError: i.push is not a function
    at l$1.diffed (plugin:dataview:15946:1539)
    at j$2 (plugin:dataview:15944:6418)
    at w$2 (plugin:dataview:15944:2236)
    at j$2 (plugin:dataview:15944:6192)
    at w$2 (plugin:dataview:15944:2236)
    at L$1 (plugin:dataview:15944:7442)
    at j$2 (plugin:dataview:15944:6377)
    at w$2 (plugin:dataview:15944:2236)
    at L$1 (plugin:dataview:15944:7442)
    at j$2 (plugin:dataview:15944:6377)

My current workaround is to not to use that script :( or run it once then restart the vault to bring the whole vault back to its normal state :(
Are there any fixes for this or alternatively way to achieve the same purpose? Thx.
An sample file in 10-Diary/Event directory
---
title: Bio Ch9, Ch10
allDay: false
startTime: 14:00
endTime: 16:00
date: 2022-09-11
---

DQL
No response
JS
let subject = Object.fromEntries(["Chi", "Eng", "Math", "LS", "Bio", "Chem", "Phy"].map(k => [k, 0]))
let file_list = dv.pagePaths(`"10-Diary/Event"`)
for (i = 0; i < file_list.length; i++) {
	let page = dv.page(`${file_list[i]}`);
	let keys = Object.keys(subject)
	for (q = 0; q < keys.length; q++){
		if (page['file']["name"].includes(keys[q])) {
			subject[keys[q]] += moment(page["endTime"], "HH:mm").diff(moment(page["startTime"], "HH:mm"), "minute") / 60
		}
	}
}

dv.paragraph(dv.markdownTable(["Subject", "Hours"], dv.array(Object.entries(subject))))

Dataview Version
0.5.43
Obsidian Version
0.15.9
OS
Windows

for (i = 0; i < file_list.length; i++) {

should be
for (let i = 0; i < file_list.length; i++) {

There are some wierd global variable collisions (with i being the most common one) due to some minified code in a library that Dataview uses. I've experimented with how to do proper script isolation but haven't found anything that doesn't break the dataview API yet.

Thx!!!! It worked!! 😀


just correct wrong word

Describe what this PR does / why we need it
just correct a wrong word
Does this pull request fix one issue?
No
Describe how you did it
just correct a wrong word
Describe how to verify it
N/A
Special notes for reviews
N/A

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

Please create same PR to branch of 2.2.x.

Please create same PR to branch of 2.2.x.

hi @steverao, branch 2.2.x do not has this file.


Add ARTags stack

Description

Add Artags stack
Add Realsense wrapper

Todos:

[ ] Standardize markers
[ ] Clean up examples/tutorials
[ ] Add tests for scene & graph

Type of change
Please check the options that are relevant.

[ ] Bug fix (non-breaking change that fixes an issue)
[ ] Proposes a change (non-breaking change that isn't necessarily a bug)
[ ] Refactor
[ ] New feature (non-breaking change that adds a new functionality)
[ ] Breaking change (fix or feature that would break some existing functionality downstream)
[ ] This is a unit test
[ ] Documentation only change
[ ] Datasets Release
[ ] Models Release

Type of requested review

[ ] I want a thorough review of the implementation.
[ ] I want a high level review.
[ ] I want a deep design review.

Before and After
If this PR introduces a change or fixes a bug, please add before and after screenshots (if this is causes a UX change) or before and after examples(this could be plain text, videos etc ) to demonstrate the change.
If this PR introduces a new feature, please also add examples or screenshots demonstrating the feature.
Testing
Please describe the tests that you ran to verify your changes and how we can reproduce.
Checklist:

[ ] I have performed manual end-to-end testing of the feature in my environment.
[ ] I have added Docstrings and comments to the code.
[ ] I have made changes to existing documentation where needed.
[ ] I have added tests that show that the PR is functional.
[ ] New and existing unit tests pass locally with my changes.
[ ] I have added relevant collaborators to review the PR before merge.
[ ] [Polymetis only] I have verified that all scripts in tests/scripts runs on hardware.

Codecov Report

Merging #862 (16f1acb) into main (8e5501e) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 16f1acb differs from pull request most recent head 2bd1a91. Consider uploading reports for the commit 2bd1a91 to get more accurate results

@@           Coverage Diff           @@
##             main     #862   +/-   ##
=======================================
  Coverage   32.67%   32.67%
=======================================
  Files         340      340
  Lines       33116    33116
=======================================
  Hits        10822    10822
  Misses      22294    22294

Impacted Files
Coverage Δ

agents/droidlet_agent.py

agents/_agent.py
52.86% <0.00%> (ø)


Split files Wranglerjs and fix windows

See opens PR https://github.com/cloudflare/wrangler/pull/149, https://github.com/cloudflare/wrangler/pull/147

The windows fix has been merged, only reorganising wranglerjs source is needed.

closed by #202


Issue with nvm and integrated terminal on macOS

VSCode Version: Version 1.19.1 (1.19.1)
OS Version: macOS 10.13.2

Steps to Reproduce:

Install nvm thru brew install nvm or install it thru the official way (curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash).  Make sure appropriate lines are added to ~/.bash_profile. Then install node v8.9.3. Make sure everything works fine with Terminal.app

Open the built-in terminal in Code and encounters the error

nvm is not compatible with the npm config "prefix" option: currently set to "/usr/local"
Run `npm config delete prefix` or `nvm use --delete-prefix v8.9.3 --silent` to unset it.

Reproduces without extensions: Yes
The issue persists on all workspaces, not just the workspace for my web dev projects. It started occurring with a recent Code release. nvm works without an issue with my default Terminal.app which is set to start a login shell which reads .bash_profile just like Code ('yes, Code also start a login shell, I made sure of that').
Issue #36987 also reported this issue and a potential hack but was closed without a satisfactory solution or bug fix. I think there is something wrong with the integrated terminal, maybe some unexpected configuration files are read which set npm config  prefix.

Did you try running npm config delete prefix and restarting code?

@Tyriar Running it gives env: node: No such file or directory. Basically both node and npm are not in $PATH. The nvm script  encountered and error and did not end up setting the path.

Try setting terminal.integrated.shellArgs.osx to [], that fixes this issue for some users.

@Tyriar Your suggestion fixed the issue for me.   Also, looking at the default setting for the terminal.integrated.shellArgs.osx of -l.  According to the zsh (which I'm using) documentation, this flag, like bash causes the shell to start as a "login" shell.  This should cause it to read /etc/zprofile, which contains the following:
# system-wide environment settings for zsh(1)
if [ -x /usr/libexec/path_helper ]; then
        eval `/usr/libexec/path_helper -s`
fi

Commenting out the call to this guy in /etc/zprofile also solves the issue, but for now I'm leaving it as is and just omitting the login shell in vscode..  Thanks for the helpful fix--perhaps others might have some additional insight?  I looked through the differences in PATH and didn't see anything on first pass.

@Tyriar  I use bash and getting rid of -l does work. But this is a hack, not a solution. And this is why I filed this issue after reading issue #36987 as mentioned in my original post. macOS Terminal.app defaults to login shell and it works just fine which I also described in my original post, so there is not reason why in Code we need to get rid of -l. Maybe Code unintentionally or intentionally set some environment variables before or after .bashrc is read?

@kun-zhou if you're aware of environment variables being set that are causing the issue I'd be more than happy to look into it but I'm not aware of any that would cause issues like this though, since I can't reproduce it's tough for me to say.

I just wrote a FAQ on the website about the proper fix for this issue: https://github.com/Microsoft/vscode-docs/blob/master/docs/editor/integrated-terminal.md#why-is-nvm-complaining-about-a-prefix-option-when-the-integrated-terminal-is-launched


Hero h1 margin and padding on mobile widths.

Before

After

There seems to be too much margin and padding on mobile devices.
At around 640px width there does not seem to be a need for the top margin and top padding to be so large.
Should I proceed with a PR and change the top margin and padding until it exceeds 640 which is tailwindcss sm breakpoint

Sorry for the slow response @bmartinez287. I agree and your suggestion seems like an improvement. Go for it!

no worries


Use absolute paths derived from sys.executable in job script

This will ensure that when mop is run from a virtual env or some other conda environment it'll just work.

I'm not sure I fully understand this issue, to clarify:
is the job script  mopper_job.sh?
Because there we have
"cd /g/data..." whatever the appdir passed into the configuration file is
and then "mop -c config-file run" is launched from there.
Are you proposing to change this to
"mop -c  run" ?

So I'm running mopper out of a virtual env, and the script it generates loads an analysis environment and then mop -c config-file run. This fails, as it doesn't pick up that mop came out of a virtual env. If we changed mop to something like os.path.dirname(sys.executable) +'/mop' would fix it.

ok, I get it, I was kind of assuming eventually it would be in hh5, which is actually wrong as it might be easier to actually have "your" own version installed. All of this how to call it execute and from where, how to handle the data properly is quite messy and unclear at the moment

It's now generating this for me:
/g/data/hh5/public/apps/miniconda3/envs/analysis3-24.01/bin/mop which however it's not what I want as the mop I want to use is installed in .local
It could also be problematic as it's not the module I'm loading automatically which is the latest stable. I'm not sure how to make this work for all sorts of different cases.

We could potentially test if that executable exists and if not just passing mop. Or otherwise add something else to the config file which specify which "mop" to use.
I guess the possible scenarios are:

a user installs this on their own loading a conda env we supply which has all the dependencies and uses it from .local
we get this installed in hh5 envs which should be doable provided we manage the data correctly, some files will come with the package but in some cases you have to add/modify some input files
a user create a separate conda env, not sure if this is needed as it doesn't give you any advantage compared to option 1 or 2. I can see this useful only if eventually CMOR is not part anymore of shared conda envs

I've added an extra field in the config file called
"conda_env"
a user can pass  a path relative to appdir or the absolute path for their custom conda env activate command
conda_env: mopper-env/bin/activate
The code will add a line
"source /" to the job file so this env can be used.
There are still a couple of assumptions here,

module load conda/analysis3-unstable
is the default behavior (hopefully we will have mopper there soon)
the user env is also built on top of conda/analysis3-unstable or at least they are both loaded

WE could customise this further or better but for the moment should be enough. If the setup is run with the "test: true" option then a user can always sort out the modules before submitting the job


added ssl_endpoint_identification_algorithm config option

#298

@JackDavidson I've included this in a follow-on commit that fixes an issue which was causing this not to work.
Thanks for the contribution!

This was merged along another branch.


STOR-1574: Bump library-go

Update openshift/library-go and openshift/api to today's master. Update k8s deps to v0.29.0.
@openshift/storage

/label px-approved
/label docs-approved
No changes from user perspective
/label qe-approved
CI should be enough for library bumps

/retest

/retest

/lgtm


Can't import custom commands

I was following docs, and added
command script import /usr/local/opt/chisel/libexec/fblldb.py
script fblldb.loadCommandsInDirectory('/Users/dshmidt/Documents/Scripts/LLDB/Chisel/')

to my .lldbinit file.
However, I'm getting following error when running command source ~/.lldbinit:
Script done, output file is import
-bash: /Users/dshmidt/.lldbinit: line 49: syntax error near unexpected token `('
-bash: /Users/dshmidt/.lldbinit: line 49: `script fblldb.loadCommandsInDirectory('/Documents/Scripts/LLDB/Chisel/')'

If I just run lldb, then it shows:
File "<input>", line 1
SyntaxError: can't assign to operator

You shouldn't need to run command source ~/.lldbinit, that should happen automatically by lldb when it starts. However if you do want to run this, it needs to be from lldb's command prompt, but it looks like you are running this from the command line. Let me know if this helps sort things out.

@kastiglione I was using command source ~/.lldbinit just to reload this file in terminal. Here I just provided its output, as it gives more clear error message, then when I run lldb.

command source ~/.lldbinit is an lldb command, it must be run from the lldb command prompt ((lldb) ), not from the command line. Running it from the command line will run the script command (which is for capturing a shell session's input and output).

I believe my last answer should clear things up, but if not feel free to re-open with further updates.

I still have this problem.
So from what I understand, this error comes from 'import lldb' line.
I removed all Python versions except system one, and 'import lldb' totally works in REPL, so I have no idea why it doesn't work in Chisel.


Shield web ui reports agent status as failing but it works (backup and restore)

Hello,
Shield web ui reports agent status as failing whereas the agent works as expected (it performs backup and restore).
The message is the following :
Note:
This SHIELD agent is not reporting its version, which means that it is probably a v6.x version of SHIELD.  It will not be able to report back health and status information to this SHIELD Core.  Similarly, plugin metadata will be unavailable for this agent, and SHIELD operators and site administrators will have to operate without it for all targets that use this agent for backup and restore operations.
The shield core is configured with a dynamic ip allocated by bosh.
The release cf-routing (with the job route_registrar) is used in order to open a route (name) on this dynamic ip.
The domain property in the core job is valuated with the name.
Thanks and regards,
Jean-Christophe.

What version is the shield-agent at?

Hello James,
I am using the 8.0.16 release (output from bosh releases command).
How can I check that in order to be sure ? Is there a file that can I check on the VM which hosted the agent ?
Regards,
Jean-Christophe.

I believe the problem here might lie in the use of gorouter.  The legacy fabric for SHIELD Core <-> Agent communication uses the TCP remote IP of the connection that registers the agent.  If you transit another system, i.e. a NAT device, HTTP proxy, or a reverse proxy like the gorouters, it may not pass through properly.  Does the IP address in the Agents part of the admin UI match your expectations, knowing your internal network topology?


Eliminate dependencies

I merged the regexp from is-extglob into this, making it have 0 dependencies. Incidentally, it's smaller.

no, sorry this is an anti-pattern


Add support for 'session cookies'

Some applications prefer having cookies deleted by the users browser
when the browser is closed. This is achieved by not setting
max-age nor expires headers.

Can you add docs and tests for this?

Will do! Probably this coming week.

Added docs and tests.
@subyraman

I see the travis build fails because it can't install 'sanic'. End of "python setup.py install" goes:
Searching for sanic

Downloading https://pypi.python.org/packages/4f/fd/9d4a7bc63ac6ed80bc9c58fc771d5a7af977b325c805e965448404d6631f/sanic-motor-0.2.8.tar.gz#md5=19697ce750e03e0cb4301a9d871b8f82

Best match: sanic motor-0.2.8

Processing sanic-motor-0.2.8.tar.gz

Writing /tmp/easy_install-xdtw9d90/sanic-motor-0.2.8/setup.cfg

Running sanic-motor-0.2.8/setup.py -q bdist_egg --dist-dir /tmp/easy_install-xdtw9d90/sanic-motor-0.2.8/egg-dist-tmp-ixj8vmd8

removing '/home/travis/virtualenv/python3.5.3/lib/python3.5/site-packages/sanic_motor-0.2.8-py3.5.egg' (and everything under it)

creating /home/travis/virtualenv/python3.5.3/lib/python3.5/site-packages/sanic_motor-0.2.8-py3.5.egg

Extracting sanic_motor-0.2.8-py3.5.egg to /home/travis/virtualenv/python3.5.3/lib/python3.5/site-packages

sanic-motor 0.2.8 is already the active version in easy-install.pth

Installed /home/travis/virtualenv/python3.5.3/lib/python3.5/site-packages/sanic_motor-0.2.8-py3.5.egg

error: The 'sanic' distribution was not found and is required by sanic-session

The command "python setup.py install" failed and exited with 1 during .

Your build has been stopped.

Looks like it searches for sanic but only finds sanic_motor which was already installed earlier. I don't know what causes this, but I don't think this has anything to do with this PR.

The above commit fixes the sanic requirement install for my local python 3.6.3 install in a virtualenv. But the travis run still fails (uses python 3.5.3 - don't know if that could be a factor).

All right, thanks! I'll have to do some work soon to get all this new code out for release.


Extensible enums

A mechanism for declaring an enum to be extensible, which prevents exhausting matching in downstream crates.
Rendered text.

:+1:

Easy, solves a real problem.

It seems weird to have pattern matching behave differently depending on whether the enum is external to the crate or not - afaik apart from coherence we don't have such behavior anywhere else, and it would hinder refactoring of code that moves an enum into its own crate.
So I'd be for consistently treating such an enum as non-exhaustivly matchable even in the crate that defines it.

:+9000:

Ditto @seanmonstar

Sounds great.
I wonder if this could be extended to allow an enum which can be extended by its users, i.e. they can add variants to an existing enum. I'm unsure how this would work in terms of representation, but it would be really useful for generic error types, where the only real solution today is using Any and downcasting.

I don't completely understand. If a library adds more errors to an enum, I don't want my code to compile until I handle all of the errors, right? Isn't putting a catch all _ -> ... dangerous?

:+1: It doesn't sound invasive and it provides more flexibility to one of the types that's broadly used.

Maybe the downstream crate really wants to match every variant. Using _ => {} makes it easy to miss one match when updating code. Perhaps it should be something like .. => {}, and emits a warning if this .. arm is reachable.

@kennytm hmm, that's an interesting thought. I do agree that it'd be nice to give downstream crates the option to try and exhaustively match everything, even if they must provide a backup.

@reem I think that enums which are extensible by end-users is kind of a separate feature. That is typically the role of a trait object. There might be some overlap with virtual structs. Certainly, though, to support user-defined variants, we would need to guarantee that the base type is considered unsized so that it is only manipulated by pointer (which was a key ingredient in most of the virtual struct designs). Those designs however were typically targeted at non-extensible use cases, though it seems that there is demand for extensible cases as well.

@gsingh93 there is certainly some tension between the desire for stability -- your code keeps compiling even with newer versions of my library -- and your desire for completeness. I think perhaps something like what @kennytm is suggesting offers a compromise path, but we'd need to find an acceptable syntax.

(Using .. as a substitute for _ is clearly ambiguous, e.g. Foo(..) vs Foo(_) have distinct meanings today.)

@nick29581 the reason I chose .. is just that it's what we use everywhere else (e.g., Foo(..) in patterns). I think using ... feels like a kind of random inconsistency. I'd rather restrict the use of ... to inclusive ranges of various kinds (or, alternatively, restrict the use .. to exclusive ranges, but that ship has sailed). Point is, I don't want to have to guess how many dots!

Updated the RFC to include an alternative design (no exhaustive matching) and unresolved question (can we have a nice syntax for "wildcard that should never match").
Regarding the first point -- whether to draw a distinction between crate-local matches and external ones -- I am on the fence. I like the extra expressive power of being able to do exhaustive matches locally, but I am not sure if real-world use cases (like IoError) will ever take advantage of it.

In ye olde draft RFC (under the more sophisticated variant) abstract enum types would have this behavior (though per-mod, not per-crate).

@glaebhoerl yes, I considered per-module, but per-crate seems superior to me, since the enum is public and hence it seems likely that matches against that enum will occur outside the module where it was declared (moreover, per-crate is the largest scope you can get without affecting semver guarantees what-so-ever). There is probably a use case for one module within a crate "defending itself" against another adding variants, but it seems less important, and is counterbalanced by the fact that being able to write exhaustive matches is legitimately useful for maintaining overall consistency within a package (it happens somewhat regularly that I find bugs due to over-eager use of _).

This adds the inverse source incompatibility, where I forget to make an enum extensible and then break downstream when I realize I might need to add variants in the future, right? So people should always make enums extensible unless they're really really sure the current set of variants is exhaustive?  What's the perception of how frequently one or the other is the case?  Should 'extensible' be the default and something like 'sealed' get added instead?
Another alternative is to allow downstream consumers to explicitly protect themselves by not throwing an 'unreachable pattern' error for terminal _ match arms.  This allows consumers who want to break when their match is no longer exhaustive to just not provide that catch-all.

@jfager It seems to me that most enums would probably end up "closed" or sealed or whatever it'd be called. For example, we're never going to want to add any more variants to Option, Result, Ordering, etc. The most common use case for extensible enums that I can see is for error handling like IoError or SqlState. Having to break backwards compatibility to "extensify" an enum seems like not that much of a problem in practice, since you're presumably doing it because you want to add more variants, so you can just fold the extensification change in with the addition of more variants.

@sfackler Option, Result, Ordering, and many others in the std lib are basic, core enums that I don't think are representative of the sort of enums people usually create in their own code.  I don't think that sealed enums would be rare by any stretch, but I think it's questionable whether they're more common than extensible ones:

Errors are going to get created in user code all the time.
Standards, like http status codes, which grow over time.
Games might decide to add new monster types or whatever.
Supported machine architectures, operating systems, browser types, etc.

@nikomatsakis Would having an arm such as this work:
_ => static_assert!(false)

When the _ case is unreachable it could disable asserts within it. I'm not sure if there's an equivalent macro for warnings.

As it's written right now this RFC turns a compile-time error into a potential run-time bug. -1 for this reason. Making it a warning doesn't solve anything. Downstream often does not know if a warning is serious or not and upstream will have to fix the warning for the same reason.
Any change that aims to make Rust more semver compatible should be part of a comprehensive solution that addresses all points in https://github.com/rust-lang/rust/issues/17152.

My point is the same as @mahkoh's, which is why I'm still against this.

@Diggsey, if you did that it wouldn't compile, and you'd be right back where you started.

While I'd really like extensibility, I'm not seeing how we can safely allow the crate defining the enum to have exhaustive matches:
If another crate B extends an enum in A, and then some code in B passes an instance of one of the new variants in that enum into the original defining crate A, A will need to have wild card matches.

@jmesmon That's a different feature that is mostly unrelated - my bad for bringing it up, really. This feature only allows crate A to add new variants backwards compatibly.

Maybe extensible enums should be the default? (which would mean using a different syntax, such as "sealed", for the non-extensible ones)
Perhaps there should be an attempt at creating statistics of which would be more frequent.

Maybe extensible enums should be the default?

I don't think making this the default behavior would be a great idea. It'd add a lot of noise for little benefit to a lot of common cases. I also think that when the intention is that the sum might be extended, this should be emphasized as the more interesting case rather than made implicit.

:+1:
Error codes are an obvious reason for this. There are also a lot of use cases for enums where each variant corresponds to a unit of functionality (e.g. selecting an algorithm for doing some operation, choosing from a list of supported data formats, enumerating types of requests that can be issued to some subsystem).
Adding variants in these cases just shouldn't be a breaking change. It forces the author to choose between either breaking the rules of semver by not bumping the major version number, or bump the major version so often that it becomes meaningless to the majority of users whose code doesn't actually break.
Another potential use case for extensible enums is if you have a crate with an API that can be extended based on whether optional features are enabled in an installation. Lets say that for some crate there's a feature that can be enabled that adds more variants to an enum (because there are now new options, or new errors that can be thrown, or whatever). If you are developing against a version of the crate with the feature enabled, and your code fails when the feature is disabled, that's not a big shock. If you wrote something that depends on that feature, of course your code won't work when it's off.
But if you develop with the feature disabled, and your code fails when the feature is enabled, that is more surprising. The compiler can't check that you're matching all variants if some variants aren't even present in your particular installation of a crate. So if there's an enum that adds variants based on an optional feature, and you want to decrease the impact on code that doesn't actually use that feature, making the enum extensible would help.

As it's written right now this RFC turns a compile-time error into a potential run-time bug.

This is strictly adding power, it is making something currently impossible (or rather ugly) to express into something that is possible to write. That is to say, there's no inherent change of time-of-errors happening in this RFC.
There is such a change happening in cases where an enum is changed from non-extensible to extensible, but this happens on a case-by-case basis. And such cases will likely want to hack some sort of extensibility in anyway, e.g. storing Other(Box<Error>) for error codes, which has the same runtime bug potential, and new downsides e.g. a C-like enum would be turned into one with data.

If we have a lint for reachable "extensibility-patterns", we may not want to use .. for the extensibility-pattern, or else .. is used for two distinct things in patterns, that and ignoring all contained data in an enum variant. E.g.
let x: Option<Extensible> = ...;
match x {
     None => {}
     Some(..) => {}
}

(... would presumably work for this.)

This is strictly adding power, it is making something currently impossible (or rather ugly) to express into something that is possible to write.

So does disabling the borrow checker via attributes.

That is to say, there's no inherent change of time-of-errors happening in this RFC.

You're practically saying that the enum writer now has to decide very carefully if the enum is critical enough that marking it Extensible is a possible bug.
The sole reason for this RFC is to avoid having people bump the major when they add an enum variant. This is bought by forcing the user to disable compile-time checks, i.e., by forcing them to use _ => .... This could make sense if there was a consistent plan how to make it easier to use Rust and Semver together. But there is no such plan afaik and this RFC has to be evaluated in that context.
Let me reproduce my (incomplete) list of things that currently force a major bump:

Adding a field to a struct.
Changing a struct from Copy to NoCopy (same with Send, Sync, etc.)
Adding a variant to an enum.
Adding a public method to a type (consider extension traits)
Adding a method to a trait (consider #17151)
Changing the conditions under which a function can panic.

(See https://github.com/rust-lang/rust/issues/17152 for comments)
I've asked about this before and the answer was that Rust libraries are expected to bump the major regularly. If we assume this, then the motivation behind the RFC becomes much less convincing.

That being said, if the variant of this RFC that suggests a warning is accepted and if the user can turn this warning into an error via a global attribute then that's already much better.

@mahkoh I agree with you that we need to produce an RFC explaining each of the points where a new major version is required. We've done a lot of thinking about this but it's not been written up in a central location afaik (your comments are a good start, though I do not agree with your complete list).
However, I don't see why that argues against adding features that allow changes without requiring new major versions. Nor do I see why we must address every such feature all at once. We can grow such features as they become important: there is currently a very real need for extensible enums in the standard library. The same is not true e.g. for adding new public fields to structs.

We can grow such features as they become important: there is currently a very real need for extensible enums in the standard library.

This RFC could be postponed for six weeks and still be implemented before 1.0. More than enough time to write a comprehensive RFC for Rust+Semver.

So @huonw and I were talking about things this morning and I wanted to transcribe some of our conversation. In particular, there are two kind of interesting questions here:

Should we permit exhaustive matches on extensible enums? If so, within what scope?
How can we permit "semi-exhaustive" matches, where the downstream user gets a warning when new variants are added, but is still required to specify some sort of fallback?

Exhaustive matches on extensible enums. The RFC states that normal exhaustive matches would be permitted within the local crate. The choice of crate was simply because it's the "semver boundary", so to speak -- a smaller boundary (like per module) seems to offer no particular advantage. On the other hand, there are legitimate use cases that might want a larger boundary -- I envision something like libsyntax, which might like to declare AST enums that the compiler can exhaustively match against, but where downstream clients must be more defensive. Obviously this overlaps somewhat with question 2.
The compiler example is a bit unrealistic because in practice I think that any kind of stable AST-like API is going to wind up being completely divorced from the representation that we use internally in the compiler. I am not sure whether there are other examples that are more realistic.
Primarily the goal of this RFC is to handle things like the IoError enum, where it rarely if ever makes sense to exhaustively match anyhow (since many of the errors don't apply to any particular instance, and you rarely if ever expect to handle every kind of thing that can go wrong). However, there are a few cases where it could be useful -- for example, we might like to have some kind of "IoError-to-string" method implemented in libstd, and that would likely want to match exhaustively. This seems to argue in favor of crate-local exhaustive matching at least.
In general, we can extend the set of crates where exhaustive matching is permitted in the future if we choose, but we cannot retract. This argues in favor of not stressing too hard about covering every case.
So all in all I feel pretty good about leaving crate-local in place.
Semi-exhaustive matches. Nonethless, the idea of "semi-exhaustive" matches seems like a great compromise. Basically how I see it is that having the semi-exhaustive match option permits more enums to be declared extensible -- otherwise there is (more) backpressure to keep enums as fixed and prefer a major-version-bump, so that clients can use exhaustive matching. There is always something of a tradeoff here, but we can shift the balances around.
Nonetheless, this feels like a bit of a niche tweak. That is, there will always be enums (e.g. IoError) where exhaustive matching is unlikely. Semi-exhaustive matching allows us to extensibility more broadly, but there will still be enums where it's too onerous. So it's a good idea and worth considering, but not a must have; it can easily be added later. (It'd be interesting to know if there are enums in libstd where semi-exhaustive matching would affect our opinion about making them extensible.)
Unfortunately, the original proposal of using .. is unfortunately syntactically ambiguous, and creating a whole new kind of pattern feels a bit like overkill to me anyhow (a big piece of syntax for a relatively niche case). Another option would be to use lints -- we might say that there is a lint (which defaults to off) that warns when _ ignores an existing variant for an extensible enum. Or perhaps we add some kind of annotation.
Bottom line is, I think we can probably tweak this by adding a lint later, it doesn't seem like it needs to block the RFC, but it's a good idea.
Sorry for the length of this comment! No time to make it shorter.

One idea about the syntax is to revert to * for multiple wildcard pattern and use .. for extensible wildcard pattern, or vice versa.

+1, love this idea.
However, how does this interact with Rust dylibs? Wouldn't it be possible to get a size mismatch between two dylibs which are exposing functions with extensible enums as parameters or return types? (I'm not sure what level of dylib support we have)
@kmcallister @erickt This might help solve the problem of plugin stabilization we discussed in December. :D

This could also be a lint, e.g., "Warning: Matching an extensible enum without a default branch."

And instead of additional syntax, extensible enums could be declared with an attribute.

That sounds doable, and a reasonable alternative.
(This also should be possible to implement as an external library, however you'd need to enforce that users of the library with extensible enums also import the lint)

I much prefer @mahkoh's idea of making it a lint.  I pretty much love exhaustive matching and think the utility of enums is severely reduced without it, and I think it would be a much more consistent way of handling it.
I also echo @Manishearth's concerns about dylibs, and in general how this would interact with (distant future) ABI stabilization.

On Tue, Feb 03, 2015 at 10:05:00AM -0800, Joshua Yanovski wrote:

I much prefer @mahkoh's idea of making it a lint.  I pretty much
love exhaustive matching and think the utility of enums is severely
reduced without it, and I think it would be a much more consistent
way of handling it.

Nobody is proposing removing exhausting matching. I think there would
be pretty strong pressure against making enums extensible without good
reason.

I also echo @Manishearth's concerns about dylibs, and in general how
this would interact with (distant future) ABI stabilization.

This may be worth digging into more, but I'm not overly
concerned. There are definitely numerous changes today that can cause
binary incompatibilities but not source incompatibilities. Reordering
enum variants, for example. I'll try to do some research into how
dynamic linking and multiple versions works in existing systems,
probably just by bothering people on IRC (any suggestions for links to
read?)

@nikomatsakis Reordering enum variants can probably be solved by sorting them, however with extensible enums, that doesn't work so well unless the author sticks to some scheme of annotations on the variants (stability attributes work here, since we can just sort by version first and then alphabetically/whatever). #[repr(sorted)] would be one way of doing this.
Still has the size issue though. #[extensible(max_size=foo)] enum Bar{...} is one hacky way of solving this.
But I agree that binary incompatibilities isn't something we need to be worried about at the moment. Eventually we should have some form of ABI stabilization, but right now that seems far off.

I already mentioned this in a previous comment, but I'd like to push harder for a different approach:  moving the decision about whether adding variants to an enum breaks downstream code to the downstream code itself, by not considering the _ => case unreachable.
So for
enum Foo {
    First,
    Second,
    // Third // add this later
}

consumer code that doesn't want to break when the Third variant gets added would just look like:
match foo {
    Foo::First => ...
    Foo::Second => ...
    _ => ... // would error as unreachable in current rust
}

This is consistent with how you already write code for enums with cases you're willing to ignore; conceptually this just extends those cases to those that might not exist yet.
The advantage of this over the RFC approach is simplicity.  The RFC is talking about adding new syntax, adding complexity around how things behave across crate or mod boundaries, and adding more new syntax or lints for clients who would still want to break.  All this and enum authors still have to pick right the first time or risk breaking consumer code when they need to update, or conversely default to making enums extensible.

I implemented this as a plugin.
It's not perfect yet, but that can be fixed.
Of course, this has the obvious flaw that it only works if the user imports the plugin. Library authors can reregister the lint pass, however this still requires the library to be imported with #[plugin]

I am in favour. I was a little hesitant about this feature being baked-in to the language but I do see the appeal.
I am not sure I agree we should be satisfied with how structs would (not) be affected by the same problem - I think for data types such as models in Web applications, the similar issue will prove itself to be as significant. Using a convention such as an extra private field is not something I would expect user code to follow easily.

Perhaps you could introduce enum inheritance. That looks clean to me, but I am not sure if it covers all use cases.
enum Foo {A, B}

// ExtendedFoo inherits from  Foo
fn bar<ExtendedFoo:  Foo>(x: ExtendedFoo) {

    match x {
        Foo::A => ...,
        Foo::B => ...,
        _ => ...,
    }
}

I think there would
be pretty strong pressure against making enums extensible without good
reason.
Agree with that.
-1 for enum inheritance, if you really need to check another type, just check it.
For example when I handle C language data structrues:
struct Struct(HashMap<String, (usize, usize)>);
struct Union(HashMap<String, (usize, usize)>);
enum Type {
 	Struct(Struct),
 	Union(Union),
 	Primitive(usize),
 	Pointer(Rc<Type>),
 	Unknown(TypeName)
}

This is a scenario where you think inheritance is needed at first glance. And if Rust allow enum inheritance I'll probably do that, which is wrong.
When you modify an enum's definition, almost everywhere it is used should be pointed out by compiler, this behavior is significant and should not be changed.

@jfager I don't understand: With your proposal, how would a library author force its clients to write the extra _ => ... match arm?
(I am not opposed to your proposal, but it does not seem to address the full problem here.)

@bombless FYI: you left some important context out of your quotation.
At least to me, the way you have written that quotation, it could be interpreted as "there will be strong pressure against the language change from this RFC without better motivation."
But the author of the quote is the author of the RFC, and the sentence preceding that quote was "Nobody is proposing removing exhausting matching."; I believe @nikomatsakis 's intention was to say that "there will be strong pressure against a library making one of its enum definitions extensible."  I.e., you're only supposed to do it in scenarios like the one laid out in the RFC itself.
(I do not think @bombless was actively trying to distort niko's words; the quote just struck me as a difficult to understand, and so I am trying to fix that.)

@pnkfelix In current Rust, an enum client can either exhaustively match the current set of variants and break when new variants are added, or partially match the current set of variants and not break when new variants are added.  There is no way to exhaustively match the current set of variants and not break when new variants are added.  I'm saying we should add that ability.
I'm further claiming that if we add that ability, the need for this rfc and its attendant complexity is reduced, as clients then have a way to make themselves source compatible with upstream changes if that's what they want.  While it's true that doesn't give library authors a way to force clients to stay source compatible, I think that's fine, as it's completely reasonable for clients to want to break regardless of the library author's intent.
If some way for the library author to signal intent is still desired, I think an attribute and a lint as @mahkoh suggested would be preferable to a full-blown language feature, especially if that language feature is going to come with a bunch of extra baggage like different behavior around crate boundaries and new counter-features to continue allowing people to do exhaustive matching.

Having chewed this over in my sub-concious a little more, I'm thinking that an attribute + lint (as suggested by @markoh) would be a good approach, rather than adding new syntax. To make things more concrete: adding #[extensible] to an enum would allow match statements which match it to have a wildcard arm, even if the other arms are exhaustive. A lint, error by default, would check that all uses in a different crate have such an arm.
I like this because the extensible-ness doesn't affect the dynamic semantics of the enum and the only way it affects the static semantics (by forcing a wildcard arm) can't cause a soundness issues, i.e., if type checking is wrong, there still won't be an error. Together these signal to me that the feature should not have first class syntax.
I like a lint because it seems a reasonable position to take to value exhaustiveness more highly than avoiding future errors (although I believe the other preference is more reasonable), So, it seems justifiable to allow this switch to be flicked. I believe we can justify any future backwards compatibility issues by including error-by-default-lints as errors for the sake of compatibility.

Making it a lint would make it near-useless for the stdlib unless
disabling this lint required a feature gate, because otherwise you'd be
able to subvert our stability guarantees.
One thing I've become increasingly disturbed about with this RFC is the
inability to exhaustively match against an extensible enum. I want the
ability to opt-in to instabilty for the sake of robustness.
On Wed, Feb 11, 2015, at 00:20, Nick Cameron wrote:

Having chewed this over in my sub-concious a little more, I'm thinking
that an attribute + lint (as suggested by @markoh[1]) would be a good
approach, rather than adding new syntax. To make things more concrete:
adding #[extensible] to an enum would allow match statements which
match it to have a wildcard arm, even if the other arms are
exhaustive. A lint, error by default, would check that all uses in a
different crate have such an arm.

I like this because the extensible-ness doesn't affect the dynamic
semantics of the enum and the only way it affects the static semantics
(by forcing a wildcard arm) can't cause a soundness issues, i.e., if
type checking is wrong, there still won't be an error. Together these
signal to me that the feature should not have first class syntax.

I like a lint because it seems a reasonable position to take to value
exhaustiveness more highly than avoiding future errors (although I
believe the other preference is more reasonable), So, it seems
justifiable to allow this switch to be flicked. I believe we can
justify any future backwards compatibility issues by including
error-by-default-lints as errors for the sake of compatibility.

— Reply to this email directly or view it on GitHub[2].

Links:

https://github.com/markoh
https://github.com/rust-lang/rfcs/pull/757#issuecomment-73835558

@cmr Stable Rust releases will ship with unstable features disabled explicitly to avoid allowing people to "opt into instability" because if you allow people to opt in, they'll do it. How is this case materially different?

@cmr, being able to subvert the stability guarantees doesn't seem like an issue to me - you can always do it if you are determined enough. The fact that you have to opt in, seems like its enough of a disclaimer to me.
I'm not sure I understand your second point, that seems to be asking for exactly the lint that is proposed.

Closing as postponed; RFCs issue

@cmr we decided to postpone this for the time being, however making this into a lint does not make it near useless, at least not anymore than any other lint. One of the changes I've been meaning to propose along to address this particular point is that rustc should have a command line flag to override and cap all lints at "warn" status so that a lint can never block compilation. cargo can then use this for dependencies. This would ensure that while you get the full benefit of the lints in the current crate you are working on, you are not blocked from using other people's work. Note also that the way the lint was proposed, you would still be required to put a _ case, so there would be some defined fallback and behavior if additional variants are added, even if you also get a compilation warning.

Enums being non-extensible by default, with opt-in extensibility, is a good idea.
However, for structs it's the wrong way round. Adding an implementation detail such as a private field to an all public struct mustn't cause third-party code to break.
Instead, by default structs should be extensible and not allow public instantiation. Then adding a private field to a struct is never a breaking change.
Of course, there would be an opt-in that makes the struct non-extensible and allows public instantiation. This opt-in also requires all fields to be public. Adding a private field would cause a compile-time error.
One way to implement this: the compiler by default adds a zero-sized hidden dummy field to every struct. When the user opts-in, the dummy field is not added and all fields must be public.

@Virtlink would you also make destructuring bind and FRU illegal without the opt-in?  See e.g.
https://github.com/rust-lang/rust/issues/21407
Seems like a deal-breaker to me. But maybe I am missing something
An analogous #[extensible] attribute for (all pub) structs that enforces your rule via a lint (and lint-warns on destructuring bind and FRU too) seems like a way around that, and is is a non-breaking change to boot.

It's funny that in Rust we already can build a enum that always have potential to grow.
mod some_module {
    enum _Enum { A, B, _Dummy }
    pub type Enum = self::_Enum;
    pub use self::_Enum::{A, B};
}
fn to_string(e: some_module::Enum) -> String {
    match e {
        some_module::A => 'A'.to_string(),
        some_module::B => 'B'.to_string(),
        _ => "_not_supported".to_string()
    }
}

I think it's related to https://github.com/rust-lang/rust/issues/22261 though.

@pnkfelix Indeed, function record updates outside the module would only be allowed with the opt-in, as public FRU would break as soon as a private field is added. If the author wants to add a private field to the struct later, then it wasn't his intention to allow FRU in the first place. Or if it was, removing the opt-in makes the author aware he's now making a breaking change.
Destructuring outside the module is still possible with a wildcard, as this won't break if a private field is added:
pub struct Foo { pub value: u32, }

// Somewhere outside the module:
let Foo { value: v, .. } = Foo::new();

Again, only with the opt-in has the author stated that no private fields will ever be added and is it safe to destructure without the wildcard.


Liqo installer improvement for Liqo Agent installation

Description
This PR adds a section to the Liqo installer to let users install and uninstall the latest version of the Liqo Agent as a desktop application.

[ADDED] files to make the Agent binary as a desktop application

xdg .desktop file
.svg scalable logo

[ADDED] new iconset for the desktop banner notifications

Pull Request Test Coverage Report for Build 317459700

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.05%) to 47.83%

Totals

Change from base Build 317295294:
0.05%

Covered Lines:
6259

Relevant Lines:
13086

💛  - Coveralls

A second problem is that the installation of the v0.1 is broken, as the layout of the repo changed (it fails to retrieve the icons). My suggestion there is to manually delete the binary from that release (which I nonetheless suppose not being yet fully functional), and do a follow-up release when everything will be ready. @palexster WDYT?

Ok to me. We will publish the agent for the v0.2 or make a v0.1.1 with the agent correctly generated.

A second problem is that the installation of the v0.1 is broken, as the layout of the repo changed (it fails to retrieve the icons). My suggestion there is to manually delete the binary from that release (which I nonetheless suppose not being yet fully functional), and do a follow-up release when everything will be ready. @palexster WDYT?

Ok to me. We will publish the agent for the v0.2 or make a v0.1.1 with the agent correctly generated.

@palexster seems good to me too, this way we can also have the opportunity to merge #214 and #351 first, thus having a fully functioning version with a couple of working features


A random delay is added when the lock is repeatedly acquired

When a client to acquire the lock failure, the client should retry after a random delay, the reason why the use of random delay is to avoid different client and try again. The results all clients can't get the lock.

is to avoid different client and try again
Sorry, I didn't understand why do you need this delay? If all clients trying to acquire lock at the same time then only one client get it in any case. Due to atomicity of Redis lua-script execution.

Maybe I can't describe the problem very well.But there's such a piece of content in the redis official document：
When a client is unable to acquire the lock, it should try again after a random delay in order to try to desynchronize multiple clients trying to acquire the lock for the same resource at the same time (this may result in a split brain condition where nobody wins). Also the faster a client tries to acquire the lock in the majority of Redis instances, the smaller the window for a split brain condition (and the need for a retry), so ideally the client should try to send the SET commands to the N instances at the same time using multiplexing.
It is worth stressing how important it is for clients that fail to acquire the majority of locks, to release the (partially) acquired locks ASAP, so that there is no need to wait for key expiry in order for the lock to be acquired again (however if a network partition happens and the client is no longer able to communicate with the Redis instances, there is an availability penalty to pay as it waits for key expiration).
Link is https://github.com/antirez/redis-doc/blob/master/topics/distlock.md
I hope this passage will help.

RedissonLock is not the RedLock. RedLock described by antirez is a distributed cluster wide lock. RedissonLock is only a single (master)server lock.

Fixed in #633


Call specific GKE version in release channel

This PR calls a specific GKE version as defined by the API, as opposed to a generic "1.22" string

Didn't pass checks due to us ignoring some Google provider warnings. Forcing a merge to get another hub running, but this must be fixed in a future release.


Creating Scheduler tutorial for new portal

@krisragh - Please pull these changes to a branch in your local clone of the private repo and resubmit via the private repo so the changes can be validated and staged. You should be able to use these commands from your private master branch.
git checkout -b krisragh-patch-7 master
git pull https://github.com/krisragh/azure-content.git patch-7