load_model(filename) fails on weight ordering if sublayer .trainable is modified after init

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): macOS, Darwin-19.3.0-x86_64-i386-64bit, mac version: ('10.15.3', ('', '', ''), 'x86_64')
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): v1.12.1-26991-g5a6ae102f0 2.2.0-dev20200311
Python version: 3.7.6

Describe the current behavior
Creating a layer and then setting layer.trainable = False (after creation) and then creating a model using that layer and saving that model with model.save(filename), and then loading that model with tf.keras.models.load_model(filename, custom_objects=...), fails because weights ordering for the layer is inconsistent.
Describe the expected behavior
I expect to be able to load a model I saved, despite having changed the trainable attribute on some layer before compiling and saving. (The trainable attribute is documented, with no warning that it must not be mutated, nor is there any runtime warning about this.)
Standalone code to reproduce the issue
import tensorflow as tf
from tensorflow import keras

class LayerWithSublayers(keras.layers.Layer):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.embedding = keras.layers.Embedding(3, 2)
        self.dense = keras.layers.Dense(4)

    def call(self, inputs, **kwargs):
        return self.dense(self.embedding(inputs))

input_ids = keras.Input(shape=(4,), dtype=tf.int32, name='input_ids')
output_layer = LayerWithSublayers()
output_layer.embedding.trainable = False
output = output_layer(input_ids)

model = keras.Model(inputs=[input_ids], outputs=[output])
model.compile(loss=tf.losses.SparseCategoricalCrossentropy(from_logits=True), metrics=['accuracy'])

model_file_name = 'foo.h5'
model.save(filepath=model_file_name)

loaded_model = keras.models.load_model(model_file_name, custom_objects={'LayerWithSublayers': LayerWithSublayers})

If I change this to pass trainable=False when creating the keras.layers.Embedding, then the model loads just fine. So the problem is that the change of trainable is not reflected when the model is serialized to HDF5 format.
Other info / logs Include any logs or source code that would be helpful to
diagnose the problem. If including tracebacks, please include the full
traceback. Large logs and files should be attached.
Running the above script outputs this traceback:
Traceback (most recent call last):
  File "keras_save_load_h5_nontrainable.py", line 26, in <module>
    loaded_model = keras.models.load_model(model_file_name, custom_objects={'LayerWithSublayers': LayerWithSublayers})
  File "/Users/gbr/.pyenv/versions/NLNIGHTLY/lib/python3.7/site-packages/tensorflow/python/keras/saving/save.py", line 184, in load_model
    return hdf5_format.load_model_from_hdf5(filepath, custom_objects, compile)
  File "/Users/gbr/.pyenv/versions/NLNIGHTLY/lib/python3.7/site-packages/tensorflow/python/keras/saving/hdf5_format.py", line 173, in load_model_from_hdf5
    load_weights_from_hdf5_group(f['model_weights'], model.layers)
  File "/Users/gbr/.pyenv/versions/NLNIGHTLY/lib/python3.7/site-packages/tensorflow/python/keras/saving/hdf5_format.py", line 704, in load_weights_from_hdf5_group
    K.batch_set_value(weight_value_tuples)
  File "/Users/gbr/.pyenv/versions/NLNIGHTLY/lib/python3.7/site-packages/tensorflow/python/keras/backend.py", line 3402, in batch_set_value
    x.assign(np.asarray(value, dtype=dtype(x)))
  File "/Users/gbr/.pyenv/versions/NLNIGHTLY/lib/python3.7/site-packages/tensorflow/python/ops/resource_variable_ops.py", line 842, in assign
    self._shape.assert_is_compatible_with(value_tensor.shape)
  File "/Users/gbr/.pyenv/versions/NLNIGHTLY/lib/python3.7/site-packages/tensorflow/python/framework/tensor_shape.py", line 1117, in assert_is_compatible_with
    raise ValueError("Shapes %s and %s are incompatible" % (self, other))
ValueError: Shapes (3, 2) and (2, 4) are incompatible

when you are passing trainable = True  its works fine with .h5 and when I am changing .h5 with .tf it also load model with trainable = False but model loaded is with trainable = True
 import tensorflow as tf
from tensorflow import keras

class LayerWithSublayers(keras.layers.Layer):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.embedding = keras.layers.Embedding(3, 2)
        self.dense = keras.layers.Dense(4)

    def call(self, inputs, **kwargs):
        return self.dense(self.embedding(inputs))

input_ids = keras.Input(shape=(4,), dtype=tf.int32, name='input_ids')
output_layer = LayerWithSublayers()
output_layer.embedding.trainable = False
output = output_layer(input_ids)

model = keras.Model(inputs=[input_ids], outputs=[output])
model.compile(loss=tf.losses.SparseCategoricalCrossentropy(from_logits=True), metrics=['accuracy'])

model_file_name = 'foo.tf'

model.save(filepath=model_file_name)

loaded_model = keras.models.load_model(model_file_name, custom_objects={'LayerWithSublayers': LayerWithSublayers})

Output :

Total params: 18
Trainable params: 18
Non-trainable params: 0

but in actual with trainable = False model summary be like :

Total params: 18
Trainable params: 12
Non-trainable params: 6

@gthb
I tried to reproduce the issue in colab with TF nightly version.Please, find the gist here.Is this the expected behavior? Thanks!

@ravikyram Thanks for checking it, but when I save mode as .tf instead of .h5 I am able to load mode with trainabe =False but loaded model has params same as with `trainable = True. So is model always loaded with trainable = True ?

@ravikyram

I tried to reproduce the issue in colab with TF nightly version.Please, find the gist here.Is this the expected behavior? Thanks!

This is the behavior I'm reporting as a bug — specifically the result in this cell, ValueError: Shapes (3, 2) and (2, 4) are incompatible. This is caused by trying to assign a value to the wrong variable. That in turn is because the variables are assigned in a single batch operation with the assumption that their order matches the order of variable values in the serialized file, and that assumption is undoubtedly failing because variables are ordered trainable first, then untrainable, and the trainable information is not correctly recorded in the serialized file if the .trainable attribute is assigned after layer creation.

The expected behavior is for the serialized file to get deserialized correctly on load_model, yielding a model identical to the one I serialized.
(Or alternatively, for the .trainable attribute to be a read-only property, or output a warning when assigned to, or at least be documented as not safe to assign to.)

Restoring the trainable value can be tricky.
Say that LayerWithSublayers defines the trainable status of the embedding layer in the class definition, and is saved with the embedding.trainable set to True:
class LayerWithSublayers(keras.layers.Layer):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.embedding = keras.layers.Embedding(3, 2)
        self.embedding.trainable = True

Then the definition of the class is changed so that embedding.trainable is False:
class LayerWithSublayers(keras.layers.Layer):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.embedding = keras.layers.Embedding(3, 2)
        self.embedding.trainable = False

When loading the model with the new definition, should the embedding layer retain it's original trainable status, or should it use the trainable status set in the LayerWithSublayers class?
The current behavior is that we will whatever is returned by  the layer's get_config/from_config (i.e. the latter of the two options). If you want LayerWithSublayers to retain the trainable status of one of its internal layers, then consider adding that to the layer's get_config method.
e.g.
class LayerWithSublayers(keras.layers.Layer):
    def __init__(self, train_embeddings=True, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.embedding = keras.layers.Embedding(3, 2)
        self.embedding.trainable = train_embeddings
    def get_config(self):
        config = super().get_config()
        config['train_embeddings'] = self.embedding,trainable

Restoring the trainable value can be tricky.

Sure, but that's missing the point. Deserialization doesn't just fail to restore the trainable attribute, it fails completely, if the trainable attribute has been changed. This is because the ordering of weights depends on the trainable attribute, and the serialization/deserialization assumes that the ordering is unchanged.

If you want LayerWithSublayers to retain the trainable status of one of its internal layers, then consider adding that to the layer's get_config method.

Sure, I can do that for my own use case, but the point remains that setting trainable to False after initialization quietly causes serialization to write output which then will fail to deserialize. This violates POLA, and causes wasted time as people run long training runs and then can't use the result.
To avoid that, trainable should be a read-only property rather than an attribute — or at the very least should be clearly documented as not safe to mutate after initialization.

A possible workaround (for someone who knows about this gotcha) is to set the .trainable attribute of all layers back to True before serializing. (Untested, but should work.)


[BarChartCard] classname prop is not attached to the top container

What package is this for?

[x] React
[ ] Angular

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to BarChartCard story
Inspect container element
See that className prop is not attached to the top container

Expected behavior
Should be attached to the top container

:tada: This issue has been resolved in version 2.134.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fix decompilation of non-block combined fields

fixes https://github.com/microsoft/pxt-arcade/issues/966
let a = bc.createTest()
a.data = 5
testNamespace.numberArgument(a.data)

goes to

(Fixes decompilation of https://forum.makecode.com/t/combo-attack-and-button-combination-extension/169, decompiles successfully to mostly gray blocks)

Good call, It was just falling through and missing that check


Is androidX supported?

I am using it on androidX enabled Project, if that is what you mean.

Close it if your question is answered.

When androidx is mixed with 'com.android.support.*'，It always comes with errors.
run './gradlew :app:dependencies' in shell,
and you will see:
+--- com.github.barteksc:android-pdf-viewer:3.2.0-beta.1
|    +--- com.github.barteksc:pdfium-android:1.9.0
|    |    --- com.android.support:support-v4:26.1.0
...

Will look into it.. and get back to you.

waiting for the good news from you.

As of right now, there is nothing I can do as I depend on com.github.barteksc:android-pdf-viewer and they haven't migrated yet. If that doesn't happen soon.. I will fork the library and make a jetpack supported one(which is not a recommended way).
Can you explain to me the issue you are facing? because I am using it in a Jetpack enabled project. I could may be help you out?


option to display full path

related to https://github.com/ad-on-is/adonis-autoswagger/issues/47

@ad-on-is can we get this merged?

I did some modifications... you were right in your issue. I don't know what drove me to tell it was by design, but it wasn't... It was meant to show only the path after /controller, but not /home/user/... etc..
I fixed it now. No need to add showFullPath variable.


Why does raleTrackerTaskFileLocation has to be an absolute path?

Very curious, can we allow relative paths?
I want to keep my project working cross systems without modifications, so I do not wish to hardcode this path that includes my username, as it won't work for other computers.

It's just how we coded it. It could definitely be improved to support other paths. I think the issue right now is that it's actually a user setting. If we modified it so that it could also be a launch setting, then you could use things like ${workspaceFolder}.
I'd be happy to accept a PR for this if you're interested in contributing?

Actually Im a bit confused, I see it as a launch config, but
injectRaleTrackerTask was set to true but could not find TrackerTask.xml at:
${workspaceFolder}/tools/RALE/TrackerTask.xml

Hmm. Sorry for the confusion. I was answering from my phone last night, so I was just going off of what I remembered, which is obviously incorrect. :)
So here's the code that handles the raleTrackerTaskFileLocation. Looks like we never handle the ${workspaceFolder} replacements. I think it could pretty easily be updated to support the same replacements as rootDir, outDir, etc...

Thanks! I always assumed these vars get auto-replaced with a single mechanism. I was wrong!
https://github.com/rokucommunity/vscode-brightscript-language/pull/462/files

vscode has a "pre vars replaced" and "post vars replaced" extension hook. We're using the "pre" because of some timing-related reasons. As a result, much of our replacements need to be done manually. We tried switching to "post" a few times, but it kept causing issues.
Ideally, we should update our logic to blanket-replace all values across the entire config. It just hasn't been a high enough priority because our current logic "works".


CSI: PV stuck in terminating state

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
The binaries affected:

[ ] openstack-cloud-controller-manager
[x] cinder-csi-plugin
[ ] k8s-keystone-auth
[ ] client-keystone-auth
[ ] octavia-ingress-controller
[ ] manila-csi-plugin
[ ] manila-provisioner
[ ] magnum-auto-healer
[ ] barbican-kms-plugin

What happened:
I am seeing following in our cluster:
% kubectl get pv|grep Terminating
pvc-0139bbd5-ad48-4e91-a6a9-2abcb97c899b   8Gi        RWO            Delete           Terminating   dapi/kubedb-dapi-postgres-20200325-122153       csi-sc-cinderplugin            7d2h
pvc-039b33f6-65b4-4d43-9bce-f42896d95ec5   8Gi        RWO            Delete           Terminating   dapi/kubedb-dapi-postgres-20200113-000149       csi-sc-cinderplugin            79d
pvc-1245fb92-787b-4509-861d-e0962a0b326a   8Gi        RWO            Delete           Terminating   kapi/kubedb-postgres-prod-20200125-203133       csi-sc-cinderplugin            66d
pvc-1662ce70-7cb1-4b6c-984a-edd23a7116e9   8Gi        RWO            Delete           Terminating   dapi/kubedb-dapi-postgres-20200319-002153       csi-sc-cinderplugin            13d
pvc-1e5c8db1-4d5c-41ae-8f90-19f70ea8e785   8Gi        RWO            Delete           Terminating   kapi/kubedb-postgres-prod-20200103-000136       csi-sc-cinderplugin            89d
pvc-1fd0e6c9-0fb7-4197-84c5-087cbdd93156   8Gi        RWO            Delete           Terminating   dapi/kubedb-dapi-postgres-20200129-083133       csi-sc-cinderplugin            63d
pvc-338a1f69-b387-4d34-8511-ecb8d73f3959   8Gi        RWO            Delete           Terminating   kapi/kubedb-postgres-prod-20200115-000136       csi-sc-cinderplugin            77d
pvc-46057c02-354c-4a8d-ad96-2301e8742375   8Gi        RWO            Delete           Terminating   kapi/kubedb-postgres-prod-20191219-120136       csi-sc-cinderplugin            104d
pvc-6221a6fc-f70d-4e1c-82e7-00e3a083ad31   8Gi        RWO            Delete           Terminating   dapi/kubedb-dapi-postgres-20200322-002153       csi-sc-cinderplugin            10d
pvc-769f4d07-f51d-434b-ad4f-0db645ce8ecc   8Gi        RWO            Delete           Terminating   dapi/kubedb-dapi-postgres-20200203-203133       csi-sc-cinderplugin            57d
pvc-79a22ede-c004-4786-8879-1632b95d7229   8Gi        RWO            Delete           Terminating   kapi/kubedb-postgres-prod-20200302-221837       csi-sc-cinderplugin            29d
pvc-94f3a15a-0e29-4997-ab7e-286b040e0928   8Gi        RWO            Delete           Terminating   dapi/kubedb-dapi-postgres-20200322-122153       csi-sc-cinderplugin            10d
pvc-9a6004cd-98db-11e9-904d-fa163e4958e4   8Gi        RWO            Delete           Terminating   kapi/data-quick-postgres-0                      csi-sc-cinderplugin            279d
pvc-a08f3f57-4017-4bf0-a581-22c4e9e03608   8Gi        RWO            Delete           Terminating   dapi/kubedb-dapi-postgres-20200218-001437       csi-sc-cinderplugin            43d
pvc-a23a38a8-73e8-4d2d-8afc-fdf827217061   8Gi        RWO            Delete           Terminating   kapi/kubedb-postgres-prod-20191230-000136       csi-sc-cinderplugin            93d
pvc-adf9902a-dba8-42a8-ae74-792768fe03a0   8Gi        RWO            Delete           Terminating   kapi/kubedb-postgres-prod-20200114-120136       csi-sc-cinderplugin            78d
pvc-b30ee087-4df0-4c4f-b449-a691d795afe1   8Gi        RWO            Delete           Terminating   kapi/kubedb-postgres-prod-20191213-000136       csi-sc-cinderplugin            110d
pvc-d70c1270-4860-4ae3-85d0-eb2c4b516981   8Gi        RWO            Delete           Terminating   kapi/kubedb-postgres-prod-20200120-083133       csi-sc-cinderplugin            72d
pvc-dae15c4b-1671-438c-95c2-f34104aa2c87   8Gi        RWO            Delete           Terminating   kapi/kubedb-postgres-prod-20200208-083133       csi-sc-cinderplugin            53d
pvc-de2d2ea2-4dd2-4d97-a943-b1eab6d07048   8Gi        RWO            Delete           Terminating   dapi/kubedb-dapi-postgres-20200113-120149       csi-sc-cinderplugin            79d
pvc-dfbe53f1-f3b5-471e-88fa-58a83b38bdbd   8Gi        RWO            Delete           Terminating   kapi/kubedb-postgres-prod-20200121-083133       csi-sc-cinderplugin            71d
pvc-f3e1d28f-e154-44fd-b350-e914e145aabc   8Gi        RWO            Delete           Terminating   kapi/kubedb-postgres-prod-20200306-101837       csi-sc-cinderplugin            26d
pvc-fb54020d-4841-4e14-b5c5-4eaf1f6487e8   8Gi        RWO            Delete           Terminating   kapi/kubedb-postgres-prod-20200205-083133       csi-sc-cinderplugin            56d

What you expected to happen:
I expect that volumes are terminated 100% when volume is deleted from kubernetes API. Now the situation is that volumes are not found anymore from openstack API - it has deleted those. However, pv object and volumeattachment still exists. When I am trying to delete volumeattachment manually using kubectl delete volumeattachment <attachment> I can see following in csi-attacher logs:
I0401 14:44:58.532341       1 connection.go:184] GRPC error: rpc error: code = NotFound desc = ControllerUnpublishVolume Volume not found
I0401 14:44:58.532372       1 csi_handler.go:428] Saving detach error to "csi-b689e426fb9de8fe1e2038ecadd34174752925cb1676a6ac128e6ebc76118870"
I0401 14:44:58.548856       1 csi_handler.go:439] Saved detach error to "csi-b689e426fb9de8fe1e2038ecadd34174752925cb1676a6ac128e6ebc76118870"
I0401 14:44:58.558362       1 csi_handler.go:99] Error processing "csi-b689e426fb9de8fe1e2038ecadd34174752925cb1676a6ac128e6ebc76118870": failed to detach: rpc error: code = NotFound desc = ControllerUnpublishVolume Volume not found
I0401 14:44:58.558855       1 controller.go:141] Ignoring VolumeAttachment "csi-b689e426fb9de8fe1e2038ecadd34174752925cb1676a6ac128e6ebc76118870" change

So because volume does not found it is impossible to delete pv / volumeattachment object anymore. Even --force --grace-period=0 does not do anything.
How to fix this:

when deleting volumeattachment ignore volume not found error

@zetaab which cinder-csi version do you use? Did you try v1.18.0?

docker.io/k8scloudprovider/openstack-cloud-controller-manager:v1.17.0
quay.io/k8scsi/csi-attacher:v2.0.0,quay.io/k8scsi/csi-provisioner:v1.4.0,quay.io/k8scsi/csi-resizer:v0.3.0,quay.io/k8scsi/csi-snapshotter:v1.2.2,docker.io/k8scloudprovider/cinder-csi-plugin:v1.16.0
quay.io/k8scsi/csi-node-driver-registrar:v1.1.0,docker.io/k8scloudprovider/cinder-csi-plugin:v1.16.

@zetaab some of the above behaviors are changed in 1.18, like volume not found, it returns success assuming its already detached .
Could you try with cinder-csi-plugin: 1.18, if you still see the issue

I updated to 1.18 and all zombie volumeattachments and pvcs was gone

@ramineni could you please help to backport that change to branch release-v1.17? We could do a patch release and build new tag image for v1.17 users.

@ramineni could you please help to backport that change to branch release-v1.17? We could do a patch release and build new tag image for v1.17 users.

sure, Ill do that

@ramineni could you please help to backport that change to branch release-v1.17? We could do a patch release and build new tag image for v1.17 users.

sure, Ill do that

Any news on this? possible maybe to get a WA  please as how to do that locally on an working cluster? I mean on v1.17 csi

@itayrin these are already backported to 1.17. Please use cinder-csi-plugin v1.17.1 for the fix.
k8scloudprovider/cinder-csi-plugin:v1.17.1


Doesn't work on Catalina 10.15.4

I tried it using the latest download from here. 1.5.1.
reloaded/ restarted but still won't display NFO files.

Same problem on 10.15.7.

This project provides the same feature set, and is compatible with latest macOS versions FYI: https://github.com/sbarex/SourceCodeSyntaxHighlight


Doc: Insert license file

same as in https://github.com/3PillarGlobal-Czechia/interview-app-api/issues/34
create the same license in this repository.

After consultation, we want to use the MIT license.


add more errno constants to uclibc

Add more errno constants as requested by rustc since commit
1ec9454403e9bb0361d0725524c4bd27030474cc (for a discussion of the
change, see https://github.com/rust-lang/rust/pull/79965).
The constant values and descriptions were taken from
include/uapi/asm-generic/errno.h in the Linux kernel, since "uClibc will
be compiled to match the interfaces available in the provided version of
the Linux kernel headers".
While the fork of uClibc in L4Re nominally has its own errno constants,
they appear to be based on the Linux header file and thus are the same.

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13
Approved by: JohnTitor
Pushing 698d39732c9e1efa9ae35f21d467c0a3de8207ad to master...


Add syntactic sugar for attr.ib(default=attr.Factory)

Let's help @glyph to type less.
Fixes #178

@chadrik I guess this needs into the stubs? 😇

Yeah it will.  I'm trying to figure out the best time to update the stubs?  When is the next release happening?

I don’t know could be any time but I don’t really have any pressure. Any wishes?

I think my preference would be to update all the stubs at once per release.  Sadly you can't version the stubs per library version so I don't want to give people old stubs.  Although I don't know how often mypy releases come.
Oh bother. I can't wait for PEP 561 so we can just include the stubs with the library and be perfectly happy about it.
Oh I just noticed that this feature means I have to update the plugin too.  So that the init has a default.
Anyway when is the next release planned for?

As said: I don’t have a schedule, any wishes? Should be March tho. ;)

Luckily my tests on the pyi_stubs branch will flag these issues when it gets merged :)

I can't wait for PEP 561, so we can just include the stubs with the library and be perfectly happy about it.

It's getting close: https://github.com/python/mypy/pull/4693
However, after it lands keeping the plugin and stubs in sync is going to be a bit of a pain, especially considering my PR for pip-installable mypy plugins was shot down for now.  For example, I'm assuming this particular feature needs to be supported by the stubs and the plugin in tandem...  what happens when they're out of sync with each other?  At least with the typeshed we can ensure that each mypy release contains a compatible version of the plugin and stubs, even though it's only for bleeding edge versions of attrs.
Once PEP561 lands, and while we're still waiting on pip-installable plugins, I think each release of attrs will need to specify a compatible mypy version.

Oops. Misread the message.  I might have time this weekend to work on the plugin.   But now that I think about it, since it depends on mypy shipping a release (which won't happen for a while) there's no real rush here.  People who want to use this feature and type-check will probably have to install an unreleased version of mypy.

I guess it would be good to have #238 in 18.1 tho?

Ok I have both a typeshed diff and a mypy diff ready to support this.  I'd like to do a single "support attrs 18.1" PR are there any other features?    I got fields_dict also.
https://github.com/euresti/mypy/commit/ee19aedc2fb8dd9f9d2268c0b04008b78ac712a4
https://github.com/euresti/typeshed/commit/20e3cf866357577ff5dac40670f45fb5455fd69f


weatherunderground.0.forecastHourly.28h.precipitation" has to be type "value.precipitation" but received type "number"

Describe the bug
IO broker Log files report tons of these  info messages:
weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.28h.precipitation" has to be type "value.precipitation" but received type "number"
To Reproduce
Steps to reproduce the behavior:
Adapter version  3.4.2
Expected behavior
Clean up data type mismatch
Screenshots & Logfiles
2022-10-15 04:10:22.319 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.0h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.351 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.1h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.384 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.2h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.420 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.3h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.460 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.4h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.510 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.5h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.536 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.6h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.571 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.7h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.610 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.8h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.646 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.9h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.670 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.10h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.699 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.11h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.719 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.12h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.753 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.13h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.786 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.14h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.817 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.15h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.844 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.16h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.881 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.17h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.912 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.18h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.945 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.19h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:22.975 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.20h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:23.004 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.21h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:23.033 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.22h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:23.061 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.23h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:23.095 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.24h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:23.107 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.25h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:23.123 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.26h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:23.151 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.27h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:23.184 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.28h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:23.222 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.29h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:23.252 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.30h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:23.280 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.31h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:23.307 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.32h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:23.344 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.33h.precipitation" has to be type "value.precipitation" but received type "number"
2022-10-15 04:10:23.363 - info: weatherunderground.0 (19048) State value to set for "weatherunderground.0.forecastHourly.34h.precipitation" has to be type "value.precipitation" but received type "number"
Versions:
Plattform: linux
Betriebssystem: linux
Architektur: x64
CPUs: 4
Geschwindigkeit: 800 MHz
Modell: Intel(R) Pentium(R) Silver N5030 CPU @ 1.10GHz
RAM: 7.6 GB
System-Betriebszeit: 44 T. 00:02:56
Node.js: v14.20.0
time:<PHONE_NUMBER>123
timeOffset: -120
Adapter-Anzahl: 443
NPM: 6.14.17
Datenträgergröße: 108.7 GB
Freier Festplattenspeicher: 92.7 GB
Betriebszeit: 20 T. 23:43:44
Aktive Instanzen: 19
Pfad: /opt/iobroker/aktiv:
Additional context
Add any other context about the problem here.

Please delete the affected object in admin and restart adapter ... does it happen again afterwards?


TS Go to implementation doesn't seem to work for multiple implementations

I tried to ctrl+f12 to IWorkspaceConfigurationService.lookup and it did nothing https://github.com/Microsoft/vscode/blob/e92940c09c12d1a083e422125f0c96c6b55fbf68/src/vs/workbench/services/configuration/common/configuration.ts#L27
I expect a peek view like find all references only containing the implementations, alternatively in the meantime if that's difficult to do a popup saying there are multiple implementations would be good.

I'm unable to reproduce this.
One thought though: Go to implementation is only enabled on TS 2.2+. Can you please make sure you are using that in the workspace?

That was probably it, I haven't had any issues recently.


Samsung TV state

Home Assistant release with the issue:
0.81.1
Last working Home Assistant release (if known):
0.80.3
Operating environment (Hass.io/Docker/Windows/etc.):
Raspberry Pi2, Raspbian stretch, virtual env.
Component/platform:
issue with the https://www.home-assistant.io/components/media_player.samsungtv/
Description of problem:
I have a Samsung 32UNJ5500. I know the media player control does not work, but the state on/off did work.
After the update to version v0.81.0 the state is always off.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
I am using the Discovery component, so thre is no additional configuration for this component.
Traceback (if applicable):

Additional information:

Possible duplicate of #17802.

Possible duplicate of #17802.

Yes, is the same issue. Thanks.


Config Settings

It appears the configuration settings reset after each quit. Not sure if this is on the to-do list but it's somewhat of a pain to set them each time (let alone remember to). Also, the recording frame is not remembering placement either.
I'm on an older mac btw – Late 2011, Yosemite 10.10.3

Hey @tdreitz, #75 should fix this (not in master yet), however, we're trying to decide if the window position & size should reset on Quit. For now, we've decided on yes, but could revisit. I will take a look a persisting these:

In my opinion the configuration should be remembered (aspect ratio, size, etc.) while the actual selection area could reset on every quit. Thoughts @tdreitz, @stursby?

@skllcrn that's exactly what I was thinking... working on a new branch now 💪

Fixed on v1.0.0 😄


Modulo operator does not work as expected with decimals

Steps to reproduce
1 % 0.2
Expected behavior
1 % 0.2 = 0
Actual behavior
1 % 0.2 = 0.2
Environment data

> $PSVersionTable  5.1.14393.2189

Also able to repro in 6.0.2

Try using the decimal type
[decimal]1 % 0.1 = 0.0
[decimal]1 % 0.8 = 0.2
[decimal]1 % 0.9 = 0.1

In arithmetic operations, PowerShell converts the operands to the most accurate type. So the type of the operation 1 % 0.2 is [double] and the type of [decimal] 1 % 2 (which could more easily be written as 1d % 0.2) is [decimal]. Once the type is established, PowerShell uses the underlying .NET framework APIs to perform the operation e.g. System.Decimal.Modulus.

@hksky: In light of the comments above:
Why do you expect
1 % 0.2

to yield 0 (whether typed [double] or [decimal])?

@mklement0 expectation was to receive
0.0 or 0
because 5 % .5 yields 0 and several other Modulo operations with decimal  do yield the expected result.
I do understand the explanation and appreciate the response from @BrucePay  which makes sense and we could mark this as working correctly as per the developer but not for the end user.


Trouble with "metadata workflow"

I'm trying to follow the "metadata workflow" instructions at https://www.xiph.org/vorbis/doc/libvorbis/overview.html to implement tag editing. Everything seems to be working, except that the resulting files report

Negative or zero granulepos (-1) on vorbis stream outside of headers. This file was created by a buggy encoder

multiple times when checked with ogginfo.exe. I believe the issue is that the majority of data packets obtained via ogg_stream_packetout have granule positions of -1, i'm guessing because this information is only available once per page.
Now, I may be fundamentally misunderstanding the instructions, but my interpretation is that i'm supposed to init a new ogg_stream and simply pass in the packets verbatim (substituting packet 1 with my updated comments) then page_out as follows (note this is C#, just think of it as C pseudocode):
`
using (var sync = new OggSync())
{
OggPage inPage;
    do
    {
        // Read from the buffer into a page
        while (!sync.PageOut(out inPage))
        {
            var nativeBuffer = sync.Buffer(buffer.Length);
            var bytesRead = stream.Read(buffer, 0, buffer.Length);
            Marshal.Copy(buffer, 0, nativeBuffer, bytesRead);
            sync.Wrote(bytesRead);
        }

        if (inputOggStream == null)
            inputOggStream = new OggStream(SafeNativeMethods.OggPageSerialNo(ref inPage));
        if (outputOggStream == null)
            outputOggStream = new OggStream(inputOggStream.SerialNumber);

        inputOggStream.PageIn(ref inPage);

        while (inputOggStream.PacketOut(out var packet))
            switch (packet.PacketNumber)
            {
                case 0:
                    outputOggStream.PacketIn(ref packet);
                    break;

                // Substitute the new comment packet
                case 1:
                    using (var adapter = new MetadataToVorbisCommentAdapter(metadata))
                    {
                        adapter.HeaderOut(out var commentPacket);
                        outputOggStream.PacketIn(ref commentPacket);
                    }
                    break;

                // Flush at the end of the header
                case 2:
                    outputOggStream.PacketIn(ref packet);
                    while (outputOggStream.Flush(out var outPage))
                        WritePage(outPage, tempStream, buffer);
                    break;

                // Write subsequent packets verbatim
                default:
                    outputOggStream.PacketIn(ref packet);
                    while (outputOggStream.PageOut(out var outPage))
                        WritePage(outPage, tempStream, buffer);
                    break;
            }
    } while (!SafeNativeMethods.OggPageEos(ref inPage));

    // Once the end of the input is reached, overwrite the original file and return
    stream.Position = 0;
    stream.SetLength(tempStream.Length);
    tempStream.WriteTo(stream);
}

`
Let me know if this is off the mark. I'm wondering if this just fundamentally doesn't work, and I should write the data pages out verbatim and then update the page headers with new sequence numbers and recalculate the CRCs. Seems like a hack though, so i'd appreciate guidance.

Alright, I followed my own advice and simply copy the non-header pages out verbatim, with the sequence numbers modified (and CRCs recalculated) if necessary. Would be good to mention that this workflow is a gross oversimplification. Seems the project is more or less legacy now anyway - I imagine most people having this problem have moved on.