[iOS] Handle error gracefully when user incorrectly writes CCC descriptor

iOS will terminate if user tries to manually write the CCC descriptor:
'NSInternalInconsistencyException', 'Client Characteristic Configuration descriptors must be configured using setNotifyValue:forCharacteristic:'
Handle this gracefully by blacklisting CCCD UUID before call is made.

How to "blacklisting CCCD UUID before call is made"，I'am an Android developer using flutter.

@pauldemarco  Hi,
What if we need to write to a descriptor in order to get heart rate from MiBand3? I am using flutter too, and I need to write to a descriptor. What should I do?

@aytunch This issue just refers to the CCC descriptor. Writing to other (writable) descriptors should work fine. Let me know if you run into issues.

@pauldemarco Ah ok, I will see if it CCC descriptor first then. Thanks for the quick response, take care

@pauldemarco I am still having issues, the moment I try to write to the descriptor, app crashes instantly. It should not be CCC but I could not be sure. Is there a way to ask the characteristic/descriptors of their traits (allow-read/write/notify)? I am trying to get Real Time Heart Rate from my MiBand3. My code and the result is this:
void _startMonitoringHeartRate() async {
    if (hrmctrlCharacteristic != null && hrmdataDescriptor != null) {
      print("NOT NULLLLLL");
      await hrmctrlCharacteristic.write(
          hex.decode("15" + COMMAND_SET_HR_MANUAL + COMMAND_STOP),
          withoutResponse: true);
      print("1111");
      await hrmctrlCharacteristic.write(
          hex.decode("15" + COMMAND_SET__HR_CONTINUOUS + COMMAND_STOP),
          withoutResponse: true);

      print("2222");
      print("descriptorUUID:${hrmdataDescriptor.uuid.toString()}");
      print("characterUUID:${hrmdataDescriptor.characteristicUuid.toString()}");
      print("serviceUUID:${hrmdataDescriptor.serviceUuid.toString()}");
      await hrmdataDescriptor.write(hex.decode("0100"));

      print("3333");
      await hrmctrlCharacteristic.write(
          hex.decode("15" + COMMAND_SET__HR_CONTINUOUS + COMMAND_START),
          withoutResponse: true); //TODO: change to true!!!!

      print("4444");
      Timer.periodic(Duration(seconds: 12), _sendPing(hrmctrlCharacteristic));

      print("5555");
    } else {
      print("NULLLLLL");
    }
  }

Output:

flutter: Start Getting Continous Heart Data...
flutter: NOT NULLLLLL
flutter: 1111
flutter: 2222
flutter: descriptorUUID:00002902-0000-1000-8000-00805f9b34fb
flutter: characterUUID:00002a37-0000-1000-8000-00805f9b34fb
flutter: serviceUUID:0000180d-0000-1000-8000-00805f9b34fb
Lost connection to device.
Exited (sigterm)

One last thing: What is the _bool inside character.write(_data, withoutResponse:_bool) for? Is there a chance the problem might be caused of using wrong withoutResponse for the previous character.write's? And there is no withoutResponse inside of descriptor.write. What is the reason there?

Hello people!
I have the same problem!! I can't to write descriptor and i don't know what i do...
I'am using the flutter_blue 0.7.2
My code:
targetCharacteristic = service.characteristics
.where((element) => element.uuid.toString() == GLUCOSE_CHARACTERISTIC)
.first;
if (targetCharacteristic != null) {
  print("notify GLUCOSE_CHARACTERISTIC");
  targetCharacteristic.setNotifyValue(true);
  BluetoothDescriptor descriptor = targetCharacteristic.descriptors[0];
  if (descriptor != null) {
    List<int> elements = [1, 1];
    var data = new Uint16List.fromList(elements);
    await descriptor.write(data);
  }

  targetCharacteristic = null;
}

Message error:
D/BluetoothGatt(24483): setCharacteristicNotification() - uuid: 00002a18-0000-1000-8000-00805f9b34fb enable: true
E/flutter (24483): [ERROR:flutter/lib/ui/ui_dart_state.cc(166)] Unhandled Exception: PlatformException(RuntimeException, Protocol message contained an invalid tag (zero)., com.google.protobuf.InvalidProtocolBufferException: Protocol message contained an invalid tag (zero).
E/flutter (24483):      at com.google.protobuf.CodedInputStream.readTag(CodedInputStream.java:148)

How to "blacklisting CCCD UUID before call is made"，I'am an Android developer using flutter
I hava got the same issue ,do you deal it ? @coderLM @pauldemarco

Hello people!
Has anyone here managed to solve the bluetooth communication problem with the miband?
I was able to decipher the authentication process with the bracelet, but I'm having trouble implementing it in flutter. Can you help me?
The steps are as follows:
1- Create a key with 16bytes. Example: {0x30, 0x31, ..., 0x46, 0x45}
2 - Enable notifications on the miband by sending TRUE to service UUID 0x0009
3 - Send {0x01, 0x08, KEY} to UUID 0x0009.
4 - Check if the first three bytes of the return were {0x10, 0x01, 0x01} which means success in receiving.
5 - Send another request now with an extra bit in the first element and without a key {0x02, 0x08}
6 - Check the return again if equal to {0x10, 0x02, 0x01} means success.
7 - Take the last 16bytes of the response from step 6 and encrypt it using AES / ECB / NoPadding using the key created in step one. Store in a RESPONSE_KEY variable.
8- Send another request with the encrypted response created above. Example: {0x03, 0x08, RESPONSE_KEY}, similar to what is done in step 3.
9- Check the return, if equal to {0x10, 0x03, 0x01} the data has probably already been sent.
Font: https://leojrfs.github.io/writing/miband2-part1-auth/


How To Convert Mediapipe BlazePose For Coral TPU

Issue Type
Others
OS
Ubuntu
OS architecture
x86_64
Programming Language
Other
Framework
TensorFlow
Model name and Weights/Checkpoints URL
https://storage.googleapis.com/mediapipe-assets/pose_detection.tflite
Description
Hi,
Firstly, this is a really cool project that is great for quantization of models that are not already quantized, and a great place to get the models easily.
I am trying to quantize and convert the Mediapipe BlazePose 3D Pose Estimation for use with the Coral USB accelerator TPU. Maybe I am mistaken as in the chart it is already quantized for INT8, however I might not understood it correctly.
I followed the steps in the 053_BlazePose folder in the following order:

executed download_fullkey.sh
from the convert_script.txt I used the docker command with a modification (due to docker not finding the remote repository):

docker run --gpus all -it --rm \
    -v `pwd`:/workspace/resources \
    -e LOCAL_UID=$(id -u $USER) \
    -e LOCAL_GID=$(id -g $USER) \
    ghcr.io/pinto0309/tflite2tensorflow:latest bash

Inside the docker container running I first run the following command:

tflite2tensorflow \
  --model_path pose_detection.tflite \
  --flatc_path ../flatc \
  --schema_path ../schema.fbs \
  --model_output_path saved_model_edgetpu \
  --output_pb True \
  --optimizing_hardswish_for_edgetpu True

I got two errors - the first was about the pose_detection.tflite not found, so I downloaded it from Mediapipe Model Location
And the second error is that --optimizing_hardswish_for_edgetpu True had the following error:
tflite2tensorflow: error: unrecognized arguments: True --optimizing_hardswish_for_edgetpu True

So I got rid of that flag, and then the second command also had an issue with the boolean flag so I removed the boolean in this way:
tflite2tensorflow \
  --model_path pose_detection.tflite \
  --flatc_path ../flatc \
  --schema_path ../schema.fbs \
  --model_output_path saved_model_edgetpu \
  --string_formulas_for_normalization 'data / 255' \
  --output_edgetpu    <----  Removed True

Lastly I finally got a 'Compilation succeeded!' message and I saw the files in the saved_model_edgetpu folder, however I am not sure I followed the steps correctly. Did I follow the steps correctly, and I can now use the quantized model with the coral tpu or I got an error in one of my steps?
BTW, the log for the compilation was the following:
Operator                       Count      Status

DEPTH_TO_SPACE                 3          Operation not supported

PAD                            8          Mapped to Edge TPU

CONCATENATION                  2          Mapped to Edge TPU

ADD                            15         Mapped to Edge TPU

RESIZE_BILINEAR                2          Mapped to Edge TPU

CONV_2D                        45         Mapped to Edge TPU

DEPTHWISE_CONV_2D              28         Mapped to Edge TPU

RESHAPE                        6          Mapped to Edge TPU

What is the DEPTH_TO_SPACE?
Thank you in advance,
Ofek
Relevant Log Output
No response
URL or source code for simple inference testing code
No response

Oh wow thank you for this swift response, well received.
Do you know what is the DEPTH_TO_SPACE variable?

If you want to know, attach the float32 tflite and uint8 tflite here.

Please specify --output_no_quant_float32_tflite to generate a float32 model. It's a pain to convert it myself because I'm concentrating on other tasks.

Sure, There it is

EdgeTPU does not support tensors beyond 5 dimensions. Since DEPTH_TO_SPACE used in the pose_detection model is an operation involving Reshape and Transpose to 6 dimensions in the internal processing, EdgeTPU skips the transformation. There is no workaround.
python -m tf2onnx.convert \
--opset 11 \
--dequantize \
--inputs-as-nchw input_1:0 \
--tflite pose_detection.tflite \
--output pose_detection_tf2onnx.onnx

onnx2tf \
-i pose_detection_tf2onnx.onnx \
-cotof \
-oiqt \
-qt per-tensor \
-coion

edgetpu_compiler pose_detection_tf2onnx_full_integer_quant.tflite

Float32 ONNX

pose_detection_tf2onnx.onnx.zip

Float32 tflite

model_float32_tf2onnx_float32.tflite.zip

Full Integer Quantization tflite

model_float32_tf2onnx_full_integer_quant.tflite.zip

EdgeTPU tflite

model_float32_tf2onnx_full_integer_quant_edgetpu.tflite.zip

Well noted, thank you for taking the time to explain this fully.
I will try out other 3D pose estimation models to test what can work with the coral tpu and let you know, as I did not know this was an already unsupported (last update in 2022) device and I got that for a small test project.


get_custom_effort     group_by = "year"     unit = "day"

at the moment these settings calculate the effort for each 365 days after the selected starting date, calculated as the number of days. This is rather confusing and not often useful for research questions
suggestion => calculate the effort (in days) for each calendar year

Discussed with @jimcasaer: this should be implemented quite soon and so it should be developed at patchlevel: v0.20.1.

yes !
Op di 5 sep. 2023 16:30 schreef Damiano Oldoni @.***>:

@jimcasaer https://github.com/jimcasaer: I would extrapolate your
suggestion to other group_by values. This means that setting group_by =
"month" or "week", calculates the effort for each calendar month/week.
Does it make sense to you?
—
Reply to this email directly, view it on GitHub
https://github.com/inbo/camtraptor/issues/219#issuecomment-1706736339,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEHMZ2EFNIF7WJEJD5PIPQLXY4ZRBANCNFSM6AAAAAAZDN7HJI
.
You are receiving this because you were mentioned.Message ID:
@.***>


Unable to run the stack on an existing cluster

Error: local-exec provisioner error
  with null_resource.oke_nginix_setup,
  on oke.tf line 80, in resource "null_resource" "oke_nginix_setup"
  80:    provisioner "local-exec" {
Error running command 'echo '(1) Create namespace: '; export
KUBECONFIG=./generated/kubeconfig;kubectl create ns nsgreen;kubectl create ns
nsblue': exit status 1. Output: (1) Create namespace:
Error from server (AlreadyExists): namespaces "nsgreen" already exists
Error from server (AlreadyExists): namespaces "nsblue" already exists

Hi @ssp0
As you may see in the error the cluster has existing namespaces 'nsgreen' and 'nsblue' respectively and hence it's conflicting with the default config. So in this, you can set a preferable namespace name via stack Configure Variable options

You may do this while creating the stack (second step) or using Edit variable screen under an existing stack.

Thank you


rust-analyzer: 2022-01-31 -> 2022-02-14

Motivation for this change
https://github.com/rust-analyzer/rust-analyzer/releases/tag/2022-02-14
Things done

Built on platform(s)

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

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

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

[x] 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/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Supersedes #159300
Closes #159739

Superseded by #161720


Formatting

Urgent - Can't release hhi.rmd until it looks presentable. Plan is to release with Sections that are complete  by lunch time tomorrow.

BUG in format of markdown. See all the cat("\n***"). Without these, the captions are pushed into the margin?!? Need to understand this.
I need to add some more text here and there, but I'm seeing the same problem where it's getting shoved into the margin.
Kables are a mess - all different, and most of the formatting is not being applied somehow.
Plots all need a once over. They are inconsistent. The report must look it's best.

Once this is released, we can carefully continue to work on it with less pressure.

When you run the 'asis' chunks, the \n indicates a new line to ensure that markdown headers (#### in this case) are understood as headers. So, whenever you include markdown operators inside those 'asis' calls just make sure to add a line after.
For example,
cat(paste0("\n", "#### Figure ", section_number, ".1.1 Estimated Correlation Segmented by ", target_var_Title,"\n"))

I'm not sure what the kable formatting should look like and they all look the same to me. maybe a png of what they're supposed to look like would help.

What might be better is if I let you suggest the best way. If you have a quick look at this output, you can see some of the problems:

The widths are random which looks messy
They look "unfinished", if you see what I mean?
The collapse rows is a nice touch though. can we keep that?
I was using formattable once upon a time and it looks very nice with some effort, but kableExtra looks like a much less painful option.


[Question] Postgres does not keep data after docker-compose down

Hi,
I installed this stack and it works really well. I only have one problem.
When I execute commands 'docker-compose down' and then 'docker-compose up -d' I lose all my data in the database. This may be a normal docker behaviour but I want to keep my data. I think I need to name the volumes so that they are persistent but I don't understand how to do it.
Can you help me ?
Regards
Frédérik

Since the latest updates, the volume with the data should already be named and persisted when you do docker-compose down and docker-compose up -d. Do you get anything named when you do docker volume ls?

As @Nonameentered says, it uses a Docker volume, it should be persisted unless you do docker-compose down -v.
Could you check that @maverick42 ?

Hi @Nonameentered, @tiangolo
Sorry for the delay. I've checked and I only have (many) volumes with GUIDs. I still don't have enough knowledge about how docker/docker-composer works

Maybe my configuration is old and my volumes are not named?

Thanks,

Yeah, that app-db-data is a "named volume", it should be storing your data even if you do docker-compose down that stops and eliminates the containers.
docker-compose down -v stops and eliminates the containers AND eliminates named volumes like this one.
So, that should be preserved...
Could you try doing this?:

generating a fresh new project, from scratch
start it up with docker-compose up -d
add some data, e.g. a new user
confirm with pgadmin that the data is stored in the DB
stop the stack with docker-compose down
start it up again with docker-compose up -d
confirm that the data (the new user) is still in the DB with pgadmin


trim WAL on safekeepers

DOD:
Safekeepers that are not in touch with the pageserver can coordinate and delete WAL after one them confirms that WAL is stored on pageserver and S3.
We need to keep enough WAL for

safekeper p2p recovery
direct S3 offloading from safekeepers
the last checkpoint offloaded to s3 (remote consistent LSN)

[x] #944
[x] make it configurable whether WAL trim should depend on safekeepers offloading or not (safekeeper config parameter, and possibly per tenant?)
[x] trim WAL
[ ] confirm that the trim works once the S3 on safekeepers is implemted and integrated on stageing/prod

Now on staging WAL is removed without waiting for s3 offloading. FYI @stepashka
https://github.com/neondatabase/neon/pull/1662

s3 offloading is enabled on staging, WAL removal happens after it.


MvpViewStateFragment vs MvpViewStateFragment<MvpView, MvpPresenter>?

In the samples and your blog post I see you used a version of MvpViewStateFragment that takes a View and Presenter, but in the library v1.0.0 it only takes a presenter. Am I doing something wrong?

You are right, in my blog post I'm talking about v 1.0.0  withMvpViewStateFragment<MvpPresenter> (I will update this blogpost as soon as I have release 1.1.0).  If you have cloned the current master branch then you will see MvpViewStateFragment<MvpView, MvpPresenter> since I'm working on 1.1.0 and I had made this change to implement a more type safe way to deal with internal delegates #14
If you want to play around with mosby the current master branch or the latest snapshot is completely fine (version 1.1.0). You can expect that msoby 1.1.0 is going to be realeased very soon.


cabal-install not in the shell environment

I can use the nix-build command to successfully build this app, but I'd like to reuse your nix setup to develop my own app, and I want to be able to use cabal build from inside a shell environment. If I run nix-shell --run cabal configure && cabal build I get the following error:
/tmp/nix-shell-2455143-0/rc: line 3: cabal: command not found

Is this a bug or is there a better workflow available?

Okay I think I finally figured it out:
I had to add:
  env = drv.env.overrideAttrs (oldAttrs: {
    buildInputs = oldAttrs.buildInputs ++ [
      pkgs.haskell.packages.ghc.cabal-install
    ];
  });

To default.nix, and use cabal-install from pkgs.haskell.packages.ghc and not ghcjs.


Exporting as a pure black image

When I export my image, it exports as a pure black .svg file no matter what settings I tinker with.

Please add more information - what image? Which OS and framework? How do you export the image?

Any image that is transparent exports as a pure black image so I can't make my font without the letter being pure black


Failing to start process

I was trying to update my SLPDB code, as I've been having sync issues lately and I see there is a new rc, but it's failing to start on any commit after this one:
commit a7bad2b8934af1e1406baf03294712379171f4f4
Author: James Cramer<EMAIL_ADDRESS>Date:   Mon Sep 21 11:16:34 2020 -0400

    add mongo client option useUnifiedTopology

if I try to npm start using 5bd24bf14c523b36b60a9f181f5f6ad5b872dae1, I get the following error below:
><EMAIL_ADDRESS>start /usr/src/slpdb
> tsc && node --max_old_space_size=8192 index run

[INFO] JSON RPC: getBlockchainInfo
(node:16100) DeprecationWarning: current Server Discovery and Monitoring engine is deprecated, and will be removed in a future version. To use the new Server Discover and Monitoring engine, pass option { useUnifiedTopology: true } to the MongoClient constructor.
/usr/src/slpdb/node_modules/mongodb/lib/mongo_client.js:306
    throw new MongoError('MongoClient must be connected before calling MongoClient.prototype.db');
    ^

MongoError: MongoClient must be connected before calling MongoClient.prototype.db
    at MongoClient.db (/usr/src/slpdb/node_modules/mongodb/lib/mongo_client.js:306:11)
    at new Db (/usr/src/slpdb/db.js:20:30)
    at Object.<anonymous> (/usr/src/slpdb/index.js:34:10)
    at Module._compile (internal/modules/cjs/loader.js:1137:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1157:10)
    at Module.load (internal/modules/cjs/loader.js:985:32)
    at Function.Module._load (internal/modules/cjs/loader.js:878:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
    at internal/main/run_main_module.js:17:47 {
  [Symbol(mongoErrorContextSymbol)]: {}
}
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>start: `tsc && node --max_old_space_size=8192 index run`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2020-12-11T00_35_21_868Z-debug.log

@jcramer Can you briefly explain what changed in 5bd24bf14c523b36b60a9f181f5f6ad5b872dae1 and what I should do to run the latest code?
Thanks!

Closing this, if you're still having issues try the 1.0.0 release with Mongo 4.4+

Closing this, if you're still having issues try the 1.0.0 release with Mongo 4.4+


Populate env in span Meta in ReceiveResourceSpansV2

What does this PR do?
In refactored OTLPReceiver in trace agent, the env attribute was only being populated in the output at trace level. In this PR, populate it at span level as well. Also, modify tests to ensure this code path is tested, and fix minor bugs that came up during this testing.
Motivation
Describe how to test/QA your changes
Possible Drawbacks / Trade-offs
Additional Notes

/merge


WinUI authentication sample always returns IsAuthenticated false

Describe the bug
We followed the instructions on
https://github.com/MicrosoftDocs/azure-dev-docs/blob/main/articles/mobile-apps/azure-mobile-apps/quickstarts/winui/authentication.md
but:
result = await identityClient
                    .AcquireTokenSilent(Constants.Scopes, accounts.FirstOrDefault())
                    .ExecuteAsync();

always yields an AuthenticationResult with a ClaimsPrincipal where the IsAuthenticated property returns false.
Is this expected?
We have added the following logic to enforce IsAuthenticated to true:
var claimsIdentity = new ClaimsIdentity(claims: authenticationResult.ClaimsPrincipal.Claims, authenticationType: "nativeapp");
                var claimsPrincipal = new ClaimsPrincipal(claimsIdentity);

The documentation of ClaimsPrincipal's IsAuthenticated property states:
true if the AuthenticationType property is not null or an empty string.
Reference: https://learn.microsoft.com/en-us/dotnet/api/system.security.claims.claimsidentity.isauthenticated?view=net-6.0
We created an issue on the docs repo:
https://github.com/MicrosoftDocs/azure-dev-docs/issues/914
but @adrianhall asked us to create an issue in this repo instead.
What platforms?
  <PackageReference Include="Microsoft.Identity.Client" Version="4.47.2" />

Target framework: net6.0-windows10.0.19041.0

I'll walk through the entire tutorial again on Friday.  Until then, can you please dump out the value of the result?  (feel free to obfuscate GUIDs but starring out the middle sets of digits so I recognise they are GUIDs but can't use them).

So, let's go through the findings of this:

There is a bug in the code, but it isn't about the IsAuthenticated. - the code in the sample does not use the "IsAuthenticated" flag - we use the existance of the access token as a determiner of authentication.  So the original report isn't relevant.  If you need IsAuthenticated in your code, you need to file an issue with MSAL and pursue it there.

There IS a bug in the code around the DisplayErrorAlertAsync() method.  Basically, if you cancel out of the authentication box or GetAuthenticationToken otherwise returns an error, then the DisplayErrorAlertAsync() method is called and that throws.  I need to do an investigation on this, but it will result in a new issue here.

There is also a bug in the docs - in the WinUI sample, I tell you to reference the TodoApp.WPF project, which is wrong.  I'll submit a correction today.

This issue itself is closed at this point, as the reported issue is not an issue with the sample or tutorial.


Fix CPU graph scaling

What does this pull request do?
It's showing 10000% where it should be showing 100%.
The change pulled in several other changes as well due to a Grafana upgrade.
The most important change is
- "unit": "percentunit"
+ "unit": "percent"

Before
After

What is the intent behind these changes?
To have accurate monitoring.
Please link to ticket
IPB-110

📝 I have bypassed reviews as I need these refactors for upcoming work.
Given these are for operational monitoring, the worst that it can do is break one graph (and we can revert).


Folding overlay disappear after command eval-buffer

This only happens when evaluable buffer, like emacs-lisp-mode or lisp-interaction-mode.
Steps to reproduce:

Fold a node.
M-x eval-buffer

I tried this, but works fine on my setup in both modes

Ah, you are right. I guess this somehow goes away. Thanks! :)


runtime: performance regression about 2~3ms since Go 1.15 on macOS, due to linking two more shared libraries

What version of Go are you using (go version)?

$ go version
go version go1.15 darwin/amd64

1.15, especially on macOS
Does this issue reproduce with the latest release?
Yes, this is a performance comparison issue, compared 1.15 against 1.14.7.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/itchyny/Library/Caches/go-build"
GOENV="/Users/itchyny/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/itchyny/.local/share/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/itchyny/.local/share/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/itchyny/Downloads/go1.15.darwin-amd64/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/itchyny/Downloads/go1.15.darwin-amd64/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/1c/r313z3nn77b3qyzyx6cnwcv80000gn/T/go-build806662573=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
Compile a hello world program using Go 1.15 and 1.14.7 and compare the performance using hyperfine.
 % cat main.go
package main

import "fmt"

func main() {
        fmt.Println("Hello, world!")
}

 % ./go1.15.darwin-amd64/go/bin/go build -o hello-go115 main.go

 % ./go1.14.7.darwin-amd64/go/bin/go build -o hello-go114 main.go

 % hyperfine --warmup 10 ./hello-go115 ./hello-go114 # first run
Benchmark #1: ./hello-go115
  Time (mean ± σ):       7.3 ms ±   0.9 ms    [User: 2.6 ms, System: 3.2 ms]
  Range (min … max):     6.1 ms …  12.3 ms    228 runs

Benchmark #2: ./hello-go114
  Time (mean ± σ):       5.0 ms ±   1.5 ms    [User: 1.3 ms, System: 2.2 ms]
  Range (min … max):     3.5 ms …  12.8 ms    261 runs

Summary
  './hello-go114' ran
    1.46 ± 0.49 times faster than './hello-go115'

  Warning: Command took less than 5 ms to complete. Results might be inaccurate.

 % hyperfine --warmup 10 ./hello-go115 ./hello-go114 # second run
Benchmark #1: ./hello-go115
  Time (mean ± σ):       7.3 ms ±   0.7 ms    [User: 2.6 ms, System: 3.0 ms]
  Range (min … max):     6.3 ms …  11.6 ms    211 runs

Benchmark #2: ./hello-go114
  Time (mean ± σ):       4.8 ms ±   0.6 ms    [User: 1.2 ms, System: 2.1 ms]
  Range (min … max):     3.8 ms …   7.9 ms    287 runs

Summary
  './hello-go114' ran
    1.54 ± 0.23 times faster than './hello-go115'

  Warning: Command took less than 5 ms to complete. Results might be inaccurate.

 % # This hello world program is too small to compare the performance so let's do a loop.

 % cat main.go
package main

import "fmt"

func main() {
        for i := 0; i < 50000; i++ {
                fmt.Println("Hello, world!")
        }
}

 % ./go1.15.darwin-amd64/go/bin/go build -o hello-go115 main.go

 % ./go1.14.7.darwin-amd64/go/bin/go build -o hello-go114 main.go

 % hyperfine --warmup 10 ./hello-go115 ./hello-go114 # first run
Benchmark #1: ./hello-go115
  Time (mean ± σ):      44.1 ms ±   1.9 ms    [User: 26.7 ms, System: 15.9 ms]
  Range (min … max):    39.9 ms …  49.3 ms    58 runs

Benchmark #2: ./hello-go114
  Time (mean ± σ):      41.1 ms ±   2.5 ms    [User: 23.9 ms, System: 15.6 ms]
  Range (min … max):    36.5 ms …  48.6 ms    67 runs

Summary
  './hello-go114' ran
    1.07 ± 0.08 times faster than './hello-go115'

 % hyperfine --warmup 10 ./hello-go115 ./hello-go114 # second run
Benchmark #1: ./hello-go115
  Time (mean ± σ):      44.4 ms ±   2.7 ms    [User: 26.5 ms, System: 16.1 ms]
  Range (min … max):    39.1 ms …  50.5 ms    58 runs

Benchmark #2: ./hello-go114
  Time (mean ± σ):      41.2 ms ±   2.2 ms    [User: 23.8 ms, System: 15.8 ms]
  Range (min … max):    37.1 ms …  46.7 ms    62 runs

Summary
  './hello-go114' ran
    1.08 ± 0.09 times faster than './hello-go115'

What did you expect to see?
I upgraded the version of Go so I see no performance regression or even faster.
What did you see instead?

Single fmt.Println program took 4.9 ms in Go 1.14.7 but 7.3 ms in Go 1.15, so the regression is around 2.4 ms.
Repeating fmt.Println 50000 times took 41.2 ms in Go 1.14.7 but 44.4 ms in Go 1.15 so the regression is around 3.2 ms.

Why is this happening?
This regression is caused by https://go-review.googlesource.com/c/go/+/227037/ (crypto/x509: use Security.framework without cgo for roots on macOS). As you can see with otool command (ldd equivalent on macOS), two more shared library are linked in Go 1.15 compared to 1.14.7. This will lead (almost) constant overhead to any program built for macOS.
 % otool -L hello-go114
hello-go114:
        /usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current version 0.0.0)

 % otool -L hello-go115
hello-go115:
        /usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current version 0.0.0)
        /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 0.0.0, current version 0.0.0)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 0.0.0, current version 0.0.0)

Actually, when I removed the two lines and build the Go command, it produces the executable without linking to the two libraries and the performance is now comparable.
The Go 1.15 Release Notes says On macOS, binaries are now always linked against Security.framework to extract the system trust roots, regardless of whether cgo is available. The resulting behavior should be more consistent with the OS verifier. Thus I think this is an intended overhead we have to accept since Go 1.15. But I want to mention here in this issue tracker because this is where I searched for some regression issues after seeing the weird profiling results on upgrading Go. 2~3 ms addition for hello world program was actually surprising. Maybe I have to accept the fact that the change is applied to any program, even if it is not related to networking.
Go devs, I always appreciate your tough works and please close this issue if the overhead is expected. Thanks @koron for the big clue for this problem.
Regards

@FiloSottile
Is there any way to avoid the reference to the new frameworks if none of the security code that uses it is linked in?

I was looking at that the other day, and have a fix locally, which involves some change in the linker. Will send it out soon.

It sLinda reasonable to wire it up so it's only linked when crypto/x509 is imported, happy to review the CL @cherrymui.

I was wondering if this will be ported to 1.15.1 or not.

@gopherbot please open a backport issue for Go 1.15.
I am not sure this qualifies to be backported, but it might as it's a regression with no workaround.
The team will evaluate it in the backport issue.

@gopherbot add OS-Darwin

I'm not sure it qualifies backporting either. But I made a CL anyway. It backports cleanly and does work.


Task name should be camelCase

All grunt tasks that I have seen are in camel case. My JSCS checker is also complaining about mocha_istanbul being camel case, since the task name is an object key in the Gruntfile configuration.
Could you please rename the task?

that would break everything for everyone. the cost benefit of this change is null, sorry

I understand. I didn't see that you are already on 3.x. When 4.x may come out, you could reconsider renaming the task. For now you could consider making an alias.
In the meanwhile I use this workaround:
grunt.task.renameTask('mocha_istanbul', 'mochaIstanbul');

Also see stephenharris/grunt-checktextdomain#2

yeah, aliasing should do.


Terrain estimation when height estimation is based on range finder data

When height estimation is based on range finder data, the terrain estimation must not use a range finder as source. Either terrain estimation needs to be stopped or uses a different source. This is an open PR to find an appropriate and generic solution to this issue.
As a first step, terrain estimation is paused as soon as a fallback from vision based to range finder based height estimation occurs. Terrain estimation is continued when vision data is available again. However, this workaround is not generic enough as it only covers the specific use case described.
Refer to https://github.com/PX4/PX4-ECL/pull/994#issuecomment-810309127

To avoid drift during fallbacks, terrain estimator should not run for modes where a valid estimation is not possible:

Rangefinder based height
intermediate states where height estimation purely relies on ACC

@mhkabir, @bresch : Your comments?

I agree that we should not be running the terrain estimator if ground is being used as the height datum for the EKF, ie using range finder. Do you have test evidence that this fixes the issue reported? The change looks sensible.

The change is tested in the context of vision as primary source to survive reset cycles of the vision subsystem.

Further tests have shown that this does not work in the case when vision fails before terrain is estimated the first time (initialization?). Any suggestions how to solve this?

Further tests have shown that this does not work in the case when vision fails before terrain is estimated the first time (initialization?). Any suggestions how to solve this?

@ecmnet Are you able to provide the steps you used to create the input data that resulted in the failure case? I would like to make a unit test for corner cases like this.

I tested this with a live vehicle using odometry and a rangefinder with propellers unmounted. After simulating a takeoff and waiting for valid terrain estimation, I switched off vision observing z estimation following raw lidar data.

ECL has been absorbed into PX4-Autopilot, can you recreate this PR over there?
https://github.com/PX4/PX4-Autopilot/tree/master/src/lib/ecl

Will do as soon as I get a running version based on v1.12.0. Currently I have the issue, that 'freezing' the ground level takes place too late (about 5secs). I also want to adjust initialisation in the case that the initial primary height source is a range finder .

ECL has been absorbed into PX4-Autopilot, can you recreate this PR over there?
https://github.com/PX4/PX4-Autopilot/tree/master/src/lib/ecl

Link is not working

@ecmnet I initially merged it into src/lib/ecl (where the submodule lived), then later moved it to within src/modules/ekf2/EKF.
https://github.com/PX4/PX4-Autopilot/tree/master/src/modules/ekf2/EKF

Further tests show, that there is a dependency to Ekf::controlHeightSensorTimeouts(): Within the phase the selected height sensor idoes not provide any data and the detection of the timeout, terrain estimation is continued and relies e.g. on RF. As no height source is available, Z position is considered to be (more or less) constant. If the vehicle actually moves in Z direction during this phase, this movement is falsely reflected as movement of the terrain altitude. With the detection of the timeout, the terrain altitude is freezed. The freezed altitude in this case is not correct, depending on the selected timeout time and the speed of the vehicle in Z-direction.
Any suggestions how to solve this?

There may reasons to use range finder for terrain offset and EKF height (assuming terrain is at zero) due to differing requirements for filtering out the effect of terrain height variation. We will move this to the PX4-Autopilot issues list and continue the investigation.


25% regression in timeToFirstFrameMicros complex_layout_ios__start_up

Description
timeToFirstFrameMicros complex_layout_ios__start_up regressed 25%
skiaperf
https://flutter-flutter-perf.skia.org/e/?begin=1658785076&end=1658853605&keys=Xde9e0f83c32d64a5a26a36361411be1b&num_commits=50&request_type=1&xbaroffset=30074
Apparent introduction
https://github.com/flutter/flutter/pull/108350

https://dart.googlesource.com/sdk.git/+/1ab217ac409ad77ce0db3b053831f33a8f551fec  may be the culprit since it would only effect iOS.

I'm also wondering about this patch to snapshots https://dart.googlesource.com/sdk.git/+/286326f834fcb4816c78472e36b4a69675694727. Either way cc @rmacnak-google

Reproduced this and confirmed that it started with the snapshot change (https://dart.googlesource.com/sdk.git/+/286326f834fcb4816c78472e36b4a69675694727)

The unstripped library is now bigger. Is this benchmark using stripped or unstripped libraries?

Here is the test: https://github.com/flutter/flutter/blob/f1df76e963c3e00baff85a8020a1753f72f6b729/dev/devicelab/bin/tasks/complex_layout_ios__start_up.dart#L11
Here is what is ultimately called: https://github.com/flutter/flutter/blob/f1df76e963c3e00baff85a8020a1753f72f6b729/dev/devicelab/lib/tasks/perf_tests.dart#L691
It is using flutter build ios -v --profile.  I'd have to look at the tool but to know for sure but I suspect the libraries are unstripped since profile builds should have symbols for profiling.

There is also a ~100KB compressed size regression on the same engine roll. https://flutter-flutter-perf.skia.org/e/?queries=sub_result%3Drelease_size_bytes%26test%3Dflutter_gallery_ios__compile
I'm guessing the cause is the same. But I'm pretty sure the size benchmark uses a release build: https://github.com/flutter/flutter/blob/b5a36f03c69ed86be85aecef48a8359e05c84482/dev/devicelab/lib/tasks/perf_tests.dart#L1379

Sending a revert here https://dart-review.googlesource.com/c/sdk/+/252801.

The CL mentioned really shouldn't have affected the size of stripped snapshots, since it only adds information in the static symbol table, which shouldn't get output to snapshots there.  I don't see any changes to snapshot size on the Golem benchmarks for that revision either outside of the usual very small fluctuations in gzip/brotli size, so I'm quite confused as to how it ended up affecting a release snapshot here. Is there an easy reproduction I can try locally?

The size and start-up regressions appears to be iOS-only. The size benchmark I linked above is running the command:
flutter build ios --release --tree-shake-icons --split-debug-info=infos/

Under dev/integration_tests/flutter_gallery in a flutter/flutter checkout. Then the benchmark looks at the built artifact here.

The size and start-up regressions appears to be iOS-only.

That's a blind spot for Golem, right?

Both regressions have recovered following the revert rolling through, so closing this issue.

The size and start-up regressions appears to be iOS-only.

That's a blind spot for Golem, right?

Hmm, I suppose so. As I said, I'll look into it, because I am very interested in seeing what's causing it. The only thing I could think of is that I somehow made a mistake in the AssemblyImageWriter that wasn't repeated in the BlobImageWriter (used for direct ELF output, which I assume the Android pipeline uses). I'll report back just to close the loop once I've found it.


joplin-desktop: 2.7.13 -> 2.7.15

Description of changes
See release notes.
Things done

Built on platform(s)

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

open $(nix-build -A joplin-desktop | tail -n1)/Applications/Joplin.app

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 170997 run on x86_64-linux 1

1 package built:

joplin-desktop

I also ran joplin-dekstop and it seemed to work fine.


LibWeb/CSS: Avoid capturing local references in lambda

Apple Clang doesn't like this, rather than waiting for their version of random-clang-commit-to-call-a-release to catch up with llvm trunk, just work around the issue.

The commit title would be more accurate as "Avoid capturing structured binding in generic lambda"
(see https://github.com/llvm/llvm-project/commit/e1111e2056e7245b21e24816f6f7ef5ac016ed6f)

thank you. LGTM!


Return timestamps as a date

Timestamps should be converted to dates within the package.

Implementing along with #14

Changed to return as date time instead of timestamp.


Type checking for source files fails because next-env.d.ts does not exist

I need to run next build before tsc --project tsconfig.src.json to generate next-env.d.ts.
It seems there are no commands or options to generate only next-env.d.ts.
https://github.com/vercel/next.js/discussions/47010
next build fails when TypeScript errors are present.
ref: https://nextjs.org/docs/app/api-reference/next-config-js/typescript
However, it cannot replace tsc --project tsconfig.src.json because it fails at the first error and does not report the rest.


Input giving NaN in Ionic 3 and Angular 4

Hello!
I'm grateful there is this amazing mask. The only issue so far, is that when deleting all content in the input box, the model will be set to NaN. I'm using Ionic version 3 and Angular 4, and followed the instructions for ionic already. I managed to work around with a validation in the ts file of the page, but it's an unnecessary code, so it would be great to give it a look.
The settings are all the default ones, and the environment the same as others. The only things different are that i'm using just input instead of ion-input, although it may not be the issue, and align left.
Best regards.

Update: the settings are global and the following:
align: "left",  allowNegative: false,  allowZero: true,  decimal: ",",  precision: 2,  prefix: "R$ ",  suffix: "",  thousands: "."

I have the same issue, but i'm not using Ionic and my Angular version is 5.

try this while fixing the bug....
this.form.controls["controlName"].valueChanges.subscribe((val) => {
if (String(val)==="NaN"){
this.form.controls["controlName"].setValue(null);
}
});

@carlosmorcerf thanks, it worked right. For now, I'm applying this to fix the issue. I still not knowing if this affects other kind of environments.

This also causes flies in the face of with Angular's most basic Validator, required.
See source and spot the problem:
function isEmptyInputValue(value: any): boolean {
  // we don't check for string here so it also works with arrays
  return value == null || value.length === 0;
}

  static required(control: AbstractControl): ValidationErrors|null {
    return isEmptyInputValue(control.value) ? {'required': true} : null;
  }

In turn, it also effectively breaks Validators min and max.

Fixed in newest version.


[Documentation] Local dictionary Data which are not supported float and byte updated in the note

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder2.1/750/

Build Success with Spark 2.3.1, Please check CI http://<IP_ADDRESS>:8080/job/carbondataprbuilder2.3/9016/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/948/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder2.1/1049/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder2.1/1050/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder2.1/1051/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/1265/

Build Success with Spark 2.3.1, Please check CI http://<IP_ADDRESS>:8080/job/carbondataprbuilder2.3/9317/

@sraghunandan kindly review and help me to merge my changes

@sraghunandan kindly review and help me to merge my changes

@sraghunandan kindly review

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder2.1/1307/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/1518/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder2.1/1512/

Build Success with Spark 2.3.1, Please check CI http://<IP_ADDRESS>:8080/job/carbondataprbuilder2.3/9770/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/1722/

LGTM


Switch to dev ecr for extensions e2e tests

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 65.56%. Comparing base (08d5959) to head (18e10f5).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #3858   +/-   ##
=======================================
  Coverage   65.56%   65.56%
=======================================
  Files         404      404
  Lines       21819    21819
=======================================
  Hits        14306    14306
  Misses       6161     6161
  Partials     1352     1352

Flag
Coverage Δ

unittests
65.56% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


fill may render on wrong side of incomplete multipolygons

This way/relation has the tag waterway=polygon and renders incorrectly

The rendering issue of broken or incompletely loaded multipolygons could be addressed in the following way: Define additional roles like outer:right and outer:left indicating on which side of the way the multipolygon area is located. The user should not need to add these suffices, but the editor can automatically add or update these, if the multipolygon is complete. This would significantly
Being a change of the OSM datastructures this needs to be discussed with the community in case the change is desired.

I guess much has been written about this issue since 2013.  see: The Future of Areas for a current summary.
So where things stand right now, iD will always wrongly render certain multipolygons unless we download the entire multipolygon.  Some multipolygons are too prohibitively large to download.
@slhh's solution of adding tags to indicate which side of the way contains the area could work.  (It sounds a bit like Tagging Outlines from the above link, but not exactly).   It would definitely upset a lot of people in the OSM community if iD started silently tagging multipolygon member ways with this extra data.
That said, we can use Any Tags We Like.  I'm kind of inclined to push OSM in this direction and just start doing it.  Thoughts @pnorman?

That said, we can use Any Tags We Like. I'm kind of inclined to push OSM in this direction and just start doing it. Thoughts @pnorman?

Don't.

So where things stand right now, iD will always wrongly render certain multipolygons unless we download the entire multipolygon. Some multipolygons are too prohibitively large to download.

I haven't found this an issue in practice. Do you have data which indicates otherwise?
I'd still recommend /relation/id#/full. I can probably get some solid data on it, but my instinct is that most type=multipolygon relations will be entirely within the downloaded area, and of those that aren't, most will be small.

I haven't found this an issue in practice. Do you have data which indicates otherwise?
I'd still recommend /relation/id#/full. I can probably get some solid data on it, but my instinct is that most type=multipolygon relations will be entirely within the downloaded area, and of those that aren't, most will be small.

@pnorman I went back and read your comment a bit more carefully.
I originally thought we would need to do this background relation/id/full fetch for all relations, but if we limit it to only multipolygons it would probably be ok.  Coastlines and boundaries are where this approach wouldn't scale.

Coastlines and boundaries are where this approach wouldn't scale.

Yes, boundaries could be large, and take several seconds. Coastlines don't have relations.
I did some numbers, and of the 2 million MP relations
members   number
1           86k
2         1000k
3          260k
4          230k
5          101k
>5         362k

The total number of nodes in the MP is more interesting to me than the number of members. That's a better measure of bandwidth and memory cost.

The total number of nodes in the MP is more interesting to me than the number of members. That's a better measure of bandwidth and memory cost.

Yes, but that number is capped at 2000 nodes per member way.   It's probably ok.
I don't have time this week, but sometime soon I'll try automatically fetching the multipolygons with relation/id/full.  My home state of New Jersey is a great place to test this - it is covered with huge imported landuse multipolygons.

So, @pnorman maybe the more interesting question to ask is how many members these multipolygons max out at.   ">5" doesn't sound so scary, but if the max is thousands then we have a problem.
Here's an outlier mentioned in IRC:  https://www.openstreetmap.org/relation/5989495
We should test how long that takes to download via relation/id/full


Incorrect encoding with none-Latin symbols

Hello,
The project is perfect but I have a problem with a Cyrillic symbols with upgrading or restoring the Project.
I have created the Project and there are some place where I need to user Cyrillic symbols. After upgrading o new version or after export / import All Cyrillic symbols are replacing by symbol ?.
On new version 1.24 after rewriting text via Cyrillic symbols the text becomes like code:
Exp, Иванов -> Иванов in preview mode

Hi @timonych.
Thank you so much for using Castle Mock and your feedback. Much appreciated :)
I found the issue and it has now been resolved. It will be part of the next release, which is expected to be released at the end of the week.
Just keep in mind that you might have to set the Content-Type for your mocked responses depending on your setup. For example, mine was using iso-8859-1 as default. You can easily change this by adding the following header to your mocked response: Content-Type: application/soap+xml; charset=utf-8.
Feel free to contact me if you have any problems or questions.
Once again, thank you very much.
Best regards,
Karl Dahlgren


docker build no version

use source v2.1.0  build in docker

Thanks for your feedback, the version needs to be set when you compile, like this STARROCKS_VERSION="branch-2.1" ./build.sh --fe --be

Thanks for your feedback, the version needs to be set when you compile, like this STARROCKS_VERSION="2.1.0" ./build.sh --fe --be

Use the command:
STARROCKS_VERSION="2.1.1";
./build.sh --fe --be

built starrocks, but no version number
Version: UNKNOWN-


some playlists are not getting fetched

These lists are not fetching...also the music's good
http://8tracks.com/mixaholic/let-it-be-chillstep
http://8tracks.com/red-nomad/empty-minds-solitude
http://8tracks.com/clemcable/cradled-under-the-stars
http://8tracks.com/red-bull-sound-select/good-vibes

I've had no luck with soundcloud urls either.

@paulthedev I have fixed those playlists. Pushing the changes in a second. It seems that those playlists have a track count that isn't accurate (says there's one more song than there actually is) and that was messing with things. Also yeah it is.
@sethcohn good call. https://github.com/cadejscroggins/catz/issues/72

Fixed in v0.1.1


[Feature Request]Support EXTERNAL rules

See this issue for the context.
In a nutshell, Maple could ask the user for the *.dat/*.site files, and make Leaf be able to find them by modifying the ASSET_LOCATION env var.

May I know if you have started working on this already?

No, not yet. I just hack Leaf's code to make absolute path work last weekend. And I'm not an experienced UWP developer :(

Landed in https://github.com/YtFlow/Maple/commit/51f812d88f65d32525f782c2b75d2bf9155f74c3


doc: document how to upgrade from 0.2.5 to 0.2.6

To upgrade from 0.2.5 to 0.2.6, users need to migrate their existing clusters. we should provide a doc as a reference guide.

breaking change https://github.com/coreos/etcd-operator/pull/999:

the PR changes self-hosted pods's anti-affinity field.


Load Global CSS

Global CSS should be loaded properly, as for now, it does not get loaded. This is needed for fonts and resets to be extended to content injected components.

Fonts won't load no matter what I try, but the rest load fine. Ill have to dive deeper into it in a future issue.


corrected typos

Minor typos corrected
This PR addresses https://github.com/RaspInLoop/RaspInLoop/issues/10

Thanks a lot.

pleasure to help!


Upload with Auto=false does not call Complete/Error/Progress

Describe the bug
I am using the Upload component with Auto=false. The Upload() method is called when after I have submitted contents of a form (and have received an ID back), with this ID in the Url to the controller that handles the upload.
The controller action is called allright by the upload component and finishes correctly. However, at no point the callbacks Progress, Error or Complete are called, which means also there is no way to get any result back (such as the ID of the record where I saved the uploaded file to).
I read the Radzen.js code, which seems fine, but the functions xhr.upload.onprogress and xhr.onreadystatechange don't get called (I put breakpoints in the js file).
When running a test with Auto="true", the callbacks are correctly called, but this does not fit with the scenario I am trying to implement.
To Reproduce
Put an Upload component inside a form template. Set Auto=false, ref=upload
Create Complete callback
In the Submit action of the form, call the upload.Upload()
Observe that the Complete method is not called.
Expected behavior
Independent of whether Auto is true or false, the callbacks must be called.
Desktop (please complete the following information):

OS: Windows 10
Browser: Edge, FireFox
Version RadZen 3.20.9

Further investigation: changing the Url during the submit action fails. If the Url remains unchanged, all works fine.

Hey @rudolfdeschipper,
I'm afraid that changing the upload url in form submit action is not possible.


xmc4000: breakpoint must be on half-word boundaries

Describe the bug
architecture::arm::core::armv7m::FpRev1CompX::get_breakpoint_comparator() returns an error while attempting to use probe-run on an XMC4800.
(HOST) WARN  Could not clear all hardware breakpoints: ArchitectureSpecific(Other(Unsupported breakpoint comparator value 0xc80e46a5 for HW breakpoint. Breakpoint must be on half-word boundaries))
└─ probe_rs::session @ …/probe-rs/probe-rs/src/session.rs:496
Error: A core architecture specific error occured

Caused by:
    Unsupported breakpoint comparator value 0xc80e46a5 for HW breakpoint. Breakpoint must be on half-word boundaries

To Reproduce
Steps to reproduce the behavior:

Obtain a KIT_XMC48_IOT_AWS_WIFI.
Connect to the onboard J-Link debugger, or power the board and use an external CMSIS-DAP probe.
Check out my xmc4000-enabled probe-run branch to use my xmc4000-enabled probe-rs branch (which is just target-gen'd from the vendor's CMSIS pack).
cargo run -- -vv path/to/blinky

I captured some maximally verbose log output.
Expected behavior
Flashing should succeed.
Additional context
I've learned some things while trying to work this issue:

The XMC4xxx chips have flash mapped into the address space twice: one for cached accesses, once for uncached accesses. On this device it's cached at 0x08000000 and uncached at 0x0c000000.
The vendor's linker script defines both regions and does .text {…} > FLASH_1_cached AT > FLASH_1_uncached. In other words, for things which end up in flash, the VMA (seen by the code) is in the cached region while the LMA (seen by the flashing program) is in the uncached region.
The CMSIS pack contains a whole pile of *.FLMs which distinguish these two regions:

% strings < XMC4800_2048.FLM | grep XMC | head -1
XMC4800 2048kB Flash
% strings < XMC4800c_2048.FLM | grep XMC | head -1
XMC4800 2048kB cached Flash

The target-gen'd YAML contains entries for each of the ELF files in the pack:

  - name: xmc4800_2048
    description: XMC4800 2048kB Flash
    default: true
…
    flash_properties:
      address_range:
        start: 201326592
        end: 203423744
      page_size: 256
…
…
  - name: xmc4800c_2048
    description: XMC4800 2048kB cached Flash
    default: true
…
    flash_properties:
      address_range:
        start: 134217728
        end: 136314880
      page_size: 256

The target-gen'd flash algorithm xmc4800_2048 and xmc4800_2048c live components – the instructions: and function pointers and such – are completely identical.
The target-gen'd XMC4800-F100x1024 chip definition refers to both flash algorithms, but the memory map overlaps only the cached flash algorithm's address range. This makes probe-run unable to flash binaries linked using a strategy similar to the vendor's strategy.

    memory_map:
      - Ram:
          name: ~
          range:
            start: 536797184
            end: 537001920
          is_boot_memory: false
          cores:
            - main
      - Nvm:
          name: ~
          range:
            start: 134217728
            end: 135266304
          is_boot_memory: true
          cores:
            - main

(I think this means that the vendor toolchain will flash via xmc4800_2048 while probe-rs will flash via xmc4800_2048c. This might be nothing because they're identical, or this might be a problem if the cached one is broken and no one noticed because everyone else uses the uncached one.)

openocd supports this product family via a hand-written flash driver which seems to work.
All these flash details are likely to be red herrings since the reported issue concerns the contents of the FPB's FPCOMPn registers, which is super far removed from the flash controller.
XMC4700/4800 errata has an entry "DEBUG_CM.002 CoreSight logic only reset after power-on reset" describing how debug resets do not reset the debugging logic. I don't think probe-rs is performing debug resets, but if it did, this chip would respond poorly.

That's as far as I got before coming here.

I learned something new. Plugging into the board's embedded J-Link debugger and trying to run cargo-flash tells me the core is locked up:
% cargo flash --chip XMC4800-F100x2048
…
    Flashing …/target/thumbv7em-none-eabi/debug/blink
       ERROR probe_rs::architecture::arm::core::armv7m > The core is in locked up status as a result of an unrecoverable exception
     Erasing sectors ✔ [00:00:02] [---------------------------------------]       0B/16.00KiB @       0B/s (eta 0s )
 Programming pages   ✔ [00:00:03] [---------------------------------------]       0B/10.75KiB @       0B/s (eta 0s )
       Error 0: The initialization of the flash algorithm failed.
             1: An error with the usage of the probe occured
             2: Operation timed out

Doing it again here causes the titular "breakpoint must be on half-word [boundary]" error:
% cargo flash --chip XMC4800-F100x2048
…
    Flashing …/target/thumbv7em-none-eabi/debug/blink
        WARN probe_rs::session > Could not clear all hardware breakpoints: ArchitectureSpecific(Other(Unsupported breakpoint comparator value 0xc80e46a5 for HW breakpoint. Breakpoint must be on half-word boundaries))
       Error Connecting to the chip was unsuccessful.

        Hint A hard reset during attaching might help. This will reset the entire chip. Run with `--connect-under-reset` to enable this feature.

Trying a third time from this state with the proposed --connect-under-reset doesn't help:
% cargo flash --chip XMC4800-F100x2048 --connect-under-reset
…
    Flashing …/target/thumbv7em-none-eabi/debug/blink
       Error 0: Failed to get information for AP ApAddress { dp: Default, ap: 0 }

…and in fact it leaves the chip in a state where it won't even fail in the ways above:
% cargo flash --chip XMC4800-F100x2048
…
    Flashing …/target/thumbv7em-none-eabi/debug/blink
       Error Connecting to the chip was unsuccessful.

        Hint A hard reset during attaching might help. This will reset the entire chip. Run with `--connect-under-reset` to enable this feature.

Power cycling the board at this point lets me restart this whole sequence. However, openocd is able to recover without power cycling:
% openocd -f scripts/board/xmc4800-relax.cfg
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : J-Link Lite-XMC4200 Rev.1 compiled Oct 27 2015 17:41:01
Info : Hardware version: 1.00
Info : VTarget = 3.300 V
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : xmc4800.cpu: hardware has 6 breakpoints, 4 watchpoints
Error: xmc4800.cpu -- clearing lockup after double fault
Polling target xmc4800.cpu failed, trying to reexamine
Info : xmc4800.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for xmc4800.cpu on 3333
Info : Listening on port 3333 for gdb connections

% cargo flash --chip XMC4800-F100x2048
    Flashing …/target/thumbv7em-none-eabi/debug/blink
       ERROR probe_rs::architecture::arm::core::armv7m > The core is in locked up status as a result of an unrecoverable exception
     Erasing sectors ✔ [00:00:02] [---------------------------------------]       0B/16.00KiB @       0B/s (eta 0s )
 Programming pages   ✔ [00:00:02] [---------------------------------------]       0B/10.75KiB @       0B/s (eta 0s )
       Error 0: The initialization of the flash algorithm failed.
             1: An error with the usage of the probe occured
             2: Operation timed out

"Clearing lockup after double fault" seems significant.

I can now cargo build a blink ELF binary which openocd can flash, gdb can debug via openocd, and which does in fact blink the LEDs on my KIT_XMC48_IOT_AWS_WIFI. My linker script is suboptimal – it's at running code from uncached flash at 0x0C000000 – but at least it works.
I have been unable to coerce cargo-flash or probe-run into loading this same binary. They complain that 0x0C000000 does not correspond to any memory region, which is true because target-gen generated a flash algorithm for that address didn't generate a corresponding region. Adding the uncached flash to the target as an Nvm: region did not help, and neither did changing the linker script to place code in cached flash at 0x08000000. In both cases, cargo-flash causes the blinking to momentarily stutter, resume, and then fails several seconds later saying:
% cargo flash --chip XMC4800-F100x2048 --elf target/thumbv7em-none-eabi/release/blink
    Flashing target/thumbv7em-none-eabi/release/blink
        WARN probe_rs::architecture::arm::core::armv7m > Core is running, but we expected it to be halted
     Erasing sectors ✔ [00:00:02] [---------------------------------------]       0B/16.00KiB @       0B/s (eta 0s )
 Programming pages   ✔ [00:00:03] [---------------------------------------]       0B/ 5.50KiB @       0B/s (eta 0s )
       Error 0: The initialization of the flash algorithm failed.
             1: An error with the usage of the probe occured
             2: Operation timed out

%

probe-run behaves similarly:
Error: Error while flashing

Caused by:
    0: Something during the interaction with the core went wrong
    1: A core architecture specific error occured
    2: Failed to write register DRW at address 0x0000000c
    3: An error specific to a probe type occured
    4: USB error while reading from device: Operation timed out

The program seems to be running almost the entire time that both tools attempt to overwrite it. "Core is running, but we expected it to be halted" indeed.

I've familiarized myself with CoreSight™, the standard CMSIS debug sequences, and the XMC4800 reference manual enough to determine that the Infineon XMC4000 series reset is weird. Snippets from the reference manual:

The "Warm Reset" sequence accomplishes the same goal as the CMSIS ResetCatchSet + ResetSystem but bears little resemblance to the usual implementations. The Infineon CMSIS pack does not include alternate sequences, and at the moment I have no idea what the official tools do. I'm pretty sure this means adding a probe_rs::architecture::arm::sequences::infineon module, so I've started on that.

All roads from the official tools seem to converge at SEGGER J-Link. DAVE (the official IDE) packages J-Link. The Infineon XMC PlatformIO support stuff shells out to J-Link. The third-party XMC for Arduino requres J-Link.
J-Link works with this chip, and can reset/go/halt/flash:
% JLinkExe -device XMC4800-2048 -if SWD -speed 4000 -autoconnect 1
SEGGER J-Link Commander V7.66d (Compiled Jun 21 2022 17:01:42)
DLL version V7.66d, compiled Jun 21 2022 17:01:36

Connecting to J-Link via USB...O.K.
Firmware: J-Link Lite-XMC4200 Rev.1 compiled Mar  1 2019 11:28:26
Hardware version: V1.00
S/N: 591137765
VTref=3.300V
Device "XMC4800-2048" selected.

Connecting to target via SWD
Performing XMC4500 connection sequence.
DPv0 detected
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[1]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
[0][0]: E000E000 CID B105E00D PID 000BB00C SCS-M7
[0][1]: E0001000 CID B105E00D PID 003BB002 DWT
[0][2]: E0002000 CID B105E00D PID 002BB003 FPB
[0][3]: E0000000 CID B105E00D PID 003BB001 ITM
[0][4]: E0040000 CID B105900D PID 000BB9A1 TPIU
[0][5]: E0041000 CID B105900D PID 000BB925 ETM
Cortex-M4 identified.
J-Link>

The output above indicates that J-Link has a specific "XMC4500 connection sequence" which supports my determination that this product family is weird.
The SEGGER wiki has some information beyond the reference manual, including that Infineon requested that they perform a reset under certain circumstances. Experimentally, J-Link situationally performs a power-on reset. (Recall that power on resets do not reset debugging state due to the DEBUG_CM.002 erratum.) I don't know exactly which situations those are, other than that I can occasionally create them if I thrash around and put the chip into weird states.
My best guess is that this power on reset is to set SCU_GENERAL->STCON's HWCON field, since HWCON a) is latched after power on reset, b) reflects which are normally configured at the board level with pullups/pulldowns but can be overridden with a debug probe, and c) configures the boot mode.
J-Link>Mem32 0x50004010 1
50004010 = 00000000

0x50004010 & 3 == 0 corresponds to normal boot mode, which IMO is the sane and reasonable way to implement the "halt after warm reset" process. It's likely that my effort to create weird states was sometimes doing a power on reset while sending SWD commands, which could cause HWCON to latch nonzero, which J-Link would want to do a power-on reset to clear.

🥳
% RUST_LOG=probe_rs::probe::jlink::swd=info,probe_rs::architecture::arm::ap=info cargo-flash --log debug --chip XMC4800-F100x2048 --elf …/blink --speed 1000
       DEBUG cargo_flash > Changed working directory to .
    Flashing …/blink
       DEBUG probe_rs::config::registry > Searching registry for chip with name XMC4800-F100x2048
       DEBUG probe_rs::config::registry > Exact match for chip name: XMC4800-F100x2048
        WARN probe_rs::config::target   > Using custom sequence for XMC4000
       DEBUG probe_rs::probe::cmsisdap::tools > Searching for CMSIS-DAP probes using libusb
       DEBUG probe_rs::probe::cmsisdap::tools > Found 0 CMSIS-DAP probes using libusb, searching HID
       DEBUG probe_rs::probe::cmsisdap::tools > Found 0 CMSIS-DAP probes total
       DEBUG jaylink                          > libusb <IP_ADDRESS>84
       DEBUG jaylink                          > libusb has capability API: true
       DEBUG jaylink                          > libusb has HID access: false
…
       DEBUG probe_rs::flashing::flasher                          > Reset and halt
       DEBUG probe_rs::architecture::arm::sequences::infineon     > Set a breakpoint at 0c0001fe
       DEBUG probe_rs::architecture::arm::sequences::infineon     > Cleared SCU_RESET->RSTSTAT
       DEBUG probe_rs::architecture::arm::sequences::infineon     > Resetting via AIRCR.SYSRESETREQ
       DEBUG probe_rs::architecture::arm::sequences::infineon     > Detected reset via S_RESET_ST
       DEBUG probe_rs::architecture::arm::sequences::infineon     > Waiting for XMC4000 to halt after reset
       DEBUG probe_rs::architecture::arm::sequences::infineon     > Halted after reset
       DEBUG probe_rs::architecture::arm::core::armv7m            > Reason for halt has changed, old reason was Halted(Request), new reason is Breakpoint
       DEBUG probe_rs::flashing::flasher                          > Loading algorithm into RAM at address 0x1ffe8000
…
       DEBUG probe_rs::flashing::flasher                                  > Waiting for routine call completion.
       DEBUG probe_rs::architecture::arm::core                            > DFSR: Dfsr { .0: 3, external: false, vcatch: false, dwttrap: false, bkpt: true, halted: true }
     Erasing sectors ✔ [00:00:01] [#######################################] 16.00KiB/16.00KiB @ 23.79KiB/s (eta 0s )
 Programming pages   ✔ [00:00:01] [#######################################]  5.50KiB/ 5.50KiB @  2.14KiB/s (eta 0s )
    Finished in 2.141s
%

I pushed this to my xmc4000 branch, which is not yet ready for a PR but can (!) flash this chip.

I'm pleased to report that gdb-server also works in this branch:

Awesome work! I love the persistence :) Sorry for not helping with any hints :(


Maybe resume read nowait

What do these changes do?
FlowControlStreamReader.read_nowait was not resuming the underlaying transport in case the buffers are drained, so that the subsequent FlowControlStreamReader.read call would hang until it timed out.
read, readany and others had @maybe_resume decorator but read_nowait did not. Since read_nowait changes _buffer and _buffer_size, we need to check the new size against _buffer_limit and perform the pause/resume action accordingly.

Are there changes in behavior for the user?

Related issue number

Checklist

[x] I think the code is well written
[x] Unit tests for the changes exist
[ ] Documentation reflects the changes
[x] Add yourself to CONTRIBUTORS.txt
[x] Add a new entry to CHANGES.rst

Choose any open position to avoid merge conflicts with other PRs.
Add a link to the issue you are fixing (if any) using #isuue_number format at the end of changelog message. Use Pull Request number if there are no issues for PR or PR covers the issue only partially.

Current coverage is 98.34% (diff: 75.00%)

Merging #1206 into 1.0 will increase coverage by <.01%

@@                1.0      #1206   diff @@
==========================================
  Files            29         29
  Lines          6530       6545    +15
  Methods           0          0
  Messages          0          0
  Branches       1094       1095     +1
==========================================
+ Hits           6422       6437    +15
  Misses           56         56
  Partials         52         52

Powered by Codecov. Last update a6e39f2...2e8e833

@dalazx please add a test or two for covering all affected lines.
I love to merge your PR and publish a new bugfix release but want to improve test coverage especially in complex cases like stream resuming.
My final target is 100% coverage someday.

@asvetlov please take a look

Awesome!
Thanks, @dalazx !


csvlogger: version number doen't increase in the save directory

Bug description
In pytorch-lightning 2.0.2 No matter how many times I run training, the results are always saved in save_dir/name/version0. However, in previous pytorch-lightning versions, the version number should increase by 1 automatically.
When I run the training again, I get the following warning:
lightning_fabric/loggers/csv_logs.py:188: UserWarning: Experiment logs directory weights/xx/version_0 exists and is not empty. Previous log files in this directory will be deleted when the new ones are saved!

and
pytorch_lightning/callbacks/model_checkpoint.py:612: UserWarning: Checkpoint directory weights/alaskalp_lpclass/version_0/checkpoints exists and is not empty.
  rank_zero_warn(f"Checkpoint directory {dirpath} exists and is not empty.")

What version are you seeing the problem on?
v2.0
How to reproduce the bug
csv_logger = CSVLogger("weights", "xx")
trainer.fit(model, train_loader, dev_loader)

Error messages and logs
# Error messages and logs here please

Environment

Current environment
#- Lightning Component (e.g. Trainer, LightningModule, LightningApp, LightningWork, LightningFlow):
#- PyTorch Lightning Version (e.g., 1.5.0):
#- Lightning App Version (e.g., 0.5.2):
#- PyTorch Version (e.g., 2.0):
#- Python version (e.g., 3.9):
#- OS (e.g., Linux):
#- CUDA/cuDNN version:
#- GPU models and configuration:
#- How you installed Lightning(`conda`, `pip`, source):
#- Running environment of LightningApp (e.g. local, cloud):

More info
No response

Thanks for reporting @zhong-yy
This was recently fixed in https://github.com/Lightning-AI/lightning/commit/a36af3f9f855a4735fdc97c5e08bebb8a7467bf3. The fix is not yet released in a bugfix release, but will be soon.
If you want to confirm this, you could install the development version via
pip install -U https://github.com/Lightning-AI/lightning.git


Update to support Minecraft 1.20.4 Fabric

Please update to support Minecraft 1.20.4 Fabric. Thanks!

done!


Add filters for reducing amount of data output

This change adds commented-out samples of how to use filters to reduce the amount of data that are written to the HA recorder database by default.
Depending on the pulse_rate variable, the type of house/apartment and the heating system in use, this may or may not be a problem in practice. For example, with the default in the file, 1000, a power consumption of 3600 W means that the sensors produce 2 HA state changes per second (which means 7200 state changes per hour). With the commented-out filters enabled, only 396 state changes will be produced per hour.

Super cool additions for the glow! Maybe more useful to do the explanation in the readme documentation and place a reference in the yaml file 🤔

@klaasnicolaas Yeah, that makes sense. 👍 I'll try to restructure it a little bit.

Done, what do you think? 🙂

Let's work towards a merge though, since there have been some other changes you'll need to rebase this PR first to resolve the merge conflicts.

@klaasnicolaas still interested in getting this merged? I rebased it on top of latest dev now again.


Rebase onto .NET Core 1.1

Build.psm1 and project.json files modified to use .NET Core 1.1.
.NET Core 1.1 ships with an older dotnet/cli than has currently been used,
so we revert to use case-sensitive directory names for dependencies.
.NET Core 1.1 is a pre-requisite for supporting Fedora 24.

Hi @randomvariable, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
We will now validate the agreement and then real humans will evaluate your PR.
TTYL, MSBOT;

.NET Core 1.1 ships with an older dotnet/cli than has currently been used

That should not really matter, although, I think it could be acceptable to revert back for consistency.
Since we are not using nightly dotnet cli anymore.
Last pinned version of dotnet cli was completely random and it's probably better to stick with the one that corresponds to some release.

Appears the build in #2738 that I've got out of that doesn't allocate a tty, so is pretty unusable as an interactive shell. Not sure why.

TTY bug seems unrelated to .NET 1.1, have filed issue at https://github.com/PowerShell/PowerShell/issues/2745

Not sure why the DSC tests are failing. Any ideas?

Think this is ready to merge.

Commits added for each of the review comments.

The Travis CI failure is a known issue, not related to your PR. I have restarted it. I will merge this PR once it succeeds.

@randomvariable Thanks again for your contribution!


Issue when having a duplicate name in the lable

When we use a duplicate name when a label is created it gives a back end error. it is better is we can display an error like "The name is duplicated" under the label name field.

This PR contains the fix for handling error https://github.com/wso2/carbon-apimgt/pull/7524


Use deploy role to invoke migrations

Use the new terraform managed role to invoke the migrations. Jenkins instance role (used by default) doesn't have permissions anymore.

Pull Request Test Coverage Report for Build 736

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.83%

Totals

Change from base Build 734:
0.0%

Covered Lines:
874

Relevant Lines:
875

💛  - Coveralls


stories dataset for plm

What's the stories dataset?  Is it writingprompts? Thanks

@pkuzengqi, No, it is the story dataset from A Simple Method for Commonsense Reasoning.


TP - Improve profile diffing

Currently a profile diff will just compare a sorted version of the json of 2 profiles and then display them side by side highlighting the differences.  I find the old TO diff much more useful where

Anything that is the same is stripped in the diff, showing only differences
The differences shown are just 'param name' - 'value' - 'value', so you can easily see the name of the param and the value differences between the 2 profiles
Doesnt show the full json, I dont think this is particularly useful anyway

I disagree on 2 & 3.  Being able to see the context and an unchanged sibling can provide better insight of it a projected change looks right or isn't yours.
Currently I just do a browser find for "++" and "--" to skip to the relevant pieces.  A UI improvement I'm not sure is possible would be to model the JSON as a collapsed tree, then expand elements with changes.

I think you might be thinking of the snapshot diff.  That is something different and I would agree having the context there is useful.  This is in regards to the profile diff, which does not have the ++ -- differentiations, it has color highlights for each profile but leaves a lot of cruft in between that IMHO isnt really useful when comparing profiles

Ah, you're right.  I was mixing up Snapshot diff with Profile diff.  Statement withdrawn.

@ezelkow1 @jhg03a what about something like this?

you can compare 2 or more profiles
it shows ALL params associated with ALL the profiles being compared (whether there is a diff or not). maybe highlight the rows where there is a diff?
it allows you to add or remove params from a profile easily
it allows you to edit params easily

keep in mind, 2 params of the same name/config file with different values can currently be created as seen in this example (foo)

What about parameters with the same config file and value but different names? or different secure settings?

What about parameters with the same config file and value but different names?

Tom (hello.config); value:4 belongs to profile 1
Jerry (hello.config);value:4 belongs to profile 2
^^ that would show up perfectly in my above example. And as a user I could
a. leave it alone as it won't technically hurt anything or
b. remove Jerry from profile 2 and add Tom to profile 2 if i wanted to clean things up

or different secure settings?

this is not possible:
foo; hello.config; value:1, secure:false
foo; hello.config; value:1, secure:true

I think these changes are pretty good. It might be nice if there was a way to have the params with actual diffs be propagated to the top, then everything non-diff below those. That way you get the best of both worlds with easy to see diffs but still able to see everything if you want

I like it.  Rather than forcing the UI to include/exclude non-changes, I'd recommend a checkbox to show unchanged values.  Normally I wouldn't expect it to be relevant, but it is handy to turn on to verify that all 3 in this case had a given parameter to begin with and not have to change UI pages (probably still leaning on [ctrl]+f here, unless there's a search of some kind).
  If a parameter has more than X lines of text there might be a better way to display it.

If the parameter value includes newlines it could be displayed as a normal text block. Could even add syntax highlighting for configFile values that end with .lua (and aren't named location).

@jhg03a

Rather than forcing the UI to include/exclude non-changes, I'd recommend a checkbox to show unchanged values

Just so i'm clear. You want a way (a checkbox perhaps) to show/hide "equal" params across the profiles? in this example, a way to show/hide the bar parameter.

this is the same as the above design but a little cleaner/easier to work with imo

and yes, i can think of the best way to show/hide params with no diff or vice versa as well.


Indeterminate state for checkboxes

Feature Request
Ionic version:
[x] 4.x
Describe the Feature Request
Implement an indeterminate state for the ion-checkbox component. We need this for a nested checkbox tree structure.

Describe Preferred Solution
The easiest way is probably to add an indeterminate prop, because the indeterminate state is visual only and doesn't effect the actual value of the checkbox.
Related Code
@Component()
export class NestedCheckboxes {
  render = () => [
    <ion-checkbox indeterminate={true} />
    <ion-checkbox onClick={e => (e.target.indeterminate = true)} />
  ];
}

Additional Context
Article on CSS Tricks.
#11601 is the same (closed) request, just linking here for context.
I will try make a PR for this later today.

Released dev build 4.1.0-dev.201903041631.c641ae1 with this in it if you'd like to test it out in your app, thanks again for the PR!


Add mockito-kotlin inside mockito-bom

It would be nice to be able to use the current mockito-bom to define the version of mockito-kotlin. I know that, right now, their versions are not fully aligned but it would be really nice.

I understand the request and if they follow the same versioning cycle, this makes a lot of sense. However, since they publish at different times and are therefore not considered part of the same bundle (just like mockito-scala), I don't think we should do so.