Make keras.callbacks.Callback and tensorflow.keras.callbacks.Callback mutually compatible

tensorflow.keras.callbacks.Callback has private methods _implements_train_batch_hooks etc which are called e.g. when the callback is used with tensorflow.keras.models.Model.fit.
keras.callbacks.Callback provides no such methods and so using it with e.g. tensorflow.keras.models.Model.fit results in AttributeError: 'SomeClassExtendingCallback' object has no attribute '_implements_train_batch_hooks'.
If those two versions of Keras aim to be compatible, then this should be fixed.

@PiotrJander,
In order to expedite the trouble-shooting process, could you please provide the complete code to reproduce the issue reported here and also the TensorFlow version you are using. Thanks!

Versions:
tensorflow==2.2.0
Keras==2.3.1

Minimal example:
import neptune
from tensorflow import keras
from keras.callbacks import BaseLogger

mnist = keras.datasets.mnist
(x_train, y_train), (x_test, y_test) = mnist.load_data()
x_train, x_test = x_train / 255.0, x_test / 255.0

model = keras.models.Sequential([
  keras.layers.Flatten(),
  keras.layers.Dense(100, activation=keras.activations.softmax)
])

model.compile(optimizer='adam',
              loss='sparse_categorical_crossentropy',
              metrics=['accuracy'])

model.fit(x_train, y_train,
          epochs=5,
          batch_size=256,
          callbacks=[BaseLogger()])

Output and error:
Using TensorFlow backend.
2020-06-19 10:32:15.050829: I tensorflow/core/platform/cpu_feature_guard.cc:143] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA
2020-06-19 10:32:15.069239: I tensorflow/compiler/xla/service/service.cc:168] XLA service 0x7ff6bf6ae880 initialized for platform Host (this does not guarantee that XLA will be used). Devices:
2020-06-19 10:32:15.069257: I tensorflow/compiler/xla/service/service.cc:176]   StreamExecutor device (0): Host, Default Version
Traceback (most recent call last):
  File "tf-issue.py", line 18, in <module>
    model.fit(x_train, y_train,
  File "/Users/piotr/projects/neptune-sandbox/.env/lib/python3.8/site-packages/tensorflow/python/keras/engine/training.py", line 66, in _method_wrapper
    return method(self, *args, **kwargs)
  File "/Users/piotr/projects/neptune-sandbox/.env/lib/python3.8/site-packages/tensorflow/python/keras/engine/training.py", line 819, in fit
    callbacks = callbacks_module.CallbackList(
  File "/Users/piotr/projects/neptune-sandbox/.env/lib/python3.8/site-packages/tensorflow/python/keras/callbacks.py", line 230, in __init__
    self._should_call_train_batch_hooks = any(
  File "/Users/piotr/projects/neptune-sandbox/.env/lib/python3.8/site-packages/tensorflow/python/keras/callbacks.py", line 231, in <genexpr>
    cb._implements_train_batch_hooks() for cb in self.callbacks)
AttributeError: 'BaseLogger' object has no attribute '_implements_train_batch_hooks

I hope this helps!

Versions:
tensorflow==2.2.0
Keras==2.3.1

Minimal example:
import neptune
from tensorflow import keras

# this is an import from standalone Keras, as opposed to the Keras shipped with TF
from keras.callbacks import BaseLogger

mnist = keras.datasets.mnist
(x_train, y_train), (x_test, y_test) = mnist.load_data()
x_train, x_test = x_train / 255.0, x_test / 255.0

model = keras.models.Sequential([
  keras.layers.Flatten(),
  keras.layers.Dense(100, activation=keras.activations.softmax)
])

model.compile(optimizer='adam',
              loss='sparse_categorical_crossentropy',
              metrics=['accuracy'])

model.fit(x_train, y_train,
          epochs=5,
          batch_size=256,
          callbacks=[BaseLogger()])

Output and error:
Using TensorFlow backend.
2020-06-19 10:32:15.050829: I tensorflow/core/platform/cpu_feature_guard.cc:143] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA
2020-06-19 10:32:15.069239: I tensorflow/compiler/xla/service/service.cc:168] XLA service 0x7ff6bf6ae880 initialized for platform Host (this does not guarantee that XLA will be used). Devices:
2020-06-19 10:32:15.069257: I tensorflow/compiler/xla/service/service.cc:176]   StreamExecutor device (0): Host, Default Version
Traceback (most recent call last):
  File "tf-issue.py", line 18, in <module>
    model.fit(x_train, y_train,
  File "/Users/piotr/projects/neptune-sandbox/.env/lib/python3.8/site-packages/tensorflow/python/keras/engine/training.py", line 66, in _method_wrapper
    return method(self, *args, **kwargs)
  File "/Users/piotr/projects/neptune-sandbox/.env/lib/python3.8/site-packages/tensorflow/python/keras/engine/training.py", line 819, in fit
    callbacks = callbacks_module.CallbackList(
  File "/Users/piotr/projects/neptune-sandbox/.env/lib/python3.8/site-packages/tensorflow/python/keras/callbacks.py", line 230, in __init__
    self._should_call_train_batch_hooks = any(
  File "/Users/piotr/projects/neptune-sandbox/.env/lib/python3.8/site-packages/tensorflow/python/keras/callbacks.py", line 231, in <genexpr>
    cb._implements_train_batch_hooks() for cb in self.callbacks)
AttributeError: 'BaseLogger' object has no attribute '_implements_train_batch_hooks

I hope this helps!

same issue

keras.callbacks.Callback provides no such methods and so using it with e.g. tensorflow.keras.models.Model.fit results in AttributeError: 'SomeClassExtendingCallback' object has no attribute '_implements_train_batch_hooks'.

@PiotrJander,
You are facing this error because of the mixed up imports of keras and tf.keras.
I was able to run the code without any issues using keras, whereas I'm facing an error stating KeyError: 'metrics' on running the code with tf.keras. Please check the linked gist.
For more information, please take a look at this StackOverflow comment. Thanks!

Thank you. I knew this is due to mixing up keras and tf.keras, I just wanted to raise this in case mutual compatibility were a goal.
Perhaps the docs should state visibly that keras and tf.keras are not mutually compatible?

I solved this problem by using tensorflow==1.14.0 and keras==2.3.1

@PiotrJander This is a well known fact in the tensorflow community.
tf.keras is the Tensorflow specific implementation of the Keras API specification. It adds the framework the support for many Tensorflow specific features like: perfect support for tf.data.Dataset as input objects, support for eager execution, ...
In Tensorflow 2.0 tf.keras will be the default and I highly recommend to start working using tf.keras

Sure, we can close this

Using tensorflow.keras instead of keras worked for me. Thanks!

Code:
import pandas as pd
from transformers import BertTokenizer, TFBertForSequenceClassification
from sklearn.model_selection import train_test_split
from sklearn.preprocessing import LabelEncoder
from tensorflow.keras.optimizers import Adam
from tensorflow.keras.callbacks import EarlyStopping, ReduceLROnPlateau

# Load your dataset
df = pd.read_csv('/kaggle/input/complaints10k/indian_railway_complaints_10k.csv')

# Encode the labels
label_encoder = LabelEncoder()
df['label'] = label_encoder.fit_transform(df['Complaint Category'])

# Train-test split
X_train, X_test, y_train, y_test = train_test_split(df['Complaint'], df['label'], test_size=0.2, random_state=42)

# Load pre-trained BERT tokenizer
tokenizer = BertTokenizer.from_pretrained('bert-base-uncased')

# Tokenize the input texts
def tokenize(sentences, tokenizer, max_len=128):
    return tokenizer(
        sentences.tolist(),
        max_length=max_len,
        truncation=True,
        padding=True,
        add_special_tokens=True,  # Add [CLS] and [SEP]
        return_tensors='tf'       # Return TensorFlow tensors
    )

X_train_tokenized = tokenize(X_train, tokenizer)
X_test_tokenized = tokenize(X_test, tokenizer)
# Load BERT model for sequence classification
model = TFBertForSequenceClassification.from_pretrained('bert-base-uncased', num_labels=len(categories))

# Compile the model
# optimizer = Adam(learning_rate=2e-5)
model.compile(optimizer= 'adam', loss='sparse_categorical_crossentropy', metrics=['accuracy'])
from tensorflow.keras.callbacks import EarlyStopping, ReduceLROnPlateau

# Define EarlyStopping and ReduceLROnPlateau callbacks
early_stopping = EarlyStopping(monitor='val_loss', patience=3, restore_best_weights=True)
reduce_lr = ReduceLROnPlateau(monitor='val_loss', factor=0.2, patience=2, min_lr=1e-5) #reduce learning rate when mteric not improving

# Train the model
history = model.fit(
    train_dataset,
    validation_data=val_dataset,
    epochs=3,
    callbacks=[early_stopping, reduce_lr]
)

Output:

AttributeError                            Traceback (most recent call last)
Cell In[76], line 8
      5 reduce_lr = ReduceLROnPlateau(monitor='val_loss', factor=0.2, patience=2, min_lr=1e-5) #reduce learning rate when mteric not improving
      7 # Train the model
----> 8 history = model.fit(
      9     train_dataset,
     10     validation_data=val_dataset,
     11     epochs=3,
     12     callbacks=[early_stopping, reduce_lr]
     13 )

File /opt/conda/lib/python3.10/site-packages/transformers/modeling_tf_utils.py:1229, in TFPreTrainedModel.fit(self, *args, **kwargs)
   1226 @functools.wraps(keras.Model.fit)
   1227 def fit(self, *args, **kwargs):
   1228     args, kwargs = convert_batch_encoding(*args, **kwargs)
-> 1229     return super().fit(*args, **kwargs)

File /opt/conda/lib/python3.10/site-packages/tf_keras/src/utils/traceback_utils.py:70, in filter_traceback.<locals>.error_handler(*args, **kwargs)
     67     filtered_tb = _process_traceback_frames(e.__traceback__)
     68     # To get the full stack trace, call:
     69     # `tf.debugging.disable_traceback_filtering()`
---> 70     raise e.with_traceback(filtered_tb) from None
     71 finally:
     72     del filtered_tb

File /opt/conda/lib/python3.10/site-packages/tf_keras/src/callbacks.py:245, in <genexpr>(.0)
    237 # Performance optimization: determines if batch hooks need to be called.
    239 self._supports_tf_logs = all(
    240     getattr(cb, "_supports_tf_logs", False) for cb in self.callbacks
    241 )
    242 self._batch_hooks_support_tf_logs = all(
    243     getattr(cb, "_supports_tf_logs", False)
    244     for cb in self.callbacks
--> 245     if cb._implements_train_batch_hooks()
    246     or cb._implements_test_batch_hooks()
    247     or cb._implements_predict_batch_hooks()
    248 )
    250 self._should_call_train_batch_hooks = any(
    251     cb._implements_train_batch_hooks() for cb in self.callbacks
    252 )
    253 self._should_call_test_batch_hooks = any(
    254     cb._implements_test_batch_hooks() for cb in self.callbacks
    255 )

AttributeError: 'EarlyStopping' object has no attribute '_implements_train_batch_hooks'

I am still facing the issue even though I am using tf.keras

Please has there been any way to resolve  this issue :"AttributeError: 'EarlyStopping' object has no attribute" '_implements_train_batch_hooks'. Despite  using from tensorflow.keras.callbacks import EarlyStopping, the issue still persist

The issue still persist for me, we might have to open a new issue

Facing same issue even after using tf.keras also I need tf >2.0 so cannot use the downgrade solution as well (pip install --upgrade "tensorflow==1.4" "keras>=2.0")


Fixed README.md

A part of the code was not working since it did not call to any variable in the mqtt module (on line 385)
Adding "mqtt_" would make it call a viable variable
PS.
Hoping this is clear enough, as it is my first pull request

I realised the mistake. I should have read the instructions - placing the code under then "handle_telemntry" function makes it viable


[Improvement-14080][script] cleanup dist directory at the beginning of check-LICENSE.sh

Purpose of the pull request

close: #14080

Brief change log

cleanup dist directory at the beginning of check-LICENSE.sh
Avoid the interference of the pre-existing dist directory on the LICENSE check results

Verify this pull request

This pull request is code cleanup without any test coverage.

Hi, @kezhenxu94 ,could you please help review this?

Codecov Report

Merging #14081 (7c70d18) into dev (f1e7862) will decrease coverage by 0.03%.
The diff coverage is 46.34%.

:exclamation: Current head 7c70d18 differs from pull request most recent head b1158b9. Consider uploading reports for the commit b1158b9 to get more accurate results

@@             Coverage Diff              @@
##                dev   #14081      +/-   ##
============================================
- Coverage     38.41%   38.39%   -0.03%
+ Complexity     4476     4452      -24
============================================
  Files          1228     1223       -5
  Lines         42733    42497     -236
  Branches       4727     4681      -46
============================================
- Hits          16417    16316     -101
+ Misses        24504    24381     -123
+ Partials       1812     1800      -12

Impacted Files
Coverage Δ

...duler/plugin/storage/hdfs/HdfsStorageOperator.java
19.86% <0.00%> (+0.40%)
:arrow_up:

.../plugin/task/api/parameters/K8sTaskParameters.java
0.00% <ø> (ø)

...server/worker/utils/TaskExecutionCheckerUtils.java
7.69% <0.00%> (-0.36%)
:arrow_down:

...nscheduler/service/process/ProcessServiceImpl.java
31.01% <11.11%> (+0.55%)
:arrow_up:

...ache/dolphinscheduler/plugin/task/k8s/K8sTask.java
83.87% <75.00%> (-3.09%)
:arrow_down:

...heduler/api/service/impl/ResourcesServiceImpl.java
43.75% <100.00%> (+0.05%)
:arrow_up:

...che/dolphinscheduler/dao/utils/TaskCacheUtils.java
86.76% <100.00%> (ø)

...heduler/plugin/storage/gcs/GcsStorageOperator.java
35.96% <100.00%> (+0.72%)
:arrow_up:

...heduler/plugin/storage/oss/OssStorageOperator.java
36.00% <100.00%> (+0.65%)
:arrow_up:

...scheduler/plugin/storage/s3/S3StorageOperator.java
34.49% <100.00%> (+1.54%)
:arrow_up:

... and 2 more

... and 40 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Hi @rickchengx you can directly restart the failed tests because you are a member of this this repos


Multiple values of a HTTP header are reduced to one value.

If a HTTP response header has multiple values, these are reduced by class RestfulResponse to the last value (a non multi value map is used to collect the values). The class also returns this non multi value map so that the corresponding HttpServletResponse or JAX-RS Response is only populated with this value. The patch solves this issue and provides all header values.

Coverage increased (+0.03%) to 74.581% when pulling 35c440b7479d259b23b7edcf4b34696ec134d562 on volsch:master into 979b1287d085ed1407f576810b65313d962701a6 on jamesagnew:master.


Here I have made further modifications to allow for no solver check

QC

[ ] The PR contains a test case for the changes or the changes are already covered by an existing test case.
[ ] The documentation (docs/) is updated to reflect the changes or this is not necessary (e.g. if the change does neither modify the language nor the behavior or functionalities of Snakemake).

LGTM!


isOptional not work correctly

When using isOptional for the last step - it does not work properly
isAsync: false,
isOptional: true

Fixed in v8.0.1.
Let me know if it works as expected for you now.


Add test PBA search script, remove dataset assumptions

Add scripts/test_search.sh to test with random noise data and 224x224 image size. Removes many hardcoded assumptions about SVHN or CIFAR. Adding a new dataset should now only require loading the data arrays in the dataloader object of pba/data_utils.py
(needs lint)

Tested on R-SVHN search and retraining with R-SVHN on WRN-28-10.


[Android] [iOS] Change speaker does not work when headphones are used

Environment:
SDK Version: 3.6.1
Client Platform: Flutter test app. Samsung S22 + Android 12
Description/Steps-to-reproduce:
-Install the QA test app
-Connect to the conference (There is no difference if you use Bluetooth or USB-C headphones or lightning headphones)
-Use "Change speaker" option
Expected result:
"Change speaker" option works, audio is audible on speakerphone.
Actual result:
"Change speaker" option does not work, audio is audible only on headphones.
Devices:
Any Android and iOS device

This standard behavior for the ioS native sdk, and this behavior was copied to Android. Since we cannot change native SDK behavior in Flutter, we are closing this issue.


verify Avalanche Router on mainnet

Please verify the avalanche Router address:  0xd8df34A071179fe8CEF910Ae0B43cdE49D611B49 on mainnet. You will need to checkout to the last commit before the deployment https://github.com/LimeChain/hashport-contracts/commit/c26ee046feafad8f8ee87c964aaec731bc51f8ed and pass the same order of the facets as in the router constructor.

Already verified


Request signing with strong consistency does not work

We are continuously addressing and improving the SDK, if possible, make sure the problem persist in the latest SDK version.

Describe the bug
A read request with strong consistency with request signing enabled does not work - the head request isn't signed with the key
To Reproduce
Enable gateway signing, do a concurrent read/write workload with strong consistency. You'll see 403 in the internal sdk calls.
Expected behavior
A clear and concise description of what you expected to happen.
Actual behavior
Provide a description of the actual behavior observed.
Environment summary
SDK Version:
OS Version (e.g. Windows, Linux, MacOSX)
Additional context
Add any other context about the problem here (for example, complete stack traces or logs).

Simple test case validation showed that signinghandler is called as expected for both write and reads.

Head/HeadFeed for Collection/Database are the ones having issues.
One suspicion is BarrierReqeustHelper.
@ausfeldt can you please look into it further?

The workaround is the add the header the same way as ComputeTransportHandler.cs in Microsoft.Azure.Cosmos.Friends for Direct Mode. For Gateway the header will have to be added using "internal HttpMessageHandler httpMessageHandler" on DocumentClient


How do we know a project should have CI?

@RichardLitt said in https://github.com/ipfs/project-repos/issues/25#issuecomment-168011391:

Travis and CI aren't needed for some repos, and they are in the list twice. Perhaps we could have a 'Travis not enabled' instead of 'Build unknown'? Would remove two columns we'd no longer need.

The two Travis colums are actually different... One is the build status, and one is whether the Travis badge is in the readme.
Better button text sounds fine, feel free to PR, preferably with similar styling to the buttons, and probably grey color.
Since, as you point out, CI is not needed on all repos, we should not turn the latter column red, if there is no CI at all. Unfortunately, this looks roughly the same as a project that has code and tests but has set up zero CI, which we would like to "mark red".
We could say if it contains code (JS, go, rust, etc) it needs CI, and  mark it red if it has none.  This may be a bit of work ; )
Thoughts?
Should all repos that contain code have CI?

I think you should check for a CI Badge, and leave it at that. There should be a CI badge on all relevant repos, at this point.

Regarding Travis and 'build unknown', Getting a better button seems harder than I expected. For now, let's just leave it as it is.
Rethinking the CI; Do the tests fail if there are no tests set up? Should we test everything?

Rethinking the CI; Do the tests fail if there are no tests set up? Should we test everything?

Probably not.  We have a lot of random repos, eg: https://github.com/ipfs/POST

Those can be cleared out by searching for 'discussion repo' badges, which I should have added to all of them.

OK. Can we check for code in a repository using https://github.com/github/linguist, and then automatically disqualify all non-code repositories? Everything else should have CI or Travis, right?

Or could we just search for a .travis.yml or a circle.yml and leave it up to the project heads to make sure that these exist?

OK. Can we check for code in a repository using https://github.com/github/linguist, and then automatically disqualify all non-code repositories? Everything else should have CI or Travis, right?

👍  this sounds perfect.  Maybe language is in the repo object returned by Octokat?

Or could we just search for a .travis.yml or a circle.yml and leave it up to the project heads to make sure that these exist?

👎  I don't think so... part of the idea of this project is to watch all the repos and make sure they are all following our guidelines...

Boom! It looks like that is in the language object returned by Octokat. For https://api.github.com/repos/ipfs/ipfs, it shows language: null - same for ipfs/pm, ipfs/apps. For anything with code on it, it shows the main language of code. I think we can assume that if there is a language, it should have code, and it should have CI.
We should also check in case there is a .travis.yml or circle.yml, too: for instance, ipfs/awesome-ipfs has no code, but I have travis running to make sure that links aren't broken in any PR.

Awesome.  So if no CI is found, we leave the CI column blank for language=>null repos, but put a "CI missing" badge in if language=>something.


Provide a JSON-option for the CLI.

Some people may want to process the found problems automatically by some script. Providing the problems as a json may make things much simpler for them.

Done


Settings editor not showing inherited values in workspace scope

VSCode Version: 1.27
OS Version: Windows 10 1803

Steps to Reproduce:

Set some value to true in your user settings, like editor.formatOnSave:

Open settings editor, switch to Workspace Settings, you will see the item is unchecked but showed (modified by user):

If you want to set editor.formatOnSave to false in this workspace, there's no way to achieve this. If you check & uncheck the item, there will only be an empty settings.json file in .vscode folder:

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

That's correct - we decided to consider this an "advanced" feature that you can still configure in the json file, but not in the settings UI.
Showing a setting that's configured to its default value is a confusing UI experience, I'm still open to supporting this in the future though.

According to settings override order (Workspace Settings > User Setting > Default Settings), shouldn't workspace settings editor showing values inherited from user settings? If so, we can override values in workspace settings editor.

I thought it would be less confusing to show always show the default unless a setting is modified in that scope.

Since there's a notice after the item (Modified in: User), I thought this won't be that confusing for users. These two settings (User and Workspace) are not parallel, so maybe we don't need to show default values in both editor?

From #58901

(not sure if this is a feature request or a bug, since it was intentional)
Default settings may change.
When users explicitly set a setting to a value, they expect to have a guarantee that the setting they chose explicitly will not change in the future, even if the default happens to change.
However, when you use the new settings editor to change a setting back to a value that happens to be the default, it removes the setting from the json.
This is not only wrong, but also unnecessary, since the settings editor already has a simple way to track modified settings and reset a setting to its default value:

I strongly think the current behavior is incorrect, because these two things are completely different when we think about user intention:

explicitly wanting a value that happens to be the default
accepting whatever the default is for that setting

An example of why I think this sort of thing is important:
https://money.cnn.com/2018/06/07/technology/facebook-public-post-error/index.html
It may be an extreme example, but you get the point.
This incorrect behavior is the sole reason I was still using the json to edit my settings, and it became more of a concern now that the new editor is the default.
The correct behavior should be:

When setting the value explicilty, mark the setting as modified/overriden and keep the setting in the json, even if it happens to be equal to the default. The user wants the guarantee that the setting will have THAT value, and a way to remember that such value was explicitly chosen by them.
When choosing "Reset Setting", remove the setting from the json, because the user wants to accept whatever the default is, even if it changes later. Mark the setting as not modified/overriden.

If possible, change the text and semantics of "modified" settings to "overriden" settings.

I agree that this is confusing. I think that supporting this for power users could also be confusing for newer users. Imagine if they click a checkbox on a bool setting to modify it, then click it again to "unmodify" it. Most people won't expect that action to have side effects, but it would have the side effect of writing the default value to the JSON.
I want to keep thinking about and discussing this, but I am also putting the experience for new users first in the UI.

Well, if a user checks and unchecks a setting, they will immediately notice that the setting now has a blue line, which wasn't there before. Even new users that don't know the exact meaning of the blue line will at least notice that something changed and didn't unchange.
If this wasn't intended, the first thing they will do (after possibly trying CTRL+Z) is look inside the gear icon. This is the intuitive thing to do, because its the only button related to the setting apart from the setting itself.
Even if they don't notice the change, or even if they don't get that the blue line means that there was some sort of change, I still believe strongly that the current behavior is not right. The side-effect of erasing a setting you had explicitly chosen before is more unexpected (even for experienced users) than the side-effect of adding and keeping a setting you explicitly just messed with.
Specially because there is also a separate reset button, so you wouldn't expect that explicitly setting something could also reset it.

Even new users that don't know the exact meaning of the blue line will at least notice that something changed and didn't unchange

Yes but that's not a good thing, because they will be confused.

If this wasn't intended, the first thing they will do (after possibly trying CTRL+Z) is look inside the gear icon.

I disagree. I think many users will never notice or explore the context menu.
A checkbox is the simplest control in the world. It works the same on every form or in every settings page in every app, everywhere. If we change its behavior by introducing a mysterious third state, controlled by a different command in a hidden menu, we risk making users feel like they don't understand how a checkbox works. And if they don't understand even a checkbox, they will feel like they can't understand anything. This is why I want to proceed with caution.

Ok then, how about erasing the setting only if it wasn't already there before the settings tab was first open?
Then the current behaviour can be mantained, while people that already have a custom setting won't risk losing it unless they use the reset button.

My previous comment was for user settings.
In the specific case of this issue, (not being able to override the Workspace setting) this solution (an override checkbox before each setting) would solve it better, I think.

@RedTailBullet had a good suggestion, that the default in the Workspace settings would match the configured value in the User settings. So here's how I interpret this:

Starting clean with no configured settings
Open User settings, see editor.insertSpaces is checked by default
Open Workspace settings, editor.insertSpaces is checked by default
Go back to User settings uncheck editor.insertSpaces. It gets the blue modified indicator
Switch to workspace settings, find editor.insertSpaces, it appears unchecked by default, and doesn't have the modified indicator
Click the checkbox, now it is checked and has the modified indicator

This is an interesting idea because it preserves "normal" checkbox behavior, it is transparent about the value at "this" scope (not taking the folder-level scope into account), and makes it easy and natural to override a value to the "default".

@RedTailBullet had a good suggestion, that the default in the Workspace settings would match the configured value in the User settings. So here's how I interpret this:

Starting clean with no configured settings
Open User settings, see editor.insertSpaces is checked by default
Open Workspace settings, editor.insertSpaces is checked by default
Go back to User settings uncheck editor.insertSpaces. It gets the blue modified indicator
Switch to workspace settings, find editor.insertSpaces, it appears unchecked by default, and doesn't have the modified indicator
Click the checkbox, now it is checked and has the modified indicator

This is an interesting idea because it preserves "normal" checkbox behavior, it is transparent about the value at "this" scope (not taking the folder-level scope into account), and makes it easy and natural to override a value to the "default".

Thanks roblourens! That's exactly what I mean.

One thing as well, the actual config.json for workspace setting should also be based on user settings.
For example:

In user setting, the editor.insertSpaces is unchecked (which is not the default).
In workspace setting, the editor.insertSpaces is checked again (which is the global default), and the json of the workspace setting actually have editor.insertSpace: true.

From the manual:

Workspace settings override user settings.

See: User and Workspace settings

I agree with @SetTrend: "user settings differ from user to user, whereas workspace settings don't".
I'm having an issue with "Trim Trailing Whitespace". I like to used it in all my projects, but if you want to contribute in a project with some whitespaces and you save, a lot of lines have changed. Right now my only option is to disable it on the User settings, hope I don't forget to turn it on again...

Setting the workspace to the default value does not override the user settings. This is a very confusing behavior.
When I use the UI settings, if I don't pay attention, I will break my workspace settings
The UI settings of the workspace are displayed as inherited values will be better.

I just ran into this nonsense. :( Workspace settings must override user settings, at least for linters.

I'm also confused. My workspace settings should surely override my user settings?? Why wouldn't this be the expected behaviour?

I got into this issue as well while testing the "remote - ssh" extension. On my laptop, I've a user setting that defines where to find linters in Python (e.g. path to flake8). On the remote machine, I would like to define this path to "flake8" for this workspace, but I can't because it's the default value assumed by vscode. I currently have no way to specify that for this specific workspace, I would like "flake8" (the default value in vscode) to override the value I put in my user settings.

I got into this issue as well while testing the "remote - ssh" extension. On my laptop, I've a user setting that defines where to find linters in Python (e.g. path to flake8). On the remote machine, I would like to define this path to "flake8" for this workspace, but I can't because it's the default value assumed by vscode. I currently have no "direct way" (using the UI) to specify that for this specific workspace, I would like "flake8" (the default value in vscode) to override the value I put in my user settings.

To workaround you can change the setting editor to split json mode by setting below two options:
  "workbench.settings.editor": "json",
  "workbench.settings.useSplitJSON": true,

Then you can override your settings in workspace tab manually:

Thanks @yhvicey !

You don't have to use the deprecated "split" json editor for this. Use the command "Open Settings (JSON)" or the button in the corner of the settings GUI that opens the backing JSON file.

Can't override a setting to turn off format-on-save in Workspace settings if it's set to on in User settings. Blue "overrides User settings" line appears when you check the box (which is wrong because the override is the same as the User setting) but it disappears when you uncheck the box, which is now a different setting from the User setting.
If the Workspace is inheriting a User setting then that setting should be displayed in the Workspace settings unless it's overridden. A checked User setting should appear checked in Workspace, and when the unchecked, it should have the blue line indicating that it differs.

@roblourens Don't you think it's more confusing to show a value that doesn't apply in Workspace Settings (UI) than to explicitly setting a value to the same as default? Considering that Workspace Settings are supposed to override all other settings?
I haven't looked at the code but it seems that:

Workspace Settings (UI) will show the default value unless specifically set in Workspace Settings (JSON). Regardless of whether the User Settings are overriding the Default Settings.
Workspace Settings (UI) will also only write to Workspace Settings (JSON) if the value is different from the default value. It will delete the setting from Workspace Settings (JSON) if it is the same as Default.

The first issue is handled to some degree by (Modified in: User). Considering Workspace Settings are supposed to override User Settings it's not very intuitive that being modified in User Settings means it overrides the setting shown in Workspace Settings (UI). It would be clearer if it showed (Overridden by: User). Even better would be to show the actual value applied to the workspace and where it's been set. As in (Set in: User)/(Set in: Default). For text input settings the applied value could be set as placeholder rather than value.
I think the second issue is worse. Why make it make it impossible to make the workspace explicitly use the default setting through Workspace Settings (UI)? The only benefit with the current behaviour seems to be that it is possible to disable the Workspace Setting so that the User Setting is applied.

This violates the principle of least surprise IMHO.

I just ran into this issue. From my point of view, on https://code.visualstudio.com/docs/getstarted/settings text
Workspace settings override user settings.

should be removed, because it is simply not true.
Can someone give approximate estimate for this issue resolution?

+1

Currently to force the default value to override a user setting for a workspace you need to:

Click the gear icon next to the setting
Click "Copy Setting as JSON"
Open the workspace's settings.json file
Paste the default setting (that was copied in step 2) between the brackets

Proposed Solution
Add an additional option to the gear menu that says something like "Force default value" or have clickable text next to the setting (if the default is selected) that says "Force default" or "Override user setting".
Clicking any of these would be a shortcut to doing the manual steps above.
Also it would be helpful to show the actual active setting.
How about if the active value for a setting does not equal the value you are looking at, have a message like Active value is currently: onFocusChange appear next to or under the setting.

I agree, this is confusing. Please make workspace overriding more user-friendly. I was just trying to modify workspace settings and wondering why this doesn't work at all and googled to find this issue.

Is there any ETA for this? Even when I paste the JSON on my settings.json like @mattgaspar said the change does not override because the hierarchy rule is Workspace > User.

This has been driving me nuts and I've probably sunk at least 20-30 minutes over the course of several months figuring out what VSCode was doing. I had no idea the setting wasn't actually being pushed to the JSON. It's not best practice for a UI to randomly make an opaque exception like this, not do what the user is asking it to do, and provide no feedback about why it did that. Perhaps you guys could show an error message saying "Setting change was not successful. This setting needs to be overriden directly in the JSON because of _____." I also find it strange that this particular functionality is hostile toward UI settings users but not JSON settings users. Why? That's weird.

We have more than 20 upvotes on this issue now. Just like with this issue.
What is the further process of this improvement request? Is the "20 upvotes limit" just a mirage?

We have more than 20 upvotes on this issue now. Just like with this issue.
What is the further process of this improvement request? Is the "20 upvotes limit" just a mirage?

We have more than 20 upvotes on this issue now. Just like with this issue.
What is the further process of this improvement request? Is the "20 upvotes limit" just a mirage?

@SetTrend the 20 upvote thing is only relevant for an issue that was classified by a team member as 'Backlog Candidate'. Then, getting 20 upvotes on the initial post within 60 days would move it automatically to 'Backlog'. Still no guarantee of implementation, but arguably better than being in limbo, tagged as 'feature-request'.
@roblourens please move this to Backlog. Judging by the number of other issues that have referenced it over the years, this behaviour continues to confuse and surprise people.

We have more than 20 upvotes on this issue now. Just like with this issue.
What is the further process of this improvement request? Is the "20 upvotes limit" just a mirage?

@SetTrend the 20 upvote thing is only relevant for an issue that was classified by a team member as 'Backlog Candidate'. Then, getting 20 upvotes on the initial post within 60 days would move it automatically to 'Backlog'. Still no guarantee of implementation, but arguably better than being in limbo, tagged as 'feature-request'.
@roblourens please move this to Backlog. Judging by the number of other issues that have referenced it over the years, this behaviour continues to confuse and surprise people.

<<< Look at this clown thinking his workspace settings were enforced on his team members.
Please fix this :)

Coupled with vscode-python#7314, it is impossible to enable Pylint without manually editing settings.json. Allowing user-toggled settings to persist would mean I would have never encountered the other issue (as I toggled the Pylint setting prior). It also protects against similar bugs where a default is not correctly interpreted, providing the user toggles the setting.
Replying to https://github.com/microsoft/vscode/issues/58038#issuecomment-423002429

I disagree. I think many users will never notice or explore the context menu.

I know I am not "many users", but I personally did look at the setting to reset values - without realising that VSCode doesn't allow you to explicitly set the default value without editing settings.json. As suggested by others, a "reset" button (e.g. the revert circular arrow) coupled with the already-present blue bar would be more than sufficient in my opinion.
Also extremely confusing to me was the fact that Workspace settings, while inherited from User settings, display the VSCode default if inherited from User settings, rather than the User value if defined. The Modified in: User label suggests it's displaying the value of the User setting, but this is not the case.

Hello
I confirm this behavior is not logical, as configuration are cascaded then default value depend to hierarchic value not to main default value.
In my case I spent some time to use some option set in my project to my workspace. I've not understood how enable correct option and edit json file is not a friendly feature when anywhere we can edit it. Option displayed was not option used by vscode in the context. We get then an incoherence.
Could be nice to display config value following cascading context and be coherent.
Thanks a lot :)

I thought it would be less confusing to show always show the default unless a setting is modified in that scope.

This is where this all went wrong. I don't see any reasoning to back up this idea.
If a user cares what the default is, they will look for that information somewhere else (some default label next to something - not in the same place the setting is set).
Most of the time, if a user is in the settings editor, they don't even care what the default is. They just know what they want and are trying to set it to that.
There is no reason to be showing the default in the place where the setting is set.
If it isn't modified in this scope, it should show whatever is inherited.
If you care about showing the default, put that somewhere else.

Whether or not the behavior is changed here, I think the docs could be improved. In https://code.visualstudio.com/docs/getstarted/settings it says:

Workspace settings override user settings. Workspace settings are specific to a project and can be shared across developers on a project.

It seems like it would helpful to add a sentence or two, perhaps as a note, saying something like:

Note: you cannot use the settings editor create a workspace setting that matches the setting's default value. If you are trying to ensure that when in a workspace, a particular setting has its default value even if users configure it, you must add it to the workspace settings file manually.

This one is +1 from me. I have the Python extension configured to lint files with MyPy at the User scope (with custom arguments list), and I thus expected these settings to apply to every new project I'd open, and I was honestly surprised to learn that "Workspace scope overwriting User scope" would pretty much revert these settings back to default, forcing me to repeat the exact same configuration in the current workspace, and any other workspace I'd open. I don't think that's how it should work.
I'm fine with workspace settings overwriting user settings, but if there's no workspace setting configured, user scope settings should be applied instead of the default.

@DevilXD it works exactly in a way you described, you don't need to repeat any configuration. This issue is about not being able to revert default settings in the Workspace scope, when modified in the User scope, from the Settings UI.

@jaklan For some reason it didn't do so, until I set them in the workspace. Not sure what that was about then.

Whether or not the behavior is changed here, I think the docs could be improved.

I've opened a docs PR with the above suggestion: https://github.com/microsoft/vscode-docs/pull/5190

When will this be fixed?

Starting from tomorrow's Insiders release, users should be able to add settings to the workspace file that stay there until manually reset.
The default values the settings display in the event that they have also been modified in the user settings will still be the default values rather than the user values for now, though.

If I set the User setting tab size to 3 (a non-default value), the Workspace setting shows 4 (the default value) in the UI, but behaves as if tab size is 3 in the editor.
My desire is to use 4 the default value for Workspace, but keep 3 in the User setting. The workaround is to manually put
{...
	"settings": {
		"editor.detectIndentation": false,
		"editor.tabSize": 4
...}

In the workspace settings files.
Is this caused by the same issue?

What's the status on this?
I would expect workspace settings to override user settings (how else can we enforce any settings for the team working on a codebase?). If you're worried about this being a breaking change, how about releasing it as an opt-in setting initially?

At the risk of being a "+1", I ran into this again due to https://github.com/microsoft/vscode-mypy/issues/184 (I originally hit this in June 2021 with Pylint).
Workspace settings UI continued to show me it was set to useBundled even though my User settings are fromEnvironment (the latter causing the extension to error out due to the linked issue).
At least now I can change the setting to fromEnvironment and then back to useBundled now and it will persist, rather than having to edit the JSON - thanks! 😅

This issue still exists for remote scope.


Updated validations.py python script

Fixed the behavior of validate_user function in validations.py
Closes: #1
Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

Here I have modified validations.py.


Release 4.7.0 for Windows

Add eight audio players of Tropical Thunderstorm & Rain Sounds For Sleeping, Relaxing ~ Rumbling Storm Equatorial Ambience.

https://github.com/kkamara/kelvinkamara/releases


fix(ds): allow destroy early during retry backoff

Fixes RVT-4415
Changes

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#1718  👈 (View in Graphite)
#1717
#1716
#1715
#1714
#1712
#1711
#1710
#1709
#1708
#1707
#1706
#1695
main

How to use the Graphite Merge Queue
Add the label merge-queue to this PR to add it to the merge queue.
You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has required the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.


Enhancements to Word Loom—item metadata

Having spent some time working with Word Loom lately, I have a few enhancements in mind. @chimezie, would love your thoughts.
First of all, I'd like to to formalize the name "language item" (just "item" for short) for each entity that's specified with a TOML table.
I'd like to add support for language item metadata. In effect, any other key/value pairs within the TOML table for an item would be passed in as metadata associated with that item to the Word Loom implementation. There is actually an example of this already in the Word Loom "spec" ([i18n_context] / source), but I completely omitted any discussion of that. I would just add the formalization that it would be preserved as item metadata. Such metadata would support e.g. control features for how language items are selected & processed for LLM prompts.
Then probably the most controversial bit. In order to lower the footprint of English language in Word Loom, and also free up a couple of other metadata keys, I would deprecate the text key in favor of just _ (inspired by gettext) and deprecate the markers key in favor of _m.

Oh, I would also say that all keys starting with _ are reserved for (possibly future) Word Loom-specced use.

Furthermore, alternate languages would be specified using _ followed by an IETF language code, e.g. _fr.

Above commit implements changes discussed above (on a branch until agreed & ready 😊)

TOML table metadata would be a welcome addition for declarative prompt composition using Word Loom. Deprecating the text and markers keys in that way makes sense, given the proposal for indicating metadata and seems justified as a breaking change.


Is there a way to send the log messages to server(api)?

If yes, can you point me to an example?

If this is a needed feature, I can send a PR for remote logging @langley-agm

Hi Guys,
Thanks for the interest.
This can't be done native atm.
It is planned with the Appenders functionality down the road.
Basically you configure an appender to an specific logger, this appender can be a console appender, or something else, in this case I was planning an http appender of some sort that instead of sending the messages to the console would send them to an specific configured url.
I accept PRs if its tied to this road, but consider that right now no decision has been made whether we'll keep creating Loggers by injecting them or through something like this:
LoggerFactory.getLogger()
And this is a big part of how to configure them and add appenders to them.
A work around would be to create a wrapper of the Logger and inject that instead.
This wrapper would extend the Logger, call the parent's methods and then post the specific message.

+1 for "create a wrapper of the Logger and inject that instead". This also protects you mostly from future API changes.

I like it how ng2-translate solves this:
@NgModule({
    imports: [
        BrowserModule,
        HttpModule,
        TranslateModule.forRoot({
            provide: TranslateLoader,
            useFactory: (http: Http) => new TranslateStaticLoader(http, '/assets/i18n', '.json'),
            deps: [Http]
        })
    ],
    bootstrap: [AppComponent]
})
export class AppModule { }


youki: 0.3.2 -> 0.3.3

Description of changes
Updates the unmaintained (in nixpkgs) youki to v0.3.3.
Also updates the time crate in Cargo.lock with a patch, because of the build failure with Rust 1.80 (see https://github.com/NixOS/nixpkgs/issues/332957 for more information about the issue). I've already created an issue in youki, so this patch will be removed with the next version update PR.
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Timeout on aarch64-linux is strange… any idea what's up?

That's weird, yeah... I don't know whats up and unfortunately cannot test it (don't have an aarch64-linux machine).
The logs don't seem to contain useful information except for the message that a timeout occurred.


[RESOLVED] Interface eth0(): High error rate (>2 for 5m)

Problem started at 14:30:29 on 2023.08.07
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Operational data: errors in: 1, errors out: 0
Original problem ID: 34666
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23483&eventid=34666

Problem has been resolved in 3m 0s at 14:33:29 on 2023.08.07
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Original problem ID: 34666


[FEATURE] system 中添加Option

//windows 执行时隐藏执行窗口
system.ExecCommand(command string, system.WithWinHide())
//...

Codecov Report
Patch coverage: 9.09% and project coverage change: -1.10 :warning:

Comparison is base (8bdd46b) 82.81% compared to head (658f289) 81.71%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #87      +/-   ##
==========================================
- Coverage   82.81%   81.71%   -1.10%
==========================================
  Files          56       58       +2
  Lines        5248     5365     +117
==========================================
+ Hits         4346     4384      +38
- Misses        674      742      +68
- Partials      228      239      +11

Impacted Files
Coverage Δ

system/os_linux.go
0.00% <0.00%> (ø)

system/os.go
70.17% <25.00%> (-3.90%)
:arrow_down:

... and 2 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


/ping overhaul

Is your feature request related to a problem? Please describe.
Not exactly, but fixes the 48h role limit.
Describe the solution you'd like
Instead of creating roles for each subject, just ping the channel with /ping #course.
This would fix the problem of discord locking the bot and it gets rid of the gigantic wall of roles in server management.

Yes, good idea!
But when a channel is "pinged"directly then the bot should not ping everyone any more, since this could happen out of context.
This is totally fine though.

Just thought a bit more about it. This would break /join, because channels are not being suggested if you re not part of them.